Menus de navigation sensibles aux permissions et qui font respecter les autorisations

Quel problème les menus sensibles aux permissions résolvent-ils vraiment ?

Quand les gens disent « masquer le bouton », ils veulent généralement dire l'une des deux choses : réduire l'encombrement pour les utilisateurs qui ne peuvent pas utiliser une fonctionnalité, ou empêcher les usages abusifs. Seul le premier objectif est réaliste côté frontend.

Les menus sensibles aux permissions sont principalement un outil UX. Ils aident quelqu'un à ouvrir l'application et à voir immédiatement ce qu'il peut faire, sans tomber sur des écrans « Accès refusé » à chaque autre clic. Ils réduisent aussi la charge du support en évitant des confusions du type « Où approuve-t-on les factures ? » ou « Pourquoi cette page plante ? »

Masquer l'interface n'est pas de la sécurité. C'est de la clarté.

Même un collègue curieux peut toujours :

• Taper un deep link vers une page cachée s'il connaît l'URL
• Ouvrir un ancien favori vers un écran admin
• Appeler votre API directement avec un script ou un outil
• Modifier des requêtes depuis le navigateur et tester différents identifiants

Donc le vrai problème que résolvent les menus sensibles aux permissions est une guidance honnête. Ils gardent l'interface alignée avec le travail, le rôle et le contexte de l'utilisateur, tout en rendant évident ce qui n'est pas disponible.

Un bon état final ressemble à ceci :

• Les utilisateurs voient surtout des actions qui ont du sens pour eux, et rencontrent rarement des erreurs surprises.
• Les développeurs ont une source unique de vérité pour les règles d'accès, au lieu de vérifications éparpillées.
• Les changements produit sont plus sûrs car un nouvel élément de menu vous force à décider quelle permission il exige.
• La sécurité est appliquée là où ça compte : le backend rejette les actions interdites à chaque fois, même si l'UI les affiche par erreur.

Exemple : dans un petit CRM, un Commercial doit voir Leads et Tâches, mais pas la Gestion des utilisateurs. S'il colle quand même l'URL de gestion des utilisateurs, la page doit échouer en mode fermé, et le serveur doit toujours bloquer toute tentative de lister les utilisateurs ou de changer des rôles.

Visibilité n'est pas autorisation

La visibilité est ce que l'interface choisit d'afficher. L'autorisation est ce que le système permettra réellement lorsqu'une requête atteint le serveur.

Les menus sensibles aux permissions réduisent la confusion. Si quelqu'un ne sera jamais autorisé à voir Facturation ou Admin, masquer ces éléments garde l'app propre et diminue les tickets de support. Mais masquer un bouton n'est pas un cadenas. Les gens peuvent toujours essayer l'endpoint sous-jacent avec les outils dev, un ancien favori, ou une requête copiée.

Règle pratique : décidez de l'expérience que vous voulez, puis faites appliquer la règle côté backend quoi qu'il arrive.

Quand vous décidez comment présenter une action, trois patterns couvrent la plupart des cas :

• Masquer quand la fonctionnalité doit être indétectable pour la plupart des rôles (par exemple, outils internes seulement).
• Désactiver quand la fonctionnalité existe mais que l'utilisateur ne peut pas l'utiliser pour le moment (par exemple, Export désactivé tant qu'une mise à niveau de plan n'est pas faite, tant qu'un enregistrement n'est pas sélectionné, ou pendant le chargement des données).
• Afficher avec une explication quand les utilisateurs doivent comprendre pourquoi ils ne peuvent pas continuer (« Vous pouvez voir les factures, mais seuls les Owners peuvent modifier les moyens de paiement »).

« Vous pouvez voir mais pas modifier » est courant et mérite d'être conçu explicitement. Traitez-le comme deux permissions : une pour lire les données et une pour les modifier. Dans le menu, vous pouvez afficher Détails client pour tous ceux qui peuvent lire, mais n'afficher Modifier le client qu'à ceux qui ont l'accès en écriture. Sur la page, rendez les champs en lecture seule et protégez les contrôles d'édition, tout en laissant la page se charger.

Surtout, le backend décide de l'issue finale. Même si l'UI cache chaque action admin, le serveur doit quand même vérifier les permissions sur chaque requête sensible et renvoyer une réponse claire « non autorisé » quand quelqu'un essaie.

Choisissez un modèle de permissions que vous pouvez maintenir

