# Pourquoi une application bâtie avec l’IA a-t-elle besoin de règles d’accès à sa base de données?

Date: 2026-10-28 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/regles-acces-base-de-donnees-app-ia/

**Answer:** Bien des applications bâties avec l’IA laissent la page Web parler directement à la base de données : la seule chose qui empêche un visiteur de lire chaque ligne est un ensemble de règles d’accès, comme la sécurité au niveau des lignes (Row Level Security), stockées dans la base elle-même. Si ces règles manquent ou sont trop permissives, quiconque examine le trafic de la page peut lire, et parfois modifier, toutes les données de vos utilisateurs.

Une base de données, c’est l’endroit où une application garde son information : comptes d’utilisateurs, réservations, messages, commandes. Dans une application Web traditionnelle, le navigateur ne touche jamais à la base de données. Il s’adresse à un serveur, et c’est le serveur qui décide ce que chaque personne peut voir. Bien des créateurs d’applications IA prennent un raccourci qui accélère la génération des applications : la page dans le navigateur du visiteur envoie ses requêtes directement à une base de données hébergée, avec une clé intégrée à la page, donc publique.

Ce modèle n’est pas mauvais en soi, mais il déplace toute la protection dans la base de données. La clé dans la page est censée être inoffensive; ce qui empêche un utilisateur de lire les fiches d’un autre, c’est un ensemble de règles rattachées à chaque table. Si une IA écrit les tables, mais pas les règles, ou écrit des règles qui disent « tout le monde peut lire », l’application fonctionne parfaitement pendant les tests et laisse tout fuir une fois publique.

## Ce que fait la sécurité au niveau des lignes

Supabase, un service de base de données qu’utilisent bien des créateurs d’applications, s’appuie sur une fonction de Postgres appelée *Row Level Security* (RLS, ou sécurité au niveau des lignes). Sa [documentation](https://supabase.com/docs/guides/database/postgres/row-level-security) décrit une politique comme une condition ajoutée discrètement à chaque requête sur une table, un peu comme un filtre. Deux couches travaillent ensemble : les **autorisations** (*grants*) disent si un type de visiteur peut lire, ajouter, modifier ou supprimer dans une table, et les **politiques** (*policies*) disent à quelles lignes ces actions s’appliquent.

Supabase désigne les visiteurs par des rôles. `anon` est une personne non connectée. `authenticated` est un utilisateur connecté. Un troisième rôle, `service_role`, ignore complètement les règles et ne doit jamais servir ailleurs que sur un serveur, jamais dans une page Web. La documentation est sans détour : une table exposée au Web sans RLS peut être lue et modifiée par tout rôle qui a reçu l’autorisation d’y accéder.

## Un exemple concret : une table de réservations

Imaginez que votre application de yoga stocke les réservations avec un nom, un courriel, l’heure du cours et l’identifiant de l’utilisateur qui a réservé. Une règle sûre dit que chaque utilisateur connecté ne voit que ses propres réservations :

```sql
alter table bookings enable row level security;

create policy "people see their own bookings"
on bookings for select
to authenticated
using (auth.uid() = user_id);
```

La version dangereuse, qu’un assistant pourrait écrire pour « faire disparaître l’erreur », laisse chaque visiteur lire chaque ligne :

```sql
create policy "anyone can read bookings"
on bookings for select
to anon
using (true);
```

Vous n’avez pas besoin d’écrire du SQL vous-même pour vous en servir. Vous devez demander, puis tester :

```prompt
Pour chaque table de cette application, indique-moi si la Row Level Security est activée
et décris chaque politique en français simple : à quel rôle elle s’applique, quelle action
(lire, ajouter, modifier, supprimer) et quelles lignes. Dis-moi ensuite quelles tables un
visiteur non connecté peut lire ou modifier.
```

Testez ensuite comme le ferait une personne de l’extérieur : ouvrez l’application dans une fenêtre de navigation privée sans vous connecter et essayez d’afficher les données de quelqu’un d’autre, ou connectez-vous avec un deuxième utilisateur de test et voyez si les réservations du premier apparaissent.

> **À essayer :** dans un projet de test avec des données inventées, créez deux comptes, ajoutez une réservation avec chacun et confirmez qu’aucun des deux comptes ne voit la réservation de l’autre.

## Comment des applications bâties avec ces outils ont-elles fini par divulguer les données de leurs utilisateurs?

**Des règles absentes, à grande échelle.** En mai 2025, une fiche de vulnérabilité, [CVE-2025-48757](https://www.cve.org/CVERecord?id=CVE-2025-48757), a été publiée pour les applications générées avec Lovable jusqu’au 15 avril 2025. Elle décrit des politiques de Row Level Security insuffisantes qui permettaient à des attaquants non connectés de lire ou de modifier n’importe quelle table des sites générés, et qualifie le problème de critique. La fiche note aussi que Lovable conteste cette vulnérabilité, en faisant valoir que chaque client est responsable de protéger les données de sa propre application. Les deux points méritent d’être retenus ensemble : l’outil rendait le raccourci facile, et c’est quand même le propriétaire de l’application dont les utilisateurs sont exposés.

**Une clé publique sans rien derrière.** En février 2026, des chercheurs de Wiz se sont penchés sur Moltbook, un réseau social pour agents d’IA bâti, selon son fondateur, sans écrire de code à la main. Ils ont trouvé la clé de la base de données dans le JavaScript du site, ce qui est normal dans ce modèle, mais aucune règle par ligne derrière elle, ce qui ne l’est pas. N’importe qui pouvait lire et modifier les données de production, dont, selon Wiz, environ 1,5 million de jetons d’API et environ 35 000 adresses courriel. Moltbook a sécurisé le tout quelques heures après avoir été averti.

**Les permissions de la plateforme elle-même.** Toutes les fuites ne viennent pas de vos tables. Lovable a indiqué en avril 2026 qu’une régression dans sa propre infrastructure avait permis à tout utilisateur connecté possédant le lien d’un projet de lire le code et les conversations de création des projets marqués publics, du 3 février au 20 avril 2026. Les conversations et le code contiennent souvent des noms de tables, des détails d’affaires et parfois des clés collées : un projet public dans l’éditeur peut donc révéler bien plus que le site terminé.

Le scénario est le même chaque fois : une application qui se comporte correctement pour la personne qui l’a bâtie, et personne qui vérifie ce qu’elle fait pour un inconnu. Activer la RLS, écrire une politique pour chaque table, garder la clé de service hors de la page, garder les projets privés et tester comme un visiteur non connecté comblent l’essentiel de cet écart.

## Sources

- CVE-2025-48757: https://www.cve.org/CVERecord?id=CVE-2025-48757
- Hacking Moltbook: The AI Social Network Any Human Can Control: https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
- Our response to the April 2026 incident: https://lovable.dev/blog/our-response-to-the-april-2026-incident