“ Vendor risk “, pas toujours là où on l’attend…

(Article initialement publié sur LinkedIn en 2016)

Durant ma vie professionnelle, que ce soit en tant que développeur, architecte, consultant, DSI ou patron d’une entité de business IT, j’ai à de multiples reprises été confronté à des choix de clients qui m’ont plus ou moins surpris.

Le dernier en date illustre un cas de figure relativement fréquent dans les choix auxquels sont exposés les DSI.

Le contexte est le suivant : l’un de mes clients devait fournir un service de consultation de documents électroniques dans le cadre d’un contrat de service plus global à l’un de ses clients (un grand groupe français).

Il avait été initialement prévu, au moment du projet d’avant-vente, d’inclure sous forme SaaS un progiciel “ du marché “ développé par l’une des divisions de mon client et déjà vendu à plusieurs entreprises.

Ce logiciel, que nous appellerons “ X “, est un logiciel de GED (Gestion Électronique de Documents) comme il en existe des dizaines sur le marché.

Il embarque des centaines de fonctionnalités de classement, indexation, recherche, workflows métiers, etc.

Au court du projet, il s’est avéré que les besoins du client final étaient relativement simples, mais très spécifiques.

La question du développement d’un petit soft sur mesure s’est alors posée en lieu et place du progiciel sur étagère.

Comme tous les logiciels complets du marché, ce dernier a été conçu pour répondre aux besoins du plus grand nombre, sans avoir été conçu pour les besoins d’une entreprise en particulier.

Un éditeur, en général, conçoit un logiciel pour répondre à une problématique métier commune à plusieurs clients potentiels (de sorte à rentabiliser son investissement en le vendant à plusieurs entreprises, le coût de “ duplication “ du logiciel étant marginal pour ne pas dire nul).

Pour élargir cette base de clients potentiels, il doit identifier les fonctions communes dont le panel aura besoin, puis y ajouter une ribambelle de fonctions additionnelles dont seule une partie des clients auront besoin, mais qui lui permettront de se distinguer de la concurrence (et de prononcer la phrase magique : “ Oui, notre logiciel répond à tous vos besoins, ce n’est que du paramétrage “).

Il en résulte souvent (pour ne pas dire toujours), des logiciels obèses, dont le client final n’utilisera que 10% (au mieux) des fonctionnalités (étant entendu qu’il payera pour 100% de ces dernières).

Lorsqu’une entreprise a un besoin simple, mais assez spécifique, comme c’est le cas dans mon exemple, deux options s’offrent alors à elles :

• Prendre un logiciel du marché, utiliser 2% de ses fonctionnalités “ standard “ et payer pour le “ paramétrage “ (en fait le développement) des fonctionnalités spécifiques dont il a réellement besoin (une reprise d’historique, une intégration au S.I., etc.)
• Opter pour un développement spécifique qui répondra à 100% de son besoin et uniquement à ce dernier

Dans le premier cas, le client à l’impression d’avoir fait un choix prudent, puisqu’identique à bien d’autres entreprises.

Dans les années 70, on disait “ un DSI ne se fera jamais virer pour avoir choisi IBM “, dans les années 90 on disait “ un DSI ne se fera jamais virer pour avoir choisi Microsoft “, vous pouvez décliner ce genre de maximes à l’infini avec tous les produits à la mode actuelle.

Le problème, c’est que l’entreprise qui fait ce type de choix prend en fait des risques importants :

• Elle prend tout d’abord le risque avéré de payer doublement trop cher : premièrement parce qu’elle paye pour des fonctionnalités dont elle n’a pas besoin, ensuite parce qu’elle paye pour le développement spécifique des fonctionnalités dont elle a réellement besoin.
• Elle prend ensuite le risque d’être confrontée à des problèmes de stabilité : les développements spécifiques nécessaires viennent souvent s’insérer comme une verrue sur le logiciel “ standard “ puisqu’ils n’ont pas été prévus lors de la phase de conception initiale. De plus, le logiciel “ standard “ embarque beaucoup de fonctionnalités dont le client n’a pas besoin, mais qui sont autant de sources de “ Bugs “ dont il hérite malgré lui (il est couramment admis en ingénierie logicielle que les “ Bugs “ sont à peu près uniformément distribués dans un code source, plus ce dernier comporte de lignes, plus il y aura de “ Bugs “).
• Enfin, elle prend le risque de subir rapidement des problèmes de performance. Pour les mêmes raisons que le risque de stabilité, les nombreuses fonctionnalités inutiles (mais bien présentes) et la généricité avec laquelle le logiciel “ standard “ a été conçu pour répondre aux besoins d’un plus grand nombre (dans ses algorithmes de traitement, dans son modèle de données, etc.) sont autant de cycles CPU et d’octets mémoire (ou disque) inutilement consommés. Dans le meilleur des cas le client devra déployer une infrastructure disproportionnée pour atteindre le niveau de performance souhaité, dans le pire des cas (malheureusement majoritaire) il atteindra un palier logique au-delà duquel ajouter de l’infrastructure n’améliorera plus les performances.

Dans le deuxième cas, celui du développement 100% spécifique, le client a le sentiment de prendre un risque énorme : il sera le seul à utiliser le logiciel résultant.

En cas de pépins, il devra assumer son choix avec son prestataire, il ne pourra se réfugier derrière le choix de ses confrères et/ou concurrents.

De plus, la pérennité de sa solution dépendra uniquement de la santé de son prestataire (c’est du moins la vérité souvent perçue, j’y reviendrais).

En revanche sur un plan technique cela reste souvent la solution optimum :

