Application Lovable : à corriger avant la mise en production

Lovable permet de décrire une application et de la voir apparaître : écrans, inscription, base de données, et même paiements. Pour un fondateur, cette rapidité a une vraie valeur. Le piège, c'est qu'un prototype et un produit sont deux choses différentes. Un prototype a un seul utilisateur, des données de test bienveillantes et aucune conséquence. Un produit a des inconnus, des données personnelles et une réputation.

Ce guide s'adresse aux fondateurs qui veulent mettre en production une application Lovable et la rendre prête pour la production sans tâtonner. Si vous voulez d'abord un aperçu rapide de votre situation, lancez notre AI App Health Check gratuit. Il met en évidence les domaines ci-dessous qui demandent le plus d'attention. Lovable et Supabase évoluent rapidement : vérifiez donc tout détail propre à la plateforme dans les paramètres de votre projet et dans la documentation actuelle.

Prototype ou production : ce qui change vraiment

Lovable est un constructeur d'applications par IA, souvent associé à Supabase pour l'authentification, une base de données Postgres et le stockage de fichiers. Cette combinaison reporte une grande part de la responsabilité de sécurité sur la configuration : politiques de base de données, paramètres de redirection, clés d'API et règles de stockage. Le constructeur génère le code, mais il ne voit ni vos vrais utilisateurs, ni votre vrai argent, ni vos vraies erreurs.

Être prêt pour la production signifie que chacune de ces configurations a été testée par quelqu'un qui cherche à la contourner. Les sections ci-dessous suivent l'ordre dans lequel les problèmes font généralement le plus de dégâts.

Les points où les applications créées avec Lovable demandent en général une intervention d'ingénierie

1. La sécurité au niveau des lignes de Supabase (RLS)

C'est la première chose à vérifier. Dans une configuration Supabase, le navigateur dialogue avec la base de données via une clé publique, et ce sont les politiques de sécurité au niveau des lignes (RLS) qui déterminent ce que chaque utilisateur peut lire ou écrire. Une table sans politique, ou avec des politiques qui autorisent tout, peut exposer les données de tous vos clients.

Testez avec deux comptes. Créez un client A et un client B avec des enregistrements distincts. Connectez-vous en tant que B, puis essayez d'ouvrir, de modifier et de supprimer les enregistrements de A en changeant les identifiants dans les URL et en appelant directement l'API. Si l'une de ces manipulations fonctionne, vous avez un point bloquant pour le lancement. Notre guide sur les sept erreurs de RLS des applications créées par IA détaille les schémas à repérer, notamment les rôles stockés à un endroit que les utilisateurs peuvent modifier et les buckets de stockage trop ouverts.

2. Authentification, URL de redirection et flux d'e-mails

Une authentification qui fonctionne sur une URL de prévisualisation se casse souvent, ou pire, se comporte de façon trop permissive, sur votre vrai domaine. Vérifiez les points suivants :

• L'URL du site et la liste des URL de redirection autorisées mentionnent votre domaine de production, et non d'anciennes adresses de prévisualisation ou des jokers dont vous n'avez plus besoin.
• La confirmation par e-mail, les liens magiques et la réinitialisation du mot de passe fonctionnent de bout en bout en production, et les liens de réinitialisation expirent et ne peuvent pas être réutilisés.
• Les e-mails d'authentification partent de votre propre domaine, avec SPF, DKIM et DMARC configurés, afin de ne pas finir dans les spams. L'expéditeur par défaut est généralement prévu pour les tests plutôt que pour un trafic réel ; vérifiez les paramètres de votre projet.
• Les actions réservées aux administrateurs sont appliquées côté serveur ou par une politique de base de données, et pas seulement masquées dans l'interface.

3. Les secrets et ce qui parvient au navigateur

Tout ce qui est intégré au code du frontend est public. Une clé publique Supabase (anon) est conçue pour être visible, mais elle n'est sûre que si vos politiques RLS sont correctes. Une clé service-role, une clé secrète de paiement ou une clé de fournisseur d'IA dans le code du frontend constitue une fuite grave. Recherchez des clés dans votre JavaScript compilé et dans l'historique de votre dépôt, renouvelez tout ce qui a été exposé, et déplacez les appels qui nécessitent des secrets vers des fonctions côté serveur. Définissez des plafonds de dépense sur toute clé d'IA ou d'API tierce.

4. Webhooks Stripe et droits d'accès

Un parcours de paiement qui fonctionne en mode test n'est pas terminé. L'accès payant doit découler d'événements de webhook vérifiés, et non de la page de succès sur laquelle arrive le navigateur. Vérifiez que les signatures sont contrôlées, que les livraisons répétées sont gérées sans risque, et que les renouvellements échoués, les résiliations et les remboursements modifient correctement les accès. Les clés de test et de production ne doivent jamais être mélangées. Les détails figurent dans notre guide sur les webhooks et abonnements Stripe dans les applications créées par IA.

5. Structure du code généré, duplication et tests

Le code généré fonctionne souvent, mais se répète : des composants similaires copiés avec de petites différences, des règles métier éparpillées dans l'interface et aucun test automatisé. Ce n'est pas une urgence le premier jour, mais c'est la raison pour laquelle une petite modification peut casser quelque chose sans rapport. Avant de passer à l'échelle, ajoutez des tests autour des parcours d'argent et de permissions, regroupez les règles dupliquées en un seul endroit et gardez les changements de base de données dans des migrations versionnées, afin que le schéma puisse être recréé et relu.

