Parmi les cibles commerciales d’un éditeur de logiciel, il y a les particuliers puis les organisations. Ce terme organisation regroupe sous un même nom les entreprises de toute taille, les associations et le secteur éducatif dans son ensemble.

Vendre son logiciel à des organisations est généralement une bonne idée. Cependant, cela impose un cahier des charges minimum qui n’est que trop rarement respecté par les éditeurs.

Nous nous proposons d’exposer ici notre cahier des charges standard pour tout déploiement organisationnel d’un logiciel. Cet article est donc principalement à destination des éditeurs de logiciel. Il peut également être utilisé par différentes organisations afin de confronter leur pratique voir de servir de modèle.

Dans cet article, nous exposerons un cahier des charges à minima du point de vue IT. Il vient en complément du cahier des charges métier propre à chaque scénario et des éventuelles contraintes règlementaires.

Se conformer à ce cahier des charges IT ne fait pas d’un logiciel un bon logiciel pour l’entreprise. En revanche, ne pas s’y conformer, même partiellement, le classe automatiquement dans la catégorie des mauvais logiciels, représentant des coûts cachés non négligeables pour l’entreprise ainsi qu’un risque pour sa sécurité.

Sauvegarde

Tout logiciel, dès sa première gamme commerciale, doit impérativement fournir des outils de sauvegarde journalière et de restauration. Certains éditeurs ont pris pour habitude de faire payer un abonnement pour l’accès aux fonctions de sauvegardes. Ce genre de pratique est à proscrire.

Si le service est installé sur le matériel du client, les outils de sauvegarde doivent impérativement pouvoir fonctionner sans interface graphique, et sans session ouverte sur la machine.

S’il est question d’un service en ligne, un système de téléchargement automatique est impératif (par envois périodique d’e-mail ou via une API compatible avec le point suivant).

Automatisation des tâches

Dès lors qu’un logiciel vise une organisation, il vise une masse d’utilisateurs consommateurs d’une application qui sera gérée par une équipe informatique réduite. De fait, il est impératif que le logiciel offre des fonctionnalités d’automatisation des tâches liées à l’IT.

Cela peut se traduire par une API REST pour les services web ou encore des outils de ligne de commande UNIX / PowerShell.

Dans le cas d’outil en ligne de commande, il est bon de rappeler que les serveurs d’une entreprise ne sont pas exclusivement sous Windows, et que ce dernier à un coût de licence non négligeable. À ne supporter qu’un seul et unique système, GNU/Linux reste le choix le moins coûteux pour les clients.

Intégration au service d’annuaire

Peu importe le nombre d’employés, le service d’annuaire est au cœur de tout système d’information. Il contient l’intégralité des informations sur les utilisateurs et leur rôle. Tout logiciel destiné à une organisation doit obligatoirement être capable de consommer les informations de l’annuaire afin de réduire les temps de configuration nécessaires durant les opérations de ressources humaines.

Cela peut se traduire par le support de deux scénarios : LDAP ou SAML.

Annuaire 1.0 : LDAP

Historiquement, un annuaire d’entreprise est accessible à travers le protocole LDAP. Celui-ci permet l’authentification des utilisateurs ainsi que l’accès à toutes les informations de groupes de l’entreprise.

Un développeur supportant LDAP doit garder en tête que c’est un format ouvert à base de classe d’objets (très proche du développement orienté objet). De fait, un logiciel consommant une source LDAP doit impérativement être capable de prendre une série de paramètres indiquant comment interpréter les informations obtenue.

Active Directory, Open Directory eDirectory, LDAP fait maison, chacun à sa propre vision du monde. Ne comprendre que la vision du monde Active Directory du LDAP vous coupe ainsi du marché des TPE/PME utilisant les technologies Apple ou encore des universités souvent tournées vers des annuaires LDAP personnalisé.

Même dans le cas de l’Active Directory, il est important de comprendre que chaque organisation a sa politique de gestion des identités. Certains réseaux continuent d’utiliser les sAMAccountName limités à 20 signes et remplacés par Microsoft depuis Windows 2000, d’autres imposent une authentification avec les UserPrincipalName beaucoup plus adaptés au monde présent. Si vous ne supportez qu’un seul des deux, vous vous coupez de la moitié du marché.

