AFTER : Ton Vibe Code Mérite Mieux

L’IA écrit la majorité du code. L’humain prend chaque décision.

Architect First, parce que rien n’est généré avant que les décisions soient prises. Test Everything Rigorously, parce que rien ne part en production sur la confiance. AFTER. Le reste est une question d’implémentation, et l’implémentation a pris de l’ampleur de la meilleure façon possible : un fichier de protocole que les agents suivent d’emblée, un CLI en Go avec des portes d’approbation physiquement impossibles à sauter, et assez de surprises en chemin pour que j’arrête de traiter tout ça comme une manie personnelle et que je commence à l’écrire.

La fin de la lune de miel

Comme la plupart des développeurs, j’ai eu ma lune de miel avec les outils de codage IA. On décrit ce qu’on veut, le code apparaît, ça fonctionne à peu près, et la vitesse est grisante. Puis on revient deux semaines plus tard et on réalise qu’on ne peut pas expliquer la moitié de ce qui se trouve dans son propre dépôt.

Le problème n’est pas que l’IA écrit du mauvais code. Elle écrit souvent du code correct. Le problème, c’est que personne n’a pris les décisions. La couche de stockage a été choisie par inertie. La gestion d’erreurs existe là où le modèle a eu envie d’en mettre. La sécurité a reçu le traitement que lui réserve le dépôt GitHub public moyen, c’est-à-dire pas grand-chose. Et parce que tout est arrivé vite et à peu près fonctionnel, personne ne s’est arrêté pour se demander si quoi que ce soit était juste.

J’ai passé des années sur des systèmes de conformité en entreprise, dont un modèle de permissions multi-tenant où un seul bug de scoping aurait signifié qu’un client voie les données d’un autre. Avec ce bagage, difficile d’accepter « ça a l’air de marcher » comme barre de qualité. Alors plutôt que de faire moins confiance aux sorties, j’ai structuré davantage le processus.

Architect First, Test Everything Rigorously

Le postulat est économique : la génération par IA ne coûte rien, le jugement humain coûte cher. La méthodologie dépense donc le jugement là où il compte, aux deux extrémités du flux de travail : avant que le code existe, et après qu’il apparaît. Que l’acronyme forme un vrai mot n’est pas un accident.

Architect First signifie qu’aucun code n’est généré avant que l’humain ait pris les décisions qui comptent :

• Tout travail significatif part d’une spécification écrite : architecture, schémas de données, signatures d’API et plan par phases.
• Les choix technologiques sont faits par l’humain, avec un raisonnement documenté, avant toute génération.
• Les specs incluent une section de contraintes explicites couvrant les décisions dont une IA dériverait autrement : choix de stockage, formats d’identifiants, dépendances interdites, patterns non négociables.
• Le travail est découpé en tâches autonomes avec critères d’acceptation. Chaque prompt transporte tout le contexte dont il a besoin. Rien ne repose sur la mémoire de l’IA.
• Les standards de qualité du projet vivent dans un fichier de standards chargé dans chaque session, pour que les attentes soient imposées structurellement plutôt que répétées à la main.

Test Everything Rigorously signifie que rien ne part en production sur la confiance. Toute sortie générée est considérée comme non vérifiée jusqu’à preuve du contraire :

• Les tests sont générés en même temps que le code de production, jamais après. Minimum par unité de logique : le cas nominal, au moins un cas limite, au moins un cas d’erreur.
• Le code généré doit pouvoir être expliqué ligne par ligne par l’humain. Une ligne qu’on ne peut pas expliquer ne se merge pas.
• Le code sensible côté sécurité est signalé par des marqueurs explicites qui forcent une revue humaine avant le merge.
• Les gros chantiers avancent par phases, avec des portes de validation humaine entre elles, et le contrôle de version isole chaque phase pour permettre un retour arrière sûr.
• La phase finale est adversariale : une revue en avocat du diable contre une checklist, validée par l’humain, avant que quoi que ce soit soit considéré comme terminé.

