Pratique : vous guider étape par étape pour utiliser 7 agents afin d'améliorer Vibe Coding en un processus de développement expert

L'auteur @sairahul1 a décomposé la révolution du workflow passant de « Vibe Coding » à « l'usine logicielle » : diviser une seule conversation IA en 7 agents spécialisés : chercheur, scénariste, rédacteur de spécifications, constructeur backend, constructeur frontend, vérificateur de tests, validateur d'implémentation, chacun avec une seule responsabilité, un contexte propre et des frontières strictes.
(Précédemment : La MCP connectant tout avec Web3, peut-elle devenir la prochaine vague de narration IA à mille fois ? )
(Complément : Le plus grand maître investisseur vous fait travailler ! Rassemblement de Buffett, Munger, Cathie Wood… 19 agents IA pour analyser le marché)

Table des matières de cet article

Toggle

• La question dont personne ne parle
• Transition : du Vibe Coding à l’usine logicielle
• Sept agents
  • Agent 1 : Chercheur de code (Codebase Researcher)
  • Agent 2 : Scénariste (Story Writer)
  • Agent 3 : Rédacteur de spécifications (Spec Writer)
  • Agent 4 : Constructeur backend (Backend Builder)
  • Agent 5 : Constructeur frontend (Frontend Builder)
  • Agent 6 : Vérificateur de tests (Test Verifier)
  • Agent 7 : Validateur d’implémentation (Implementation Validator)
• Comment toute la chaîne fonctionne
• Fondamentaux : avant que les agents puissent fonctionner, il faut ceci
  • CLAUDE.md — mémoire vivante de chaque conversation
  • Drift de contexte — le tueur silencieux
• Résultats : ce qui change vraiment
  • Avant l’usine :
  • Après l’usine :
  • La vraie transformation :
• Faites votre propre version ce week-end
  • Liste de 8 étapes pour la configuration :
• Les sept agents — référence rapide

Je pensais utiliser l’IA pour coder. En réalité, je tape juste plus vite.

Ce que je vais expliquer ici, c’est la différence — et la « systeme à 7 agents » qui change tout.

Enregistre cet article. Il te fera gagner plusieurs mois.

La question dont personne ne parle

Ce cycle apparemment productif, mais en réalité inefficace :

→ Demander à Claude de faire une fonctionnalité → Il génère du code → Quelque chose ne va pas → Coller le message d’erreur → Il corrige → Un autre problème apparaît → Re-demander

Jour 1 : C’est magique.

Jour 30 : Tu passes plus de temps à superviser l’IA qu’à coder toi-même.

Ce même raisonnement apparaît dans trois endroits différents. Claude oublie ta routine d’il y a deux semaines. La nouvelle fonctionnalité casse l’ancienne. Les tests sont absents ou superficiels.

Un jour, tu te réveilles et tu réalises : Ce n’est pas l’IA qui échoue, c’est ton workflow qui échoue.

Le problème est structurel.

Quand tu demandes dans Claude Code « Fais-moi cette fonctionnalité », tu demandes en réalité à une IA de jouer plusieurs rôles en même temps :

→ Analyste produit → Architecte → Développeur backend → Développeur frontend → Testeur → Relecteur de code

Tout en une seule conversation chaotique.

Une hypothèse erronée dans le plan devient un modèle de base de données incorrect. La base de données fausse entraîne une API erronée. L’API fausse déforme l’UI.

Et quand tu t’en rends compte, la erreur s’est déjà propagée partout.

C’est ce qu’on appelle le Vibe Coding (coder à l’instinct).

Il y a une limite très dure.

Transition : du Vibe Coding à l’usine logicielle

Le vrai changement clé :

Une vraie équipe d’ingénierie ne travaille pas dans une seule grande conversation.

Chacun a un rôle précis :

→ Quelqu’un clarifie le problème utilisateur → Quelqu’un pense l’architecture → Quelqu’un écrit l’API → Quelqu’un construit l’UI → Quelqu’un réfléchit aux limites → Quelqu’un fait la revue

