Agentic engineering : le guide après le vibe coding (avec les vrais chiffres)

En mai 2026, lors du Sequoia AI Ascent, Andrej Karpathy a posé le diagnostic sans détour : le vibe coding appartient à 2025. Générer une application en quelques heures à partir d'un prompt, sans architecture ni tests, reste fascinant comme preuve de concept. En production, c'est une dette technique masquée qui explose au premier changement réel. Ce moment marque l'entrée dans une autre ère, celle que les ingénieurs et les analystes industriels commencent à appeler l'agentic engineering.

Cet article propose une définition opérationnelle de ce que signifie l'agentic engineering en 2026, avec les preuves chiffrées, les choix d'architecture qui le permettent, et un plan de transition concret pour les équipes qui veulent passer du prototype à la production.

Ce que Karpathy a vraiment dit

Karpathy a décrit un point de bascule personnel : en novembre 2025, il écrivait encore environ 80 % de son code lui-même. En décembre, ce ratio s'est inversé — il déléguait 80 % de la production aux agents. Le déclic n'est pas venu d'une amélioration spectaculaire des outils. Il est venu du moment où la charge cognitive de superviser un agent est devenue inférieure à celle d'écrire le code soi-même.

L'objectif est de capturer le levier des agents sans aucun compromis sur la qualité du logiciel. Le vibe coding fait le contraire : il maximise le levier en sacrifiant la qualité.

— Andrej Karpathy, Sequoia AI Ascent 2026 (paraphrase à partir du résumé bearblog)

Le message de Karpathy est souvent réduit à une critique du vibe coding. C'est plus subtil que ça. Il ne dit pas que le vibe coding est inutile : il dit que ses 80 % de délégation aux agents IA ne produisent de la valeur durable que si le cadre dans lequel les agents opèrent est rigoureux. Sans ce cadre, les 80 % de délégation génèrent 80 % de risque non contrôlé.

Vibe coding versus agentic engineering : la distinction qui compte

Martin Fowler a formulé la distinction avec une précision utile en septembre 2025. Le vibe coding, c'est laisser un modèle de langage conduire les décisions de conception, sans modèle explicite du problème. L'agentic engineering, c'est donner aux agents IA un cadre formel issu de l'ingénierie logicielle — spécifications, domaines, contraintes — et les laisser opérer à l'intérieur de ce cadre.

Sans bonnes pratiques en place, ce multiplicateur de vélocité devient un accélérateur de dette technique. Écrire du code n'a jamais été le vrai goulot d'étranglement.

— Martin Fowler, To vibe or not to vibe, septembre 2025

En pratique, la différence se mesure à une question : est-ce que votre agent peut expliquer pourquoi il a pris une décision, et est-ce qu'un humain peut la retracer ligne par ligne dans un journal d'événements ? Si la réponse est non, vous êtes encore dans le vibe coding, même si votre prompt est long.

La preuve par les chiffres : 2 900 € contre 85 000 €

Ces chiffres méritent d'être lus avec leur contexte. La divergence ne vient pas de la qualité des développeurs mais de la structure du système. Un prototype généré sans modèle de domaine n'a pas de frontières entre ses composants. Chaque correction introduit une régression. Chaque évolution nécessite de tout re-lire. Le coût marginal de chaque changement croît de façon exponentielle, alors que dans un système agentic-engineered, il reste constant.

Les 7 caractéristiques d'un système agentic-engineered

• Spécification formelle du domaine : chaque agent opère dans un périmètre métier bien délimité, défini indépendamment du code.
• Traçabilité des décisions : chaque action de l'agent génère un événement daté et typé, rejouable indépendamment.
• Invariants vérifiables : les règles métier critiques sont exprimées comme des contraintes vérifiées à la compilation et au runtime.
• Escalade structurée : l'agent sait quand il sort de son périmètre et comment transférer le contrôle à un humain ou à un autre agent.
• Évaluation continue : des suites de tests évaluent le comportement de l'agent à chaque évolution, pas seulement à la mise en production initiale.
• Isolation des effets de bord : les appels aux systèmes externes sont médiatisés par des interfaces explicites, réversibles ou rejouables.
• Observabilité native : les métriques de dérive, de taux d'erreur et de confiance sont exposées sans instrumentation manuelle.

