Vibe coding best practices : quand passer à l’agentic coding

Qu’est-ce que le vibe coding, et en quoi diffère-t-il de l’agentic coding ?

Dans nos articles précédents, nous avons présenté une à une les pièces d’un agent de codage : les hooks, les subagents, les skills, les worktrees, l’auto mode et la sandbox. Cet article les réunit autour d’une seule question : que faut-il pour bien faire du vibe coding, et où tombe-t-on dans le piège ? Nous présentons chaque habitude en quelques mots, avec un lien vers l’article qui la détaille.

Le terme vient d’Andrej Karpathy, sur X, le 2 février 2025. Dans son message, tel que Wikipédia le cite, il décrivait sa façon de travailler : il acceptait chaque modification avec « Accept All », ne lisait plus les diffs et recollait les messages d’erreur à l’agent sans un mot. Selon ses propres termes, ce n’était pas si mal pour des projets du week-end qu’on jette ensuite. En somme, le vibe coding consiste à faire écrire du code à l’IA sans le lire et à ne regarder que le résultat.

L’article de Simon Willison du 6 mai 2026 trace clairement la limite. Pour lui, le vibe coding, c’est travailler sans jamais regarder le code : vous ne savez peut-être même pas programmer, vous dites ce que vous voulez, et si ça marche, c’est bon. Dans un outil que vous êtes seul à utiliser, dont les bugs ne touchent que vous, il n’y a pas de problème. Si vous construisez un logiciel pour d’autres, en revanche, le vibe coding est « grossly irresponsible », parce que ce sont les autres qui subissent vos bugs. L’agentic engineering en est l’autre extrémité : un ingénieur logiciel qui maîtrise la sécurité, la maintenabilité, l’exploitation et la performance utilise ces outils. Les outils eux-mêmes sont appelés outils d’agentic coding : selon la définition d’Anthropic, un agent qui lit le code, modifie des fichiers et exécute des commandes. L’agentic coding est donc la façon de travailler où l’agent écrit et exécute le code de lui-même ; entre vibe coding et agentic engineering, la différence tient à ce que vous lisiez ou non le résultat et que vous en preniez la responsabilité.

Les conseils de cet article reposent eux aussi sur cette limite. Dans un outil pour vous seul, un prototype ou pour apprendre quelque chose, le vibe coding ne pose pas de problème. En revanche, du code que d’autres utilisent, qui stocke des données d’utilisateurs ou qui gère des connexions ou des paiements ne se publie pas sans avoir été lu. Les habitudes qui suivent rapprochent le vibe coding d’un agentic coding dont quelqu’un a pris la responsabilité.

En français aussi, le terme s’emploie le plus souvent en anglais. Si vous cherchez le nom général de la programmation avec l’IA, c’est le codage assisté par IA (AI-assisted coding) ; le vibe coding en est l’extrémité où personne ne lit le code. Deux autres termes sont souvent confondus avec lui. Le spec-driven development en est presque l’inverse : l’agent écrit une spec, un plan et une liste de tâches avant le code. Le harness engineering est un autre sujet : il décrit la structure que vous construisez autour du modèle.

Qu’est-ce qui a changé dans les outils de codage cet automne ?

En septembre et en octobre, les cinq outils ont changé dans le même sens : l’agent vous demande moins, travaille seul plus longtemps et davantage en parallèle. D’après les notes de version :

Source : notes de version des outils, 21 octobre 2026. Versions : Claude Code 2.1.284 et 2.1.286, Codex CLI 0.162.0, Antigravity CLI 1.3.5 ; la ligne Copilot vient des versions de septembre de VS Code. Le 18 juin 2026, Google a fermé Gemini CLI aux abonnés Google AI Pro et Ultra ainsi qu’aux utilisateurs gratuits, et l’a remplacé par Antigravity CLI ; les entreprises et ceux qui utilisent une clé d’API payante peuvent continuer à utiliser Gemini CLI.

La direction commune est claire : l’agent mène une tâche plus loin sans vous demander. De toute façon, on répondait le plus souvent oui aux demandes d’approbation sans les lire ; nous avons présenté les mesures des éditeurs à ce sujet dans l’article sur l’auto mode et la sandbox. Le vrai contrôle doit se trouver dans la boucle de l’agent et fonctionner même quand vous ne regardez pas : un test, un hook, la CI. C’est exactement ce que fait le changement verify de Claude Code : avant le commit, il fait lancer la vérification que vous avez écrite.

Que disent les études sur les applications faites en vibe coding ?

