Une base de données range ses informations dans des tableaux, un peu comme un tableur : chaque ligne correspond à un élément, une demande de congé, un devis, un client. La RLS, pour « Row Level Security », ajoute à ces tableaux des règles qui disent qui peut voir ou modifier chaque ligne. Par exemple, un salarié ne voit que ses propres demandes, et sa responsable voit celles de toute son équipe.
Sa force : la règle est appliquée par la base de données elle-même. Masquer un bouton ou une colonne à l’écran ne protège rien, car une personne un peu technique peut interroger les données sans passer par l’écran. Avec une règle RLS, la base ne livre que les lignes autorisées, quel que soit le chemin de la demande.
On la croise surtout avec PostgreSQL, un système de base de données très répandu, et avec Supabase, qui repose sur lui et que beaucoup d’outils de création d’applications par l’IA utilisent. Dans ce cas, le navigateur dialogue directement avec la base de données : sans règles RLS bien écrites, les informations deviennent lisibles par quiconque sait où regarder.
Le piège : croire que l’outil est protégé parce que tout s’affiche correctement. Un oubli de RLS passe inaperçu à l’usage. Avant de partager un outil, demandez à l’IA de vérifier que chaque tableau a ses règles, et de prouver par un test qu’un compte sans droits ne peut ni lire ni modifier les lignes des autres.
Exemple
Dans l’outil des demandes de formation, Salomé, responsable formation, veut que chaque salarié ne voie que ses propres demandes : une règle RLS l’impose dans la base de données elle-même.
Avec Toolify
Sur Toolify, le serveur revérifie les droits à chaque demande faite à un outil, et pas seulement à l’affichage.