La fonction marchait. C'était ça, le problème. Une équipe à qui j'ai parlé en mai avait livré un module de tarification le trimestre d'avant, bâti vite avec un agent de codage, tests verts, déploiement propre, personne s'était plaint. Puis un nouveau développeur a ouvert le fichier pour ajouter un palier de rabais, et il est resté là un bout de temps, à scroller, parce que la chose calculait les bons prix par un chemin que personne n'avait vraiment conçu et qu'aucun commentaire n'expliquait. Ça passait. Personne pouvait dire pourquoi. Cet écart, entre du code qui roule et du code que quelqu'un comprend, c'est toute l'histoire de 2026.
Fait que voici mon opinion impopulaire, dite franchement. On n'a pas tué le vibe coding. On a rebrandé l'ambiguïté et on a appelé ça une méthodologie. L'industrie a passé la dernière année à déclarer le vibe coding mort et à sacrer le développement piloté par specs comme le remplaçant sérieux, et la deuxième moitié de cette phrase, c'est une vraie bonne nouvelle. La première moitié, c'est une histoire qu'on se raconte. Passer d'un prompt lâche à une spec structurée change où vit l'ambiguïté. Ça ne fait à peu près rien sur le fait qu'elle existe.
Les chiffres derrière le réveil de 2026 ne sont pas subtils. Une analyse de CodeRabbit publiée le 17 décembre 2025 a comparé des pull requests coécrites par IA à des PR humaines, et le lot IA portait en moyenne 10,83 problèmes par PR contre 6,45, environ 1,7 fois plus, avec des erreurs de logique qui ressortent à peu près 75 % plus souvent (CodeRabbit, décembre 2025). Une étude académique à grande échelle a suivi 304 362 commits écrits par IA dans 6 275 dépôts GitHub et a trouvé que 24,2 % des problèmes que ces commits ont introduits sont encore dans la dernière version du code (Liu et coll., « Debt Behind the AI Boom », 2026). Et l'analyse sécurité Spring 2026 de Veracode a trouvé que les modèles choisissent la manière non sécuritaire d'implémenter une tâche environ 45 % du temps quand on leur laisse le choix (Veracode, Spring 2026). Trois lentilles différentes. Une seule image.
Pourquoi 2026 est-elle l'année de la dette technique?
Parce que la facture est arrivée d'un coup. Pendant deux ans, l'histoire dominante sur le codage IA, c'était la vélocité : plus de lignes, plus de pull requests, plus de livré par sprint. C'était vrai. C'était aussi incomplet, de la même façon que « je suis arrivé en un temps record » est vrai jusqu'au moment où tu mentionnes le ticket de vitesse pis la mauvaise sortie d'autoroute. L'output a monté. Ce que l'output a coûté en nettoyage commence juste à paraître dans les livres, et ça paraît partout en même temps.
Regarde le chiffre de survie encore, parce que c'est celui qui devrait empêcher les directeurs d'ingénierie de dormir. Dans cette étude de 304 362 commits écrits par IA, les chercheurs n'ont pas juste compté les bogues au moment de l'écriture. Ils les ont suivis. Près du quart des problèmes que ces commits ont introduits étaient encore vivants dans la dernière révision, ce qui veut dire qu'ils n'ont pas été attrapés en revue, pas attrapés aux tests, pas attrapés par la prochaine personne qui a touché le fichier. Ils sont juste restés. Tranquillement. À composer la chose que tout le monde appelle maintenant la dette technique.
Et l'adoption est totale, c'est pour ça que ce n'est pas un problème de niche. JetBrains a sondé 24 534 développeurs pour son rapport Developer Ecosystem 2025 et a trouvé que 85 % d'entre eux utilisent régulièrement des outils d'IA (JetBrains via InfoWorld, 2025). Quatre-vingt-cinq pour cent. Donc peu importe ce que l'IA fait à la qualité du code, en bien ou en mal, elle le fait maintenant au code de presque tout le monde, et c'est exactement pour ça qu'un problème de qualité qui était autrefois une erreur d'arrondi est devenu le thème de l'année.
Le développement piloté par specs a-t-il réglé le vibe coding?
En partie, et je veux lui donner tout le crédit avant d'en reprendre un peu. Le développement piloté par specs est une vraie avancée. En ancrant un agent IA sur une spécification structurée et durable plutôt que sur un prompt jetable, des outils comme GitHub Spec Kit et AWS Kiro règlent vraiment deux des pires défauts du vibe coding : la dérive d'intention, où l'agent s'égare sur une longue session, et la perte de contexte, où il oublie ce que tu lui as dit il y a vingt minutes. C'étaient de vraies plaies. Le piloté par specs les referme. Je suis pas poli là, je le pense.
Voici la partie que la fête saute. Une spec, c'est un registre de décisions que quelqu'un a déjà prises. C'est sa nature même. Elle encode ce que tu savais quand tu l'as écrite, avec plus de rigueur et de structure qu'un prompt en a jamais eu, puis elle remet cet encodage à une machine qui va l'exécuter fidèlement, à grande vitesse. Exécuter fidèlement une mauvaise décision, ce n'est pas une correction. C'est la même erreur, maintenant formatée, versionnée et livrée avec confiance. Plus la spec est claire, plus elle livre efficacement ce qui a été décidé, y compris les bouts décidés tout croche ou jamais vraiment décidés.
J'ai déjà changé d'idée là-dessus, en fait, alors je vais pas prétendre que la ligne m'a toujours paru évidente. Au début, je pensais qu'un bon gabarit de spec forcerait une meilleure réflexion, et ça pousse les gens, un peu. Mais un gabarit peut juste demander les affaires que son auteur a déjà imaginées. Il va consciencieusement te demander la gestion d'erreurs pis les critères d'acceptation. Il va jamais te demander de penser à la règle de conformité dont tu n'as jamais entendu parler, ou à l'équipe en aval que tu ne savais pas qui consommait tes données. La structure organise ce que tu sais. Elle est muette sur ce que tu ne sais pas.
Le vibe coding mettait l'ambiguïté dans l'éditeur, où au moins un humain devait la regarder. Le développement piloté par specs a déplacé l'ambiguïté d'un cran en amont, dans la spec, et l'a fait paraître réglée. Ce n'est pas un progrès sur le vrai problème. C'est un meilleur emballage pour lui.
D'où vient vraiment la dette technique amplifiée par l'IA?
En amont de l'éditeur, à tous les coups. C'est l'affirmation sur laquelle repose tout l'article, alors je vais être direct. La vague de dette technique de 2026 n'est pas partie quand un agent a écrit une fonction maladroite. Elle est partie des semaines plus tôt, quand une exigence a été supposée au lieu d'être validée, quand « temps réel » voulait dire trois affaires différentes pour trois parties prenantes, quand un contrôle de sécurité que personne n'a nommé n'a tout simplement jamais atterri dans l'intrant. L'agent n'a pas inventé l'écart. Il en a hérité, puis il l'a multiplié sur quelques milliers de lignes à la vitesse de la machine.
Pense au résultat de Veracode dans cette optique. Les modèles choisissent le chemin non sécuritaire 45 % du temps, et le taux de réussite en sécurité a à peine bougé de 55 % en deux ans malgré des modèles dramatiquement plus puissants (Veracode, Spring 2026). Le monde lit ça comme « les modèles ne sont pas assez sécuritaires », pis oui, en partie. Mais voici la lecture plus difficile. Un contrôle qui n'a jamais été spécifié n'apparaîtra jamais dans le résultat, peu importe à quel point le modèle devient bon. Tu ne peux pas générer une protection contre une menace que personne n'a nommée à la découverte. L'exigence manquante et la protection manquante, c'est le même trou, vu des deux bouts.
Je vais concéder le contre-argument en une phrase, parce qu'il est juste : le processus, le talent et la revue de code comptent eux aussi, et une équipe disciplinée écrit de meilleurs prompts et attrape plus de choses en revue. Vrai. Mais rien de ça ne remonte jusqu'au moment où l'exigence était fausse, et ce moment-là, c'est là que naissent les défauts les plus chers, ce qui est le fil conducteur de tout ce qu'on a écrit sur pourquoi ce sont vos specs, pas votre agent, le problème et sur le coût caché que votre pile IA de codage ignore.
La chose la plus utile publiée là-dessus en 2026 ne venait pas d'un fournisseur qui vend une solution. Elle venait de chercheurs prêts à compter. Yue Liu, David Lo et leurs collègues de la Singapore Management University ont mené une étude qu'ils ont franchement intitulée « Debt Behind the AI Boom », en analysant 304 362 commits vérifiés, écrits par IA, dans 6 275 vrais dépôts GitHub en Python, JavaScript et TypeScript (arXiv, 2026).
Ce qui rend le travail honnête, c'est la deuxième moitié de la méthode. Ils ne se sont pas arrêtés à « les commits IA introduisent des problèmes », un constat qui ne surprend personne. Ils ont suivi si ces problèmes se faisaient corriger, et ont trouvé que 24,2 % d'entre eux survivaient encore dans la dernière révision, à peu près 37 problèmes survivants pour 100 commits écrits par IA. La dette n'est pas théorique. Elle est mesurable, et la majeure partie est juste là, à traîner.
Crédit où c'est dû : c'est le genre de mesure dont le domaine avait besoin, et ça pointe la bonne direction. Les chercheurs sont clairs que les problèmes se concentrent dans des modes d'échec prévisibles, ceux qu'une intention plus claire en amont aurait évités. La leçon, ce n'est pas « l'IA écrit du mauvais code, arrêtez de l'utiliser ». La leçon, c'est que l'intention validée est la défense la moins chère qu'on a, et que presque personne ne l'achète avant de générer.
Qu'est-ce que la discipline des exigences change avant la génération du code?
Elle change l'intrant, le seul endroit où une correction reste encore pas chère. Le temps qu'un défaut atteigne la spec, tu peux l'attraper. Le temps qu'il atteigne le code, tu peux l'attraper plus cher. Le temps qu'il atteigne la production, ça peut coûter des ordres de grandeur de plus, ce qui est tout l'argument de la règle du 29x. La discipline des exigences déplace l'attrapage tout en avant, avant que la machine ait multiplié quoi que ce soit, et c'est le temps de divulguer : c'est exactement ce que Specira est bâti pour faire, alors pesez le biais en conséquence.
Concrètement, l'intelligence des exigences mène une découverte structurée avant qu'un prompt ou une spec existe. Elle force chaque partie prenante à définir le mot flou en chiffres, fait que « temps réel » arrête d'être trois sens secrets cachés dans une ligne propre. Elle demande, à tous les coups, quelles obligations de conformité et de sécurité touchent ces données, fait que le contrôle auquel personne n'a pensé se fait nommer tant que le nommer est encore gratuit. Elle attribue un propriétaire à chaque arbitrage, fait que le choix entre la vitesse et le coût est fait par une personne plutôt que défaut par un agent. Puis elle remet cet ensemble validé en aval. Le même Spec Kit. Le même Kiro. Le même agent rapide. Enfin pointé sur le bon système.
Le format n'a jamais été le problème
Le vibe coding et le développement piloté par specs sont deux réponses à la question de comment capturer l'intention. Ni l'un ni l'autre ne répond à la question plus difficile : est-ce que l'intention était correcte au départ? Cette question-là vit en amont, à la découverte, et aucun format de fichier ne s'y rend.
Alors adoptez les specs. Gardez les agents rapides. Arrêtez juste de prétendre que la spec, c'est là que la qualité se décide. Validez l'exigence en premier, puis générez aussi vite que vous voulez, parce que la vitesse ne devient de la dette que quand elle est pointée sur la mauvaise chose. Mettez l'ordre comme il faut et les mêmes outils que tout le monde a deviennent un avantage durable. Mettez-le à l'envers et vous livrez la mauvaise chose plus vite que jamais, ce qui est le même fil qui traverse pourquoi les agents IA ne savent toujours pas poser les bonnes questions.
Quelles sont les questions les plus fréquentes sur le vibe coding en entreprise?
