Droits applicatifs : 9 décisions à cadrer avant la recette

La liste des décisions à verrouiller

• Nommer les actions sensibles qui changent réellement le niveau de risque.
• Séparer les rôles métier des profils techniques configurés dans l’application.
• Décider qui demande, qui valide et qui attribue les droits.
• Prévoir une règle claire pour les accès temporaires.
• Identifier les profils incompatibles avant les tests de recette.
• Rendre les profils lisibles pour les valideurs métier.
• Tester les droits comme une fonctionnalité à part entière.
• Préparer le support aux premières demandes d’accès.
• Conserver une preuve simple des décisions prises.

1. Nommer les actions sensibles, pas seulement les écrans

Un écran accessible ne dit pas ce qu’un utilisateur peut réellement faire. Deux personnes peuvent voir la même fiche client, mais l’une peut seulement consulter, tandis que l’autre peut modifier une adresse, déclencher un remboursement ou exporter un portefeuille complet.

Le cadrage doit donc partir des actions sensibles : créer, modifier, supprimer, valider, annuler, exporter, paramétrer, réaffecter, débloquer, archiver. Cette granularité évite les profils trop larges et rend les arbitrages plus faciles à expliquer. Elle prépare aussi les scénarios de test, car chaque permission importante devient vérifiable.

2. Séparer les rôles métier des profils techniques

Un rôle métier décrit une responsabilité dans l’organisation : gestionnaire, superviseur, contrôleur, administrateur fonctionnel, support niveau 2. Un profil technique décrit ce que l’application autorise concrètement. Les confondre crée des intitulés trompeurs : un responsable peut avoir besoin de consulter beaucoup d’informations sans avoir le droit de les modifier.

Le projet gagne à maintenir une table de correspondance simple. Elle indique quel rôle métier obtient quel profil applicatif, dans quel contexte et avec quelle justification. Cette table peut être reliée au cadrage du projet informatique lorsque les responsabilités font partie du besoin initial.

3. Décider qui attribue les droits

Attribuer un droit n’est pas un geste neutre. Le projet doit préciser qui peut demander, qui valide et qui exécute l’attribution. Dans une petite application interne, ces trois rôles peuvent être proches. Dans une application critique, ils doivent souvent être séparés pour éviter qu’une même personne demande et accorde un accès sensible sans regard externe.

La décision doit rester praticable. Un circuit trop long sera contourné. Un circuit trop informel finira dans les messages privés et les demandes orales. Le bon compromis consiste à identifier quelques droits sensibles avec validation renforcée, puis à garder un chemin court pour les accès standards.

4. Prévoir les droits temporaires dès le départ

Les projets accumulent des accès temporaires : recette métier, renfort support, prestataire, administrateur ponctuel, reprise de données. Le problème apparaît lorsque le temporaire n’a pas de date de fin. Au moment de la recette, il faut donc prévoir comment ces accès seront créés, suivis et retirés.

Une règle simple suffit souvent : tout accès exceptionnel doit avoir un propriétaire, une justification, une durée et une condition de retrait. Cette règle est particulièrement utile lorsque l’équipe prépare une mise en production sensible, car les accès ajoutés pour le jour J peuvent rester actifs après la bascule si personne ne les suit.

5. Identifier les profils incompatibles

Certaines combinaisons de droits posent problème même si chaque droit paraît légitime isolément. Une personne qui crée une demande et la valide, qui modifie une donnée de référence et approuve son usage, ou qui administre les paramètres et contrôle les résultats cumule des pouvoirs difficiles à justifier.

Le projet doit lister ces incompatibilités avant la recette. Cette liste n’a pas besoin d’être parfaite pour être utile. Elle permet déjà de repérer les profils trop puissants, les rôles hybrides et les exceptions qui devront être assumées explicitement.

6. Rendre les profils lisibles pour les valideurs

Un export de permissions brutes aide rarement un responsable métier à prendre une décision. Les noms techniques, les codes internes et les menus imbriqués ne disent pas clairement le risque associé. Avant de demander une validation, l’équipe doit traduire les profils en langage opérationnel.