Trois études ont été publiées ou mises à jour en août et en septembre ; toutes trois sont sur arXiv, sous forme de preprints qui n’ont pas été évalués par des pairs. La plus grande est l’étude de Deng, Fan et Meng ; sa dernière version date du 14 septembre 2026. Les chercheurs ont rassemblé 9 041 applications open source écrites avec Claude Code et Lovable, ont audité les 200 d’entre elles qui étaient en ligne et y ont trouvé 1 186 vulnérabilités. Des auditeurs IA ont d’abord repéré les vulnérabilités candidates ; deux auteurs compétents en sécurité ont ensuite examiné chacune séparément, et elle n’était retenue comme vulnérabilité que si tous deux la jugeaient exploitable.

Résultat : 91 % des applications avaient au moins une vulnérabilité, et 65,77 % des vulnérabilités étaient de gravité critique ou élevée. Elles se concentrent dans le contrôle d’accès (broken access control), l’injection et l’authentification. Le contrôle d’accès, c’est la partie qui garantit qu’un utilisateur n’accède qu’à ses propres données ; s’il manque, l’application fonctionne quand même, et une démo ne le montre donc pas.

Les chercheurs ont aussi reproduit une partie de ces vulnérabilités pour voir ce qui aide. Deux choses les ont le plus réduites : un prompt qui fait du code prêt pour la production une condition pour que la tâche soit considérée comme finie, et un harness auquel on a ajouté des contrôles de sécurité. Mais aucune configuration ne les a toutes supprimées. Un autre résultat frappe : dans 90 des 434 exécutions où une vulnérabilité a été déclenchée (20,7 %), l’agent a repéré le risque lui-même et a quand même écrit le code non sécurisé ; souvent, il a laissé un avertissement ou un commentaire au lieu de corriger. Que l’agent connaisse le risque ne suffit pas ; la vérification doit tourner avant que la tâche soit finie.

L’étude d’Andročec du 21 août 2026 pose une question modeste mais directe. Elle a fait écrire deux fois chacune des 6 applications web, d’une seule traite, par le même agent avec le même modèle. La seule différence entre les deux prompts était une section d’exigences de sécurité ajoutée à la fin du second. La version avec exigences de sécurité comptait moins de constats confirmés dans chaque application (24 contre 51), et aucun n’était critique ou élevé. Le constat le plus grave, lui, n’a été détecté que par un test manuel. L’auteur le précise lui-même : l’échantillon est petit et chaque version n’a été générée qu’une fois ; les résultats sont des observations, pas un effet statistique.

L’étude de Kraishan (12 septembre 2026) regarde ailleurs : que deviennent les pull requests des agents après le merge ? Elle a comparé 37 623 pull requests de cinq agents commerciaux à celles d’humains dans les mêmes dépôts. Le résultat est « vendor-specific rather than uniform » : dans les 90 jours suivant le merge, le taux de revert de 3 des cinq agents ne se distinguait pas statistiquement de celui des humains ; l’un était annulé moins souvent, un autre plus souvent. Les motifs suspects comme des identifiants écrits en dur ou eval apparaissaient moins souvent dans le code des agents que dans celui des humains ; mais c’est une recherche de motifs, pas des vulnérabilités confirmées. Les données vont de décembre 2024 à juillet 2025 ; elles ne disent rien du classement des outils et des modèles d’aujourd’hui. Nous avons expliqué comment lire ce genre de comparaison dans l’article sur SWE-bench.

Les développeurs, eux aussi, font surtout confiance à ce qu’ils peuvent vérifier. Dans l’enquête 2026 de Stack Overflow, publiée le 6 octobre (plus de 30 000 participants ; pas un échantillon aléatoire mais des réponses volontaires), 48 % des participants ont dit faire confiance à l’IA quand ils peuvent facilement vérifier sa réponse. La plupart des habitudes ci-dessous servent justement à faciliter cela.

Sur quoi les guides des cinq outils sont-ils d’accord ?

Les cinq outils ont chacun leur guide de bonnes pratiques. Le 21 octobre 2026, nous les avons tous lus et avons mis côte à côte leurs conseils sur un même sujet. Pour Copilot, nous avons lu ensemble trois guides de GitHub (VS Code, Copilot CLI et l’agent cloud) ; celui de Cursor est un article de blog daté du 9 janvier 2026, les autres ne sont pas datés. Dans combien de guides figure chacune des six habitudes :