Rien de tout ça n’est exotique. C’est ce qu’une équipe senior disciplinée fait déjà, traduit dans une forme qui survit au contact d’une IA qui produit du code plus vite qu’on ne peut le relire distraitement.

Commencez par un seul fichier

Voici la partie qui m’a surprise. En construisant l’outillage, j’ai remarqué que les agents se mettent à suivre la méthodologie simplement parce qu’elle est nommée et structurée dans leur contexte. J’y reviendrai, parce que la raison compte.

Le déploiement le plus simple d’AFTER est donc un seul fichier, AFTER.md, écrit comme des instructions directes à l’agent. Déposez-le dans votre projet comme CLAUDE.md ou AGENTS.md, collez-le dans vos règles Cursor, ou utilisez-le comme prompt système. Il transporte les règles d’opération (marqueurs de décision, marqueurs d’assomption, tests avec chaque changement, sortie non vérifiée jusqu’à preuve), les portes de phase sous forme de points d’arrêt conversationnels où l’agent doit s’arrêter et attendre votre approbation, et quatre workflows qui couvrent la vraie vie d’une codebase : greenfield, feature, debug et refactor.

L’un de ces workflows porte ma règle préférée de toute la méthodologie, alors je vous la divulgâche tout de suite : en mode debug, aucun correctif n’est permis avant qu’un test en échec reproduise le bug. Le test qui échoue est la spécification du bug. Le tour complet des quatre workflows arrive plus bas.

Un fichier, n’importe quelle interface, zéro installation. Pour bien des projets, c’est tout l’AFTER dont vous avez besoin.

Pourquoi les agents jouent le jeu

Il y a une raison pour laquelle le protocole fonctionne d’emblée, et elle n’a pas grand-chose à voir avec une quelconque invention de ma part. Les modèles ont ingéré des décennies de culture du développement logiciel : TDD, design docs, RFC, post-mortems, étiquette de revue de code, méthode scientifique appliquée au débogage. Chaque pattern qu’AFTER formalise vit déjà dans le corpus, défendu par des milliers de développeurs seniors. Le protocole n’a donc jamais à enseigner à un modèle que le spec-first est une bonne chose ; le modèle le sait déjà. Ce qui manque, dans une conversation libre, c’est une raison d’agir en conséquence. Sans cadre, un agent optimise pour ce que la conversation récompense en surface, c’est-à-dire produire du code plausible rapidement. AFTER renverse cette récompense locale. À l’intérieur de son cadre, les gestes compétents sont s’arrêter, demander, et écrire ses assomptions, parce que le protocole les nomme comme étant le travail.

Les marqueurs en sont l’exemple le plus clair. DECISION_REQUIRED donne au modèle une sortie honorable. Sans lui, un agent incertain devine, parce que deviner ressemble à de la compétence et s’arrêter ressemble à un échec. Avec lui, s’arrêter devient le comportement compétent, avec un nom et une étape suivante définie : remettre la décision à l’humain. ASSUMPTION fonctionne de la même façon, en donnant à l’incertitude un endroit sanctionné où vivre plutôt que de se cacher dans une prose confiante. Et tout ça ne fera que s’améliorer. Chaque génération de modèles suit les instructions plus fidèlement et raisonne plus solidement sur les protocoles. Une méthodologie qui lutte contre la nature de ces systèmes vieillit mal ; une méthodologie qui s’appuie dessus prend de la valeur.

Les instructions s’érodent. La structure, non.

Voici ce que j’ai appris en appliquant AFTER à la main, et ça vaut aussi pour le fichier de protocole : la discipline qui dépend de la mémoire s’érode. Un bon jour, l’agent respecte chaque porte. Vingt tours plus loin dans une longue session, ou un jour pressé où on lui fait signe d’avancer, les phases commencent à se fondre les unes dans les autres. La méthodologie fonctionnait quand elle était suivie, et tout le problème tenait dans le mot « quand ». C’est vrai pour les humains, et c’est vrai pour un protocole qui vit dans une fenêtre de contexte.

