Vous avez décrit votre application à un agent AI, regardé l’interface s’afficher en quelques secondes et vous êtes connecté avec succès à votre nouveau tableau de bord. On a l’impression d’une victoire éclatante. Vous invitez vos dix premiers clients, et tout semble propre. Mais derrière les superbes composants React et les animations fluides de Tailwind, un désastre silencieux pourrait être en train de se préparer.
Construire un portail client est fondamentalement différent de la création d’un annuaire public ou d’une simple application web. Dans un portail client, l’isolation des données est la seule fonctionnalité qui compte vraiment. Si un client peut accéder à ses factures, il ne devrait jamais pouvoir voir celles d’un autre client.
Beaucoup de créateurs utilisent des générateurs de code AI pour monter ces portails, comptant sur l’AI pour configurer des backends comme Supabase. Mais s’appuyer sur l’AI pour écrire des politiques de Row-Level Security (RLS) est un raccourci qui mène souvent à des fuites de données.
Voici pourquoi la sécurité de base de données générée par AI est fragile, et comment les schémas de permissions visuels offrent une voie plus fiable pour les portails clients.
L’illusion de la sécurité frontend
Quand vous construisez avec des assistants AI, ils ont tendance à écrire du code qui privilégie le retour visuel. L’AI masque un bouton si l’utilisateur n’est pas administrateur, ou masque une liste d’enregistrements si l’e-mail de l’utilisateur ne correspond pas à l’enregistrement.
C’est ce qu’on appelle la sécurité frontend, et c’est totalement inutile si elle est seule.
N’importe qui avec un navigateur peut ouvrir les outils de développement, cliquer sur l’onglet réseau et inspecter les charges utiles JSON entrantes. Si votre application récupère tous les dossiers clients depuis la base de données et les filtre côté frontend avec React ou Vue, vos données sont déjà compromises. Un attaquant n’a pas besoin de pirater votre serveur. Il lui suffit d’appuyer sur F12 pour voir les données brutes que votre code frontend tentait de masquer.
Pour créer un portail sécurisé, vous devez filtrer les données au niveau de la base de données avant même qu’elles ne transitent sur le réseau. Si un client demande une liste de projets, le moteur de la base de données doit inspecter la session, vérifier l’identité et ne renvoyer que les lignes correspondantes.
Pour les projets créés sur Supabase, cette sécurité de la base de données repose entièrement sur la Row-Level Security (RLS) de PostgreSQL.
Les vulnérabilités du RLS Supabase généré par IA
Supabase est un excellent choix de backend pour les applications personnalisées, mais il déplace la responsabilité de la sécurité vers la configuration de la base de données. La mise en place du RLS nécessite l’écriture de politiques PostgreSQL précises en SQL.
Lorsque vous demandez à un constructeur IA de s’en charger, vous introduisez plusieurs points de défaillance.
1. Dérive de la fenêtre de contexte et complexité des relations
Une politique RLS simple est facile à écrire. Si un utilisateur possède une ligne, il peut la lire. Vous écrivez une règle vérifiant si auth.uid() = user_id.
Mais les portails clients sont rarement aussi simples. On y trouve généralement des organisations, des équipes, des prestataires externes et différents rôles. Un projet peut appartenir à une organisation, et un utilisateur est membre de cette organisation avec un rôle spécifique. Pour vérifier si un utilisateur peut lire un enregistrement de projet, la base de données doit interroger une table de liaison.
À mesure que le schéma de votre base de données s’étoffe, l’IA doit suivre toutes ces relations. Dès que vous demandez une nouvelle fonctionnalité à l’IA, une dérive de la fenêtre de contexte peut se produire. L’IA peut écrire une nouvelle requête qui contourne la logique RLS existante ou simplifier la politique pour que le code fonctionne, ouvrant ainsi l’accès à des utilisateurs non autorisés.
2. Échecs silencieux de la logique SQL
Les politiques PostgreSQL échouent silencieusement. Si vous écrivez une politique buggy, PostgreSQL ne fait pas planter votre application. Soit il bloque tout accès, soit, s’il est mal configuré, il permet à tout le monde de lire les données.
Les modèles d’IA font souvent des erreurs subtiles avec les valeurs nulles SQL ou la logique booléenne. Par exemple, une politique comme celle-ci :
create policy "Users can view company data" on companies
for select using (
auth.uid() in (select user_id from members where company_id = id)
or public_access = true
);Si le moteur de la base de données évalue public_access comme nul, ou si la sous-requête renvoie nul de manière inattendue, la politique pourrait être évaluée comme vraie pour tous les utilisateurs authentifiés. Une IA pourrait générer ce code parce qu’il semble syntaxiquement correct, mais il manque la gestion des cas particuliers requise pour des environnements de production réels.
3. Le manque de tests
Les développeurs professionnels ne se contentent pas d’écrire des politiques RLS ; ils écrivent des suites de tests pour les vérifier. Ils utilisent des outils comme pgTAP pour simuler différentes sessions utilisateur et confirmer qu’un client ne peut pas interroger les données d’un autre client.
Les générateurs de code IA n’écrivent pas ces tests, sauf si vous le demandez explicitement, et même dans ce cas, exécuter des tests de sécurité au niveau de la base de données dans un environnement généré par IA est complexe. Sans suites de tests automatisées, vous jouez aux devinettes pour savoir si vos politiques sont sécurisées. Vous ne découvrez qu’elles sont défectueuses quand un client vous appelle pour demander pourquoi il voit le tableau de bord d’une autre entreprise.
Schémas de permissions visuels : l’alternative no-code
Si vous ne voulez pas auditer du code PostgreSQL ou gérer des suites de tests, vous avez besoin d’un autre paradigme de sécurité. Les schémas de permissions visuels, comme ceux utilisés dans Softr, remplacent le code personnalisé de la base de données par des règles structurées et appliquées par la plateforme.
Au lieu d’écrire des instructions SQL pour filtrer les lignes, vous configurez vos règles d’accès via un panneau de paramètres visuels.
Mappage visuel vs scripting SQL
Alors que les configurations traditionnelles nécessitent d’écrire des politiques de base de données personnalisées, les constructeurs modernes s’appuient sur des paramètres visuels. Dans Softr, vous définissez des groupes d’utilisateurs basés sur les attributs de la base de données. Par exemple, vous pouvez créer un groupe appelé “Utilisateurs Portail Client” où l’ID de l’entreprise correspond à l’ID de l’entreprise de l’utilisateur connecté.
Une fois définis, vous appliquez ces groupes directement aux pages, aux blocs et aux actions. La plateforme gère automatiquement le routage backend et les requêtes de base de données. Le bloc frontend ne reçoit pas l’ensemble du jeu de données ; le serveur filtre la source de données avant de rendre le bloc.
Bases de données nativement sécurisées
Lorsque vous utilisez Softr Databases comme couche de données native, la sécurité au niveau des lignes est intégrée à la connexion dès le départ. Vous n’écrivez pas de règles de sécurité directement sur les tables de la base de données - il n’y a pas de SQL généré à auditer, pas de scripts de migration à exécuter et pas de politiques à maintenir. La couche d’intégration restreint l’accès aux requêtes par défaut, il n’y a donc aucun code généré susceptible de dériver, de casser ou d’exposer accidentellement des enregistrements après un changement de schéma.
Si un groupe d’utilisateurs n’est autorisé à lire que les enregistrements dont le statut est “Actif” et dont le champ client correspond à son compte, le moteur de l’interface applique ce filtre au niveau de la requête. Le client ne peut pas manipuler la requête API pour récupérer des enregistrements inactifs ou des lignes d’autres clients, car le serveur backend ignore les paramètres non autorisés.
Softr se connecte également à plus de 17 sources externes - dont Airtable et Google Sheets - si vous devez importer des données que vous gérez déjà ailleurs. Les mêmes règles visuelles de groupe d’utilisateurs s’appliquent, quel que soit l’endroit où se trouvent les données.
Le fardeau de la maintenance du code généré
Construire un portail client n’est pas un événement unique. Vos règles métier évolueront. Vous ajouterez de nouveaux niveaux de clients, introduirez des structures de projets imbriquées ou changerez la façon dont les administrateurs examinent les documents soumis.
Dans une application à code généré construite avec des outils comme Bolt ou Lovable, chaque modification de mise en page ou mise à jour de relation nécessite de refondre le schéma de la base de données et de réécrire vos politiques de sécurité. Vous dépendez de l’IA pour :
- Lire l’intégralité du code pour comprendre le schéma existant.
- Générer un script de migration sans corrompre les données existantes.
- Réécrire les règles RLS pour s’adapter aux nouvelles relations.
- Mettre à jour le frontend React pour transmettre les bons headers et tokens.
C’est le problème du “Jour 2”. Un seul prompt peut briser une politique de sécurité qui fonctionnait auparavant, et vous pourriez ne pas le remarquer avant que le code ne soit déjà déployé en production.
Avec Softr, vous effectuez ces changements sans toucher au code. Vous pouvez utiliser l’AI Co-Builder pour décrire le changement souhaité - “ajouter un groupe d’utilisateurs Manager pouvant approuver les soumissions de projets” - et il met à jour les groupes d’utilisateurs, les pages et les permissions simultanément. Ou vous pouvez faire la modification manuellement dans le panneau de paramètres si vous préférez. Dans les deux cas, il n’y a pas de SQL généré à auditer après coup, et aucun risque qu’une régression de la politique de sécurité ne soit déployée silencieusement en production.
Bonnes pratiques de sécurité pour votre portail client
Si vous construisez un portail qui manipule des données métier sensibles, gardez ces directives à l’esprit :
Arrêtez de compter sur les filtres frontend
Ne supposez jamais que les données sont en sécurité parce qu’elles sont masquées dans l’interface utilisateur. Vérifiez toujours que votre API backend ou votre source de données filtre les données avant l’envoi. Si votre plateforme ne supporte pas le filtrage backend sécurisé, ne l’utilisez pas pour des portails clients.
Gardez des rôles utilisateurs simples
Évitez les hiérarchies de permissions trop complexes. Si vos permissions sont trop compliquées pour être auditées facilement par un humain, une IA aura du mal à les écrire correctement. Tenez-vous-en à des groupes d’utilisateurs clairs et distincts comme Administrateurs, Managers et Clients.
Choisissez des outils structurés pour vos logiciels opérationnels
Les générateurs de code IA sont formidables pour la validation, le prototypage et la création d’interfaces SaaS grand public. Mais lorsque vos exigences principales sont la sécurité opérationnelle, l’isolation des données et la stabilité à long terme, une plateforme no-code structurée est le choix le plus sûr.
En utilisant une plateforme qui isole les configurations de sécurité du code de mise en page, vous vous assurez que les mises à jour de style n’exposeront jamais accidentellement votre base de données sur l’internet public. Vous obtenez un portail sécurisé et professionnel reposant sur une base prévisible, vous permettant de vous concentrer sur vos clients plutôt que de débugger des politiques de base de données.