Comment je construis un SaaS en solo avec Claude Code : méthode et garde-fous

J’ai construit neuf produits SaaS seul, avec Claude Code comme équipe de développement. Ce n’est pas l’IA qui rend ça possible : c’est la façon de l’encadrer. Un agent qui code vite sans cadre produit vite du code que personne ne comprend, y compris lui à la session suivante. Voici la méthode que j’applique, telle qu’on peut la lire dans mes repos — à commencer par celui de ce site. Les produits eux-mêmes sont sur la page des projets.

Cadrer avant la première ligne

Une fonctionnalité non triviale commence par une spécification écrite, pas par un prompt. Le blog que vous lisez en est l’exemple : avant tout code, un document décrivait le problème, le modèle de données, les états à gérer, les critères d’acceptation, le plan de tests, les pièges repérés dans le code existant, et se terminait par le prompt d’implémentation.

Ce n’est pas de la bureaucratie. Un agent exécute très bien ce qui est décidé ; il décide mal ce qui ne l’est pas. La spécification déplace les décisions là où elles coûtent le moins cher : avant le code, pas pendant la relecture.

Un CLAUDE.md qui dit la vérité

Chaque repo a son CLAUDE.md : la stack, la structure, les commandes, les conventions, les règles de modification, les pièges connus et les checklists avant commit. C’est le document que l’agent lit en premier, à chaque session. Les règles y sont concrètes et vérifiables, comme celle-ci, extraite du repo de ce site :

Ne jamais construire un lien interne avec `/${locale}${path}` :
utiliser localeHref(locale, path), sinon le lien anglais pointe
vers une URL française qui répond en 301.

La contrepartie : un CLAUDE.md faux est pire qu’un CLAUDE.md absent. Sur ce site, la documentation de sécurité a décrit pendant six semaines une protection qui avait été retirée du code. Le cadrage du blog est parti de cette contrainte inexistante ; il a fallu relire la configuration réelle pour s’en apercevoir, puis corriger neuf fichiers. D’où une ligne de la checklist avant chaque commit : si le changement touche ce que la doc décrit, la doc change avec lui.

Des règles que l’agent ne peut pas contourner

Une consigne écrite est un souhait. Une vérification automatique est une règle. Tout ce qui peut être vérifié par un outil doit l’être :

• TypeScript strict : sur ce blog, un paragraphe auquel il manque sa version anglaise ne compile pas.
• Des tests unitaires et de bout en bout, écrits en même temps que le code, pas après.
• Avant chaque PR : lint, vérification des types, tests et build de production. Une commande, pas un effort de mémoire.
• Validation des entrées non fiables (variables d’environnement, formulaires, webhooks) par un schéma.
• Pas de TODO dans le code : chaque dette connue a une entrée dans un fichier de problèmes connus, avec sa piste.

Quand l’IA est dans le produit

Construire avec l’IA et construire de l’IA sont deux sujets. Dans le second cas, la discipline se déplace dans le produit. Novera Signal, un agent qui détecte et qualifie des opportunités commerciales, impose une sortie JSON stricte validée par un schéma, versionne ses prompts, isole le fournisseur de données derrière une abstraction, et n’envoie jamais rien seul : l’humain valide chaque message. Novera Recorder transcrit et résume des réunions entièrement en local, parce que leur contenu ne doit pas quitter la machine.

Ce que je ne délègue jamais

• Décider ce qu’on ne construit pas. C’est la décision qui économise le plus.
• L’architecture : droits, isolation des données, paiement. Là où une erreur coûte une réécriture.
• La relecture de chaque changement, en comparant le diff à la spécification.
• Les actions irréversibles : mise en production, envoi à des tiers, suppression de données.

Le reste, l’agent le fait mieux et plus vite que moi seul. C’est ce partage qui rend un produit construit en solo tenable dans la durée. Et c’est aussi ce qui fixe son prix : combien coûte un MVP SaaS avec l’IA.