Comment construire une usine logicielle avec Claude Code qui déploie des fonctionnalités pendant que vous dormez

Je pensais utiliser l'IA pour coder.

En réalité, je ne faisais que taper plus vite.

Voici la différence — et le système à 7 agents qui a tout changé.

Gardez ça sous la main. Ça vous fera gagner des mois.

LE PROBLÈME DONT PERSONNE NE PARLE

La boucle qui donne l'impression d'être productive, mais qui ne l'est pas :

→ Demander à Claude de construire une fonctionnalité → Il génère du code → Quelque chose casse → Coller l'erreur → Il la corrige → Autre chose casse → Redemander

Jour 1 : ça ressemble à de la magie.

Jour 30 : vous passez plus de temps à superviser l'IA que vous n'en passiez à écrire du code.

La même logique apparaît à 3 endroits différents.

Claude a oublié la convention que vous avez établie il y a deux semaines.

Les nouvelles fonctionnalités cassent les anciennes.

Les tests sont manquants ou superficiels.

Vous vous réveillez et réalisez : ce n'est pas l'IA qui échoue.

C'est votre flux de travail.

Le vrai problème est structurel.

Quand vous tapez "construis cette fonctionnalité" dans Claude Code, vous demandez à une seule session IA d'être :

→ Analyste produit → Architecte → Ingénieur back-end → Ingénieur front-end → Ingénieur test → Relecteur de code

Tout à la fois.

Dans la même conversation désordonnée.

Des hypothèses erronées dans le plan deviennent des modèles de base de données erronés.

Des modèles de base de données erronés deviennent des API erronées.

Des API erronées deviennent des IHM erronées.

Au moment où vous le remarquez, l'erreur s'est propagée partout.

C'est ce qu'on appelle le "vibe coding".

Et il a un plafond de verre.

LE CHANGEMENT : DU VIBE CODING À UNE USINE LOGICIELLE

Ce qui change vraiment tout :

Les vraies équipes d'ingénierie ne travaillent pas en une seule grande conversation.

Différentes personnes ont différentes responsabilités :

→ Quelqu'un clarifie le problème utilisateur → Quelqu'un réfléchit à l'architecture → Quelqu'un construit l'API → Quelqu'un construit l'IHM → Quelqu'un réfléchit aux cas limites → Quelqu'un relit

Quand vous réduisez tout cela à une seule session IA, les erreurs se cumulent silencieusement.

La solution est de répartir le travail entre des agents spécialisés.

Chaque agent reçoit : → Une tâche ciblée → Sa propre fenêtre de contexte propre → Uniquement les outils dont il a réellement besoin → Des règles strictes sur ce qu'il ne peut pas toucher

Le résultat : une usine logicielle.

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

Voici les sept agents qui font fonctionner le système.

LES 7 AGENTS

Agent 1 : Le Chercheur de Code Source

La plus grosse erreur que les développeurs commettent avec l'IA ?

Demander du code comme première action.

L'IA accepte la requête, fait des suppositions pour combler les lacunes, et commence à générer.

C'est là que les mauvaises conceptions s'infiltrent.

Le Chercheur de Code Source corrige cela.

Son seul travail : inspecter le code source et expliquer comment les choses fonctionnent — avant qu'une seule ligne ne soit écrite.

Ce qu'il fait : → Cartographie les fichiers pertinents et leurs rôles → Documente les modèles existants à suivre → Trouve des fonctionnalités similaires déjà construites → Signale les risques (fuseau horaire, multi-tenant, logique de nouvelle tentative) → Liste les tests qui devront être mis à jour

Ce qu'il ne peut pas faire : → Modifier des fichiers (accès en lecture seule uniquement) → Exécuter une commande qui modifie l'état → Faire des suppositions — il demande plutôt

Outils : Lecture, Recherche, Glob uniquement.

La règle : explorer avant de construire, à chaque fois.

Le Chercheur s'exécute en premier. Toujours.

Agent 2 : Le Rédacteur d'Histoires Utilisateur

La plupart des fonctionnalités échouent non pas à cause d'un code erroné.

Mais parce que le problème n'a jamais été clairement défini.

Le Rédacteur d'Histoires Utilisateur transforme une idée de fonctionnalité brute en une véritable histoire utilisateur avant toute décision technique.

