Le vibe coding est mort : place à l'UltraCoding

Quand l’inventeur enterre son propre mot

Le 2 février 2025, Andrej Karpathy (cofondateur d’OpenAI, ancien directeur de l’IA chez Tesla) publie sur X un message qui devient viral en quelques heures. Il y décrit une nouvelle manière de programmer : décrire ce qu’on veut en langage naturel, laisser un modèle écrire le code, accepter ce qui revient, relancer si ça ne marche pas. Sa formule fait mouche : « se laisser totalement aller aux vibes, embrasser les exponentielles, et oublier que le code existe » [1]. Le terme vibe coding est né. En quelques mois, il entre au Merriam-Webster comme expression « tendance », puis est sacré mot de l’année 2025 par le dictionnaire Collins [3].

Il faut lire la suite du message original, que l’enthousiasme collectif a souvent oubliée. Karpathy précisait que cette pratique valait « pour des projets jetables du week-end ». Le praticien Simon Willison a posé la définition la plus rigoureuse quelques semaines plus tard : faire du vibe coding, ce n’est pas « utiliser l’IA pour coder » : c’est construire un logiciel sans relire le code que l’IA écrit [2]. Le geste qui définit le vibe coding n’est pas la génération. C’est le renoncement à la relecture.

Or, en ce début 2026, le même Karpathy a tourné la page. Il déclare désormais le vibe coding « passé » et propose un autre terme pour décrire l’avenir du logiciel : agentic engineering, l’ingénierie agentique [4][5]. La différence qu’il pose est nette : le vibe coding consiste à décrire et à accepter ; l’ingénierie agentique consiste à concevoir le système, spécifier les contraintes, et raisonner l’architecture en amont, puis à orchestrer des agents qui implémentent, sous supervision [5].

L’inventeur a enterré son propre mot. Ce n’est pas un reniement : c’est un diagnostic. Le vibe coding n’était pas une erreur. C’était une technique de prototypage que le marché a prise pour une méthode de production. Et la facture de ce malentendu est aujourd’hui chiffrable.

La facture du vibe coding

Trois études sérieuses, publiées en 2025, permettent de sortir des impressions et de regarder les chiffres.

La sécurité d’abord. En juillet 2025, l’éditeur Veracode publie son GenAI Code Security Report : 80 tâches de développement soumises à plus de 100 modèles différents. Le résultat est stable et inquiétant : lorsqu’un modèle a le choix entre une manière sûre et une manière non sûre d’écrire un bout de code, il choisit la version vulnérable dans 45 % des cas [6]. Le détail compte : le taux grimpe à 72 % en Java, et surtout il ne s’améliore pas d’une génération de modèles à l’autre, constat stable sur toutes les familles testées (OpenAI, Anthropic, Google). La mise à jour Veracode de mars 2026 prolonge le constat : après deux ans de sorties présentées comme révolutionnaires, le taux reste à 45 %, y compris sur GPT-5.1/5.2, Gemini 3 et Claude 4.5/4.6 [6]. Autrement dit, attendre « le prochain modèle, plus intelligent » ne réglera pas le problème de sécurité. Un modèle plus performant écrit du code plus impressionnant, pas nécessairement plus sûr.

La productivité ensuite. En juillet 2025, le laboratoire indépendant METR publie un essai contrôlé randomisé, l’étalon-or de la preuve scientifique. Seize développeurs open-source expérimentés, 246 tâches réelles sur des projets qu’ils connaissaient en moyenne depuis cinq ans. Verdict : avec les outils d’IA de début 2025, ils ont mis 19 % de temps en plus pour accomplir leurs tâches. Le plus troublant n’est pas le ralentissement. C’est l’écart de perception : ces mêmes développeurs estimaient que l’IA les avait rendus 20 % plus rapides [7]. La machine ne ralentit pas seulement : elle donne l’illusion de l’accélération. C’est exactement le piège du vibe coding : la sensation de fluidité masque le coût réel, qui se paie plus tard, en débogage.

