Votre app Lovable est en production ? Les failles qu'on retrouve à chaque audit

La sécurité d’une application Lovable en production se joue sur cinq points qu’un audit retrouve presque à chaque intervention : des politiques RLS absentes ou trop larges dans Supabase, des clés d’API exposées dans le navigateur, une authentification contrôlée seulement côté client, l’absence de tests et une isolation des données entre clients approximative. Ces failles ne viennent pas de Lovable : elles viennent du fait qu’une application générée est livrée fonctionnelle sans passer par le durcissement qu’on applique à un logiciel classique.

Le scénario est toujours le même. Le produit construit avec Lovable, Bolt ou v0 a trouvé ses premiers utilisateurs, la facturation tourne, et l’équipe continue d’ajouter des écrans. Le code généré optimise le parcours nominal : il fait ce que vous avez demandé, sur un seul compte, avec les droits d’administration. Dès qu’il y a plusieurs organisations, plusieurs rôles, des données personnelles ou des appels à un LLM facturés au token, les questions de cloisonnement, de coût et de robustesse n’ont jamais été posées.

Voici ce qu’on vérifie dans une application vibe-codée déjà en ligne, le contrôle que vous pouvez mener vous-même en trente minutes, et la manière de corriger sans tout réécrire.

Pourquoi une application générée arrive en ligne sans durcissement

Lovable, Bolt, v0 et Replit produisent une application qui fonctionne : les écrans, la base de données et les paiements sont en place. Ce qu’ils ne produisent pas, ce sont les décisions qui rendent cette application exploitable par plusieurs clients.

Supabase crée des tables utilisables immédiatement, alors que le contrôle d’accès au niveau des lignes (RLS, Row Level Security) se pose table par table, avec une politique par rôle. Sur une démonstration à un seul compte, personne ne remarque son absence.

Le code généré reste sur le chemin nominal : la vérification des droits, la gestion des erreurs réseau, les plafonds d’appel aux modèles et les tests ne sont pas demandés, donc pas écrits. Enfin, la mise en ligne est immédiate, sans étape de relecture : l’application part en production avec les mêmes privilèges qu’en développement.

Quelles failles reviennent dans presque tous les audits ?

1. RLS absente ou permissive. Une table de devis, de factures ou de clients lisible par n’importe quel utilisateur connecté, parce qu’une politique qui autorise tout a été posée pour débloquer la démonstration, et jamais resserrée.
2. Clés exposées côté navigateur. Clé de service Supabase, clé d’API OpenAI ou Anthropic, jeton de webhook : tout ce qui est préfixé NEXT_PUBLIC_ ou VITE_ est servi à quiconque ouvre les outils de développement. C’est la faille la plus coûteuse, parce qu’elle donne un accès direct à la base ou à votre budget de tokens.
3. Authentification contrôlée dans le front. L’écran d’administration est masqué, mais la route d’API reste ouverte. Un utilisateur standard atteint les données réservées en appelant l’adresse directement.
4. Requêtes N+1 et index manquants. Chaque ligne d’un tableau déclenche sa propre requête. L’affichage passe de quelques centaines de millisecondes à plusieurs secondes dès quelques milliers d’enregistrements, et les causes d’une API lente se traitent en général par des index et des jointures.
5. Isolation multi-tenant posée côté client. Le filtre par organisation est écrit dans la requête du navigateur, donc modifiable. Sa place est la politique RLS et la fonction serveur, comme on le détaille dans préparer un produit à la croissance.
6. Aucun test, aucune intégration continue. Chaque correction peut en casser une autre, et personne ne le constate avant les utilisateurs.

Un audit classe ces points par gravité. Dans la plupart des cas, deux ou trois seulement sont critiques sur le moment, le reste relevant de la dette ordinaire à traiter ensuite.

Votre application est-elle exposée ?

Le contrôle tient en cinq étapes et ne demande pas de compétence en développement avancé.

