Créer un SaaS avec Claude Code : ce qui marche, ce qui coince

Claude Code permet aujourd'hui à un fondateur de faire sortir un premier SaaS de son terminal en quelques semaines : écrans, base de données, comptes utilisateurs, paiement. C'est un vrai changement, et il serait malhonnête de le minimiser. Ce qui ne change pas, c'est ce qui sépare une application qui tourne d'un SaaS vendable : l'isolation entre clients, une facturation qui pilote les accès, la sécurité, des tests qui protègent chaque modification, un hébergement exploité. Claude Code peut écrire tout cela. Il ne décide pas à votre place de ce qu'il faut écrire, et il ne répond pas des incidents.

Cet article est centré sur l'outil Claude Code, ses prix et sa façon de travailler. Pour la question générale des outils d'IA appliqués au SaaS (générateurs et assistants confondus), lisez créer un SaaS avec l'IA. Pour un SaaS dont le produit lui-même repose sur un modèle d'IA, voyez lancer un SaaS d'IA.

Claude Code, en deux phrases

Claude Code est l'agent de programmation d'Anthropic : il lit votre dépôt de code, modifie les fichiers, lance des commandes et ouvre des demandes de fusion. Selon sa documentation officielle, il tourne dans le terminal, dans VS Code et les éditeurs JetBrains, dans une application de bureau et dans le navigateur.

Trois mécanismes comptent pour un projet de SaaS :

• Le fichier CLAUDE.md, placé à la racine du dépôt, que Claude Code lit à chaque session. C'est là que vous écrivez vos règles : architecture, conventions, ce qu'il ne faut jamais faire. Plus ce fichier est précis, plus le code produit est cohérent d'une semaine à l'autre.
• Les permissions. D'après la page sécurité de Claude Code, le mode manuel démarre en lecture seule et demande votre accord avant de modifier un fichier ou de lancer une commande. La même page rappelle que la relecture du code et des commandes proposées reste votre responsabilité.
• L'intégration à Git. Le code vit dans votre dépôt, chez vous, et chaque modification peut passer par une demande de fusion relue. C'est la grande différence avec un générateur hébergé : vous partez propriétaire de l'outil de travail.

Ce que coûte Claude Code, relevé du 6 novembre 2026

Les prix ci-dessous viennent de la page tarifs d'Anthropic, relevée le 6 novembre 2026, en dollars américains. Ils changent souvent : vérifiez-les avant de vous abonner.

Deux remarques que les comparatifs oublient souvent :

• Le coût de l'outil est la plus petite ligne du budget. Hébergement, base de données, envoi d'e-mails, supervision, paiement, nom de domaine, et surtout votre temps de relecture : c'est là que se joue le coût réel. Ce sont ces postes qu'il faut chiffrer avant de comparer les formules.
• Les conditions d'utilisation ne sont pas les mêmes selon la formule. La page sécurité de Claude Code renvoie aux conditions commerciales pour Team, Enterprise et l'API, et aux conditions grand public pour Free, Pro, Max et Ultra. Si votre dépôt contient un jour des données de clients réels (exports, sauvegardes, journaux), lisez les deux et vérifiez vos réglages de confidentialité avant de choisir.

Ce que Claude Code fait bien pour un SaaS

• Monter le squelette d'un produit. Authentification, modèle de données, écrans de liste et de saisie, tableau de bord : le code répétitif d'un back-office sort en quelques heures plutôt qu'en quelques jours.
• Travailler sur l'existant. Contrairement à un générateur qui part d'une page blanche, Claude Code lit un dépôt entier, retrouve une fonction, explique un module et corrige un bogue à partir d'un message d'erreur.
• Écrire les tests, quand on les lui demande. C'est sans doute son apport le plus sous-estimé : un test qui vérifie qu'un client A ne voit pas les factures du client B coûte quelques minutes à générer, et protège le SaaS pour toujours.
• Brancher des services documentés. Paiement, e-mails transactionnels, stockage de fichiers : l'agent connaît les bibliothèques courantes et lit la documentation que vous lui donnez.
• Automatiser le travail ingrat. Mises à jour de dépendances, conflits de fusion, notes de version, revue d'une branche avant fusion.

Ce qui coince quand le SaaS part en production

Un SaaS sert plusieurs entreprises clientes avec la même application, sur abonnement, et vous en êtes l'éditeur responsable. Voici, exigence par exigence, ce que Claude Code produit et ce qui reste à faire.

Le multi-tenant : la règle invisible

La règle cardinale d'un SaaS est qu'un client ne voit jamais les données d'un autre. Elle ne se voit pas à l'écran, et c'est précisément pour cela qu'elle est oubliée. Claude Code écrira volontiers une requête qui filtre par entreprise ; il ne saura pas, sans que vous l'écriviez, qu'un comptable invité ne doit voir que deux dossiers, ou qu'un administrateur de groupe voit ses trois filiales. Si votre base est PostgreSQL via Supabase, la documentation sur la sécurité au niveau des lignes demande d'activer ces règles sur chaque table exposée. Les modèles d'architecture possibles sont détaillés dans SaaS multi-tenant : ce que le fondateur doit comprendre.

La facturation qui pilote les accès

