Claude Octopus Dark Factory : de la spec au code testé sans intervention

Le Dark Factory Mode est la fonctionnalité la plus radicale de Claude Octopus. Le principe tient en une ligne : vous fournissez une spec en Markdown, l’outil pilote le pipeline complet de développement, recherche, cadrage, implémentation, livraison, et vous remettez du code testé en sortie.

Vous reviewez le résultat, pas chaque étape intermédiaire.

Ce mode n’est pas fait pour remplacer le développeur. Il est fait pour les tâches où vous savez exactement ce que vous voulez mais n’avez pas envie de piloter manuellement 50 commandes pour y arriver. Une feature bien délimitée, un module isolé, un prototype à tester rapidement.

Avant de lire ce guide, vérifiez que Claude Octopus est installé et fonctionnel sur votre machine, consultez notre guide d’installation si ce n’est pas le cas. Pour une vue d’ensemble de tout ce que fait Claude Octopus, notre guide complet couvre le reste.

---

Ce qu’est réellement le Dark Factory Mode

Le nom “Dark Factory” vient du concept industriel des usines entièrement automatisées qui tournent “dans le noir”, sans présence humaine. L’analogie est claire : vous configurez le pipeline, lancez la production, récupérez le résultat.

Concrètement, /octo:embrace en mode autonome sur une spec bien rédigée déclenche les 4 phases du framework Double Diamond :

Discover (Probe) : les agents analysent la spec, recherchent du contexte, explorent les approches possibles, identifient les contraintes et dépendances. Cette phase est délibérément large, c’est la divergence.

Define (Grasp) : le pipeline se resserre. Les agents définissent l’architecture, les interfaces, les contrats entre composants, les critères de succès. C’est à cette étape que le “quoi” devient un “comment précis”.

Develop (Tangle) : l’implémentation. Le gate à 75% s’applique : le code généré est validé par plusieurs agents avant d’avancer. Le travail qui ne passe pas le seuil de qualité est refait, pas juste signalé.

Deliver (Ink) : tests, review de sécurité et de performance, préparation au merge. Le “holdout testing”, des tests sur des cas que l’IA n’a pas vus pendant le développement, vérifie que le code se généralise correctement.

À la fin, vous avez un résultat avec un satisfaction score. Si le score est insuffisant, le pipeline vous le dit clairement.

---

Les 3 niveaux d’autonomie

Supervisé : vous validez chaque phase

Le pipeline s’arrête après chaque étape et vous demande confirmation avant de continuer.

/octo:embrace --mode supervised

Recommandé pour vos premières utilisations du Dark Factory Mode. Vous gardez la main à chaque transition, vous comprenez ce que chaque phase produit, et vous pouvez ajuster la spec si la direction prise ne vous convient pas.

Semi-autonome : intervention sur échec seulement

Le pipeline tourne seul mais vous notifie si une phase échoue ou si le satisfaction score d’une étape est insuffisant.

/octo:embrace --mode semi-autonomous

Le bon équilibre pour la majorité des cas. Vous faites autre chose pendant que le pipeline tourne, vous intervenez seulement si quelque chose se bloque.

Autonome : pipeline complet

Le pipeline tourne du début à la fin sans interruption. Vous récupérez le résultat une fois le delivering terminé.

/octo:embrace --mode autonomous

À utiliser quand vous faites confiance au setup (vous avez déjà utilisé le mode supervisé sur des tâches similaires) et que la spec est suffisamment précise pour ne pas laisser place à l’interprétation.

---

Écrire une spec Markdown qui donne de bons résultats

La qualité de la spec est le facteur le plus important pour un bon résultat en Dark Factory Mode. Un pipeline bien configuré ne rattrape pas une spec floue.

Structure recommandée

# Nom de la feature

## Objectif
[Ce que la feature doit accomplir, en une ou deux phrases. Pas de jargon interne.]

