Vous l'avez créé avec Lovable — qui est responsable en cas de fuite de données ?

Un chef de produit a besoin d'un tableau de bord interne. Plutôt que d'ouvrir un ticket et d'attendre un trimestre que l'équipe d'ingénierie s'en occupe, il ouvre Lovable, décrit ce qu'il souhaite en langage naturel, le connecte au Google Workspace de l'entreprise, et livre une application fonctionnelle le jour même. Elle lit les données de Drive, récupère quelques feuilles de calcul et envoie un résumé hebdomadaire par e-mail. Ça fonctionne. Tout le monde est content.

Personne ne pose la question qui compte six mois plus tard, quand un auditeur sécurité ou un régulateur s'en charge : qui est responsable de la manière dont cette application traite les données auxquelles elle accède ?

La réponse n'est pas la plateforme qui a généré le code. C'est l'entreprise qui l'a déployée. Cet article explique pourquoi « nous l'avons créée avec l'IA » n'est pas une défense, ce qui pose concrètement problème avec les applications créées par IA, et comment obtenir de la visibilité avant que la question ne soit posée sur un ton accusateur.

Ce que signifie réellement une « application créée par IA »

Une nouvelle catégorie d'outils — Lovable, Base44, Bolt.new, Cursor et une liste croissante d'autres — permet de créer et de déployer de véritables applications web à partir d'invites en langage naturel. On les appelle souvent des plateformes de « vibe coding ». L'attrait est évident : une personne non développeuse peut produire ce qui nécessitait auparavant une équipe, et ce en quelques heures.

Ces applications ne sont pas des jouets. Elles sont déployées auprès d'utilisateurs réels, et se connectent régulièrement à de vrais systèmes d'entreprise — Google Workspace, Salesforce, bases de données internes — via de simples autorisations OAuth. Du point de vue des données, une application créée en un après-midi avec une invite et une application développée sur des mois par une équipe d'ingénierie sont identiques : toutes deux détiennent un jeton d'accès et toutes deux peuvent lire ce que ce jeton autorise.

Cette symétrie est au cœur du problème. La rapidité qui rend les outils de création par IA attractifs est la même rapidité qui permet à une application d'accéder à des données sensibles sans que personne n'examine ce qu'elle en fait.

Créer avec l'IA n'équivaut pas à être en sécurité

Il convient d'être précis et juste ici : une application créée avec Lovable ou Base44 n'est pas intrinsèquement non sécurisée. Ces plateformes peuvent produire des applications tout à fait raisonnables, et c'est souvent le cas. Le risque n'est pas que l'IA écrive du mauvais code. Le risque relève de la gouvernance, et il se manifeste de trois manières prévisibles.

La personne qui déploie lit rarement le code. L'ensemble de la proposition de valeur du vibe coding repose sur le fait de ne pas avoir à le faire. Ainsi, la personne qui a livré l'application ne peut souvent pas vous dire comment celle-ci stocke les données, si elle enregistre des champs sensibles dans des journaux, où elle envoie les informations, ni combien de temps elle conserve quoi que ce soit. La partie responsable dispose de la moins bonne visibilité sur ce dont elle est responsable.

L'accès est étendu et invisible. Les outils de création par IA demandent les autorisations nécessaires au bon fonctionnement de la démonstration, et « faire fonctionner » implique souvent un large accès en lecture. Un tableau de bord interne qui n'avait besoin de lire qu'un seul dossier peut détenir un accès en lecture à l'ensemble de Drive. Comme l'autorisation s'est faite via un écran de consentement OAuth ordinaire, elle n'est jamais apparue sur le radar de la sécurité de personne — il s'agit, par définition, de shadow IT.

Il n'existe aucune politique documentée de traitement des données. Demandez la politique de conservation d'un système de production construit à la main et vous obtiendrez généralement une réponse. Demandez la politique de conservation d'une application qu'un collègue a générée mardi dernier, et il n'y a rien d'enregistré. Au regard du droit de la protection des données, « nous ne savons pas combien de temps elle conserve les données » n'est pas une réponse neutre — c'est un constat d'écart.

Pourquoi l'entreprise — et non la plateforme — est en première ligne

Voici ce qui surprend les gens. Lorsqu'une application créée par IA traite mal des données, la responsabilité juridique et réglementaire retombe sur l'organisation qui l'a déployée, pas sur la plateforme de création IA qui l'a générée.

C'est le même glissement de responsabilité qui redessine aujourd'hui le droit de l'IA en général. En vertu du Règlement général sur la protection des données (RGPD) de l'UE, l'entité qui détermine les finalités et les moyens du traitement des données personnelles est le responsable du traitement, et le responsable du traitement porte les obligations — base légale, minimisation des données, limitation de la conservation, et le devoir de démontrer tout cela. Lorsque votre entreprise déploie une application qui traite des données clients, votre entreprise est le responsable du traitement. La plateforme de création n'est, au mieux, qu'un outil que vous avez utilisé.

