Qui peut voir et modifier quoi dans votre application métier ?

Avant de nommer un modèle technique, votre équipe doit répondre à des questions ordinaires. Une personne peut-elle consulter ce dossier, modifier cette commande, valider cette dépense, exporter cette liste ou supprimer ce document ?

Commencez par les objets métier et leurs actions. Pour chaque fonction de travail, écrivez autorisé, refusé ou à décider. Ajoutez ensuite la portée : son propre dossier, son équipe, un établissement ou toute l’entreprise.

Lorsqu’aucune règle explicite ne correspond, prévoyez le refus. Testez au moins un cas autorisé et un cas refusé pour chaque action sensible. Une inconnue sur l’export, la suppression, l’administration ou la validation arrête la fonction jusqu’à la décision du responsable métier.

Le moindre privilège réduit les droits au besoin réel. C’est une recommandation de conception, pas une loi universelle. Les références RGPD et CNIL citées ici restent limitées aux traitements de données personnelles.

Pour un produit par abonnement, replacez cette matrice dans le cahier des charges complet du SaaS : création de l’organisation cliente, offre, échecs de paiement, support et sortie doivent conduire aux mêmes droits et aux mêmes refus vérifiables.

Un profil « administrateur » mélange souvent des décisions sans rapport : corriger un dossier, créer un compte, exporter toutes les données ou modifier une règle. Séparez ces actions. Vous pourrez ensuite regrouper les permissions qui correspondent réellement à une même fonction de travail.

Fonction de travail :
Objet métier :
Action :
Relation / état / portée :
Décision : autorisé | refusé | à décider
Responsable de la décision :
Cas autorisé :
Cas refusé :
Trace utile et finalité :

Le contrôle par rôles, appelé RBAC, associe des permissions à une fonction puis affecte cette fonction aux personnes. Il convient à des règles stables comme « la comptabilité peut consulter les factures validées ».

Il devient moins lisible si vous créez « responsable agence Lyon », « responsable agence Chambéry » et une nouvelle variante pour chaque remplacement.

Dans ce cas, la règle dépend d’un attribut (l’établissement, l’état, la date) ou d’une relation (le créateur, l’équipe, la délégation). OWASP les décrit comme un contrôle fondé sur des attributs (ABAC) ou sur des relations (ReBAC). La règle métier observable doit guider ce choix.

Une application doit répondre lorsqu’aucune règle ne correspond. OWASP recommande de refuser par défaut et de justifier chaque autorisation. Ce choix évite qu’une nouvelle API, une pièce jointe ou un écran secondaire devienne accessible parce que personne ne l’a ajouté à la liste.

La fiche CNIL « Gérer les habilitations » du 13 mars 2024 recommande, pour les traitements de données personnelles, de faire valider les demandes et de retirer les droits devenus inutiles lors d’un changement ou d’un départ. Elle invite aussi à impliquer les métiers dans une revue régulière, au moins annuelle.

La revue annuelle n’est pas une fréquence légale universelle. Elle ne permet pas d’attendre : un changement de situation doit déclencher l’action. Le cycle couvre l’arrivée, la mobilité et le départ, mais aussi le remplacement, la fin de mission, l’absence longue ou le changement d’établissement.

La fiche CNIL « Tracer les opérations » du 14 mars 2024 recommande, dans le périmètre des données personnelles, de tracer notamment création, consultation, partage, modification et suppression avec l’auteur, la date, l’heure, la nature de l’opération et une référence à la donnée.

Enregistrer ces champs ne suffit pas à rendre le journal exhaustif, inaltérable ou réellement consulté. Une trace devient une alerte seulement si une règle la repère et qu’une personne reçoit puis traite le signal.

Une trace peut elle-même contenir des données personnelles. Sa finalité, ses accès, sa protection et sa durée doivent alors être justifiés.

Répondez avec des états génériques. L’outil traite d’abord le contexte et les inconnues, puis la matrice, le refus, les droits sensibles, le cycle de vie et les tests négatifs. Il passe ensuite aux relations et à la trace. Une réponse documentée ne compense jamais un STOP antérieur.

Le dernier verdict signifie uniquement que la matrice peut être relue en atelier. Il ne prouve pas que le code applique les règles, qu’aucun chemin n’est oublié ou que le traitement respecte ses obligations. Les réponses restent dans l’état de la page et sont perdues au rechargement.

Avant le développement, chaque ligne critique de la matrice doit produire un cas autorisé et un cas refusé. Commencez par les actions qui exposent, modifient, exportent, suppriment ou valident les objets les plus sensibles.

Le guide du plan de recette aide à attribuer ces tests, préparer les données et classer les anomalies. Le guide du socle de sécurité complète les droits avec sauvegarde, détection, réponse et responsabilités globales.

Dans ce scénario, une personne crée et consulte ses demandes. Son responsable peut valider celles de son équipe. La comptabilité consulte et exporte seulement les demandes validées. Une personne ne valide jamais sa propre demande. Une délégation de validation est possible pendant une absence, avec début, fin et responsable de l’accord.

La suppression reste inconnue : elle ne passe donc pas en développement. La délégation possède un test après expiration. Le journal vise les validations, exports, retraits et refus sensibles, mais le scénario ne fixe aucune durée de conservation universelle.

Les droits sont le premier chapitre d’un ensemble plus large : les contrôles de sécurité d’une application métier couvrent la suite — journalisation, restauration, sous-traitance. Dès qu’une donnée réelle entre dans le produit, ces exigences appartiennent au premier lot, comme le rappelle le guide sur ce qu’un MVP doit contenir.

Deux contextes rendent l’exercice plus difficile. Reprendre un logiciel métier existant suppose d’inventorier des comptes dont plus personne ne connaît le périmètre, et une migration sans interruption de service fait cohabiter deux modèles de droits le temps de la bascule. Sur une plateforme partagée, Airtable ou Notion face à une application métier et Power Apps face à une application sur mesure expliquent ce que le plan souscrit permet réellement de cloisonner.

Si le besoin dépasse la configuration d’un outil existant, le service d’outils internes sur mesure peut transformer la matrice en fonctions et critères de réception. Pour transmettre un besoin déjà préparé, vous pouvez ensuite décrire le projet.