Gouvernance et gestion des risques

Pourquoi ce chapitre déplace le sujet

La cybersécurité a longtemps été traitée comme un problème technique confié à une direction informatique, avec un reporting annuel poli et sans conséquence réelle pour qui l'a rédigé. NIS2 rompt avec ce schéma. L'article 20 de la directive impose explicitement que les organes de direction des entités concernées approuvent les mesures de gestion des risques et supervisent leur mise en œuvre — et qu'ils puissent être tenus responsables des manquements. La transposition française via ReCyF reprend cette logique et l'articule avec le régime de sanctions existant.

Ce déplacement n'est pas cosmétique. Il signifie qu'un dirigeant ne peut plus se contenter de déléguer intégralement le sujet et de découvrir un incident par la presse. Il doit pouvoir démontrer qu'il a été informé, qu'il a arbitré, et que les moyens alloués étaient proportionnés au risque identifié. C'est cette chaîne de décision documentée que ce chapitre décrit.

L'approbation par l'organe de direction n'est pas une formalité de façade. Un simple email de validation sans trace des éléments présentés, des alternatives écartées et du raisonnement budgétaire ne constitue pas une preuve de gouvernance effective au sens de la directive. En cas de contrôle, c'est la qualité de cette trace qui est examinée, pas seulement son existence.

Ce que l'organe de direction doit réellement faire

La directive distingue trois obligations pour les dirigeants, qui se recoupent partiellement avec ce qu'exige ReCyF au niveau national :

1. Approuver les mesures de gestion des risques cybersécurité — pas les valider a posteriori, mais les arbitrer en amont, avec un niveau de détail suffisant pour comprendre les compromis effectués.
2. Superviser leur mise en œuvre, ce qui suppose un reporting régulier et compréhensible, pas un tableau de bord technique illisible pour des non-spécialistes.
3. Se former — NIS2 impose une formation périodique des membres de l'organe de direction aux risques cybersécurité, formalisée et documentée.

Le troisième point surprend souvent les organisations qui découvrent la directive tardivement : ce n'est pas seulement le RSSI qui doit monter en compétence, c'est le comité de direction lui-même. Un administrateur qui ne comprend pas la différence entre un ransomware et une fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire n'est plus en mesure d'exercer une supervision effective, et l'absence de formation documentée est en soi un facteur aggravant en cas d'incident.

Une ETI industrielle soumise à NIS2 organise chaque trimestre une session d'une heure où le RSSI présente au comex trois indicateurs simples : le taux de correctifs critiques appliqués sous 30 jours, le nombre d'incidents ayant déclenché une procédure d'astreinte, et l'avancement du plan de continuité d'activité. Chaque session est actée par un compte rendu signé. Cette cadence légère mais régulière constitue une preuve de supervision bien plus solide qu'un rapport annuel de cinquante pages jamais discuté en réunion.

RSSI : exécutant mandaté, pas responsable ultime

Le RSSI reste la cheville ouvrière opérationnelle, mais NIS2 clarifie un point souvent flou dans les organisations : le RSSI conçoit, met en œuvre et alerte, il ne porte pas seul la responsabilité finale. Cette distinction protège paradoxalement le RSSI autant qu'elle engage la direction — un RSSI qui a alerté par écrit sur un risque non traité, sans que la direction n'ait arbitré ni motivé son refus, dispose d'une trace qui le dégage largement en cas d'incident.

Cela suppose en pratique que le RSSI dispose de trois choses que beaucoup d'organisations ne lui donnent pas encore :

• Un accès direct et régulier à l'organe de direction, sans filtrage systématique par la DSI ou la direction générale.
• Une autorité formelle pour documenter ses alertes, y compris quand elles restent sans suite.
• Un budget dont il connaît l'enveloppe en amont de l'année, et non négocié ligne par ligne au fil de l'eau.

Un schéma organisationnel fréquent et fragile illustre ce point : le RSSI rapporte hiérarchiquement au DSI, qui rapporte lui-même à la direction générale. En cas d'arbitrage entre un projet de transformation numérique porté par le DSI et une mesure de sécurité qui ralentit ce projet, le RSSI se retrouve en position de subordonné face à son propre arbitre. NIS2 n'impose pas un rattachement hiérarchique précis, mais les régulateurs examinent de près les situations où le reporting sécurité transite intégralement par une fonction ayant un intérêt potentiellement contraire.

Cette dépendance hiérarchique n'est pas rédhibitoire en soi : de nombreuses organisations fonctionnent avec un RSSI rattaché à la DSI sans dysfonctionnement majeur. Ce qui doit exister en complément est un canal alternatif — accès direct au comex sur les sujets d'arbitrage sensibles, ou rattachement fonctionnel à un comité des risques indépendant de la ligne hiérarchique opérationnelle. L'essentiel est qu'aucune alerte documentée ne puisse rester bloquée à un seul niveau hiérarchique sans traçabilité de son traitement.

Construire une politique de sécurité opposable

Une politique de sécurité de l'information n'est pas un document de principes généraux téléchargé et adapté à la marge. Pour être opposable — c'est-à-dire pour pouvoir servir de référence en cas de contrôle ou de litige interne — elle doit remplir plusieurs conditions cumulatives :

La colonne « déclinable par métier » est souvent le point faible des politiques rédigées trop vite. Une politique qui énonce « les donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sensibles doivent être protégées » sans préciser ce qu'est une donnée sensible pour la production, pour les RH ou pour le commercial reste inapplicable — et donc, en pratique, inopposable.

