Pourquoi cette analyse
Dans le playbook « 12 jours », j'avance que l'IA compresse énormément le temps de build. Une affirmation pareille mérite un dénominateur : compresse par rapport à quoi ? Ce document répond en chiffrant, aussi honnêtement que possible, ce que DeepWorkGraph aurait coûté à une équipe traditionnelle.
Deux garde-fous d'entrée : les modèles d'estimation (COCOMO, points de fonction) datent et sur-estiment les stacks modernes — on les donne en fourchette. Et le nombre de lignes n'est pas la valeur — c'est un proxy de complexité, pas un trophée.
01 La complexité mesurée
Sur le code versionné uniquement (zéro artefact, zéro généré, zéro node_modules) — via git ls-files + wc.
Volume de code
| Nature | Lignes | Détail |
|---|---|---|
| Code applicatif (hors tests) | 65 783 | dont IA/agents 4 704 |
| Tests (unit + e2e Playwright) | 10 290 | ~600 cas |
| Migrations SQL | 842 | 30 migrations |
| CI/CD (GitHub Actions) | 906 | 9 workflows |
| Infra (Chatwoot, PostHog, backups…) | 818 | 14 scripts |
| Total code d'ingénierie | ≈ 78 600 | hors doc & données |
| Documentation (markdown) | 13 693 | 41 documents |
Non compté : ~208 k lignes de JSON — surtout les 16 templates d'organisation seedés et les lockfiles. C'est de la donnée, pas du code.
Complexité fonctionnelle
| Dimension | Quantité |
|---|---|
| Écrans / pages | 53 |
| Endpoints API | 45 |
| Composants React | 82 |
| Entités de données (modèles) | 26 |
| Migrations de schéma | 30 |
| Agents IA (génération, tissage, Pouls, extraction duale…) | ~6 |
| Intégrations externes | ~8 |
| Cas de test · articles KB | ~600 · 14 |
Multiplicateurs qu'aucun compteur de lignes ne capture : multi-tenant strict (isolation par workspace sur chaque requête), 3 modes de jeu (démo / role-play / réel), streaming IA temps réel, paiement récurrent + webhooks signés, conformité RGPD (hard delete cascade, pages légales), sorties IA structurées, session replays masqués, CI/CD + staging + auto-healing.
Les briques assemblées — la complexité cachée
Le nombre de lignes ne dit pas tout. DWG, c'est aussi une trentaine d'outils et de services à apprendre, câbler, sécuriser et maintenir — chacun un sous-système à part entière, totalement invisible dans le décompte de LOC. Et un fait à mettre en avant : la très grande majorité est européenne ou auto-hébergée (🇪🇺 ci-dessous) — c'est le « souverain à plus de 90 % » en pratique, pas en slogan.
Chacune de ces briques est, à elle seule, un projet : l'apprendre, l'intégrer, la configurer, la sécuriser, la surveiller, la sauvegarder. Un solo assisté par l'IA a orchestré l'ensemble — et l'a fait tenir, à plus de 90 %, sur une chaîne souveraine. C'est cette intégration, encore plus que le code, que les modèles d'estimation classiques peinent à chiffrer.
02 Trois méthodes d'estimation
Chacune répond à : « combien de personnes-mois pour une équipe traditionnelle ? » — et chacune a ses biais.
Méthode 1 — COCOMO basique (borne haute, modèle historique)
Effort = a · KLOC^b. DWG a des parties « semi-détachées » (sécurité multi-tenant, IA, temps réel). Modèle calibré sur assembleur/C → sur-estime le TypeScript.
| KLOC | Organic | Semi-détaché |
|---|---|---|
| 55 | 161 p.-mois · ~9 pers. | 267 p.-mois · ~15 pers. |
| 66 | 195 p.-mois · ~11 pers. | 327 p.-mois · ~17 pers. |
| 76 | 226 p.-mois · ~12 pers. | 383 p.-mois · ~19 pers. |
→ ~160 à 380 personnes-mois. Clairement gonflé pour du TS moderne, mais utile comme borne haute « entreprise ».
Méthode 2 — Points de fonction (backfiring, ~48 LOC/FP)
~1 370 FP. À 10-20 FP par personne-mois → ~69 à 137 personnes-mois.
Méthode 3 — Productivité LOC/jour (la plus intuitive)
76 000 LOC (code + tests) à 20-50 lignes nettes/jour/dev (tout compris : design, debug, review, tests, rework) → ~72 à 181 personnes-mois.
Hors COCOMO semi-détaché (le plus daté), les trois méthodes se recoupent autour de ~70 à 180 personnes-mois.
03 Le verdict
En tirant vers le bas (stack moderne, pas de legacy, équipe compétente), la lecture réaliste « startup agile ».
Une équipe de ~4 à 6 personnes (2-3 devs, 1 design/produit, 1 QA/DevOps partagé) pendant ~12 à 18 mois — soit ~60 à 110 personnes-mois — pour atteindre exactement cet état : feature-complete en prod, testé, CI/CD, support, analytics, légal.
Borne basse optimiste : ~4 pers. × ~9 mois (~35-40 p.-mois). Borne haute « entreprise » (COCOMO) : 12-20 mois, équipe élargie.
Le contraste
| Approche | Effort |
|---|---|
| DWG réel — 1 personne + IA | ~0,6-0,9 pers.-mois (~110 h) |
| Estimation équipe pré-IA (central) | ~60-110 pers.-mois |
Compression de l'ordre de plusieurs dizaines de fois — ~80-120× en effort brut sur la borne centrale, ~40× même sur l'hypothèse la plus optimiste.
04 Le garde-fou — ce n'est pas « l'IA seule »
Si on attribuait ce facteur à 100 % à l'IA, un lecteur tech le verrait tout de suite. Il agrège quatre leviers.
- L'IA. Écriture, tests, docs, exploration à coût marginal quasi nul. Probablement le levier le plus fort — mais pas le seul.
- La stack moderne. Next.js / Prisma / Better Auth donnent un levier énorme qu'une équipe des années 2010 n'avait pas. COCOMO l'ignore complètement.
- Zéro coût de coordination. Un solo n'a ni réunions, ni handoffs, ni specs à négocier. Une bonne part des « personnes-mois » d'une équipe, c'est de l'overhead d'équipe, pas de la production.
- Un décideur produit expert. 30 ans d'XP → arbitrages in/out sans gâchis, pas de features mortes, pas d'allers-retours.
« Une personne expérimentée, outillée d'une stack moderne et de l'IA, a produit en ~110 h ce que les modèles classiques chiffrent à plusieurs dizaines de personnes-mois pour une équipe. » L'IA est le multiplicateur central — pas le seul.
05 Les limites de l'analyse
Transparence — parce qu'un chiffre sans ses limites est du marketing.
- Le LOC n'est pas la valeur. Compter des lignes mesure un volume, pas l'utilité ni la difficulté. Un bon code fait moins de lignes.
- Les modèles sont datés. COCOMO/FP sont calibrés sur une autre époque ; ils sur-estiment le high-level moderne.
- DWG est un cas particulier : solo + expert + IA + stack moderne. Pas « n'importe qui obtient ce ratio ».
- L'estimation d'équipe est contrefactuelle : personne n'a vraiment refait DWG à l'ancienne pour comparer. C'est un ordre de grandeur, pas une mesure.
git ls-files riffs/deepworkgraph/ + wc -l pour le volume, comptage page.tsx / route.ts / model pour la structure, COCOMO / FP / LOC-jour pour l'estimation. Tout est recalculable.