Tracer les décisions : qui a décidé quoi, quand, sur quelle base

Un incident de sécurité survient. Les autorités compétentes demandent de démontrer que l’organisation a bien évalué et documenté les risques avant l’incident, et que les mesures appliquées étaient proportionnées. Ou une décision prise il y a dix-huit mois est contestée en interne : pourquoi a-t-on choisi ce fournisseur, qui a validé cette dérogation, sur quelle base a-t-on estimé le risque acceptable ? La traçabilité des décisions répond à ces questions, mais elle ne se construit pas après l’incident.

Ce que les cadres réglementaires imposent

La demande de traçabilité des décisions s’est renforcée dans plusieurs textes réglementaires récents. NIS 2, dont la transposition nationale était due le 17 octobre 2024, impose aux entités essentielles et importantes de démontrer à leurs autorités compétentes la bonne mise en œuvre des mesures de gestion des risques, ce qui suppose une documentation des décisions de risque. DORA (en vigueur depuis le 17 janvier 2025) impose dans le secteur financier des exigences de gouvernance documentée sur les risques informatiques, les prestataires tiers et les incidents. L’AI Act, dont les dispositions sur les systèmes d’IA à haut risque entrent progressivement en vigueur, exige une documentation de la conception et des décisions de déploiement pour ces systèmes.

Ces exigences ne demandent pas de tracer toutes les décisions, mais certaines catégories bien précises. Le point de départ est donc l’inventaire des décisions qui entrent dans le périmètre de chaque cadre applicable.

Ce qu’une trace de décision doit contenir

Une trace de décision utile contient cinq éléments.

L’identifiant et le sujet : une référence unique et un libellé qui permet de retrouver la décision par sujet ou par date, sans lire le détail.

Le décideur et la date : qui a pris la décision (une personne nommée, pas seulement un comité) et quand. Pour les décisions collectives, le président du comité ou le responsable signataire.

Le contexte et les options considérées : c’est l’élément le plus souvent absent. Une trace qui dit seulement « décision : accepter le risque X » sans indiquer pourquoi et quelles alternatives ont été écartées n’a qu’une valeur limitée. Les auditeurs regardent le contexte, pas seulement la décision finale.

La base de la décision : les éléments factuels (mesures de risque, résultats de tests, analyses d’impact), les contraintes (budget, délai, dépendances) et les critères retenus.

Le statut et les révisions : une décision peut être révisée. La trace doit documenter les révisions successives, avec leurs dates et motifs.

• Identifier les catégories de décisions à tracerSécurité, conformité, contractuel, achats, architecture SI, risque accepté
• Choisir le support et le formatWiki, tableau partagé, outil GRC ou module de gestion des décisions
• Définir qui alimente et qui validePropriétaire du processus concerné, avec revue périodique
• Intégrer la mise à jour dans les processus existantsChange management, comités de pilotage, revues de risque
• Tester la retrouvabilité régulièrementSimuler une demande d’audit : peut-on retrouver la décision en moins de 30 minutes ?

Les erreurs les plus fréquentes

La première est de créer un registre exhaustif qui documente tout, y compris les décisions sans enjeu, jusqu’à ce qu’il devienne trop volumineux pour être consulté. Mieux vaut un registre ciblé sur les décisions significatives, tenu à jour, que l’encyclopédie complète abandonnée après six mois.

La deuxième est de confondre documentation et traçabilité. Un compte rendu de réunion documente ce qui s’est dit. Un registre de décisions documente ce qui a été décidé, par qui, et pourquoi. Les deux sont utiles mais ne se substituent pas l’un à l’autre.

La troisième est d’oublier les décisions informelles. Certaines des décisions les plus importantes d’une organisation sont prises en couloir, par e-mail ou en bilatérale. Si elles n’entrent pas dans le registre, elles n’existent pas pour un auditeur.

• Les catégories de décisions à tracer sont définies et connues des équipes concernées
• Chaque entrée du registre contient le contexte et les options considérées, pas seulement la décision finale
• Le décideur est nommé (une personne, pas seulement un comité)
• La mise à jour du registre est intégrée dans les processus existants (changements en production, revues de risque)
• Un responsable de la tenue du registre est nommé
• La retrouvabilité est testée périodiquement

Notre expertise en cybersécurité et conformité accompagne la mise en place des processus de gouvernance documentée requis par NIS 2, DORA et l’AI Act. Pour les outils de pilotage et de traçabilité, notre offre Gouvernance propose les cadres adaptés.

Questions fréquentes

Quelles décisions doivent absolument être tracées ?

En premier lieu : les décisions qui engagent la sécurité, la conformité ou la responsabilité de l'organisation (décisions de risque accepté, dérogations à une politique, modifications d'un système critique, changements de configuration en production). Les cadres réglementaires comme NIS 2 et DORA précisent leurs exigences propres.

Quelle est la différence entre un registre de décisions et un compte rendu de réunion ?

Un compte rendu documente ce qui s'est passé dans une réunion. Un registre de décisions documente la décision elle-même (quoi, qui, quand, options considérées, critères retenus), indépendamment du format dans lequel elle a été prise. Une décision prise par e-mail ou en couloir doit figurer dans le registre si elle est significative.

Combien de temps conserver les traces de décision ?

La durée dépend de la nature de la décision et du cadre réglementaire. Pour une décision de sécurité, NIS 2 n'impose pas de durée explicite mais demande la capacité de démontrer la conformité à tout moment de contrôle. Pour une décision contractuelle, les délais de prescription civile (en France, 5 ans en général) sont un repère. Pour des décisions liées à des données personnelles, les délais de conservation de la trace doivent être documentés dans le registre RGPD.

Un outil spécialisé est-il nécessaire ?

Non. Un tableau partagé ou une page wiki peut suffire pour les organisations qui débutent. Ce qui compte, c'est la discipline de mise à jour et la capacité à retrouver une décision par son sujet ou sa date. Un outil GRC ou un module de gouvernance peut apporter de la structure et des workflows de validation, mais ne remplace pas la culture de la décision documentée.