Les cinq guides se rejoignent sur 3 habitudes. Les 3 autres figurent dans 4 guides ; le guide d’Antigravity CLI n’en parle pas, mais il recommande de lancer des subagents en parallèle en arrière-plan sur les gros travaux, et la CLI a une vue /diff qui montre les changements. Ce que dit chaque guide :

Source : guides de bonnes pratiques des cinq outils, 21 octobre 2026. La colonne Copilot vient des guides de VS Code, de Copilot CLI et de l’agent cloud de Copilot. Chaque cellule reprend en bref la phrase du guide. « Absent de son guide » : nous n’avons trouvé aucune phrase qui le dise dans le guide lu ce jour-là ; cela peut figurer dans d’autres documents de l’outil.

Vérification. L’agent s’arrête quand la tâche a l’air finie. Selon le guide de Claude Code, sans vérification qu’il peut lancer, « looks done » est le seul signal dont il dispose, et chaque erreur attend que vous la remarquiez. Tests, build, linter ou script qui compare la sortie à un exemple : tout ce qui se lit comme réussi ou échoué fait l’affaire. Quand l’agent dit « les tests passent », demandez la commande qu’il a lancée et sa sortie. L’agent peut vérifier une interface dans le navigateur ; nous avons expliqué comment en faire un test Playwright durable dans l’article sur computer use.

Plan. Le plan évite que l’agent résolve le mauvais problème. Le guide de Claude Code dit aussi quand s’en passer : si vous pouvez décrire le diff en une phrase, inutile ; si vous hésitez sur l’approche, si le changement touche plusieurs fichiers ou si vous ne connaissez pas le code, faites établir un plan. Le guide de Cursor juge lui aussi qu’on peut passer directement à l’agent pour les petites tâches qu’on a déjà faites souvent. Pour une grosse fonctionnalité, l’étape au-delà du plan est une spec ; nous avons expliqué quand elle aide dans l’article sur le spec-driven development.

Fichier de règles. Codex et Cursor recommandent la même voie : commencer court et ajouter une règle quand l’agent répète une erreur. Le guide de Codex dit que, lorsque l’agent fait deux fois la même erreur, il faut lui demander une rétrospective et mettre à jour AGENTS.md. Nous avons expliqué quel outil lit quel fichier dans l’article sur AGENTS.md et CLAUDE.md. Pour une règle qui doit s’appliquer à chaque fois, un fichier ne suffit pas ; selon le guide de Claude Code, une instruction est un conseil, alors qu’un hook s’exécute à chaque fois (l’article sur les hooks). Un prompt que vous répétez sans cesse peut devenir un skill. Le même fichier sert aussi à la review. Notre outil de revue de code par IA, diffox, lit l’AGENTS.md du dépôt (ou, à défaut, le CLAUDE.md) sur la branche dans laquelle la pull request sera fusionnée quand il examine la pull request. Il se sert des phrases qui expriment une obligation (comme « must », « never », « doit », « jamais ») comme des règles qui définissent ce qui compte comme un défaut.

Lire le changement. Le guide de Cursor en donne la raison en peu de mots : le code écrit par l’IA peut avoir l’air juste et être faux sur un détail, et plus l’agent va vite, plus la review compte. Le guide de Claude Code recommande de faire la review dans un contexte neuf : un subagent qui ne voit que le diff et les critères n’est pas influencé par le raisonnement de la session qui a écrit le changement. Nous avons expliqué comment fonctionne un subagent dans l’article sur les subagents, et ce qu’un humain doit regarder dans l’article sur l’examen du code généré par l’IA.

Travail en parallèle. Deux agents qui travaillent dans le même dossier peuvent modifier les fichiers l’un de l’autre. Le guide de Codex range parmi les erreurs le fait de lancer des tâches parallèles sur les mêmes fichiers sans worktrees ; Claude Code, Cursor et Copilot recommandent aussi de lancer chaque session dans son propre worktree ou dossier. Nous avons expliqué ce qu’un worktree sépare et ce qu’il ne sépare pas dans l’article sur git worktree.

Session propre. Plus la conversation s’allonge, plus le contexte se remplit de détails sans rapport, et les performances de l’agent baissent. Le guide de Claude Code conseille, si l’agent se trompe encore après deux corrections sur le même point, de vider la session et de repartir avec un meilleur prompt qui intègre ce que vous avez appris. Nous avons expliqué ce que fait perdre le résumé sur une longue tâche dans l’article sur l’auto-compact.

Sur quoi les guides divergent-ils ?

Les guides ne disent pas la même chose sur tout. Ils divergent sur quatre points ; le bon choix pour vous dépend de votre travail.