Pour les projets où ce n’est pas acceptable, j’ai construit la discipline dans un outil où les portes ne peuvent pas être sautées, parce qu’elles sont une machine à états plutôt qu’une suggestion.

YVCDB : des portes impossibles à sauter

YVCDB (Your Vibe Code Deserves Better, en français Ton Vibe Code Mérite Mieux) est un CLI interactif écrit en Go qui orchestre des workflows AFTER par-dessus Claude Code, Codex CLI ou OpenCode. Là où le fichier de protocole demande à l’agent de respecter les portes, YVCDB les rend physiques : un pipeline de phases spécialisées, chacune gouvernée par son propre prompt embarqué, avec une porte d’approbation humaine obligatoire après chacune d’elles. Il implémente les quatre workflows AFTER : greenfield, feature, debug et refactor.

Le provider OpenCode mérite un mot, parce qu’il change qui peut utiliser tout ça. À travers OpenCode, YVCDB fonctionne avec des dizaines de fournisseurs de modèles, y compris des API à palier gratuit et des modèles entièrement locaux via Ollama. Ça signifie des workflows AFTER complets à coût nul et, sur la voie locale, du code qui ne quitte jamais votre machine. Ça met aussi à l’épreuve une conviction qui me tient à cœur : un harnais structuré relève le plancher. Des périmètres de phase étanches, des prompts spécialisés et un humain qui attrape la dérive à chaque porte permettent à des modèles modestes de produire un travail qu’on ne pourrait jamais accepter d’eux de façon responsable en conversation libre. Les modèles frontière gagnent une couche de qualité ; les modèles bon marché gagnent un chemin vers l’utilisable tout court. C’est une affirmation testable, et j’ai l’intention de la tester correctement dans un prochain article : mêmes specs, mêmes workflows, modèles gratuits contre modèles frontière, résultats mesurés plutôt que ressentis.

La décision de design centrale est une asymétrie. Pendant une phase, l’agent a de larges pouvoirs : il peut lire, écrire, modifier et exécuter des commandes dans son bac à sable. Entre les phases, il n’a aucun pouvoir. Chaque transition passe par une décision humaine dans le TUI : approuver, réessayer, envoyer un retour libre dans une nouvelle itération, ou sauter. La machine à états rend structurellement impossible d’avancer sans un choix humain. On ne peut pas oublier AFTER en l’utilisant, parce que l’outil ne le permet pas.

Les quatre workflows se répartissent en deux paires. Greenfield et refactor sont les grands moments, la naissance d’un projet et son sauvetage. Feature et debug sont tout ce qu’il y a entre les deux, c’est-à-dire l’essentiel de la vraie semaine d’un développeur. Une note de design qui en dit long : la détection de mode ne devine jamais l’intention. Un répertoire vide ne peut signifier que greenfield. Pour tout le reste, le TUI vous demande de déclarer quel genre de travail est sur le point de commencer (refactor, feature ou debug), parce que c’est en soi une décision, et les décisions appartiennent à l’humain.

Greenfield implémente la moitié Architect First au pied de la lettre. Les trois premières phases ont l’interdiction de générer le moindre code produit. La phase 0 produit un document de spécification avec buts, non-buts, critères d’acceptation et la section de contraintes. La phase 1 produit l’architecture et le fichier de standards du projet, et le prompt exige que chaque choix technologique liste les alternatives considérées et le raisonnement, dans une forme lisible par un humain. La phase 2 produit le plan : des tâches autonomes, chacune transportant tout ce dont une session IA fraîche a besoin, parce que chaque phase tourne comme un sous-processus frais, sans mémoire conversationnelle. La continuité vit dans des documents versionnés, jamais dans un fil de discussion. Le code n’apparaît qu’à la phase 3, et seulement l’échafaudage prévu par le plan approuvé.