La livraison enfin. Le rapport DORA 2025 de Google Cloud, référence annuelle de la mesure de la performance logicielle, confirme la bascule au niveau de l’organisation : l’adoption de l’IA augmente bien le débit (on livre plus), mais elle augmente aussi l’instabilité des mises en production [9]. Sa formule résume tout : « l’IA ne répare pas une équipe ; elle amplifie ce qui est déjà là ». L’édition suivante (Google Cloud/DORA, mai 2026) confirme en dessinant une « courbe en J » : la taxe de vérification et d’instabilité précède les gains. Sans système de contrôle (tests automatisés robustes, intégration continue, petits lots, boucles de retour rapides), plus de code livré plus vite produit mécaniquement plus de casse.

Le point commun de ces trois constats est limpide. Le problème n’est pas la capacité de l’IA à générer du code. Elle n’a jamais été aussi forte. Le problème est l’absence d’un système de vérification autour de cette génération. Le vibe coding a supprimé la relecture sans rien mettre à la place. C’est précisément le vide que comble la pratique suivante.

D’« agentic engineering » à l’UltraCoding

L’ingénierie agentique de Karpathy décrit une posture : ne plus écrire le code soi-même 99 % du temps, mais orchestrer des agents qui le font, en gardant la main sur la conception, les contraintes et la supervision [4][5]. C’est juste. Mais une posture n’est pas une méthode. « Garder la main » et « superviser » ne disent pas comment, ni jusqu’où, ni à quel moment on a le droit de livrer.

C’est ce passage de la posture à la chaîne de production que nous appelons UltraCoding. Le mot est volontairement fort, parce que la pratique l’est. L’UltraCoding est une chaîne de production logicielle agentique dont la seule condition de sortie est un niveau de qualité mesuré, et qui assume de consommer davantage de ressources pour atteindre ce niveau : plus de jetons (tokens), plus de calcul, plus de temps machine. La surconsommation n’est pas un effet de bord à corriger. C’est le prix d’entrée d’une qualité que le vibe coding ne pouvait structurellement pas livrer.

L’UltraCoding tient en quatre gestes, plus un audit transverse :

1. L’orchestration multi-agents : plusieurs IA spécialisées plutôt qu’une seule généraliste.
2. La revue adversariale : une IA dont le métier est de casser le code d’une autre.
3. Le test à trois couches : du test automatique classique au contrôle visuel de l’interface par l’IA.
4. La boucle de déploiement au seuil : on recommence jusqu’à atteindre la barre, puis on livre.

Et, en transverse à chacun de ces gestes, un audit : sécurité, internationalisation (i18n), accessibilité.

Reprenons chaque geste, avec ce qui le justifie.

Geste 1 : L’orchestration multi-agents

L’intuition dominante de 2023-2024 était qu’un seul modèle, toujours plus gros, finirait par tout faire. La pratique de 2025-2026 dit l’inverse : on obtient de meilleurs résultats avec plusieurs agents spécialisés qui collaborent qu’avec un agent unique surchargé.

La démonstration la plus documentée vient d’Anthropic. Dans le retour d’expérience publié en juin 2025 sur son système de recherche multi-agents, l’architecture est de type orchestrateur-travailleurs : un agent chef de file planifie, lance 3 à 5 sous-agents spécialisés en parallèle, chacun avec sa propre fenêtre de contexte, puis synthétise leurs travaux. Résultat mesuré : cette organisation surpasse l’agent unique (Claude Opus 4 seul) de 90,2 % sur leur évaluation interne [8].

Le même retour d’expérience donne le prix de cette performance, et c’est essentiel pour un dirigeant : le système consomme environ 15 fois plus de jetons qu’une conversation classique, et la quantité de jetons utilisée explique à elle seule près de 80 % de la variance de performance [8]. Traduit en clair : la qualité se paie en ressources, de manière quasi linéaire. La règle économique qu’Anthropic en tire est la bonne boussole de l’UltraCoding : l’architecture multi-agents n’a de sens que lorsque la valeur de la tâche dépasse le coût des jetons. Pour produire du logiciel destiné à la production, à des clients, à de l’argent qui transite, cette condition est presque toujours remplie.