6. Performance et supervision des erreurs

Une démo avec dix lignes est rapide. Des données réelles révèlent les requêtes qui récupèrent tout, les index de base de données manquants et les pages qui chargent trop de choses. Ajoutez une supervision des erreurs et des alertes de disponibilité qui atteignent une personne, afin d'apprendre une panne avant qu'un client ne vous la signale. Testez vos pages de liste avec des volumes de données réalistes, et non avec des lignes d'exemple.

7. Déploiement, domaines et sauvegardes

Décidez où l'application s'exécute, qui peut déployer et comment revenir à la dernière version fonctionnelle. Séparez la préproduction et la production, chacune avec sa propre base de données et ses propres clés. Vérifiez votre domaine et votre configuration HTTPS, activez les sauvegardes de la base de données et restaurez-en une pour de bon afin de mesurer le temps nécessaire. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un plan.

8. Propriété du code, dépôt et export

Assurez-vous de posséder ce que vous construisez. Connectez le projet à un dépôt hébergé dans un compte que vous contrôlez, vérifiez que vous pouvez exécuter l'application en dehors du constructeur, et gardez le projet Supabase, le registraire de domaine et le compte de paiement sous des identifiants d'entreprise plutôt que sous ceux d'une personne ou d'un prestataire. Les fonctionnalités et les conditions de Lovable évoluent : consultez donc la documentation actuelle. Disposer du code dans votre propre dépôt facilite aussi grandement tout travail d'ingénierie ultérieur.

Ce que vous pouvez continuer à faire par prompts, et quand faire appel à un ingénieur

Continuez à utiliser des prompts pour les tâches où une erreur est visible et peu coûteuse : mise en page, textes, couleurs, nouveaux écrans qui n'affichent à l'utilisateur que ses propres données, petites fonctionnalités de contenu. Relisez le résultat, conservez une version à laquelle revenir et évitez de demander à l'outil de réécrire ce qui fonctionne déjà.

Faites appel à un ingénieur lorsqu'une erreur serait invisible ou coûteuse : politiques de base de données, paramètres d'authentification, tout ce qui touche aux paiements, migrations qui modifient ou suppriment des données, secrets, et tout domaine où chaque correction semble en casser une autre. Si vous ne savez pas expliquer qui peut voir quoi dans votre application, cela suffit à lui seul. Nous approfondissons cette décision dans quand arrêter les prompts et faire appel à un ingénieur, et la liste complète des vérifications figure dans la checklist de préparation à la production en 20 points.

Un parcours de remise en état, étape par étape

1. Auditer. Obtenez une revue indépendante du contrôle d'accès, des politiques de données, des paiements, des secrets et du déploiement. Le résultat doit être une liste priorisée avec les étapes pour reproduire chaque problème, et non une note vague.
2. Corriger les problèmes critiques. Commencez par tout ce qui expose des données ou de l'argent : politiques manquantes ou trop permissives, clés divulguées, webhooks non vérifiés.
3. Renforcer. Ajoutez des tests pour les parcours de permissions et de facturation, déplacez les secrets et la logique sensible côté serveur, mettez en place les migrations, la préproduction, la supervision et les sauvegardes.
4. Lancer. Publiez avec un plan de retour arrière, un responsable désigné et des alertes que quelqu'un traitera. Si possible, commencez avec un petit groupe d'utilisateurs réels.
5. Maintenir. Les dépendances, les évolutions de la plateforme et les nouvelles fonctionnalités continuent d'arriver. Décidez qui applique les mises à jour et surveille les erreurs, que ce soit votre équipe ou un forfait de maintenance.

Remarquez ce qui manque : une réécriture. La plupart des applications peuvent être réparées sur place, et un audit est le moyen de savoir si la vôtre en fait partie.

Comment UnlockLive intervient

UnlockLive IT travaille depuis Toronto avec un centre d'ingénierie à Dhaka, et c'est précisément cette étape que nous accompagnons.

• L'AI App Technical Audit est la première étape : nous examinons votre configuration Lovable et Supabase, testons les zones à risque et vous remettons une liste de corrections priorisée que vous pouvez exploiter, avec nous ou sans nous.
• Le service AI App Repair and Launch mène cette liste à son terme : correction des problèmes critiques, renforcement de l'application et mise en ligne sur une infrastructure que vous contrôlez.

Si vous hésitez sur le besoin de l'un ou de l'autre, sachez qu'un audit technique diffère aussi d'un test d'intrusion ; notre comparatif audits, tests d'intrusion et revues de code explique lequel correspond à votre situation.

Commencez par une vérification gratuite

Avant de dépenser quoi que ce soit, faites le point sur votre situation. Notre AI App Health Check gratuit prend quelques minutes et indique les zones de votre application Lovable qui méritent le plus un examen approfondi. Utilisez ensuite la liste ci-dessus pour tester vous-même les inconnues, et faites appel à un ingénieur pour ce que vous ne pouvez pas vérifier. Rendre une application Lovable prête pour la production consiste surtout à découvrir les problèmes tant que la seule personne concernée, c'est vous.