En condensant tout cela dans une seule conversation IA, les erreurs s’accumulent silencieusement.

La solution : diviser le travail entre agents spécialisés.

Chaque agent reçoit :

→ Une tâche ciblée → Un contexte propre et clair → Les outils dont il a besoin → Des règles strictes sur ce qu’il ne doit pas toucher

Résultat : Une usine logicielle.

Un développeur + sept agents ciblés = une équipe coordonnée.

Voici les sept agents qui font fonctionner cette idée.

Les sept agents

Agent 1 : Chercheur de code (Codebase Researcher)

Quelle est la plus grande erreur quand un développeur utilise l’IA ?

Considérer « obtenir du code » comme la première étape.

L’IA reçoit un prompt, devine, remplit les blancs, puis génère. Une mauvaise conception s’infiltre à ce moment-là.

Le chercheur corrige cela.

Sa seule tâche : examiner la base de code et expliquer l’état actuel — avant qu’une ligne ne soit écrite.

Ce qu’il fait :

• Marquer les fichiers pertinents et leur rôle
• Noter les patterns existants
• Trouver des fonctionnalités similaires déjà faites
• Signaler les risques (fuseaux horaires, multi-tenants, logique de retry)
• Lister les tests à mettre à jour

Ce qu’il ne peut pas faire :

• Modifier les fichiers (lecture seule)
• Exécuter des commandes qui changent l’état
• Faire des hypothèses — il doit poser des questions

Outils : Read, Grep, Glob, rien d’autre.

Règle : Avant de commencer, explorer.

Le chercheur doit toujours commencer.

Agent 2 : Scénariste (Story Writer)

La plupart des échecs fonctionnels ne viennent pas du code.

Mais du fait que le problème n’a jamais été clairement défini.

Le scénariste transforme une idée brute en une véritable histoire utilisateur — avant toute décision technique.

Entrées :

• La description brute de la fonctionnalité
• Les résultats de l’enquête du chercheur

Sorties :

• Une histoire utilisateur : « En tant que [rôle], je veux [action], afin que [résultat]. »
• Critères d’acceptation : des tests concrets — chemin heureux, chemins d’échec, règles métier.
• Cas limites : limites, retries, considérations multi-tenants.
• Ce qui n’est pas dans le scope : ce qui est explicitement exclu.
• Questions non résolues : ce qu’il ne sait pas, sans deviner.

Ce qu’il ne peut pas faire :

• Inventer des règles métier
• Écrire du code ou de la conception technique
• Continuer si quelque chose n’est pas clair

Outils : Read, rien d’autre.

Règle : Tu dois lire et approuver cette histoire pour que la suite se fasse.

C’est la clé pour que tout en aval ne se trompe pas — Point de revue humain 1.

Agent 3 : Rédacteur de spécifications (Spec Writer)

Après approbation de l’histoire, le spécificateur la transforme en un document technique.

Ce document sert de plan pour tous les agents de construction.

Entrées :

• L’histoire utilisateur approuvée
• Les résultats du chercheur
• Les règles CLAUDE.md du projet

Sorties :

• Modifications du modèle de données (champs, types, migrations)
• Processus / flux de traitement
• Modifications API (endpoints, formats request/response)
• Modifications UI (composants, pages, hooks)
• Tests nécessaires (succès, échec, limites)
• Risques et questions non résolues
• Liste des fichiers à modifier

Ce qu’il ne peut pas faire :

• Modifier des fichiers
• Inventer de nouvelles infrastructures — il doit préciser
• Ignorer la séparation multi-tenants ou fuseaux horaires
• Laisser des questions sans réponse

Outils : Read, Grep, Glob, rien d’autre.

Règle : Ce document est Point de revue humain 2.

Vous devez l’avoir lu et approuvé pour que chaque fichier soit modifié.

Si vous voyez « stocker l’ID en mémoire » — c’est un drapeau rouge.

Repérez-le immédiatement. Ne pas attendre que 10 fichiers soient modifiés.

Agent 4 : Constructeur backend (Backend Builder)

C’est là que commence la construction.

Le constructeur backend implémente la « moitié backend » — uniquement cette partie.

