Construire, configurer ou acheter : comment un comité décide avec des critères clairs

Il est une scène qui se répète dans bien des comités. Quelqu'un présente un besoin : un processus qui vit aujourd'hui dans des tableurs, un portail que les clients réclament, une validation qui se perd dans la messagerie. Trois personnes autour de la table arrivent, chacune, avec une réponse déjà formée. La technologie dit qu'il faut le construire, parce que « on l'aura exactement comme il nous le faut ». La finance dit qu'il faut acheter un produit, parce que « c'est moins cher et il existe déjà ». Les opérations disent qu'il faut configurer ce que l'on a déjà, parce que « à quoi bon dépenser davantage ».

Les trois réponses peuvent être justes. Aucune ne l'est par défaut. L'erreur la plus coûteuse de cette décision est rarement de choisir le mauvais chemin parmi trois chemins raisonnables : c'est de choisir sans avoir posé sur la table les critères qui distinguent un chemin d'un autre, et de signer un contrat sans savoir ce que l'on achète réellement.

Cet article s'adresse à celui ou celle qui répond de cette décision : direction générale, finance et technologie dans une entreprise moyenne ou grande. Ce n'est ni un guide technique ni une comparaison de marques. Il propose six critères pour décider, un tableau à porter au comité, les questions qu'il convient de poser avant de signer un développement sur mesure et une explication honnête de la raison pour laquelle tant de systèmes sur mesure finissent en sauvetage.

Les trois chemins, dans les mots du comité

Avant de comparer, il convient que tous parlent de la même chose.

Configurer ce que vous avez déjà. Votre ERP, votre CRM, votre plateforme de flux ou votre système central offrent déjà des capacités que l'on n'utilise peut-être pas, ou à moitié. Configurer, c'est ajuster des paramètres, des règles, des formulaires et des rapports dans ce que l'éditeur prend en charge. On n'écrit pas de code nouveau, ou très peu, et le système reste celui de l'éditeur.

Acheter un produit. On acquiert une solution déjà construite pour un problème que beaucoup d'entreprises partagent : facturation, paie, gestion des polices, rapprochement. On paie une licence ou un abonnement, on l'adapte à l'activité par configuration et l'on accepte que certaines choses se fassent à la manière du produit. Ici, « acheter » inclut aussi bien le progiciel traditionnel que le service dans le cloud.

Construire sur mesure. On développe un système pour le processus particulier de l'entreprise. Il y a du code propre, des décisions propres et, si le contrat est bien fait, une titularité propre. Il y a aussi une responsabilité propre sur ce qui a été construit : quelqu'un doit le maintenir, le tester et le faire évoluer.

Il existe un quatrième chemin, qu'il convient de mentionner pour qu'il ne se glisse pas sans nom : combiner. Bien souvent, la bonne réponse est un produit pour la partie qui ressemble à celle des autres entreprises et une pièce sur mesure pour la partie qui distingue la vôtre. Les trois chemins ne s'excluent pas ; ce qui change, c'est l'endroit où l'on trace la ligne.

Six critères pour décider

1. À quel point votre processus vous différencie

C'est la question de fond. Si la manière dont votre entreprise fait quelque chose fait partie des raisons pour lesquelles les clients la choisissent ou pour lesquelles ses marges sont différentes, ce processus mérite une attention propre. S'il s'agit d'un processus que toute entreprise du secteur fait de la même façon (clôturer la comptabilité, émettre un justificatif fiscal, payer une paie), le construire crée rarement un avantage.

Un test utile pour le comité : un concurrent pourrait-il acheter demain le même produit et fonctionner comme nous ? Si la réponse est oui, cela ne vaut probablement pas la peine de le construire. Si la réponse est non, et que cette différence est précisément ce que l'on veut protéger ou développer, alors construire, ou au moins construire la partie qui différencie, mérite d'être sur la table.

Le test a un revers que l'on oublie : tout ce que l'entreprise croit la distinguer ne la distingue pas vraiment. Souvent, ce qui est « unique » est une habitude accumulée pendant des années, non un avantage. Avant de payer pour reproduire une habitude, il convient de se demander si le client remarquerait son absence.

2. Quelle urgence il y a et ce que coûte l'attente

