La pull request avait l'air parfaite. Deux approbations, tous les checks au vert, un diff tellement propre que le reviewer a à peine ralenti avant de merger. Un assistant IA avait écrit tout le morceau en une quarantaine de secondes, ce mardi après-midi, une petite fonction pour appliquer un rabais client, et elle faisait exactement ce que le ticket demandait. Ça a shippé. Trois semaines plus tard, une escalade au support tombe sur une équipe qui avait rien à voir : une poignée de clients s'étaient fait charger le mauvais montant, parce que le rabais était censé se cumuler avec un remboursement régional que le ticket, donc le prompt, donc le modèle, a jamais mentionné une seule fois. Le code était pas buggé. Il était presque correct.
C'est toute l'affaire, cette dernière phrase-là, et 49 000 développeurs viennent de mettre un chiffre dessus. Ça fait 25 ans que je livre du logiciel, bien avant qu'un assistant puisse compléter une fonction tout seul, pis j'ai jamais vu un mode d'échec se répandre aussi vite. Le réflexe, c'est de blâmer le modèle. D'en attendre un plus intelligent. Je pense que ce réflexe-là vise à côté. Et les données, lues comme du monde, commencent à être d'accord.
Pourquoi le code IA est-il si souvent presque correct, mais pas tout à fait?
Parce que presque correct, c'est exactement à quoi ressemble une exigence sous-spécifiée bâtie fidèlement. Le modèle a fait ce que le prompt disait. Le prompt, lui, oubliait le bout qui vivait dans la tête de quelqu'un. Dans son sondage 2025 auprès des développeurs, Stack Overflow a demandé à environ 49 000 développeurs de 177 pays comment ils travaillent pour vrai aujourd'hui, et le constat est direct : 84 % utilisent ou prévoient utiliser des outils IA, en hausse par rapport à 76 % l'année d'avant. L'adoption, c'est réglé. Ce qui l'est pas, c'est la confiance, et la plus grosse frustration, nommée par 66 % des développeurs, c'est du code qui est, dans les mots du sondage, presque correct, mais pas tout à fait. Relis ça. Pas faux. Presque.
Voici pourquoi cette phrase précise fait mal. Le code faux plante fort : une stack trace, un test rouge, un crash que tu peux pas manquer et pas merger. Le code presque correct passe. Il compile, le happy path roule propre, la démo brille, pis la seule condition que personne a spécifiée attend tranquille dans le trou jusqu'à ce que la prod vienne la chercher à ta place. Un modèle n'hallucine pas une règle de rabais qu'on lui a jamais donnée. Il remplit le silence avec la chose la plus probable, il livre sa devinette avec une confiance totale, pis il passe au prochain ticket. Le trou a jamais été dans les poids du modèle. Il était dans la demande, dans l'espace entre ce que le ticket disait et ce que le système devait vraiment faire, la même gueule de bois d'adoption-sans-confiance qu'on a décortiquée dans la gueule de bois Copilot.
Est-ce un problème de modèle ou d'exigences?
Surtout un problème d'exigences. Laisse-moi donner au contre-argument sa phrase juste : la qualité du modèle compte pour vrai, un modèle plus fort va mal lire moins d'instructions et inventer moins de détails, pis ce bout-là du trou rétrécit à chaque version. Maintenant le bout qui rétrécit pas. Le résidu qui survit à chaque mise à jour de modèle, c'est le morceau que personne a écrit, et aucun nombre de paramètres découvre une règle qui existe juste dans la mémoire d'une analyste partie à la retraite en 2021. Un modèle plus intelligent lit mieux ton prompt. Il peut pas lire dans ta tête. Pis encore moins dans la tête de quelqu'un qui a quitté la boîte avant même que le ticket soit ouvert.
La première fois que j'ai vu des équipes frapper ce mur-là, je pensais qu'un meilleur prompt réglerait ça. Des instructions plus claires, deux-trois exemples, un system prompt plus serré. Ça a aidé, honnêtement, un peu. Après, j'ai remarqué ce qui était vraiment en dessous : les prompts qui produisaient du code presque correct étaient pas mal écrits. Ils étaient écrits fidèlement contre une compréhension incomplète de ce que le logiciel était supposé faire. Tu peux pas prompter ton chemin hors d'une exigence que tu sais même pas qui existe. C'est pas un problème de langage à régler avec de meilleurs mots. C'est un problème de découverte, pis il est vieux, bien plus vieux que l'IA, le même trou qui coule des projets logiciels depuis longtemps avant qu'un modèle puisse taper une ligne.
C'est là que la vague actuelle d'outils spec-driven a à moitié raison. Écrire une spec avant de générer du code, c'est vraiment mieux que de vibe-coder un prompt en croisant les doigts. Mais un outil spec-driven hérite du trou exact qu'il devait fermer, parce qu'il met en forme la décision, il la découvre pas. Si la règle manquante s'est jamais rendue dans la spec, l'outil rend ta compréhension incomplète en beau markdown structuré et confiant, pis le donne au modèle, qui bâtit ensuite la mauvaise affaire avec encore plus de conviction qu'avant. On est allés creux là-dessus dans pourquoi les specs sont le problème, pis encore dans pourquoi le vibe coding avec specs est toujours brisé. La version courte tient sur un post-it. Une spec que tu peux écrire, c'est une spec que tu savais déjà. L'exigence qui te fait mal, c'est celle que tu savais pas.
Qu'est-ce que presque correct coûte une fois shippé?
Plus que le bug qu'il cache, et le même sondage a mis un chiffre sur la taxe. Après presque correct lui-même, la deuxième plus grosse frustration nommée par les développeurs, c'est que déboguer du code généré par IA prend plus de temps, cité par 45 %. Assis-toi avec ce que ça fait aux économies de temps promises. Le modèle écrit la fonction en quarante secondes, pis il te redonne le temps plus tard, tranquillement, au pire moment, à l'endroit le moins prévisible, déguisé en code qui a déjà passé. T'as pas sauvé une heure. Tu l'as empruntée, avec intérêt, payable en prod.
Et le coût, c'est pas toujours une erreur d'arrondi sur une facture. Des fois, c'est un précédent juridique. L'échec presque correct le plus instructif des deux dernières années s'est pas passé dans une revue de code. Il s'est passé dans une cour, parce qu'un système IA a fait exactement ce pour quoi il était bâti tout en manquant la seule règle qui vivait ailleurs. Et l'entreprise, ça se trouve, était canadienne.
En novembre 2022, Jake Moffatt visite le site d'Air Canada quelques heures après un décès dans sa famille, à la recherche d'un tarif de deuil. Il demande au chatbot de soutien. Le bot répond avec aisance, avec confiance, avec serviabilité : oui, réserve maintenant, pis demande le tarif de deuil réduit rétroactivement dans les 90 jours. Raisonnable. Bien tourné. Presque correct. Le seul hic, c'est que la vraie politique de deuil d'Air Canada, sur une page que le bot pointait lui-même, disait le contraire : le rabais peut pas être réclamé après le voyage. Le bot avait fidèlement généré une réponse plausible pour remplir un trou dans ce qu'il savait. Personne avait encodé la vraie contrainte dans ce qu'il pouvait dire.
Moffatt réserve, se fie à la réponse, pis se fait refuser le remboursement. Il amène ça au Tribunal civil de résolution de la Colombie-Britannique. En février 2024, dans Moffatt c. Air Canada, le tribunal rejette l'argument de la compagnie que le chatbot serait une entité séparée responsable de ses propres mots, conclut à une déclaration inexacte faite par négligence, pis ordonne à Air Canada de payer des dommages. Une petite somme, 650,88 $. Un très gros point. Le résultat, c'était pas un bug dans le modèle. C'était une exigence que personne avait écrite dedans, pis l'échec était invisible jusqu'à ce qu'il le soit plus. La leçon se transpose direct au code : une réponse presque correcte, livrée avec confiance, arrive avec une vraie facture, plus tard, adressée à quelqu'un d'autre.
Source : Moffatt c. Air Canada, 2024 BCCRT 149.
Qu'est-ce qui ferme vraiment le trou?
Pas un modèle plus intelligent. Une meilleure question, posée plus tôt. Si presque correct est l'ombre d'une exigence manquante, alors le fix, c'est pas plus de génération, c'est plus de découverte, faite avant que le modèle roule. Fais remonter les hypothèses, les cas limites, la règle régionale, les deux équipes qui pensent chacune que l'autre possède la logique de rabais. Mets-les sur la page pendant que ça coûte encore une conversation. Après, génère contre une demande complète, pis regarde combien de presque correct arrête juste de se produire, parce que le silence que le modèle remplissait avec une devinette a maintenant une vraie réponse dedans.
Cette pratique-là a un nom, pis c'est pas analyse d'écarts ni meilleur prompt. Rouler les recherches de ce qu'une exigence a laissé de côté, avant le build, avec une machine qui fait l'échelle et un humain qui confirme l'intention, c'est la forme concrète de l'intelligence des exigences : traiter l'intention derrière un système comme quelque chose à récupérer activement et à rendre testable, pas un sous-produit chanceux d'un prompt bien tourné. Fais-le, pis l'économie se retourne. L'exigence que tu fais remonter dans une conversation un mardi coûte une conversation un mardi. La même exigence, découverte comme un bug presque correct au mois cinq, coûte un incident en prod, un marathon de débogage, pis des fois un tribunal. Même règle. Facture pas mal différente. Le modèle allait jamais t'envoyer la moins chère.
Presque correct, c'est un signal d'exigences, pas un verdict sur le modèle.
84 % des développeurs utilisent l'IA, et 66 % nomment presque correct, mais pas tout à fait comme pire frustration. C'est pas un rapport de bug sur le modèle. C'est un rapport d'état sur la demande. Le code presque correct, c'est un build complet et confiant d'une exigence incomplète : il passe tous les checks de la mauvaise façon et apparaît juste en prod, là où 45 % des développeurs disent que le débogage mange le temps que la génération devait sauver.
Un modèle plus intelligent rétrécit la moitié capacité du trou et peut pas toucher l'autre moitié, la règle qui a jamais été écrite. Les outils spec-driven mettent en forme la décision sans la découvrir. Ce qui bouge vraiment le chiffre, c'est la découverte avant la génération : fais remonter les hypothèses silencieuses et les cas limites pendant que ça coûte encore une conversation, pis laisse le modèle bâtir fidèlement une exigence enfin complète.
Quelles sont les questions les plus fréquentes sur la qualité du code IA?