Refactor applique AFTER à une codebase qui existe déjà, ce qui veut généralement dire du vibe code. L’ordre des phases est lui-même un argument : diagnostic d’abord (lecture seule stricte, comprendre avant de toucher), puis un filet de sécurité de smoke tests sur les flux critiques, puis trois passes à périmètre étanche (sécurité, structure, lisibilité), et enfin la revue adversariale. Une règle de la phase filet de sécurité résume la philosophie : un test qui échoue sur le code actuel est un bug existant à documenter, jamais quelque chose à corriger tout de suite. Chaque phase fait une seule chose.

Feature, c’est le greenfield replié sur une codebase vivante. Les mêmes phases documentaires avant tout code, mais chaque document devient un delta. La spec scinde les contraintes en héritées et nouvelles, parce que les contraintes d’un projet existant ne se renégocient pas au gré d’une nouvelle fonctionnalité. L’analyse d’impact met à jour le document d’architecture en place plutôt que de le remplacer, si bien que les documents AFTER deviennent la mémoire longue du projet, chaque feature y ajoutant une strate. Le plan exige que chaque tâche liste les comportements existants qu’elle risque de casser, ce qui fait du risque de régression une propriété de premier ordre du travail plutôt qu’une découverte tardive, et un échec dans la suite préexistante est un bloqueur. La revue adversariale se termine sur une question calibrée pour un anti-pattern documenté du code généré par IA : la fonctionnalité s’intègre-t-elle aux patterns existants, ou l’agent a-t-il discrètement construit un mini-framework parallèle à côté d’eux ? Et il y a un bonus discret dans la phase de cadrage : pointée sur un dépôt qui n’a jamais utilisé AFTER, elle diagnostique la structure et les conventions et amorce un jeu léger de documents AFTER au passage. On peut adopter la méthodologie par sa première feature, sans projet de migration.

Debug est le workflow que je montrerais à un sceptique, parce qu’il transforme la méthodologie en quelque chose de proche de la méthode scientifique. Quatre de ses six phases interdisent de toucher au code produit. Il s’ouvre sur un artefact de rapport de bug, et si aucune description n’a été fournie, l’agent s’arrête et la demande plutôt que de diagnostiquer dans le vide. Puis la reproduction : le plus petit test automatisé qui échoue actuellement, exécuté et montré en échec pour la raison attendue, avant toute théorie. Puis un diagnostic en lecture seule qui doit remonter à la cause racine, considérer des hypothèses alternatives et les écarter explicitement, avec l’humain qui approuve la théorie avant qu’une seule ligne de code produit ne change. La phase de correctif est la seule autorisée à modifier du code, contrainte au plus petit changement qui traite la cause racine documentée. La vérification exige ensuite la preuve dans les deux sens : le test de reproduction passe avec le correctif et échoue de façon démontrable sans lui, ce qui protège contre les tests qui passent pour de mauvaises raisons. La revue adversariale se referme sur la question propre au debug : véritable cause racine, ou pansement de symptôme qui masque le bug ailleurs ?

Quelques mécanismes auxquels je tiens particulièrement :

Des marqueurs plutôt que des suppositions silencieuses. Chaque session tourne sous des règles d’opération injectées : marquer les inférences non fondées avec ASSUMPTION, signaler le code touchant à l’authentification, aux paiements, aux permissions ou aux données personnelles avec REQUIRES_REVIEW, et s’arrêter avec DECISION_REQUIRED quand une décision conséquente manque, plutôt que de deviner. La phase adversariale traque ensuite les marqueurs non résolus, et « aucun marqueur non résolu » est un item de la checklist finale. Les marqueurs ne sont pas décoratifs ; ils sont la piste d’audit de tout ce dont l’IA n’était pas sûre.

