Créer un SaaS avec l'IA (Claude Code, Cursor, Lovable) : jusqu'où aller seul ?

Un fondateur peut ouvrir Lovable un lundi et montrer un SaaS qui fonctionne le vendredi. La question n’est donc plus de savoir si l’IA sait coder, mais ce qu’elle laisse de côté quand personne ne le lui demande. Voici ce qu’un SaaS doit tenir après la démo, comment le vérifier vous-même, et quand un studio de développement SaaS devient utile.

Peut-on créer un SaaS avec l’IA sans être développeur ?

Oui pour valider une idée, non pour vendre. L’IA suffit à créer un SaaS de démonstration et à le faire tester par quelques utilisateurs, en quelques jours et pour quelques dizaines d’euros d’abonnement. Elle ne suffit pas, sans relecture par un développeur, pour encaisser les abonnements de clients professionnels qui vous confient leurs données.

Un SaaS (logiciel en tant que service) est un logiciel vendu par abonnement et utilisé en ligne, où tous les clients partagent la même application tout en gardant chacun leurs données à part.

La frontière passe par l’argent et par les données des autres. Tant que vos testeurs manipulent des données fictives et ne paient rien, une faille coûte une correction. Dès qu’une entreprise paie pour stocker chez vous ses clients ou ses devis, une faille coûte un contrat, et parfois une notification de violation de données à la CNIL.

Le vibe coding est une façon de développer qui consiste à décrire son application en langage naturel à une IA et à accepter le code produit sans le lire. Idéal pour un prototype, il laisse sans réponse tout ce que la démo ne montre pas.

Que livrent Claude Code, Cursor ou Lovable par défaut ?

Par défaut, ces outils livrent ce que la démo montre : des écrans, une base de données, une connexion par e-mail, un paiement de test et une mise en ligne en un clic. Ils livrent rarement, sans demande précise, ce que le client ne voit pas : cloisonnement des données entre clients, restauration des sauvegardes, alertes, gestion des secrets.

Deux familles d’outils coexistent :

• Les générateurs d’applications (Lovable, Bolt) : vous décrivez le produit dans une conversation, l’outil construit et héberge une application web complète. La voie la plus rapide pour un fondateur non technique.
• Les agents et éditeurs de code (Claude Code, Cursor) : ils écrivent et modifient le code d’un projet sous la conduite de quelqu’un qui sait le lire. Sans ce lecteur, cela redevient du vibe coding.

Ces outils ne sont pas incapables : entre les mains d’un développeur qui sait quoi demander et contrôle le résultat, Claude Code écrit une isolation par client correcte. Mais personne ne demande une sauvegarde restaurée dans un prompt de démo.

Lovable le dit lui-même : ses analyses de sécurité intégrées ne remplacent pas une revue approfondie, et des règles d’accès mal configurées sont une cause fréquente de fuites de données (documentation sécurité de Lovable, consultée en octobre 2026). Le constat dépasse un outil : sur plus de 100 modèles de langage testés, le code généré introduit une faille de sécurité dans 45 % des tests, et les modèles plus récents ne font pas mieux (Veracode, GenAI Code Security Report 2025, mis à jour en octobre 2025).

Quelles exigences un SaaS doit-il tenir après la démo ?

Un SaaS vendu à des professionnels doit tenir neuf exigences que la démo ne montre jamais : isolation des données entre clients, authentification et rôles, abonnement et facturation, RGPD, sauvegardes restaurables, supervision, sécurité des secrets, montée en charge et réversibilité. Chacune se vérifie par un test simple, même sans lire le code.

Les données : isolation, rôles, RGPD

