Vibe Coding, C'est Quoi ? Le Guide pour Superviser un Agent en Direct

Vibe coding, c'est quoi exactement ?

Le vibe coding désigne une manière de travailler où un agent IA écrit le code à votre place. Vous décrivez ce que vous voulez en phrases normales, l'agent propose une version, et vous jugez le résultat en le testant plutôt qu'en relisant chaque ligne comme vous le feriez pour un collègue humain.

Le terme vient d'un message posté par Andrej Karpathy sur X le 2 février 2025. Karpathy, cofondateur d'OpenAI, y décrit une pratique où l'on se laisse porter par les suggestions de l'agent, où l'on accepte les changements sans toujours les comprendre dans le détail, et où l'on finit par presque oublier que le code existe en tant que texte qu'on pourrait lire soi-même.

Le mot a rapidement été repris ailleurs. Merriam Webster l'a listé comme expression en vogue en mars 2025, et le Collins English Dictionary en a fait son mot de l'année 2025, annoncé le 6 novembre 2025. Ce n'est donc pas un mot marginal, c'est devenu le nom standard de cette façon de travailler.

• Origine : un message d'Andrej Karpathy sur X, le 2 février 2025.
• Idée centrale : guider l'agent, juger par le résultat, pas par la relecture.
• Reconnaissance : mot de l'année 2025 selon le Collins English Dictionary.

Pourquoi 'en direct' change le problème

Faire du vibe coding en direct veut dire que les décisions se prennent au moment où l'agent agit, pas après coup pendant une revue de code classique. Il n'y a pas de pause naturelle où quelqu'un relit tout avant que le changement parte en production.

C'est exactement ce que décrivait Karpathy : la vitesse vient du fait qu'on ne s'arrête pas pour tout vérifier. Le problème, c'est que cette vitesse s'applique aussi bien à un changement anodin qu'à un changement qui supprime un fichier important ou expose une clé API. L'agent ne fait pas la différence tout seul entre les deux.

Cela ne veut pas dire que le vibe coding en direct est forcément imprudent. Cela veut dire que la prudence doit être construite autrement : pas par une relecture ligne par ligne, mais par des limites fixées avant que l'agent ne commence, et par un signal clair de ce qu'il fait pendant qu'il travaille.

• Le vibe coding en direct ne laisse pas de pause pour une relecture classique.
• La même vitesse s'applique à un changement anodin et à un changement dangereux.
• L'agent ne distingue pas les deux sans qu'on le lui demande explicitement.

Ce que vos outils de terminal demandent avant d'agir

Claude Code demande votre accord par défaut avant de modifier quoi que ce soit. Un bac à sable séparé existe pour les commandes shell, basé sur Seatbelt, le mécanisme d'isolement de macOS, mais il reste désactivé jusqu'à ce que vous l'activiez vous-même.

Codex CLI fonctionne différemment : au lieu de demander à chaque commande, il vous fait choisir un mode au départ, lecture seule, écriture dans le dossier de travail, ou accès complet, chacun avec ses propres limites.

GitHub Copilot CLI, qui tourne aussi sur Mac, demande également votre accord par défaut avant d'utiliser un outil qui modifie ou exécute quelque chose, avec la possibilité d'autoriser ou de refuser certaines commandes à l'avance.

• Claude Code : accord demandé par défaut, bac à sable Seatbelt désactivé au départ.
• Codex CLI : un mode choisi au départ, pas une demande à chaque commande.
• GitHub Copilot CLI : accord demandé par défaut, avec des listes d'autorisation possibles.

Superviser sans tout relire

Superviser un agent en direct ne veut pas dire relire chaque ligne qu'il écrit, ce serait contraire à l'idée même du vibe coding. Cela veut dire savoir à tout moment si l'agent travaille encore, s'il est bloqué, et ce qu'il a touché depuis la dernière fois que vous avez regardé.

Concrètement, cela passe par trois choses : limiter les dossiers que l'agent peut atteindre, garder un œil sur ce qu'il modifie sans tout lire mot à mot, et relire le diff final avant de l'accepter, même si le reste du travail s'est fait sans relecture.

C'est une discipline différente de la revue de code classique, pas une version allégée de celle-ci. L'objectif n'est pas de tout comprendre avant d'accepter, mais de savoir où se trouve la limite que l'agent n'a pas le droit de franchir, et de la vérifier une fois le travail terminé.

• Limiter les dossiers accessibles plutôt que tout permettre par défaut.
• Garder un signal clair de ce que l'agent fait, sans tout lire en détail.
• Relire le diff final avant de l'accepter, systématiquement.

Comment Forkbench s'intègre, et ce qu'il ne fait pas

Forkbench est une application de bureau pour Mac qui fait tourner vos agents de code dans de vrais terminaux. Chaque onglet a un pouls en direct qui s'accélère quand l'agent travaille plus fort, calculé à partir du CPU et du débit de sortie, jamais à partir des tokens consommés. Un signal rouge apparaît avec un compteur quand un agent est bloqué et attend une réponse.

Un Thread peut être verrouillé à ses propres dossiers grâce au bac à sable du noyau macOS, ce qui empêche l'agent d'atteindre vos autres dépôts ou votre dossier Documents. Le Vault garde vos clés dans le Keychain et les utilise par leur nom, sans jamais les montrer à l'agent ni les écrire dans le terminal.

Il faut aussi connaître les limites. Le verrouillage des dossiers est optionnel et ne restreint pas le réseau : un agent verrouillé peut toujours envoyer ce qu'il a le droit de lire. Une clé du Vault non épinglée reste lisible par le programme qui l'a reçue. Et le pouls indique une activité, jamais une consommation de tokens.

• Le pouls suit le CPU et le débit de sortie, jamais les tokens.
• Le verrouillage de dossier est optionnel et n'empêche pas le réseau.
• Une clé du Vault reste lisible par le programme qui l'a reçue.

Une liste de contrôle pour aujourd'hui

Vous n'avez pas besoin d'un nouvel outil pour commencer à superviser correctement. Les points suivants s'appliquent quel que soit l'agent que vous utilisez, et ils réduisent le risque sans ralentir le travail en direct.

Faites-les dans l'ordre, les deux premiers comptent le plus parce qu'ils retirent ce qui est déjà exposé avant de s'attaquer à ce qui pourrait arriver ensuite.

• Sortez vos clés API des fichiers .env et mettez-les dans le Keychain ou un vault.
• Limitez les dossiers que l'agent peut atteindre, surtout hors du projet en cours.
• Gardez un signal visible de l'activité de l'agent pendant qu'il travaille.
• Relisez toujours le diff final, même pour un changement qui semblait trivial.
• Changez toute clé qui a déjà pu être lue par un agent ou poussée sur un dépôt.