Le LDAP a cependant un défaut, son fonctionnement repose sur une authentification envoyée par l’utilisateur à l’application qui la transfère ensuite au LDAP. L’application a donc accès aux identifiants et mot de passe des utilisateurs. Cela représente un risque majeur pour la sécurité d’une entreprise.

Annuaire 2.0 : SAML & SCIM

Technologie beaucoup plus moderne, le SAML et SCIM sont deux technologies permettant de remplacer le LDAP en palliant ses défauts de sécurité.

Lors d’une demande d’authentification sur un service supportant SAML, l’utilisateur est redirigé vers une page web appartenant à l’annuaire de l’organisation qui permettra d’authentifier l’utilisateur en fonction des réglages de sécurité de l’entreprise (identifiants, géolocalisation, double facteur, etc.). Une fois son travail fait, elle renverra de nouveau l’utilisateur vers l’application demandée avec le résultat de l’authentification et l’extrait intéressant des informations d’annuaire (nom, prénom, e-mail, etc.). Ainsi, les identifiants de l’utilisateur ne sont jamais vus par le logiciel tiers.

Cependant le SAML a un défaut, il ne précharge pas les informations vers le service ni ne le maintient à jour. La synchronisation est faite uniquement à l’authentification.

Pour pallier ce manque, un standard émerge, le SCIM. Il a pour objectif de standardiser et automatiser le processus de création, mise à jour et suppression des profils utilisateurs, depuis l’annuaire interne vers les services tiers.

Bien qu’une bonne partie des outils peuvent fonctionner avec une création et mise à jour d’information uniquement à l’authentification, et d’ici à ce que le SCIM soit supporté par tous, il peut être utile de mettre à disposition des outils de synchronisation avec les annuaires, ou de proposer des implémentations de référence utilisant les interfaces d’automatisation précédemment citées dans cet article. Cela permettra à l’organisation de précharger un service tiers si nécessaire.

Quelle méthode choisir ?

Deux solutions existent, laquelle supporter ? La question est légitime.

C’est un fait, le LDAP est bien plus connu que le SAML aujourd’hui. Bien que toute infrastructure reposant sur Active Directory le supporte gratuitement via le service ADFS. De plus, un certain nombre de portails Open Source permettant une intégration sur des annuaires personnalisés.

Le LDAP est un choix dangereux et compliqué. Il est très rare de le voir correctement supporté par un éditeur tiers. Laisser passer les informations d’identification dans les mains d’un tiers est un risque trop grand aujourd’hui. Il est rare de voir une entreprise accepter d’exposer son service LDAP sur Internet.

Peu importe l’hébergeur de services, grand comme petit, il sera un jour piraté. Il semble donc légitime de vouloir éviter que des codes d’accès soit volés en plus des informations d’entreprise.

Le SAML est la solution apportant le plus de simplicité aux éditeurs : il permet de déléguer l’authentification à l’organisation ainsi qu’une part des problématiques de sécurité. Il permet également à l’éditeur de profiter gratuitement de toutes les avancées en matière d’authentification forte : des outils comme Duo Security, VMware Identity Manager ou encore Open OTP pouvant augmenter le niveau de sécurité du service d’authentification sans nécessiter de changement de la part des fournisseurs de services.

SAML est donc la solution à retenir pour tout nouveau développement.

Hébergement

L’hébergement du service est une autre des problématiques sur laquelle deux écoles s’affrontent : en ligne et sur site.

Hébergement sur site

Choix historique de bien des entreprises, il complique le travail de l’IT en ajoutant des tâches de gestion d’infrastructure parfois complexes. Il a cependant l’avantage de répondre aux besoins de sécurité d’un nombre non négligeable d’entreprises :

  • localisation des données ;
  • capacité d’audit ;
  • capacité de détection en cas d’attaque ;
  • indépendance économique et structurelle de l’organisation.

Le dernier point peut surprendre, mais est tout autant important : un grand nombre de startups fait faillite ou est racheté dans les premières années d’activité. En hébergeant un service sur ses propres infrastructures, une organisation a la garantie de voir celui-ci épargné d’une coupure franche en cas de changement de cap de l’éditeur.