Ces sept caractéristiques ne sont pas des aspirations. Ce sont des propriétés vérifiables. Un système peut en avoir cinq sur sept et être en production saine. En dessous de quatre, il y a une dette architecturale significative qui se manifestera au prochain pivot produit.

DDD et journal d'événements : le harnais symbolique

L'architecture qui part du métier, connue sous l'acronyme DDD (Domain-Driven Design), n'est pas une mode. C'est le résultat de vingt ans de consensus dans l'industrie sur comment structurer un logiciel de façon à ce qu'il reste modifiable. Appliqué à l'agentic engineering, DDD fournit le harnais symbolique dans lequel les agents opèrent : les périmètres métier bien délimités définissent ce que chaque agent peut voir et écrire, et les objets du domaine définissent le vocabulaire que les agents partagent avec les humains.

Le journal d'événements daté (event sourcing) — chaque changement enregistré comme un événement — complète ce harnais. Il ne s'agit pas d'un simple log applicatif. C'est une mémoire structurée dans laquelle chaque décision de l'agent peut être retracée, rejouée, et auditée. En cas d'anomalie, on ne cherche pas dans des logs textuels : on rejoue la séquence d'événements qui a mené à l'état erroné. La correction est alors chirurgicale.

Le neurosymbolisme : pourquoi le LLM seul ne suffit pas

Combiner apprentissage neuronal et raisonnement symbolique permet de produire des systèmes plus adaptables, transparents et alignés avec les exigences du génie logiciel moderne — non pas en remplaçant le jugement de l'ingénieur, mais en l'encodant structurellement.

— Mastropaolo & Poshyvanyk — A Path Less Traveled, FSE Companion 2025 (paraphrase)

L'approche qui combine apprentissage neuronal et raisonnement symbolique — appelée neurosymbolisme dans la littérature académique — résout précisément le point de fragilité du vibe coding. Un LLM seul produit du texte plausible, pas nécessairement correct. Couplé à un moteur de règles formelles (invariants de domaine, contraintes d'événements), il produit du texte correct et vérifiable. Mastropaolo et Poshyvanyk ont défendu cette voie en 2025, en montrant que la combinaison améliore la fidélité aux spécifications sur des tâches d'ingénierie logicielle structurées.

En pratique, ça signifie que les agents qui génèrent du code ou des décisions métier sont contraints par le modèle de domaine. Ils ne peuvent pas produire quelque chose qui viole un invariant. C'est la différence entre un agent qui suggère et un agent qui garantit.

MCP : le protocole de coordination entre agents et outils

Le protocole standard qui permet aux IA de parler aux outils — Model Context Protocol, dit MCP — est devenu en 2025-2026 l'infrastructure de coordination des systèmes multi-agents. Son adoption par Anthropic, puis par les principaux éditeurs d'outils de développement, a créé un standard de fait. Les agents peuvent désormais appeler des outils externes (bases de données, APIs, systèmes de fichiers, services métier) de façon structurée, avec des métadonnées d'appel explicites et un schéma de réponse formel.

Pour l'agentic engineering, MCP n'est pas anecdotique. Il rend les appels d'agents aux systèmes externes observables, rejouables et testables. On peut écrire des tests d'évaluation qui couvrent l'intégration complète — agent plus outil — sans mocking approximatif. La couverture des chemins critiques devient atteignable.

4 modes d'échec quand on passe du vibe coding à la production

1. Absence de modèle de domaine explicite : l'agent comprend le code mais pas le métier. Chaque nouveau besoin métier se traduit en régression dans un code non structuré.
2. Mémoire implicite dans les prompts : l'état du système est stocké dans des variables de session ou des prompts longs. Le premier redémarrage ou la première montée en charge efface l'état.
3. Effets de bord non médiatisés : l'agent appelle directement les APIs externes sans couche d'abstraction. Un changement de contrat API casse l'ensemble du système sans signal préalable.
4. Absence d'évaluation structurée : le comportement de l'agent est validé manuellement à la mise en production. Les régressions sur les cas limites ne sont détectées qu'en production réelle.

