12 jours pour faire un SaaS complet, de A à Z

01 Le chiffre qui surprend

Voici ce que le git raconte réellement, phase par phase.

Trois durées à ne surtout pas confondre

C'est là que se cache l'exagération habituelle (« un SaaS en un weekend »). Trois chiffres différents, trois significations :

• Calendaire. Le cœur du produit — auth, paiement Stripe, IA duale souveraine, 16 templates — était en production après 12 jours (app déployée et accessible dès le 2ᵉ jour, pas une page « coming soon »). Le produit complet a ensuite mûri sur 2,5 mois — soit plus long au mur que les 8 semaines prévues, mais à faible intensité.
• Effort effectif. ~95-130 h de travail réel au total, soit ≈ 2,5 à 3,5 semaines à temps plein. Le cœur seul : ~1,5-2 semaines équivalent temps plein.
• Jours actifs. 27 jours où j'ai touché le projet (au moins un commit), sur ces 2,5 mois. Ni la durée calendaire, ni de l'équivalent temps plein — juste les jours où j'ai ouvert le capot.

La complexité, objectivée — quelle équipe avant l'IA ?

« Compression », soit. Mais par rapport à quoi ? Pour donner un dénominateur, j'ai mesuré la complexité réelle de DWG et estimé, métriques classiques à l'appui, ce qu'une équipe traditionnelle aurait dû mobiliser.

DWG, c'est ~78 000 lignes de code (dont ~10 000 de tests), 53 écrans, 45 endpoints, 26 entités, ~600 tests, ~8 intégrations — plus CI/CD, support, analytics et RGPD. Les modèles d'estimation situent cette version entre ~60 et 110 personnes-mois — soit une équipe de 4 à 6 personnes pendant 12 à 18 mois. Une personne + IA l'a atteinte en ~110 h effectives. La compression se compte en dizaines de fois.

Le détail — mesures, trois méthodes d'estimation, limites — est dans l'analyse dédiée : Combien pèse vraiment un SaaS ?

À propos des « 8 semaines ». Le plan initial (« Solo, scope plein, timing ajustable ») parlait de 8 semaines calendaires, en side-project : RiffLab est mené à côté de Jamespot, mon activité principale, pas à temps plein. Comparer brutalement « 8 semaines » à « 12 jours » serait malhonnête — ce ne sont pas les mêmes unités.

* Phase 3 : la méthode de mesure casse ici (voir §5). Le vrai temps est nettement au-dessus des 3h affichées.

02 Où part vraiment le temps

Le contre-intuitif le plus utile de ce doc.

Phase 1 — « De zéro à la prod » (~60-80 h)

La partie qu'on imagine longue. Elle a été la plus dense mais pas la plus piégeuse : stack figée, schéma de données complet dès le premier commit, l'IA génère le squelette et les premières features à grande vitesse. Le déploiement en prod dès le 2ᵉ jour a forcé à affronter tôt les vrais problèmes plutôt que de les accumuler.

Phase 2 — « Durcissement + features » (~25-35 h)

Le premier piège. Une fois le produit « fini », il restait un tiers du temps à faire. Analytics (PostHog auto-hébergé), support client (Chatwoot), pages légales conformes RGPD/LCEN, migration de la CI. Rien de « sexy », tout indispensable pour un vrai SaaS. C'est le travail que les démos oublient et que la prod exige.

Phase 3 — « Maintenance & retours terrain » (~10-15 h)

Le second piège, et le plus instructif. Presque tous les bugs de cette phase ont été trouvés par de vrais utilisateurs, pas par les tests. Une invitation d'équipe jamais envoyée par email. Un enregistrement vocal sans limite claire qui plantait au-delà d'un seuil invisible. Une navigation post-invitation qui perdait l'utilisateur. Chacun a passé tests + typecheck et cassé en usage réel.

03 Ce que l'IA change — et ce qu'elle ne change pas

Être précis là-dessus est une question d'honnêteté, et de crédibilité.

Ce que l'IA compresse massivement

• L'écriture de code — le squelette, les routes, les composants.
• Les tests et la documentation, écrits en même temps que le code (pas « plus tard », donc jamais). DWG a des centaines de tests et un journal daté parce que leur coût marginal est devenu quasi nul.
• L'exploration — essayer, jeter, retenter, sans le coût psychologique habituel.
• Les tâches d'infra scriptables (déploiement, migrations, setup Stripe, funnels) — via API plutôt que des clics.