Entrée qu'il reçoit : → Votre description approximative de la fonctionnalité → Les conclusions du Chercheur

Ce qu'il produit :

Une histoire utilisateur :"En tant que [rôle], je veux [comportement], afin de [résultat]."

Critères d'acceptation :Des affirmations qu'un test peut vérifier directement. Chemin heureux. Chemins d'échec. Règles métier.

Cas limites :Limites, nouvelles tentatives, préoccupations multi-tenant.

Hors du périmètre :Ce qui n'est EXPLICITEMENT PAS construit.

Questions ouvertes :Ce qu'il ne sait vraiment pas — il ne devine jamais.

Ce qu'il ne peut pas faire : → Inventer des règles métier → Écrire du code ou une conception technique → Avancer si quelque chose n'est vraiment pas clair

Outils : Lecture uniquement.

La règle : vous lisez cette histoire et l'approuvez avant toute autre action.

C'est le point de contrôle humain qui sauve tout ce qui suit.

Agent 3 : Le Rédacteur de Spécifications

Une fois l'histoire approuvée, le Rédacteur de Spécifications la transforme en un brief technique.

C'est le plan que chaque agent de construction suivra.

Entrée qu'il reçoit : → Votre histoire utilisateur approuvée → Les conclusions du Chercheur → Les règles CLAUDE.md de votre projet

Ce qu'il produit :

→ Modifications du modèle de données (champs, types, migrations) → Flux de fond / flux de processus → Modifications d'API (points d'accès, formes de requête/réponse) → Modifications front-end (composants, pages, hooks) → Tests requis (succès, échec, cas limites) → Risques et questions ouvertes → Chaque fichier qui sera modifié

Ce qu'il ne peut pas faire : → Modifier un fichier → Inventer une nouvelle infrastructure — il le signale explicitement à la place → Ignorer l'isolation des locataires ou les problèmes de fuseau horaire → Laisser des questions sans réponse

Outils : Lecture, Recherche, Glob uniquement.

La règle : ce brief est le deuxième point de contrôle humain.

Vous le lisez et l'approuvez avant qu'un seul fichier ne soit touché.

Si vous voyez "stocker les ID en mémoire" — c'est votre drapeau rouge.

Attrapez-le maintenant. Pas après que 10 fichiers aient été modifiés.

Agent 4 : Le Constructeur Back-End

Maintenant, la construction commence.

Le Constructeur Back-End implémente la partie back-end de la fonctionnalité — et seulement la partie back-end.

Entrée qu'il reçoit : → Brief technique approuvé → Conclusions du Chercheur → CLAUDE.md de votre projet

Ce qu'il construit : → Routes API → Services et logique métier → Accès à la base de données et migrations → Tâches de fond → Tests unitaires pour tout ce qu'il écrit

Ce qu'il ne peut pas faire : → Toucher aux composants React, pages ou hooks côté client (c'est l'Agent 5) → Inventer de nouvelles dépendances sans instruction → Modifier des fichiers en dehors du périmètre convenu → S'arrêter sans avoir exécuté la vérification de type, le lint et la suite de tests

Après avoir terminé, il renvoie un résumé : → Chaque fichier ajouté ou modifié → Chaque aide ou modèle existant réutilisé → Toute règle CLAUDE.md qui aurait été utile

Outils : Lecture, Édition, Écriture, Bash — limités aux dossiers back-end uniquement.

La séparation est le point clé.

Le Constructeur Back-End ne peut pas casser accidentellement le front-end. Jamais.

Agent 5 : Le Constructeur Front-End

Le Constructeur Front-End implémente la partie IHM — et seulement la partie IHM.

Il lit d'abord le résumé du Constructeur Back-End.

C'est important.

Il consomme l'API exactement comme le back-end l'a produite.

Il n'invente pas de nouveaux points d'accès.

Si la forme de l'API est incorrecte pour l'IHM, il signale l'inadéquation comme un retour — pas comme un correctif.

Entrée qu'il reçoit : → Brief technique approuvé → Conclusions du Chercheur → Résumé du Constructeur Back-End (le contrat API)

Ce qu'il construit : → Composants et pages React → Hooks et état côté client → États de chargement et d'erreur → Tests de composants et unitaires pour tout ce qu'il écrit