Entrées :

• La spécification technique approuvée
• Les résultats du chercheur
• Les règles CLAUDE.md

Il construit :

• Routes API
• Services et logique métier
• Accès à la base de données et migrations
• Tâches en arrière-plan
• Tests unitaires

Il ne peut pas faire :

• Toucher aux composants React, pages ou hooks côté client (c’est le boulot de l’agent 5)
• Inventer de nouvelles dépendances sans instruction
• Modifier des fichiers hors scope
• S’arrêter sans avoir passé typecheck, lint, tests

Après, il renvoie un résumé : fichiers modifiés, patterns réutilisés, observations CLAUDE.md.

Outils : Read, Edit, Write, Bash — uniquement dans le dossier backend.

Clé : La séparation est essentielle.

Le constructeur backend ne doit jamais casser le frontend.

Agent 5 : Constructeur frontend (Frontend Builder)

Le constructeur frontend implémente l’UI — uniquement cette partie.

Il lit le résumé du constructeur backend.

C’est crucial.

Il utilise l’API selon le contrat. Il ne crée pas de nouveaux endpoints.

Si la forme de l’API est incorrecte pour l’UI, il doit le signaler — pas patcher lui-même.

Entrées :

• La spécification technique approuvée
• Les résultats du chercheur
• Le résumé API du backend

Il construit :

• Composants React et pages
• Hooks et gestion d’état côté client
• États de chargement et d’erreur
• Tests unitaires et composants

Il ne peut pas faire :

• Toucher aux services, routes API, workers ou migrations (c’est le boulot de l’agent 4)
• Inventer de nouveaux endpoints ou formats de réponse
• Ajouter des dépendances sans instruction
• Passer typecheck, lint, tests

Outils : Read, Edit, Write, Bash — uniquement dans le dossier frontend.

Deux constructeurs. Deux contextes propres. Zéro risque de casser l’autre.

Agent 6 : Vérificateur de tests (Test Verifier)

Les deux constructeurs écrivent leurs tests unitaires.

Ce n’est pas suffisant.

Le vérificateur de tests ne fait qu’une chose : prouver que la fonctionnalité fait ce que l’histoire dit.

Il écrit des « tests d’acceptation », pas des tests unitaires.

Les tests d’acceptation testent la fonctionnalité comme un utilisateur réel la vivrait.

Entrées :

• L’histoire utilisateur approuvée (avec tous les critères)
• La spécification technique approuvée
• Résumé des deux constructeurs

Sorties :

• Un fichier de tests d’acceptation couvrant chaque critère
• Un rapport : succès, échecs, couverture incomplète

Il ne peut pas faire :

• Modifier du code backend ou frontend
• Inventer des solutions pour les critères non testés
• Marquer comme couverts des critères non couverts

Si un test échoue : la fonctionnalité ne satisfait pas l’histoire.

Il signale « quel critère a échoué ». Il ne corrige pas le code.

Les corrections reviennent aux constructeurs.

Outils : Read, Edit, Write (tests uniquement), Bash.

Règle : Avant que la fonctionnalité ne passe, elle n’existe pas.

Agent 7 : Validateur d’implémentation (Implementation Validator)

C’est l’agent qui repère ce que tout le monde a oublié.

Il compare l’implémentation actuelle avec l’histoire et la spécification, et rapporte l’écart.

Il ne modifie jamais. Il dit la vérité.

Chaque exécution vérifie :

• Si des critères d’acceptation ne sont pas encore réalisés
• Des chemins d’échec non couverts
• Des questions de sécurité : permissions, isolation, clés dans logs, erreurs exposées
• Des fichiers modifiés hors scope
• Des incohérences avec CLAUDE.md ou le code existant
• Des patterns qui auraient dû être réutilisés mais sont répétés
• Des considérations de fuseau horaire ou multi-tenants omises

Les résultats sont classés par gravité :

• Critique — à corriger impérativement avant merge
• Important — à corriger avant merge
• Mineur — opinion du relecteur

Chaque problème est indiqué avec le fichier et la ligne.