1. Ouvrez votre site, appuyez sur F12, onglet Réseau, puis cherchez dans les requêtes et dans les fichiers JavaScript des traces de clés : service_role, NEXT_PUBLIC_, VITE_, sk-.
2. Créez deux comptes rattachés à deux organisations différentes. Connectez-vous avec le premier et demandez, depuis la console du navigateur, une table ou une route appartenant au second. Si vous obtenez une réponse, l’isolation est à corriger.
3. Dans Supabase, parcourez la liste des tables et vérifiez que RLS est activé partout, avec des politiques par rôle plutôt qu’une politique ouverte.
4. Consultez les journaux de votre fournisseur de modèle : une consommation nocturne ou depuis une adresse inconnue signale une clé qui circule.
5. Lancez un audit des dépendances et vérifiez les versions des paquets chargés de l’authentification et du paiement.

Ce contrôle ne remplace pas une revue de code. Il élimine le pire en une demi-journée.

Combien coûte l’audit d’une app Lovable déjà en production ?

Le check-up coûte 350 € : il suffit pour savoir si votre application est exposée et quels points traiter en priorité. L’audit de reprise coûte 750 € et couvre l’architecture, la sécurité, la dette et les intégrations, avec un plan d’action chiffré au forfait. Il est déduit si le projet de correction démarre sous 60 jours.

Le bon réflexe : commencez par le check-up quand vous voulez une réponse rapide sur le risque, passez à l’audit de reprise quand le produit a des clients payants, des données personnelles ou des coûts d’API qui augmentent. Les deux concernent un existant, application, agent ou automatisation déjà en ligne.

Réparer sur place ou réécrire : comment trancher

Réécrire est rarement la bonne réponse. Une application qui a trouvé ses utilisateurs contient des décisions utiles (parcours, vocabulaire métier, intégrations) qu’une nouvelle version perdrait. Le travail consiste à fermer les accès, déplacer les appels sensibles vers le serveur (fonctions Supabase), ajouter index et politiques RLS, puis couvrir les parcours qui génèrent du chiffre d’affaires par des tests exécutés à chaque livraison.

Les agents de code comme Cursor, Claude Code ou GitHub Copilot accélèrent cette reprise : ils lisent un dépôt existant, proposent les corrections et écrivent les tests, à condition de leur retirer l’accès aux secrets et de relire chaque modification. Le choix entre ces outils se joue sur votre contexte plus que sur leurs fonctionnalités, et le comparatif des outils de génération de code aide à le trancher. Côté exécution, Langfuse permet de suivre les appels aux modèles et leur coût, et pgvector ou Qdrant prennent le relais si la recherche sémantique fait partie du produit.

Un exemple de mise en production : la reprise d’un SaaS Lovable passé de 50 à 3 000 utilisateurs montre le déroulé complet, du classement des risques à la passation documentée.

Pour les règles à appliquer côté interface, API et composants serveur, l’article Sécuriser une application React : interface, API et Server Components détaille les mêmes principes sur une pile technique proche de celle que produisent les générateurs.

Ce qu’il faut exiger avant d’ouvrir à tous vos clients

Avant d’ouvrir une application vibe-codée à l’ensemble de votre marché, demandez par écrit cinq choses : RLS activée sur chaque table avec des politiques par rôle, aucune clé serveur dans le bundle client, appels aux modèles déplacés côté serveur, tests exécutés automatiquement à chaque livraison, plan de correction daté avec critères de sortie. Si ces cinq points ne sont pas fournis, l’application reste un prototype qui fonctionne, et non un produit sur lequel vous pouvez facturer sans risque.

Une reprise se mène sans arrêter l’activité : on gèle les fonctionnalités quelques jours, on corrige les points critiques, on remet l’application en ligne, puis on traite la dette par ordre de gravité. La démarche complète est décrite sur la page reprendre et stabiliser un produit construit avec l’IA, avec les étapes, les livrables et les critères de fin.