Le moyen le plus rapide de livrer des menus sensibles aux permissions est de commencer par un modèle que votre équipe peut expliquer en une phrase. Si vous ne pouvez pas l'expliquer, vous ne le garderez pas correct.

Utilisez les rôles pour regrouper, pas pour signifier. Admin et Support sont des bacs utiles. Mais quand les rôles se multiplient (Admin-West-Coast-ReadOnly), l'UI devient un labyrinthe et le backend devient du guessing.

Privilégiez les permissions comme source de vérité pour ce que quelqu'un peut faire. Gardez-les petites et basées sur l'action, comme invoice.create ou customer.export. Cela scale mieux que la prolifération de rôles parce que les nouvelles fonctionnalités ajoutent généralement de nouvelles actions, pas de nouveaux intitulés de poste.

Ajoutez ensuite des policies (règles) pour le contexte. C'est là que vous gérez « peut éditer seulement son propre enregistrement » ou « peut approuver des factures uniquement sous 5 000 $ ». Les policies évitent de créer des dizaines de permissions presque identiques qui ne diffèrent que par une condition.

Une couche maintenable ressemble à ceci :

• Les rôles regroupent les permissions (fonction de poste)
• Les permissions décrivent les actions (quoi)
• Les policies ajoutent du contexte (quand, quels enregistrements)

Le nommage compte plus qu'on ne le croit. Si votre UI dit Exporter les clients mais que l'API utilise download_all_clients_v2, vous finirez par masquer la mauvaise chose ou bloquer la bonne. Gardez les noms humains, cohérents et partagés entre frontend et backend :

• Utilisez nom. verbe (ou ressource.action) de façon cohérente
• Faites correspondre les libellés UI à l'intention de la permission, pas aux noms internes de code
• Maintenez la compatibilité des anciens noms de permission lors du renommage de fonctionnalités

Exemple : dans un CRM, un rôle Sales peut inclure lead.create et lead.update, mais une policy limite les mises à jour aux leads dont l'utilisateur est propriétaire. Cela garde votre menu clair tandis que votre backend reste strict.

Étape par étape : implémenter rôles et permissions de bout en bout

Les menus sensibles aux permissions font bonne impression parce qu'ils réduisent l'encombrement et évitent les clics accidentels. Mais ils n'aident que si le backend reste aux commandes. Pensez l'UI comme un indice, et le serveur comme le juge.

Commencez par écrire ce que vous protégez. Pas des pages, mais des actions. Voir la liste de clients est différent d'exporter les clients ou de supprimer un client. C'est l'épine dorsale des menus sensibles aux permissions qui ne tournent pas au théâtre de sécurité.

Une recette pratique de bout en bout

1. Inventoriez les actions dans l'UI et l'API. Pour chaque fonctionnalité, listez les opérations concrètes : lire, créer, mettre à jour, supprimer, exporter, inviter, changer la facturation, exécuter des rapports admin.
2. Définissez les permissions côté serveur comme source de vérité. Stockez la correspondance rôle->permission en base (ou config), et faites en sorte que chaque handler API demande « est-ce que cet utilisateur a la permission X sur la ressource Y ? »
3. Renvoyez un petit payload de capabilities pour l'UI. Après la connexion (ou au rafraîchissement de session), renvoyez des booléens comme canEditCustomers, canDeleteCustomers, canExport, ou une liste compacte de chaînes de permission. Gardez-le minimal.
4. Appliquez des vérifications sur chaque écriture, plus les lectures sensibles. Toutes les mutations doivent vérifier les permissions. Certaines lectures devraient aussi le faire (par exemple salaires, logs d'audit, exports, ou tout endpoint qui contourne le filtrage normal).
5. Ajoutez quelques tests centrés sur les rôles. Choisissez 2-3 rôles clés et testez les actions les plus risquées. Exemple : Sales peut créer des deals mais ne peut pas exporter les clients, et Admin peut inviter des utilisateurs.

Une petite règle importante : ne faites jamais confiance aux rôles ou flags fournis par le client. L'UI peut cacher des boutons en se basant sur les capabilities, mais l'API doit toujours rejeter les requêtes non autorisées.

Patterns frontend qui restent honnêtes

Les menus sensibles aux permissions doivent aider les gens à trouver ce qu'ils peuvent faire, pas prétendre appliquer la sécurité. Le frontend est une glissière de guidage. Le backend est la serrure.

Construire les menus depuis une source unique de vérité

Au lieu d'éparpiller des vérifications de permissions sur chaque bouton, définissez votre navigation depuis une seule config qui inclut la permission requise pour chaque item, puis rendez à partir de cette config. Cela garde les règles lisibles et évite d'oublier des vérifications dans des coins bizarres de l'UI.

Un pattern simple ressemble à ceci :

const menu = [
  { label: "Contacts", path: "/contacts", requires: "contacts.read" },
  { label: "Export", action: "contacts.export", requires: "contacts.export" },
  { label: "Admin", path: "/admin", requires: "admin.access" },
];

const visibleMenu = menu.filter(item => userPerms.includes(item.requires));

Privilégiez le masquage de sections entières (comme Admin) plutôt que de parsemer des vérifications sur chaque lien de page admin. C'est moins de lieux à rater.

États honnêtes : masqué vs désactivé

Masquez les éléments quand l'utilisateur ne sera jamais autorisé à les utiliser. Désactivez quand l'utilisateur a la permission, mais que le contexte actuel est insuffisant.

Exemple : Supprimer un contact doit être désactivé tant qu'aucun contact n'est sélectionné. Même permission, juste pas assez de contexte pour l'instant. Quand vous désactivez, ajoutez un court message « pourquoi » près du contrôle (tooltip, texte d'aide, ou note inline) : Sélectionnez un contact pour le supprimer.