Concrètement, une équipe UltraCoding ne lance pas « une IA qui code ». Elle orchestre un architecte qui découpe, plusieurs implémenteurs qui écrivent en parallèle, un testeur qui éprouve, un relecteur qui conteste. Chacun a un rôle, un périmètre, et une fenêtre de contexte propre.

Geste 2 : La revue adversariale

C’est le cœur de l’UltraCoding, et c’est ce qui le sépare le plus nettement du vibe coding. Une IA ne doit jamais être son propre juge. Lui demander « ton code est-il correct ? » revient à demander à un candidat de corriger sa propre copie : il se donnera une bonne note.

La parade est connue de la recherche depuis 2023 et porte un nom : la boucle générateur-critique. Un agent produit ; un autre agent, indépendant, a pour unique mission de trouver la faille. OpenAI a entraîné un modèle dédié à cet usage, CriticGPT, spécifiquement pour critiquer et débusquer les bugs du code écrit par d’autres modèles [10]. Les cadres académiques Self-Refine (générer → critiquer → corriger) et Reflexion (mémoriser ses échecs pour ne pas les répéter) ont formalisé cette mécanique d’auto-amélioration par confrontation [11]. Le code a ici un avantage unique sur le texte : il est exécutable. Le retour n’est pas une opinion, c’est un résultat de compilation ou de test, un fait objectif sur lequel la boucle peut s’appuyer.

La revue adversariale ne s’arrête pas à la correction fonctionnelle. Elle s’étend à la sécurité : un agent « équipe rouge » dont le rôle est de penser comme un acteur malveillant : chercher l’injection de prompt, la fuite de données, l’autorisation manquante. Vu le taux de 45 % de code vulnérable mesuré par Veracode [6], cette confrontation n’est pas un luxe : c’est la seule défense crédible contre un défaut que les modèles, laissés à eux-mêmes, reproduisent génération après génération.

La règle, en UltraCoding, est sans exception : le générateur ne valide jamais sa propre production.

Geste 3 : Le test à trois couches

Tester, en UltraCoding, ne veut pas dire « lancer les tests unitaires ». Cela veut dire empiler trois couches de vérification, du plus mécanique au plus subtil.

Couche 1 : les tests automatisés classiques. Tests unitaires, d’intégration, de bout en bout. C’est la vérité exécutable : le code fait-il ce qu’il prétend faire ? Cette couche est nécessaire mais insuffisante : elle vérifie la logique, pas l’expérience ni la sûreté.

Couche 2 : l’audit. Deux contrôles que le vibe coding ignore presque toujours. D’abord la sécurité : analyse statique, détection de secrets en clair, vérification des en-têtes et des protections contre les attaques classiques, la réponse directe au 45 % de Veracode [6]. Ensuite l’internationalisation et l’accessibilité : pseudo-traduction pour débusquer les textes codés en dur, gestion des langues écrites de droite à gauche, formats de dates et de devises, et conformité aux critères d’accessibilité (WCAG) pour que l’interface reste utilisable par tous. Ces audits ne « se sentent » pas en démo ; ils se révèlent en production, souvent au pire moment.

Couche 3 : le contrôle visuel de l’interface par l’IA, avec critique UX/design. C’est la couche la plus récente et la plus spectaculaire. Jusqu’en 2024, tester une interface revenait à comparer des pixels : fragile, bruité, aveugle au sens. L’arrivée des modèles vision-langage (VLM) a changé la donne. Ces modèles regardent l’écran rendu et le comprennent comme un humain : non plus « ce pixel a bougé de 3 points », mais « le bouton Acheter est en partie masqué par une bannière, donc l’action principale est compromise » [14]. L’outil Percy a lancé fin 2025 un agent de revue visuelle qui réduit d’environ 3 fois le temps de relecture et filtre près de 40 % des faux positifs [14]. Au-delà du rendu, des travaux académiques comme UXAgent (CHI 2025) simulent des panels d’utilisateurs et conduisent des évaluations heuristiques automatisées de l’ergonomie avant tout test humain réel [12].

