Vibe Coding contre Agentic Engineering : ce que prône le nouveau document de Google sur le SDLC

De une devise à un livre blanc

Début 2025, Andrej Karpathy a esquissé un style de programmation où l’on se soumet entièrement aux tendances, on suit la courbe exponentielle et on cesse de se soucier de l’existence du code. Le cycle consistait à formuler une demande, l’accepter, l’exécuter, et en cas d’échec, à renvoyer le message d’erreur. Cette notion s’est répandue immédiatement, bien que les gens travaillent déjà de cette manière. Elle manquait simplement d’un nom.

Environ seize mois plus tard, Google a publié un document technique de 50 pages intitulé « The New SDLC With Vibe Coding », rédigé par Addy Osmani, Shubham Saboo et Sokratis Kartakis. Il est dense et bien structuré, et son message est percutant : le code vibe était adapté aux prototypes, mais il érode progressivement les systèmes de production, et de nombreuses équipes ne s’en rendent pas compte car les dommages s’accumulent peu à peu. Les sections suivantes présentent les arguments du document, sa ligne de démarcation claire et ses implications pour ceux qui développent avec des agents d’IA en 2026.

Pourquoi le code vibe a fonctionné, et où il s’arrête

Le code vibe a pris de l’ampleur parce qu’il a abaissé les barrières d’entrée. Les prototypes pouvaient être créés en quelques minutes, des non-ingénieurs pouvaient assembler des outils fonctionnels, et l’écart entre une idée et du code exécutable est passé de jours à heures. C’est précieux, et le rejeter relève du snobisme technique. Cependant, ce n’était jamais le problème principal ; c’est plutôt le plafond qui l’est.

Lorsque les agents sont devenus plus compétents, les équipes ont commencé à appliquer cette même habitude de prompt et d’acceptation informelle au travail en production, y compris aux API de paiement, à la logique d’authentification, aux pipelines de données et aux outils de santé. Le résultat a l’air propre et passe généralement les tests de base, ce qui permet de le mettre en ligne. Quelques semaines ou mois plus tard, quelque chose échoue d’une manière coûteuse et difficile à tracer.

La cause est structurelle. Le codage rapide visait à faire fonctionner quelque chose rapidement, et non à répondre aux exigences de fiabilité propres à la production ; il s’agit de objectifs différents. C’est en les mélangeant que naissent les problèmes actuels. Le document technique cherche à fournir aux équipes le vocabulaire et le cadre nécessaires pour cesser de les confondre.

Un spectre avec un seul facteur de division

Cet article présente un spectre allant du codage des ambiances d’un côté à l’ingénierie agente de l’autre. La plupart des praticiens se situent quelque part entre ces deux extrêmes, sans pouvoir préciser exactement où, ce qui fait lui-même partie du problème.

Ce spectre s’étend sur trois dimensions : la manière dont l’intention est spécifiée, le degré de rigueur de la vérification, et le profil de risque. Un seul facteur sépare ces extrêmes, et il ne s’agit ni du modèle utilisé, ni de l’ingéniosité des prompts, ni de l’outil choisi. Il s’agit plutôt de la façon dont les résultats sont vérifiés.

Deux types de vérifications sont nécessaires. Les tests déterministes vérifient si une fonction renvoie la bonne sortie pour une entrée donnée. Les évaluations de trajectoire vérifient si l’agent a suivi la bonne séquence d’étapes de raisonnement pour y parvenir. Sans l’un comme sans l’autre, on se contente de coder de manière approximative, aussi sophistiquée que puisse paraître la configuration. Un résultat impeccable et fluide qui a été obtenu sans vérification n’est pas un succès ; c’est même un échec plus dangereux que celui qui affiche une erreur, car il reste caché jusqu’à la mise en production. C’est là la ligne rouge, et cela explique pourquoi de nombreuses équipes disposant de workflows d’agents sophistiqués continuent techniquement de coder de manière approximative.