Un ensemble de règles qui tient la route :

• Masquer quand l'utilisateur n'a pas la permission.
• Désactiver quand l'utilisateur a la permission, mais aucun élément n'est sélectionné, le formulaire est invalide, ou les données sont en chargement.
• Ne jamais traiter le stockage local comme vérité pour les permissions. Ce n'est qu'un cache.
• Reverifier les permissions après connexion, changement de rôle ou changement de compte.

Application backend qui ne peut pas être contournée

Masquer des éléments de menu aide les gens à se concentrer, mais ça ne protège rien. Le backend doit être le juge final parce que les requêtes peuvent être rejouées, modifiées ou déclenchées en dehors de votre UI.

Une bonne règle : chaque action qui modifie des données nécessite une vérification d'autorisation, en un seul endroit, que chaque requête traverse. Cela peut être un middleware, un wrapper de handler, ou une petite couche de policy que vous appelez au début de chaque endpoint. Choisissez une approche et tenez-vous-y, sinon vous manquerez des chemins.

Placer la vérification sur le chemin de la requête

Séparez l'autorisation de la validation des entrées. Décidez d'abord « est-ce que cet utilisateur est autorisé à faire ceci ? », puis validez le payload. Si vous validez d'abord, vous pouvez divulguer des détails (comme quels IDs existent) à quelqu'un qui ne devrait même pas savoir que l'action est possible.

Un pattern qui scale :

• Authentifiez l'appelant et construisez une identité claire (user id, org id, rôles, permissions).
• Chargez le contexte de ressource nécessaire pour l'autorisation (souvent juste owner id ou org id).
• Appelez une seule fonction de policy (par exemple : Can(user, "invoice.delete", invoice)).
• Si refusé, arrêtez immédiatement et renvoyez le statut approprié.
• Ensuite seulement, validez et exécutez la logique métier.

Renvoyer des réponses claires et cohérentes

Utilisez des codes de statut qui aident à la fois votre frontend et vos logs :

• 401 Unauthorized quand l'appelant n'est pas connecté.
• 403 Forbidden quand connecté mais pas autorisé.

Faites attention à 404 Not Found comme déguisement. Cela peut être utile pour éviter de révéler l'existence d'une ressource, mais si vous l'utilisez de façon incohérente, le débogage devient pénible. Choisissez une règle cohérente par type de ressource.

Assurez-vous que la même autorisation s'exécute que l'action vienne d'un clic de bouton, d'une app mobile, d'un script, ou d'un appel API direct.

Enfin, enregistrez les tentatives refusées pour le débogage et les audits, mais protégez bien les logs. Enregistrez qui, quelle action, et quel type de ressource haut niveau. Évitez les champs sensibles, les payloads complets ou les secrets.

Cas limites qui font ou cassent la conception

La plupart des bugs de permissions apparaissent quand les utilisateurs empruntent des chemins que votre menu n'envisageait pas. C'est pourquoi les menus sensibles aux permissions sont utiles, mais seulement si vous prévoyez aussi les chemins qui les contournent.

Deep links et écrans « cachés »

