Transformer son projet Claude en vrai SaaS : le chemin complet
Votre outil fait avec Claude ou Lovable marche et on s'en sert. Pour en faire un vrai SaaS, il manque sept briques : comptes, données, droits, paiement, hébergement, suivi des erreurs, cadre légal. Dans quel ordre, et pour quel coût.
Sommaire
Vous avez ouvert Claude ou Lovable un soir, décrit l'outil dont votre entreprise avait besoin, et il tourne. Votre équipe l'utilise tous les jours, il remplace peut-être déjà un logiciel que vous payiez, et un client demande s'il peut l'avoir aussi. Bonne nouvelle : le plus dur, trouver un usage, est fait. Ce qui reste, c'est transformer ce projet Claude en vrai SaaS, ou au moins en vrai outil : des comptes, des données qui ne se perdent pas, un paiement, et quelqu'un qui répond quand ça casse. Voici ce qui manque, dans quel ordre l'ajouter et combien ça coûte.
Qu'est-ce qui sépare un projet Claude d'un vrai SaaS ?
Un projet Claude, c'est une application que vous avez fait écrire par l'IA : un artifact partagé, une app générée avec Claude Code, un prototype sur Lovable ou Bolt. Un SaaS, c'est un logiciel que des clients paient chaque mois pour utiliser en ligne. La différence ne tient pas à l'écran. Elle tient à tout ce qui se passe quand des inconnus s'en servent : leurs comptes, leurs données, leur argent, leurs erreurs.
| Sujet | Projet Claude (prototype) | SaaS en production |
|---|---|---|
| Utilisateurs | Vous et quelques proches | Des inconnus, qui font ce que vous n'aviez pas prévu |
| Comptes | Aucun, ou un mot de passe partagé | Inscription, connexion, mot de passe oublié, équipes |
| Données | Dans le navigateur ou une base de test | Une base sauvegardée, chaque client cloisonné |
| Paiement | Aucun | Abonnement, factures, relances, résiliation |
| Mise en ligne | Un lien de démo | Un domaine, des e-mails qui arrivent, une mise à jour sans coupure |
| Quand ça casse | Vous relancez la conversation | Une alerte, un historique, quelqu'un qui corrige |
Rien dans cette colonne de droite n'est spectaculaire. C'est justement pour ça que l'IA la saute : quand vous demandez « fais-moi un outil de devis », elle fait l'outil de devis. Elle ne pense pas d'elle-même au client qui oublie son mot de passe, ni au deuxième client qui ne doit pas voir les devis du premier.
Quelles briques ajouter pour passer en SaaS ?
Sept chantiers reviennent sur presque tous les prototypes qu'on nous montre. Aucun n'est exotique. Chacun se fait en quelques jours quand on sait ce qu'on cherche, et coûte cher quand on le découvre après un incident.
Des comptes et des organisations
Inscription, connexion, mot de passe oublié, invitation d'un collègue. Pour un SaaS B2B, ajoutez la notion d'organisation : un client, c'est une entreprise avec plusieurs utilisateurs, pas une personne seule. Partir d'un outil d'authentification éprouvé plutôt que de laisser l'IA en écrire un à la main.
Une vraie base de données, sauvegardée
Beaucoup d'artifacts gardent les données dans le navigateur : elles disparaissent quand l'utilisateur change d'ordinateur. Il faut une base hébergée, des sauvegardes automatiques, et avoir déjà essayé d'en restaurer une. Une sauvegarde jamais testée n'en est pas une.
Des droits qui cloisonnent chaque client
Chaque requête doit vérifier qui demande et à quelle organisation appartient la donnée. C'est la brique la plus souvent ratée par le code généré : l'écran cache le bouton, mais le serveur répond quand même si on l'interroge directement.
Le paiement et l'abonnement
Stripe couvre l'essentiel : page de paiement, abonnement mensuel, factures, carte expirée, résiliation. Le piège n'est pas le bouton « payer ». C'est de garder votre base à jour quand Stripe vous prévient qu'un paiement a échoué ou qu'un client est parti.
L'hébergement, le domaine et les e-mails
Un nom de domaine à vous, un hébergement prévu pour un usage commercial, des e-mails (confirmation, facture, invitation) qui arrivent en boîte de réception et pas en spam. Et un environnement de test séparé, pour ne pas essayer une modification sur les données de vos clients.
Le suivi des erreurs
Quand un client voit un écran blanc, il ne vous écrit pas : il part. Un outil de suivi d'erreurs vous prévient avant lui, avec le contexte pour corriger. Ajoutez des journaux lisibles sur tout ce qui tourne sans vous regarder (e-mails, paiements, tâches planifiées).
Le cadre légal
Mentions légales, conditions générales de vente, politique de confidentialité, registre des sous-traitants pour le RGPD (l'hébergeur, Stripe, l'outil d'e-mail, le fournisseur d'IA si vous en appelez un). Ce n'est pas du code, mais un client professionnel vous le demandera avant de signer.
La brique 3 mérite qu'on s'y arrête : c'est elle qui fait les fuites de données. On détaille les vérifications dans vibe coding : que vérifier avant la mise en production.
Dans quel ordre s'y prendre ?
L'erreur classique est de commencer par ce qui se voit (un nouveau design, une page d'accueil) et de garder pour la fin ce qui protège. L'ordre qui marche est l'inverse.
Phase 1 : rendre le prototype sûr
Mettre le code dans un dépôt Git, sortir les clés et mots de passe du code, brancher une vraie base avec sauvegardes, ajouter les comptes et le cloisonnement entre clients. À ce stade, rien ne change pour l'utilisateur, et c'est normal.
Phase 2 : le rendre vendable
Le paiement, le domaine, les e-mails, les pages légales, le suivi d'erreurs. À la fin de cette phase, un inconnu peut s'inscrire, payer et utiliser le produit sans que vous interveniez.
Phase 3 : le faire grandir
Les vraies demandes de vos premiers clients, un tableau de bord pour suivre l'usage, les intégrations qu'on vous réclame. C'est là que le produit prend de la valeur, et c'est là que le rythme de livraison compte le plus.
Pour savoir où s'arrêter avant de lancer, on fait la différence entre les deux étapes dans MVP ou V1 : ce qui change vraiment.
Combien coûte le passage en SaaS ?
Les outils eux-mêmes coûtent peu au départ. Le vrai coût, c'est le temps de quelqu'un qui sait quoi vérifier.
Côté outils : Stripe prélève une commission par paiement (de l'ordre de 1,5 % + 0,25 € pour une carte européenne standard, sans abonnement fixe). L'offre gratuite de Vercel exclut l'usage commercial : comptez environ 20 $ par mois et par membre pour l'offre Pro. Ajoutez une base de données hébergée, un outil d'e-mail et un domaine : quelques dizaines d'euros par mois au démarrage. Tarifs vérifiés le 23 octobre 2026 ; ils bougent, vérifiez les conditions actuelles.
Côté travail, quatre façons de faire, avec leurs vrais compromis :
| Option | Ce que ça coûte | Ce qui va bien | Ce qui coince |
|---|---|---|---|
| Continuer seul avec Claude | Votre temps, le soir | Gratuit ou presque, vous apprenez | Personne ne relit la sécurité, et vous n'avancez plus sur la vente |
| Un freelance | Au jour ou au forfait | Souple, bon pour un chantier précis | Dépend d'une personne, disponibilité variable |
| Une agence au projet | Un devis, souvent à cinq chiffres | Périmètre cadré, équipe complète | Chaque évolution après la livraison repart en devis |
| Un abonnement de développement | Un forfait mensuel (1 990 € HT par mois chez Figue) | Les phases 1 à 3 avancent demande par demande, sans devis | Une demande active à la fois : il faut prioriser |
Pour situer ces montants face à un développement complet, on a détaillé les fourchettes dans combien coûte la création d'un SaaS. Transparence : Figue vend l'option abonnement, c'est donc notre préférence. Elle ne convient pas à tout le monde, voir ci-dessous.
Pour qui c'est le bon moment ?
Tous les projets Claude n'ont pas vocation à devenir un SaaS vendu à d'autres. Mais un outil interne qui porte votre activité (vos clients, vos devis, vos documents officiels) mérite le même sérieux : les briques 1 à 3 et 6 s'appliquent à lui aussi.
Si votre outil doit remplacer un logiciel que vous payez aujourd'hui, la reprise des données et la bascule ont leurs propres pièges : on les détaille dans remplacer son logiciel métier par un outil fait avec l'IA. Et pour comparer honnêtement avec le fait de continuer seul, voir Figue ou le faire soi-même avec l'IA.
FAQ
Questions fréquentes
Ce qu'on nous demande le plus quand un fondateur arrive avec un projet fait avec Claude.
Peut-on vendre une application codée avec Claude ?
Oui. Le code produit par l'IA vous appartient et peut servir un produit commercial. Ce qui compte n'est pas l'outil qui l'a écrit, mais ce qui l'entoure : des comptes, des données cloisonnées et sauvegardées, un paiement, des conditions de vente et quelqu'un qui corrige quand ça casse.
Faut-il tout réécrire pour passer en SaaS ?
Rarement. Dans la plupart des cas, on consolide le prototype brique par brique : dépôt Git, base de données, comptes, droits, paiement. Une réécriture se justifie seulement si la structure empêche d'ajouter proprement les comptes et le cloisonnement entre clients, ce qu'un développeur constate en lisant le code.
Combien de temps faut-il pour passer d'un prototype à un SaaS ?
Pour un prototype simple, les briques de base (comptes, base de données, droits, paiement, mise en ligne) représentent en général quelques semaines de travail pour une personne expérimentée. Le délai réel dépend de l'état du code et du nombre de cas particuliers de votre activité.
Claude peut-il ajouter lui-même les comptes et le paiement ?
Il peut écrire le code. Le risque est ailleurs : il ne sait pas ce qu'il a oublié. Un paiement qui marche en test mais ne gère pas la carte expirée, ou des droits vérifiés à l'écran mais pas côté serveur, ne se voient pas en démo. Il faut quelqu'un qui sait quoi vérifier, et qui relit.
Quelle est la différence entre un prototype IA et un MVP ?
Un prototype montre que l'idée fonctionne, pour vous. Un MVP est la plus petite version qu'un client peut utiliser seul et payer : il inclut donc les comptes, la protection des données et le paiement que le prototype n'a pas.