• Le logiciel sera conçu sur la base du besoin client et de rien d’autre (le prestataire n’a pas intérêt à implémenter des fonctionnalités pour lesquelles il n’est pas payé).
• Il sera donc plus concis, plus léger, certainement plus performant et statistiquement (a qualité de développement égale) plus robuste (moins de lignes de code donc moins de “ Bugs “).

S’opposent donc deux classes de risques dans ce type de situations :

• Un risque “ technique “ souvent mal caractérisé (puisque le client l’attribue à tort plutôt au deuxième scénario)
• Un risque “ tactique “ qui se résume souvent à une question de pérennité : que vais-je devenir si mon prestataire de service, le seul à maîtriser le logiciel, disparaît ?

Vous aurez compris que le risque technique n’est pas forcément plus important dans le cadre d’une solution sur mesure, bien au contraire.

En ce qui concerne le risque tactique, le client oublie souvent de se poser la bonne question dans le cas d’un progiciel : que vais-je devenir si l’éditeur (dont je ne suis pas le seul client) continue de faire évoluer son logiciel (sans mes développements spécifiques) et finit par stopper le support officiel de ma version (ce qui ne manquera pas d’arriver) ?

Bien souvent, la réponse à cette question est douloureuse : il faut remettre la main au portefeuille pour “ porter “ (en fait redévelopper) son spécifique sur la nouvelle version du logiciel “ standard “ (qui a bien sûr tellement évolué qu’il n’est plus compatible avec le spécifique initial).

Pire encore, que se passera-t-il si l’éditeur décide de stopper purement et simplement ce produit pour repartir sur une base différente (cas souvent observé) ?

Où enfin, que se passera-t-il si l’éditeur disparaît ? Après tout, personne n’est à l’abri d’une faillite.

Certes, un Microsoft, un IBM ou un SAP ont moins de chances de disparaître qu’un prestataire de service de taille intermédiaire.

Mais il est plutôt rare de faire appel à un logiciel sur étagère chez Microsoft pour répondre à un besoin métier spécifique.

Le “ vendor risk “ est-il donc vraiment un problème pour ce type de solutions métier ?

Ma réponse est claire : non.

Imaginons deux cas de figure :

• L’entreprise A choisi un progiciel du marché de l’éditeur B plus un développement spécifique pour répondre à son besoin simple, mais particulier.
• L’entreprise C choisit un développement totalement spécifique réalisé par la société D pour répondre au même type de besoin.

Les sociétés B et D disparaissent (ou le produit édité par B sort du catalogue de l’éditeur).

L’entreprise A, qui n’est qu’un client parmi tant d’autres de B aura beaucoup de mal à récupérer les compétences voire les sources de son progiciel pour éventuellement en faire assurer le support par une société E (ou par elle même). Le logiciel de B est en effet certainement protégé par des brevets, et aucun éditeur ne vous cède la propriété intellectuelle de son progiciel même en cas d’accident de parcours.

Elle aura aussi beaucoup de mal à influer sur la stratégie de B pour le convaincre de garder son progiciel au catalogue simplement parce qu’elle continue à l’utiliser (vous pouvez en revanche compter sur les forces de vente de B pour convaincre A d’acheter la nouvelle version du logiciel).

L’entreprise C, en revanche, ayant payé pour un logiciel qui ne répond qu’à son besoin peut facilement négocier la propriété intellectuelle de ce dernier ou une session de cette propriété dans une clause de réversibilité.

De plus, le logiciel étant, comme indiqué, plus petit, il a certainement été conçu par une équipe de développeurs plus petite.

En cas de disparition de D, et au cas au l’entreprise C n’aurait pas les compétences internes pour reprendre le code source dont elle a négocié la propriété, elle peut toujours identifier la ou les ressources (les développeurs) clés de D maîtrisant son logiciel (elle les connaît d’ailleurs certainement déjà, car cet avec elles que B a affiné ses spécifications et mené à bien tests et intégration) puis les recruter.

L’illusion de sécurité qu’a acheté (au prix fort) l’entreprise A se retourne donc contre elle.

• Elle obtient une solution moins performante,
• Plus coûteuse,
• Probablement moins robuste pour son besoin,
• Probablement moins adaptée au final à son besoin,
• En fin compte moins pérenne en cas d’accident de son fournisseur.

Cette analyse n’est toutefois applicable que sur des surfaces fonctionnelles modestes et spécifiques (comme je l’ai introduit dans mon exemple), n’allez pas faire développer un OS ou un ERP sur mesure pour réduire votre risque…

Mais dans ce type de situations particulières, et malgré tout assez fréquentes en entreprise, posez-vous deux fois la question : choisir comme tout le monde pour répondre à un besoin qui m’est propre me met-il à l’abri des problèmes ?

Dans le monde du logiciel, la fabrication en grande série n’est pas (encore ?) un gage de qualité supérieure à “ l’artisanat “.

Quand vous le pouvez, choisissez donc plutôt un bon artisan.

Pour revenir à mon anecdote, le grand groupe français a choisi la première solution, et cela m’a d’autant plus surpris que les deux étaient proposées par le même fournisseur, en mode SaaS toutes les deux, au même prix et ce dans le cadre d’un contrat avec obligation de résultat.

Le risque tactique était donc a priori le même, mais le client a eu l’illusion que faire le choix d’un produit déjà utilisé par d’autres sociétés (qui n’ont pas le même besoin que lui) était moins risqué que d’utiliser une solution développée sur mesure pour lui, quand bien même il faudrait “ tordre “ le produit original et lui ajouter des fonctionnalités afin qu’il réponde au besoin.

Originally published at https://www.linkedin.com.