Si le menu cache Facturation pour un rôle, un utilisateur peut toujours coller une URL sauvegardée ou l'ouvrir depuis l'historique. Traitez chaque chargement de page comme une requête fraîche : récupérez les permissions actuelles de l'utilisateur, et faites en sorte que l'écran refuse de charger les données protégées quand la permission manque. Un message amical « Vous n'avez pas accès » est acceptable, mais la vraie protection est que le backend ne renvoie rien.

Appels API directs et endpoints en masse

N'importe qui peut appeler votre API depuis les outils dev, un script, ou un autre client. Vérifiez donc les permissions sur chaque endpoint, pas seulement les écrans admin. Le risque facile à manquer est celui des actions en masse : un seul /items/bulk-update peut accidentellement permettre à un non-admin de modifier des champs qu'il ne voit jamais dans l'UI.

Les rôles peuvent aussi changer en cours de session. Si un admin retire une permission, l'utilisateur peut encore avoir un ancien token ou un menu en cache. Utilisez des tokens à courte durée de vie ou une consultation de permissions côté serveur, et gérez les réponses 401/403 en rafraîchissant les permissions et en mettant à jour l'UI.

Les appareils partagés créent un autre piège : l'état du menu en cache peut fuir entre comptes. Stockez la visibilité du menu indexée par user ID, ou évitez de la persister.

Cinq tests à exécuter avant la sortie :

• Ouvrir un deep link vers une page cachée en étant connecté avec un rôle limité
• Appeler une API protégée avec une requête copiée depuis les outils dev
• Changer le rôle de l'utilisateur pendant qu'il est actif, puis retenter des actions
• Se déconnecter, se reconnecter en tant qu'autre utilisateur, et vérifier que le menu se réinitialise
• Tenter des endpoints en masse avec des champs autorisés et non autorisés mélangés

Scénario exemple : un menu CRM simple avec application réelle

Imaginez un CRM interne avec trois rôles : Sales, Support, et Admin. Tout le monde se connecte et l'app affiche un menu à gauche, mais le menu n'est qu'une commodité. La vraie sécurité est ce que le serveur autorise.

Voici un simple jeu de permissions lisible :

• Leads : view, create, edit, delete, export
• Tickets : view, create, edit, assign
• Billing : view, edit
• Users : view, manage