• Isolation des données entre clients. Une architecture multi-tenant est une organisation du logiciel qui fait cohabiter plusieurs clients dans la même application et la même base, chacun isolé dans son espace avec ses utilisateurs et ses données. Le contrôle d’accès défaillant reste le risque n°1 du classement OWASP Top 10 de 2025, trouvé sous une forme ou une autre dans 100 % des applications testées ; un contrôle d’accès n’est efficace qu’appliqué côté serveur (OWASP Top 10:2025, A01). Le test : créez deux organisations clientes, copiez l’adresse d’une fiche de la première et ouvrez-la connecté avec la seconde. Si elle s’affiche, le SaaS n’est pas vendable.
• Authentification et rôles. Une connexion par e-mail n’est pas une gestion des droits. Un client professionnel attend un administrateur qui invite ses équipes, des rôles distincts et une révocation immédiate quand un salarié part. Le test : connectez-vous avec un compte simple et ouvrez directement l’adresse d’une page d’administration. La règle vaut aussi pour les assistants d’IA. Le MCP (Model Context Protocol) est un protocole ouvert qui permet à un assistant comme Claude d’agir dans un logiciel au travers d’outils déclarés. Kascade et Smashr, deux de nos produits en lancement, exposent chacun un serveur MCP. La règle y est la même que pour un humain : un assistant connecté ne doit jamais avoir plus de droits que le compte qui l’a connecté.
• RGPD. Un éditeur de SaaS B2B est en général sous-traitant des données que ses clients déposent chez lui : contrat de sous-traitance avec chaque client, registre des traitements, export et suppression des données d’une personne sur demande. Le test : un utilisateur demande la suppression de son compte, combien d’étapes manuelles faut-il ? Les bases sont dans RGPD et SaaS : ce qu’un dirigeant doit vraiment savoir.

L’argent : abonnement et facturation

Un bouton de paiement n’est pas un abonnement. Un SaaS gère l’essai qui expire, la carte refusée au renouvellement, le changement d’offre en cours de mois, la licence ajoutée ou retirée, la résiliation. C’est le quotidien de Trottr, notre SaaS de gestion d’interventions terrain, vendu par abonnement avec des licences par utilisateur et utilisé notamment par Engie : chaque licence ajoutée ou retirée doit se retrouver juste sur la facture suivante. Le test : faites échouer un renouvellement avec une carte de test refusée. L’accès est-il suspendu, le client prévenu, la relance programmée ?

Une facture électronique est une facture au format structuré (UBL, CII ou Factur-X), transmise par une plateforme agréée par l’État ; un PDF envoyé par e-mail n’en est pas une. Toutes les entreprises doivent pouvoir en recevoir depuis le 1er septembre 2026, et les PME devront les émettre à partir du 1er septembre 2027. Votre SaaS doit donc se brancher à une plateforme agréée, un interfaçage simple de 2 000 à 5 000 € HT, détaillé dans facture électronique : ce que votre SaaS doit changer avant 2027.

L’exploitation : sauvegardes, supervision, secrets, charge, réversibilité

• Sauvegardes. Une sauvegarde jamais restaurée reste une hypothèse. Le test : restaurez la base de la veille sur un environnement séparé et chronométrez l’opération.
• Supervision. La supervision est l’ensemble des sondes et des alertes qui surveillent un logiciel en production (disponibilité, erreurs, lenteurs) et préviennent une personne désignée dès qu’un seuil est franchi. Le test : qui est prévenu si l’application tombe un dimanche à 3 heures ? Si c’est le premier client qui appelle, la supervision n’existe pas.
• Sécurité des secrets. Un secret est une information qui ouvre l’accès à un service : clé d’API, mot de passe de base de données, clé Stripe. Il doit vivre côté serveur, hors du code, et pouvoir être changé rapidement. Le test : cherchez « sk_live », le début des clés secrètes Stripe de production, dans le dépôt et dans le code chargé par le navigateur.
• Montée en charge. Une application fluide avec trois testeurs ne dit rien de son comportement avec 50 utilisateurs simultanés ou un import de 10 000 lignes. Le test : simulez ces volumes avant de signer le client qui les apporte.
• Réversibilité. La réversibilité est la capacité d’un client, ou la vôtre, à récupérer l’ensemble des données et à changer de prestataire ou d’hébergeur sans perte ni blocage. Vos clients exigeront un export complet, et vous devez détenir vos propres accès. Chez Krafter, tout est mis au nom du client en fin de projet, sauf la stack open source.

Comment créer un SaaS avec l’IA sans mettre vos clients en danger ?

En séparant deux phases que l’IA pousse à confondre : une phase de preuve, menée seul et vite sur des données fictives, puis une phase de production, relue par un développeur avant le premier abonnement payant. Sept étapes, dont les quatre premières se mènent seul.