Une honnêteté s’impose ici, car c’est la couche la moins mature. La critique UX par IA n’est pas infaillible : en mars 2025, deux chercheuses UX de Microsoft ont mesuré des taux d’exactitude de 50 à 75 % seulement pour des évaluations heuristiques conduites par IA, quand des systèmes spécialisés et entraînés comme celui de Baymard revendiquent jusqu’à 95 % [13]. La conclusion opérationnelle est claire : le contrôle visuel par IA accélère et élargit la relecture, il ne remplace pas le jugement de design humain. Il signale, il pré-trie, il documente. La décision esthétique et l’arbitrage d’expérience restent humains.

Geste 4 : La boucle de déploiement au seuil

Voici ce qui fait de l’UltraCoding une méthode et non une collection d’outils. Les trois gestes précédents tournent en boucle (générer, confronter, tester, corriger) et cette boucle ne s’arrête pas quand le développeur est fatigué ou quand le délai presse. Elle s’arrête quand un seuil de qualité explicite et mesurable est atteint : couverture de test, zéro vulnérabilité critique, conformité d’accessibilité, score de revue visuelle. Tant que le seuil n’est pas franchi, la boucle recommence. Dès qu’il l’est, le déploiement se déclenche.

Cette inversion est profonde. Dans le vibe coding, on livre quand « ça a l’air de marcher ». En UltraCoding, on livre quand la barre est atteinte, pas quand l’humain est à bout. C’est exactement la prescription du rapport DORA 2025 : associer le débit accru de l’IA à des garde-fous automatisés, des petits lots, des boucles de retour rapides ; sans quoi la vitesse se paie en instabilité [9]. Le seuil rend la décision de livrer objective, reproductible et défendable.

Le contre-argument honnête : ça coûte cher, mais ça s’internalise

Il faut le dire sans détour : l’UltraCoding consomme. Quinze fois plus de jetons pour l’orchestration multi-agents mesurés par Anthropic en 2025 [8], du calcul pour chaque couche de test, du temps pour chaque tour de boucle, de la latence. Les mesures 2026 situent la fourchette des workflows agentiques entre 5 et 30 fois (TechCrunch, juin 2026). Ce n’est pas gratuit, et prétendre le contraire serait malhonnête.

La conséquence est qu’il existe des cas où l’UltraCoding est un gâchis. Pour un script jetable, une macro qu’on lancera une fois ou un prototype du week-end destiné à valider une intuition puis à être supprimé, le vibe coding reste parfait, et Simon Willison a raison de dire qu’il « assure » dans ce registre [2]. Déployer une chaîne adversariale à trois couches pour cela reviendrait à passer le contrôle technique sur une voiture qu’on enverra à la casse le lendemain.

L’UltraCoding devient en revanche non négociable dès que le coût d’un bug dépasse le coût des jetons : un logiciel en production, une interface face à des clients, un système réglementé, un flux qui touche à de l’argent ou à des données personnelles. Là, économiser 15 fois les jetons pour risquer une faille de sécurité (45 % de probabilité par défaut, mesurée par Veracode mi-2025 [6]) ou une mise en production instable [9] n’est pas une économie. C’est un transfert de coût vers plus tard, avec intérêts.

Et ce coût n’est même pas une fatalité : il peut être internalisé. Les 15 fois de consommation ne posent problème que tant qu’on les paie à l’unité, en dépense courante (OpEx), à une API frontière facturée au jeton. Rien n’impose ce modèle. Un serveur d’inférence dédié, un modèle open-source bien calibré sur son domaine, et une boucle agentique développée en interne transforment cette surconsommation en investissement amorti (CapEx) : un actif matériel fixe qui tourne sans compteur, sur une infrastructure que l’on possède. Le calcul d’amortissement bascule souvent en faveur de l’internalisation dès que le volume est là, et il apporte ce que le cloud facturé ne donnera jamais : la souveraineté. Le code, les données et les secrets de l’entreprise ne quittent plus son périmètre.

