AI Product Factory : comment une idée devient une pull request revue

Flux

1. Idée. Un message : un paragraphe décrivant le produit ou la fonctionnalité.
2. Découverte. La skill discover étudie le marché, les produits existants, la réglementation et la faisabilité, puis produit une étude d'opportunité sourcée et un verdict GO / PIVOT / NO-GO. Un NO-GO s'arrête ici.
3. Spécification. Un REQUIREMENTS.md pré-rempli où chaque hypothèse est marquée et les questions ouvertes regroupées (sept au plus), puis la suite documentaire : PRD, architecture, modèle de données, API, ADR, runbook, brief de design.
4. Porte 1, approbation de la spécification (humain). Un message, lisible partout, y compris sur un téléphone. Aucun code de fonctionnalité avant l'approbation.
5. Design dans Figma ou Claude Design. Par le serveur MCP de Figma, ou Claude Design selon le projet : page de marque avec trois pistes de logo, variables, composants, écrans clés bureau et mobile, flux prototypés.
6. Porte 2, boucle de design (humain). Autant d'itérations que nécessaire jusqu'à l'approbation, puis le design est gelé dans le dépôt sous forme de jetons, d'écrans et de code de référence.
7. Construction. Tranches verticales guidées par les tests, chacune vérifiée contre le design gelé. Chaque tranche se termine avec build, typage, lint et tests au vert.
8. Boucle qualité. Revue de code et revue de sécurité automatisées, puis une boucle revue → correction jusqu'à ce que la revue revienne propre.
9. Livraison. Une commande ouvre une pull request squash vers la branche dev et la fusionne. La promotion en production est une pull request distincte, manuelle, que je suis seul à ouvrir.

Portes humaines

Deux approbations (spécification, design) et un acte manuel (promotion en production). Tout le reste tourne sans surveillance ; les actions risquées ou tournées vers l'extérieur remontent en notification push et attendent.

Chaque dépôt porte un CLAUDE.md avec ses propres règles : lire les exigences d'abord, respecter le design gelé, suivre la politique de livraison, aucune signature d'attribution dans les commits.

Ce qui ne part jamais au LLM

Les secrets, les clés de signature et les données personnelles : ignorés par git et provisionnés dans la CI comme secrets chiffrés par un script qui ne les affiche jamais.

La branche de production : les agents peuvent fusionner dans dev, jamais dans main.

Décisions et pourquoi

Pourquoi uniquement des outils de première partie. Trois produits d'orchestration tiers ont fermé en un an. L'usine repose sur Claude Code Remote Control et des scripts shell : rien ne peut disparaître avec un fournisseur.

Pourquoi des artefacts sous forme de fichiers. Exigences, ADR et jetons de design vivent dans le dépôt : une nouvelle session, un nouvel agent ou un réviseur humain partent de la même vérité.

Pourquoi des skills plutôt que des prompts. Une skill est versionnée, testable et partagée entre projets ; un prompt dans une conversation est perdu.

Pourquoi un humain seulement aux portes. Cela garde la cadence des agents sans abdiquer la responsabilité de ce qui part en production.

Chiffres

17 dépôts sous l'usine, sur GitHub et Azure DevOps, chacun avec son fichier de politique.

Un site corporatif bilingue mené de l'idée à la production en 8 jours et 32 commits ; un site d'une page en une journée.

Pilume, plateforme de cinq applications avec 66 fichiers de tests et 15 ADR, construite en 10 semaines.

4 skills maison (discover, figma-studio, design-handoff, research-document) en plus des skills standard de planification, de TDD et de revue.

Pile technique

Claude Code (Remote Control, skills, sous-agents) · Model Context Protocol (Figma, GitHub, Azure DevOps, Todoist) · Bash et Python · tmux sur Ubuntu · edge Caddy · API GitHub et Azure DevOps