Le modèle n’est pas la variable principale

C’est probablement la reformulation technique la plus importante du rapport, et de nombreux développeurs se trompent à son sujet. Lorsqu’un agent se comporte mal, la réaction habituelle est de blâmer le modèle pour être trop faible, trop lent ou trop sujet aux hallucinations, en supposant qu’un modèle meilleur constitue la solution. Ce raisonnement est presque toujours erroné.

Le modèle n’est qu’une partie du système. Le reste, à savoir les prompts, les outils, les politiques de contexte, les environnements d’exécution sécurisés, les sous-agents et les mécanismes d’observabilité, forme le harness ; le comportement d’un agent dépend bien plus de ce harness que du modèle lui-même. Deux exemples tirés du rapport illustrent ce point. Sur Terminal Bench 2.0, une équipe a réussi à faire passer un agent de programmation de la 30e place environ à la 5e place en modifiant uniquement le harness. Dans une étude distincte menée par LangChain, des modifications apportées au prompt système, aux outils et au middleware, tout en conservant le même modèle, ont permis à un agent de programmation d’obtenir 13,7 points de plus dans les tests de référence.

Les fichiers de règles, les outils, les environnements de test, la logique d’orchestration, les mécanismes de contrôle et les capacités d’observation font tous partie de l’ensemble logiciel, et sa construction relève entièrement de l’équipe. Le fournisseur fournit le moteur, tandis que l’équipe construit autour de lui l’infrastructure nécessaire. Honnêtement, la plupart des défaillances des agents sont dues à des problèmes de configuration : un outil manquant, une règle vague, un mécanisme de contrôle absent, ou une fenêtre de contexte submergée de bruit. La faute est attribuée au modèle, car c’est la couche visible, alors que le véritable défaut réside dans l’ensemble logiciel. S’acharner sur les mises à jour du modèle tout en négligeant cet ensemble logiciel, c’est comme installer un moteur plus rapide sur une voiture sans freins.

Le génie du contexte remplace l’ingénierie des prompts

L’ingénierie des prompts en tant que discipline à part entière a pour l’essentiel disparu, laissant la place à l’ingénierie du contexte. Cela signifie fournir aux agents des informations riches et organisées concernant le code, l’architecture, les conventions et les objectifs dans lesquels ils travaillent. L’article énumère six types de contexte dont chaque agent a besoin : des instructions, des connaissances, de la mémoire, des exemples, des outils et des règles de contrôle. Chacun de ces éléments peut être statique, présent à chaque interaction, ou dynamique, fourni sur demande.

Le contexte statique est très coûteux, car chaque token est transmis avec chaque appel au modèle, que cela soit pertinent ou non. Un excès de tokens entraîne des gaspillages, affaiblit le signal et peut nuire aux performances en masquant des règles essentielles sous du bruit. Le contexte dynamique, quant à lui, est moins coûteux ; il provient de pipelines RAG, de déclencheurs de correspondance de tâches ou des résultats d’outils au moment où ils sont nécessaires. Choisir ce qui doit aller où constitue un compromis fondamental en ingénierie, et non une simple note de configuration ; il mérite donc une gestion par versions, des revues et les mêmes soins que les autres décisions de conception.

Le meilleur modèle à utiliser ici est celui des compétences d’agent : des ensembles structurés et portables de connaissances procédurales qui ne s’chargent que lorsque une tâche en a besoin. Au lieu d’intégrer des connaissances spécialisées directement dans le prompt du système, ces compétences permettent à l’agent de rester un généraliste léger qui devient un spécialiste lorsqu’on a besoin de ses compétences spécifiques. Un AGENTS.md bien conçu pour gérer cette frontière pourrait ressembler à ceci :

# Project: PaymentService API

## Architecture
- REST API, Node.js, PostgreSQL
- Never modify /src/core/billing without explicit approval

