Vibe coding vs agentic engineering : où est vraiment la ligne (et pourquoi elle s'efface)
La réponse courte
La ligne entre vibe coding et agentic engineering ne passe pas par l'outil : les deux utilisent les mêmes agents IA. Elle passe par votre rapport à la responsabilité du code livré. Vous faites du vibe coding quand vous acceptez la sortie de l'IA sans forcément la lire ni la comprendre — c'est quality-agnostic, vous pilotez au feeling et au résultat. Vous faites de l'agentic engineering quand vous restez responsable de chaque ligne qui part en prod : vous relisez, vous testez, vous comprenez l'architecture, vous répondez des bugs. Même clavier, même modèle, deux relations différentes au risque.
Et cette ligne s'efface. Simon Willison observe (mai 2026) qu'à mesure que les agents deviennent fiables, même les pros arrêtent de relire chaque ligne. Il appelle ça une normalization of deviance : chaque fois qu'on saute la relecture et que rien ne casse, sauter la relecture devient la nouvelle norme — jusqu'au jour où ça casse. Rester du bon côté ne veut pas dire refuser l'IA ni relire chaque caractère : ça veut dire calibrer la relecture sur le risque réel de ce que vous expédiez. Un prototype jetable et un service de paiement ne demandent pas la même vigilance. Le reste de cet article pose les définitions, la frontière, et une méthode simple pour ne pas glisser sans s'en rendre compte.
Définir les deux termes, sans mépris
Le débat traîne beaucoup de mépris de classe : le « vrai » dev contre le « touriste » qui prompt. On va éviter ça, parce que c'est faux et inutile.
Vibe coding : vous décrivez une intention, l'IA génère, vous regardez si « ça marche », vous itérez. Vous ne relisez pas forcément le code, parfois vous ne le lisez pas du tout. C'est quality-agnostic par définition — la qualité interne n'est pas le critère, le résultat visible l'est. Et c'est parfaitement légitime pour un prototype, un script perso, un jetable, une démo du week-end.
Agentic engineering : vous utilisez exactement les mêmes agents, mais vous gardez la main sur ce qui compte. Vous relisez les diffs, vous écrivez ou exigez des tests, vous surveillez l'architecture, vous savez expliquer ce que fait chaque morceau et pourquoi. L'IA accélère ; elle ne vous décharge pas de la responsabilité.
La distinction n'est donc ni le niveau du dev, ni la quantité de code écrite à la main. C'est la question : est-ce que je réponds de ce code ?
Où passe vraiment la ligne
Un seul test la révèle : seriez-vous capable de défendre ce code en revue, et voulez-vous en répondre en prod ? Si oui, vous êtes du côté ingénierie, même si l'agent a tout tapé. Si vous ne pourriez pas expliquer ce que fait le code — et que ça ne vous gêne pas — vous êtes en vibe coding.
| Vibe coding | Agentic engineering | |
|---|---|---|
| Objectif | Un résultat qui marche, vite | Un système qu'on maîtrise et qu'on maintient |
| Rapport au code | Quality-agnostic : relecture optionnelle | Responsable de chaque ligne livrée |
| Relecture | Au feeling, souvent zéro | Calibrée sur le risque |
| Qui répond des bugs | L'IA, le hasard, personne | Vous |
| Bon terrain | Prototype, jetable, perso, démo | Prod, équipe, données réelles, argent |
Aucune des deux colonnes n'est « mauvaise ». Le problème n'apparaît que quand on exécute la colonne de gauche sur le terrain de la colonne de droite : livrer du code non compris dans un système qui gère de vrais utilisateurs, de vraies données, de vrais paiements.
Pourquoi la frontière s'efface (le point de Simon Willison)
Voici l'observation qui rend le sujet brûlant en 2026. Simon Willison note (mai 2026) que la frontière se brouille non pas parce que les débutants montent en compétence, mais parce que les experts descendent leur garde. Les agents sont devenus assez bons pour que relire chaque ligne paraisse une perte de temps la plupart du temps.
Le mécanisme qu'il nomme, la normalization of deviance, est emprunté à la sociologie des accidents industriels : une entorse à la règle qui ne provoque aucun incident finit par ne plus être perçue comme une entorse. Appliqué à notre métier :
- Vous acceptez un diff sans le lire. Rien ne casse.
- Vous le refaites. Toujours rien.
- Au bout de cinquante fois, « accepter sans lire » n'est plus une exception assumée : c'est votre process par défaut.
- La cinquante-et-unième fois, l'agent introduit une faille silencieuse, une régression subtile, une fuite. Et là, personne ne l'a vue passer.
Le piège est vicieux parce que le renforcement est positif à court terme : sauter la relecture est récompensé (plus rapide, ça marche) exactement jusqu'au moment où ça ne l'est plus. C'est pour ça qu'on peut glisser du bon côté vers le mauvais sans jamais décider de le faire.
Comment rester du bon côté sans devenir insupportable
La mauvaise réponse serait « relis toujours tout ». Personne ne le fera, et ce n'est même pas rationnel. La bonne réponse est de rendre la relecture proportionnelle au rayon de souffle (blast radius) du code. Concrètement :
- Classez par zone de risque. Un helper d'affichage jetable ≠ un middleware d'auth ≠ une migration de base ≠ une logique de facturation. Plus le rayon de souffle est grand, plus la relecture doit être serrée. La relecture zéro est un choix valide — sur les zones à rayon nul.
- Verrouillez les tests là où ça compte. Un test qui échoue est une relecture qui ne dépend pas de votre vigilance du jour. C'est le meilleur rempart contre la normalisation de la dérive, parce qu'il ne s'use pas.
- Nommez le moment où vous sautez la relecture. Le danger, ce n'est pas de sauter la relecture, c'est de le faire sans le savoir. « Là je merge sans lire, c'est un jetable » est sain. Le merge automatique silencieux sur du code prod ne l'est pas.
- Gardez la capacité d'expliquer. Si vous ne pourriez pas dire à un collègue ce que fait ce module et pourquoi, vous avez déjà franchi la ligne, quel que soit votre niveau.
- Faites de la revue une porte, pas une politesse. Sur les zones critiques, un humain qui répond du code doit l'avoir compris avant le merge — agent ou pas.
Aucune de ces règles n'exige de renoncer aux agents ni de ralentir sur le code sans enjeu. Elles déplacent juste l'effort là où il paie.
Le vrai enseignement
La ligne n'est pas une identité (« je suis un vrai dev / je suis un vibecodeur »), c'est une posture que vous choisissez, fichier par fichier. Le même développeur vibe-code son script de config le matin et fait de l'agentic engineering rigoureux sur le service de paiement l'après-midi — et c'est très bien. Ce qui abîme la prod, ce n'est pas le vibe coding : c'est le vibe coding appliqué par défaut, sans s'en apercevoir, là où il fallait de l'ingénierie. La seule discipline qui tienne en 2026, c'est de savoir de quel côté vous êtes à l'instant où vous appuyez sur « merge ».
FAQ
Le vibe coding, c'est mauvais ? Non. Pour un prototype, un jetable, un script perso ou une démo, c'est même l'usage optimal des agents. Le problème n'est pas le vibe coding : c'est de l'appliquer, sans le décider, à du code de production que vous ne comprenez pas.
Comment savoir de quel côté de la ligne je suis ? Posez-vous une question : « Pourrais-je expliquer ce que fait ce code, et voudrais-je en répondre en revue et en prod ? » Si oui, vous êtes en ingénierie, même si l'agent a tout écrit. Si non, et que ça ne vous gêne pas, vous vibe-codez.
Si les agents sont fiables, relire n'est-il pas une perte de temps ? C'est exactement le piège que décrit Simon Willison (mai 2026) : la normalization of deviance. La fiabilité récompense le fait de sauter la relecture… jusqu'à l'incident que personne n'a vu venir. La parade n'est pas de tout relire, mais de calibrer la relecture sur le rayon de souffle du code.