J'ai construit un pipeline d'auto-generation d'apps avec Claude Code

Depuis quelques mois je n'utilise plus Claude Code comme un assistant. Je l'utilise comme un operateur. La difference n'est pas dans le modele, elle est dans la chaine d'outillage que j'ai construite autour. Cet article documente ce pipeline : a quoi il sert, comment il est decoupe, et pourquoi chaque etape existe.

Le probleme : de l'idee a l'app, le chemin est long

Quand on me demande "tu peux me coder une app qui fait X ?", la vraie distance entre l'idee et la production passe par une dizaine d'etapes qu'on a tendance a sauter :

• preciser ce qu'on veut vraiment (et ce qu'on ne veut pas),
• ecrire des specs ou au moins un brief structure,
• decouper en tickets atomiques,
• identifier les hypotheses critiques avant de coder massivement,
• coder, tester, revoir, deployer,
• mesurer la derive entre la spec et le livre.

Avec un agent assez puissant pour generer du code en volume, sauter ces etapes coute cher : on accumule de la dette technique invisible, on refait deux fois la meme chose, on s'apercoit en prod que la fonctionnalite centrale n'est pas celle qu'on imaginait.

Le pipeline que je decris ici est ma reponse a ce probleme.

Vue d'ensemble

Le flow standard d'un nouveau projet ressemble a ca :

/app-bootstrap   →  intake interactif, on cadre la demande
/app-refine      →  on raffine les zones floues (boucle)
/app-spec        →  on synthetise en spec + decisions + non-goals
/app-plan        →  on decoupe en tickets atomiques
/app-derisk      →  on identifie les assumptions critiques
/app-validate    →  revue critique adversariale (optionnelle)
/app-execute     →  UN tick : selection, agents en parallele, merge
/loop            →  on boucle jusqu'au backlog vide

Chaque etape produit des artefacts versionnes dans un dossier .app/ :

.app/
├── INTAKE.md         ← phase 1 : la demande brute, raffinee
├── SPEC.md           ← phase 2 : la spec rigoureuse
├── DECISIONS.md      ← alternatives ecartees + raisons
├── NON_GOALS.md      ← ce qu'on ne fera pas
├── PLAN.md           ← vue narrative du decoupage
├── tickets/
│   ├── todo/         ← un .md par ticket
│   ├── in_progress/
│   └── done/
├── STATE.md          ← compteurs, dependances
├── METRICS.md        ← tokens, temps, retries
└── DASHBOARD.md      ← vue tableau auto-regenere

L'idee centrale : le projet est un repository d'etat lisible par un humain autant que par l'agent. Si je veux reprendre un projet apres trois semaines, je relis le SPEC + DASHBOARD et je sais ou j'en suis.

Phase 1 — l'intake : forcer la conversation que tout le monde saute

/app-bootstrap lance un intake interactif. L'agent ne suppose pas ; il pose des questions :

• qui sont les utilisateurs cibles ?
• quel est le critere de succes ?
• quelles integrations sont obligatoires ?
• quelle stack ou contraintes infra ?
• qu'est-ce qu'on ne veut pas faire ?

La sortie est un INTAKE.md qui n'est pas une spec mais un brief riche. C'est la couche de comprehension partagee entre l'humain et l'agent.

Puis /app-refine peut etre rappele autant de fois que necessaire pour traquer les ambiguites. Concretement, il repere les zones ou l'agent a ete oblige de "deviner", pose des questions ciblees, et applique les corrections. C'est la version automatisee du "attends, dis-m'en plus" qu'un bon chef de projet fait en reunion.

Phase 2 — la spec : du brief a la regle

/app-spec transforme l'intake en :

• une spec rigoureuse (regles metier, schemas de donnees, comportements attendus),
• un fichier DECISIONS.md qui liste les choix faits et les alternatives ecartees avec la raison. C'est ce qui evite a la prochaine session de remettre en cause des decisions deja prises,
• un NON_GOALS.md explicite. Aussi important que les goals : il borne le scope.

Phase 3 — le plan : atomiser le travail

/app-plan decoupe la spec en tickets. Un ticket = une unite executable par un agent dans une seule session, sans surprise. Chaque ticket vit dans .app/tickets/todo/<id>.md avec :

• un titre,
• un objectif,
• des criteres d'acceptation testables,
• une estimation de complexite,
• des dependances avec d'autres tickets.