• Combien de détails donner au départ ? Codex demande quatre choses dans chaque prompt : l’objectif, le contexte, les contraintes et le moment où la tâche est considérée comme finie. Le guide de l’agent cloud de Copilot demande une description claire, des critères d’acceptation complets et les fichiers à modifier, mais ajoute que, même sans chemin de fichier, l’agent trouve souvent le bon code tout seul. Claude Code demande aussi de citer les fichiers, les contraintes et des exemples de motifs. Cursor, lui, dit de mentionner le fichier si vous le connaissez et de laisser l’agent le trouver sinon ; des fichiers sans rapport peuvent l’embrouiller.
• Faut-il corriger tous les constats d’une review ? Le guide de Claude Code prévient : un relecteur à qui l’on demande de trouver des manques en trouve généralement, même quand le travail est solide. Courir après chaque constat mène à des couches inutiles, à du code défensif et à des tests pour des cas impossibles. Le guide recommande de ne faire signaler au relecteur que les manques qui touchent la justesse du code ou les exigences énoncées. Les guides de Cursor et de Copilot présentent les outils de review sans cet avertissement.
• Quand automatiser ? Le guide de Codex range parmi les erreurs le fait de planifier une tâche récurrente qui ne marche pas encore de façon fiable à la main : en faire d’abord un skill, puis la planifier une fois qu’elle est prévisible. Les nouveautés de cet automne rendent pourtant la planification plus facile ; les automatisations de Copilot et Projects de Cursor peuvent lancer des tâches sans que vous le demandiez. Avant de les activer, posez la question de Codex : cette tâche marche-t-elle de façon fiable à la main ?
• Quelles tâches ne pas confier à l’agent ? Le seul guide qui le dit clairement est celui de Copilot. Il liste les tâches que vous préférerez peut-être faire vous-même plutôt que de les confier à l’agent : les problèmes critiques en production ; les travaux qui touchent à la sécurité, aux données personnelles ou à l’authentification ; les tâches mal définies et les sujets que vous voulez apprendre vous-même. Les quatre autres guides n’ont pas de liste de ce genre.

Quels sont les pièges du vibe coding ?

Deux guides listent aussi les erreurs courantes : celui de Claude Code en compte 5, celui de Codex 8. Voici où les deux listes se recoupent : mener toutes les tâches dans une seule longue session, ne pas donner à l’agent de moyen de vérifier son travail, et mettre les règles au mauvais endroit (pour Claude Code, gonfler CLAUDE.md ; pour Codex, réécrire des règles durables dans chaque prompt). Une phrase de la liste de Claude Code résume presque cet article : si vous ne pouvez pas le vérifier, ne le livrez pas.

Nous sommes nous-mêmes tombés dans les cinq pièges ci-dessous en travaillant avec des agents de codage dans notre propre dépôt ; après chacun, nous avons écrit une règle dans le fichier de règles du dépôt. Ils viennent tous d’un seul dépôt, ce n’est donc pas une statistique ; mais derrière chacun il y a une vraie erreur. Les questions que nous posons quand l’agent dit « terminé » :

• Le test qui passe en local passe-t-il aussi en CI ? Chez nous, l’environnement local différait de la CI à plusieurs endroits : un fichier .env lu en local, un paquet installé autrement en CI et une vérification qui ne tourne qu’en CI. Supprimer des variables d’environnement n’empêchait pas la lecture du fichier .env ; une option d’installation manquante a en plus fait apparaître en rouge une branche correcte et conduit à un mauvais diagnostic. Notre règle aujourd’hui : un résultat local n’est jamais présenté comme un résultat de CI, un échec de CI se reproduit dans un clone propre sans .env, et après un push on regarde la CI elle-même.
• Le résultat est-il vide parce que l’étape a tourné ? Dans l’un de nos enregistrements, une exécution propre et une exécution dont une partie des étapes avait échoué paraissaient identiques ; toutes deux laissaient une liste de constats vide. Désormais, l’enregistrement garde aussi si les étapes ont tourné et combien de résultats elles ont produits ; un résultat vide et une étape morte se distinguent en lisant l’enregistrement. Si vous voyez dans le code de l’agent une ligne qui intercepte une erreur et renvoie une liste vide, posez la même question.
• Une valeur absente a-t-elle été lue comme 0 ? L’un de nos rapports a lu comme 0 une valeur jamais mesurée et a écrit « 100% saving » à côté d’un travail réellement effectué ; la même erreur a aussi désactivé une vérification sans que personne le remarque. Une valeur non mesurée doit rester None et se lire en vérifiant si la clé existe :

