Candide et les éditeurs de logiciel

Dans cette série d'articles dédiée à la culture générale en informatique, j'ai essayé de me mettre dans la peau de quelqu'un de novice qui se trouverait conduit à exercer une responsabilité quelconque impliquant la mise en oeuvre de moyens informatiques. Et j'ai essayé de lui donner quelques points de repères. On ne parlera pas ici de technique, ou très peu, mais plutôt des acteurs du secteur, des différents métiers, des tendances, de différents façon d'aborder des projets.

Ces articles n'intéresseront aucunement les professionnels du domaine, ils visent plutôt une population de non informaticiens qui veulent avoir un minimum de compréhension de l'écosystème de l'informatique, et ce pour éviter de se faire dévorer tout cru quand ils iront se frotter au milieu.

Dans cet article, je vais parler d'un type d'acteur incontournable : les éditeurs de logiciel.

Les éditeurs de logiciel.

Leur activité consiste à fabriquer des logiciels qu'ils vont ensuite commercialiser auprès de clients dits "finaux", selon différents canaux de vente et diverses modalités commerciales.

Microsoft pour prendre un exemple connu de tous est un éditeur, il fabrique (développe) la suite Office (Word, Excel, Powerpoint etc) ou Windows 10 pour citer deux produits phares. Puis il vous vend le droit d'installer et d'utiliser le logiciel, ce qu'on appelle une licence utilisateur.

Citons quelques éditeurs incontournables : IBM, Oracle, Adobe, Apple

Les licences d'utilisation

Vous n'achetez pas un produit auprès d'un éditeur, mais le droit de l'utiliser dans le respect de conventions définies. Les conventions étant définies par la licence d'utilisation.

Par exemple, quand vous achetez une licence d'un système d'exploitation (Windows 7, Windows 10 etc) la licence détermine si vous n'avez le droit de l'installer que sur une machine unique, celle sur laquelle vous l'avez installé la première fois (ce modèle de licence est souvent appelé OEM), ou au contraire si vous aurez le droit quand cette machine sera abandonnée (en panne, renouvellement du matériel etc.) de l'installer à nouveau sur une autre machine (souvent appelé licence "boite"). Notez bien que dans les deux cas, une licence ne donne le droit qu'à une seule installation sur un seul poste. Il existe aussi bien sur pour les entreprises des licences en volume qui donnent le droits à n installations.

Dans les deux cas le produit est exactement le même mais le prix est bien différent : la licence, OEM est bien moins chère que la licence "boite". Quand vous achetez un PC de distributeur, il est généralement vendu avec un OS pré-installé sous licence OEM (le nom de la licence, Original Equipment Manufacturer vient de là), ce qui explique que vous n'avez pas le droit, et très généralement pas la possibilité via divers systèmes de contrôle, de réinstaller l'OS fourni avec la machine sur une autre machine : répétons nous bien, vous n'avez pas acheté le logiciel mais uniquement un droit d'usage limité (en l’occurrence à la machine sur laquelle il a été installé la première fois).

J'ai donné l'exemple d'un logiciel "utilisateur" qui est destiné à être installé sur un poste de travail pour être utilisé par une personne (celle qui utilise la machine). Mais les éditeurs commercialisent aussi des logiciels qui par nature sont destinés à être installés sur un serveur et à être utilisés par un nombre variables d'utilisateurs. Ces logiciels sont totalement incontournables et vous en utilisez quotidiennement  : messagerie, base de données, annuaires, serveurs web etc.

Les modèles de licence sont alors bien différents et leur tarif est généralement conditionné par différentes métriques, éventuellement combinées : 

• le nombre d'utilisateurs. Ce peut être par exemple, 10 utilisateurs préalablement identifiés qui sont les seuls autorisés à utiliser le logiciel, ou encore 10 utilisateurs quelconques auquel cas 10 personnes maximum ont le droit d'utiliser le logiciel simultanément peu importe qui elles sont (ce second modèle est plus souple)

• la puissance du serveur. C'est la capacité de traitement du serveur (l'ordinateur, la machine), sur lequel est installé le logiciel, qui va déterminer le tarif. La puissance se quantifie généralement via le nombre de processeurs ou le nombre de cœurs (les processeurs modernes disposent de plusieurs cœurs, le processeur est le composant "englobant" qui est enfiché sur la carte mère, le cœur est le composant englobé utile où se trouve la puissance de traitement). Il existe d'autres systèmes de quantification plus complexes.