Ce qu'il ne peut pas faire : → Toucher aux services, routes API, workers ou migrations (c'est l'Agent 4) → Inventer des points d'accès ou des formes de réponse → Ajouter des dépendances sans instruction → S'arrêter sans avoir exécuté la vérification de type, le lint et la suite de tests

Outils : Lecture, Édition, Écriture, Bash — limités aux dossiers front-end uniquement.

Deux constructeurs.

Deux fenêtres de contexte propres.

Zéro risque que l'un casse le travail de l'autre.

Agent 6 : Le Vérificateur de Tests

Les deux constructeurs ont écrit des tests unitaires pour leur propre code.

Ce n'est pas suffisant.

Le Vérificateur de Tests ne fait qu'une seule chose : prouver que la fonctionnalité fait réellement ce que l'histoire utilisateur a dit qu'elle devrait faire.

Il écrit des tests d'acceptation.

Pas des tests unitaires.

Des tests d'acceptation.

Ces tests testent la fonctionnalité de l'extérieur — comme un véritable utilisateur la vivrait.

Entrée qu'il reçoit : → Histoire utilisateur approuvée (avec tous les critères d'acceptation) → Brief technique approuvé → Résumés des deux constructeurs

Ce qu'il produit : → Un fichier de test d'acceptation couvrant chaque critère d'acceptation → Un rapport : quels critères ont réussi, lesquels ont échoué, lesquels ne peuvent pas être couverts proprement

Ce qu'il ne peut pas faire : → Modifier du code back-end ou front-end → Inventer des solutions de contournement pour des critères non testables → Marquer un critère comme couvert s'il ne l'est vraiment pas

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

Il signale exactement quel critère a échoué.

Il ne corrige pas le code.

Cela retourne au constructeur approprié.

Outils : Lecture, Édition, Écriture (fichiers de test uniquement), Bash.

La règle : vous n'avez pas de fonctionnalité tant que les tests d'acceptation ne passent pas.

Agent 7 : Le Validateur d'Implémentation

C'est l'agent qui attrape tout ce que les autres ont manqué.

Le Validateur compare l'implémentation actuelle avec l'histoire et le brief approuvés — et signale les écarts.

Il ne corrige jamais rien.

Il dit juste la vérité.

Chaque vérification qu'il effectue, à chaque fois :

→ Critères d'acceptation de l'histoire non encore implémentés → Chemins d'échec sans couverture de test → Problèmes de sécurité : vérifications d'authentification manquantes, lacunes d'isolation des locataires, secrets dans les logs, erreurs brutes exposées aux clients → Fichiers modifiés en dehors du périmètre convenu → Modèles incohérents avec CLAUDE.md ou le code existant → Logique dupliquée qui devrait réutiliser des aides existantes → Problèmes de fuseau horaire ou multi-tenant du brief qui ont été silencieusement ignorés

La sortie est toujours regroupée par gravité :

Critique — doit être corrigé avant la fusion Important — devrait être corrigé avant la fusion Mineur — basé sur l'opinion, décision du relecteur

Chaque constatation inclut le chemin du fichier et le numéro de ligne.

S'il n'y a rien de mal, il le dit clairement.

Il n'invente pas de problèmes pour paraître minutieux.

Outils : Lecture, Recherche, Glob uniquement.

Cet agent est la raison pour laquelle l'usine est digne de confiance.

Un devoir auto-évalué ne vaut rien.

Un validateur qui ne voit que ce qui est sur le disque — pas comment cela a été écrit — est honnête.

COMMENT LA CHAÎNE FONCTIONNE

Le flux complet — une seule requête lance tout :

Vous ouvrez Claude Code et tapez :

"Construis des rappels de facture pour les factures impayées depuis plus de 7 jours."

Voici ce qui se passe sans que vous tapiez autre chose :

Étape 1 → Chercheur cartographie votre code de facture, de paiement et d'email. Renvoie les fichiers pertinents, les modèles existants, les risques.

Étape 2 → Rédacteur d'Histoires Utilisateur produit l'histoire utilisateur et les critères d'acceptation.

⏸ PAUSE : Vous lisez et approuvez l'histoire.

Étape 3 → Rédacteur de Spécifications transforme l'histoire approuvée en un brief technique.