# Exemple : une valeur non mesurée doit être None, pas 0
seconds = record.get("seconds") or 0   # faux : sans la clé, on obtient 0
seconds = record["seconds"] if "seconds" in record else None   # juste

or 0 transforme en zéro aussi bien une clé absente que None. Ce zéro entre ensuite dans une moyenne ou un seuil et fait passer un travail jamais mesuré pour gratuit ou réussi.

• Le .env s’est-il affiché à l’écran ? Une fois, nous avons affiché le fichier .env masqué avec sed. Comme toutes les lignes n’ont pas la forme KEY=value, le masque a sauté une ligne, et la clé qu’elle contenait est apparue en clair. Désormais, nous demandons à l’environnement si une clé existe, pas au fichier ; le contenu du fichier ne s’affiche pas, même masqué. Nous avons expliqué quels outils empêchent d’emblée l’agent de lire les fichiers secrets dans l’article sur la sandbox.
• Le chemin, l’adresse ou le paquet cité existe-t-il vraiment ? L’une de nos notes de mesure citait comme source un dossier qui n’existe sur aucune branche. Dans un brouillon qui complétait des noms de fichiers abrégés, la plupart des noms complétés étaient faux. Désormais, un outil vérifie que chaque chemin d’une ligne de source existe sur le disque ; l’outil qui construit ce blog refuse lui aussi un chemin de source qu’on ne peut pas ouvrir. Nous avons expliqué pourquoi vérifier à part les paquets que l’agent propose dans l’article sur l’examen du code.

Ce que les cinq ont en commun, c’est l’écart entre « terminé » et « a l’air terminé ». Le conseil du guide de Claude Code vaut ici aussi : demandez à l’agent la preuve de la réussite, pas son affirmation ; la commande qu’il a lancée et la sortie qu’il a obtenue.

Quelles habitudes pour quel type de travail ?

Toutes les tâches n’ont pas besoin de toutes les habitudes. Pour un correctif d’une phrase, vous pouvez sauter le plan ; pour du code qui touche aux données des utilisateurs, vous ne pouvez pas sauter la relecture. En gros, il y a quatre situations :

Chaque situation en détail, et quelques cas particuliers :

• Un outil ou un prototype pour vous seul. Comme le dit Willison, si un bug ne touche que vous, le vibe coding ne pose pas de problème. Faites quand même des commits fréquents pour pouvoir revenir en arrière, et mettez les clés dans l’environnement, pas dans le code.
• Un petit correctif dans un vrai dépôt. Sautez le plan mais pas la vérification ; le diff est court, sa lecture aussi. Si vous corrigez un bug, suivez l’ordre du guide de Claude Code : d’abord un test qui reproduit le bug et échoue, ensuite le correctif.
• Une fonctionnalité sur plusieurs fichiers ou du code que vous ne connaissez pas. D’abord un plan, et une spec pour un gros travail ; faites écrire les tests avant le code et relire le changement dans un contexte neuf. Nous avons expliqué quand un modèle haut de gamme et un effort plus élevé font la différence sur des tâches longues et floues dans les articles sur le choix du modèle et sur l’effort.
• Exécutions sans surveillance et agents en parallèle. En auto mode, avec un agent cloud ou dans une tâche planifiée, personne n’est là pour répondre. Mettez la vérification dans un hook ou dans la CI, gardez des permissions étroites, activez la sandbox, donnez à chaque agent son propre worktree, et à la fin demandez une preuve, pas une affirmation. Nous avons présenté les permissions et la sandbox dans l’article sur l’auto mode et la sandbox.
• Données des utilisateurs, connexion, paiement et secrets. Écrivez explicitement les exigences de sécurité dans le prompt ; dans l’étude d’Andročec, ajouter seulement cela a réduit les constats dans chaque application. Mais le constat le plus grave, c’est encore un test manuel qui l’a détecté : faites lire ce code par un humain.
• Avant d’ouvrir à tous une application faite en vibe coding. Les vulnérabilités trouvées par Deng et ses collègues se situent surtout dans le contrôle d’accès et l’authentification. Essayez vous-même : un utilisateur peut-il voir les données d’un autre, et peut-on atteindre une page protégée sans se connecter ?
• Un dépôt que vous ne connaissez pas. Avant de l’ouvrir avec un agent, cherchez les fichiers qui peuvent s’y exécuter d’eux-mêmes ; nous avons expliqué lesquels dans l’article sur le workspace trust.