À retenir

• La recertification consiste à faire valider périodiquement, par les bonnes personnes, que les accès accordés restent justifiés — et à révoquer ceux qui ne le sont plus.
• Le piège principal n’est pas l’absence de recertification mais la « campagne de tampons » : un volume trop important poussé à des reviewers sans contexte, qui valident en masse pour s’en débarrasser.
• Une recertification efficace cible par le risque (toutes les applications n’ont pas la même criticité), confie la revue au plus près de la décision, et fournit au reviewer le contexte minimum pour décider en connaissance de cause.
• Recertifier ce qui est déclaré dans l’IGA ne suffit pas : il faut périodiquement réconcilier avec l’état réel des accès dans les applications, sinon on certifie une fiction.

Introduction

Fin de trimestre, campagne de recertification trimestrielle obligatoire : un manager reçoit 340 lignes à valider, sans contexte sur les droits attribués, sans information sur leur dernier usage, avec un délai de cinq jours ouvrés. Il ouvre la liste, fait défiler, valide tout, et passe à autre chose. Il a satisfait à l’exigence formelle ; le risque qu’il était censé contrôler reste intact.

Cette scène se rejoue, à des degrés divers, dans une grande partie des organisations qui ont déployé une recertification d’accès. Le problème n’est presque jamais l’absence du dispositif, c’est sa conception. Cet article explique pourquoi la recertification est essentielle, pourquoi elle échoue si souvent en pratique, et comment la concevoir pour qu’elle produise réellement de la valeur.

Qu’est-ce que la recertification des accès ?

La recertification — également appelée revue des habilitations ou revue des droits d’accès, termes utilisés de façon largement synonyme — consiste à demander périodiquement à des responsables désignés de valider ou révoquer les accès dont disposent des utilisateurs, afin de s’assurer qu’ils restent légitimes au regard de leur fonction actuelle.

C’est l’une des fonctions structurantes de la gouvernance des identités. L’ISO/IEC 27001:2022 l’inscrit implicitement dans ses contrôles 5.16 (gestion des identités) et 5.18 (droits d’accès), qui attendent une revue régulière des droits attribués. De nombreuses réglementations sectorielles — Sarbanes-Oxley (SOX) côté financier américain, DORA pour le secteur financier européen, exigences d’audit interne — rendent ces revues obligatoires en pratique pour les organisations concernées.

Pourquoi c’est essentiel — et souvent inefficace

L’objectif théorique de la recertification est clair : faire correspondre les droits accordés aux droits légitimes au regard des responsabilités actuelles de chacun. Sans revue régulière, les droits dérivent — accumulés par les mobilités successives (le Mover, traité dans l’article sur le cycle de vie des identités (JML)), accordés temporairement puis oubliés, alignés sur une fonction qui n’existe plus.

L’objectif réel observé dans beaucoup d’organisations est différent : produire une preuve de conformité pour les auditeurs. Et c’est précisément ce glissement qui transforme la recertification en exercice de tampon. Quand l’objectif devient « cocher la case », le reviewer optimise — c’est-à-dire valide en masse. La recertification produit alors une preuve documentaire sans aucune valeur de contrôle.

Les causes typiques de l’échec sont toujours les mêmes : volume excessif, absence de contexte fourni au reviewer, reviewer mal choisi (trop éloigné de la décision), absence de conséquences réelles aux décisions prises, absence d’audit des reviewers eux-mêmes.

Cibler par le risque

Le réflexe naturel — recertifier tout, tout le temps — est aussi le plus contre-productif. Une revue trimestrielle exhaustive sur l’ensemble des accès est généralement le pire des deux mondes : trop volumineuse pour être traitée sérieusement, pas assez ciblée pour gérer les risques réellement élevés.

Une recertification utile commence par une segmentation par criticité :

