Mardi matin, 9 h 12. Bureau de Montréal, sixième étage. Un VP produit me montre fièrement son dashboard : 47 pull requests mergées la semaine dernière. Record. Sauf que trois fonctionnalités sur cinq vont devoir être refaites. Personne s'en est encore rendu compte.
Le code? Pas le problème. Ça ne l'a jamais été.
Vingt-cinq ans que je bâtis du logiciel. Les outils ont changé, les frameworks aussi, les pipelines de déploiement sont passés de jours à secondes, et pourtant la question qui compte vraiment reste exactement la même qu'en 2003 quand j'ai commencé à diriger des équipes de dev sur la Rive-Sud : est-ce que l'équipe a compris ce qu'elle devait construire avant de commencer? En 2026, on investit des milliards pour accélérer l'écriture du code. Le problème en amont, celui qui cause la majorité des échecs? On l'ignore. Presque complètement.
Pourquoi les requis sont-elles la conversation que personne ne veut avoir ?
On connaît tous le scénario. Tous. Un VP a une vision, il l'explique (plus ou moins clairement) à un responsable produit, le responsable produit la traduit pour les devs, et quelque part dans cette chaîne de téléphone arabe, des bouts importants disparaissent. Pas parce que le monde est incompétent. C'est juste que traduire une idée d'affaires en quelque chose d'assez précis pour être codé correctement, c'est une des tâches les plus ingrates en informatique. Ingrate et invisible.
Et pourtant? Silence. On parle de React versus Vue, d'architecture microservices, de vélocité de sprint, de stratégie de déploiement. Mais la conversation qui précède tout ça, celle où quelqu'un essaie d'expliquer ce qu'il voit dans sa tête et où quelqu'un d'autre doit transformer ça en plan exécutable? Tabou. On dirait que le sujet rend tout le monde mal à l'aise.
principalement causé par le retravail lié aux requis
2,41 T$. Pas un chiffre théorique. C'est le poids accumulé de chaque fonctionnalité bâtie tout croche, chaque sprint déraillé par des hypothèses que personne a vérifiées, chaque fois qu'un intervenant a regardé l'écran à la démo et a lâché : « Ce n'est pas ce que je voulais dire. » Dix mots. On a tous vécu ça au moins une fois. La plupart d'entre nous, une dizaine de fois, peut-être plus.
Que révèlent 25 ans d'échecs de projets logiciels ?
Genre 2003, si je me souviens bien. Je dirigeais une équipe de dev à Montréal. On a reçu une demande du côté affaires, détaillée, avec des specs de quarante-quelques pages. On les a suivies à la lettre.
Trois mois plus tard, livraison. L'intervenant regarde l'écran : « Ce n'est pas ce que je voulais dire. »
On n'avait pas mal lu le document. On avait construit exactement ce qui était écrit. Exactement. Sauf que ce qui était écrit, c'était pas ce qui était nécessaire. Depuis? Même scénario, quatre entreprises différentes, trois industries, des échelles allant de 10 personnes à 20 000. Les titres de poste changent. Les technologies aussi. La frustration? Identique. Chaque maudite fois.
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 journée-là m'a appris quelque chose que j'ai traîné avec moi pendant vingt ans. La réponse est jamais dans le document. Jamais. Elle est sur le plancher, là où le travail se fait pour vrai, avec le bruit des scanners pis l'odeur du carton. L'écart entre ce que quelqu'un imagine dans sa tête et ce qui finit par être construit? C'est exactement là que les projets vivent ou meurent. Pas dans le code. Dans la compréhension.
Pourquoi les outils IA de codage n'ont-ils pas amélioré le taux de réussite des projets ?
Bon. C'est ici que ça devient intéressant. Et honnêtement? Un peu dérangeant.
En à peine deux ans, les assistants IA de codage ont complètement changé la game. Copilot, rendu dans 90 % des Fortune 100. Une étude contrôlée de GitHub et Microsoft montre 55 % plus vite sur les tâches avec Copilot, et c'est un bond réel, pas juste du marketing. (Pour creuser ce que ces outils livrent vraiment au quotidien, allez lire La gueule de bois Copilot.)
Sauf que. Les résultats des projets, eux? Rien. Le retravail n'a pas diminué d'un iota. Le rapport CHAOS du Standish Group indique toujours 31 % à 75 % de projets d'entreprise qui n'atteignent pas leurs objectifs, et selon le PMI Pulse of the Profession : 12 % d'échecs complets, 40 % de résultats qu'on qualifie poliment de « mitigés ».
Arrêtons-nous là-dessus. Deux secondes. On a augmenté la vitesse d'écriture du code. Ce qui détermine si ce code résout le bon problème? Zéro changement. On accélère sans s'aligner. On construit la mauvaise affaire, juste plus vite qu'avant.
J'ai commencé à appeler ça la gueule de bois Copilot. Le moment où les organisations réalisent que la vélocité sans clarté, ça n'égale pas le progrès. Ça égale du gaspillage accéléré. Pis ça fait mal quand tu reçois la facture.
Quel est le coût caché des requis flous ?
Selon la recherche d'IBM, 40 à 50 % de l'effort de développement part en retravail causé par des lacunes dans les requis. Pas des bugs classiques. Des fonctionnalités construites correctement selon la spec, sauf que la spec elle-même était erronée, incomplète ou mal comprise. C'est ça le piège, il est vicieux parce qu'il a l'air de fonctionner jusqu'au moment où ça plante. (On explore pourquoi ce problème reste carrément invisible pour la direction dans Le problème invisible qui coûte des millions.)
En chiffres concrets? Une équipe de 50 développeurs, budget annuel de 5 M$. Entre 1,5 et 2,5 M$ dépensés à reconstruire ce qui aurait dû être bien fait la première fois. Chaque année. Et ça, c'est sans compter le coût d'opportunité que personne ne mesure : les fonctionnalités jamais livrées, les fenêtres de marché qui se ferment pendant qu'on refait la même affaire, l'innovation étouffée par le rework. Invisible.
Le pattern se répète. Projet après projet. Le Standish Group rapporte 31 % à 75 % des projets logiciels d'entreprise qui n'atteignent pas leurs objectifs. La cause principale? Le désalignement des requis. Pas la dette technique. Pas des devs incompétents. Le problème est en amont, bien avant le premier commit : on construit la mauvaise chose.
À quoi ressemble l'intelligence des requis d'affaires en pratique ?
Pendant le gros de ma carrière, la réponse tenait en un mot : l'expérience. Un analyste d'affaires senior qui avait vu assez de projets planter pour sentir instinctivement où les lacunes allaient apparaître. Le genre de personne qui posait la bonne question gênante dans le meeting du lundi matin, avant que quiconque touche au clavier. Rare. Précieux.
Sauf que ces personnes-là? De moins en moins. Le Bureau of Labor Statistics américain projette 98 100 postes d'analystes ouverts par an jusqu'en 2034, une croissance de 9 % (quasiment trois fois la moyenne nationale). Côté salaire, un analyste senior coûte entre 120 000 $ et 180 000 $ par an selon Glassdoor, et chacun jongle avec trois, quatre, cinq projets en même temps. On ne réglera pas ça juste en embauchant plus de monde. Le pipeline est vide.
Mais imaginez autre chose. Chaque équipe de projet reçoit le bénéfice d'une analyse structurée, multi-perspectives, dès la toute première session de travail. Pas pour remplacer le jugement humain (on y reviendra, c'est important). Pour l'augmenter. Pour s'assurer que les questions tough sont posées avant la première ligne de code, pas après la première démo ratée devant le client un jeudi après-midi. (Découvrez comment ça fonctionne concrètement dans Comment comprimer la découverte des requis de semaines à heures.)
C'est exactement là-dessus que je travaille avec Specira. L'utilisation la plus impactante de l'IA en logiciel? Pas l'écriture de code. La structuration de la réflexion qui devrait précéder toute ligne de code. Ce que j'appelle la gouvernance pré-code : cette couche manquante entre avoir une idée d'affaires dans la tête du VP et être réellement prêt à la construire.
Pourquoi la distinction entre IA « ébauche d'abord » et IA « décision d'abord » est-elle importante ?
Voici un truc que j'ai remarqué en travaillant avec une trentaine d'équipes au fil des ans. La plupart des outils IA abordent les requis d'une façon. Les projets qui réussissent? Ils fonctionnent d'une toute autre façon. La distinction mérite deux minutes de votre temps.
ChatGPT, Copilot, les outils généralistes : des machines à ébauche. On donne un prompt, ça sort un document, ça a l'air propre, ça sonne professionnel. Mais c'est une seule perspective, un seul angle, zéro analyse structurée derrière. Le danger? On se retrouve avec un point de départ qui ressemble à un produit fini. L'équipe le traite comme tel. Personne challenge les hypothèses parce que le document est beau.
L'approche qui fonctionne dans la vraie vie? Décision d'abord. On génère pas un document. On structure les décisions à prendre. C'est quoi les besoins réels des utilisateurs? Les contraintes techniques qu'on connaît déjà? Les requis de sécurité? Et les compromis, tsé, est-ce que tout le monde autour de la table les accepte vraiment, ou on fait juste semblant pour pas étirer le meeting?
D'un côté, une équipe qui démarre avec une spec d'apparence soignée mais truffée d'hypothèses non résolues. De l'autre? Clarté véritable sur ce qu'elle construit et pourquoi. J'ai vu les deux scénarios assez souvent pour vous dire que la différence entre les deux détermine le succès du projet bien avant le premier git init.
Le changement qui change tout
Toute l'industrie investit dans l'accélération. Mais la percée viendra de l'alignement. Coder plus vite sans clarté, c'est gaspiller plus vite. Les équipes qui saisissent cette distinction en premier accumuleront 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'objection? Je la connais par coeur. « Investir dans les requis, c'est ralentir. Processus. Bureaucratie. » Je l'ai entendue chez Quebecor, chez TEC, chez Optimal Solutions. Toujours les mêmes mots. Toujours.
La réalité, c'est exactement l'inverse. Pensez à la collecte traditionnelle des requis telle qu'on la vit dans la plupart des boîtes : 3 à 6 semaines de réunions séparées, des suivis par courriel qui s'éternisent (avec 14 personnes en CC dont la moitié ne répondra jamais), des sessions d'alignement qui génèrent plus de questions que de réponses. Quand les devs commencent enfin à coder? La moitié des décisions originales a déjà dérivé. Le PO a changé d'idée sur deux fonctionnalités. Le VP a ajouté un requis par Slack un jeudi soir à 22h.
Une approche structurée, guidée par l'IA, comprime tout ça en une seule session intensive. Pas en coupant les coins (j'insiste). En abordant toutes les perspectives critiques simultanément plutôt que séquentiellement : affaires, expérience utilisateur, architecture technique, sécurité, conformité. Tout. Sur la table. En même temps.
On livre pas plus lentement. On livre la bonne chose, plus vite. Cette différence-là? Elle vaut infiniment plus que n'importe quelle accélération de codage. Demandez à n'importe quel dev qui a passé trois sprints à refaire une fonctionnalité sur la rue Saint-Laurent : il vous le confirmera.
Pourquoi l'avenir de la livraison logicielle commence-t-il avant le code ?
Vingt-cinq ans. Le même film. Des startups de cinq personnes dans un coworking sur Saint-Laurent aux organisations de 20 000 employés avec des bureaux dans quatre pays, j'ai vu ce scénario d'échec se rejouer partout où je suis passé. La techno s'améliore, les outils accélèrent, et le problème fondamental reste obstinément, ridiculement identique : l'écart entre ce que quelqu'un imagine et ce qui finit par être construit.
On est en 2026. Ça devrait plus être une fatalité.
Les capacités d'IA qui permettent aux développeurs de coder 5 à 10x plus vite? On peut les pointer vers le problème en amont. Pas pour remplacer le jugement humain ni l'empathie qui font un bon travail d'analyse des besoins (le genre de compréhension profonde qu'on développe en passant une journée complète dans l'entrepôt du client avec Nathalie, comme je l'ai fait chez Quebecor en 2013). Plutôt pour structurer cette expertise, la mettre à l'échelle, garantir que les questions difficiles ne tombent pas entre les craques quand les échéances serrent et que tout le monde est stressé.
La plus grande percée en logiciel ne viendra pas du fait de coder plus vite. Elle va venir de savoir quoi coder. Ça semble évident dit comme ça, mais regardez autour de vous : presque personne ne travaille sur ce problème-là.
Franchement? Il était temps.
Questions fréquentes