## Agent Skills (load on demand)
- skill:stripe-integration → load when task involves payments
- skill:database-migrations → load when task involves schema changes

## Hard Constraints
- No hardcoded credentials
- All new endpoints require integration tests before merge

La syntaxe exacte importe moins que l’idée d’intention codée sous forme de contrainte. L’agent apprend ce qu’il est, ce qu’il peut toucher, ce qui déclenche un comportement spécialisé et ce qui est interdit sans autorisation, et rien de tout cela n’a besoin d’être présent dans chaque fenêtre de contexte. C’est là la différence entre un agent qui reste fiable pour des centaines de tâches et un autre qui perd en efficacité après seulement une dizaine d’opérations.

Le piège des 80 %

Les agents peuvent écrire rapidement environ 80 % du code d’une fonctionnalité. Cette partie a tendance à paraître propre, à résister à un examen superficiel et à être déployée sans problème, ce qui permet au piège de se refermer. Ce sont les 20 % restants qui provoquent les pannes : cas limites, règles métier stockées dans l’esprit des personnes plutôt que dans des documents, points d’intégration entre des services développés il y a des années par des équipes distinctes, ainsi que des exigences de précision qui ne se manifestent qu’en conditions réelles de charge ou de comportement utilisateur.

La nature des erreurs liées à l’IA a également changé. Les premiers outils de programmation révélaient des erreurs de syntaxe évidentes que les revues pouvaient facilement détecter. Les agents actuels commettent des erreurs conceptuelles : hypothèses erronées concernant les règles métier, cas limites plausibles mais négligés, ainsi que des choix architecturaux qui engendrent des coûts cachés de maintenance à long terme. Le code semble correct et peut passer le jeu de tests, mais l’échec est structurel, différé et généralement bien plus coûteux à corriger qu’à prévenir.

C’est pourquoi l’évaluation de la trajectoire, c’est-à-dire l’examen du parcours de raisonnement de l’agent ainsi que de ses résultats, ne peut être omise dans les systèmes d’agents en production. L’évaluation des résultats vérifie si la fonction a renvoyé le bon résultat. L’évaluation de la trajectoire s’assure que l’agent a bien compris le problème avant d’écrire quoi que ce soit. Chacune de ces questions est importante, et se fier uniquement aux résultats permet aux 20 % les moins performants de passer. Les développeurs qui réussissent le mieux ne gagnent pas en vitesse en acceptant tout sans critique. Ils accélèrent en apportant leur propre jugement là où le jugement de l’IA est structurellement le plus faible : des exigences peu claires, des compromis architecturaux et la correction des erreurs aux frontières du système.

Modes conducteur et orchestrateur

Le document décrit deux modes de fonctionnement, et le passage d’un mode à l’autre peut représenter le changement de carrière le plus important sur le plan pratique dans l’ingénierie logicielle actuelle. Dans le mode conducteur, le développeur travaille en temps réel dans l’IDE, observant l’apparition du code, apportant des corrections et exerçant un contrôle fin sur chaque modification. Cela préserve l’intuition et le sens de la compréhension pour lesquels les ingénieurs sont formés. Le prix à payer est la vitesse de traitement, car gérer personnellement chaque interaction limite les avantages offerts par l’IA.

Le mode orchestrateur se situe à un niveau supérieur. Les développeurs définissent des objectifs, les transmettent aux agents et examinent les résultats obtenus, sans avoir à observer l’apparition ligne par ligne du code. Les agents travaillent en parallèle dans des environnements de test en arrière-plan, parfois pendant des heures, avant de renvoyer des demandes de fusion. Le développeur vérifie périodiquement les résultats et redirige le processus si nécessaire.

Le mode conducteur est en temps réel, interactif et implique un seul agent. Le mode orchestrateur est asynchrone, avec des agents parallèles et une demande de pull request comme résultat. La plupart des développeurs sont formés comme conducteurs, et le passage à l’orchestrateur représente un changement important de rôle.

