Je construis des logiciels depuis 25 ans. J'ai vu les outils devenir plus rapides, les frameworks s'améliorer, les pipelines de déploiement passer de jours à secondes. Et pendant toute cette période, ce qui détermine réellement le succès d'un projet n'a pratiquement pas changé.
Ce n'est pas le code. Ça n'a jamais été le code.
C'est si l'équipe a vraiment compris ce qu'elle devait construire avant de commencer à le construire. Et en ce moment, en 2026, nous avons une industrie qui investit des milliards pour que les développeurs écrivent du code plus vite, tandis que le problème en amont qui cause la majorité des échecs de projets logiciels reste presque complètement ignoré.
Pourquoi les requis sont-elles la conversation que personne ne veut avoir ?
Chaque projet logiciel commence par une conversation. Un intervenant a une vision. Un responsable produit la traduit. Un développeur l'interprète. Et quelque part dans cette chaîne de traduction, des éléments se perdent.
Pas parce que quelqu'un est mauvais dans son travail. Mais parce que traduire une idée d'affaires en quelque chose d'assez précis pour être construit correctement est véritablement l'une des tâches les plus difficiles en logiciel. On n'en parle tout simplement pas. On parle des frameworks. De l'architecture. De la vélocité des sprints. De la stratégie de déploiement.
Personne ne parle de la conversation qui précède tout cela. Celle où quelqu'un essaie d'expliquer ce qu'il voit dans sa tête, et quelqu'un d'autre essaie de transformer cela en plan.
principalement causé par le retravail lié aux requis
Ce chiffre n'est pas théorique. C'est le poids accumulé de chaque fonctionnalité mal construite, chaque sprint qui a déraillé parce que des hypothèses n'ont pas été vérifiées, chaque projet où l'intervenant a regardé le produit final et a dit : « Ce n'est pas ce que je voulais dire. »
Que révèlent 25 ans d'échecs de projets logiciels ?
Au début de ma carrière, je dirigeais une équipe de développement. Nous avons reçu une demande du côté affaires. C'était détaillé. Il y avait des spécifications. Nous les avons suivies à la lettre.
Trois mois plus tard, nous avons livré. Et l'intervenant a regardé l'écran et a dit : « Ce n'est pas ce que je voulais dire. »
Nous n'avions pas mal lu le document. Nous avions construit exactement ce qui était écrit. Le problème était que ce qui était écrit n'était pas ce qui était nécessaire. J'ai depuis vu ce scénario se répéter dans quatre entreprises différentes, dans trois industries différentes, à des échelles allant de 10 personnes à 20 000. Les mots changent. La frustration non.
En 2013, je dirigeais les équipes d'ingénierie logicielle à la Division du commerce de détail de Quebecor. Nathalie, qui gérait les opérations à l'entrepôt de livres, envoyait régulièrement des requis à mon équipe pour ajuster leur système ERP. Chaque fois que nous apportions des améliorations, ce n'était jamais tout à fait correct. Nous ne nous comprenions pas.
Avec la période des Fêtes qui approchait, je lui ai dit que je serais à l'entrepôt à 9 h le lendemain. Elle s'attendait à une autre réunion. Au lieu de cela, j'ai dit : « Je passe la journée ici. Traitez-moi comme un employé. Je veux tout savoir. Tout faire. Je veux comprendre comment vous travaillez. »
J'ai passé de poste en poste. J'ai utilisé leurs scanners. J'ai observé les écrans avec lesquels ils travaillaient. J'ai appris comment l'inventaire était navigé, où se trouvaient les frictions, à quoi ressemblait le flux de travail réel au-delà de ce que tout document pouvait capturer.
À la fin de cette journée, j'ai enfin pu traduire leurs irritants en véritables requis logicielles. Parce que voici l'enjeu : le client comprend ses irritants, mais il ne comprend pas toujours ses besoins.
Cette journée est devenue l'un de mes premiers vrais succès comme directeur, non seulement parce que le volume de commandes des Fêtes a été géré sans accroc pour la première fois depuis des années, mais parce que Nathalie s'est enfin sentie comprise.
Cette expérience m'a enseigné quelque chose qui a façonné tout ce que j'ai fait depuis : la réponse n'est pas dans le document. Elle est dans la salle où le travail se fait vraiment. Et l'écart entre ce que quelqu'un imagine et ce qui est construit, c'est là que les projets vivent ou meurent.
Pourquoi les outils IA de codage n'ont-ils pas amélioré le taux de réussite des projets ?
Maintenant, voici où les choses deviennent intéressantes, et honnêtement, un peu préoccupantes.
Au cours des deux dernières années, les assistants IA de codage ont transformé la façon dont le logiciel est écrit. GitHub Copilot est déployé dans 90 % des entreprises Fortune 100. Une étude contrôlée de GitHub et Microsoft a révélé que les développeurs complétaient les tâches 55 % plus vite avec Copilot. Selon tous les indicateurs conventionnels, nous avons fait un bond en avant véritable. (Pour un regard approfondi sur ce que ces outils livrent réellement, consultez La gueule de bois Copilot.)
Mais les résultats des projets ne se sont pas améliorés. Les taux de retravail n'ont pas diminué. Le rapport CHAOS du Standish Group indique toujours qu'entre 31 % et 75 % des projets logiciels d'entreprise n'atteignent pas pleinement leurs objectifs. La dernière recherche du PMI Pulse of the Profession montre que 12 % des projets échouent complètement et 40 % supplémentaires livrent des résultats « mitigés ».
Réfléchissez à ce que cela signifie. Nous avons augmenté considérablement la vitesse à laquelle les équipes peuvent écrire du code, tandis que ce qui détermine réellement si ce code résout le bon problème n'a pas changé. On accélère sans s'aligner. On construit la mauvaise chose, juste plus vite que jamais.
J'ai commencé à appeler cela la gueule de bois Copilot : le moment où les organisations réalisent que la vélocité sans clarté n'égale pas le progrès. Ça égale du gaspillage accéléré.
Quel est le coût caché des requis flous ?
Voici un chiffre qui devrait empêcher chaque directeur technique de dormir la nuit : la recherche montre constamment que 40 à 50 % de l'effort de développement est consacré au retravail causé par des lacunes dans les requis. Pas des bogues au sens traditionnel. Des fonctionnalités qui ont été construites correctement selon la spécification, mais la spécification elle-même était erronée, incomplète ou mal comprise. (Nous explorons pourquoi ce problème reste invisible pour la direction dans Le problème invisible qui coûte des millions.)
Pour une équipe de 50 développeurs avec un budget annuel de 5 millions de dollars, c'est 1,5 à 2,5 millions de dollars dépensés à construire des choses qui doivent être reconstruites. Chaque année. Et cela ne tient pas compte du coût d'opportunité : les fonctionnalités qui n'ont pas été livrées, les fenêtres de marché qui se sont fermées, l'innovation qui a été étouffée par le retravail.
Il y a une façon encore plus percutante de le formuler. La recherche CHAOS du Standish Group montre constamment que 31 % à 75 % des projets logiciels d'entreprise n'atteignent pas leurs objectifs, le désalignement des requis étant la cause principale. Pas la dette technique. Pas de mauvais développeurs. Le problème en amont de construire la mauvaise chose.
À quoi ressemble l'intelligence des requis d'affaires en pratique ?
Pendant la majeure partie de ma carrière, la réponse à ce problème était l'expérience. Il fallait un analyste d'affaires senior qui avait vu assez de projets déraper pour pouvoir anticiper où les lacunes se trouveraient. Quelqu'un qui savait quelles questions poser avant que quiconque ne commence à écrire du code.
Le problème est que ces personnes sont de plus en plus difficiles à trouver. Le Bureau of Labor Statistics américain projette environ 98 100 postes d'analystes de gestion ouverts par an jusqu'en 2034, avec une croissance de 9 % annuellement, près de trois fois plus rapide que la moyenne des professions. Les analystes seniors coûtent entre 120 000 $ et 180 000 $ par an (Glassdoor) et jonglent typiquement avec plusieurs projets simultanés. On ne peut tout simplement pas résoudre ce problème en embauchant.
Mais que se passerait-il si on pouvait donner à chaque équipe de projet le bénéfice d'une analyse structurée et multi-perspectives dès la toute première session ? Non pas en remplaçant le jugement humain, mais en l'augmentant. En s'assurant que les questions difficiles sont posées avant que la première ligne de code ne soit écrite, pas après la première démo ratée. (Découvrez comment cela fonctionne en pratique dans Comment comprimer la découverte des requis de semaines à heures.)
C'est sur quoi je travaille. L'idée que le rôle le plus impactant de l'IA en logiciel n'est pas d'écrire du code. C'est de structurer la réflexion qui se passe avant que le code ne devrait même être envisagé. Ce que j'appelle la gouvernance pré-code : la couche manquante entre avoir une idée d'affaires et être prêt à la construire.
Pourquoi la distinction entre IA « ébauche d'abord » et IA « décision d'abord » est-elle importante ?
Il y a une différence fondamentale entre la façon dont la plupart des outils IA abordent les requis et ce qui fait réellement avancer les projets.
ChatGPT, Copilot et la plupart des outils IA généralistes sont ce que j'appellerais des outils ébauche d'abord. Vous leur donnez un prompt, ils produisent une ébauche. Ça a l'air soigné. Ça sonne bien. Mais c'est une seule perspective, d'un seul angle, sans analyse structurée derrière. C'est un point de départ qui ressemble à un produit fini, et c'est exactement ce qui le rend dangereux.
Ce qui fonctionne réellement en pratique, c'est la pensée décision d'abord. Au lieu de générer un document, on structure les décisions qui doivent être prises. Quels sont les besoins des utilisateurs ? Quelles sont les contraintes techniques ? Quelles requis de sécurité et de conformité s'appliquent ? Quels compromis sont faits, et tout le monde est-il d'accord ?
La différence n'est pas cosmétique. C'est la différence entre une équipe qui commence à construire avec une spécification d'apparence soignée qui cache des hypothèses non résolues, et une équipe qui commence à construire avec une clarté véritable sur ce qu'elle fait et pourquoi.
Le changement qui change tout
L'industrie investit dans l'accélération. La percée viendra de l'alignement. La vitesse sans clarté n'est que du gaspillage plus rapide. Les équipes qui comprennent cela en premier auront un avantage structurel qui se compose à chaque projet.
La vraie question n'est pas « à quelle vitesse peut-on coder ? » C'est « à quel point est-on clair avant de commencer ? »
Comment la gouvernance pré-code accélère-t-elle la livraison ?
L'une des objections les plus courantes que j'entends est qu'investir davantage dans les requis signifie ralentir. Ajouter du processus. Créer de la bureaucratie.
C'est le contraire qui est vrai. La collecte traditionnelle des requis d'affaires prend 3 à 6 semaines : des réunions séparées avec différentes parties prenantes, des semaines de suivis par courriel, des sessions d'alignement qui créent plus de questions que de réponses. Au moment où les développeurs commencent à construire, beaucoup des décisions originales ont déjà dérivé.
Une approche structurée et guidée par l'IA peut comprimer cela en une seule session de travail. Non pas en coupant les coins, mais en s'assurant que toutes les perspectives critiques (besoins d'affaires, expérience utilisateur, architecture technique, sécurité et conformité) sont abordées simultanément plutôt que séquentiellement.
Le résultat n'est pas une livraison plus lente. C'est une livraison plus rapide de la bonne chose. Et la différence entre ces deux résultats vaut plus que toute accélération de codage ne pourrait jamais offrir.
Pourquoi l'avenir de la livraison logicielle commence-t-il avant le code ?
J'ai passé 25 ans à regarder le même scénario d'échec se répéter dans chaque entreprise où j'ai travaillé, des startups aux entreprises de 20 000 employés. La technologie continue de s'améliorer. Les outils continuent de devenir plus rapides. Et le problème fondamental, l'écart entre ce que quelqu'un imagine et ce qui est construit, reste obstinément, constamment le même.
Je ne pense pas que cela doive rester ainsi.
Les mêmes capacités d'IA qui permettent aux développeurs de coder 5 à 10× plus vite peuvent être orientées vers le problème en amont. Non pas pour remplacer le jugement humain et l'empathie qui font un excellent travail d'analyse des besoins (le type de compréhension qu'on n'obtient qu'en passant une journée dans l'entrepôt de quelqu'un), mais pour le structurer, le mettre à l'échelle et s'assurer que les questions difficiles ne sont pas ignorées quand les échéances sont serrées.
La plus grande percée en logiciel ne viendra pas du fait de coder plus vite. Elle viendra du fait de savoir quoi coder en premier lieu.
Et franchement, il était temps.
Questions fréquentes