Ce que l'IA ne change pas d'un pouce

• Le jugement produit. Quoi construire, quoi couper, quoi mettre hors-V1. C'est le fondateur, pas le modèle.
• La parité dev/prod. Les bugs shippés qui passaient les tests locaux naissent de divergences invisibles — l'IA ne les voit pas plus que toi. Ingénierie prudente, pas génération.
• Les retours terrain. Aucun modèle ne remplace un vrai testeur qui se perd dans ton flow. C'est la Phase 3, irréductible.
• Le légal et la conformité. Il faut décider, assumer, être exact.

04 La méthode qui rend les 12 jours possibles

La partie réutilisable. Sans ces choix, les 12 jours deviennent 12 semaines.

1. Stack figée dès le jour 1, non négociable. Une « stack figée » écrite noir sur blanc, qu'on ne rediscute pas sans raison forte. Zéro bikeshedding, zéro fatigue décisionnelle. L'IA est d'autant plus efficace qu'elle travaille dans un cadre contraint.
2. Le schéma de données complet dès le premier commit. Le modèle entier (comptes, paiement, métier, événements) posé au scaffold. Construire sur un schéma stable est bien plus rapide que le faire évoluer à chaque feature.
3. Déployer en prod très tôt — le 2ᵉ jour. La prod révèle en heures ce que le local cache pendant des semaines. Plus tu déploies tard, plus les divergences s'accumulent en silence.
4. Simuler avant le réel. Générer des organisations et personae fictives via l'IA pour tester les parcours avant d'avoir de vrais utilisateurs. Les bugs de flow se voient sur des données simulées réalistes, pas sur des fixtures « happy path ».
5. Tests + journal à chaque feature livrée. Pas de dette invisible. C'est aussi ce qui rend ce document possible : on n'objective que ce qu'on a tracé.
6. Paralléliser proprement. Plusieurs sessions IA en parallèle — mais chacune dans son git worktree dédié, pour ne pas se marcher dessus. Discipline d'abord, vitesse ensuite.
7. Cycle de livraison en autonomie. Branche → PR → validation → merge, en boucle courte. L'intégration continue (tests, audit sécurité, smoke test) tient le filet.
8. « Si c'est en prod, c'est que ça tient debout. » Pas de feature flag pour cacher du travail à moitié fait. Ça oblige à finir, ou à couper franchement.

05 Le piège du chiffre

Un chiffre sans sa méthode est du marketing. Voici la mienne, avec ses limites.

• La mesure : pour chaque jour, l'écart entre le premier et le dernier commit. Un proxy objectif et vérifiable (git log), mais imparfait.
• Deux biais en sens inverse. Il sur-compte les longues journées (déjeuner et pauses dans la fenêtre) et sous-compte les journées à un seul commit (un correctif d'1 à 3 h s'affiche 0.0h). La Phase 3, faite de sessions courtes et espacées, est particulièrement sous-estimée.
• D'où la fourchette. Le « effectif estimé » applique un coefficient (×0.6-0.8 sur les longues journées, correction à la hausse sur les journées mono-commit). Pas une science exacte ; une honnêteté assumée.
• Ce que le chiffre n'inclut pas : la réflexion produit loin du clavier, les échanges avec les testeurs, la veille. Le temps-cerveau déborde toujours le temps-git.

06 Reproductible ? La recette condensée

Les 12 jours ne sont pas magiques — ils sont la conséquence de conditions réunissables.

• Périmètre V1 tranché et écrit (in / out explicites), avant de coder.
• Stack figée dès le départ — ne pas la rediscuter en cours de route.
• Schéma de données complet posé au premier jour.
• Déploiement en prod dans les 48 premières heures (même sur données de démo).
• Données simulées réalistes pour tester les parcours avant les vrais users.
• Tests + journal systématiques — coût quasi nul avec l'IA, l'absence coûte cher plus tard.
• Compter autant de temps « après le produit » (durcissement, légal, support, retours) que pour le produit.
• Accepter que le jugement produit et le contact terrain ne se compressent pas.

Le comment technique de la mise en prod est dans le playbook go-to-prod souverain.

07 Annexe — le détail jour par jour

Reconstruit via git log --format='%aI' -- riffs/deepworkgraph/, fenêtre = 1ᵉʳ → dernier commit du jour.