Structurez la politique en deux niveaux distincts : un socle commun court (dix à quinze pages, principes et obligations générales) et des annexes métier plus longues, révisables indépendamment. Cela évite de devoir refaire approuver l'ensemble du document par la direction à chaque ajustement opérationnel mineur, tout en gardant une trace de révision propre à chaque annexe.

Le budget : sortir de la logique de reliquat

Dans beaucoup d'organisations, le budget cybersécurité est historiquement ce qui reste après l'arbitrage des projets métier — une variable d'ajustement plutôt qu'une ligne pilotée par le risque. NIS2 rend cette logique intenable, car elle exige une preuve de proportionnalité entre le niveau de risque identifié et les moyens alloués. Un budget en baisse alors que la cartographie des risques signale une aggravation constitue en soi un indice de manquement à l'obligation de supervision.

La méthode attendue par les régulateurs se rapproche de celle utilisée en gestion des risques financiers :

1. Cartographier les risques (menaces, vulnérabilités, impact potentiel) — voir le chapitre consacré à l'analyse de risques.
2. Traduire chaque risque majeur en options de traitement : accepter, réduire, transférer, éviter.
3. Chiffrer le coût de chaque option de réduction et le comparer à l'impact évité.
4. Faire arbitrer ce choix par la direction, avec traçabilité du raisonnement — y compris quand le choix est de ne rien faire.

Un risque accepté sciemment, documenté et motivé, n'est pas une faute de gouvernance. C'est au contraire l'exercice normal de l'arbitrage attendu par la directive. Ce qui pose problème n'est pas l'acceptation du risque, mais son absence de traçabilité — un risque non traité parce que personne n'en a jamais formellement décidé.

Cette logique implique aussi un changement de vocabulaire en interne : on ne demande plus « combien coûte la sécurité », mais « combien coûte le risque non traité ». Ce recadrage facilite paradoxalement les arbitrages budgétaires, car il replace la décision sur un terrain que la direction générale maîtrise déjà — l'analyse coût-bénéfice — plutôt que sur un terrain technique où elle se sent démunie.

Accountability : ce qu'il faut pouvoir produire en cas de contrôle

L'accountability, au sens de NIS2, ne se limite pas à « avoir fait les choses bien ». Elle consiste à pouvoir le démontrer a posteriori, souvent plusieurs mois ou années après les faits. Un registre de preuves solide doit permettre de reconstituer, pour n'importe quel risque majeur identifié :

• Quand le risque a été identifié et par qui.
• Quelles options ont été présentées à la direction, avec leurs coûts respectifs.
• Quelle décision a été prise, par qui, et à quelle date.
• Quels moyens ont effectivement été alloués et déployés.
• Comment la mise en œuvre a été vérifiée dans le temps.

Ce registre n'a pas besoin d'un outil dédié coûteux pour démarrer : un tableau structuré, versionné et accessible en lecture aux personnes concernées suffit dans une organisation de taille moyenne. Ce qui compte est la discipline de mise à jour, pas la sophistication de l'outil.

Ne confondez pas accountability et volume documentaire. Un registre de deux cents pages que personne ne relit jamais n'est pas une preuve de gouvernance, c'est un point de fragilité supplémentaire — en cas de contrôle, un régulateur peut légitimement questionner pourquoi un risque documenté n'a jamais donné lieu à décision explicite. Mieux vaut un registre court, à jour et effectivement consulté en comité, qu'un registre exhaustif mais mort.

Sanctions et responsabilité personnelle

La directive introduit une nouveauté par rapport au régime antérieur : la possibilité, pour les entités essentielles, d'engager la responsabilité personnelle des dirigeants en cas de manquement grave et répété aux obligations de gestion des risques, en complément des sanctions financières visant l'entité elle-même. Ce n'est pas systématique, et cela suppose généralement une négligence caractérisée — l'absence totale de dispositif de gouvernance, ou l'ignorance délibérée d'alertes documentées.

Cette possibilité change néanmoins la nature de l'incitation. Elle transforme la conformité d'un sujet de conformité réglementaire générique en un sujet d'intérêt personnel direct pour les décideurs, ce qui explique en partie pourquoi les comités de direction s'emparent désormais du sujet avec un sérieux inédit.

Checklist de mise en conformité gouvernance

• L'organe de direction a formellement approuvé une politique de gestion des risques cybersécurité, datée et signée.
• Une cadence de reporting sécurité vers la direction existe et est respectée (trimestrielle a minima).
• Les membres de l'organe de direction suivent une formation cybersécurité documentée.
• Le RSSI dispose d'un accès direct à la direction, hors filtrage systématique par une fonction en conflit d'intérêt potentiel.
• Le budget sécurité est justifié par une cartographie des risques actualisée, pas reconduit par défaut.
• Un registre de preuves trace les décisions, options écartées et risques acceptés.
• La politique de sécurité est déclinée par direction métier, avec accusé de réception.
• Les risques acceptés sans traitement sont explicitement motivés et datés.

Ce qu'il faut retenir

La gouvernance attendue par NIS2 et ReCyF déplace le centre de gravité de la conformité cybersécurité vers l'organe de direction, sans pour autant dépouiller le RSSI de son rôle d'exécution technique. La clé de voûte du dispositif est la traçabilité des décisions : ce qui protège l'organisation et ses dirigeants n'est pas l'absence d'incident, mais la capacité à démontrer qu'un processus de décision informé, régulier et documenté a existé avant l'incident. Le chapitre suivant approfondit la méthode d'analyse de risques qui alimente concrètement ce processus décisionnel.