• Applications critiques (systèmes financiers, données sensibles, comptes à privilèges) : revue fréquente — semestrielle ou trimestrielle — avec un examen attentif et un volume restreint.
• Applications standard : revue annuelle suffit dans la plupart des cas.
• Droits sensibles transverses (administration, accès aux données personnelles, droits financiers) : revue dédiée plus fréquente, indépendamment de l’application.
• Populations à risque accru (prestataires, comptes à privilèges, utilisateurs ayant connu une mobilité récente) : campagnes ciblées spécifiques.

Cette gradation libère du temps là où il a peu de valeur (revue d’accès anodins) pour le concentrer là où il en a beaucoup. C’est le principe de base d’une démarche par les risques.

Qui doit recertifier ?

Le choix du reviewer conditionne plus la qualité de la revue que l’outil ou la fréquence. Trois rôles principaux coexistent en pratique :

Le manager direct voit son équipe et connaît le rôle de chacun ; c’est le reviewer naturel pour les droits liés aux fonctions métier. Sa limite : il connaît mal les droits techniques précis derrière les rôles, et peut manquer de recul sur les exceptions.

Le propriétaire de l’application voit qui a accès à son application et à quels droits ; c’est le reviewer pertinent pour les accès à forte criticité applicative ou pour les comptes externes (prestataires, intégrations). Sa limite : il connaît mal les utilisateurs eux-mêmes.

Le propriétaire de rôle vérifie la composition d’un rôle (quelles permissions il porte) et son attribution à des populations cohérentes ; c’est lui qui maintient le modèle dans la durée. La pertinence du modèle de rôles lui-même se prépare en amont par une démarche de role mining ; sans rôles métier solides, la revue par propriétaire de rôle perd une grande partie de son sens.

La règle utile : placer le reviewer au plus près de la décision qu’il doit prendre. Faire valider par la DSI les accès métier d’un utilisateur n’a aucun sens — elle ne peut pas en juger. La combinaison des trois points de vue, sur des périmètres distincts, est la voie la plus solide.

Les types de campagne

En complément de la segmentation par risque, plusieurs types de campagne se combinent :

La revue périodique est le mode classique : à intervalles définis, sur des périmètres définis. C’est le socle.

La revue événementielle se déclenche en réaction à un événement : un Mover (changement de poste), un audit, un incident de sécurité, une réorganisation. Elle vise un périmètre restreint mais traité avec attention.

La revue continue s’inscrit dans le quotidien plutôt qu’en campagne : à chaque attribution d’un droit sensible, validation immédiate par le bon responsable. Combinée à des alertes sur les anomalies (cumuls inattendus, droits dormants), elle réduit le volume des campagnes périodiques.

Aucun de ces modes n’est suffisant seul ; les organisations matures les combinent.

Éviter le piège du tampon

C’est la section la plus utile de cet article. Cinq leviers, dans l’ordre d’impact :

1. Maîtriser le volume. Une campagne avec 50 lignes par reviewer sera lue ; une campagne avec 500 ne le sera pas. La segmentation par risque conditionne cette maîtrise.
2. Fournir le contexte. Pour chaque ligne : qui est l’utilisateur, quelle est sa fonction actuelle, quel droit est en question, depuis quand est-il attribué, et — quand l’information est disponible — quel est son dernier usage effectif. Sans ce contexte, le reviewer ne peut que tamponner.
3. Justifier les maintiens, pas seulement les révocations. Si la révocation seule demande une justification, le réflexe est de valider sans réfléchir. Demander une justification pour le maintien d’un droit sensible change la dynamique.
4. Auditer les reviewers eux-mêmes. Échantillonner les décisions et les confronter à la réalité ensuite : un reviewer qui valide tout systématiquement peut faire l’objet d’un échange, voire d’un changement.
5. Intégrer la séparation des tâches dans la revue. Les conflits SoD non détectés par ailleurs ressortent souvent au moment de la recertification, à condition que l’outil les signale explicitement au reviewer.