Un produit qui existe déjà peut être mis en service en moins de temps qu'un produit qui doit seulement être conçu, mais « moins de temps » ne veut pas dire « peu de temps » : il faut le configurer, migrer les données, former les équipes et le connecter. Une configuration dans ce que vous avez déjà est généralement la plus rapide des trois. Un développement sur mesure est, en général, celui qui met le plus de temps à donner le premier résultat, sauf s'il est livré par parties et que la première partie est utile à elle seule.

L'urgence doit s'exprimer en argent ou en risque, non en anxiété : quel revenu est repoussé, quelle sanction se rapproche, quel client est perdu pour chaque mois d'attente. Avec ce chiffre, le comité peut comparer le coût de l'attente au coût de chaque chemin. Sans lui, l'urgence finit souvent par décider en faveur du chemin qui paraît le plus rapide dans la présentation, qui n'est pas toujours celui qui arrive le plus vite.

3. Quelle part d'intégration il exige

C'est ici que beaucoup de comités se trompent, parce qu'ils regardent l'écran et non les connexions. Un système nouveau fonctionne presque toujours en lien avec d'autres : il lit et écrit dans votre ERP, reçoit des données de vos canaux, livre de l'information à la comptabilité, répond à une autorité. Le travail d'intégration est généralement la partie la moins visible du projet et celle qui surprend le plus.

Chaque chemin l'aborde différemment. Un produit apporte des connecteurs pour les systèmes les plus courants, et la question est de savoir si les vôtres en font partie et à quel coût. Configurer dans ce que vous avez déjà réduit le nombre de nouvelles connexions, parce que le système est déjà connecté. Construire sur mesure donne la liberté de connecter ce dont on a besoin, mais chaque connexion est un travail qui se paie, se teste et se maintient ; et l'éditeur du système auquel on se connecte peut changer ses règles.

Une question concrète à porter à tout fournisseur, de produit ou de développement : avec lesquels de nos systèmes se connecte-t-il, par quelle interface prise en charge par son éditeur, et qui répond quand l'une des deux parties change ?

4. Qui va le maintenir

Un système ne s'achève pas le jour de sa livraison. À partir de là, il faut corriger des défaillances, s'adapter aux changements de réglementation, mettre à jour des composants qui ne reçoivent plus de support et répondre aux demandes de l'activité. C'est la part du coût qui apparaît le moins dans les propositions, et celle qui pèse le plus au bout de quelques années.

Dans un produit, la maintenance de la base est assurée par l'éditeur, et vous la payez. Dans une configuration, elle est assurée par l'éditeur de la plateforme, plus ceux qui ont fait les ajustements. Dans un développement sur mesure, elle est assurée par qui vous décidez, et c'est là que se trouve la question de fond : cette personne ou cette équipe existe-t-elle, dispose-t-elle de la documentation nécessaire et peut-elle tenir dans la durée ? Un système qui dépend du souvenir de celui qui l'a programmé est un risque déguisé en actif.

5. Coût total, non prix d'entrée

La comparaison la plus fréquente dans un comité oppose le prix du produit et le budget du développement. C'est une comparaison incomplète. Pour décider, le coût doit se voir sur plusieurs années et avec toutes ses lignes :

• Acquisition : licences ou abonnement pour un produit ; heures ou prix du projet pour un développement.
• Mise en œuvre : configuration, migration des données, intégration, tests et formation. Pour un produit, il convient de demander séparément et par écrit licences, configuration, migration, intégration, tests et formation.
• Exploitation : infrastructure, support, supervision et les personnes qui s'y consacrent.
• Changement : ce que coûte l'adaptation du système quand l'activité change. Pour un produit, cela dépend en général de l'éditeur et de son calendrier ; pour un système sur mesure, de votre capacité de maintenance.
• Sortie : ce que coûterait le fait de quitter le système et d'emporter les données et les règles ailleurs.

Aucun des trois chemins ne l'emporte à tous les coups dans cette analyse. Un produit peut revenir moins cher sur cinq ans et plus cher sur dix si l'activité s'éloigne de ce que le produit suppose. Un développement peut revenir plus cher au départ et moins cher si ce qui a été construit évite de payer des licences par utilisateur qui croissent avec l'entreprise. L'important est que le calcul existe, qu'il soit celui du comité et non de celui qui vend, et qu'il se fasse avec les lignes ci-dessus.

