Les permissions : le point souvent oublié des outils no-code

Un portail peut sembler parfaitement sécurisé parce que chaque client dispose d’un identifiant. Pourtant, la connexion ne répond qu’à une question : qui est cette personne ? Il reste à définir les dossiers qu’elle peut consulter, les champs qu’elle peut modifier et les documents qu’elle peut télécharger.

Dans un outil no-code, ces permissions font partie du produit. Les ajouter à la fin, après la conception des écrans, oblige souvent à reprendre le modèle de données.

Partir des opérations, pas des menus

Construisez une matrice simple avec les rôles et les actions : lire, créer, modifier, supprimer, exporter. Distinguez un client, un membre de son équipe, un collaborateur interne et un administrateur.

Précisez ensuite le périmètre : ses propres dossiers, ceux de son entreprise ou tous les dossiers. Un rôle « client » ne suffit pas si plusieurs entreprises utilisent la même application. L’appartenance à la bonne organisation doit être vérifiée pour chaque donnée concernée.

Ne pas confondre affichage et protection

Masquer un bouton ou une rubrique améliore l’expérience, mais ne prouve pas que la donnée est inaccessible. La protection doit empêcher une lecture ou une action non autorisée, même lorsque l’utilisateur tente un autre chemin que l’écran prévu.

La documentation de Bubble sur les règles de confidentialité illustre ce principe. Chaque plateforme possède ses mécanismes ; il faut vérifier leur portée réelle, notamment pour les fichiers et les interfaces de connexion à d’autres outils.

Tester avec deux clients distincts

Dans un exemple fictif, une application permet à deux entreprises de télécharger leurs devis. Créez des comptes de test séparés et des documents facilement reconnaissables. Le compte de la première entreprise ne doit retrouver aucune donnée de la seconde, même avec une recherche ou un lien direct.

Testez également un ancien collaborateur dont les accès viennent d’être retirés. La révocation doit être cohérente avec les sessions existantes et les fichiers déjà partagés. Le retrait d’un compte ne permet pas de récupérer un document précédemment téléchargé : cette limite doit être comprise.

Contrôler les comptes techniques

Une connexion entre outils utilise parfois des droits plus larges que ceux d’un utilisateur ordinaire. Une règle correcte dans l’interface peut être contournée par une automatisation mal cadrée. Les clés et les comptes techniques doivent donc être inventoriés séparément.

Évitez d’utiliser systématiquement le compte du créateur de l’application. Définissez qui peut gérer ces connexions et comment les remplacer au départ d’un prestataire. Le fonctionnement ne doit pas dépendre d’un accès personnel oublié.

Intégrer les permissions aux évolutions

Chaque nouveau champ, export ou parcours doit déclencher un test des accès. Conservez une petite liste de scénarios interdits autant que de scénarios autorisés. Une mise à jour visuelle peut introduire une nouvelle façon d’exposer des informations.

Notre comparaison entre no-code et développement sur mesure replace ces contraintes dans le choix d’outil. Un développement web utile doit protéger les données dès sa première version, pas attendre que le nombre de clients rende le problème visible.