Application codée avec l'IA : la check-list sécurité avant d'ouvrir aux clients

Avant d'ouvrir à des clients une application codée avec l'IA (Lovable, Bolt, Base44, Cursor ou un autre outil), vérifiez quatre choses avant toutes les autres : qu'un utilisateur ne voit jamais les données d'un autre, qu'aucune clé secrète n'est visible dans le navigateur, que les pages privées refusent un visiteur non connecté, et qu'une sauvegarde se restaure. Les trois premières relèvent du risque numéro un de l'OWASP Top 10 2025, le contrôle d'accès défaillant.

Les check-lists publiées sur ce sujet s'adressent surtout aux développeurs. Celle-ci est écrite pour le fondateur : elle sépare ce que vous pouvez vérifier vous-même, en une après-midi, de ce qui exige quelqu'un qui lit le code.

Pourquoi une application générée a des failles particulières

L'IA écrit un code qui fonctionne : les écrans s'affichent, les boutons répondent. La sécurité, elle, porte sur ce qui se passe quand quelqu'un utilise l'application d'une manière que vous n'aviez pas prévue. Un générateur optimise le premier point, pas le second.

Trois schémas reviennent souvent :

• Des contrôles faits à l'écran seulement. Le bouton « Supprimer » est caché aux non-administrateurs, mais la base accepte la suppression si on l'appelle directement.
• Des règles d'accès absentes dans la base. La documentation de Supabase, base utilisée par plusieurs de ces outils, prévient qu'une table exposée sans sécurité au niveau des lignes (RLS) est lisible et modifiable par tout rôle qui y a accès. C'est le mécanisme en cause dans la vulnérabilité CVE-2025-48757, publiée en mai 2025 à propos d'applications générées par Lovable, que l'éditeur conteste.
• Des secrets au mauvais endroit. Une clé d'API collée dans une conversation peut finir dans le code envoyé au navigateur, où n'importe qui peut la lire.

Les éditeurs ne le cachent pas. La documentation sécurité de Lovable indique que l'éditeur de l'application est responsable de la sécurité adaptée à son usage, et que ses outils d'analyse ne garantissent pas une sécurité complète.

Ce que vous pouvez vérifier vous-même

Aucune de ces vérifications ne demande de lire du code. Prévoyez une après-midi et un tableau où noter chaque résultat.

1. Le test des deux comptes

Créez deux comptes clients, A et B, avec chacun quelques données (une commande, un dossier, un message). Connecté en A :

• repérez dans la barre d'adresse un identifiant (un numéro, une suite de lettres) et remplacez-le par celui d'un objet de B ;
• essayez d'ouvrir, de modifier, puis de supprimer cet objet.

Si une seule de ces actions réussit, ne lancez pas. C'est le défaut le plus fréquent, et le plus grave.

2. La visite sans compte

Ouvrez une fenêtre de navigation privée, sans vous connecter, et collez l'adresse d'une page privée (tableau de bord, administration, facture). Vous devez être renvoyé vers la connexion, sans voir de contenu, même une seconde.

3. Les rôles

Si l'application a des administrateurs, connectez-vous avec un compte ordinaire et tentez d'ouvrir les adresses des pages d'administration. Cacher un lien ne suffit pas : l'adresse elle-même doit être refusée.

4. Le dépôt de code

Si le code est synchronisé sur GitHub, vérifiez que le dépôt est privé. Pour un dépôt public, GitHub analyse gratuitement l'historique à la recherche de clés exposées : si une alerte apparaît, la clé doit être changée chez le fournisseur concerné, pas seulement effacée du code, car elle reste dans l'historique.

5. Les comptes d'administration

Activez la double authentification partout où l'application a ses clés : l'outil de génération, GitHub, la base de données, le prestataire de paiement, le nom de domaine, la messagerie. Un attaquant qui prend l'un de ces comptes n'a pas besoin de faille dans le code.

6. La restauration

Demandez où sont les sauvegardes, puis faites restaurer une copie sur un environnement de test. Une sauvegarde jamais restaurée n'est qu'une hypothèse.

7. Les obligations visibles

Mentions légales, politique de confidentialité, information sur les cookies : si vous traitez des données personnelles de clients, le RGPD s'applique quel que soit l'outil. Notre check-list RGPD d'une application métier détaille ce que la conception doit prévoir.