Mieux encore : ces boucles n’ont aucune raison de tourner aux heures de pointe. Elles peuvent s’exécuter en temps masqué, quand les serveurs ne sont pas mobilisés par les tâches en temps réel : la nuit, le week-end, dans les creux de charge. Le coût de calcul devient alors un coût masqué : on exploite une capacité déjà payée et autrement inutilisée. Ne subsiste, à la marge, que l’énergie, elle-même optimisable (heures creuses, pilotage de la charge, électricité bas-carbone). L’UltraCoding cesse ainsi d’être une dépense variable subie pour devenir une capacité industrielle possédée. La contrepartie, honnête, est qu’il faut un volume suffisant pour amortir le matériel et une compétence interne pour calibrer le modèle et tenir la boucle : cette voie n’est pas pour tout le monde, mais elle est ouverte à qui veut sortir de la location.

Et l’humain, dans tout cela ? L’étude METR est un garde-fou salutaire [7] : l’IA livrée à elle-même peut ralentir et tromper sur sa propre vitesse. L’UltraCoding ne supprime pas l’humain. Il le déplace là où il crée le plus de valeur : définir le seuil, écrire la spécification, arbitrer les cas que la machine ne tranche pas, et signer la livraison. Le développeur ne tape plus chaque ligne ; il devient l’architecte du standard et le juge de dernier ressort.

Ce que ça change pour un dirigeant

On peut lire cet article comme un sujet d’ingénieurs. Ce serait une erreur. L’UltraCoding est d’abord une exigence de qualité que tout dirigeant peut, et devrait, formuler, sans écrire une ligne de code.

Vous n’avez pas à construire la chaîne vous-même. Vous avez à savoir réclamer la barre et à budgéter les ressources quand l’enjeu le justifie. Trois questions suffisent à révéler la maturité d’un prestataire ou d’une équipe interne : Qui relit le code que votre IA produit, et avec quel autre outil ? Comment testez-vous l’interface et la sécurité avant livraison ? Quel seuil mesurable déclenche une mise en production, et qui le signe ? Une équipe qui « fait du vibe coding » n’a pas de réponse à ces trois questions. Une équipe qui pratique l’UltraCoding les a toutes.

C’est exactement de cette manière que nous construisons Junyr Suite. Notre conviction, dans la Méthode MATIA™, est qu’à l’ère de l’IA la rareté ne se déplace pas vers la génération de code (elle devient abondante) mais vers la vérification : la capacité à garantir, prouver et tenir un niveau de qualité. C’est là que se joue désormais la transformation IA des entreprises : non pas « produire plus vite », mais « produire à un standard qu’on peut défendre devant un client, un auditeur ou un régulateur ».

Et c’est ici que l’UltraCoding dépasse le logiciel. La logique qui le fonde (générer, confronter à un contradicteur, éprouver sur trois couches, ne livrer qu’au seuil) n’a rien de propre au code. C’est une boucle de confiance transposable à n’importe quel travail produit par une IA. C’est précisément ce que nous faisons avec la Méthode MATIA™ : nous implémentons l’UltraCoding dans les entreprises, puis nous appliquons la même boucle aux agents de toutes les fonctions : commercial, finance, marketing, support, RH. Un agent qui rédige une proposition, qualifie un prospect ou prépare un reporting suit le même cycle qu’un agent qui écrit du code : production, revue adversariale, contrôle, seuil de qualité avant toute action. La génération devient abondante partout dans l’entreprise ; la vérification, elle, en devient le standard partout. C’est cela, au fond, la transformation IA : non pas brancher des modèles, mais installer la boucle qui rend leur travail fiable.

Le vibe coding promettait d’oublier que le code existe. L’UltraCoding fait le pari inverse : se souvenir que, derrière chaque interface fluide, il y a du code dont quelqu’un répond. Cette responsabilité ne se délègue pas à une « vibe ». Elle s’organise.

En une phrase

Le vibe coding a appris au monde que l’IA peut tout écrire. L’UltraCoding lui apprend la seule chose qui compte désormais : comment savoir que ce qu’elle a écrit est bon, avant de le livrer.