Si rien à signaler : il dit « tout est OK ». Il n’invente pas de problèmes pour faire sérieux.

Outils : Read, Grep, Glob, rien d’autre.

Ce vérificateur est la raison pour laquelle l’usine peut être fiable.

Un rapport d’auto-évaluation sans valeur. Un vérificateur qui ne regarde que ce qui est sur le disque, sans analyser comment c’est écrit, est honnête.

Comment toute la chaîne fonctionne

Un processus complet — un prompt lance tout :

Tu ouvres Claude Code, tu tapes :

« Fais-moi la fonction ‘Rappel de facture impayée depuis plus de 7 jours’ »

Et tu n’as plus besoin d’écrire autre chose, ça se passe ainsi :

Étape 1 → Le chercheur parcourt les fichiers liés aux factures, paiements, emails. Retourne fichiers, patterns, risques.

Étape 2 → Le scénariste produit une histoire utilisateur et ses critères.

⏸ Pause : tu lis et approuves l’histoire.

Étape 3 → Le spécificateur transforme en plan technique.

⏸ Pause : tu lis et approuves le plan. (C’est ici qu’on repère « stocker l’ID en mémoire » comme erreur.)

Étape 4 → Le constructeur backend implémente service, API, BullMQ, tests. Retour : fichiers, patterns, tests verts.

Étape 5 → Le constructeur frontend lit l’API, construit UI, composants, tests. Tout vert.

Étape 6 → Le vérificateur d’acceptation écrit tests, signale succès ou échec (par ex. pas vérifié la propriété du tenant).

Étape 7 → L’implémentation est validée. Si échec, retour au constructeur backend. Corrige. Tout vert. Vérification à nouveau. Tout propre.

⏸ Pause : tu révises et fais PR.

Trois points de revue humaine. Le reste se fait tout seul.

Base : Avant que les agents puissent fonctionner, il faut ceci

CLAUDE.md — mémoire vivante de chaque conversation

Chaque fois que tu ouvres Claude Code, il repart de « zéro mémoire ».

CLAUDE.md corrige cela.

C’est un fichier Markdown à la racine du repo, chargé automatiquement à chaque début de conversation.

Il est le « lieu des faits permanents du projet » :

• Ta stack technique (Next.js App Router, Node.js, Prisma, BullMQ, Resend)
• Tes commandes (npm run dev, npm test, npx prisma migrate dev)
• Règles d’architecture (« logique métier dans services, API légère »)
• Ce qu’il ne faut pas faire (« pas de cron, pas de log de payloads de paiement »)
• Indicateurs pour approfondir (docs/billing.md, docs/architecture.md)

Garder entre 100 et 300 lignes.

Chaque erreur surprenante de l’IA, demande-toi : « Si une règle était dans CLAUDE.md, pourrais-je l’éviter cette fois ? »

Ajoute-la.

En quelques semaines, ton CLAUDE.md deviendra le registre de toutes les hypothèses erronées de l’IA — ton dialogue s’améliorera nettement.

Drift de contexte — le tueur silencieux

La plupart des conversations Claude Code ne s’effondrent pas dramatiquement.

Mais elles dérivent.

Une mauvaise hypothèse s’infiltre dans le contexte. Le modèle continue à empiler.

Tu veux que Claude gère « la gestion des abonnements ». Il conçoit : User → Subscription.

Plus tard, tu te rappelles : l’abonnement appartient à « l’entreprise », pas à « l’utilisateur ».

Si tu dis simplement « Non, l’abonnement appartient à l’entreprise » — Claude appliquera un patch.

Et tu te retrouveras avec deux IDs : user.subscriptionId et company.subscriptionId, qui dérivent.

Règles :

• Petite faute ? Corrige en ligne.
• Hypothèse architecturale fausse ? Jette tout le contexte, recommence, et intègre la bonne hypothèse dès le premier prompt.

Une conversation propre, avec le bon modèle mental, vaut toujours mieux qu’un patch chaotique.

Résultat : ce qui change vraiment

Avant l’usine :

