Lovable analyse chaque application avant sa publication et corrige les failles d’accès en quelques clics

Vous avez créé une application en une soirée en discutant avec une IA, de vraies personnes l’utilisent déjà — et la question « est-elle seulement sécurisée ? » devient gênante. Lovable y a répondu dans un billet de son équipe de sécurité : ce que la plateforme fait seule, ce qu’elle signale et ce qu’elle vous laisse gérer. Voyons ce qui est réellement utile.

Ce qui fonctionne sans votre intervention

La protection de base est activée par défaut. L’authentification et le contrôle d’accès sont préconfigurés, les secrets sont chiffrés et ne se retrouvent pas dans le code du frontend, et l’application est analysée pendant sa création. Ces protections sont les mêmes pour tout le monde, y compris les comptes gratuits. Pour le vibe coding, ce détail compte : une personne sans bagage technique ne remarquera pas forcément qu’une clé secrète a atterri dans le code côté client.

Le cycle « détecter — corriger — publier »

À chaque publication, les outils d’analyse vérifient le code, la logique de l’application, les schémas de base de données et les politiques de row-level security (RLS). Ces règles déterminent qui peut lire et modifier des lignes précises dans les tables.

Prenons un exemple simple. Vous avez une table de commandes dont la politique autorise tout utilisateur connecté à lire l’intégralité des données, au lieu de ses seules commandes. L’application fonctionne parfaitement, rien ne plante et la faille ne se voit pas à l’œil nu. Selon Lovable, les règles d’accès trop permissives sont précisément le problème le plus fréquent dans les applications de la plateforme. L’outil d’analyse le signale avant la mise en ligne, vous cliquez sur Fix, puis l’agent reçoit une instruction adaptée à ce problème précis et réécrit la politique.

D’autres leviers sont disponibles :

• une analyse approfondie peut être lancée à tout moment et gratuitement : elle prend plus de temps, mais examine davantage de choses. Elle repose sur un système de test maison, entraîné sur les problèmes courants des applications Lovable ;
• l’option « Auto-fix security issues », dans les paramètres du projet, corrige automatiquement de nombreux problèmes détectés lors de votre prochain message dans le chat ;
• le contrôle de publication : vous ou l’administrateur de l’espace de travail pouvez bloquer la mise en ligne tant que des problèmes critiques subsistent.

Ce dernier point est sans doute le plus pratique. Il fait de la sécurité une condition obligatoire plutôt qu’un simple conseil, comme une CI au rouge avant un déploiement.

Ce qui reste à votre charge

La plateforme le dit clairement : examiner les problèmes détectés et agir relève de votre responsabilité, à moins de déléguer cette tâche à la correction automatique. Il arrive que l’outil d’analyse signale un choix délibéré, comme des noms d’utilisateur publics sur un forum. C’est alors à vous de trancher : l’application vous appartient, et vous avez aussi le dernier mot sur ce qui passe en production.

Ce que le billet ne dit pas

Il s’agit d’une communication de l’éditeur, sans chiffres à l’appui. Rien sur la précision de l’outil d’analyse, le taux de faux positifs ou le nombre de problèmes correctement résolus par la correction automatique. La formule « de nombreux problèmes » signifie qu’ils ne le sont pas tous. Par ailleurs, la correction automatique repose sur un agent qui modifie le code et les politiques. Après son intervention, mieux vaut au moins relire le diff, surtout si l’application traite des paiements ou des données personnelles. Pour un produit aux enjeux importants, une analyse automatique ne remplace pas, à mon avis, un audit indépendant.

Au programme de ce mois-ci : une interface de sécurité remaniée, avec des résultats plus lisibles, et des analyses régulières planifiées sur toutes les offres payantes, sans clics supplémentaires.

Que faire concrètement

Si vous créez un produit sur Lovable :

1. Activez le blocage de la publication en présence de problèmes critiques et, pour un projet d’équipe, demandez à l’administrateur de faire de même.
2. Activez la correction automatique, mais examinez les modifications aux endroits où sont stockées les données d’autres personnes.
3. Avant le premier lancement public, lancez manuellement une analyse approfondie.
4. Réexaminez les problèmes considérés comme « intentionnels » : si les données sont publiques par choix, consignez cette décision.

Si vous utilisez un autre outil de vibe coding, la question reste la même : vérifie-t-il les politiques RLS et les secrets avant la mise en ligne, et peut-il bloquer la publication ? Si ce n’est pas le cas, vous devrez suivre cette liste de vérification manuellement.