Hébergement en ligne

Grande mode permettant aux éditeurs de logiciels de s’assurer une rente permanente en devenant prestataire de service. Si elle est bien construire, cette solution peut également présenter des avantages pour certaines organisations.

Aujourd’hui, une organisation peut disposer de tous les services nécessaires à son fonctionnement, sans posséder aucune infrastructure physique. Annuaire avec authentification à double facteur, CRM/ERP, e-mail, contacts, calendrier, partage de documents, gestion de flotte de terminaux (iPhone, iPad, Mac, etc.), téléphonie sur IP, sauvegarde. Tous ces services nécessaires et suffisants à la plupart des entreprises peuvent être simplement loués aux éditeurs de logiciel qui hébergent eux-mêmes leurs solutions. De fait, ces services deviennent également utilisables depuis n’importe quelle connexion Internet.

Pour autant, cette vision du monde peut très rapidement être gâchée par les contraintes règlementaires auxquels font face certaines organisations.

Ainsi, pour prétendre proposer une solution en ligne à un marché économique, un éditeur doit y placer une filiale et garantir l’hébergement des données dans cette même zone et uniquement dans cette même zone.

Si un éditeur a une activité en Union Européenne et aux États-Unis d’Amérique, il lui est impératif de disposer d’une société dans chaque zone en charge du commerce et du technique. L’hébergement doit se faire chez des acteurs de confiance de cette zone et non des acteurs globaux. Par exemple, un éditeur installé en Europe, mais utilisant Amazon Web Service pour fournir ses prestations se verra recalé au premier audit de sécurité.

Système d’exploitation

Serveur

Dans le cas d’un déploiement sur site, il est bon de rappeler que toutes les organisations ne disposent pas de serveurs Windows. Aussi, une solution ne tournant que sur des serveurs Windows se prive d’un important de clients.

Supporter un serveur UNIX garantit un certain niveau de sécurité et de stabilité de la solution tout en réduisant les coûts de mise en œuvre. Les coûts cachés d’un logiciel ne sont pas négligeables quand celui-ci nécessite, par exemple, des licences Windows Server et Microsoft SQL Server.

Client

Les stations de travail permettant l’accès à un logiciel peuvent être de tout type aujourd’hui. iPad, Mac, Windows, Android… Tous les systèmes sont utilisés et n’en supporter qu’un place forcément l’éditeur sur un marché minoritaire.

De plus, de nombreuses organisations se retrouvent confrontées à des situations de mobilité de nos jours. Il est donc attendu qu’un logiciel puisse fonctionner à distance depuis un terminal mobile.

Fournir l’application via un navigateur web en respectant les standards du domaine permet à n’importe quel éditeur de fournir sa solution logicielle à l’intégralité du marché sans surcout. Dans un second temps, l’usage de statistiques clients réelles permet d’identifier les systèmes majoritaires pour lesquels une application native serait utile.

Gestion du déploiement

Une flotte de terminaux, cela prend du temps à gérer. Pour tout logiciel déployé il est impératif de disposer de solution de configuration automatique. Cela peut être via des services de découverte automatique ou plus préférablement des solution de gestion à base de MDM ou de GPO.

Dans tous les cas, il doit être possible pour les équipes informatique d’injecter préalablement les informations de configuration d’un logiciel afin de réduire le temps de déploiement et de gestion des postes. Cela peut inclure l’URL d’un serveur, l’identifiant d’un utilisateur comme des restrictions d’usage des fonctionnalités (par exemple interdit l’ajout d’un compte autre que le compte géré dans le cadre d’une application multi utilisateur).

Les entreprises de moins de 25 collaborateurs existent

Difficile de savoir qui a choisi ce nombre, mais il existe aujourd’hui une certaine discrimination envers les entreprises de moins de 25 collaborateurs qui les prives ainsi d’utiliser des solutions leur permettant d’améliorer leur fonctionnement.

C’est particulièrement le cas sur les solutions en ligne et les solutions d’infrastructure.

Cette limite est incompréhensible pour les installations sur site. Pour les installations en ligne, il serait plus aimable de proposer une grille de prix dégressif plus raisonnable afin qu’une organisation, même de 5 personnes, puisse profiter de service moderne et intéressant.