Les compétences requises diffèrent également. Les conducteurs s’appuient sur une connaissance approfondie du langage et de la syntaxe, une capacité rapide de débogage, une compréhension fine du code et une interprétation en temps réel des erreurs. Les orchestrateurs, quant à eux, ont besoin de spécifications précises, d’une décomposition des tâches, d’une évaluation rapide des résultats ainsi que d’une conception de système, ce qui implique de définir les contraintes, les tests et les boucles de feedback permettant aux agents de fonctionner de manière fiable sans surveillance constante. De nombreux développeurs seniors sont de véritables conducteurs, et l’orchestration leur semble inconfortable car elle évoque un abandon du contrôle. C’est parfois le cas, il est donc nécessaire de mettre en place des infrastructures adaptées, une évaluation de la couverture et une ingénierie du contexte avant d’étendre les capacités d’orchestration. Déléguer sans mettre en place de mécanismes de vérification n’est pas de l’ingénierie : c’est du codage à grande échelle sans rigueur.

Une question d’économie

Cet article aborde le débat entre le codage des ambiances et l’ingénierie agente comme une question de coût et non de méthode. Le codage des ambiances ne coûte presque rien au départ : pas de discipline de spécification, pas d’infrastructure d’évaluation, pas de conception de framework, pas de maintenance de AGENTS.md. Pourtant, il génère rapidement des dettes opérationnelles cachées dues au gaspillage de tokens lié à des contextes non structurés, à une augmentation du nombre de bugs dus à des sorties non vérifiées, ainsi qu’à du temps perdu par les développeurs à cause d’échecs que les évaluations automatisées auraient dû détecter.

L’ingénierie agente exige un investissement réel et important dès le départ en termes de rigueur des spécifications, d’infrastructure d’évaluation, de conception de framework et d’architecture du contexte. Par la suite, le coût marginal par fonctionnalité diminue fortement, car chaque nouvelle capacité de l’agent réutilise le même framework, le même ensemble d’évaluations et la même architecture de contexte.

Pour un développeur travaillant sur un prototype ou un projet secondaire, le codage intuitif est clairement plus avantageux en termes de coûts. Aucun système de production n’a besoin d’être protégé, et la dette technique ne atteint jamais un niveau dangereux. Les équipes atteignent ce point de bascule plus tôt que prévu. Cinq ingénieurs qui utilisent le codage intuitif pendant trois mois peuvent facilement voir un tiers de leur capacité absorbé par le débogage et les corrections, des tâches que la vérification systématique aurait permis d’éviter. L’infrastructure agente rembourse ses coûts, à condition d’être mise en place avant que la dette technique ne dépasse son point de bascule.

Ce que l’étude confirme et ce qu’elle ne confirme pas

Cet article n’est pas une présentation commerciale. Il s’agit d’un document de cadre, et un des plus pratiques car ses principales affirmations peuvent être vérifiées. L’effet de « harness » est réel et mesurable, comme le montrent les benchmarks cités. Le problème des 80 % est réel et s’aggrave à mesure que les agents s’attaquent à des tâches plus difficiles. De plus, le passage du rôle de chef d’orchestre à celui d’orchestrateur a déjà lieu au sein de toutes les organisations d’ingénierie sérieuses à grande échelle.

La question de savoir où une équipe donnée devrait se situer sur cet éventail reste ouverte, apparemment intentionnellement, car cela dépend des enjeux, de la taille de l’équipe, de la pression des délais et du niveau de maturité technique, des facteurs que aucun cadre ne peut dicter. L’article fournit un vocabulaire et un modèle mental, mais c’est aux personnes de prendre la décision, ce qui est probablement la position la plus honnête possible.

La structure est scalable, mais pas les dynamiques. Les développeurs qui comprennent cela dès maintenant construisent sur des bases très différentes de celles de ceux qui l’apprendront à un coût élevé en production.