L'enquête Stack Overflow 2025 (49 000+ devs) révèle que la plus grande frustration avec l'IA (66 %) n'est pas qu'elle se trompe, mais qu'elle livre des solutions « presque correctes » : elles semblent terminées et échouent sur le détail, et les corriger coûte plus cher que de repartir de zéro. Le métier n'est plus de générer, c'est de boucler ce dernier tronçon avec une spécification claire et une vérification.
Il existe un type d'erreur qui agace plus que de se tromper : avoir presque juste. Quand une chose est clairement fausse, on la jette et on repart de zéro, sans deuil. Mais quand elle est presque bonne — 95 % impeccable, 5 % cassé dans un coin qu'on ne voit pas — on reste coincé, parce qu'on a l'impression d'être à un réglage de la fin alors qu'en réalité on est à une réécriture de distance. L'enquête officielle Stack Overflow 2025, avec plus de 49 000 développeurs ayant répondu, a mis un chiffre sur cet agacement : la frustration numéro un avec l'IA n'est pas qu'elle mente, ni qu'elle hallucine, ni qu'elle soit lente. C'est qu'elle livre des « solutions qui sont presque bonnes, mais pas tout à fait ». 66 % l'ont pointée du doigt. C'est la plainte la plus votée du métier, et elle renferme une leçon utile à quiconque demande quelque chose à un modèle, qu'il sache programmer ou non.
Le « presque » est l'erreur la plus coûteuse qui soit
L'intuition nous dit qu'une grosse erreur coûte plus cher qu'une petite. Avec l'IA, c'est l'inverse. Une erreur évidente est bon marché : on la repère en une seconde et on l'écarte sans réfléchir. L'erreur « presque correcte » est hors de prix, parce qu'elle doit d'abord te convaincre qu'elle est bonne — et elle y parvient, car les 95 % qui fonctionnent baissent tes défenses — pour ne révéler qu'ensuite, en production, sous les yeux du client, les 5 % qui la brisent. Tu paies deux fois : tu paies pour avoir fait confiance et tu paies pour l'avoir découvert trop tard. La deuxième frustration de l'enquête le confirme froidement : 45,2 % disent que déboguer du code généré par l'IA leur prend plus de temps que de l'écrire. Traduction : le « presque » ne t'a pas fait gagner de travail, il l'a déplacé et lui a ajouté des intérêts.
Le syndrome du dernier kilomètre
Il existe une analogie qui le capture mieux que n'importe quel graphique. Imagine un livreur qui apporte ton colis 99 % du chemin et le laisse sur le trottoir d'en face, dans le mauvais porche, à une rue de chez toi. Techniquement, il a fait presque tout le trajet. Concrètement, le colis n'est pas arrivé, et c'est maintenant à toi de sortir le chercher sous la pluie. Ce dernier kilomètre — le tronçon entre « presque livré » et « livré » — est là où vit la valeur réelle, et c'est exactement le tronçon que l'IA ne boucle pas toute seule. Elle génère 90 % en quelques secondes et te laisse les 10 % qui exigent de comprendre le problème entier. Le hic, c'est que ces 10 % finaux sont souvent plus difficiles que les 90 % initiaux, parce que ce sont eux qui réclament du contexte, du jugement et de savoir ce qui est vraiment « correct » dans ton cas précis.
Voilà pourquoi la confiance a chuté, et à juste titre
La même enquête a relevé une donnée qui, à première vue, semble contradictoire : 84 % des développeurs utilisent ou prévoient d'utiliser l'IA, mais dans le même temps le sentiment positif est passé de plus de 70 % en 2023 et 2024 à environ 60 % en 2025. Plus de gens l'utilisent et elle plaît de moins en moins. Ce n'est pas une contradiction : c'est de la maturité. La nouveauté s'est usée et il reste l'expérience réelle, et l'expérience réelle, c'est que l'IA est un outil puissant qui exige une supervision constante. Le détail le plus révélateur : il y a aujourd'hui plus de développeurs qui se méfient activement de l'exactitude de l'IA (46 %) que de développeurs qui lui font confiance (33 %), et à peine 3 % lui font grandement confiance. Ce n'est pas du rejet. C'est le respect sain qu'on porte à une tronçonneuse : on l'utilise tous les jours, et c'est précisément pour ça qu'on ne lui lâche jamais les deux mains.
La vérité qui dérange : le « presque » est la faute du processus, pas du modèle
Il est tentant de rejeter la faute sur le modèle — qu'il hallucine, qu'il ne raisonne pas — mais cela esquive la vraie leçon. Un modèle produit ce que sa spécification lui permet de vérifier. Si tu lui demandes « fais-moi un formulaire de paiement » sans dire ce qui est correct — quelles devises, quelles erreurs, que se passe-t-il si l'utilisateur double-clique, ce qui est enregistré — le modèle comblera ces trous avec des suppositions plausibles, et « plausible » est justement la définition de « presque correct ». Le presque-bon ne naît pas de l'ignorance du modèle ; il naît de l'ambiguïté de la demande et de l'absence d'un test qui dise oui ou non. Là où il n'y a ni spécification claire ni vérification, le modèle livrera toujours quelque chose qui semble terminé. La question « est-ce que c'est bon ? », ce n'est pas celui qui construit qui y répond. C'est celui qui vérifie — et ce doivent être deux moments distincts.
Le métier n'est plus d'écrire, c'est de boucler
Si les 90 % sont générés par n'importe qui en quelques secondes, l'avantage professionnel a déménagé vers le dernier kilomètre : savoir spécifier ce qui est correct avant de demander, et savoir vérifier que c'est respecté après avoir reçu. Voilà le cadre mental à réutiliser et à partager : traite chaque sortie d'IA comme un brouillon convaincant, pas comme un livrable ; définis par écrit le critère de « terminé » avant de générer ; et sépare construire et auditer en deux étapes délibérées, parce que l'esprit qui construit est amoureux de son œuvre et ne voit pas les 5 % cassés — ceux-là, seul un esprit qui arrive frais pour chasser les défauts les débusque. Le presque-bon ne se boucle pas avec plus de confiance. Il se boucle avec plus de spécification et plus de test. C'est moins glamour que « l'IA fait tout », mais c'est la seule chose qui transforme un brouillon impressionnant en quelque chose qui tient avec un vrai client de l'autre côté.
Comment nous le voyons
Chez NeuralOS, nous partons du principe que l'IA, seule, produit du presque-bon — nous ne le traitons pas comme un défaut qui sera un jour réglé, mais comme la nature même du terrain. C'est pourquoi nous pensons le produit non pas autour de générer plus vite, mais autour de boucler le dernier kilomètre : que la spécification soit la source unique de vérité, de sorte que « ce qui est correct » soit écrit avant que quoi que ce soit ne s'exécute ; que construire et auditer vivent dans des étapes séparées à dessein, parce qu'un même esprit ne fait pas bien les deux ; et que le critère de « terminé » ne soit pas dicté par l'enthousiasme du « on dirait que ça marche », mais par une vérification explicite qui dise oui ou non. Voilà tout le point de vue : nous ne vendons pas le fantasme que l'IA a juste toute seule. Nous défendons la discipline qui transforme son « presque » en un « oui » vérifiable — le dernier kilomètre, fait de manière à tenir quand ça compte vraiment. Parce qu'au fond le mérite n'a jamais été de générer les 90 %. Il a toujours été de boucler les 10 % qui décident si le colis est arrivé.