Ces quatre modes d'échec ne sont pas théoriques. Ils sont les raisons les plus fréquentes pour lesquelles des prototypes vibe-coded atteignent une mise en production partielle et restent bloqués là. Le passage à l'échelle requiert une refonte architecturale qui coûte systématiquement plus que si la structure avait été pensée dès le départ.

Le rôle de l'ingénieur ne rétrécit pas, il change

Une inquiétude légitime traverse les équipes techniques : si les agents génèrent le code, qu'est-ce qui reste pour l'ingénieur ? La réponse de l'agentic engineering est claire. L'ingénieur ne devient pas inutile — il monte d'un niveau d'abstraction. Son travail porte sur la définition des domaines, la formalisation des invariants, la conception des protocoles d'escalade, et l'évaluation du comportement des agents.

C'est un travail plus exigeant conceptuellement, pas moins. Il demande une compréhension fine du métier et une capacité à le formaliser de façon vérifiable par des machines. Les ingénieurs qui maîtrisent ça sont rares et leur valeur dans un contexte d'automatisation croissante augmente, elle ne diminue pas.

Les 5 métriques qui distinguent un système agentic-engineered

Cinq métriques permettent de mesurer objectivement où en est un système. La fidélité aux spécifications mesure si les agents produisent des résultats conformes au modèle de domaine défini. La couverture d'évaluation mesure le pourcentage des comportements critiques couverts par des tests d'évaluation automatisés. La résistance à la dérive mesure si le comportement reste stable sur une fenêtre glissante sans ajustement manuel. Le coût du changement mesure en heures le temps nécessaire pour ajouter une règle métier sans régression. L'auditabilité mesure si une décision passée peut être retracée en moins de dix minutes.

Un système vibe-coded en production a typiquement une couverture d'évaluation proche de zéro et un coût du changement qui croît linéairement avec le temps. Un système agentic-engineered vise une couverture d'évaluation supérieure à 80 % sur les chemins critiques, et un coût du changement stable. Ce ne sont pas des métriques de sprint : ce sont des propriétés architecturales.

Plan de transition en 5 étapes pour les équipes

1. Cartographier le domaine métier : identifier les périmètres bien délimités et les invariants non négociables avant de toucher au code. Cette étape prend 2 à 5 jours selon la complexité du domaine.
2. Extraire le modèle de domaine du code existant : si du code vibe-coded existe, refactoriser en isolant les entités et règles métier dans des modules indépendants du LLM.
3. Introduire le journal d'événements daté sur les flux critiques : commencer par les décisions à fort enjeu (transactions, modifications d'état irréversibles) avant d'étendre à l'ensemble du système.
4. Câbler MCP sur les intégrations externes : remplacer les appels directs aux APIs par des outils MCP avec schéma formel, pour rendre chaque appel testable et observable.
5. Construire la suite d'évaluation : écrire des tests d'évaluation qui couvrent les cas limites du domaine, pas seulement le chemin heureux. C'est cette suite qui garantit la fidélité aux spécifications dans le temps.

Ces cinq étapes ne sont pas séquentielles dans le sens où chacune doit être complète avant d'attaquer la suivante. Elles sont itératives : on peut commencer à introduire le journal d'événements sur un flux critique pendant qu'on cartographie un autre domaine. L'objectif est de progresser systématiquement vers les cinq métriques cibles, pas de tout refondre en une fois.

Conclusion : le vibe coding était une porte d'entrée

Le vibe coding a rendu le développement logiciel accessible à un spectre de personnes beaucoup plus large. C'est une contribution réelle. Il a aussi prouvé, à grande échelle et en conditions réelles, que générer du code n'est pas la même chose que construire un logiciel. L'agentic engineering n'est pas une réaction contre le vibe coding : c'est son prolongement naturel dans les contextes où la fiabilité, l'auditabilité et la maintenabilité ont une valeur économique. Ce qui était une exploration en 2024 est devenu une exigence en 2026.