Étude de cas : comrenov

1. Contexte et objectifs

Problématique métier

Comrenov gérait son flux de demandes de rénovation avec un assemblage d'outils SaaS : JotForm pour les formulaires et Make.com pour l'automatisation. Ce setup posait des problèmes critiques :

• Pas de contrôle sur le pipeline de traitement des demandes
• Perte de données lors des synchronisations Make.com
• Aucune visibilité temps réel sur l'état des demandes
• Impossibilité de personnaliser le parcours formulaire
• Coûts récurrents élevés (JotForm + Make.com + plugins)

Pourquoi remplacer ?

2. Architecture monorepo

4 packages npm workspaces

Le projet est organisé en monorepo avec 4 packages distincts partageant des types TypeScript via @comrenov/shared :

comrenov/
├── packages/
│   ├── frontend/      # Lit 3 — formulaire public
│   ├── backend/       # NestJS 11 — saga pipeline
│   ├── admin/         # Angular 21 — dashboard
│   └── shared/        # Types partagés
├── e2e/               # Playwright E2E
└── tools/scripts/     # SSOT sync, utilities

3. Pipeline saga

Architecture du pipeline

Le coeur du système est un pipeline saga NestJS qui remplace les scénarios Make.com. Chaque étape est un handler indépendant avec retry automatique et logging structuré :

// Pipeline saga — chaque étape est un handler indépendant
@Injectable()
export class RequestPipeline {
  async process(request: RenovationRequest) {
    await this.validate(request);
    await this.deduplicate(request);
    await this.syncAxonaut(request);
    await this.uploadToDrive(request);
    await this.notifyAdmin(request);
  }
}

4. 11 agents Claude spécialisés

Comrenov utilise le plus grand nombre d'agents Claude spécialisés sur un seul projet dans mon lab. Chaque agent a son domaine de compétence et ses propres instructions :

## Agents Claude (11 spécialisés)

### Backend agents
- `backend-api` : Routes NestJS, controllers, DTOs
- `backend-saga` : Pipeline saga, handlers, retry
- `backend-axonaut` : Intégration CRM Axonaut
- `backend-drive` : Google Drive upload, permissions
- `backend-security` : Chiffrement AES-256-GCM, JWT

### Frontend agents
- `frontend-form` : Formulaire Lit 3, validation
- `frontend-shared` : Composants et styles partagés

### Admin agents
- `admin-dashboard` : KPIs, graphiques, tableaux
- `admin-auth` : Login, rôles, guards

### Cross-cutting agents
- `e2e-tests` : Playwright, scénarios critiques
- `ssot-sync` : Google Sheets sync bidirectionnel

5. SSOT Google Sheets

Source de vérité externe

Les données de référence (types de travaux, zones géographiques, barèmes) sont gérées dans Google Sheets par l'équipe non-technique, puis synchronisées automatiquement dans la base PostgreSQL :

// Synchronisation bidirectionnelle Google Sheets
@Injectable()
export class SSOTSyncService {
  async syncFromSheets(): Promise<SyncResult> {
    const rows = await this.sheets.getRows(SSOT_RANGE);
    const parsed = this.parseReferenceData(rows);

    for (const item of parsed) {
      await this.prisma.referenceData.upsert({
        where: { externalId: item.id },
        create: item,
        update: item,
      });
    }

    return { synced: parsed.length, source: 'sheets' };
  }
}

6. Sécurité

Chiffrement et authentification

Le projet implémente un niveau de sécurité avancé pour protéger les données personnelles des demandeurs de rénovation :

// Chiffrement AES-256-GCM pour les clés API
@Injectable()
export class EncryptionService {
  private readonly algorithm = 'aes-256-gcm';

  encrypt(plaintext: string): EncryptedPayload {
    const iv = randomBytes(16);
    const cipher = createCipheriv(this.algorithm, this.key, iv);
    const encrypted = Buffer.concat([
      cipher.update(plaintext, 'utf8'),
      cipher.final(),
    ]);
    const tag = cipher.getAuthTag();
    return { encrypted, iv, tag };
  }
}

7. Métriques et résultats

Activité du projet

Ratio sessions/commits : 2.36

Couverture de test

8. Problèmes rencontrés et solutions

9. Enseignements clés