Git comme couche d’isolation. Un commit instantané avant tout travail, une branche par phase, un commit par itération pour préserver l’historique des reprises, et des worktrees avec rebase et merges fast-forward pour les étapes parallèles. En cas de conflit de rebase, l’outil annule le rebase, préserve le worktree pour une résolution manuelle et s’arrête avec un rapport plutôt que de forcer le passage. Quand quelque chose est ambigu, l’humain tranche. Cette règle s’applique aussi aux opérations Git.

Le verdict final appartient à un humain. Chaque workflow se termine par un prompt de revue adversariale qui joue un développeur senior exigeant, convaincu que les phases précédentes ont raté quelque chose. Il n’a qu’un accès en lecture, doit répondre à une checklist par des OUI ou NON justifiés item par item, et doit rendre exactement l’un de trois verdicts : prêt, prêt avec des risques explicitement acceptés (chaque risque nommé et assumé par l’humain), ou pas prêt avec des conditions. Et au-dessus de tout ça se trouve la dernière couche : une checklist de qualité finale à laquelle l’humain répond lui-même, item par item, dans le TUI. La validation ultime n’est jamais déléguée à l’IA.

L’outil s’est construit lui-même

YVCDB a été construit avec AFTER. Les specs, les décisions d’architecture et le découpage des tâches étaient les miens ; l’implémentation a été réalisée par des agents IA travaillant comme exécutants dirigés, à travers trois harnais différents : Claude, Codex et, pour les workflows feature et debug, un agent d’entrée de gamme (Devin Lite). Ce dernier point compte. L’exécutant le moins cher de l’équipe a livré des workflows complets dans une codebase Go concurrente, parce que les specs sur lesquelles il travaillait ne lui laissaient aucune décision conséquente à rater. L’architecture a aidé, en gardant les workflows sous forme de données : ajouter feature et debug a représenté environ 360 lignes, pour la plupart des prompts et des tests, avec zéro changement à l’orchestrateur, au runner ou à la couche Git. L’affirmation du plancher relevé, celle de la section OpenCode, a déjà survécu au contact de la réalité à l’intérieur même de cet outil. La CI rejette toute couverture sous 93 pour cent, et la suite de tests a attrapé de vraies race conditions et de vrais deadlocks pendant le développement, ce qui est à peu près la preuve la plus concrète que je puisse offrir que la moitié « Test Everything Rigorously » mérite sa place.

L’outil qui impose la méthodologie est lui-même le cas de référence de la méthodologie. J’aime que l’argument soit circulaire de la façon dont les bons bootstraps le sont : si AFTER ne pouvait pas produire un TUI Go concurrent de quatre mille lignes que je peux expliquer ligne par ligne, je ne serais pas en train d’écrire cet article à son sujet. Et la récursion ne s’arrête pas là : le blog sur lequel vous lisez ceci a été intégré et publié à travers une exécution AFTER, portes humaines incluses.

Quand l’utiliser, quand s’en passer

AFTER ne rendra pas la génération de code par IA sûre par magie, et elle a un coût : écrire des specs prend du temps, les portes de revue interrompent le flow, et sur un prototype jetable, la surcharge n’en vaut pas la peine. Je l’ajuste aux enjeux. Une expérimentation de fin de semaine se fait vibe coder comme chez n’importe qui ; tout ce que j’ai l’intention de maintenir, de livrer ou de signer passe par le pipeline.

Ce qu’elle rend en retour, c’est ce que j’avais perdu pendant la lune de miel : une codebase où chaque décision conséquente a été prise par une personne, volontairement, avec le raisonnement écrit noir sur blanc. L’IA écrit la majorité du code. L’humain prend chaque décision.

Les deux paliers sont open source. La méthodologie et le fichier de protocole vivent à github.com/Morialkar/after ; le CLI d’enforcement vit à github.com/Morialkar/yvcdb. Commencez par le fichier. Si vous voulez le pipeline complet sans dépenser un sou, pointez YVCDB vers OpenCode avec un modèle local. Et si vous essayez le workflow refactor sur un dépôt vibe codé, j’aimerais sincèrement savoir ce que la phase de diagnostic en déterre.