260 commits en 8 jours avec 12 agents Claude

Le contexte

ComRenov est une franchise de rénovation énergétique. Leur stack technique : JotForm pour les formulaires, Make.com pour l’automatisation, Google Sheets pour le suivi. Ça fonctionnait. Jusqu’au jour où ça n’a plus fonctionné - un scénario Make.com qui plante, des données perdues entre deux étapes, et personne capable de debugger le pipeline.

La demande : remplacer tout ça par une plateforme custom. CRM, gestion des devis, suivi des chantiers, pipeline commercial, multi-tenant pour les franchises. Le genre de projet qui prend normalement trois mois avec une équipe de quatre.

J’ai dit huit jours. Avec douze agents Claude.

L’organisation en agents

Pas douze instances de Claude qui font n’importe quoi en parallèle. Douze agents spécialisés, chacun avec un rôle précis et un périmètre défini.

• Agent Architecture : schémas de base, décisions techniques, structure des modules
• Agent Backend Core : NestJS, modules métier, services, controllers
• Agent Backend Auth : authentification, rôles, permissions, multi-tenant isolation
• Agent Backend Pipeline : le moteur de saga, les étapes du pipeline commercial
• Agent Frontend Core : Angular, composants partagés, layout, navigation
• Agent Frontend Forms : formulaires réactifs, validation, logique conditionnelle
• Agent Frontend Dashboard : tableaux de bord, graphiques, widgets
• Agent Tests Backend : tests unitaires et d’intégration NestJS
• Agent Tests E2E : Playwright, scénarios utilisateur complets
• Agent DevOps : Docker, CI/CD, migrations, seeds
• Agent Documentation : OpenAPI, commentaires JSDoc, guides
• Agent Review : relecture du code des autres agents, détection d’incohérences

Chaque agent recevait un brief détaillé avec les interfaces attendues, les conventions de nommage, les patterns à suivre. Le brief incluait les types TypeScript des entités voisines pour éviter les incompatibilités.

Le rythme

260 commits en 8 jours. Ça fait 37 commits par jour en moyenne. Le record : 133 commits en une seule journée. C’était le jour 2 (4 mars), quand le multi-tenant, la saga DAG, la sécurité, Docker, le CI/CD et les tests avançaient en parallèle.

Le rythme réel ressemblait à ça :

• 6h-8h : planification, briefing des agents, définition des interfaces
• 8h-12h : première vague de génération, review en continu
• 12h-13h : merge, résolution de conflits, tests d’intégration
• 13h-14h : pause. Sortir de l’écran. Réfléchir à ce qui bloque.
• 14h-18h : deuxième vague, corrections, nouveaux agents sur les zones faibles
• 18h-20h : stabilisation, tests E2E, commit de fin de journée

La fatigue n’était pas physique. C’était cognitive. Garder la cohérence entre douze flux de code parallèles demande une attention constante. Une décision d’architecture prise à 8h par l’agent Backend devait être propagée aux agents Frontend avant 9h, sinon les interfaces divergeaient.

L’architecture

NestJS en backend avec une structure modulaire classique. Chaque domaine métier dans son propre module : clients, devis, chantiers, pipeline, documents, franchises.

Le pattern SSOT (Single Source of Truth) partout. Chaque entité a une source unique. Pas de duplication de données entre modules. Les références se font par ID avec des relations Prisma.

model Submission {
  id          String   @id @default(uuid())
  reference   String
  status      SubmissionStatus @default(DRAFT)
  franchiseId String
  franchise   Franchise @relation(fields: [franchiseId], references: [id])
  data        Json
  totalHT     Decimal  @default(0) @db.Decimal(10, 2)
  createdAt   DateTime @default(now())
}

Le multi-tenant repose sur l’isolation par franchise. Les secrets d’intégration (Axonaut, Google Drive, Sheets, SMTP) sont chiffrés AES-256-GCM et isolés par département. Un RBAC à 3 rôles (super_admin, admin, viewer) contrôle les accès.

Le moteur de saga

Le cœur du système. Un pipeline commercial en étapes : prospection, qualification, visite technique, devis, signature, travaux, réception, facturation. Chaque étape a des préconditions, des actions automatiques, et des transitions possibles.

const pipelineDefinition: SagaDefinition = {
  steps: [
    {
      id: 'qualification',
      name: 'Qualification du lead',
      preconditions: ['client.telephone', 'client.adresse'],
      actions: [
        { type: 'notification', target: 'commercial' },
        { type: 'task', template: 'relance-48h' },
      ],
      transitions: [
        { to: 'visite-technique', condition: 'qualificationScore >= 70' },
        { to: 'archive', condition: 'qualificationScore < 30' },
      ],
    },
    // ... 7 autres étapes
  ],
};