## Contexte
[Où cette feature s'insère dans le projet. Stack technique, contraintes existantes.]

## Comportement attendu
[Ce que ça fait, step by step, du point de vue utilisateur ou API.]

## Contraintes techniques
[Librairies à utiliser, à éviter. Compatibilité requise. Contraintes de performance.]

## Definition of Done
[Critères précis et vérifiables. Chaque critère doit pouvoir être évalué à true/false.]

## Ce qui est hors scope
[Explicitement ce que cette spec ne couvre pas, pour éviter la dérive.]

La Definition of Done est critique

C’est elle qui pilote le holdout testing. Si votre DoD est vague, les tests seront vagues. Si elle est précise, les tests seront précis.

Exemple de DoD faible :

- Le système doit fonctionner correctement
- Les erreurs doivent être gérées

Exemple de DoD solide :

- Un appel POST /api/users avec email valide retourne 201 + le user créé en JSON
- Un appel POST /api/users avec email déjà existant retourne 409 + message d'erreur
- Un appel POST /api/users avec email invalide retourne 422 + liste des erreurs de validation
- Tous les endpoints sont couverts par des tests d'intégration
- Aucune query SQL en N+1 sur les endpoints de listing

Les erreurs de spec qui font dérailler le pipeline

La spec ambiguë : “le système doit être rapide” ne veut rien dire. “Les endpoints doivent répondre en moins de 200ms sous une charge de 100 req/s” est une contrainte testable.

La spec trop large : le Dark Factory Mode est fait pour des features délimitées, pas pour refactorer un monolith entier. Si votre spec décrit plus de 3-4 fichiers principaux à créer ou modifier, découpez-la.

L’absence de contexte stack : le pipeline doit savoir avec quoi il travaille. Mentionnez explicitement le langage, le framework, les versions importantes.

Le manque de cas limites : si vous ne décrivez pas comment gérer les erreurs, l’IA inventera sa propre gestion d’erreurs, qui ne correspondra peut-être pas à vos conventions.

---

Exemple concret : générer un module d’authentification JWT

Voici une spec réaliste et ce qu’elle produit.

La spec

# Module d'authentification JWT

## Objectif
Ajouter l'authentification JWT à une API Express existante, avec refresh tokens.

## Contexte
API Express 4.x, Node.js 20+, TypeScript strict. ORM Prisma avec PostgreSQL.
La table users existe déjà (id uuid, email, password_hash).
Pattern existant pour les handlers : async/await, zod pour la validation.

## Comportement attendu
- POST /auth/login : email + password → access_token (15min) + refresh_token (7j)
- POST /auth/refresh : refresh_token → nouveau access_token
- POST /auth/logout : invalide le refresh_token
- Middleware authenticateJWT : vérifie le Bearer token, injecte req.user

## Contraintes techniques
- jsonwebtoken ^9.0
- bcryptjs pour la vérification du password_hash existant
- Les refresh tokens sont stockés en base (table refresh_tokens à créer)
- Pas de cookie, uniquement Bearer token dans les headers
- Ne pas modifier les handlers existants

## Definition of Done
- POST /auth/login avec credentials valides retourne 200 + les deux tokens
- POST /auth/login avec mot de passe incorrect retourne 401
- POST /auth/login avec email inexistant retourne 401 (pas de distinction)
- POST /auth/refresh avec token valide retourne 200 + nouveau access_token
- POST /auth/refresh avec token expiré retourne 401
- POST /auth/logout invalide le refresh token (test : le refresh après logout retourne 401)
- Le middleware authenticateJWT retourne 401 sans header Authorization
- Le middleware retourne 401 avec un token expiré ou invalide
- Tests d'intégration pour tous les cas ci-dessus
- Migration Prisma pour la table refresh_tokens incluse

## Hors scope
- Rate limiting (déjà géré par un middleware global existant)
- Envoi d'email de vérification
- Reset de mot de passe

Ce que le pipeline produit

En mode semi-autonome, le pipeline prend environ 4-8 minutes selon les providers configurés. En sortie :

• src/routes/auth.ts – les 3 routes avec handlers
• src/middleware/authenticateJWT.ts – le middleware
• src/lib/jwt.ts – les utilitaires de génération et vérification
• prisma/migrations/xxx_add_refresh_tokens.sql – la migration
• tests/auth.test.ts – les tests d’intégration (tous les cas de la DoD)
• Un rapport de satisfaction score avec les résultats des holdout tests

Si le satisfaction score est inférieur au seuil, le pipeline indique quels critères de la DoD n’ont pas été satisfaits et pourquoi.

---

Dark Factory vs pipeline manuel : quand choisir quoi ?

Privilégiez le Dark Factory Mode pour :

• Features isolées avec des contrats d’API clairs (endpoints CRUD, modules utilitaires, intégrations tierces)
• Prototypage rapide à évaluer avant de décider si on investit
• Tâches répétitives sur lesquelles vous avez déjà de l’expérience (vous savez exactement ce que vous voulez, vous ne voulez pas piloter manuellement)
• Onboarding technique : donner à un nouveau dev une spec précise à faire passer en Dark Factory pour valider sa compréhension du codebase

Gardez le mode manuel (ou supervisé) pour :

• Refactoring de code legacy complexe
• Décisions d’architecture structurantes qui méritent débat (voir /octo:brainstorm)
• Code critique où vous voulez comprendre chaque ligne produite
• Premières utilisations sur un projet que le pipeline ne connaît pas encore

La mémoire persistante cross-session de Claude Octopus (via claude-mem) améliore les résultats au fil du temps : les décisions d’architecture passées, le style de code du projet et les patterns réussis sont réinjectés dans les sessions suivantes.

---

Intégration dans un workflow CI/CD

Pour aller plus loin, le Dark Factory Mode peut s’intégrer dans votre pipeline CI :

1. Une spec Markdown est commitée dans un dossier dédié (specs/)
2. Un workflow GitHub Actions détecte le nouveau fichier
3. Il lance Claude Octopus en mode autonome sur la spec
4. La PR est créée automatiquement avec le code généré
5. Le Code Review officiel d’Anthropic (Teams/Enterprise) ou Claude Octopus lui-même analyse la PR

Ce pattern est particulièrement intéressant pour les équipes qui itèrent rapidement sur des features bien définies. Pour la mise en place du Code Review automatisé dans ce workflow, consultez notre comparatif Code Review officiel vs Claude Octopus.

---

FAQ Dark Factory Mode