PLAN.md est la vue narrative — utile pour expliquer le projet a un humain. DASHBOARD.md est la vue tableau, auto-regeneree a chaque tick d'execution.

Phase 3.5 — derisk : la phase qui m'a sauve plusieurs fois

/app-derisk est la phase que j'ai ajoutee tardivement, et qui me semble retrospectivement evidente.

Avant de lancer l'execution massive du backlog (qui peut representer 30+ tickets), on identifie les assumptions critiques non verifiees :

• "le SDK X supporte bien le mode Y" — vrai ?
• "on peut faire passer ce volume dans cette API" — vrai ?
• "cette lib fonctionne dans un container Alpine" — vrai ?
• "ce service externe a une API stable" — vrai ?

Pour chaque assumption critique, on cree un ticket spike avec un derisk_gate: true. Tant que ces spikes ne sont pas valides, le worker refuse de demarrer les tickets dependants. Cout : 2-3 heures de spikes. Benefice : on n'ecrit pas 5000 lignes de code pour decouvrir que l'assumption #2 etait fausse.

Phase 4 — execute : le tick

/app-execute n'est pas la phase "fait tout le boulot". C'est un seul tick :

1. lit STATE.md pour savoir ou on en est,
2. selectionne les tickets prets (deps satisfaites, pas de gate ouvert),
3. lance les agents en parallele, chacun dans son worktree git pour eviter les conflits,
4. attend, valide les criteres d'acceptation,
5. merge les branches qui passent,
6. met a jour STATE.md / METRICS.md / DASHBOARD.md,
7. pose un lock anti-overlap pour qu'un second tick ne lance pas les memes tickets.

Auto-pause sur quota epuise. Reprise propre via /app-resume.

L'orchestration est faite par /loop /app-execute : un tick toutes les N minutes jusqu'a ce que le backlog soit vide.

Les revues : 6 angles en parallele

Une fois la livraison stabilisee, je lance /dev-report-all qui execute 6 revues en parallele :

• UX : design, ergonomie, accessibilite
• BA : conformite aux specs et regles metier
• Code : qualite, lisibilite, maintenabilite
• Securite : pentest defensif
• Test : couverture, robustesse, pertinence
• Archi : couplage, boundaries, scalabilite

Chaque revue produit un dev-report-<angle>.md versionne. Sur les gros projets, je lance aussi /app-drift-check : un sous-agent independant audite l'ecart entre la spec et le code livre. C'est rare qu'il ne trouve rien.

Ce que ce pipeline change concretement

Trois observations apres plusieurs dizaines de projets passes par cette chaine :

1. Le cout du contexte baisse. Quand je reprends un projet apres trois semaines, je lis SPEC + DASHBOARD + dernier METRICS et je sais ou j'en suis. Avant, je passais 20 minutes a "me rappeler" en lisant le code.

2. Les bugs metiers diminuent. Pas les bugs techniques — ceux-la, on les a toujours. Mais les bugs du genre "ah, en fait ce n'est pas du tout ce que je voulais" sont presque elimines, parce que SPEC + DECISIONS + NON_GOALS forcent a verbaliser les ambiguites en amont.

3. Le projet survit a la fin de la session. C'est l'effet le plus sous-estime : un projet pilote par ce flow est reprenable par un autre humain ou un autre agent demain, sans contexte oral.

Limites honnetes

Ce pipeline n'est pas adapte a tout :

• Pour un script de 50 lignes : c'est de l'overkill. Je tape directement.
• Pour de l'exploration pure (essayer une lib, prototyper une idee) : la phase d'intake bride. On veut juste coder.
• Pour un projet ou la spec change tous les jours : le cycle bootstrap → spec → plan perd son sens. On passe son temps a refaire l'amont.

Le sweet spot, c'est le projet ou on sait globalement ce qu'on veut, ou il y a au moins 10-15 unites de travail, et ou on n'a pas envie de devoir tout reverifier dans six semaines.

Ce qui reste a faire

Quelques chantiers ouverts cote pipeline :

• une commande /app-cost-estimate qui chiffre le projet en tokens avant de lancer (utile pour decider si on y va),
• une meilleure integration avec ProjectNotes pour tracer les tickets agent dans le meme outil que les tickets humains,
• un mode "shadow" ou un second agent revoit en silence les decisions du premier pendant que je dors.

Si tu veux discuter du pipeline, des outils, ou si tu veux que je t'aide a en monter un equivalent, contacte-moi : julien@tscherrig.com.