⏸ PAUSE : Vous lisez et approuvez le brief.(Attrapez l'erreur "stocker les ID en mémoire" ici même.)

Étape 4 → Constructeur Back-End implémente le service, la route API, le job BullMQ et les tests unitaires. Renvoie : fichiers modifiés, modèles réutilisés, tous les tests au vert.

Étape 5 → Constructeur Front-End lit le résumé API du Constructeur Back-End, construit la tuile d'IHM admin et le bouton de rappel, écrit les tests de composants. Tous les tests au vert.

Étape 6 → Vérificateur de Tests écrit des tests d'acceptation pour les six critères d'acceptation. Rapporte : 7 réussis, 1 échoué — le déclencheur manuel ne vérifie pas la propriété du locataire.

Étape 7 → Validateur le trouve. Le signale comme Critique avec le chemin du fichier et le numéro de ligne.

→ Boucle de retour vers le Constructeur Back-End. Correction appliquée. Les 8 tests d'acceptation passent. Le Validateur s'exécute à nouveau. Propre.

⏸ PAUSE : Vous révisez et ouvrez la PR.

Trois points de contrôle humains.

Tout le reste s'exécute tout seul.

LES FONDATIONS : AVANT QUE LES AGENTS NE TRAVAILLENT, VOUS AVEZ BESOIN DE CECI

CLAUDE.md — la mémoire qui survit à chaque session :

Chaque fois que vous ouvrez Claude Code, il commence avec zéro mémoire.

CLAUDE.md corrige cela.

C'est un fichier Markdown à la racine de votre dépôt qui se charge automatiquement à chaque session.

C'est là que résident les faits permanents du projet :

→ Votre stack (Next.js App Router, Node.js, Prisma, BullMQ, Resend) → Vos commandes (npm run dev, npm test, npx prisma migrate dev) → Règles d'architecture ("La logique métier vit dans les services. Les routes API restent légères.") → Ce qu'il ne faut pas faire ("N'ajoutez pas de cron — utilisez BullMQ. Ne journalisez pas les charges utiles de paiement brutes.") → Pointeurs vers une documentation plus approfondie (docs/billing.md, docs/architecture.md)

Gardez-le entre 100 et 300 lignes.

Chaque fois que l'IA fait une erreur qui vous surprend, demandez : une règle dans CLAUDE.md aurait-elle empêché cela ?

Ajoutez la règle.

En quelques semaines, votre CLAUDE.md devient un registre de chaque hypothèse que l'IA a mal comprise — et vos sessions s'améliorent sensiblement.

La dérive du contexte — le tueur silencieux :

La plupart des sessions Claude Code n'échouent pas de manière dramatique.

Elles dérivent.

Une hypothèse erronée entre dans le contexte.

Le modèle continue de construire dessus.

Vous demandez à Claude de construire la gestion des abonnements.

Il conçoit : Utilisateur → Abonnement.

Vous vous rappelez : les abonnements appartiennent à l'entreprise, pas à l'utilisateur.

Si vous dites simplement "non, les abonnements appartiennent aux entreprises" — Claude corrige.

Maintenant, vous avez à la fois user.subscriptionId et company.subscriptionId qui traînent.

Règle :

→ Petite faute de frappe ? Corrigez-la en ligne. → Mauvaise hypothèse architecturale ? Jetez la conversation et recommencez avec la bonne hypothèse intégrée dans la première requête.

Une session propre avec le bon modèle mental bat une session corrigée à chaque fois.

LES RÉSULTATS : CE QUI CHANGE RÉELLEMENT

Avant l'usine :

→ Boucle de vibe coding : demander → générer → erreur → corriger → répéter → Le contexte de la session se remplit de bruit → Les mauvaises hypothèses se cumulent en fonctionnalités cassées → Un ingénieur ne peut faire qu'une seule chose à la fois → Chaque fonctionnalité attend que la bonne personne soit disponible

Après l'usine :

→ Chaîne structurée : recherche → histoire → brief → construction → vérification → validation → Chaque agent reçoit une fenêtre de contexte propre avec seulement ce dont il a besoin → Les mauvaises hypothèses sont attrapées à l'approbation du brief — pas après 10 fichiers → Un ingénieur livre une tranche verticale complète : back-end, front-end, tests, validation → La meilleure connaissance de l'équipe vit dans les agents — pas piégée dans les personnes

Le vrai changement :

Le spécialiste des paiements construit un agent d'intégration de paiements.

Maintenant, chaque ingénieur de l'équipe peut livrer une fonctionnalité qui touche à la facturation.

Sans attendre.

Sans transfert.

Les modèles de composants du lead front-end vivent dans l'agent constructeur front-end.

Les vérifications CI de l'ingénieur DevOps vivent dans un hook.

Les cas limites du lead QA vivent dans les règles du vérificateur de tests.

Connaissances d'expert, partagées sous forme d'agents.

Pas piégées dans la disponibilité.

COMMENT CONSTRUIRE LE VÔTRE CE WEEK-END

Liste de vérification en 8 étapes :

1. Installez Claude Code → code.claude.com

2. Créez la structure de dossiers : → .claude/agents/ → .claude/skills/feature-factory/ → .claude/skills/build-with-tests/ → .claude/hooks/

3. Écrivez votre CLAUDE.md (100–300 lignes : stack, commandes, règles d'architecture, liste des choses à ne pas faire)

4. Créez les 7 agents en utilisant la commande /agents dans Claude Code. Décrivez le rôle de chaque agent. Claude écrit le fichier. Vous révisez et validez.

5. Créez la compétence d'orchestrateur feature-factory. Demandez à Claude de l'écrire — il lit vos 7 fichiers d'agents et câble la chaîne.

6. Créez la compétence build-with-tests. Décrit comment votre équipe construit : correspondre aux modèles existants, écrire des tests en même temps que le code, exécuter la vérification de type à la fin.

7. Ajoutez un hook pre-commit. Bloque les commits qui incluent des fichiers .env, .key, .pem ou secrets.json. Prend 5 minutes. Empêche les catastrophes.

8. Exécutez une vraie fonctionnalité à travers la chaîne complète. Choisissez quelque chose de petit. Observez où ça bute. Ajoutez des règles. L'usine se règle d'elle-même.

Temps total : 2 à 3 heures.

Ensuite, exécutez quelques fonctionnalités.

Après 3 ou 4, l'usine connaît votre code source.

Vous passerez moins de temps à superviser.

Plus de temps à décider quoi construire ensuite.

LES 7 AGENTS — RÉFÉRENCE RAPIDE

→ Chercheur — cartographie le code avant que quoi que ce soit ne soit construit (Lecture uniquement) → Rédacteur d'Histoires Utilisateur — transforme une idée en histoire utilisateur avec des critères d'acceptation (Lecture uniquement) → Rédacteur de Spécifications — transforme l'histoire en brief technique (Lecture uniquement) → Constructeur Back-End — construit l'API, les services, les jobs, les tests unitaires (dossiers back-end uniquement) → Constructeur Front-End — construit les composants, pages, hooks, tests IHM (dossiers front-end uniquement) → Vérificateur de Tests — écrit des tests d'acceptation par rapport à l'histoire utilisateur (fichiers de test uniquement) → Validateur — compare l'implémentation avec l'histoire et le brief, signale les écarts (Lecture uniquement)

3 points de contrôle humains :→ Approuver l'histoire → Approuver le brief → Approuver la PR

Tout le reste s'exécute tout seul.

La plupart des développeurs utilisant Claude Code font encore du vibe coding.

Demander → générer → corriger → espérer.

Ce n'est pas mal.

C'est juste un plafond.

L'usine ne vous retire pas du processus.

Elle vous retire des parties qui n'ont pas besoin de vous.

Vous restez dans la boucle où votre jugement compte :

Est-ce le bon problème ? Est-ce la bonne conception ? Est-ce sûr à livrer ?

Les agents gèrent tout ce qui se trouve entre les deux.

C'est la différence entre utiliser l'IA comme un clavier plus rapide —

et utiliser l'IA comme une équipe coordonnée.

Si cela a été utile :

→ Republiez pour le partager avec votre réseau → Suivez @sairahul1 pour plus d'analyses comme celle-ci → Mettez-le en favori — vous voudrez vous référer aux 7 agents

J'écris sur l'IA, la création de produits et les systèmes qui fonctionnent pendant que vous dormez.