← Articles8 octobre 2026Lecture : 6 minutes

Vous avez créé votre logiciel avec l'IA. Qui a vérifié qu'il est protégé ?

En un après-midi, une application qui tourne. Les données qu'elle contient, elles, sont bien réelles — et souvent lisibles par qui sait où regarder.

Un associé construit le CRM du cabinet avec Lovable. Un dirigeant monte son portail client avec Bolt. Un indépendant automatise son suivi de dossiers avec Replit. En quelques heures, sans écrire une ligne de code, ils obtiennent un outil qui fonctionne vraiment.

Et c'est exactement ce qui trompe. Une application qui fonctionne n'est pas une application protégée. Ce sont deux questions différentes, et l'IA ne répond qu'à la première — parce que c'est la seule qu'on lui pose.

Ce qui casse, concrètement

Le cas le mieux documenté porte un numéro : CVE-2025-48757, gravité 9,3 sur 10. Il concerne les applications créées avec Lovable et reliées à une base Supabase. Plus de 170 applications en production ont été recensées comme exposées.

Ce qui était accessible

Profils d'utilisateurs, adresses e-mail, numéros de téléphone, historiques de transaction, coordonnées de paiement. Et, dans le code des pages elles-mêmes, des clés d'accès à des services payants — OpenAI, Stripe, Google Maps — utilisables par qui les trouvait.

La cause : les règles d'accès à la base n'avaient jamais été activées, ou l'avaient été dans une version qui autorise tout le monde à tout lire.

Le plus instructif, ce n'est pas la faille. C'est la méthode pour l'exploiter : ouvrir la page, lire son code source, y trouver l'adresse de la base et la clé publique, puis interroger la base directement. Aucune intrusion, aucun mot de passe forcé. Tout était à disposition, il suffisait de regarder.

Ce schéma se répète d'un outil à l'autre. Les points qui reviennent :

  • Les règles d'accès aux données — par défaut, chaque utilisateur peut souvent lire les données de tous les autres.
  • Les clés et mots de passe — écrits dans le code envoyé au navigateur, donc lisibles par tous les visiteurs.
  • Les fichiers déposés — factures, pièces d'identité, bilans, accessibles par leur simple adresse, sans aucun contrôle.
  • Les pages d'administration — laissées ouvertes, ou protégées seulement par le fait que personne n'en connaît l'adresse.
  • Les environnements de test — publics, et remplis de vraies données clients.
  • Les comptes — partagés entre plusieurs personnes, sans double authentification, sans moyen de savoir qui a fait quoi.

Pourquoi l'IA ne le voit pas

Elle n'a pas de raison de le voir. On lui demande une application qui marche, elle livre une application qui marche. La sécurité n'a aucun effet visible quand tout va bien : une base ouverte à tous les vents se comporte exactement comme une base correctement fermée, tant que personne ne vient regarder.

S'y ajoute un effet de confiance. Le résultat est propre, il répond vite, il a l'air professionnel. Rien dans l'expérience ne signale qu'il manque quelque chose — alors que c'est précisément ce qui manque qui pose problème.

Qui en répond ?

C'est la partie que l'on découvre en général trop tard. L'éditeur de l'outil n'est pas responsable à votre place.

Au sens du RGPD, celui qui décide de ce que l'application collecte et pourquoi est responsable de traitement. C'est vous, pas Lovable. Vos obligations ne disparaîtront pas parce que la faille vient d'un outil :

  • Article 32 — vous devez mettre en œuvre des mesures de sécurité adaptées au risque.
  • Article 33 — en cas de fuite, vous notifiez la CNIL dans les 72 heures.
  • Article 34 — si le risque pour les personnes est élevé, vous les informez individuellement.

« C'est l'IA qui l'a écrit » n'est pas un moyen de défense. Et pour un cabinet comptable, un avocat, un médecin ou toute profession tenue au secret, la question dépasse l'amende : c'est la confiance de vos clients qui se joue.

Ce que je vérifie

Périmètre : revue de configuration et d'exposition

Je regarde ce que votre application laisse voir et comment elle est paramétrée. C'est là que se trouve la grande majorité des problèmes de ces applications — non pas dans la subtilité du code, mais dans des portes laissées ouvertes.

  • Les règles d'accès à vos données, table par table
  • Les clés, jetons et mots de passe visibles depuis le navigateur
  • Les fichiers déposés et leur accessibilité
  • Les pages d'administration et les environnements de test
  • Les comptes, l'authentification et la double authentification
  • Ce qui est enregistré, où, et pendant combien de temps
  • Les sauvegardes : existent-elles, ont-elles été testées
  • La conformité RGPD de ce que l'application collecte réellement

Ce que vous recevez

Un rapport lisible, sans jargon. Chaque point classé par gravité, avec la correction à apporter et la personne à qui elle revient — vous, votre prestataire, ou l'éditeur de l'outil.

Ce que ce n'est pas

  • Pas un test d'intrusion. Je ne cherche pas à forcer votre application, et je n'en ai pas besoin pour constater ce qui est ouvert.
  • Pas un audit de code ligne à ligne.
  • Ni certification, ni label, ni garantie de sécurité. Un constat à une date donnée, et un plan d'action.

Par où commencer

Si votre application contient des données de clients, trois vérifications valent d'être faites dès ce soir, sans aucune compétence technique :

  • Ouvrez votre application en navigation privée, sans vous connecter. Qu'est-ce qui s'affiche ?
  • Créez un deuxième compte de test. Voit-il les données du premier ?
  • Copiez l'adresse d'un fichier que vous avez déposé, puis ouvrez-la en navigation privée. S'affiche-t-il ?

Si l'une des trois réponses vous inquiète, il y a de quoi creuser.

Faire vérifier mon application Auto-diagnostic en 3 minutes

Premier échange de 30 minutes offert, sans engagement. Je vous dis d'emblée si votre situation ne justifie pas de prestation.

Sources