En février 2026, un développeur publiait sur Hey.com le bilan de son SaaS construit avec Claude Code : 713 commits, 38 632 lignes de code, 95 % du code généré par l’IA en 8 semaines. Son avantage ne tenait pas à ses prompts. Il repartait d’une application existante — modèle de données connu, spec définie avant la première session. Claude n’avait pas à deviner ce qu’il construisait. Il n’avait qu’à construire.
Ce guide explique comment créer ce même point de départ, même si vous partez de zéro : une spec de 400 à 800 mots qui permet à Claude de produire du code exploitable dès le premier sprint, sans journées de débogage ni reverts massifs. Comptez 2 à 3 heures pour la rédiger. Le reste de la semaine, Claude code.
Ce que le vibe coding révèle sur Claude
Le vibe coding (décrire un projet en langage naturel et laisser l’IA générer) a explosé en 2025. En 2026, 38 à 47% des développeurs professionnels utilisent des prompts en langage naturel chaque semaine pour générer du code de production, selon une synthèse de cinq sources indépendantes publiée par Panto AI. Dans les startups de moins de 20 ingénieurs, ce taux dépasse 60%.
Les chiffres sont assez clairs. Le temps de complétion des tâches baisse de 20 à 45% avec l’assistance IA. Le taux de défauts post-merge augmente de 7 à 15% dans les équipes qui ne maintiennent pas une revue manuelle rigoureuse. La fréquence des reverts est 30% plus élevée pour les gros commits IA que pour les commits humains de même taille (Panto AI, 2026).
Sans cadre clair, Claude optimise pour satisfaire le prompt immédiat, pas la cohérence du produit sur 7 jours. Le même rapport note que le temps de code review par PR augmente de 25 à 40% quand le relecteur n’a pas guidé l’IA itérativement. Ce que vous ne spécifiez pas en amont, vous le déboguez en aval.
La spec qui fait gagner du temps : 5 sections, pas plus
Une spec Claude efficace n’est pas un cahier des charges de 40 pages. C’est un document de 400 à 800 mots que Claude lit dans son contexte initial. Trop court : Claude invente. Trop long : Claude oublie les détails du bas quand il travaille sur le haut.
Les 5 sections indispensables :
- Le problème en une phrase, pas la solution. « Les freelances perdent 3h par semaine à relancer manuellement leurs clients. » Claude doit comprendre pourquoi votre SaaS existe, pas seulement ce qu’il fait.
- L’utilisateur cible avec ses contraintes techniques : son niveau tech, son environnement (mobile/desktop, connexion, OS), ce qu’il ne fera jamais. « Des comptables de 45 ans sous Windows, allergiques aux interfaces sans étiquettes. »
- Les fonctionnalités core du MVP, pas 8, pas 15. Décrites avec les flux exacts : entrée, traitement, sortie. Ce que Claude construit en priorité absolue.
- Les contraintes techniques non négociables : stack imposée, APIs tierces, limites de budget d’API, RGPD si applicable. « Next.js + Supabase. Pas de base de données propriétaire. Hébergement sur Vercel. »
- Ce qui est hors scope, explicitement. « Pas d’application mobile. Pas d’équipe/multi-tenant. Pas de plan freemium. » Claude ne devinera pas ce que vous ne voulez pas. Sans cette section, il l’invente.
Cette structure correspond au format PRD (Product Requirements Document) recommandé par Anthropic pour Claude Code : des user stories discrètes que Claude implémente séquentiellement, pas un sprint monolithique.
Comment charger la spec dans Claude Code
La façon la plus fiable de travailler avec Claude Code sur une semaine complète : un fichier CLAUDE.md à la racine du projet. Claude Code le lit automatiquement à chaque session. Vous n’avez pas à recoller votre spec dans chaque conversation.
Ouvrez votre éditeur. Créez CLAUDE.md à la racine. Collez-y votre spec complète, puis ajoutez en bas une section « Conventions de code » : nommage des fichiers, gestion des erreurs, langue des commentaires (anglais ou français), structure des dossiers. Ces conventions évitent que Claude réinvente la structure à chaque session.
Vérifiez que Claude l’a bien chargé avant de coder : demandez-lui « Résume le problème que ce SaaS résout et cite les fonctionnalités core du MVP. » Si la réponse est précise, vous pouvez commencer. Si elle est vague, relisez votre CLAUDE.md. Claude ne ment pas sur ce qu’il voit.
Pourquoi vos prompts comptent moins que vous pensez
En août 2025, Final Round AI a interrogé 18 CTOs sur le vibe coding. 16 sur 18 ont déclaré avoir connu des incidents de production directement causés par du code généré par IA sans cadre préalable. Le problème : les plateformes de vibe coding ne créent pas de spécification formelle et l’ignorent quand on en fournit une. Elles optimisent le prompt du moment, pas la cohérence du système.
Claude Code, correctement configuré, n’a pas ce défaut. Mais il reste tributaire de ce que vous lui donnez. Un prompt excellent sur une base floue produit du code excellent qui ne s’intègre pas. Un prompt moyen sur une spec claire produit du code intégrable.
La qualité du prompt devient secondaire dès que votre contexte est dense et cohérent. Anthropic documente ce comportement dans son guide de bonnes pratiques pour Claude Code. Le pattern Explore-Plan-Code-Commit commence par « lire les fichiers pertinents et rechercher en ligne » avant d’écrire une seule ligne. L’exploration remplace le prompt parfait.
Le planning de la semaine : ce qui doit être prêt avant le lundi
Si vous voulez un SaaS fonctionnel en 5 jours ouvrés, la spec doit être finie le dimanche soir. Pas en cours de route.
Répartition par jour :
- Dimanche (2-3h) : rédiger la spec complète en 5 sections, créer CLAUDE.md, initialiser le projet (Next.js, Supabase, Vercel).
- Lundi : authentification + modèle de données. Demandez à Claude de proposer le schéma avant de le générer. Validez manuellement.
- Mardi : fonctionnalité core n°1, de bout en bout. Une feature complète vaut mieux que trois à moitié.
- Mercredi : fonctionnalité core n°2 + gestion des erreurs visibles par l’utilisateur.
- Jeudi : fonctionnalité core n°3 + tests sur les flux critiques.
- Vendredi : déploiement, vérification des variables d’environnement en prod, première session utilisateur réelle.
À chaque début de session Claude Code, commencez par : « Lis CLAUDE.md et résume où en est le projet. » Ça prend 30 secondes et évite que Claude reparte de zéro après une nuit.
Les erreurs qui font rater la semaine
Les projets SaaS qui dérapent avec Claude Code échouent rarement à cause de limites techniques de l’IA. Ils échouent à cause de quelques schémas récurrents.
Spec évolutive. Vous modifiez le périmètre en cours de semaine. Claude adapte mais le code produit lundi est maintenant incohérent avec le code produit mercredi. La spec est un contrat : si vous la changez, réécrivez CLAUDE.md et demandez explicitement à Claude de vérifier la cohérence du code existant avant de continuer.
Sessions longues sans checkpoint. Les commits IA en gros volumes ont un taux de revert 30% plus élevé que les commits humains (Panto AI, 2026). Committez souvent. Une session, une feature, un commit.
Déléguer les décisions d’architecture à Claude. Claude implémente bien une décision déjà prise. Il est moins fiable pour choisir la bonne architecture sans contraintes. « Construis le backend » sans spec, Claude choisit. Il choisit vite, pas forcément juste pour votre contexte. Les contraintes techniques de votre spec (stack, APIs, hébergement) sont là pour cadrer ces choix.
Une fois votre SaaS livré, la vraie question devient : comment maintenir la cohérence de la spec au fil des itérations, quand le produit évolue et que la dette de contexte commence à s’accumuler dans CLAUDE.md. Ça, c’est le problème de la semaine deux.