• Le volume d'utilisation. C'est l'utilisation du logiciel qui détermine le tarif. Si vous l'installez et n'en faites rien, il ne coûtera rien, si vous l'utilisez abondamment le facture sera en conséquence. Le volume ici encore peut se quantifier de bien des façons qui dépendent étroitement de la fonction du logiciel (pour un logiciel de paye ce sera peut être le nombre de bulletins de paye émis, pour un logiciel de bourse le nombre d'ordres passés etc.)

Il existe sans doute d'autres possibilités, je ne cherche pas à être exhaustif, et de toute façon on peut compter sur les éditeurs pour faire preuve d'imagination en la matière.

Le modèle économique

Il faut bien comprendre le modèle économique des éditeurs.

Ils supportent intégralement le coût de réalisation du logiciel (encore que, ils ont diverses astuces qui leur permettent de s'en faire financer une partie par les clients). Ensuite, ils vendent des licences. Si le produit a coûté 1000 Euros, et qu'ils tarifient une licence d'utilisation mono-utilisateur 10 Euros, une fois qu'ils en ont vendu 100 ils sont à l'équilibre et toute vente supplémentaire est de la marge pure (je simplifie). C'est pourquoi les éditeurs qui sortent des logiciels à succès sont extrêmement riches.

Ceci explique que dans certains contextes concurrentiels où un éditeur veut absolument placer un premier produit chez un client (dans l'optique de placer ensuite le reste de sa gamme), il peut se permettre de baisser considérablement son tarif de base, voire offrir le produit (qui au final ne lui coûte rien une fois amorti). Ceci explique aussi pourquoi les tarifs sont aussi souvent opaques (de nombreux éditeurs ne communiquent même pas de prix public, ou alors ont des systèmes de tarification tellement alambiqués que même eux ont du mal à s'y retrouver). Conclusion : négociez pied à pied et faîtes jouer la concurrence. 

J'ai parlé jusqu'à présent des modes de commercialisation "anciens" tels qu'ils se sont toujours pratiqués, et se pratiquent toujours (fréquemment sous l’appellation "on premise") : vous achetez une licence, vous obtenez une copie du logiciel, vous l'installez  sur vos postes de travail ou vos serveurs, et vous l'utilisez. Mais une tendance très forte est la commercialisation de logiciels en mode SAAS dans lequel le logiciel est mis à disposition sur Internet et facturé selon l'usage. Je vous renvoie pour plus de détail à un précédent article de ce blog dédié à l'informatique dans le cloud. Le modèle économique est un peu différent car l'éditeur vend ici du service en plus d'un droit d'utilisation de ses logiciels (l'exploitation de la plateforme technique sur laquelle est installée le logiciel dont vous louez les services).

Les pièges

Si envisagez l'achat de licences, soyez très prudents. et prenez bien le temps d'étudier les offres en détail. Les éditeurs multiplient les astuces pour vous facturer le plus possible, en multipliant les options incompréhensibles, et les (très) mauvaises surprises ne sont pas rares.

Le dernier sport des éditeurs consiste à réaliser des audits de votre utilisation afin de détecter des cas d'utilisation non couverts et réclamer des sommes exorbitantes, devant les tribunaux si nécessaire. Certains cas n'étant parfois ni interdits, ni autorisés, il peut régner un certain flou artistique et les juges n'étant pas des experts en informatique, hé bien on peut toujours espérer... plutôt que de devoir supporter le risque juridique et devant le coût des procédures juridiques, certains entreprises qui contrairement aux éditeurs ne sont pas assises sur un trésor de guerre et ne disposent pas de bataillons d'avocats spécialisés préfèrent négocier et payer. Les éditeurs sont certes légitimes à défendre leur droit de propriété intellectuelle, mais dans certains cas, on n'est pas loin d'une forme de racket. Deux exemples actuels :

• SAP : qui profite du flou sur les accès par des systèmes tiers aux données gérées par ses applicatifs

• Oracle : qui a profité du rachat de Java (développé par Sun), gratuit depuis toujours, pour ajouter des produits sous licence payante que certains utilisent sans se douter qu'ils sortent du cadre gratuit pratiqué depuis toujours.

L'open source

Il nous faut évoquer le cas des organisations open source. Même si elles ne commercialisant pas toujours les logiciels qu'elle développent, elles n'en mènent pas moins une activité assez largement assimilable à celle d'un éditeur de logiciel "traditionnel" : elles fabriquent des logiciels et les diffusent.

Par ailleurs, certains éditeurs choisissent de diffuser leurs logiciels avec des licences gratuites et open source, et de gagner leur vie non pas par la vente de licences mais par la vente de services connexes ou d'extensions payantes. J'ai déjà assez abordé ces points dans un précédent article vers lequel je vous renvoie.

Les pratiques commerciales de ces acteurs, quand ils sont à vocation commerciale, sont je dirais généralement plus simples à appréhender. Je ne vais pas rentrer dans le détail mais je dirais simplement qu'ici aussi il faut bien étudier l'offre et déceler d'éventuels chausses-trappes (de façon assez générale, l'offre gratuite qui est souvent mise en avant est elle vraiment suffisante, quelle en sera l'impact sur le coût des ressources humaines, à quel moment et à quel coût devrez vous basculer sur un modèle payant en raison de limitations de la version gratuite).

Certaines organisations, de par la nature particulière de leur modèle de développement (équipes mouvantes, distribuées sur toute la planète, sans cadre organisationnel aussi strict que ceux rencontrés dans une entreprise classique), ou de leur activité (plateformes serveurs à l'échelle mondiale traitant des volumes énormes avec de fortes contrainte de disponibilité) sont à l'origine de nombreuses innovations en terme de méthodes de travail, de technologies et d'outils, qui ont largement influencé le milieu informatique.  Les technologies sont fréquemment mises à disposition gratuitement et en open source. Des entreprises tentent parfois de répliquer ces modèles sans vraiment en comprendre les pré-requis. Attention ici à l'effet de mode : si l'adoption de ces pratiques peut se révéler être un superbe levier de productivité ou de développement, il n'y a pas de panacée et ce qui convient parfaitement à une multinationale du web ne sera pas nécessairement transposable dans une entreprise plus modeste et plus traditionnelle.

Les projets d'intégration

La mise en oeuvre d'un logiciel éditeur, que ce soit un logiciel propriétaire ou une solution open source, est un projet informatique en soit. Il peut s'agir d'un petit projet si le travail se limite à l'installation et à un peu de paramétrage (voire uniquement du paramétrage en cas de mise en oeuvre du modèle SAAS), ou d'un projet pharaonique dans le cas par exemple de la mise en oeuvre d'un ERP comme SAP qui implique beaucoup de paramétrage complexe et des développements complémentaires pour s'interfacer finement avec le SI.

On distingue généralement les projets qui visent à déployer et intégrer au SI un logiciel qui fournit des fonctionnalités nativement (on parle généralement de projet d'intégration), et les projets basés sur la mise en oeuvre d'un langage de programmation avec lequel un logiciel "sur mesure" est développé par une équipes de programmeurs spécialisés (on parle généralement de projet de développement spécifique).

Un projet d'intégration est supposé être moins coûteux : le logiciel (ses licences d'utilisation) est vendu en volume et le coût de développement amorti sur de nombreuses ventes, vous ne supportez donc qu'une fraction du coût du produit. A l'inverse en cas de développement spécifique vous supportez seul la totalité du coût de développement.

Ceci n'est cependant vrai que si il y a une forte corrélation entre les capacités du logiciel et les besoins de l'entreprise. L'intégration d'un logiciel du marché inadapté au besoin sera risquée et coûteuse.



Il y a ici deux travers à citer :

• projet d'intégration : il faut bien s'assurer que la couverture fonctionnelle du logiciel est satisfaisante, et accepter dans une certaine mesure d'adapter son mode de fonctionnement aux contraintes apportées par le logiciel. Vouloir faire le contraire est contre nature et conduit fréquemment à l'échec. Les capacités de paramétrage des logiciels et leur capacité à s'adapter à des cas particuliers n'est pas illimitée.

• projet spécifique : il faut accepter de ne pas avoir nécessairement le même niveau de fonctionnalité et de confort d'utilisation qu'avec un logiciel du marché. La raison en est simple : un éditeur peaufine son produit pendant des années et dispose de ressources techniques très importantes, il peut mettre beaucoup de moyens et d'argent sur la table ; à l'inverse une équipe de développement mobilisée temporairement pour un projet dispose de moins de temps, de moins de budget, et souvent de moins de compétences. 

Ne cherchez pas à avoir le beurre et l'argent du beurre, généralement vous n'aurez ni l'un ni l'autre.

Une autre point important à avoir en tête : les éditeurs sont en général peu enclins, dans le contexte de projets d'intégration, à prendre des engagements de résultat : ils savent à peu près ce que leur outil sait faire (ses fonctionnalités, ses capacités à traiter des volumes importants avec des temps de réponse satisfaisant) mais pour autant ils se contentent généralement de promesses.

Ça se comprend parfaitement de leur point de vue car ils ne maîtrisent pas le besoin précis de leur client (et donc la capacité de leur outil à y répondre), ni l'infrastructure matérielle qu'il va mettre en place (les machines seront elles assez puissantes ?), ni leur organisation (y aura  il des personnes formées et disponibles, le projet sera il géré correctement ?). Et plutôt que de prendre des risques liés à ces zones d'incertitudes, ils se limitent à  vendre des licences et à proposer des prestations d'expertises facturées très très cher au temps passé, donc sans engagement de résultat (et par expérience, il n'est pas rare que les compétences des "experts" soient très largement exagérées).

Si le client veut un engagement ferme, il doit se tourner vers une société de prestation de service en informatique qui sera chargée de mener le projet d'intégration, avec une enveloppe budgétaire définie par avance. Dans le cas où le produit ne permet pas de répondre au besoin, c'est l'intégrateur et le client qui payeront les pots cassés, l'éditeur lui sera gagnant dans tous les cas. Même sanction si le logiciel est adapté mais que le projet d'intégration échoue (par la faute du client ou de l'intégrateur, ou des deux). Pour cette raison, il faut se méfier des promesses plus ou moins vagues des éditeurs en phase d'avant vente : ils peuvent parfaitement vous vendre un produit sans être sur qu'il répondra à vos attentes, voire même en sachant que ce n'est pas le cas (et là on est dans la malhonnêteté la plus complète).

Certains logiciels éditeurs n'apportent  que peu, voire aucune, fonctionnalité en eux même, mais fournissent l'ossature technique ou fonctionnelle sur laquelle s'appuyer pour réaliser des développements spécifiques "sur mesure" (par exemple des outil de gestion de processus métiers, ou des outils de gestion de contenu) ; une fine connaissance du produit de la part des informaticiens chargés de la réalisation du projet est alors requise. Il n'est pas inutile de s'assurer de ce point, en demandant par exemple des références d'intégration réussies du produit chez un autre client.

On peut rencontrer des difficultés avec des outils éditeurs très spécialisés et/ou très peu répandus que très peu de personnes connaissent sur le marché, sachant en outre que les logiciels éditeurs sont souvent très peu documentés publiquement. En clair, pour avoir accès à l'information qui permet de juger de la capacité de l'outil, il faut commencer par l'acheter pour avoir accès à la documentation (dans le meilleur des cas) ou au support technique de l'éditeur. Et bien sur si à ce moment là, on se rend compte de certaines limitations dont le commercial de l'éditeur s'était bien gardé de parler, il est trop tard.


Je terminerais cet article par un dernier avertissement.

On constate dans de nombreuses entreprises des tensions entre la fonction informatique (la DSI) et les fonctions métier (les gens qui utilisent les outils informatique pour faire leur travail et faire tourner leur entreprise). Et il n'est pas exceptionnel que des responsables métier (hors de la DSI) décident de court-circuiter les services informatiques et de s'appuyer sur des éditeurs pour mettre en place des outils informatiques. Et l'émergence du cloud et des offres SAAS (location de logiciel facturé à l'usage, installé et exploité dans le cloud par un prestataire externe) ne fait qu'amplifier la chose (il est plus facile de cacher qu'on a signé un contrat avec un éditeur qui a une offre dans le cloud que d'acheter et d'installer du matériel informatique en cachette).

Ce phénomène a d'ailleurs pris une telle ampleur qu'il a un nom (shadow IT, informatique fantôme) et fait même l'objet d'études. Il peut  arriver que ça donne de très bons résultats mais c'est à mon sens une très mauvaise pratique.

A chacun son métier, et les personnes non formées au métier de l'informatique ont d'une part toutes les chances de se faire emberlificoter par des jolies présentations des commerciaux de l'éditeur et le fameux "effet waou", et surtout n'ont généralement aucune conscience des multiples contraintes à prendre en compte dans la mise en place d'outils un tant soit peu critiques (supervision, exploitation, sauvegardes, sécurité ...) ni des coûts associés, ni de la nécessité de considérer l'architecture du système informatique dans sa globalité afin d'éviter de la scléroser et de la rendre ingouvernable au bout d'un certain temps.

Conclusion

Voilà pour ce premier article intitulé "Candide et les éditeurs de logiciel" en référence bien entendu au Candide de Voltaire. J'espère qu'il évitera des déconvenues à certains en remettant quelques pendules à l'heure : un homme averti en vaut deux.

Dans un prochain article, je me pencherais sur les SSII (ou ESN comme on les appelle maintenant). J'essayerai modestement (car le sujet est complexe) de donner quelques clés aux novices afin de mieux appréhender leur mode de fonctionnement et leur éviter de tomber dans les pièges les plus grossiers.