J'ai lu le rapport un mercredi matin, le café qui refroidissait, et je me suis mis à rire. Pas parce que c'était faux. Parce que c'était tellement juste que ça aurait pu être écrit sur un projet que j'ai vu déraper avant que certains de ses auteurs finissent le secondaire. L'index 2026 de l'échec en livraison logicielle, signé Sonatafy Technology, avait des noms tout neufs pour quatre façons de tuer un projet, et chacune était une histoire que je connais déjà par coeur. Même maladie. Nouveau marketing. J'ai fermé le portable, je l'ai rouvert, j'ai tout relu deux fois.
Voici le bout qui dérange. On mesure cet échec depuis plus de trente ans, et le taux a à peine bougé. Standish a commencé à compter dans les années 1990. Les méthodologies ont changé, les outils ont changé, les titres de poste ont changé, et les projets ont continué d'échouer de la même forme. C'est pas de la malchance. C'est une cause qu'on ne soigne pas.
Qu'est-ce que l'index 2026 de Sonatafy a vraiment trouvé?
Quatre patrons, avec des noms qui collent. Sonatafy a distillé 195 épisodes d'un balado de leadership logiciel en 48 récits d'échec détaillés, puis a cherché ce qui revenait d'un récit à l'autre (Sonatafy Technology, index 2026 de l'échec en livraison logicielle). Le résultat est la taxonomie de la mort de projet la plus citable que j'ai vue depuis un bout. Lis-la une fois et tu reconnais ton dernier mauvais trimestre dedans.
Les quatre : l'illusion du backlog, où l'équipe a l'air productive sur chaque graphique de vélocité tout en ne livrant rien qu'un client paierait. La taxe de coordination, où produit, ingénierie et direction veulent dire en silence des choses différentes, et le rework de ce décalage ressort des sprints plus tard, à coût exponentiel. Le vide de responsabilité, où on ajoute des ingénieurs et on devient plus lent, parce que personne ne porte le résultat. Et le vide de validation IA, où l'IA accélère la construction et la vérification ne rattrape jamais. Un rapport cachait un chiffre brutal : une entreprise du jeu de données a dépassé son budget de 42 millions de dollars en se déployant dans 20 marchés avant d'avoir validé que le produit marchait. Quarante-deux millions. Pour apprendre une affaire qu'une conversation difficile aurait fait sortir gratuitement.
Quatre patrons, habillés en langage 2026. Je pouvais en associer chacun à un projet d'il y a dix ou vingt ans sans forcer. Les noms sont neufs. Le cimetière est vieux.
Pourquoi le taux d'échec bouge-t-il à peine, peu importe la méthodologie?
Parce que presque toutes les méthodologies qu'on a livrées améliorent la construction, pas la décision de quoi construire. Pense à la parade. Le Waterfall promettait de la discipline. L'Agile promettait de la réactivité. Le DevOps promettait du flow. Chacun a vraiment amélioré une tranche de l'exécution, du feedback plus rapide ici, des pipelines plus propres là, et chacun a laissé intacte la partie la plus dure et la plus vieille : comprendre, avant de construire quoi que ce soit, ce que le système doit faire et pourquoi de cette façon-là.
Cette partie a un nom. La découverte. Elle est plate, elle démo mal, et c'est là que les échecs se sèment. Je pensais avant que les guerres de méthodologie étaient surtout une affaire d'ego et de conférences. J'ai changé d'idée en voyant assez de projets échouer dans tous les cadres. Le cadre n'a jamais été la variable. Une équipe peut rouler des cérémonies Agile parfaites et quand même construire la mauvaise affaire, magnifiquement, à temps, sous le budget, et la regarder mourir en production. La cérémonie était parfaite. L'exigence en dessous était une supposition que personne n'a vérifiée.
Fait que le taux tient parce qu'on optimise sans arrêt la partie qui n'a jamais été le goulot. C'est un peu comme acheter des fours plus rapides pour réparer un resto qui prépare la mauvaise commande. La cuisine va plus vite. Les plaintes ne s'arrêtent pas. Pour la mécanique complète du coût d'une exigence manquée qui descend en aval, on a passé à travers les chiffres dans le coût caché des exigences manquées, et la courbe du coût du délai dans la règle du 29x. La version courte : plus tu l'attrapes tard, plus ça coûte, et une exigence devinée est une erreur que tu as accepté de ne pas attraper avant qu'elle soit chère.
Vers quoi remontent vraiment les quatre patrons d'échec 2026?
Vers une seule place. Des exigences que personne n'a validées contre le vrai travail. Descends les quatre patrons jusqu'au socle et ils convergent. L'illusion du backlog, c'est une équipe occupée à livrer des fonctionnalités qu'aucune exigence validée n'a demandées. La taxe de coordination, c'est presque par définition un problème d'exigences : produit, ingénierie et direction qui tiennent trois modèles mentaux incompatibles de la même spec et ne le découvrent que quand le code rend le désaccord concret. Le désalignement, c'est juste des exigences non validées qui portent un calendrier.
Le vide de responsabilité ressemble à un problème de gestion, et en partie c'en est un. Mais demande pourquoi personne ne porte le résultat et tu trouves souvent qu'il n'y avait pas de définition partagée et validée du résultat à porter au départ. Tu ne peux pas tenir quelqu'un imputable d'une cible qui n'a jamais été fixée. Et le vide de validation IA, c'est le visage le plus neuf du plus vieux problème : une machine qui produit avec confiance ce qu'on lui a dit, quand ce qu'on lui a dit n'a jamais été vérifié contre la réalité. Je veux être juste, parce que ce serait paresseux de prétendre que les exigences sont la seule variable. Le talent compte. La discipline de processus compte. Le financement et la politique comptent, c'est sûr. Mais à travers trente ans de données, la couche des exigences est celle qui sort en premier, coûte le plus, et se répète le plus fort.
La preuve la plus claire à l'échelle nationale, c'est le National Programme for IT du Royaume-Uni, lancé pour le NHS en 2002, le plus gros programme logiciel civil au monde. L'estimation initiale tournait autour de 2,3 milliards de livres. Au moment de son démantèlement en 2011, les dépenses avaient dépassé les 10 milliards (Parlement du Royaume-Uni, rapport du Public Accounts Committee).
Le Public Accounts Committee n'a pas attribué l'effondrement à de mauvais ingénieurs ou à du code faible. Il l'a attribué à des exigences jamais ancrées dans le vrai travail. Les fournisseurs construisaient contre des spécifications centralisées qui ne captaient pas comment les milieux cliniques fonctionnaient vraiment, et les gens qui utiliseraient le système chaque jour n'ont pas été impliqués pour définir ce dont ils avaient réellement besoin. La spec venait d'en haut. La réalité venait d'en bas. Les deux ne se sont jamais rencontrées.
Dix milliards de livres. Pour réapprendre que documenter une exigence n'est pas la même chose que la valider. La technologie était constructible. Les exigences étaient une supposition portant l'autorité d'un mandat gouvernemental.
L'IA a-t-elle changé le patron d'échec, ou juste la vitesse?
Juste la vitesse. Et c'est tout le propos du vide de validation IA. Le patron d'échec est inchangé : construire la mauvaise affaire, la découvrir tard, payer pour la défaire. Ce que l'IA a changé, c'est l'horloge. Quand la génération était lente, une mauvaise exigence prenait des semaines à devenir une fonctionnalité brisée, et ces semaines étaient une assurance accidentelle, du temps pendant lequel un réviseur affûté ou un testeur nerveux pouvait attraper le trou avant la livraison. Ce coussin a disparu.
Maintenant un agent transforme un prompt d'une ligne en code qui roule, plausible, qui passe les tests, en quelques minutes. Donne-lui une mauvaise exigence et il construit la mauvaise affaire impeccablement, plus vite que personne peut la réviser, avec la confiance non méritée d'une syntaxe propre. L'erreur descendait en aval au pas. Là elle sprinte. On a déjà écrit comment ça se joue dans l'éditeur et la spec, dans ce qu'est vraiment l'intelligence des exigences, et la leçon tient : un constructeur plus rapide est un multiplicateur de force sur ce que tu pointes, y compris la mauvaise cible. L'IA ne fait pas échouer les projets de façons neuves. Elle les fait échouer plus tôt, et en plus grand volume, ce qui de loin peut ressembler au même vieux taux d'échec qui tient pendant que le tempo en dessous double en silence.
Qu'est-ce que régler les exigences d'abord change concrètement?
Ça change où tu paies. Chaque projet paie pour ses erreurs d'exigences; la seule question, c'est si tu paies dans une conversation de découverte pas chère ou dans un incident de production cher. Régler les exigences d'abord déplace l'attrape en amont, au moment où une erreur est une phrase que tu peux réécrire au lieu d'un système que tu dois reconstruire. C'est tout l'argument économique, et c'est vrai bien avant que quiconque prononce le mot « agentique » à voix haute.
Voici à quoi ça ressemble en vrai. Tu mènes la découverte exprès au lieu d'espérer qu'un analyste curieux trébuche sur l'exception manquante à la minute 55 d'une entrevue. Tu fais sortir l'hypothèse contradictoire entre deux équipes avant que le code la rende permanente. Tu captes la raison derrière chaque exigence, le pourquoi, comme un artefact de première classe, pour que la prochaine personne et le prochain agent en héritent au lieu de deviner. C'est à ça que sert l'intelligence des exigences. Elle traite la découverte comme un processus structuré et multi-experte avec un livrable digne d'être construit, pas comme une réunion qu'on saute quand le sprint est serré. L'index 2026 a donné aux patrons d'échec des noms mémorables. Tant mieux. Nommer une maladie, c'est du progrès. Mais on ne la guérit pas en la renommant aux cinq ans. On la guérit en soignant la racine, et la racine est la même depuis 1995.
Les noms changent. La cause, non.
L'index 2026 de Sonatafy a nommé quatre façons de tuer un logiciel : l'illusion du backlog, la taxe de coordination, le vide de responsabilité et le vide de validation IA. Des noms utiles. Sous les quatre dort la même racine que l'industrie documente depuis des décennies : des exigences fausses, incomplètes, ou jamais validées contre le vrai travail.
L'IA n'a pas changé ce patron. Elle a changé la vitesse, supprimant le délai accidentel qui laissait les équipes attraper une mauvaise exigence avant la livraison. Le taux d'échec bouge quand les exigences bougent, pas quand la méthodologie reçoit un nom neuf. Attrape l'erreur dans une conversation de découverte, où elle coûte une phrase, ou attrape-la en production, où elle coûte une reconstruction. Ce choix, fait avant qu'aucun code existe, c'est celui qui décide des projets depuis trente ans, et qui les décide encore.
Je suis retourné à ce rapport une troisième fois avant d'écrire ça. Mêmes quatre patrons. Même reconnaissance. La différence entre les projets que j'ai vus survivre et ceux que j'ai vus couler n'a jamais été la méthodologie et, ces temps-ci, ce n'est jamais le modèle. C'était si quelqu'un faisait le travail plate de valider les exigences avant que la construction commence. Ce travail-là est pas cher. Le sauter, c'est ce qui coûte dix milliards de livres.
Quelles sont les questions les plus fréquentes sur l'échec des projets logiciels?