6. La sortie du fournisseur

C'est le critère que presque personne ne met sur la feuille le jour de la décision et que l'on regrette le plus ensuite. Chaque chemin crée une dépendance différente, et il convient de la nommer.

Avec un produit, la dépendance est envers l'éditeur : son prix, son calendrier de versions et sa pérennité. La question est de savoir ce qu'il advient de vos données et de vos règles si, demain, vous voulez changer de produit : peuvent-elles être exportées, dans quel format, avec quelle documentation ?

Avec une configuration, la dépendance est double : envers l'éditeur de la plateforme et envers celui qui a fait les ajustements. Les règles métier restent à l'intérieur de l'outil ; si elles ne sont pas documentées en dehors de lui, elles deviennent difficiles à reproduire.

Avec un développement sur mesure, la dépendance est envers celui qui l'a construit, et elle se réduit ou s'aggrave selon ce que dit le contrat. Le code dans votre dépôt, la documentation, les tests, les accès et un transfert vérifiable réduisent la dépendance et rendent envisageable le passage à une autre équipe. Sans eux, le fournisseur d'origine tend à devenir indispensable. La section suivante s'en occupe.

Le tableau à porter au comité

Le tableau suivant résume le comportement de chaque chemin face aux six critères. C'est un guide de raisonnement, non une mesure : les valeurs décrivent des tendances, et votre cas concret peut s'en écarter.

Deux observations sur la façon de l'utiliser. Première : ne comptez pas combien de cellules « favorisent » chaque colonne ; les critères ne pèsent pas pareil pour toutes les entreprises. Un comité confronté à une urgence réglementaire peut donner au deuxième critère un poids qu'un autre comité ne lui donnerait pas. Seconde : le tableau sert surtout à faire apparaître les désaccords. Si deux membres du comité notent différemment une cellule, c'est là que se trouve la conversation qui vaut la peine d'être tenue avant de contracter avec qui que ce soit.

Scénario (illustratif, sans client). Un distributeur de taille moyenne, présent dans plusieurs États, veut remplacer le processus par lequel ses chargés de compte autorisent des remises spéciales, qui se règle aujourd'hui par messagerie et une feuille partagée. Le comité note ses six critères. Le processus d'autorisation a des règles propres qui varient selon le client et le produit, et l'entreprise les considère comme faisant partie de sa façon de vendre : différenciation élevée. L'urgence est modérée : il y a des pertes, mais aucune date limite. L'intégration exige de lire les prix et les stocks de l'ERP et d'écrire l'approbation en retour : deux connexions. La maintenance relèverait d'une petite équipe interne. En additionnant les coûts sur cinq ans, un produit de flux d'approbation généraliste revient moins cher en licences, mais obligerait à programmer précisément les règles qui différencient l'entreprise, à l'intérieur d'un outil étranger. Un développement complet revient plus cher, mais concentre l'effort sur ces règles. Le comité décide de combiner : un produit de flux pour le parcours de la demande et une pièce sur mesure pour le calcul de la remise que l'on peut autoriser, avec le code et la documentation de cette pièce au nom de l'entreprise. Les chiffres du scénario sont omis à dessein : ce qui importe, c'est l'ordre des questions, non les nombres.

Quoi demander avant de signer un développement sur mesure

Si le comité conclut qu'il convient de construire, ou de construire une partie, le contrat devient l'instrument qui détermine si vous finissez avec un actif ou avec une dépendance. Quatre blocs de questions structurent cette revue. Toutes doivent avoir une réponse écrite avant la signature.

À qui appartient le code

