Trois fournisseurs chiffrent le même système de remplacement. Les montants varient du simple au quadruple, et aucun des trois ne ment. Ils répondent à des questions différentes, parce que personne ne leur a dit à quelle question précise répondre. Cet écart n'est ni un échec d'achat ni un échec de négociation. C'est un échec d'architecture, et il était déjà intégré au prix des mois avant l'ouverture de l'appel d'offres.
Le prix est fixé bien avant l’appel d’offres
Quand l’offre arrive, l’essentiel du prix est déjà décidé. Il a été fixé par la précision avec laquelle l’organisation acheteuse sait dire ce dont elle a besoin, à quoi le nouveau système doit se raccorder, quelles données lui appartiennent et ce que « terminé » voudra dire. Un fournisseur qui chiffre face à un périmètre clair chiffre une quantité connue. Un fournisseur qui chiffre face à un périmètre flou chiffre du risque, et le risque coûte cher.
C’est pour cela que trois offres honnêtes peuvent, dans beaucoup d’organisations, varier du simple au quadruple. Chaque fournisseur a comblé les trous du cahier des charges avec ses propres hypothèses, puis a majoré pour celles qu’il ne pouvait pas vérifier. Personne n’est cynique là-dedans. Ils chiffrent l’incertitude qu’on leur a remise.
Le fournisseur est souvent le seul à avoir la vue d’ensemble
Le problème de fond n’est pas un achat isolé. Après quelques années passées à acheter ainsi, le fournisseur est souvent la seule partie à disposer d’une image exacte de la façon dont le paysage s’articule réellement. Il sait quelle interface la paie utilise vraiment, quel traitement nocturne personne n’ose éteindre, et quels deux services dépendent discrètement d’un champ censé être provisoire.
Cette asymétrie n’est pas un effet secondaire de la relation. Elle est la relation. Elle fixe le prix de la prochaine montée de version, elle décide de la crédibilité que peut avoir une offre concurrente, et elle détermine ce que partir coûterait. Rien de cela n’apparaît comme une ligne de facture, et c’est exactement pour cette raison que ce n’est pas piloté.
L’IA a rendu le milieu bon marché, ce qui a déplacé le levier
Pendant vingt ans, la ressource rare dans le logiciel était la capacité de livraison. Les fournisseurs la vendaient, et acheter le conseil qui l’entoure paraissait une façon raisonnable de la diriger vers son propre problème.
Cette rareté s’est dissipée. Rédiger des exigences, esquisser une architecture, écrire du code d’intégration, entretenir une suite de régression et désormais explorer les parties d’un système que personne n’a spécifiées sont devenus plus rapides en environ deux ans. Nous utilisons ces outils au quotidien, et c’est justement le point : s’ils sont bons pour nous, ils le sont tout autant pour votre fournisseur, et la capacité qui justifiait la prime n’est plus rare.
Ce qui n’a pas baissé, c’est de savoir quoi demander, et de savoir si on l’a obtenu. Le jugement sur votre propre paysage, votre exposition réglementaire, vos données et ce qui devra rester vrai dans cinq ans ne se comprime pas. Le levier s’est donc déplacé du milieu du projet vers ses deux bouts.
Un premier passage, c’est du périmètre, pas de la spécification
Le bout amont est plus petit qu’on ne le croit, et c’est la partie la plus souvent sautée parce qu’elle a l’air de demander un an.
Ce n’est pas le cas. Ce dont une décision d’achat a besoin, c’est d’un périmètre : une cartographie des capacités à jour, les quelques intégrations réellement porteuses, les fonctions qui portent le dossier économique par opposition à celles de la liste de souhaits, les données et leur juridiction, et les compétences dont vos opérations métier auront besoin pour vivre avec le résultat. Dans notre expérience, deux semaines suffisent à relier les points, quand les bonnes personnes sont disponibles et dans la salle. Cette condition est la vraie contrainte, pas la méthode.
Le périmètre n’est pas la spécification complète et ne doit pas prétendre l’être. Le travail de détail revient au fournisseur que vous finirez par choisir, et c’est très bien, car vous spécifierez alors depuis une position connue plutôt que depuis une position vide. Le premier passage a trois raisons d’être : faire en sorte que trois fournisseurs chiffrent la même chose, vous dire quels produits vous devez réellement acheter, et vous dire quelles capacités vous devrez garder en interne, côté opérations métier comme côté opérations techniques.
C’est de la pratique TOGAF et IREB ordinaire, menée volontairement tôt et volontairement peu profond. Rien de neuf là-dedans. Ce qui est neuf, c’est que cela est devenu assez bon marché pour qu’une organisation de taille moyenne puisse le tenir, là où seul un grand groupe pouvait se le permettre il y a cinq ans.
Le document avec lequel vous achetez est celui contre lequel vous réceptionnez
Voici ce qui fait de ces deux bouts une seule capacité plutôt que deux prestations.
L’exigence que vous avez écrite pour aller au marché est celle contre laquelle vous jugerez plus tard la livraison. Écrite une fois, utilisée deux fois. Si les critères de réception étaient assez explicites pour être chiffrés, ils le sont assez pour être testés, et une suite de régression en est la forme durable. S’ils ne l’étaient pas, la réception devient affaire d’opinion, et l’opinion, au moment de réceptionner, favorise toujours la partie qui a vécu dans le code.
C’est la raison pratique de résister à un cahier des charges flou, bien plus que tout principe de rigueur. Un cahier des charges flou ne vous coûte pas seulement de l’argent au départ. Il vous coûte la possibilité de dire non à l’arrivée.
La version courante de cette histoire : un logiciel est livré, puis les exigences sont reconstituées après coup et les tests terminés rétroactivement, parce que personne n’avait écrit contre quoi réceptionner. Ce travail se fait quand même, mais au pire moment, sans moyen de pression, et il se termine souvent par un changement de fournisseur.
La réception appartient au camp qui devra vivre avec le résultat
La réception formelle est en général signée par la personne mesurée sur le jalon. C’est la mauvaise personne, sans faute de sa part. Un chef de projet répond d’une date, et l’incitation honnête à la fin d’un projet en retard est de réceptionner et de passer à la suite.
Deux autres parties devront vivre avec ce qui est signé, et on en parle régulièrement comme s’il n’y en avait qu’une. Les opérations métier, c’est le client : l’organisation qui exploitera le service pour ses propres clients, en portera le coût, en répondra devant son régulateur et devra le faire évoluer. Les opérations techniques, c’est celui qui maintient la chose en marche ensuite : appliquer le correctif de CVE, restaurer la sauvegarde et produire les preuves quand un auditeur les demande. Le premier rôle revient toujours au client, le second au client, à nous ou au fournisseur, selon ce qui a été contractualisé. Ni l’un ni l’autre n’est généralement dans la salle quand le procès-verbal de réception est signé.
À la réception, nous agissons pour les opérations métier : c’est le camp que la réception est censée protéger, et celui qui porte le résultat des années après la clôture du projet. Ce qui rend ce jugement digne d’être acheté, c’est le second rôle : nous exploitons nous-mêmes des systèmes en production, donc nous savons ce qu’un raccourci dans une interface, ou un runbook manquant, coûte réellement une fois l’équipe projet partie. Le savoir n’est pas la même chose qu’être la partie qui devra vivre avec, et nous veillons à ne pas confondre les deux.
En pratique, il s’agit de tests de réception contre les exigences explicites, menés par notre propre pratique de test plutôt que par le fournisseur que l’on juge à leur aune. C’est un rôle inconfortable à confier à quelqu’un, et c’est celui qui se rembourse dès le premier refus.
Là où cela tourne mal
Internaliser l’architecture à moitié est pire que ne pas le faire. Une cartographie des capacités que personne ne met à jour est un risque, parce que les gens lui font confiance. Une fonction architecture sans autorité sur les décisions d’achat est un exercice de documentation, et le premier projet avec une échéance la contournera.
Le test est peu spectaculaire, et c’est celui qu’il faut appliquer avant tout autre. Pouvez-vous remettre à un fournisseur concurrent un périmètre assez précis pour qu’il chiffre dessus, sans l’aide de votre prestataire en place ? Pouvez-vous dire, aujourd’hui, ce qui vous ferait refuser la prochaine livraison ? Si les deux réponses sont oui, la capacité est là, et vos prix le montreront. Si l’une est non, c’est précisément là qu’est le travail, quoi qu’en dise le schéma accroché au mur.
Deux bouts et un milieu
Un projet logiciel comporte trois parties que l'on peut acheter séparément : décider ce dont on a besoin, le construire, et juger si ce qui est arrivé correspond au besoin. La plupart des organisations achètent les trois au même fournisseur, puis s'étonnent que la troisième soit si généreuse.
Le milieu est devenu la partie la moins chère à acheter et la plus facile à comparer. Les deux bouts n'ont pas baissé, et ce sont eux qui décident du coût du milieu.
Gardez la main sur les deux bouts. Achetez le milieu. Et gardez de votre côté de la table la personne qui signe la réception.
