Selon une étude ISACA 2025, 67 % des organisations européennes estiment leur maturité GRC supérieure à ce que leurs auditeurs observent. Cet écart de perception n'est pas un problème d'outils — c'est un problème de méthode. Les audits de maturité les plus courants mesurent des artefacts, pas des comportements. Ils certifient l'existence de politiques, pas leur effectivité opérationnelle. Voici les quatre biais qui transforment un audit de maturité en exercice de communication — et ce qu'il faut mesurer à la place.
Le contexte : pourquoi la maturité GRC est structurellement sur-déclarée
Le principe d'un audit de maturité GRC est séduisant : positionner l'organisation sur une échelle de 1 à 5 (CMMI, ISO 33001, ou un modèle propriétaire), identifier les écarts, prioriser les efforts. En théorie, c'est un outil de pilotage précieux. En pratique, deux dynamiques le dénaturent systématiquement.
La première est l'autoévaluation. La majorité des frameworks de maturité GRC reposent sur des questionnaires remplis par les équipes évaluées. Ces équipes ont un intérêt institutionnel à déclarer un niveau élevé — vis-à-vis de leur direction, de leurs partenaires, et parfois de leurs régulateurs. La pression sociale est réelle, même quand elle est inconsciente.
La deuxième est la confusion entre artefact et effectivité. Disposer d'une politique de gestion des risques documentée est une condition nécessaire, pas suffisante. Ce qui compte est que cette politique soit comprise, appliquée, et capable de résister à une situation réelle. Or c'est précisément ce que les modèles de maturité standards ne mesurent pas — ou ne mesurent pas bien.
NIS2 et DORA ont aggravé le phénomène : face à des obligations de conformité formelles, les organisations ont produit de la documentation en volume. Les registres de risques existent. Les plans de réponse aux incidents existent. Les politiques de gestion des accès existent. Ce qui manque, c'est la démonstration que ces documents correspondent à la réalité opérationnelle.
Erreur 1 : mesurer la présence des documents, pas leur opposabilité
La première erreur est la plus répandue. Un audit de maturité classique vérifie l'existence des politiques, la couverture des frameworks, la présence des signatures de validation. Ce sont des indicateurs de conformité documentaire — pas de maturité opérationnelle.
Ce que les auditeurs expérimentés mesurent à la place : la capacité des équipes à localiser et appliquer un document sans aide externe. Demandez à un manager opérationnel de vous montrer, en temps réel, la procédure à suivre en cas d'incident de sécurité. Si la réponse prend plus de deux minutes — ou implique de contacter le RSSI pour savoir où chercher — le niveau de maturité déclaré est artificiel.
L'erreur courante à éviter : évaluer la maturité sur la base de présentations préparées. Les organisations qui savent qu'elles seront auditées préparent leurs réponses. Une organisation vraiment mature n'a pas besoin de préparer — ses processus sont intégrés dans les pratiques quotidiennes, pas dans des fichiers archivés.
Application pratique : introduisez dans vos audits des "tests de découverte non annoncés" — des demandes ponctuelles faites à des équipes opérationnelles sans préavis. La réponse que vous obtenez est votre niveau de maturité réel.
Erreur 2 : confondre couverture des contrôles et effectivité des contrôles
Les frameworks de maturité demandent généralement : "Avez-vous un contrôle pour X ?" La réponse est presque toujours oui — au sens où quelque chose existe qui peut être présenté comme un contrôle. Ce que le questionnaire ne demande pas : ce contrôle a-t-il fonctionné lors des trois derniers événements pour lesquels il aurait dû s'activer ?
Un exemple documenté lors d'un audit NIS2 en 2025 : une organisation mid-market déclare un contrôle de revue des accès à hauts privilèges. La politique existe. Le calendrier de revue est documenté. Score de maturité : 4/5. Réalité observée lors de l'audit approfondi : la dernière revue effective date de 14 mois. Le contrôle existe — il ne fonctionne pas.
Ce que les auditeurs expérimentés mesurent à la place : les preuves d'exécution. Pas l'existence du processus, mais les traces de sa mise en œuvre. Pour chaque contrôle critique, demandez les trois dernières instances de son activation — avec date, responsable, et résultat. DORA RTS Article 9 est explicite : les contrôles doivent être testés périodiquement et les résultats documentés.
Erreur 3 : évaluer la maturité hors contexte d'incident
La troisième erreur est peut-être la plus coûteuse : mesurer la maturité en conditions normales, pas en conditions dégradées. Un programme GRC mature doit démontrer sa valeur précisément quand les conditions sont difficiles — pendant une crise, sous pression, avec des équipes débordées.
Or les audits de maturité se déroulent presque toujours dans des conditions optimales : préparation préalable, équipes disponibles, documentation à portée. Ils mesurent la maturité du programme dans sa meilleure configuration possible — pas dans la configuration où sa maturité compte vraiment.
Les incidents les plus coûteux de ces dernières années partagent un point commun : les organisations touchées avaient des scores de maturité GRC corrects. Leurs processus fonctionnaient — jusqu'au moment où ils ne fonctionnaient plus. La pression de l'incident a révélé des fragilités invisibles dans les conditions normales d'évaluation.
Ce que les auditeurs expérimentés mesurent à la place : la résilience des processus sous contrainte. Organisez des exercices où les ressources habituelles sont artificiellement réduites : le RSSI est indisponible, le système de ticketing est en panne, l'accès à la documentation est temporairement coupé. La réponse de votre équipe à cette contrainte est votre maturité réelle.
Application pratique : intégrez dans votre programme GRC un exercice annuel de simulation dégradée. Les failles identifiées dans cet exercice sont les seules qui comptent.
Erreur 4 : négliger la maturité de la gouvernance au profit de la maturité technique
Les modèles de maturité GRC ont été historiquement construits par des techniciens, pour des techniciens. Ils mesurent bien la profondeur technique des contrôles. Ils mesurent mal la qualité de la gouvernance au sens organisationnel. Or NIS2 (article 20) et DORA (article 5) sont explicites : la responsabilité de la gestion des risques ICT incombe aux organes de direction.
Concrètement : votre Conseil d'Administration ou votre Comité Exécutif reçoit-il des reportings sur les risques ICT avec une fréquence et une qualité suffisantes pour prendre des décisions éclairées ? Ces décisions sont-elles documentées et traçables ? Les arbitrages de risque sont-ils formellement validés au bon niveau de responsabilité ? Un programme GRC techniquement mature mais sans remontée décisionnelle vers la direction est immature au sens de NIS2 et DORA — quelles que soient ses scores sur les frameworks techniques.
Ce que les auditeurs expérimentés mesurent à la place : le cycle décisionnel du risque. De la détection d'un risque à son traitement documenté, en passant par son escalade au bon niveau de gouvernance, combien de temps ? Avec quelles preuves ? Ces preuves sont-elles auditables ?
Évaluer votre maturité réelle — trois questions sans filtre
Demandez à un collaborateur opérationnel, sans préavis, de vous montrer comment il signalerait un incident de sécurité. Si la réponse implique de chercher où se trouve la procédure, votre maturité déclarée est surestimée.
Demandez à votre équipe GRC les preuves d'exécution des 5 contrôles NIS2/DORA que vous considérez les plus critiques — pas les politiques, les preuves. Si ces preuves ne sont pas disponibles dans les 30 minutes, votre couverture de contrôles est documentaire, pas opérationnelle.
Demandez à votre direction générale quelle décision de risque ICT elle a prise et documentée dans les 90 derniers jours. Si la réponse est vague, votre gouvernance du risque ne satisfait pas aux exigences NIS2 et DORA — indépendamment de votre score de maturité technique.
Presidio structure la collecte de preuves d'exécution, la traçabilité des décisions de risque et la génération de reportings direction dans un registre unique, conforme NIS2 et DORA : contactez notre équipe pour un diagnostic de 30 minutes. Lire aussi : IAM et NIS2/DORA — le contrôle d'accès que votre audit signalera en premier.
Conclusion
La maturité GRC se mesure dans les conditions difficiles, pas dans les conditions idéales. Les organisations qui atteignent une maturité opérationnelle réelle partagent une caractéristique : elles traitent les audits de maturité comme des outils d'amélioration, pas comme des exercices de communication. Elles mesurent l'effectivité de leurs contrôles, pas leur existence. Elles testent leurs processus sous contrainte, pas dans des conditions préparées. Dans votre contexte, quel serait le résultat d'un test de découverte non annoncé sur vos processus les plus critiques ?