• Cycle Vibe coding : prompt → génération → erreur → patch → répéter
• Contexte encombré de bruit
• Hypothèses erronées accumulées en fonctionnalités défectueuses
• Un ingénieur ne peut faire qu’une chose à la fois
• Chaque fonctionnalité attend la disponibilité de la bonne personne

Après l’usine :

• Chaîne structurée : recherche → histoire → plan → construction → validation → confirmation
• Chaque agent a un contexte propre, ne voit que ce qu’il doit
• Les mauvaises hypothèses sont détectées lors de la « validation du plan » — pas après 10 fichiers
• Un ingénieur peut produire une tranche verticale complète : backend, frontend, tests, validation
• La meilleure connaissance de l’équipe réside dans les agents — pas enfermée dans « une seule personne »

La vraie transformation :

Un expert paiement crée un agent payments-integration. Dès lors, chaque ingénieur peut sortir une fonctionnalité complète avec gestion comptable. Pas besoin d’attendre, pas besoin de transfert.

Les modèles UI du lead frontend résident dans l’agent frontend-builder. Les contrôles CI du DevOps dans hooks. Les scénarios limites du QA dans les règles de test.

Le savoir expert, partagé sous forme d’agents. Pas bloqué par « qui est dispo ».

Faites votre propre version ce week-end

Liste de 8 étapes pour la configuration :

2. Installer Claude Code → code.claude.com
3. Créer la structure de dossiers :
   • .claude/agents/
   • .claude/skills/feature-factory/
   • .claude/skills/build-with-tests/
   • .claude/hooks/
4. Écrire votre CLAUDE.md (100–300 lignes : stack, commandes, règles, liste à ne pas faire)
5. Utiliser la commande /agents dans Claude Code pour créer 7 agents. Décrire leur rôle. Claude écrit. Vous validez et committez.
6. Créer la compétence orchestrator feature-factory. Demandez à Claude de l’écrire — elle lira vos 7 agents et connectera toute la chaîne.
7. Créer la compétence build-with-tests. Décrire comment votre équipe construit : suivre le pattern, coder et tester en même temps, finir par typecheck.
8. Ajouter un hook pre-commit. Empêcher la soumission de .env, .key, .pem ou secrets.json. 5 min, évite une catastrophe.
9. Exécuter une fonctionnalité réelle en boucle complète. Choisissez une petite. Observez où ça bloque. Ajoutez des règles. L’usine s’ajustera toute seule.

Temps total : 2–3 heures.

Faire quelques fonctionnalités. Après 3–4, l’usine connaît votre code.

Vous passerez moins de temps à superviser, plus à décider « Quoi faire ensuite ».

Les sept agents — référence rapide

• Chercheur (Researcher) — Avant toute création, analyser le code (lecture seule)
• Scénariste (Story Writer) — Transformer idée en histoire utilisateur et critères (lecture seule)
• Spécificateur (Spec Writer) — Transformer histoire en plan technique (lecture seule)
• Constructeur backend (Backend Builder) — API, services, jobs, tests (dans le dossier backend)
• Constructeur frontend (Frontend Builder) — Composants, pages, hooks, tests UI (dans le dossier frontend)
• Vérificateur de tests (Test Verifier) — Écrire tests d’acceptation (dans les fichiers de test)
• Validateur (Validator) — Comparer implémentation, rapporter écarts (lecture seule)

3 points de revue humaine :

→ Approuver histoire → Approuver plan → Approuver PR

Tout le reste se fait tout seul.

La majorité des développeurs utilisant Claude Code sont encore dans le vibe coding. Prompt → génération → patch → prière.

Ce n’est pas faux. Mais il y a un plafond.

L’usine ne te sort pas du workflow. Elle te sort de la partie « pas besoin de jugement ».

Tu restes dans les étapes où ton jugement est crucial :

Est-ce la bonne question ? Est-ce le bon design ? Peut-on déployer en sécurité ?

Tout le reste, c’est la responsabilité des agents.

C’est la différence entre « utiliser l’IA comme un clavier plus rapide » et « utiliser l’IA comme une équipe coordonnée ».