La question paraît évidente et c'est celle qui engendre le plus de malentendus. Celui qui paie un système tient généralement pour acquis qu'il lui appartient. La Ley Federal del Derecho de Autor (loi fédérale sur le droit d'auteur, LFDA) établit des règles spécifiques qu'il convient de connaître. Ce qui suit est une lecture de son texte en vigueur sur le site de la Chambre des députés ; cela ne remplace pas l'avis de votre service juridique.

• Les programmes d'ordinateur sont protégés dans les mêmes termes que les œuvres littéraires, tant en code source qu'en code objet (art. 102).
• Toute transmission de droits patrimoniaux est onéreuse et temporaire, et les contrats par lesquels ils sont transmis, comme les licences d'utilisation, doivent être conclus par écrit ; à défaut, la loi les déclare nuls de plein droit (art. 30).
• L'article 33 prévoit un délai de cinq ans lorsque la transmission n'en fixe pas ; pour les programmes d'ordinateur, l'article 103 écarte expressément cette limitation. La rédaction de la cession et sa portée doivent être revues avec votre service juridique.
• Dans une œuvre de commande, l'article 83 établit, sauf accord contraire, une règle en faveur de celui qui la commande. Pour qu'une œuvre soit considérée comme réalisée sur commande, l'article 83 bis exige que les termes du contrat soient clairs et précis, et en cas de doute l'interprétation la plus favorable à l'auteur prévaut.
• Les droits patrimoniaux sur un programme créé par des salariés dans l'exercice de leurs fonctions reviennent, sauf accord contraire, à l'employeur (art. 103, premier alinéa). Si ceux qui développent le programme sont des salariés de votre fournisseur et agissent dans leurs fonctions, ces droits naissent chez votre fournisseur ; si des sous-traitants ou des prestataires indépendants interviennent, il convient de vérifier par écrit la chaîne de titularité. Ce qui parvient jusqu'à vous y parvient par ce que dit le contrat.

La conclusion pratique n'est pas que la loi vous retire le code ; c'est qu'il convient de consigner la titularité par écrit, avec des mots explicites. Questions pour le contrat :

1. Qui est le titulaire des droits patrimoniaux sur le système livré et sa documentation, et est-ce écrit ?
2. La transmission est-elle une cession de droits ou une licence d'utilisation, exclusive ou non exclusive ? Ce sont des choses différentes, avec des conséquences différentes.
3. Qu'advient-il des outils, bibliothèques et composants propres au fournisseur qui sont réutilisés dans votre projet ? Il est fréquent que le fournisseur conserve les siens et vous accorde une licence d'utilisation ; il convient alors de savoir si cette licence est perpétuelle, si elle est transférable et si elle permet à une autre équipe de maintenir le système.
4. La transmission est-elle assortie d'un délai, d'un territoire et de conditions, et est-elle inscrite là où la loi le prévoit pour produire ses effets à l'égard des tiers (art. 32) ? C'est une consultation pour votre avocat, non une affirmation générale.

Licences de tiers

Presque aucun système moderne n'est écrit de zéro : il est assemblé avec des composants open source, des bibliothèques commerciales, des services dans le cloud et des outils de développement. Chacun a sa propre licence, et chaque composant peut imposer des conditions différentes. Le contrat doit identifier lesquelles s'appliquent à chaque composant et à l'usage concret que vous ferez du système.

Questions pour le contrat :

1. Existe-t-il une liste de tous les composants de tiers, avec leur licence et leur version ? Demandez-la comme livrable.
2. Une licence limite-t-elle la façon dont vous pouvez exploiter, modifier ou distribuer le système ?
3. Quels composants ont un coût récurrent (abonnements, services dans le cloud, clés) et à quel nom sont-ils souscrits ? S'ils sont au nom du fournisseur, le jour où la relation prend fin, le système peut cesser de fonctionner.
4. Qui répond si un composant cesse de recevoir du support ou si une faille de sécurité y apparaît ?

Critères de recette

« Livrer le système » n'est pas une date, c'est une condition. Si la condition n'est pas écrite, la livraison se négocie à la fin, quand le budget est dépensé et que la pression est maximale, et la partie qui y perd le plus est celle qui a le moins de marge pour attendre.

Questions pour le contrat :

1. Que doit pouvoir faire le système pour être accepté, exprimé en situations que vous puissiez observer et répéter ? « Qu'il fonctionne bien » n'est pas un critère ; « qu'une demande présentant ces caractéristiques soit approuvée dans ce parcours et reste consignée avec qui, quand et pourquoi » en est un.
2. Qui exécute les tests de recette, dans quel environnement et avec quelles données ? Il convient que participe quelqu'un qui n'a pas construit le système.
3. Que se passe-t-il pour les défauts découverts après la recette, et pendant combien de temps le fournisseur les corrige-t-il sans frais ?
4. Des tests automatiques sont-ils livrés avec le code ? Ce sont eux qui permettent de modifier ensuite le système sans parier.
5. Les paiements sont-ils liés à des parties livrées et acceptées, et pas seulement au passage du temps ?

Transfert

Le jour de la livraison est celui où la connaissance du système est concentrée chez celui qui l'a fait. Le transfert est le processus par lequel cette connaissance passe à celui qui va l'exploiter.

Questions pour le contrat :

1. Que livre-t-on en plus du programme : code source dans votre dépôt, documentation de la façon dont il est assemblé et installé, instructions d'exploitation et de reprise après défaillance ?
2. Qui recevra le transfert de votre côté, est-il identifié et a-t-il le temps pour cela ? Un transfert à « l'équipe informatique » sans noms finit souvent en présentation.
3. Peut-on reconstruire le système de zéro à partir de ce qui a été livré, et quelqu'un d'extérieur au fournisseur l'a-t-il vérifié ? C'est l'une des épreuves les plus révélatrices qui existent pour savoir s'il y a eu un véritable transfert.
4. Quel support existe pendant une période ultérieure et à quelles conditions, et que se passe-t-il si vous préférez qu'une autre équipe le maintienne ?

Des réponses claires permettent de repérer les sujets que le contrat doit résoudre ; la suffisance de ses clauses doit être validée par votre service juridique avant la signature. Si une réponse devient vague, cette imprécision est une donnée et il convient de la traiter comme telle.

Pourquoi tant de systèmes sur mesure finissent en sauvetage

« Sauvetage » est le mot que l'on emploie lorsqu'une entreprise possède un système qui fonctionne, que personne ne veut toucher et qui ne peut plus évoluer au rythme de l'activité. Cela n'a pas toujours mal commencé. Les causes s'accumulent, et plusieurs sont visibles dès la signature.

Première cause : la taille et la durée font monter le risque plus vite qu'on ne le suppose. Il existe des preuves empiriques à ce sujet. Bent Flyvbjerg et Alexander Budzier ont analysé 1 471 projets informatiques et ont constaté que le dépassement de coût moyen était d'environ 27 % ; mais cette moyenne cache une queue de distribution : près d'un projet sur six a connu un dépassement de coût moyen de 200 % et un retard de près de 70 % [1]. Une étude postérieure, sur un échantillon de 5 392 projets informatiques, a constaté que les dépassements de coût suivent une distribution en loi de puissance : de nombreux projets avec de petits écarts et une queue de projets aux écarts extrêmes, de sorte que les projets informatiques sont « bien plus risqués en matière de coûts que ne le supposent normalement les décideurs » [2]. Les auteurs proposent comme explication possible l'interdépendance entre composants : un problème dans l'un peut déclencher des réactions dans d'autres [2].

Ce que cela signifie pour un comité : la bonne question n'est pas « de combien dérivera-t-on en moyenne », mais « que se passe-t-il si nous tombons dans la queue ». Un budget qui ne résiste qu'au cas moyen n'est pas un budget prudent. Ces chiffres sont de haute confiance quant à leur origine (vérifiés à la source), mais ils décrivent des échantillons de projets informatiques en général, et non uniquement des développements sur mesure ; ils ne doivent pas se lire comme la probabilité que votre projet échoue.

Deuxième cause : l'échec se mesure mal et se cite plus mal encore. On voit couramment, dans des présentations commerciales, des pourcentages d'échec de projets logiciels attribués au rapport CHAOS du Standish Group. Il convient de savoir que ces chiffres ont été contestés avec méthode. Eveleens et Verhoef, dans IEEE Software (2010), soutiennent que les définitions du succès de Standish reposent uniquement sur l'exactitude de l'estimation du coût, du délai et des fonctionnalités ; que cette mesure est unilatérale et gonfle les pourcentages de projets « en échec » ; et que faire la moyenne de chiffres produits par des processus d'estimation différents, chacun avec un biais inconnu, rend les résultats dépourvus de sens. En appliquant ces définitions à leurs propres données (5 457 prévisions de 1 211 projets réels), ils ont conclu que les chiffres de Standish ne reflétaient pas la réalité des cas étudiés [3]. C'est pourquoi cet article ne cite pas de pourcentages de CHAOS comme donnée. Si quelqu'un vous les présente dans une proposition, demandez la source et la définition de l'échec qu'il utilise. La réserve vaut dans les deux sens : il n'y a pas non plus de base pour affirmer que tous les projets se passent bien.

Ce qui reste debout, avec les deux sources précédentes, est une conclusion prudente : le risque existe, il est asymétrique et il est sous-estimé si on le juge à l'aune du cas typique.

Troisième cause : on achète un écran et non un actif. Beaucoup de systèmes sur mesure sont commandés pour ce que l'on voit : les écrans, le flux. Ce que l'on ne voit pas (les tests, la documentation, le dépôt, la liste des composants de tiers) est ce qui décide si le système peut évoluer. Quand ces livrables n'ont pas été demandés, le système fonctionne le jour de la livraison et devient ingérable au premier changement important. C'est la cause la plus évitable de toutes, et les quatre séries de questions de la section précédente existent pour cela.

Quatrième cause : le système dépend d'une personne. Un programmeur qui connaît tout le système est une force tant qu'il est là, et un risque quand il s'en va. C'est la raison pour laquelle la documentation et le transfert doivent peser dans le contrat autant que les fonctions.

Cinquième cause : on a construit ce qui existait déjà. Souvent, une partie du système reproduit des capacités qu'un produit offrirait à moindre coût de maintenance. Lorsque cette partie exige des changements constants du fait de la réglementation ou des standards, l'entreprise finit par soutenir, sur son propre budget, ce qu'un éditeur soutient pour des milliers de clients. Le critère de différenciation de la première section existe pour éviter cela.

Sixième cause : il n'y a pas de critère de sortie. Aucun système n'est fait pour durer indéfiniment. Si le contrat n'a pas prévu comment extraire les données et les règles, le remplacer est un autre projet à haut risque. Un système que l'on ne peut pas abandonner finit par être conservé par inertie, ce qui en fait une version lente d'un sauvetage.

Aucune de ces causes n'est inévitable ni propre aux développements sur mesure : les produits ont leurs propres versions (adapter l'activité au produit sans s'en rendre compte, par exemple). La différence est que, dans un développement sur mesure, plusieurs de ces causes peuvent être réduites par des décisions prises avant la signature et par un suivi pendant l'exécution, ce qui est l'objet de cet article.

Comment le porter au comité : une feuille, cinq questions

Pour que cette conversation ne reste pas générale, nous proposons une feuille d'une page que tout comité peut monter en un après-midi :

1. De quel processus s'agit-il, et à quel point vous distingue-t-il ? Avec le test du concurrent qui pourrait acheter le même produit.
2. Que coûte l'attente ? En argent ou en risque, par mois.
3. Avec quels systèmes se connecte-t-il et par quelle interface ? Une liste, non une phrase.
4. Qui le maintiendra dans trois ans ? Avec un nom ou avec un profil, et avec sa documentation.
5. Comment sortons-nous ? Ce que vous emportez, dans quel format et au nom de qui cela reste.

Si le comité ne peut répondre à l'une des cinq, ce trou est le premier livrable, avant toute proposition. Et si plusieurs réponses sont « nous ne savons pas », ce n'est probablement pas un fournisseur qui manque : ce sont des informations pour décider.

Ce que fait Hábil

Hábil aide les organisations à mettre en ordre cette décision avant de s'engager sur un chemin : ce qu'il convient de configurer, ce qu'il convient de résoudre avec un produit et ce qui vaut vraiment la peine d'être construit. C'est l'idée de la page Développement sur mesure, où l'on explique comment le périmètre est convenu, ce qui est livré et à quel nom cela reste.

Si une partie de ce dont vous avez besoin ressemble à ce que font d'autres entreprises, examinez le périmètre, les conditions et les intégrations applicables de nos produits : Retícula, Pauta et Cuadre. Ce que l'un d'eux couvre se configure au lieu de se programmer, et un projet sur mesure peut se concentrer sur ce qui est réellement le vôtre.

Si votre comité a déjà identifié le processus, les intégrations et les critères de sortie, vous pouvez confronter votre cas avec Hábil lors d'une première conversation, sans frais. Écrivez-nous sur WhatsApp pour la demander.