Encaisser un paiement est facile. Gérer un abonnement ne l'est pas : essai gratuit, renouvellement, carte expirée, changement de formule, résiliation. Stripe le dit dans sa documentation sur les webhooks d'abonnement : votre application doit réagir aux événements que Stripe lui envoie. Un agent écrit ce code ; il faut ensuite le tester événement par événement, y compris quand un événement arrive deux fois ou dans le désordre. La TVA et les factures sont traitées dans facturer les abonnements d'un SaaS.

La sécurité : plausible n'est pas vérifié

Le code généré est presque toujours plausible, ce qui le rend dangereux à relire en diagonale. Les points qui reviennent : une clé secrète posée dans le code côté navigateur, une route d'API qui vérifie que l'utilisateur est connecté mais pas qu'il a le droit de lire cette ressource, une dépendance ajoutée sans être nécessaire. Claude Code propose une commande de revue de sécurité sur la branche en cours ; elle aide, elle ne remplace pas la relecture d'une personne qui sait ce qu'elle cherche.

Les tests : ce que vous ne demandez pas n'existe pas

Un agent teste ce que vous lui demandez de tester. Sans consigne, il vérifiera souvent que la page s'affiche, rarement qu'un utilisateur révoqué perd vraiment l'accès. La bonne pratique : écrire dans CLAUDE.md que toute fonctionnalité touchant aux droits ou à la facturation s'accompagne d'un test, et faire tourner ces tests automatiquement à chaque modification.

L'hébergement et l'exploitation

Le jour du lancement, le travail change de nature. Il faut des sauvegardes que l'on a déjà restaurées au moins une fois, une supervision qui prévient avant les clients, des mises à jour de sécurité, un environnement de test séparé de la production, et quelqu'un qui répond à 8 heures quand un client ne peut plus se connecter. Claude Code peut écrire les scripts ; il ne se réveille pas la nuit.

Une méthode de travail qui tient avec Claude Code

1. Écrire le CLAUDE.md avant la première ligne de code. Le produit en cinq lignes, la pile technique, le modèle multi-tenant choisi, les règles de nommage, les interdits (pas de secret dans le code client, pas de requête sans filtre d'entreprise).
2. Demander un plan avant le code. Pour chaque fonctionnalité, faites d'abord décrire l'approche, relisez-la, puis seulement laissez écrire.
3. Travailler par petites demandes de fusion. Une fonctionnalité, une branche, une relecture. Un gros changement généré d'un coup ne se relit pas vraiment.
4. Exiger les tests dans la même demande. Droits d'accès, facturation, migrations : pas de fusion sans test.
5. Garder les permissions serrées. N'autorisez pas d'office les commandes qui touchent à la production ou au réseau. La documentation des permissions explique comment les restreindre par projet.
6. Faire relire ce qui est critique par un humain compétent. Pas tout, mais tout ce qui touche aux données des clients, à l'argent et à l'authentification.

Les erreurs qui coûtent le plus cher

• Confondre démonstration et produit. Une démonstration convaincante est une réussite, pas une mise en production.
• Laisser l'agent choisir l'architecture. Il choisira quelque chose de raisonnable, pas forcément ce qui conviendra à vos clients les plus exigeants dans deux ans.
• Ne jamais tester avec deux clients. C'est le test le plus simple, et le plus souvent oublié.
• Accepter les modifications sans les lire, parce que « ça marche ». La page sécurité d'Anthropic est explicite sur la responsabilité de l'utilisateur.
• Ignorer la question de la propriété. Ce que vous possédez vraiment sur un code généré dépend de la part humaine dans son écriture et des contrats signés : documentez qui a décidé quoi dès le départ.

Claude Code, Lovable ou un studio

Claude Code n'est pas un générateur d'applications : il suppose un dépôt, un terminal ou un éditeur, et la capacité de juger ce qu'il produit. Un outil comme Lovable part de la conversation et héberge l'application pour vous. Les deux approches sont comparées sans parti pris dans Lovable ou Claude Code.

Quand ne pas faire de sur-mesure du tout

Si un logiciel du marché couvre déjà l'essentiel de votre besoin et que votre différence n'est pas dans le logiciel lui-même, l'abonnement à ce logiciel coûtera moins cher qu'un SaaS à construire, avec ou sans Claude Code. Le sur-mesure se justifie quand le logiciel est votre produit, ou quand votre façon de travailler est ce qui vous distingue.

Quand se faire accompagner

Se faire accompagner ne veut pas dire renoncer à Claude Code. Chez LPR Studio, nous éditons et exploitons nos propres logiciels, comme Izi-Devis et Tubissime, et nous écrivons une bonne part de notre code avec des assistants de ce type. Ce qui ne change pas : chaque modification est relue et testée avant la production, et nous répondons de ce qui tourne.

Le bon moment pour se faire accompagner arrive en général à l'un de ces trois signaux : un premier client prêt à payer, des données personnelles ou sensibles qui entrent dans la base, ou un dépôt que plus personne ne sait modifier sans casser autre chose.

Par où commencer

Avant d'ouvrir un terminal, écrivez sur une page les trois parcours que vos premiers clients feront chaque semaine, et les deux rôles qui n'ont pas le droit de voir les mêmes données. C'est votre premier CLAUDE.md, et c'est aussi ce dont nous partons pour un prototype présenté avant tout paiement : nous vous le montrons en visio sous 5 jours ouvrés, puis nous vous présentons les trois façons de le construire et de le financer.