Deux courriels différents. C'est ça, le bogue au complet, et il appartient à celui qui a inventé le terme dont parle cet article : Andrej Karpathy a monté une petite application, MenuGen, où l'utilisateur se connecte avec un compte Google mais achète ses crédits par Stripe, et l'agent qui écrivait le code a décidé de faire le lien entre les deux avec l'adresse courriel. Les deux systèmes ont un champ courriel. L'agent hallucinait pas, il était pas mêlé non plus, il a produit du code fonctionnel qui faisait exactement ce que l'intention laissait entendre, et un client payant pouvait ne jamais recevoir les crédits qu'il venait de payer.
Le diagnostic, publié après l'événement Sequoia AI Ascent le 30 avril 2026, tient sur une ligne : « Pourquoi utiliserais-tu des adresses courriel pour faire correspondre des fonds ? Ça prend un identifiant utilisateur persistant. » Évident après coup. Personne l'avait écrit nulle part, et c'est ça le bout qui dérange, parce que 2026 a dépensé la majeure partie de son énergie argumentative sur le format du document qui aurait contenu cette phrase plutôt que sur la question de savoir qui était censé la connaître.
Pourquoi tout le monde dit soudainement que le vibe coding est fini ?
Parce que celui qui l'a nommé est passé à autre chose, et bien du monde a lu ça comme un avis de décès. C'en était pas un. En février 2026, environ un an après avoir inventé le terme, Karpathy a proposé une étiquette successeur pour ce que les professionnels faisaient déjà avec les agents de codage : l'ingénierie agentique. La presse spécialisée a compressé ça en « le vibe coding est passé date » en dedans d'une semaine, ce qui fait un titre plus propre que ce qui s'est réellement passé, et c'est exactement comme ça qu'une distinction utile finit aplatie en verdict.
La distinction survit intacte dans le texte original. Le vibe coding, selon le résumé d'avril 2026, « consiste à relever le plancher pour tout le monde, en matière de ce qu'on peut faire en logiciel », tandis que l'ingénierie agentique « consiste à préserver le standard de qualité du logiciel professionnel ». Deux jobs différents. Rien a été enterré : une activité a reçu un plancher, l'autre a reçu un plafond, et la version professionnelle est arrivée avec une courte liste de pratiques que le marché de l'outillage a tout de suite reconnue comme une catégorie de produit, à commencer par la consigne d'écrire une spec détaillée avant de prompter.
Fait que les specs ont eu leurs outils. Le blogue développeur de Microsoft a publié sa vision spec-first de l'ingénierie native à l'IA le 10 juin 2026, et le billet est étonnamment franc sur l'échec qu'il cherche à prévenir : « Les équipes livrent souvent un logiciel qui fonctionne mais qui rate quand même l'intention de départ. » GitHub Spec Kit, OpenSpec et Kiro déclinent tous le même cycle. Un article conceptuel soumis le 31 août 2026 pousse la thèse plus loin en affirmant que le développement piloté par spec « reconstitue, sous forme centrée sur la spécification, les contrats que le vibe coding dissout : la responsabilité, la vérifiabilité et la transférabilité ». Grosse affirmation. Et, de l'aveu des auteurs, une affirmation bâtie « principalement sur de la littérature grise » parce que les preuves évaluées par les pairs « ne sont pas encore établies », ce qui dit honnêtement que la discipline devance ses propres preuves.
46,41 %
des correctifs de code proposés par quatre agents nommés, Copilot, Devin, Cursor et Claude, ont été rejetés plutôt que fusionnés. Une lecture qualitative de 306 de ces demandes de tirage rejetées a produit 14 raisons distinctes, et la plus grosse catégorie était une implémentation incorrecte, incomplète, ou qui prenait la mauvaise approche. La mesure porte sur les demandes de type correctif, pas sur tout le code généré par IA.
Source : Abujadallah, Arabat et Sayagh, Understanding the Rejection of Fixes Generated by Agentic Pull Requests: Insights from the AIDev Dataset, publié dans les actes de la 23e International Conference on Mining Software Repositories (MSR 2026), prépublication soumise le 11 juin 2026. Extrait de demandes de tirage écrites par des agents dans des dépôts GitHub publics ; échantillon qualitatif de 306 demandes non fusionnées.
La recommandation de l'article se lit comme si un partisan des specs l'avait écrite : suggère l'approche à prendre, nomme les contraintes à éviter, dis à l'agent comment valider son travail. Tout est juste. Chaque mot présuppose quand même que quelqu'un dans la bâtisse sait déjà quelle approche est la bonne et quelle contrainte est réelle, ce qui est une hypothèse pas mal plus grosse que la phrase le laisse croire.
Qu'est-ce qu'une porte de spec peut vraiment valider ?
Quatre affaires, et chacune est une propriété du document plutôt que du monde : la complétude, la cohérence interne, des critères d'acceptation testables, et une signature. Utile pareil. On a défendu en juin que sortir une exigence d'un prompt lousse pour la mettre dans une spec structurée la place au moins quelque part où une personne nommée peut être invitée à la regarder, et cet argument tient encore. Ce qu'une porte peut pas faire, c'est sortir du document pour vérifier si l'affirmation dedans a déjà été vraie, et le texte le plus pro-spec de 2026 concède exactement cette limite en une phrase : « L'IA peut accélérer ces étapes, mais elle ne peut pas corriger une ambiguïté qui n'a jamais été résolue. »
Relis ça. Microsoft nuance pas, ici : l'entreprise trace la frontière honnête de sa propre catégorie de produit, et cette frontière est le sujet même de ce texte, parce qu'une spécification est un moyen de transport pour des décisions que quelqu'un a déjà prises en amont, donc si la décision était mauvaise au moment où elle a été prise, la spec la transporte fidèlement, numérotée, traçable, testable et fausse. La ligne de résumé du billet dit « qualité de la spec = qualité du résultat ». Vrai. Ça laisse ouverte la question de ce qui détermine la qualité de la spec, et la réponse, c'est pas le gabarit.
Reprenons MenuGen, parce que c'est la preuve la plus propre disponible. Une spec rigoureuse pour cette application aurait produit une section intitulée Attribution des crédits, avec des critères d'acceptation en dessous et des cas limites en dessous de ceux-là, et chacun de ces critères aurait été parfaitement testable. Est-ce qu'elle aurait dit « faire la correspondance sur un identifiant persistant, jamais sur le courriel » ? Seulement si quelqu'un avait déjà compris que l'identité Stripe et l'identité Google sont deux systèmes distincts qui partagent par hasard un format de chaîne. Ça, c'est un constat. C'est pas un format de documentation, et aucune discipline Markdown le génère toute seule.
Qu'est-ce que le débat sur les portes de validation humaines oublie ?
La porte elle-même. Les deux camps discutent de la quantité de document à écrire, écrit quand et signé par qui, ce qui garde toute la dispute pointée sur l'instrument plutôt que sur ce que l'instrument vise. Le débat est réel, remarque, et les deux camps sont sérieux. François Zaninotto, chez Marmelab, a appelé le développement piloté par spec « The Waterfall Strikes Back » en novembre 2025, et le texte a frappé fort sur Hacker News parce que des ingénieurs en poste ont reconnu la plainte : les specs détaillées en amont supposent un déterminisme que le développement logiciel a jamais eu, et les maintenir dépense du temps de lecture qui servait avant à réfléchir. L'autre camp répond que des agents lâchés lousses sans contrat écrit produisent exactement la surcharge de révision dont tout le monde se plaint depuis 2025. Les deux ont raison.
Un camp veut garder et durcir la porte de validation humaine, l'autre veut l'amincir ou l'enlever complètement, et aucune des deux positions oblige qui que ce soit à lire ce qui est écrit sur la page. Personne la lit. Birgitta Böckeler, chez Thoughtworks, avait attrapé la dérive tôt en écrivant en octobre 2025 que le terme « n'est pas encore très bien défini, et il est déjà sémantiquement dilué », des gens utilisant « spec » comme synonyme de « prompt détaillé ». Une porte qui valide un prompt détaillé contre rien, c'est une revue de mise en page avec une cérémonie collée dessus.
La question qu'on saute est en amont des deux positions. Gênante de simplicité. D'où vient le contenu du document ? Une porte peut confirmer qu'un document est complet, cohérent, testable et signé, et elle peut faire les quatre en un après-midi. Elle peut pas confirmer que l'exigence à l'intérieur a déjà été confrontée à la personne qui aurait dit non. Les deux modes d'échec de l'ère IA se ressemblent vus d'en haut : quelque chose de plausible a été produit, personne peut pointer le moment où ça a été validé, et c'est parti en production pareil.
Sur le terrain
Le Government Accountability Office des États-Unis est allé chercher ce motif dans l'approvisionnement public et l'a trouvé à ciel ouvert. Son rapport sur les acquisitions en intelligence artificielle, publié le 13 avril 2026, a examiné 13 acquisitions dans quatre agences fédérales. Une phrase décrit toute la maladie : « l'industrie introduit parfois des capacités, dont certaines commerciales, auprès des agences pour répondre à leurs besoins en l'absence d'exigences précises en matière d'IA. » Après, l'exemple. La General Services Administration a acheté un logiciel de suivi de l'entretien des installations qui arrivait avec un agent conversationnel inclus, et des responsables ont dit au GAO, sans détour, que « le fournisseur a offert l'agent conversationnel comme capacité ajoutée et non en réponse à une exigence définie. » Personne a écrit une mauvaise spec là-dedans. Personne en a écrit une pantoute, et la capacité a été livrée quand même, ce qui est exactement l'échec que le développement piloté par spec existe pour prévenir.
Source : United States Government Accountability Office, Artificial Intelligence Acquisitions: Agencies Should Collect and Apply Lessons Learned to Improve Future Procurements, GAO-26-107859, 13 avril 2026. L'examen portait sur 13 acquisitions en IA dans quatre agences fédérales.
Où se place la validation des exigences dans l'ingénierie agentique ?
Avant le premier titre. La validation est un acte différent de l'écriture, et rédiger une spécification est un acte d'expression : on croit déjà quelque chose, et on choisit une structure et des mots pour transporter cette croyance jusqu'à un agent sans en perdre un morceau. La validation, elle, est un acte d'interrogatoire, où la croyance elle-même est ce qui passe au banc des accusés. On confond les deux tout le temps parce que les artéfacts se ressemblent à l'écran. Une des deux demande comment je dis ça clairement. L'autre demande comment je sais que c'est vrai, et juste la deuxième aurait attrapé la décision sur les courriels avant qu'un agent l'implémente magnifiquement.
La mécanique compte plus que l'étiquette. Un analyste qui interviewe une partie prenante produit un cadrage, filtré par tout ce que cet analyste croyait déjà en entrant dans la salle, et c'est comme ça qu'un contournement finit consigné comme une exigence. Une seule lentille. Plusieurs spécialistes qui interrogent la même matière depuis des positions expertes délibérément différentes produisent quelque chose de plus solide, parce que les questions se rentrent dedans et que les collisions, c'est là que l'hypothèse non dite finit par sortir. Specira fait rouler cinq agents : quatre analystes qui travaillent la matière sous des angles distincts, plus un Red Team Critic dont la job entière est d'attaquer ce que les quatre autres ont produit. Divulgation, là : c'est le produit que je bâtis, fait que pèse le discours en conséquence et vérifie le mécanisme plutôt que la marque. Le critique, c'est la pièce qui compte pour cet argument. C'est lui qui demande pourquoi une règle existe plutôt que si elle est écrite clairement.
Après ça, écris la spec. Écris-la pour vrai, avec Spec Kit ou OpenSpec ou ce que ton équipe a fini par adopter, en te rappelant que le plafond de ce qu'une spec peut atteindre est fixé par la découverte en dessous, parce que faire le travail de validation et laisser ensuite le résultat mourir dans les notes de rencontre de quelqu'un serait sa propre espèce de gaspillage. La séquence, c'est l'argument. Valide en premier pour que la certitude dans le document soit méritée, ensuite laisse la spec la transporter jusqu'à l'agent sans perte de fidélité.
À retenir
Le vibe coding est pas mort, il s'est trouvé un frère professionnel, et le frère roule sur des specs. Vrai progrès. Adopte-le, mais remarque qu'une spécification transporte la certitude au lieu de la fabriquer, donc une spec parfaitement structurée bâtie sur une hypothèse non validée reste fausse, sauf qu'elle est maintenant fausse avec une meilleure mise en page et un beau journal d'audit. La validation, c'est l'acte en amont qui décide s'il y a quelque chose qui mérite d'être spécifié.
Que devrait vérifier la porte si c'est pas la forme de la spec?
Si l'exigence tient. Une porte de spec lit la structure; Specira lit la ligne elle-même, en donnant à chaque exigence un score de qualité, une source et un responsable, et en retenant une proposition de l'IA pour une décision humaine au lieu de la laisser se fondre dans l'ensemble. Ouvrez la ligne et la vérification devient explicite : résultats promis en critères d'acceptation, sources à l'appui, liste de révision avec les étapes qui restent. Le PRD se rend à partir de ce qui a survécu.
Ce que vous voyez. La liste des exigences, c'est la porte qui lit le contenu plutôt que le format, le détail de l'exigence, c'est ce que la porte vérifie, et le PRD, c'est ce qui se rend une fois la vérification passée.
Montrez-nous la porte de spec sur laquelle vous comptez. On vous montre l'exigence qu'elle va laisser passer sans la lire.
Réserver une démoÉcrans tirés d'un espace de démonstration Specira; compteurs et scores sont des données d'exemple.
Quelles sont les questions les plus fréquentes sur la fin du vibe coding ?
