Row level security :expliquée aux fondateurs non techniques

Row level security : le RLS est une fonction de base de données qui filtre automatiquement chaque requête pour que chaque client ne voie jamais que ses propres données — même si votre code applicatif contient des bugs. Vous définissez la règle une fois, dans la base de données, et elle ne peut pas être contournée. C'est, honnêtement, la raison pour laquelle je dors bien la nuit.

Si vous construisez un SaaS avec l'IA sans être technique, le RLS est le seul concept de sécurité qui mérite vraiment d'être compris. Voici ce que c'est, pourquoi il bat toutes les alternatives, et la checklist à donner à votre IA.

Row level security expliquée : l'analogie du videur

Imaginez que votre base de données soit une salle d'archives et que les dossiers de chaque client soient des chemises rangées à l'intérieur. Sans RLS, la porte de la salle est ouverte, et vous comptez sur chaque employé — chaque morceau de votre code applicatif — pour penser, à chaque fois, à ne sortir que les chemises du bon client. Un seul moment d'inattention, et quelqu'un repart avec les dossiers d'un concurrent.

Le RLS place un videur dans la salle d'archives elle-même. Le videur vérifie l'identité de celui qui demande et ne remet physiquement que les chemises appartenant à son organisation. Peu importe que l'employé oublie de demander correctement, ou demande tout : le videur filtre ce qui revient. Chaque requête. Automatiquement. Sans exception.

Techniquement : au lieu que votre application filtre les données (« n'affiche que les lignes de ce client »), vous définissez cette règle une fois, dans la base de données, sous forme de politique. Dès lors, chaque requête est filtrée avant qu'une donnée ne quitte la base. C'est intégré à PostgreSQL, et des plateformes comme Supabase en font une fonction de premier plan.

Pourquoi filtrer dans le code de votre app ne suffit pas

Voici la vérité inconfortable sur l'alternative. Sans RLS, l'isolation des données dépend d'un humain — ou d'une IA — qui doit penser à ajouter « uniquement pour ce client » à chaque endroit où votre produit touche aux données. Des centaines d'endroits. Pour toujours. Chaque nouvelle fonctionnalité, chaque correctif rapide, chaque modification de fin de soirée.

Les humains oublient. L'IA oublie aussi — demandez-lui une fonctionnalité de rapports un mardi fatigué et elle interrogera joyeusement tout. Un exemple réel venu du terrain : un développeur a oublié de filtrer par organisation dans un endpoint de rapports. Sans RLS, il aurait divulgué les données de clients à des concurrents. Avec le RLS, la base de données a bloqué l'accès non autorisé automatiquement. Personne ne l'a remarqué avant la revue de code — parce qu'il ne s'est rien passé de grave.

Les spécialistes de la sécurité appellent cela la défense en profondeur : ne pas compter sur une seule couche parfaite. Votre code applicatif filtre les données (première couche), et le RLS l'impose au niveau de la base (seconde couche). Si la première couche échoue — un bug, un mauvais prompt, une hallucination de l'IA — la seconde tient. Cela compte doublement quand l'IA écrit l'essentiel de votre code, car le code généré par l'IA échoue de façons que vous ne verrez pas avant que ce soit coûteux.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Les quatre permissions dont chaque table a besoin

Les politiques RLS existent en quatre variantes, une pour chaque chose qu'un utilisateur peut faire avec des données. Voyez-les comme quatre questions que pose le videur :

Chaque table qui contient des données clients reçoit les quatre. C'est tout le système : l'étiquette organization_id sur chaque table dit à qui appartient chaque ligne ; les quatre politiques font appliquer cette règle par la base de données.

Comment j'ai appris le RLS (auprès de Claude)

Je vais être honnête — je n'ai pas appris le RLS dans un cours de sécurité. Je l'ai appris auprès de Claude. Quand j'ai commencé avec Supabase, j'ai demandé : « Comment m'assurer que les utilisateurs ne voient que les données de leur propre organisation ? » Claude m'a expliqué les politiques RLS. Je les ai mises en place sur chaque table. Maintenant, c'est automatique.

C'est le point essentiel pour les fondateurs non techniques : vous n'écrivez pas ces politiques à la main. Vous comprenez le concept — un videur dans la salle d'archives, quatre permissions par table — et vous donnez l'instruction à votre IA : « Active la row level security sur chaque table, avec des politiques pour voir, créer, modifier et supprimer, limitées à l'organisation de l'utilisateur. » L'IA produit les politiques ; la base de données les applique pour toujours.

Ma plateforme, FIKR Space, compte 964 tables. Toutes sont protégées de cette façon. Sans exception. Cette échelle n'est gérable que parce que la règle est appliquée par la base de données, pas par ma mémoire — la raison même pour laquelle je prône de concevoir la base de données avant d'écrire la moindre fonctionnalité.

La checklist RLS du fondateur

Vous n'avez pas besoin d'écrire une ligne de SQL. Vous devez exiger cinq choses :

1. RLS activé sur chaque table de données clients. Demandez directement à votre IA : « La row level security est-elle activée sur toutes les tables ? Liste celles où elle ne l'est pas. »
2. Les quatre types de politique par table — voir, créer, modifier, supprimer. Une table avec seulement une politique de lecture fuit quand même par les écritures.
3. Des politiques limitées par organisation, en accord avec votre configuration multi-tenant.
4. Testez avec deux comptes. Créez deux organisations de test. Connectez-vous avec l'une, essayez de lire et de modifier les données de l'autre. Si quoi que ce soit revient, arrêtez-vous et corrigez avant de livrer.
5. Revérifiez après chaque nouvelle table. Faites de « activer le RLS avec les quatre politiques standard » une règle permanente que votre IA applique à chaque table qu'elle crée — pas quelque chose dont vous devez vous souvenir à chaque fonctionnalité.

Le bonus, c'est un code applicatif plus simple : une fois que la base de données impose l'isolation, vos fonctionnalités n'ont plus besoin de logique de filtrage par client disséminée partout. Sécurité par défaut, moins de code, et vous cessez de vous inquiéter de la requête que quelqu'un a oubliée.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Questions fréquentes

Qu'est-ce que la row level security en termes simples ?

C'est une règle que vous définissez une fois dans la base de données et qui filtre automatiquement chaque requête, de sorte que chaque utilisateur ne voit jamais que les lignes de son organisation. Comme un videur dans la salle d'archives : quel que soit celui qui demande et comment, seules les bonnes chemises sortent.

Ai-je besoin du RLS si mon application filtre déjà les données ?

Oui. Le filtrage applicatif dépend du fait que chaque morceau de code — écrit par un humain ou par une IA — pense au filtre, pour toujours. Le RLS est le filet de sécurité quand quelque chose oublie : un bug dans votre app ne peut plus devenir une fuite de données, car la base de données bloque elle-même la fuite.

Puis-je mettre en place le RLS sans connaître le SQL ?

Oui. Comprenez le concept, puis donnez l'instruction à votre IA : « Active la row level security sur chaque table, avec des politiques pour voir, créer, modifier et supprimer, limitées à l'organisation de l'utilisateur. » Vérifiez ensuite avec deux comptes de test qui essaient de lire les données l'un de l'autre. L'IA écrit les politiques ; vous êtes propriétaire de la checklist.

Le RLS ralentit-il mon produit ?

Pas de façon notable, si vos tables sont bien configurées — l'essentiel est d'avoir un index sur la colonne d'organisation que contrôlent les politiques (à inclure dans les instructions permanentes de votre IA). Des plateformes avec des milliers de tables protégées tournent exactement sur ce modèle ; FIKR Space en fait tourner 964.