Une remarque opérationnelle : la valeur d’une campagne se mesure aussi à ce qui se passe après elle. Si les révocations décidées ne sont pas exécutées, ou exécutées avec un délai de plusieurs semaines, la campagne perd son sens.

Droits déclarés et droits réels

Un point souvent ignoré par les pages marketing : ce que l’IGA présente au reviewer, ce sont les droits qu’il a lui-même provisionnés. Or les accès réels dans les applications peuvent en différer pour plusieurs raisons : droits ajoutés directement dans une application sans passer par l’IGA, exceptions accordées en local, comptes hors périmètre IGA, dérives techniques.

Recertifier les droits déclarés sans les confronter aux droits réels revient à valider une fiction. La parade est la réconciliation périodique : extraire l’état effectif des accès dans les applications cibles et le comparer à l’état attendu côté IGA. Les écarts sont alors traités explicitement, soit en alignant le réel sur l’attendu, soit en mettant à jour l’attendu pour refléter une situation légitime.

C’est un travail moins visible que la recertification elle-même, mais sans lui, toute la chaîne perd sa crédibilité.

Erreurs fréquentes

• Tout recertifier tout le temps. Volume écrasant, fatigue, tampon.
• Aucun contexte fourni. Le reviewer ne peut pas décider en connaissance de cause.
• Reviewers mal choisis. Trop loin du métier ou trop loin de l’application : décision sans valeur.
• Décisions non exécutées. Les révocations validées qui restent en attente vident la campagne de son sens.
• Pas d’audit des reviewers. Sans contrôle de qualité, les pratiques de tampon s’installent durablement.
• Recertifier l’IGA sans réconcilier le réel. On certifie ce qu’on croit, pas ce qui est.

FAQ

Quelle différence entre revue des habilitations et recertification ? En pratique, les deux termes sont utilisés de façon largement synonyme. Quand une distinction est faite, certains auteurs réservent « revue » à l’examen des droits effectifs dans les applications, et « recertification » à la validation des droits déclarés dans l’IGA. Cette distinction n’est pas universelle et la réalité opérationnelle attend les deux.

À quelle fréquence faut-il recertifier ? La bonne réponse est « selon le risque ». Annuel suffit pour le standard ; trimestriel ou semestriel pour le sensible ; continu pour les droits à privilèges. Une fréquence uniforme appliquée à tout est généralement le signe d’une démarche inefficace.

Faut-il un outil dédié ? À petite échelle et sur un périmètre limité, une revue manuelle (export, tableur, formalisation des décisions) peut suffire. Dès que les volumes augmentent et que les revues se multiplient, un outil de campagnes — généralement intégré à la plateforme IGA — devient indispensable, ne serait-ce que pour tracer les décisions et exécuter les révocations.

Que faire quand un reviewer valide systématiquement tout ? C’est un signal, pas un problème individuel à punir. Trois pistes : alléger son volume (souvent trop important), améliorer le contexte fourni, et avoir un échange direct sur ce qui rend la revue difficile. Si après ajustement le comportement persiste, un audit ciblé de ses décisions s’impose.

Conclusion

La recertification des accès est moins une question d’outil que de conception : ce qu’on demande, à qui, sur quoi, et avec quelles conséquences. Une campagne mal conçue produit beaucoup de signatures et peu de contrôle ; une campagne bien conçue, plus ciblée et mieux contextualisée, produit l’inverse. Pour démarrer concrètement, le plus utile est d’arrêter une segmentation par risque des périmètres à recertifier, d’identifier explicitement le bon reviewer pour chacun, et de fournir le contexte minimum sans lequel aucune décision sérieuse n’est possible — avant de penser à la fréquence et au volume.

Sources

• ISO/IEC 27001:2022, Annexe A — contrôles 5.16 (gestion des identités) et 5.18 (droits d’accès), qui encadrent la revue régulière des droits attribués.
• CLUSIF — Gestion et Gouvernance des Identités et des Accès (2017), guide professionnel français de référence sur l’IAM (organisme français reconnu de sécurité informatique).