Transformer un constat d’audit en plan d’action ne consiste pas à copier les recommandations du rapport dans Excel. Un constat décrit ce qui a été observé ; le risque explique pourquoi la situation mérite une décision ; la recommandation indique le résultat de sécurité recherché ; l’action précise ce qui sera réellement réalisé, par qui, pour quand et avec quelle preuve. Un plan d’action cybersécurité exploitable doit donc relier chaque action à son origine, sa priorité, son responsable, son échéance, son effort, son coût, ses dépendances et son critère de clôture. Après réalisation, un contrôle distinct doit vérifier que la correction produit réellement l’effet attendu.
Le problème apparaît fréquemment à la fin d’un audit.
Le consultant remet un rapport contenant :
Puis le document est présenté à la direction, enregistré dans un espace documentaire et rarement rouvert avant le prochain audit.
Ce n’est pas nécessairement un problème de qualité de l’audit.
C’est souvent une rupture entre deux processus :
l’évaluation et l’exécution.
Le NIST Cybersecurity Framework 2.0 formalise justement cette continuité : l’organisation compare sa situation actuelle à la situation cible, analyse les écarts puis construit un plan d’action priorisé pour les traiter. Ce plan est ensuite mis en œuvre et la situation réévaluée.
Le même principe apparaît dans le ReCyF 2.5 publié par l’ANSSI en mars 2026. Pour la gestion de la conformité, le référentiel prévoit qu’un plan d’action soit établi, mis en œuvre et suivi pour corriger les écarts, avec au minimum un responsable et une échéance raisonnable pour chaque action.
Le véritable livrable post-audit n’est donc pas simplement le rapport.
C’est un système permettant de répondre continuellement à cinq questions :
Ces quatre notions sont souvent mélangées dans les rapports.
Elles doivent pourtant rester distinctes.
| Élément | Question | Exemple |
| Constat | Qu’avons-nous observé ? | Aucun test de restauration documenté n’a été présenté depuis 18 mois |
| Risque | Pourquoi est-ce important ? | Une sauvegarde défectueuse pourrait n’être découverte qu’au moment d’un incident |
| Recommandation | Quel résultat faut-il atteindre ? | Tester régulièrement la restauration des sauvegardes |
| Action | Que va-t-on concrètement faire ? | Restaurer un serveur représentatif en environnement isolé et documenter le résultat |
| Preuve de clôture | Comment démontrer que l’action a été réalisée ? | Rapport de test daté et validé |
| Contrôle d’efficacité | Comment vérifier que le dispositif fonctionne durablement ? | Nouveau test au prochain cycle et vérification du traitement des anomalies |
La distinction n’est pas seulement sémantique.
Le modèle POA&M du NIST distingue lui-même une remédiation recommandée d’une action de remédiation réellement planifiée puis d’une remédiation terminée.
Un constat doit rester factuel.
Évitez :
« La gestion des sauvegardes est mauvaise. »
Préférez :
« Les sauvegardes sont exécutées quotidiennement et supervisées par le prestataire. Aucun résultat de test de restauration réalisé au cours des douze derniers mois n’a toutefois pu être présenté lors de l’audit. »
Le constat ne prescrit pas encore la solution.
Le risque relie le constat au contexte métier.
Pour le même constat :
« En cas de corruption ou d’indisponibilité des sauvegardes, l’organisation pourrait découvrir l’impossibilité de restaurer ses données uniquement lors d’un incident réel. »
La gravité dépend ensuite :
Un constat n’entraîne donc pas automatiquement la même priorité chez deux entreprises.
Une bonne recommandation décrit une cible sans imposer inutilement la façon exacte d’y parvenir.
Exemple :
« Mettre en place des tests périodiques de restauration couvrant les systèmes critiques et conserver les résultats ainsi que les anomalies identifiées. »
Elle reste suffisamment stable même si l’équipe change d’outil ou de prestataire.
L’action doit être immédiatement attribuable.
Exemple :
« Restaurer une sauvegarde du serveur ERP dans l’environnement de test, vérifier l’intégrité des données, documenter le temps de restauration et traiter les anomalies identifiées. »
Cette formulation permet à une personne de commencer le travail sans relire dix pages du rapport.
Avant de créer une tâche, vérifiez que le constat est :
Un désaccord sur le constat doit être résolu avant de débattre de la date de remédiation.
Il peut aboutir à plusieurs décisions :
Créer une action sur un constat incorrect produit simplement une mauvaise action plus rapidement.
Deux constats différents peuvent provenir de la même cause.
Par exemple :
Créer quatre projets indépendants peut être moins pertinent qu’un seul chantier :
« Structurer la gestion du cycle de vie des comptes privilégiés. »
L’analyse de la cause évite les plans d’action constitués d’une succession de corrections superficielles.
Tous les constats ne doivent pas obligatoirement conduire à une remédiation immédiate.
Selon le contexte, l’organisation peut notamment :
Le NIST CSF rappelle que la réponse au risque dépend notamment de la tolérance au risque, des besoins métier et de l’impact potentiel sur les services critiques.
Un plan d’action sérieux conserve donc également les décisions de non-traitement.
Exemple :
Action différée jusqu’au renouvellement de l’ERP en février 2027. Risque résiduel accepté par la direction. Mesure compensatoire : restriction réseau et MFA administrateur.
Le constat ne disparaît pas simplement parce qu’aucune action immédiate n’est lancée.
Une action exploitable doit contenir un verbe, un objet et un résultat observable.
Renforcer les accès administrateurs.
Identifier les comptes administrateurs actifs et supprimer ceux qui ne disposent plus d’une justification métier.
Extraire les comptes à privilèges de Microsoft Entra ID, faire valider chaque compte par le responsable IT et désactiver les comptes sans propriétaire ou justification.
La troisième version permet immédiatement d’identifier :
Le NIST définit le Plan of Action and Milestones comme un document identifiant les tâches à accomplir, les ressources nécessaires, les jalons et les dates prévues d’achèvement.
En France, MonServiceSécurisé de l’ANSSI permet également, pour les mesures placées dans le plan d’action, d’attribuer des responsables, une priorité et une échéance.
Ces trois champs ne doivent donc pas être considérés comme des informations facultatives.
Une action sans responsable devient facilement :
« À voir avec l’IT. »
Une action sans échéance :
« À faire quand nous aurons le temps. »
Une action sans priorité :
une ligne de plus dans une liste de cinquante tâches.
Avant de valider une feuille de route, il faut distinguer trois dimensions.
Par exemple :
Il est préférable d’utiliser des classes d’effort tant que l’action n’est pas suffisamment détaillée.
Il peut comprendre :
Certaines remédiations ne coûtent presque rien à mettre en place mais génèrent ensuite :
Le coût doit donc être étudié sur le cycle de vie, pas uniquement lors du lancement.
La tâche n’est pas terminée parce que son responsable indique :
« C’est fait. »
Deux contrôles sont nécessaires.
Preuve de clôture : permet de démontrer que le travail prévu a été réalisé.
Contrôle d’efficacité : vérifie que la correction produit réellement le résultat de sécurité recherché.
Le NIST RMF prévoit précisément qu’après les actions de remédiation, les contrôles concernés soient réévalués afin de vérifier qu’ils sont correctement mis en œuvre, fonctionnent comme prévu et produisent le résultat attendu.
Cette distinction améliore fortement la qualité d’un plan de remédiation.
Une bonne action peut être contrôlée avec cette grille.
| Élément | Question |
| Verbe | Que faut-il faire ? |
| Périmètre | Sur quels systèmes, processus ou populations ? |
| Résultat | Quel état doit être obtenu ? |
| Responsable | Qui répond de l’achèvement ? |
| Échéance | Pour quand ? |
| Priorité | Avec quelle urgence ? |
| Effort | Quelle charge interne ? |
| Coût | Quel budget externe ou récurrent ? |
| Dépendances | Qu’est-ce qui doit arriver avant ? |
| Preuve | Comment démontrer la réalisation ? |
| Contrôle | Comment vérifier l’efficacité ? |
Mauvaise formulation
Formaliser la gestion des incidents.
Action exploitable
Rédiger et faire valider une procédure de gestion des incidents couvrant la qualification, les rôles, l’escalade, la conservation des informations et la clôture des incidents.
Mais cette action ne suffit pas encore à démontrer que la gestion des incidents fonctionne.
Une seconde action pourra être :
Réaliser un exercice sur table utilisant la procédure validée et documenter les difficultés rencontrées.
C’est ici que la distinction entre formalisation et effectivité devient utile.
Le responsable ne doit pas nécessairement réaliser toutes les tâches.
Il doit en revanche répondre de leur progression et de leur résultat.
Pour chaque action, conservez idéalement :
Évitez :
Responsable : DSI / RSSI / RH / prestataire.
Quatre responsables signifient généralement qu’il n’y en a aucun.
Préférez :
Responsable : DSI
Contributeurs : RSSI, administrateur système, prestataire
Validation : direction
Pour les actions importantes, utilisez au besoin une logique RACI, mais ne surchargez pas les petites actions avec une gouvernance disproportionnée.
L’échéance doit être fondée sur le risque et les contraintes d’exécution.
Elle ne doit être ni :
Le ReCyF 2.5 emploie justement la notion d’échéance raisonnable au regard du besoin de sécurisation du système d’information.
Une méthode pratique consiste à examiner :
Ne remplacez pas simplement :
30/09/2026
par :
15/12/2026.
Conservez :
Cette information permet de distinguer une feuille de route réaliste d’un plan continuellement repoussé.
La priorité n’est pas le niveau de maturité.
Ce n’est pas non plus automatiquement la sévérité affichée dans le rapport.
Une bonne priorité combine :
risque × exposition × urgence × dépendances × faisabilité.
Une matrice simple peut être utilisée :
| Priorité | Interprétation |
| P1 | Risque important, exposition élevée ou prérequis bloquant nécessitant une décision rapide |
| P2 | Remédiation significative à intégrer à la feuille de route proche |
| P3 | Amélioration utile pouvant être planifiée après les sujets prioritaires |
Les définitions doivent être adaptées au contexte de l’organisation.
Constat A
Absence de procédure formalisée pour une pratique technique déjà correctement appliquée et contrôlée.
Constat B
Absence de MFA sur plusieurs comptes administrateurs accessibles à distance.
Même si les deux constats obtiennent un score de maturité comparable, leur ordre de traitement peut être très différent.
Le NIST recommande précisément que les plans issus des écarts soient priorisés selon les objectifs métier, le contexte de risque et les ressources disponibles.
Ne confondez pas priorité et effort.
Une action peut être :
Cette distinction permet d’identifier les actions rapides sans sacrifier les vrais risques.
| Dimension | Exemple de valeur |
| Effort interne | 3 JH |
| Achat ponctuel | À chiffrer |
| Prestation externe | Oui / Non |
| Coût récurrent | Mensuel ou annuel |
| Délai incompressible | 4 semaines |
| Niveau de complexité | Faible / moyen / élevé |
| Dépendance budgétaire | Oui / Non |
Pour une estimation plus structurée :
Coût total prévisionnel = charge interne + achats + prestations + coûts récurrents sur la période retenue.
La charge interne peut être valorisée avec le coût journalier propre à l’organisation.
Il ne faut pas inventer une valeur moyenne universelle : le coût d’une journée interne ou d’une prestation cyber varie fortement selon les organisations et les compétences mobilisées.
Un plan d’action devient difficile à exécuter lorsque toutes les lignes semblent indépendantes.
Prenons un programme IAM :
A1 — inventorier les comptes privilégiés
↓
A2 — définir les règles d’attribution
↓
A3 — séparer les comptes standards et administrateurs
↓
A4 — déployer le MFA
↓
A5 — mettre en place la revue périodique
Fixer la même échéance aux cinq actions masque la réalité.
Le plan doit permettre de documenter :
Les grandes remédiations peuvent également être divisées en plusieurs jalons.
Le modèle POA&M du NIST prévoit justement la gestion de tâches, ressources et jalons permettant de suivre la progression de la remédiation.
La preuve de clôture doit être définie avant que l’action soit considérée comme terminée.
| Action | Preuve de clôture possible |
| Activer le MFA | Export de configuration ou contrôle des comptes couverts |
| Réaliser une revue des droits | Export revu, validation et anomalies corrigées |
| Formaliser une procédure | Document validé et versionné |
| Tester une restauration | Rapport du test et anomalies |
| Corriger une configuration | Export ou capture de la configuration après correction |
| Sensibiliser les collaborateurs | Support, population, date et suivi de participation |
| Réaliser une analyse de risques | Analyse validée et décisions de traitement |
| Supprimer des comptes | Export avant/après ou trace de suppression |
Une preuve ne doit pas simplement démontrer qu’une activité a commencé.
Exemple :
Action : généraliser le MFA aux administrateurs.
Preuve insuffisante : ticket « déploiement MFA terminé ».
Preuve plus solide : liste des comptes administrateurs confrontée à la configuration MFA après déploiement.
C’est l’une des distinctions les plus importantes du suivi de remédiation.
La question est :
L’action prévue a-t-elle été réalisée ?
La question devient :
Cette action a-t-elle réellement corrigé ou réduit le problème ?
Action
Réaliser un test de restauration.
Preuve de clôture
Rapport du test daté.
Contrôle d’efficacité
Vérifier que :
Le NIST RMF demande justement que les éléments remédiés soient réévalués afin de vérifier qu’ils fonctionnent comme prévu et produisent le résultat de sécurité attendu.
Un workflow plus rigoureux peut distinguer :
À faire → En cours → À valider → Clôturé → Efficacité vérifiée
Cela évite que la case « terminé » devienne le seul critère de réussite.
Voici une structure suffisamment complète pour la plupart des PME et missions de conseil.
| ID | Constat | Action | Priorité | Responsable | Échéance | Effort | Coût | Dépendance | Statut | Preuve | Contrôle |
| ACT-01 | MFA incomplet | Étendre le MFA aux administrateurs | P1 | Resp. IT | 30/09 | 2 JH | Faible | Inventaire comptes | En cours | Export MFA | Revue couverture |
| ACT-02 | Tests de restauration absents | Tester la restauration ERP | P1 | Infra | 15/10 | 1 JH | Aucun achat | Disponibilité environnement | À faire | Rapport test | Re-test annuel |
| ACT-03 | Revue des droits non démontrée | Réaliser la revue des accès critiques | P2 | DSI | 31/10 | 3 JH | Aucun achat | ACT-01 | À faire | CR + export | Contrôle anomalies |
| ACT-04 | Procédure incidents informelle | Formaliser et tester le processus | P2 | RSSI | 30/11 | 4 JH | À chiffrer | Disponibilité métiers | À faire | Procédure + exercice | RETEX |
Les valeurs sont uniquement illustratives.
Pour une utilisation réelle, ajoutez si nécessaire :
Prenons le cas de l’authentification.
Les comptes à privilèges doivent bénéficier d’un niveau d’authentification adapté à leur criticité.
Le MFA est activé sur la messagerie et l’accès VPN. Deux applications d’administration accessibles à distance utilisent encore une authentification par mot de passe uniquement.
La compromission du mot de passe d’un compte administrateur pourrait permettre un accès privilégié sans second facteur.
Étendre l’authentification multifacteur à tous les accès administratifs distants et mettre en place une règle de couverture homogène.
Risque à réduire.
Recenser tous les comptes et applications permettant une administration distante et identifier leur méthode d’authentification.
Activer le MFA sur les applications identifiées comme non couvertes.
Formaliser la règle imposant le MFA pour les accès administratifs et intégrer son contrôle à la revue des comptes privilégiés.
Responsable infrastructure.
P1 en raison de la nature privilégiée des accès et de leur exposition distante.
À chiffrer après inventaire.
À déterminer selon les capacités MFA des applications concernées.
Cette formulation est préférable à un montant générique inventé.
L’action B dépend du résultat de l’action A et éventuellement du support MFA fourni par les applications.
Lors de la revue suivante :
Le constat initial devient ainsi une chaîne de décision traçable, pas une ligne oubliée dans un PDF.
Un audit de 100 exigences ne doit pas nécessairement produire 100 actions.
Regroupez les écarts partageant :
Constats :
Au lieu de cinq projets totalement indépendants :
Lot 1 — Inventaire
Lot 2 — Règles de gestion
Lot 3 — Séparation et MFA
Lot 4 — Revue périodique
Les liens entre le chantier et les cinq constats doivent néanmoins être conservés.
C’est cette traçabilité qui permettra ensuite de démontrer quelles conclusions d’audit ont été effectivement traitées.
Une recommandation est souvent trop générale pour être exécutée telle quelle.
Transformez-la en une ou plusieurs actions concrètes.
« Équipe IT » n’est pas toujours un propriétaire suffisamment précis.
Une personne ou une fonction doit être responsable de sa progression.
Le RSSI ne peut pas devenir propriétaire de chaque correctif technique, processus RH, achat fournisseur ou décision métier.
Il peut coordonner le plan sans réaliser toutes les remédiations.
La priorité et la capacité d’exécution diffèrent.
Les dépendances doivent être prises en compte.
Les quick wins sont intéressants, mais ils ne doivent pas repousser les actions réellement importantes uniquement parce qu’elles sont difficiles.
« Fait » ne constitue pas une preuve.
Le statut doit être associé à un critère de validation.
Conservez l’historique.
Le NIST prévoit d’ailleurs que la réévaluation mette à jour l’état du dispositif sans effacer nécessairement les résultats initiaux de l’évaluation.
Une correction peut :
La clôture technique ne signifie donc pas automatiquement que le sujet est terminé du point de vue de la gouvernance.
À la fin de cette étape, l’organisation devrait disposer de cinq éléments cohérents.
Il conserve les constats et conclusions d’origine.
Il traduit les constats retenus en décisions et actions.
Il documente notamment :
Il permet de retrouver ce qui justifie réellement les statuts.
Il démontre que les corrections restent effectives dans le temps.
Le rapport et le plan d’action ne doivent pas se concurrencer.
Le rapport décrit la photographie initiale.
Le plan d’action raconte ce qui a été décidé et réalisé ensuite.
CompliKey permet de conserver la continuité entre l’évaluation et la remédiation :
audit → constat → action → responsable → échéance → preuve → avancement.
Les observations et écarts restent reliés aux mesures évaluées.
Le consultant ou le RSSI n’a donc pas besoin de reconstruire manuellement le contexte de l’action dans un second fichier.
Le rapport de démonstration CompliKey présenté précédemment illustre déjà la première partie de cette logique : chaque mesure auditée est reliée à son score, son commentaire, ses preuves et ses remédiations, puis les observations et recommandations sont regroupées dans un plan de remédiation.
Une recommandation peut ensuite être suivie opérationnellement avec :
L’intérêt est de ne pas recopier les conclusions du rapport dans un nouveau tableur.
La preuve initiale répond à :
Pourquoi avons-nous conclu à cet écart ?
La preuve de clôture répond à :
Qu’est-ce qui démontre que la situation a changé ?
Ces deux types de preuves ne doivent pas être confondus.
Le plan d’action peut continuer à vivre après la livraison du rapport :
Cette continuité est particulièrement utile pour les consultants et RSSI externalisés qui transforment un audit ponctuel en accompagnement récurrent.
CompliKey ne détermine pas automatiquement :
Ces décisions nécessitent le contexte de l’organisation et le jugement du consultant, du RSSI et des responsables métier.
La plateforme sert à structurer et tracer la décision, pas à remplacer cette décision.
Le rapport de démonstration CompliKey présente aujourd’hui les observations et recommandations du plan de remédiation.
Pour rendre la chaîne de pilotage encore plus explicite dans le livrable lui-même, une évolution pertinente serait d’y faire apparaître, pour les actions retenues :
Le rapport deviendrait ainsi non seulement une restitution d’audit, mais aussi un véritable point d’entrée vers le suivi post-audit.
Un audit ne crée de valeur durable que lorsque ses conclusions provoquent des décisions.
La méthode consiste à ne pas confondre :
constat → risque → recommandation → action.
Pour chaque action, documentez ensuite :
Le NIST comme les recommandations opérationnelles de l’ANSSI convergent sur cette logique : les écarts doivent alimenter un plan de remédiation piloté, et les corrections doivent être suivies puis vérifiées.
La prochaine action après un audit n’est donc pas :
« envoyer le rapport ».
C’est :
attribuer les premières remédiations, fixer leurs échéances et définir dès maintenant comment leur clôture sera démontrée.
Un constat décrit une situation observée par rapport à un critère ou à un objectif. L’action corrective décrit le travail réellement décidé pour traiter cette situation ou sa cause. Entre les deux se trouvent généralement l’analyse du risque et la recommandation de l’auditeur. Une même action peut traiter plusieurs constats partageant une cause commune et, inversement, un constat complexe peut nécessiter plusieurs actions successives.
Un plan d’action cybersécurité devrait au minimum préciser le constat d’origine, l’action à réaliser, son responsable, sa priorité, son échéance et son statut. Pour un pilotage plus robuste, ajoutez l’effort, le coût, les dépendances, la preuve de clôture et le contrôle d’efficacité. Le NIST inclut notamment tâches, ressources, jalons et échéances dans sa définition du POA&M, tandis que le ReCyF prévoit au minimum un responsable et une échéance raisonnable.
Ne classez pas uniquement les recommandations selon leur score de maturité ou leur difficulté. Évaluez le risque, l’exposition, la criticité du service, l’urgence, les mesures compensatoires, les dépendances et les ressources disponibles. Les actions simples peuvent être réalisées rapidement, mais elles ne doivent pas retarder une remédiation plus complexe portant sur un risque majeur. Le NIST recommande une priorisation liée au contexte métier et au processus de gestion des risques.
Le propriétaire doit être la personne ou la fonction capable de faire progresser l’action et d’en répondre. Le RSSI peut coordonner la feuille de route sans être responsable de toutes les remédiations. Une action IAM pourra appartenir au responsable IT, une sensibilisation aux RH et une décision budgétaire à la direction. Les contributeurs peuvent être multiples, mais il est préférable de conserver un responsable principal clairement identifié.
La preuve dépend du résultat attendu : configuration après correction, rapport de test, procédure approuvée, export d’habilitations revu, ticket accompagné d’un contrôle technique ou compte rendu d’exercice. Elle doit démontrer le résultat de l’action et non simplement son lancement. Il est préférable de définir cette preuve dès la création de l’action afin d’éviter des clôtures fondées uniquement sur une déclaration du responsable.
Oui lorsque le risque ou la nature de la mesure le justifie. Une preuve de clôture démontre que l’action prévue a été réalisée ; un contrôle d’efficacité vérifie que le dispositif fonctionne réellement et continue de produire l’effet attendu. Le NIST RMF prévoit explicitement de réévaluer les contrôles remédiés pour vérifier leur bonne mise en œuvre, leur fonctionnement et le résultat de sécurité obtenu.
Reliez chaque constat aux actions, responsables, échéances, preuves et validations nécessaires pour suivre réellement les progrès après l’audit.
Voir comment CompliKey transforme les écarts en actions pilotables
Source interne CompliKey : rapport « Audit interne – CompliKey Démo », utilisé pour vérifier la structure actuelle reliant mesures, scores, preuves, observations et recommandations dans le rapport d’audit.