Le DAG (Directed Acyclic Graph) permet des chemins non linéaires. Un devis refusé peut revenir en visite technique. Un chantier peut générer un avenant qui repart en qualification. Le moteur gère les boucles avec un compteur de visites par étape pour éviter les cycles infinis.

L’implémentation a pris deux jours complets. L’agent Backend Pipeline générait la structure, je validais la logique métier avec le client, et l’agent Tests écrivait des scénarios pour chaque transition. 47 tests rien que sur le moteur de saga.

Ce qui a marché

La spécialisation des agents. Donner à chaque agent un périmètre restreint avec des interfaces claires produit du code plus cohérent que de demander à un seul agent de tout faire. L’agent Frontend Forms ne connaissait pas l’implémentation backend - il connaissait les types TypeScript et les endpoints OpenAPI. Ça suffit.

La review croisée. L’agent Review recevait le code des autres agents et détectait les incohérences : un champ renommé dans le backend mais pas dans le frontend, un endpoint qui retourne un objet mais que le front attend comme un tableau, une validation manquante.

Le pattern SSOT. Quand tous les agents utilisent les mêmes types importés depuis un package @comrenov/shared, les incompatibilités se réduisent drastiquement. Le compilateur TypeScript attrape les divergences avant même de lancer les tests.

Ce qui a cassé

Les migrations. Quand trois agents modifient le schéma Prisma en parallèle, les migrations se marchent dessus. J’ai dû fusionner manuellement les migrations plusieurs fois en huit jours. La solution aurait été de sérialiser les changements de schéma - un seul agent à la fois touche à la base.

Les imports circulaires. Le module pipeline importait le module clients qui importait le module pipeline. NestJS tolère ça avec forwardRef(), mais c’est un signe que l’architecture a un problème. J’ai dû extraire un module shared-services pour casser le cycle.

Les 772 tests

Le chiffre dont je suis le plus fier. 772 tests à la fin des 8 jours. Répartition :

• 312 tests unitaires backend (services, guards, pipes)
• 187 tests d’intégration backend (controllers avec base de test)
• 143 tests unitaires frontend (composants, services)
• 82 tests E2E Playwright (parcours utilisateur complets)
• 48 tests du moteur de saga (transitions, préconditions, rollback)

Le coverage global : 78%. Pas parfait, mais suffisant pour déployer avec confiance. Les agents Tests avaient pour consigne de couvrir les chemins critiques en priorité : authentification, pipeline de saga, calcul des devis, isolation multi-tenant.

Le jour des 133 commits

Le jour 2. Le pipeline de saga avançait côté backend, les formulaires côté frontend, le DevOps montait le Docker Compose, et l’agent Review détectait des problèmes que je corrigeais en temps réel.

Le rythme était insoutenable en théorie. En pratique, chaque commit était petit - un composant, un test, un fix. Le git log ressemblait à un flux continu de micro-avancées. Pas de gros commits de 500 lignes, mais des dizaines de commits de 20-50 lignes.

C’est la force du multi-agent. Chaque agent produit des unités atomiques. Le merge est simple parce que les périmètres sont disjoints. Le risque de conflit est faible parce que chaque agent travaille dans ses propres fichiers.

Sauf pour les migrations. Toujours les migrations.

Livraison

Jour 8, 19h. Le client se connecte à la plateforme de staging. Il crée un lead, le qualifie, planifie une visite technique, génère un devis, le fait signer électroniquement, lance le chantier, et facture. Le parcours complet fonctionne.

Son commentaire : “C’est plus rapide que ce qu’on avait avec Make.com, et je comprends ce qui se passe à chaque étape.”

C’est exactement le but. Remplacer une boîte noire no-code par un système transparent. Les scénarios Make.com sont devenus des étapes de saga documentées. Les formulaires JotForm sont devenus des composants Angular testables. Les Google Sheets sont devenus des dashboards avec de vrais indicateurs.

Ce que j’en retiens

Coordonner douze agents IA, c’est un travail de chef d’orchestre. Le code se génère vite, mais la cohérence architecturale reste une responsabilité humaine. Les interfaces partagées, les conventions de nommage, les patterns imposés - c’est ce qui fait la différence entre un tas de code et un système.

Le rythme de 260 commits en 8 jours n’est pas reproductible sur le long terme. C’était un sprint, pas un marathon. Mais ça montre ce qui est possible quand on structure la collaboration humain-IA correctement : des briefs précis, des périmètres clairs, et une review continue.

La prochaine fois, je sérialise les migrations.