Revue des droits applicatifs : le cas d’un accès oublié devenu risque projet

Le point de départ : une application utile, mais des rôles devenus opaques

L’application étudiée gère des demandes internes, des validations et quelques exports sensibles. Elle n’est pas récente, mais elle reste centrale dans le quotidien des équipes. Les droits sont organisés en profils : consultation, saisie, validation, administration fonctionnelle et administration technique. Sur le papier, le modèle paraît lisible.

Dans la pratique, les profils ont été attribués par exception. Une absence à couvrir, un projet à accélérer, un test de recette, une urgence de production : chaque événement a laissé une trace dans les comptes. Personne n’a volontairement créé une situation risquée. Le problème vient plutôt de l’absence de moment régulier pour vérifier que les accès correspondent encore aux responsabilités réelles.

Le sujet est proche de la sécurité des identités, mais il ne se limite pas à l’authentification. Le déploiement du MFA réduit le risque d’accès avec un mot de passe compromis. Il ne dit pas si le compte, une fois authentifié, possède encore les bons droits. La revue applicative répond à cette seconde question.

Identifier les décisions que la revue doit permettre

Une revue des droits échoue souvent parce qu’elle commence par un export massif. La liste des comptes arrive dans un tableur, avec des noms de profils techniques que peu de responsables métier comprennent. Après quelques échanges, chacun valide par prudence ou reporte la décision.

Dans ce cas, l’équipe a inversé l’ordre. Avant d’extraire les données, elle a défini les décisions attendues : supprimer les comptes inutiles, réduire les profils trop larges, confirmer les exceptions nécessaires et repérer les droits incompatibles avec certaines fonctions. Cette clarification a changé la forme de la revue. Le tableau n’était plus une photographie exhaustive, mais un support d’arbitrage.

| Signal observé | Risque principal | Décision attendue | Responsable utile | | --- | --- | --- | --- | | Compte sans connexion récente | Accès dormant conservé sans raison claire | Désactiver ou justifier temporairement | Manager ou responsable applicatif | | Profil d’administration attribué à un utilisateur métier | Action sensible possible hors procédure | Réduire le profil ou formaliser l’exception | Responsable métier et IT | | Cumul de validation et de contrôle | Absence de séparation des tâches | Séparer les rôles ou tracer une exception | Process owner | | Compte prestataire encore actif | Accès maintenu après la mission | Désactiver, prolonger avec date de fin ou rattacher au contrat | Chef de projet |

Rendre les rôles compréhensibles avant de demander une validation

Le point dur n’était pas seulement technique. Les libellés des profils venaient de l’histoire de l’application : codes courts, noms hérités, variantes créées pour une équipe puis réutilisées ailleurs. Demander à un manager de valider ces droits sans traduction revenait à lui faire porter une responsabilité qu’il ne pouvait pas exercer correctement.

L’équipe a donc préparé une correspondance simple entre profils applicatifs et capacités réelles. Le profil ne devait pas être décrit par son nom interne, mais par ce qu’il permet concrètement : créer une demande, modifier une pièce jointe, valider un dossier, exporter une liste, gérer les référentiels, changer les paramètres. Cette étape demande un effort initial, mais elle évite une revue purement formelle.

Ce travail rejoint une logique déjà utile dans un registre des dépendances SI : rendre visible ce qui conditionne un changement futur. Ici, la dépendance n’est pas un flux ou une interface, mais un droit opérationnel qui peut peser sur la sécurité, la conformité interne et la continuité du service.

Limiter le périmètre pour obtenir une décision fiable

La première revue n’a pas cherché à couvrir tous les utilisateurs avec le même niveau de détail. L’équipe a commencé par les droits les plus sensibles : administration, export, validation finale et modification de référentiels. Ce choix a réduit le volume, mais augmenté la qualité des réponses.

Une revue trop large pousse à la validation mécanique. Une revue ciblée permet de poser des questions concrètes : cette personne doit-elle encore valider ? A-t-elle besoin d’exporter toutes les données ou seulement de consulter un dossier ? Son rôle temporaire a-t-il une date de fin ? Le compte est-il lié à une personne clairement identifiée ?

Le cadrage a aussi évité un piège fréquent : traiter tous les écarts comme des urgences. Certains droits devaient être retirés rapidement. D’autres demandaient une discussion métier, car le fonctionnement réel reposait sur une exception connue mais jamais documentée. La revue a donc distingué correction immédiate, décision à arbitrer et exception acceptée avec propriétaire.

Organiser la revue comme un cycle court

Le processus retenu tenait en quelques étapes. L’équipe IT préparait l’extraction et la traduction des rôles. Le responsable applicatif qualifiait les cas évidents. Les managers concernés validaient seulement les comptes de leur périmètre. Les décisions étaient ensuite appliquées, puis contrôlées sur un second export.

Le délai court comptait autant que la méthode. Une revue étalée sur plusieurs mois produit un résultat déjà obsolète. Dans ce cas, l’équipe a préféré une revue restreinte, terminée rapidement, plutôt qu’un grand chantier couvrant tous les détails sans date de clôture claire.

Checklist d’une revue des droits applicatifs exploitable

• Définir les droits sensibles avant d’extraire tous les comptes.
• Traduire chaque profil technique en actions compréhensibles par le métier.
• Identifier un propriétaire pour chaque décision d’accès.
• Repérer séparément les comptes dormants, les profils larges et les exceptions temporaires.
• Prévoir une date de fin pour les accès liés à un projet, une mission ou une absence.
• Conserver la trace de la décision, pas seulement le fichier d’export.
• Vérifier après application que les droits retirés ne sont plus actifs.
• Réintégrer les demandes d’accès dans un circuit standard pour éviter de recréer les mêmes écarts.

Ce que l’étude de cas montre vraiment

La revue des droits applicatifs n’est pas un exercice de conformité isolé. C’est un mécanisme de maintenance du système d’information. Elle révèle les écarts entre l’organisation officielle, les pratiques réelles et l’histoire des projets. Elle permet aussi de discuter des droits avec les personnes qui comprennent le métier, au lieu de laisser l’équipe IT deviner seule ce qui doit rester ouvert.

Le résultat attendu n’est pas une matrice parfaite. C’est une situation plus lisible : moins de comptes dormants, moins de profils trop larges, des exceptions nommées, des décisions traçables et un circuit plus propre pour les futures demandes. Une revue réussie doit donc laisser derrière elle une façon de travailler, pas seulement un tableur archivé.

Pour une première itération, le bon périmètre est souvent une seule application critique, quelques droits sensibles et un délai court. Cette contrainte oblige à produire des décisions applicables. Elle donne aussi une base concrète pour étendre ensuite la démarche à d’autres applications, sans transformer la revue des droits en rituel lourd que personne ne souhaite recommencer.