Une bonne fiche de profil indique les actions autorisées, les données visibles, les limites prévues, les profils incompatibles et les cas où ce profil doit être retiré. Ce travail rejoint la logique d’une revue des droits applicatifs, mais il intervient ici en amont, pendant la construction du projet.

7. Tester les droits comme une fonctionnalité

Les droits ne doivent pas être vérifiés seulement par absence d’erreur. Il faut des tests positifs et négatifs : l’utilisateur autorisé peut réaliser l’action attendue, l’utilisateur non autorisé ne peut pas la réaliser, et l’application réagit proprement lorsque l’accès est refusé.

Les scénarios de recette doivent inclure les profils courants, les profils sensibles, les cas de délégation, les utilisateurs sans rôle complet et les comptes sortis du périmètre. Cette approche évite de découvrir en production qu’un bouton masqué côté interface reste accessible par un autre chemin applicatif.

8. Préparer le support aux demandes d’accès

Après la mise en service, les premières demandes arrivent vite : nouvel arrivant, changement d’équipe, blocage, remplacement temporaire, erreur d’attribution. Si le support ne sait pas distinguer une anomalie d’un choix de sécurité, il risque de transformer chaque ticket en exception.

Le projet doit fournir une base courte : description des profils, critères d’attribution, circuit de validation, cas refusés par principe, procédure de retrait et point de contact pour arbitrage. Cette documentation doit être assez précise pour répondre aux demandes fréquentes sans renvoyer systématiquement vers l’équipe projet.

9. Prévoir la preuve de décision

Un droit sensible doit pouvoir être expliqué après coup. Il ne s’agit pas seulement de savoir qu’un compte avait un profil, mais de comprendre pourquoi ce profil avait été accordé, par qui, pour quel usage et jusqu’à quand. Sans cette trace, l’équipe perd du temps lors d’un audit, d’un incident ou d’un changement d’organisation.

La preuve peut être simple : ticket, demande validée, décision de comité projet, règle d’attribution documentée. L’essentiel est que la décision soit retrouvable et reliée à une responsabilité claire.

Tableau de cadrage des droits applicatifs

| Décision à prendre | Question utile | Livrable léger | | --- | --- | --- | | Actions sensibles | Quelles opérations changent réellement le risque ? | Liste des actions à contrôler | | Profils applicatifs | Quels droits composent chaque profil ? | Fiche de profil lisible | | Validation | Qui accepte qu’un utilisateur reçoive ce droit ? | Règle de demande et validation | | Droits temporaires | Quand et comment l’accès prend-il fin ? | Date ou condition de retrait | | Incompatibilités | Quels cumuls doivent être évités ? | Liste des combinaisons interdites | | Recette | Quels profils doivent être testés ? | Scénarios positifs et négatifs |

Infographie à prévoir : le circuit d’un droit applicatif

L’infographie associée à l’article doit montrer un circuit simple : besoin métier, demande d’accès, validation, attribution, test en recette, usage en production, retrait ou révision. Le message important est que le droit applicatif n’est pas un paramètre isolé. Il traverse plusieurs moments du projet et doit rester compréhensible par ceux qui demandent, ceux qui valident et ceux qui exploitent l’application.

Le bon niveau de cadrage

Le cadrage des droits applicatifs devient utile lorsqu’il aide à décider, tester et exploiter. Il devient contre-productif lorsqu’il cherche à décrire chaque micro-permission sans distinguer les vrais enjeux. Pour un projet court, une matrice simple peut suffire. Pour une application métier critique, il faut ajouter les profils incompatibles, les droits temporaires et la preuve de validation.

Le point de départ reste le même : ne pas attendre la fin du projet pour parler des droits. Plus la discussion arrive tôt, plus elle ressemble à un choix de conception. Plus elle arrive tard, plus elle devient une série d’exceptions à absorber avant l’ouverture du service.