L'année dernière, j'étais assis dans une démo de sprint chez un client à Longueuil. L'équipe de développement avait passé neuf semaines à construire une fonctionnalité d'intégration. Un morceau complexe. Pendant la démo, tout marchait parfaitement, l'exécution technique était solide, l'équipe avait construit exactement ce qu'on lui avait demandé de construire.
Silence. Le client a regardé l'écran, puis a dit : « Ça règle un problème qu'on n'a pas. »
Neuf semaines. L'équipe avait implémenté le requis tel qu'énoncé, à la lettre. Elle avait fait la job qu'on lui avait donnée. Mais le requis énoncé avait jamais été validé contre ce que l'entreprise avait vraiment besoin. L'analyste d'affaires avait assumé. Et cette hypothèse-là a coûté neuf semaines. Perdu.
Cette histoire-là se répète partout en développement logiciel. Pas parce que les équipes sont incompétentes (elles exécutent bien leurs instructions) mais parce que les instructions sont mauvaises. Le problème est en amont.
Pourquoi les outils de codage IA n'ont-ils pas corrigé le taux d'échec ?
Les agents de codage IA sont arrivés avec un pouvoir réel. GitHub Copilot a des millions d'utilisateurs. Les équipes de développement utilisent ces outils pour livrer plus vite. L'accélération est réelle, franchement impressionnante.
Et pourtant ? Les taux d'échec des projets ont pas bougé. Le PMI Pulse of the Profession 2025 rapporte que 47 % des projets n'atteignent toujours pas leurs objectifs initiaux. Les données CHAOS du Standish Group racontent la même histoire : les trois premiers facteurs d'échec sont les requis incomplets, le manque d'implication des utilisateurs, et les requis changeants. Pas du code lent. Pas des mauvais frameworks. Les requis.
Et voici ce qui rend la chose pire. Une étude de Faros AI sur 10 000 développeurs à travers 1 255 équipes a trouvé que 75 % des ingénieurs utilisent maintenant des outils de codage IA, mais les gains de productivité « s'évaporent au niveau de l'entreprise ». Les développeurs individuels mergent plus de pull requests, oui. Mais les résultats organisationnels s'améliorent pas. Le goulot est pas où les outils sont pointés.
Pourquoi ? Parce que ça a jamais été l'écriture de code.
Le développement logiciel, c'est une chaîne. On commence en amont en comprenant quoi construire, puis on descend en aval pour le construire pour vrai. L'échec dans mon histoire de démo de sprint est arrivé en amont. L'exécution du code par l'équipe était impeccable. Ils ont pas échoué à la couche de code. Ils ont échoué à la couche des requis.
Les outils de codage IA ont rendu la partie en aval plus rapide. Ils ont rien changé en amont. Quand 47 % des projets échouent à cause d'une mauvaise compréhension, donner de meilleurs outils de génération de code aux équipes, c'est comme donner de meilleurs mélangeurs à une cuisine quand c'est la recette qui est mauvaise.
Que font réellement les agents de codage IA ?
Avant d'aller plus loin, je veux être direct sur ce que ces outils font bien. Ce sont des exécuteurs extraordinaires.
Donnez à un agent de codage IA une spécification claire, une stack technologique, des contraintes. Il va construire. Il va itérer. Il va déboguer. Il va livrer. La qualité d'exécution est souvent supérieure à ce qu'un humain produirait dans le même délai, et c'est pas de l'hyperbole, c'est le produit qui fonctionne tel que conçu.
L'agent hallucine pas sur votre architecture. Il se tanne pas. Il fait pas d'erreurs de fatigue à 22 h un mardi soir. Il prend vos spécifications et les exécute bien. Point.
C'est l'objectif de conception en entier. Ces outils sont bâtis pour opérer à la couche d'exécution. On leur donne une entrée claire, ils produisent une sortie claire. Brillants pour cette job-là.
La limitation, c'est pas un numéro de version qui va la régler. Pantoute. C'est structurel, coulé dans la philosophie de conception elle-même, et aucune quantité de scaling de paramètres ou de fine-tuning va changer ce que ces outils sont fondamentalement bâtis pour faire : exécuter des spécifications, pas remettre en question si les spécifications sont bonnes.
Quel écart structurel laissent-ils ouvert ?
Imagine la scène. Une partie prenante arrive dans un sprint review et dit : « Je veux un tableau de bord qui suit le taux de désabonnement. » L'agent IA prend la spec et construit le tableau de bord. Beau. Fonctionnel. Exactement ce qui a été demandé. Mais personne (pas l'agent, pas le PM qui a tapé le ticket à 23h30 un mercredi soir sur la Rive-Sud) s'est arrêté pour demander : pourquoi tu veux suivre le désabonnement ? Quelle décision ce tableau de bord va-t-il informer ? Est-ce que le désabonnement est même la bonne métrique pour ce que t'essaies de régler ?
Jamais vu ça arriver. En 25 ans à regarder du logiciel se construire à travers peut-être 200 projets (de Boucherville à Montréal en passant par Québec), j'ai jamais une seule fois vu un outil automatisé repousser un requis pour dire : « Je pense que vous réglez le mauvais problème. » C'est pas une critique. C'est la conception.
Un analyste d'affaires humain fait quelque chose de fondamentalement différent. Il remet en question les hypothèses. Il s'assoit dans une salle (ou sur un call Zoom qui aurait dû être un courriel) et pose des questions inconfortables sur l'intention, le contexte, et l'écart entre ce que les parties prenantes disent vouloir et ce dont elles ont réellement besoin. Travail complexe. Travail lent. Travail irremplaçable.
Disciplines séparées. Les deux portent le poids.
Voici comment l'écart se manifeste. Une équipe reçoit un requis qui a l'air assez clair pour construire, fait qu'on construit. L'agent prend la spec et part avec. Six semaines plus tard (et j'ai vu ce timeline exact chez trois clients différents à Montréal) la partie prenante plisse les yeux devant la démo et dit quelque chose de dévastateur : « C'est pas ce que je voulais dire. » L'équipe a construit la mauvaise chose. Efficacement. À temps. En dessous du budget, même.
Le blâme tombe sur le développeur, ce qui est injuste. Le développeur utilisait un outil conçu pour exécuter des specs, pas les valider. L'écart vivait en amont, dans la conversation qui a jamais eu lieu, dans la question que personne a pensé poser avant que quelqu'un ouvre son IDE.
Le goulot n'a jamais été le code. C'était la conversation qui aurait dû avoir lieu avant que quiconque ouvre son IDE.
Pourquoi la vitesse aggrave-t-elle le problème ?
Générer du code plus vite, c'est positif quand les requis sont bons. Spectaculaire, même. On passe de six semaines à deux semaines à livrer des solutions validées. Pur gain.
Quand les requis sont mauvais ou ambigus, la vitesse devient un risque. Les mauvaises hypothèses atteignent la production en quelques jours maintenant. On découvre l'erreur plus vite, oui. Mais on la découvre après le déploiement, après les tests d'intégration, après que l'équipe soit déjà passée à autre chose.
La structure de coût se renverse. Dans l'ancien monde, un mauvais requis prenait des mois à découvrir. C'était un coût, c'est sûr. Mais la longue ligne de temps donnait plus de chances d'attraper les malentendus tôt. Les requis étaient souvent mauvais, oui. Mais on avait du temps pour les corriger avant de livrer en production.
Maintenant ? Une semaine. L'intégration est construite. L'agent l'a exécutée impeccablement. Le code est propre. La fonctionnalité marche comme spécifié. Et l'entreprise en veut toujours pas.
Et le gain de vitesse perçu ? Possiblement une illusion. Un essai contrôlé randomisé par METR (publié juillet 2025) a testé 16 développeurs open-source expérimentés sur 246 vraies tâches. Avec les outils IA, les développeurs ont pris 19 % plus de temps pour compléter les tâches. Pas plus vite. Plus lent. Mais voici le punch : ces mêmes développeurs croyaient être 24 % plus rapides. L'écart de perception est réel, et il est dangereux, parce que les équipes prennent des décisions de staffing et de timelines basées sur le feeling de vitesse plutôt que des résultats mesurés.
La vitesse amplifie autant les bonnes que les mauvaises entrées. Les bons requis arrivent vite en production. Les mauvais requis arrivent tout aussi vite. L'accélération fait pas la différence.
Qu'est-ce que l'intelligence des requis change ?
C'est là que l'intelligence des requis entre en jeu. C'est pas le contraire de la génération de code. C'est le complément. C'est la discipline en amont qui se passe avant qu'un agent s'assoie pour coder.
L'intelligence des requis pose des questions de clarification. Quel problème cette fonctionnalité règle-t-elle ? Qui vit ce problème-là ? Comment on sait qu'ils le vivent ? Qu'est-ce qu'ils ont essayé avant ? Quelles contraintes comptent ? À quoi ressemblerait le succès ?
Ces questions-là font remonter les contradictions. Elles révèlent les hypothèses. Elles valident si le requis énoncé est réellement le bon requis. On passe de « construis ce que je demande » à « comprends ce dont j'ai vraiment besoin ».
Quand l'intelligence des requis est bien faite, la spécification qui arrive à l'agent IA est solide. Elle a été questionnée. Validée. Elle reflète le vrai besoin de la partie prenante. Fait que quand l'agent l'exécute, on obtient la vitesse et la justesse ensemble.
L'écart se ferme parce que quelqu'un en amont a posé les bonnes questions d'abord.
Qu'est-ce qu'on observe en pratique ?
Un manufacturier est venu nous voir avec une liste de requis pour un système de planification de production. Le premier item : « intégrer le ERP existant pour tirer l'inventaire en temps réel. » L'équipe était prête à construire. Le budget était approuvé. L'échéancier était verrouillé.
On a demandé pourquoi. Quel problème l'intégration d'inventaire en temps réel réglerait-elle ?
La réponse : ils assumaient que leur système de planification avait besoin de données en direct pour être précis.
On a creusé plus profond. La dernière fois que l'inventaire a changé entre leur fenêtre de planification du matin et la production réelle, c'était quand ?
Silence. Puis : « Presque jamais. Peut-être une fois par trimestre. »
Cette seule question leur a sauvé l'effort d'intégration au complet. Ils avaient besoin de snapshots quotidiens, pas de données en temps réel. L'architecture est devenue plus simple. L'échéancier a compressé. Le coût a diminué.
Un agent de codage IA aurait construit l'intégration temps réel parfaitement. C'était un requis énoncé. Le code aurait été propre. Et ça aurait réglé un problème qu'ils n'avaient pas.
L'intelligence des requis l'a attrapé en amont.
Ce que ça signifie pour votre équipe
La tendance est claire. Le codage va devenir plus rapide. Les agents IA vont devenir plus intelligents en exécution. C'est la trajectoire.
Le risque est tout aussi clair. La vitesse n'a de valeur que si on avance dans la bonne direction. Si votre équipe adopte la génération de code plus rapide sans améliorer la compréhension en amont, vous optimisez la mauvaise couche.
Le correctif est pas technique. C'est du processus. Avant qu'un agent génère la moindre ligne de code, quelqu'un doit valider que le requis est bon. Cette personne-là pose les questions que l'agent posera pas. Cette personne-là remet en question la spécification. Cette personne-là s'assure que l'équipe règle le vrai problème.
Investissez dans l'intelligence des requis. Utilisez les agents IA pour exécuter. Le goulot va se déplacer de l'exécution vers la compréhension. Ça, c'est du progrès.
Quelles sont les questions les plus fréquentes sur les agents IA et les requis ?
Non. Les agents de codage IA excellent en exécution, mais ne remettent pas en question les requis. Ils prennent les spécifications et les construisent vite. Les analystes d'affaires comprennent l'intention des parties prenantes, valident les hypothèses et posent la question « pourquoi » avant que quiconque écrive du code. Ce sont des tâches fondamentalement différentes.
L'agent est un exécuteur. L'analyste est un découvreur. Les deux rôles comptent. L'agent remplacera pas l'analyste parce que l'agent est pas conçu pour faire ce que l'analyste fait.
Les outils de codage IA règlent la couche d'exécution. Le taux d'échec est causé par la couche des requis. Selon le PMI Pulse of the Profession 2025, 47 % des projets n'atteignent pas leurs objectifs initiaux, les mauvais requis étant la cause principale.
Générer du code plus vite ne règle pas les problèmes de compréhension en amont. L'agent accélère le travail en aval. Il change rien à ce qui se passe en amont. Quand l'amont est brisé, l'accélération fait juste rendre l'erreur plus rapide.
La génération de code prend une spécification claire et la construit rapidement. L'intelligence des requis pose les bonnes questions avant qu'on écrive la moindre spécification.
L'une est en aval. L'autre est en amont. Les deux comptent, mais le goulot aujourd'hui, c'est l'amont. La plupart des équipes ont la génération de code couverte. Très peu ont l'intelligence des requis couverte.
Quand les requis sont bons, la vitesse est de la pure valeur. Quand les requis sont mauvais ou ambigus, la vitesse amplifie le coût.
Les mauvaises hypothèses atteignent maintenant la production en quelques jours au lieu de mois. On découvre après coup que la fonctionnalité règle un problème que l'entreprise n'a pas. L'erreur est embarquée en production plus vite. Le correctif coûte plus cher. L'équipe est déjà passée au prochain projet avant de réaliser l'échec.
L'intelligence des requis pose des questions de clarification. Pourquoi la partie prenante veut-elle cette fonctionnalité ? Quel problème règle-t-elle ? A-t-elle validé que ce problème existe ? Y a-t-il des contraintes ou des préférences non mentionnées ?
Elle fait remonter les contradictions dans les requis énoncés. Elle remet en question si une fonctionnalité règle le bon problème. Elle valide les hypothèses. C'est la discipline qui transforme la bonne intention en bonnes spécifications. L'agent IA peut pas faire ça parce qu'il est pas conçu pour questionner la spécification. Il est conçu pour l'exécuter.