Ce qui exige un développeur

Les points suivants demandent de lire le code ou la configuration. Ils suivent l'ordre de l'OWASP Top 10 2025.

Deux points méritent une attention particulière sur une application générée :

• Le paiement. La confirmation qu'un client a payé doit venir du prestataire de paiement, vérifiée côté serveur, jamais de la page que le client voit. Sinon, un abonnement peut s'activer sans paiement.
• Les fonctions serveur écrites par l'IA. Elles tournent souvent avec des droits élevés. Chacune doit vérifier qui l'appelle avant d'agir.

Pour aller plus loin, le standard OWASP ASVS (version 5.0.0, publiée le 30 mai 2025) liste les exigences vérifiables une à une. En France, le guide de la sécurité des données personnelles de la CNIL (édition 2024) sert de référence à la CNIL pour apprécier les mesures de sécurité, et l'ANSSI publie des recommandations pour maîtriser les standards de sécurité côté navigateur.

Trois cas qui demandent plus de prudence

Certaines applications sortent du cadre de cette check-list, parce que l'erreur y coûte plus cher ou parce que le risque prend une autre forme.

• Une fonction d'IA dans l'application. Si vos clients dialoguent avec un assistant, ou si l'application résume des documents qu'ils déposent, un texte malveillant peut détourner le modèle de ses consignes. C'est le premier risque du Top 10 de l'OWASP pour les applications à base de grands modèles de langage (édition 2025), l'injection de prompt, suivi de la divulgation d'informations sensibles. Règle simple : l'assistant ne doit jamais avoir plus de droits que l'utilisateur qui lui parle.
• Des fichiers déposés par les utilisateurs. Pièces jointes, photos, justificatifs : chaque fichier doit être rangé de façon à n'être lisible que par son propriétaire, et son type vérifié côté serveur.
• Des données sensibles. Santé, données bancaires, informations sur des mineurs : la réglementation ajoute ses propres exigences, et une relecture par un professionnel de la sécurité, avant l'ouverture, n'est plus une option. Un conseil juridique spécialisé est alors utile.

Dans ces trois cas, la check-list reste le point de départ, mais elle ne suffit pas.

Les outils d'analyse automatique, utiles mais pas suffisants

Lovable propose une analyse rapide, lancée automatiquement à la publication, et une analyse approfondie du code, d'après sa documentation. D'autres plateformes ont leurs propres contrôles, et des outils indépendants analysent les dépendances. Lancez-les : ils trouvent vite les erreurs évidentes.

Ils ne savent pas, en revanche, ce que votre métier autorise. Un outil ne peut pas deviner qu'un gestionnaire ne doit voir que les dossiers de son agence, ou qu'une facture validée ne se modifie plus. Ces règles-là se testent avec des comptes réels et des scénarios écrits par quelqu'un qui connaît le besoin.

L'ordre de marche avant d'ouvrir

1. Passez les sept vérifications de la première partie, et notez chaque résultat.
2. Corrigez les accès d'abord. Un test des deux comptes en échec bloque le lancement, le reste peut se planifier.
3. Faites relire le code sur les points de la seconde partie, au moins les droits d'accès, les secrets et le paiement. Notre article sur la sécurité d'une application métier donne les questions à poser à la personne qui s'en charge.
4. Séparez test et production avant toute nouvelle modification par conversation.
5. Ouvrez progressivement, à quelques clients de confiance d'abord.

Si la relecture montre que certains modules doivent être consolidés ou réécrits, notre guide pour mettre en production une application Lovable, Bolt ou Base44 propose une grille module par module. Et si vous hésitez encore sur l'outil, le comparatif Lovable, Bolt et Base44 met en regard leurs back-ends et leurs options d'export.

Comment nous travaillons

LPR Studio écrit aussi du code avec l'IA. Chaque modification passe par des tests automatisés, une relecture et une validation humaine avant la production, une méthode décrite dans développement assisté par IA : pourquoi la vérification humaine fait la différence. Si vous avez une application générée à ouvrir à des clients, apportez-la : nous vous présentons en visio, sous 5 jours ouvrés, un prototype gratuit de la version consolidée, avec les points de cette check-list qui restent à traiter.