1. Écrivez le problème avant le premier prompt. Qui paie, combien par mois, pour quels trois parcours. Une page suffit : consigne pour l’IA, puis cahier des charges pour le studio.
2. Prototypez avec l’outil le plus rapide pour vous. Lovable ou Bolt si vous ne lisez pas le code, Claude Code ou Cursor si vous le lisez. Données fictives uniquement. C’est le rôle d’un prototype avant le MVP : apprendre vite, dépenser peu.
3. Faites tester par cinq à dix utilisateurs. Gratuitement ou à un prix pilote annoncé. Observez ce qu’ils font, pas ce qu’ils disent.
4. Documentez ce que l’usage a validé. Règles métier, parcours, écrans inutiles. Ce document vaut plus que le code généré.
5. Passez les neuf tests de la grille. Avant le premier euro encaissé, et notez chaque échec.
6. Faites relire avant de facturer. Un audit avant reprise de 1 à 3 jours livre un rapport écrit et un plan chiffré : ce qui se garde, ce qui se reconstruit.
7. Gardez tout à votre nom. Dépôt de code, hébergement, nom de domaine, compte Stripe : dès le premier jour.

Le moment de passer la main se reconnaît à un seul critère, qui n’est pas technique.

Si votre produit est d’abord une application mobile, la liste s’allonge : comptes développeur, signature, review des stores, détaillés dans créer une application avec l’IA.

Combien coûte le passage d’un SaaS créé avec l’IA à un produit vendable ?

Un MVP SaaS de production coûte 6 000 à 30 000 € HT chez Krafter, et passer d’un prototype généré par IA à ce MVP prend 6 à 12 semaines. Une plateforme SaaS complète, avec API ouverte, tableaux de bord et application mobile, se situe entre 40 000 et 80 000 € HT, pour 10 à 16 semaines de développement.

Les postes de la facture :

• Audit avant reprise : 1 à 3 jours, soit 700 à 3 300 € HT, avec restitution en visio. Le rapport vous appartient.
• MVP SaaS : 6 000 à 30 000 € HT, 4 à 8 semaines de développement, isolation des données et rôles compris.
• Cadrage, si le besoin reste à formaliser : 3 000 à 6 000 € HT de plus.
• Abonnement : 4 000 à 10 000 € HT de plus pour la gestion d’abonnement.
• Après la mise en production : maintien en conditions à 8 à 12 % du développement par an, puis évolutions au temps passé, de 700 à 1 100 € HT par jour.

Le plancher de 6 000 € vaut quand le besoin est défini : processus, règles métier et écrans. Un prototype qui a tourné avec de vrais utilisateurs apporte justement cette définition. Ce prix tient pour trois raisons : un socle open source, FastEdgy, qui évite de réécrire les fondations à chaque projet ; deux associés seniors qui s’appuient sur l’IA, laquelle écrit une grande partie du code, chaque ligne étant relue et testée par l’un d’eux ; aucune couche commerciale à financer.

Scénario type : un fondateur crée avec Lovable un SaaS de suivi des formations obligatoires pour des entreprises du BTP. Après six semaines, huit entreprises l’utilisent gratuitement et trois veulent payer. Le test des deux organisations échoue : une fiche salarié s’ouvre depuis un autre compte client. L’audit de deux jours garde les parcours et les règles d’échéance comme spécification ; la base, les droits et l’abonnement se reconstruisent. Le chiffrage atterrit vers 22 000 € HT, abonnement par utilisateur compris, pour une mise en production en 8 semaines.

Pour une première fourchette sur votre périmètre, utilisez le simulateur de budget logiciel. Si le marché répond mais que le budget manque, le dev for equity échange une partie du développement contre 20 % du capital et plus, avec une facture réduite selon le montage.

Quand rester seul avec l’IA suffit-il ?

Rester seul avec l’IA suffit tant que personne ne vous paie pour garder ses données : validation d’une idée, outil interne pour votre équipe, démo pour lever des fonds. Dans ces cas, payer un studio revient à dépenser trop tôt, et la grille des neuf exigences peut attendre.

• Valider une idée. Données fictives, testeurs prévenus, aucun paiement récurrent.
• Outil interne. Un seul client, vous-même : ni multi-tenant ni facturation, mais une sauvegarde et des secrets à vérifier quand même.
• Démo pour lever ou signer. Un investisseur achète un marché et une équipe ; il fera auditer le code plus tard, à la due diligence.
• Vous savez lire le code. Claude Code ou Cursor entre les mains d’un développeur expérimenté, c’est du développement assisté : vous pouvez tenir la grille vous-même.

Dans ces quatre situations, ne nous appelez pas : gardez votre budget pour le jour où le marché aura répondu. Sinon, faites ce soir le test des deux organisations sur votre prototype. S’il échoue, ou si un premier client s’apprête à signer, montrez-nous ce que vous avez construit : 30 minutes en visio avec un associé, et vous saurez ce qui se garde, ce qui se reconstruit, en combien de semaines et pour quel budget.