Le paysage juridique plus large de 2026 va dans le même sens. Les tribunaux ont commencé à traiter l'entreprise utilisant un système d'IA comme responsable de son comportement — le contentieux *Mobley v. Workday* aux États-Unis a été instruit sur la base d'une théorie de mandat (agency) et a ensuite obtenu la certification conditionnelle d'une action collective nationale. En Allemagne, l'OLG Hamm s'est penché sur la responsabilité concernant ce qu'un système d'IA dit aux clients, et a signalé qu'une clause de non-garantie générale ne suffit pas, à elle seule, à protéger l'entreprise déployante. L'AI Act de l'UE ajoute des obligations spécifiques aux déployeurs, avec des sanctions importantes pour les usages à haut risque. Nous traitons ce glissement en profondeur dans notre aperçu de qui est responsable en cas de fuite de données par un agent IA.

Le fil conducteur : déployer une application créée par IA est une décision que votre organisation a prise, et le droit considère que les décisions engagent une responsabilité. Le fait qu'une IA ait écrit le code ne change rien à la question de savoir qui a choisi de la connecter aux données de l'entreprise.

L'angle mort, concrètement

En assemblant les pièces, un mode de défaillance précis et courant apparaît :

• Un employé non technique crée une application avec un outil de création par IA.
• L'application se connecte à Google Workspace via OAuth et se voit accorder des autorisations étendues.
• Elle accède à des données personnelles de clients ou d'employés — contacts, contenus d'e-mails, fichiers.
• Personne n'a examiné le traitement des données, et aucune politique de conservation n'est enregistrée.
• La sécurité ne dispose d'aucune fiche d'inventaire pour l'application, car celle-ci n'a jamais fait l'objet d'une revue.

Chaque étape est raisonnable prise isolément. Ensemble, elles produisent une application qui traite des données personnelles, dont votre entreprise est légalement responsable, et dont votre équipe sécurité ignore l'existence. C'est exactement l'écart que sonde un auditeur et qu'exploite une violation de données.

Comment combler l'écart

La solution n'est pas d'interdire les outils de création par IA — cette course est déjà perdue, et le gain de productivité est bien réel. La solution, c'est la visibilité et la preuve : savoir quelles applications créées par IA sont connectées, savoir à quoi chacune peut accéder, et être en mesure de démontrer que vous les avez gouvernées.

C'est exactement ce que fait 8200.dev. La solution détecte les applications OAuth connectées à votre Google Workspace, et signale celles qui proviennent d'outils de création par IA — Lovable, Base44, Bolt.new, Cursor et similaires — à partir de leurs signatures de nom d'application et d'hôte de redirection, ainsi que du schéma révélateur d'une application non vérifiée, créée récemment, qui détient déjà des autorisations étendues. Pour chacune, vous visualisez la plateforme de création, les autorisations exactes accordées, qui les a autorisées, et un score de risque, le tout présenté dans une vue dédiée Applications créées par IA aux côtés du reste de vos agents IA et applications OAuth.

Lorsqu'une application créée par IA peut accéder à des données personnelles clients (PII), ou détient un accès étendu sans politique de conservation documentée, elle déclenche un constat spécifique — de sorte que l'écart devient une tâche avec un responsable désigné plutôt qu'une surprise lors d'un audit. Et chaque application créée par IA peut être enregistrée dans le AI Agent Registry, de sorte que même celles qu'aucun connecteur n'atteint apparaissent dans un inventaire complet unique. Vous pouvez consulter l'ensemble des fonctionnalités ici.

L'objectif n'est pas de ralentir vos équipes. C'est de vous assurer que lorsque la question arrive — de la part d'un régulateur, d'un auditeur ou d'une revue de sécurité client — vous puissiez y répondre. Pas « nous l'avons créée avec l'IA, donc c'est le problème de la plateforme », ce qui n'est pas une défense, mais « voici l'application, voici exactement ce à quoi elle peut accéder, et voici la preuve que nous l'avons examinée ». Pour un examen plus approfondi de ce qu'attendent désormais les auditeurs, consultez ce que les auditeurs exigent pour la gouvernance de l'IA en 2026.

Créer avec l'IA est rapide. Être responsable de ce que vous avez créé ne l'est pas moins pour autant. Les deux se réconcilient grâce à une seule chose : savoir à quoi vos applications créées par IA peuvent réellement accéder.

Commencez par voir ce qui est déjà connecté à votre Workspace. Vous pouvez cartographier vos applications créées par IA, noter leur niveau d'accès et générer votre première preuve dans l'offre gratuite — consultez les tarifs et démarrez gratuitement.

*Cet article constitue une information générale et ne constitue pas un conseil juridique. Consultez un conseil juridique qualifié pour des recommandations propres à votre organisation.*