L'UI commence par demander au backend les actions autorisées de l'utilisateur courant (souvent sous forme d'une liste de chaînes de permission) plus du contexte basique comme l'ID utilisateur et l'équipe. Le menu se construit à partir de cela. Si vous n'avez pas billing.view, vous ne voyez pas Facturation. Si vous avez leads.export, vous voyez un bouton Exporter sur l'écran Leads. Si vous ne pouvez éditer que vos propres leads, le bouton Edit peut toujours apparaître, mais il doit être désactivé ou afficher un message clair lorsqu'un lead ne vous appartient pas.

Maintenant la partie importante : chaque endpoint d'action applique les mêmes règles.

Exemple : Sales peut créer des leads et éditer les leads dont il est propriétaire. Support peut voir les tickets et les assigner, mais ne touche pas à la facturation. Admin peut gérer les utilisateurs et la facturation.

Quand quelqu'un essaie de supprimer un lead, le backend vérifie :

1. L'utilisateur a-t-il leads.delete ?
2. Si la règle est « own-only », lead.owner_id == user.id ?
3. Si le lead est verrouillé (par exemple déjà facturé), la suppression est-elle bloquée pour tout le monde sauf Admin ?

Même si un utilisateur Support appelle manuellement l'endpoint delete, il reçoit une réponse forbidden. L'élément de menu caché n'était jamais la protection. La décision backend l'était.

Erreurs courantes et pièges

Le plus grand piège avec les menus sensibles aux permissions est de penser que le travail est fini quand le menu a l'air correct. Masquer des boutons réduit la confusion, mais n'atténue pas le risque.

Erreurs qui surviennent le plus souvent :

• « Invisible » devient « impossible ». Quelqu'un peut toujours appeler l'API directement, réutiliser une ancienne URL, ou déclencher l'action via les outils dev. Traitez le masquage UI comme une commodité, pas comme une barrière.
• Permissions vérifiées uniquement dans l'UI. Si le frontend décide qui peut supprimer un enregistrement, vous avez déjà perdu. Le backend doit être le juge final pour chaque action protégée.
• Un unique flag isAdmin pour tout. Ça semble rapide, puis ça se propage. Bientôt chaque exception devient un cas spécial et plus personne ne peut expliquer les règles d'accès.
• Faire confiance au client pour dire le rôle. N'acceptez jamais role, isAdmin, ou permissions venant du navigateur comme vérité. Dérivez l'identité et l'accès depuis votre propre session ou token, puis cherchez rôles et permissions côté serveur.
• Oublier les permissions de lecture. Les équipes se concentrent sur les écritures (create, update, delete), mais les fuites de données viennent souvent des lectures. Lister des clients, voir des factures, exporter des CSV et rechercher nécessitent souvent des vérifications aussi.

Un exemple concret : vous cachez l'item Exporter les leads pour les non-managers. Si l'endpoint d'export ne vérifie pas non plus les permissions, n'importe quel utilisateur qui devine la requête (ou la copie depuis un collègue) peut quand même télécharger le fichier.

Checklist avant lancement

Avant de livrer des menus sensibles aux permissions, faites une dernière passe centrée sur ce que les utilisateurs peuvent réellement faire, pas sur ce qu'ils peuvent voir.

Parcourez votre app comme chaque rôle principal et essayez le même ensemble d'actions. Faites-le dans l'UI et aussi en appelant l'endpoint directement (ou en utilisant les outils dev) pour vous assurer que le serveur est la source de vérité.

Checklist :

• Pour chaque action protégée, confirmez qu'il existe une vérification d'autorisation côté serveur au point d'exécution (pas seulement lors de la construction du menu).
• Faites en sorte que l'UI rende les actions depuis des capabilities fournies par le serveur (par exemple une can-list depuis la session ou un endpoint permissions) au lieu de deviner à partir des noms de rôles.
• Vérifiez que l'UI traite les réponses interdites normalement : afficher un message clair, garder la page stable, et éviter de laisser l'utilisateur dans un état cassé.
• Testez les changements de rôle et de permission. Quand un admin met à jour l'accès, cela doit prendre effet rapidement et de manière prévisible (rafraîchissement de token, invalidation de session, ou versioning des permissions).
• Lancez quelques tests à haute valeur qui couvrent les rôles et actions touchant l'argent, les exports, les suppressions et les paramètres admin.

Un moyen pratique de repérer les lacunes : choisissez un bouton « dangereux » (supprimer un utilisateur, exporter un CSV, changer la facturation) et suivez-le de bout en bout. L'item du menu doit être masqué quand il le faut, l'API doit rejeter les appels non autorisés, et l'UI doit récupérer proprement quand elle reçoit un 403.

Prochaines étapes : livrer en sécurité sans ralentir

Commencez petit. Vous n'avez pas besoin d'une matrice d'accès parfaite le premier jour. Choisissez la poignée d'actions qui comptent le plus (voir, créer, éditer, supprimer, exporter, gérer les utilisateurs), mappez-les aux rôles que vous avez déjà, et avancez.

Avant de construire des écrans, faites une courte passe de planification qui liste des actions, pas des pages. Un item de menu comme Factures cache beaucoup d'actions : voir la liste, voir le détail, créer, rembourser, exporter. Les écrire en premier rend l'UI et les règles backend plus claires, et évite l'erreur courante qui consiste à protéger une page entière tout en laissant un endpoint risqué sous-protégé.

Quand vous refactorez des règles d'accès, traitez cela comme tout changement risqué : gardez un filet de sécurité. Les snapshots vous permettent de comparer le comportement avant/après. Si un rôle perd soudainement un accès nécessaire, ou en gagne un qu'il ne devrait pas avoir, revenir en arrière est plus rapide que de corriger en production pendant que les utilisateurs sont bloqués.

Une routine de release simple aide les équipes à avancer vite sans deviner :

• Rédigez la liste d'actions pour la fonctionnalité et nommez chaque permission.
• Ajoutez les vérifications backend en premier, puis branchez la visibilité UI sur les mêmes permissions.
• Testez un rôle autorisé et un rôle refusé pour chaque action risquée.
• Loggez les tentatives refusées (sans données sensibles) pour repérer les lacunes.
• Faites un snapshot avant le déploiement pour pouvoir revenir rapidement si nécessaire.

Si vous construisez avec une plateforme basée chat comme Koder.ai (koder.ai), cette même structure s'applique : définissez les permissions et policies une fois, faites lire les capabilities par l'UI depuis le serveur, et rendez les vérifications backend non optionnelles dans chaque handler.