Retour au blog
IASaaSClaude Code

Comment j'ai construit un SaaS de 1 800 commits avec Claude Code

Retour d'expérience sur le développement d'Avistra, de la première ligne de code à la production. Workflows, patterns, et le rôle de l'IA dans mon processus de dev.

Antoine Verdure

Antoine Verdure

12 avril 202612 min de lecture

En octobre 2025, j'ai commencé à développer Avistra — un SaaS de conception de systèmes audiovisuels. Six mois plus tard, le compteur affiche 1 824 commits, 693 sessions de développement, et une version v1.9.146 en production sur avistra.fr. Tout ça avec un seul développeur et un copilote : Claude Code.

Voici comment j'ai structuré mon workflow pour maintenir une vélocité constante sans sacrifier la qualité.

Les chiffres bruts

Avant de rentrer dans le détail, posons les métriques du projet au moment de la rédaction :

  • 1 824 commits sur 693 sessions — soit environ 2,6 commits par session
  • 5 742 tests unitaires qui passent, 0 flaky, répartis sur 237 fichiers
  • 50+ tests E2E Playwright couvrant l'auth et les scénarios canvas
  • 0 cycles architecturaux — dependency-cruiser vérifie ça à chaque push
  • 0 erreur TypeScript en production
  • Score de maturité workflow : 8.8/10 (niveau EXPERT)

Ces chiffres ne sont pas là pour impressionner. Ils sont là pour montrer qu'un dev solo avec le bon outillage peut maintenir un niveau de qualité professionnel sur la durée.

Le CLAUDE.md comme constitution du projet

Le cœur de mon workflow avec Claude Code, c'est le fichier CLAUDE.md. Sur Avistra, il fait 615 lignes et fonctionne comme une constitution : il définit les règles dures que l'IA ne doit jamais enfreindre, les patterns architecturaux à suivre, et les conventions du projet.

Concrètement, il contient 14 patterns documentés (P1 à P14) qui couvrent tout : du service layer obligatoire jusqu'au comportement spécifique du canvas React Flow. C'est pas un fichier qu'on écrit une fois et qu'on oublie — il évolue avec le projet. La version actuelle est la 4.2.

L'idée clé : plus le CLAUDE.md est précis, moins tu passes de temps à corriger l'IA. Un pattern bien documenté, c'est des dizaines de corrections évitées par session.

693 sessions sans perdre le contexte

Le plus gros défi du dev avec IA, c'est la continuité. Une session de conversation a un contexte limité. Comment maintenir la cohérence sur 693 sessions ?

Ma solution repose sur trois fichiers :

  • STATUS.md — l'état vivant du projet, mis à jour à chaque session
  • LAST_SESSION.md — le contexte exact de la dernière session pour un handoff propre
  • CLAUDE.md — les règles permanentes du projet

Chaque session commence par une commande /open-session qui charge tout le contexte nécessaire, et se termine par /close-session qui archive et met à jour l'état. Sur 693 sessions, je n'ai eu zéro perte de contexte. L'IA reprend exactement où elle s'était arrêtée.

L'architecture Schema-First

La décision architecturale la plus structurante d'Avistra : tout part du schéma de base de données.

Le pipeline est simple :

  1. Schéma Supabase (PostgreSQL) = source de vérité
  2. Contrats Zod générés depuis le schéma pour la validation
  3. Types TypeScript auto-générés pour le typage

Ce pattern garantit que la base, la validation, et le typage sont toujours synchronisés. Quand tu modifies le schéma, tout le reste suit. Ça élimine une catégorie entière de bugs : les désynchronisations entre couches.

Le Service Layer : la règle la plus stricte

Règle dure numéro un : aucun appel direct à Supabase depuis un composant. Tout passe par 43 services spécialisés dans lib/services/.

Pourquoi ? Trois raisons :

  • Testabilité — injection du client Supabase = tests unitaires sans base
  • Cohérence — chaque opération passe par le même pipeline (validation, logging, error handling)
  • Refactoring — changer la couche data ne touche pas les composants

Après 1 824 commits, le taux de conformité est de 100%. Pas un seul supabase.from() dans un composant.

91 scripts d'automatisation

Un projet de cette taille génère une quantité énorme de tâches répétitives. Ma réponse : 91 scripts d'automatisation — 51 scripts NPM et 40 utilitaires TypeScript.

Les plus impactants :

  • Quality gates pre-push — 4 validations automatiques (lint, types, architecture, sécurité)
  • RAG codebase — 11 656 chunks indexés pour la recherche sémantique dans le code
  • 10 agents spécialisés pour des tâches comme la revue de code ou l'audit de qualité
  • 9 slash commands pour les opérations courantes (/run-cycle pour le TDD, etc.)

Chaque script économise quelques minutes. Multipliés par 693 sessions, l'investissement se rembourse des dizaines de fois.

Les moments où ça a cassé

Tout n'a pas été un long fleuve tranquille. Quelques moments marquants :

Le bug Firefox du clic droit (sessions 527-528) : le menu contextuel ne fonctionnait pas dans Firefox. Ça a nécessité un listener en capture-phase avec détection de coordonnées — un pattern (P13) maintenant documenté dans le CLAUDE.md pour ne plus jamais tomber dessus.

La simplification du pipeline de sauvegarde canvas (session 541) : 12 couches de transformation réduites à 5. Résultat : -3 510 lignes de code et 60% de complexité en moins. Parfois, le meilleur code qu'on écrit, c'est celui qu'on supprime.

Le spike disque de 102 Go (session 536) : le cache WSL2 avait explosé. Rien à voir avec le code, tout à voir avec l'infrastructure. 24 Go récupérés en configurant correctement .wslconfig. Leçon : l'hygiène infra impacte directement la vélocité de dev.

Ce que j'ai appris

Après 5 mois et demi avec Claude Code comme copilote quotidien, voici mes convictions :

  • L'IA amplifie ta rigueur — si tu as des règles claires, l'IA les suit. Si tu n'en as pas, l'IA improvise. Et l'improvisation à l'échelle de 1 800 commits, ça crée du chaos.
  • La documentation est du code — le CLAUDE.md n'est pas de la doc décorative. C'est un fichier de configuration pour ton copilote. Chaque ligne impacte le code produit.
  • L'automatisation est un investissement — 91 scripts, ça paraît beaucoup. Mais chacun a été créé à un moment précis où la répétition devenait un frein. Le ROI est immédiat.
  • Le dev solo n'est plus "solo" — avec les bons outils, un dev seul peut maintenir une codebase de production avec 5 742 tests et zéro dette technique structurelle. Le bottleneck n'est plus la capacité de production — c'est la vision produit.

Avistra est en production sur avistra.fr, version v1.9.146. Le projet continue d'évoluer, session après session. Et le CLAUDE.md est déjà à la version 4.3 — avec probablement la 5.0 qui arrivera bientôt.

Antoine Verdure

Un projet en tête ?

Cet article t'a donné des idées ? Discutons de comment les mettre en œuvre dans ton contexte. 30 minutes, sans engagement.

Me contacter