Le prochain logiciel que votre entreprise paie 100 € par mois, allez-vous simplement le fabriquer avec Lovable ?
Votre entreprise paie peut-être 100 € par mois pour un CRM dont elle utilise cinq écrans. Jusqu’ici, le remplacer imposait de recruter un développeur ou d’accepter les limites d’un tableur. Lovable propose une troisième option : décrire ces cinq écrans, connecter les données et fabriquer un outil interne sur mesure. Mais le calcul n’est intéressant que si l’on compte aussi la personne qui devra le maintenir.
La valorisation de Lovable à 13,3 milliards de dollars ne prouve pas que votre prochain logiciel doit être construit plutôt qu’acheté. Elle révèle cependant un changement de comportement : un prototype fonctionnel coûte désormais assez peu pour que le build vs buy soit testé avant de renouveler machinalement un abonnement SaaS.
Le test utile en une phrase
Reproduisez uniquement les 20 % de fonctions réellement utilisées, faites tourner l’ancien SaaS et l’application Lovable en parallèle pendant 14 jours, puis décidez avec un coût total sur 24 mois — temps humain compris.
Ce que la levée de 400 millions de dollars change réellement
Le 12 août 2026, Lovable a annoncé une série C de 400 millions de dollars et une valorisation de 13,3 milliards. La société affirme que plus de 60 millions de projets ont été créés depuis son lancement en novembre 2024 et que les applications produites avec sa plateforme cumulent plus de 900 millions de visites mensuelles. Ce sont des chiffres communiqués par Lovable, pas un audit indépendant.
Le montant de la levée est moins important que la feuille de route qui l’accompagne. Lovable met désormais en avant les paiements, le référencement, les intégrations à Google Workspace, Microsoft 365, Salesforce ou Stripe, les analyses de sécurité, les contrôles de publication et la gouvernance. Autrement dit, les fonctions qui séparent une jolie démonstration d’un logiciel utilisé par une équipe.
L’entreprise cite notamment Nursa, qui déploierait Lovable auprès de plus de 200 salariés et travaillerait au retrait de dix logiciels SaaS. Là encore, il s’agit d’un témoignage client choisi par l’éditeur. Le signal demeure intéressant : Lovable ne cherche plus seulement à concurrencer les outils de prototypage, mais une partie du budget logiciel des entreprises.
Cette évolution prolonge le mouvement observé avec Figma Make, Lovable et Replit, qui transforment une maquette ou une consigne en application modifiable. La question n’est plus « peut-on générer une interface ? », mais « qui assume les données, les droits, les sauvegardes et les incidents une fois l’interface adoptée ? ».
Notre cas pratique : remplacer seulement 20 % d’un petit CRM
Prenons une équipe de huit à dix personnes qui paie 100 € par mois pour un petit CRM ou un outil de suivi des demandes. Après observation, elle n’utilise réellement que six fonctions :
- une fiche contact ou client ;
- un statut dans un pipeline simple ;
- des notes et un historique daté ;
- des tâches avec une échéance ;
- un import et un export CSV ;
- deux rôles : membre et responsable.
Le premier piège serait de demander à Lovable de « refaire notre CRM ». Le projet gonflerait immédiatement avec les rapports avancés, l’e-mailing, la téléphonie, les prévisions, l’application mobile et des dizaines de réglages. Pour obtenir une comparaison honnête, le périmètre doit tenir sur une page et chaque fonction supplémentaire doit répondre à un usage observé.
Le prototype peut commencer avec une consigne de ce type :
Crée une application interne de suivi commercial en français.
Elle comporte une liste de contacts, une fiche contact, un pipeline à quatre statuts,
des notes horodatées, des tâches avec échéance et un import/export CSV.
Deux rôles existent : membre et responsable.
Un membre ne voit que les fiches qui lui sont attribuées ; le responsable voit tout.
Ne crée aucune fonction non demandée. Prépare des données factices pour les tests.Il faut ensuite transformer cette consigne en critères vérifiables : un utilisateur ne doit jamais accéder à la fiche d’un collègue en modifiant l’URL ; un export doit pouvoir être réimporté ; les dates doivent conserver le bon fuseau horaire ; la suppression doit être confirmée ; les actions sensibles doivent laisser une trace. Une interface réussie ne compense pas une règle d’accès absente.
Le calcul sur 24 mois qui change la réponse
Les tarifs officiels sont affichés en dollars. Pour éviter un taux de change arbitraire, le scénario ci-dessous compare un SaaS à 100 dollars par mois au forfait Lovable Business annuel à 500 dollars par an. Si votre facture est de 100 €, remplacez simplement les montants par vos coûts réels : la méthode reste identique.
| Scénario sur 24 mois | Abonnements | Temps humain à 60 $/h | Total avant hébergement supplémentaire |
|---|---|---|---|
| SaaS existant | 2 400 $ | Non compté dans cet exemple | 2 400 $ |
| Lovable, hypothèse optimiste | 1 000 $ | 8 h initiales + 15 min/mois = 840 $ | 1 840 $ |
| Lovable, 1 h de maintenance/mois | 1 000 $ | 8 h initiales + 24 h = 1 920 $ | 2 920 $ |
Le seuil de rentabilité est brutal : 2 400 $ de SaaS moins 1 000 $ de Lovable laissent 1 400 $, soit 23 heures et 20 minutes de travail humain à 60 $ de l’heure. Après huit heures de construction initiale, il ne reste que 15 heures et 20 minutes pour les deux années suivantes — environ 38 minutes par mois pour corriger les bugs, revoir les droits, tester les mises à jour, surveiller les sauvegardes et aider les utilisateurs.
À quinze minutes de maintenance mensuelle, l’application économise 560 $ sur deux ans avant les coûts variables. À une heure par mois, elle coûte déjà 520 $ de plus que le SaaS. Le « logiciel à 50 $ par mois » n’est donc rentable que si le processus est stable et si la maintenance reste exceptionnellement faible, ou si l’abonnement remplacé coûte nettement plus de 100 $.
La formule à copier
heures disponibles = (coût SaaS sur 24 mois − abonnements de la solution construite − autres coûts) ÷ coût horaire chargé
Si ce nombre ne couvre pas la construction, la migration, la formation et deux ans de maintenance, l’achat reste moins cher même si le prototype a été généré en une soirée.
Business à 50 $ par mois ne signifie pas « entreprise complète »
La documentation des abonnements Lovable affiche Pro à 25 $ par mois et Business à 50 $ pour 100 crédits mensuels, avec une remise en paiement annuel. Les membres du workspace sont illimités : c’est un avantage réel face à un SaaS facturé par siège. En revanche, les crédits sont partagés et la consommation dépend des demandes adressées à l’agent.
Business apporte notamment la publication interne, les rôles, le SSO et un centre de sécurité. Des exigences courantes dans les grandes organisations — journaux d’audit, SCIM, contrôles poussés de publication, connecteurs personnalisés ou analyses planifiées — apparaissent dans l’offre Enterprise à tarif personnalisé. Si votre politique impose l’un de ces éléments, comparer « 50 $ contre 100 $ » n’a plus de sens avant d’avoir obtenu un devis.
L’hébergement et l’usage méritent aussi une ligne séparée. Un petit outil peut rester dans les quotas inclus ; le trafic, le stockage, les fonctions serveur, les appels d’IA et les services externes peuvent ensuite ajouter des coûts. Le tableur de décision doit contenir la facture Lovable, mais aussi la base de données, les e-mails, les API payantes, la supervision et le temps de support.
Posséder le code ne suffit pas pour être indépendant
Lovable permet de synchroniser un projet avec GitHub ou GitLab, de télécharger le code sur les forfaits payants et de déployer l’application ailleurs. Sa documentation sur la propriété et l’hébergement présente donc une vraie porte de sortie. Il faut l’ouvrir avant d’en avoir besoin.
Quitter la plateforme transfère toutefois à votre équipe l’environnement de développement, le déploiement continu, les certificats, le CDN, la montée en charge, la base, les sauvegardes, l’authentification, les secrets, la supervision et la conformité. L’éditeur visuel et l’agent de Lovable ne sont pas auto-hébergeables. Une migration de Supabase vers un PostgreSQL générique peut aussi exiger de remplacer l’authentification, le stockage, le temps réel ou les fonctions spécifiques.
La bonne mesure de l’indépendance n’est donc pas « le bouton GitHub existe ». C’est la réussite d’un exercice de sortie :
- synchroniser le dépôt dès le premier jour et cloner une copie hors de Lovable ;
- exporter le schéma et des données factices, puis réussir une restauration ;
- inventorier les secrets et services externes sans les stocker dans le code ;
- déployer une version de test à partir du dépôt seulement ;
- documenter le retour arrière et nommer la personne qui peut l’exécuter.
Un fichier comme AGENTS.md peut fixer les règles que Lovable, Codex ou Claude doivent respecter dans le dépôt : structure, tests obligatoires, gestion des secrets et critères de validation. Il ne remplace ni un responsable technique ni une procédure de restauration réellement testée.
Sécurité : les scanners aident, ils ne portent pas la responsabilité
Lovable indique lancer une analyse rapide lors de chaque publication et proposer des contrôles plus approfondis. Sa page consacrée à la sécurité détaille aussi le SSO, les rôles et plusieurs fonctions de gouvernance selon les offres. Ces protections réduisent le risque ; elles ne garantissent pas que les règles métier de votre application sont correctes.
Pour un CRM interne, les vérifications minimales sont concrètes :
- tester chaque rôle avec plusieurs comptes et des URL modifiées à la main ;
- interdire l’accès aux données au niveau du serveur ou de la base, pas seulement en cachant un bouton ;
- séparer les données de démonstration des données réelles ;
- activer l’authentification forte et retirer rapidement les anciens salariés ;
- chiffrer les échanges, protéger les secrets et limiter les intégrations ;
- définir une durée de conservation et une procédure d’effacement ;
- automatiser les sauvegardes, puis restaurer un échantillon à intervalles réguliers ;
- journaliser les opérations sensibles sans copier de données personnelles inutiles.
Vérifiez également le traitement des données servant à générer l’application. Lovable précise que les contenus des espaces Business et Enterprise ne servent pas à l’entraînement de ses modèles, tandis que les comptes Free et Pro doivent contrôler ce réglage dans leur compte. Les conditions et les offres évoluent : relisez la documentation au moment du projet.
Le protocole de 14 jours avant de résilier le SaaS
Ne migrez pas immédiatement les données de production et ne demandez pas aux salariés d’abandonner l’ancien outil. Faites fonctionner les deux solutions en parallèle avec un échantillon limité et des données nettoyées.
- Jours 1 et 2 : mesurer l’existant. Relevez les écrans ouverts, les exports produits, les intégrations utilisées, les incidents et le temps passé. Supprimez du cahier des charges tout ce qui n’a pas d’usage observé.
- Jours 3 à 5 : construire le noyau. Créez les six fonctions, les deux rôles et des données factices. Connectez Git immédiatement. Ne branchez aucun secret de production.
- Jours 6 et 7 : tenter de casser l’application. Modifiez les URL, importez un CSV invalide, créez des doublons, retirez un droit en cours de session et simulez une restauration.
- Jours 8 à 12 : usage parallèle. Cinq utilisateurs réalisent les mêmes tâches dans les deux outils. Mesurez le temps, les erreurs, les contournements par tableur et les demandes de nouvelles fonctions.
- Jour 13 : exercice de sortie. Déployez depuis le dépôt, exportez les données et demandez à une autre personne de suivre la documentation.
- Jour 14 : décision. Chiffrez les heures déjà dépensées, extrapolez la maintenance, ajoutez les coûts variables et faites signer un responsable identifié.
Les automatisations ne doivent pas être recréées à la main si elles peuvent rester dans un outil spécialisé. Un workflow n8n peut relier le logiciel interne aux e-mails, formulaires et autres applications, à condition d’inclure son hébergement, sa surveillance et ses erreurs dans le coût total.
Construire ou acheter : la matrice de décision
| Construire avec Lovable devient crédible si… | Conserver ou acheter un SaaS reste préférable si… |
|---|---|
| le workflow est étroit, stable et propre à l’entreprise ; | le processus est standard et déjà bien couvert par le marché ; |
| l’équipe n’utilise qu’une petite fraction du logiciel actuel ; | les fonctions avancées, mobiles ou multicanales sont réellement utilisées ; |
| un responsable possède du temps budgété pour la maintenance ; | personne ne peut assumer les incidents et les mises à jour ; |
| les exports et restaurations ont été testés ; | un SLA, un support 24/7 ou une certification contractuelle est indispensable ; |
| l’outil crée un avantage ou supprime beaucoup de travail manuel ; | les données sont très sensibles et l’organisation n’a pas l’expertise de contrôle ; |
| le coût humain reste sous le seuil calculé sur 24 mois. | les API, règles ou obligations réglementaires changent fréquemment. |
Lovable ne signe probablement pas la fin du SaaS. Il peut en revanche mettre fin à une habitude : acheter automatiquement un logiciel complet pour résoudre un besoin étroit. Le prototype généré sert alors de devis vivant. Il montre ce que l’équipe utilise vraiment, révèle les contraintes cachées et donne une base mesurable pour négocier, construire ou conserver l’existant.
Pour un abonnement à 100 par mois, la réponse sera souvent « achetez » dès que la maintenance dépasse quelques dizaines de minutes mensuelles. Pour dix licences facturées par utilisateur, un processus très spécifique et un propriétaire technique disponible, le résultat peut s’inverser. Le bon réflexe n’est donc pas de résilier demain, mais de consacrer 14 jours à prouver que les 20 % utiles peuvent survivre pendant 24 mois.
Article vérifié le 15 août 2026 à partir des annonces et documentations officielles de Lovable. Les chiffres de projets, de visites et de clients sont des déclarations de l’entreprise. Les tarifs, quotas et fonctions par offre peuvent évoluer ; contrôlez-les avant toute décision contractuelle.
