App créée avec Lovable, Bolt ou Cursor : 9 vérifications avant la mise en production

Les outils de génération d’applications permettent d’obtenir un produit utilisable en quelques jours. C’est un vrai progrès, et la plupart des prototypes que nous voyons méritent d’être conservés. Ils partagent pourtant les mêmes faiblesses, parce que l’outil optimise ce qui se voit à l’écran, pas ce qui se passe quand quelqu’un essaie de contourner l’interface.

Le problème n’est pas théorique. La faille CVE-2025-48757 concernait des applications créées avec Lovable dont la base de données restait lisible par n’importe qui, faute de règles d’accès correctes.

Voici ce qu’il faut vérifier avant de confier de vraies données à l’application.

1. Les règles d’accès à la base de données

C’est le point le plus important. Avec Supabase, très utilisé par ces outils, le navigateur parle directement à la base. La seule protection est la sécurité au niveau des lignes (row level security, RLS) : des règles qui disent qui peut lire ou modifier chaque ligne.

Deux erreurs reviennent sans cesse : la RLS est désactivée sur une table, ou elle est activée avec une règle qui autorise tout le monde. Dans les deux cas, n’importe quel visiteur peut lire la table entière. Il faut vérifier chaque table, et tester en se connectant avec un second compte qui ne devrait rien voir.

2. Les clés et les secrets

Tout ce qui est envoyé au navigateur est public. Une clé d’API de paiement, d’envoi d’e-mails ou de modèle d’IA placée dans le code de l’interface peut être récupérée en quelques secondes. La clé d’administration de la base (service_role chez Supabase) ne doit jamais s’y trouver : elle contourne toutes les règles d’accès.

Les secrets doivent rester côté serveur. Si une clé a déjà été exposée, il faut la révoquer et en créer une nouvelle : la retirer du code ne suffit pas.

3. Les contrôles faits uniquement à l’écran

Masquer un bouton à un utilisateur ne l’empêche pas d’appeler directement la fonction derrière. Chaque action sensible doit être contrôlée côté serveur : cet utilisateur a-t-il le droit de modifier cet enregistrement, ce montant est-il plausible, ce rôle est-il bien le sien.

Vérifiez en particulier tout ce qui touche aux rôles. Si l’application lit le rôle « administrateur » dans une donnée que l’utilisateur peut modifier lui-même, tout le monde peut le devenir.

4. La connexion et les comptes

Trois points simples : la vérification de l’adresse e-mail est-elle active, le nombre de tentatives de connexion est-il limité, et la réinitialisation de mot de passe fonctionne-t-elle réellement, avec un vrai envoi d’e-mail depuis votre domaine.

5. Les sauvegardes, et surtout la restauration

Demandez-vous ce qui se passe si une table est effacée par erreur demain matin. Une sauvegarde automatique existe-t-elle, sur quelle durée, et quelqu’un a-t-il déjà essayé de la restaurer ? Une sauvegarde jamais testée est une hypothèse.

6. La séparation entre test et production

Beaucoup d’applications générées n’ont qu’un seul environnement : chaque modification demandée à l’IA s’applique directement à la version utilisée par les clients, base de données comprise. Il faut au minimum une copie de test, et une façon de revenir en arrière.

7. Le paiement

Si l’application encaisse, le statut « payé » ne doit jamais être décidé par le navigateur. C’est le prestataire de paiement qui confirme, par une notification envoyée à votre serveur (webhook), et cette notification doit être authentifiée par sa signature. Sans cela, un utilisateur peut se déclarer abonné sans payer.

8. Ce que vous voyez quand quelque chose casse

En production, une erreur ne se signale pas toute seule. Il faut un journal des erreurs consultable et une alerte quand l’application ne répond plus. Sinon, vous l’apprendrez par un client.

9. La propriété du code

Le code doit se trouver dans un dépôt Git qui vous appartient, avec la liste des services utilisés et de leurs accès. Le jour où vous voudrez faire intervenir un développeur, changer d’outil ou répondre à la question d’un investisseur, c’est ce qui rendra la reprise possible.

Consolider plutôt que tout refaire

Ces neuf points ne condamnent pas l’application. Ils délimitent ce qui doit être repris : en général les accès aux données, les secrets, les sauvegardes et les traitements sensibles. L’interface et la logique principale restent.

Si vous préférez un regard extérieur, notre offre de reprise de projets codés avec l’IA commence par un pré-diagnostic gratuit, réalisé uniquement avec votre accord écrit. Nous n’examinons jamais une application sans y avoir été invités.

Questions fréquentes

Faut-il réécrire une application générée par IA ?

Rarement en entier. Dans la plupart des cas, l’interface et la logique principale peuvent être conservées. Ce qui doit être repris concerne les règles d’accès aux données, la gestion des secrets, les sauvegardes et les traitements sensibles comme le paiement.

Peut-on vérifier la sécurité de son app sans être développeur ?

En partie. Vous pouvez vérifier que la sécurité au niveau des lignes est activée sur vos tables, qu’une sauvegarde existe et que le code est dans un dépôt qui vous appartient. Le contrôle des règles d’accès elles-mêmes et la recherche de clés exposées demandent un regard technique.

Que risque-t-on si la base de données est exposée ?

Au-delà de la perte de confiance, une violation de données personnelles entraîne des obligations légales : notification à la CNIL sous 72 heures en France, annonce au Préposé fédéral dans les meilleurs délais en Suisse lorsque le risque est élevé pour les personnes.