Pour traduire l’UltraCoding en standard de qualité dans vos projets logiciels, voir la Méthode MATIA™ et le Diagnostic IA Express.

---

Sources

[1] Andrej Karpathy, message sur X, 2 février 2025 (origine du terme vibe coding), synthèse et citation via Vibe coding, Wikipedia. https://en.wikipedia.org/wiki/Vibe_coding [2] Simon Willison, « Not all AI-assisted programming is vibe coding (but vibe coding rocks) », 19 mars 2025. https://simonwillison.net/2025/Mar/19/vibe-coding/ [3] Collins Dictionary, vibe coding, mot de l’année 2025 ; Merriam-Webster, mention « slang & trending », mars 2025 (via Wikipedia). https://en.wikipedia.org/wiki/Vibe_coding [4] « Vibe coding is passé. Karpathy has a new name for the future of software », The New Stack, 2026. https://thenewstack.io/vibe-coding-is-passe/ [5] « Andrej Karpathy Has Renamed Vibe Coding. Here’s What Engineering Leaders Need to Do About It », SD Times, 2026. https://sdtimes.com/ai/andrej-karpathy-has-renamed-vibe-coding-heres-what-engineering-leaders-need-to-do-about-it/ [6] Veracode, 2025 GenAI Code Security Report, 30 juillet 2025 (45 % de code vulnérable ; 80 tâches, 100+ modèles ; Java 72 % ; stabilité GPT-4→GPT-5/Claude/Gemini) ; confirmé par la mise à jour Spring 2026 GenAI Code Security, 24 mars 2026 (pass rate toujours ~55 %, 150+ modèles évalués, plateau maintenu jusqu’à GPT-5.1/5.2, Gemini 3 et Claude 4.5/4.6). https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/ ; https://www.veracode.com/blog/spring-2026-genai-code-security/ [7] METR, « Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity », 10 juillet 2025 (arXiv 2507.09089), ralentissement de 19 %, écart de perception. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ [8] Anthropic, « How we built our multi-agent research system », juin 2025 (orchestrateur-travailleurs, +90,2 % vs agent unique, ~15× jetons, ~80 % de la variance). https://www.anthropic.com/engineering/multi-agent-research-system [9] Google Cloud / DORA, 2025 State of AI-assisted Software Development Report (débit en hausse, instabilité en hausse ; « l’IA amplifie ce qui est déjà là »). https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report [10] OpenAI, CriticGPT, modèle entraîné à critiquer et trouver les bugs du code généré par d’autres modèles (2024), via LLMs-as-Judges: A Comprehensive Survey (arXiv 2412.05579). https://arxiv.org/pdf/2412.05579 [11] Self-Refine (Madaan et al., 2023) et Reflexion (Shinn et al., 2023), boucle générer→critiquer→corriger et renforcement verbal par mémorisation des échecs (via arXiv 2412.05579). https://arxiv.org/pdf/2412.05579 [12] UXAgent: An LLM Agent-Based Usability Testing Framework for Web Design, CHI 2025 (arXiv 2502.12561 ; Amazon Science), personas simulés et évaluation heuristique automatisée. https://arxiv.org/abs/2502.12561 [13] Baymard Institute, « AI Heuristic UX Evaluations with a 95% Accuracy Rate » (et caveat : chercheuses UX de Microsoft, mars 2025, exactitude 50-75 % selon les cas). https://baymard.com/blog/ai-heuristic-evaluations [14] Modèles vision-langage pour le test d’interface et revue visuelle agentique (Percy AI Visual Review Agent, fin 2025 : ~3× plus rapide, ~40 % de faux positifs filtrés ; lecture sémantique de l’écran), TestMu (LambdaTest). https://www.testmuai.com/blog/visual-testing-ai-agent/ [15] A Survey of Vibe Coding with Large Language Models (arXiv 2510.12399, 2025), cadrage académique de la pratique et de ses limites. https://arxiv.org/pdf/2510.12399