Lire NIS2 autrement à la lumière d’un sociologue des risques
Le 26 mai 2026, le NIS Cooperation Group a annoncé l’adoption de modèles communs de déclaration d’incident dans le cadre de la directive NIS2. L’objectif affiché est clair : proposer un format plus uniforme pour les organisations concernées, en particulier celles qui opèrent dans plusieurs pays européens. La Commission européenne présente cette harmonisation comme une mesure de simplification destinée à réduire la charge administrative et à faciliter le traitement des incidents transfrontaliers.
À première vue, le sujet semble technique : des formulaires, des délais, des champs à remplir, des autorités à prévenir. Pourtant, il touche à une question beaucoup plus profonde : comment penser la sécurité dans des systèmes numériques devenus si complexes qu’aucun acteur ne peut en maîtriser seul toutes les interactions ?
C’est ici qu’un sociologue publié en 1984 devient étonnamment actuel. Dans Normal Accidents: Living with High-Risk Technologies, Charles Perrow défend une idée dérangeante : dans certains systèmes très complexes, les accidents graves ne sont pas seulement des anomalies, des fautes ou des échecs individuels. Ils peuvent devenir des conséquences prévisibles de la structure même du système.
Lire NIS2 avec Perrow, ce n’est donc pas dire que la régulation est inutile. C’est apprendre à distinguer ce qu’elle peut faire — rendre visible, coordonner, responsabiliser — et ce qu’elle ne peut pas promettre : supprimer totalement le risque dans des infrastructures numériques interconnectées, rapides et dépendantes les unes des autres.
La thèse de Perrow : quand l’accident cesse d’être exceptionnel
Charles Perrow analyse des catastrophes industrielles, notamment dans le nucléaire, la chimie ou l’aéronautique, non comme de simples erreurs humaines, mais comme des événements systémiques.
Son idée centrale tient en deux notions : la complexité interactive et le couplage serré.
Dans un système à forte complexité interactive, les composants ne s’enchaînent pas de façon simple et linéaire. Ils interagissent de manière parfois imprévisible. Une panne mineure peut provoquer une cascade d’effets, parce que personne ne peut anticiper toutes les combinaisons possibles.
Dans un système étroitement couplé, les marges de manœuvre sont faibles. Les réactions doivent être rapides. Il y a peu de temps pour isoler l’erreur, la comprendre, la corriger ou empêcher sa propagation.
Lorsque ces deux dimensions se combinent, l’accident devient difficile à éliminer totalement. On peut en réduire la probabilité, en limiter les effets, en améliorer la détection. Mais prétendre atteindre le risque zéro relève davantage du récit rassurant que de l’analyse réaliste.
Pourquoi cette grille parle au monde numérique
Les réseaux numériques contemporains ressemblent de plus en plus aux systèmes décrits par Perrow.
Une entreprise dépend rarement d’un seul serveur ou d’une seule application. Elle repose sur du cloud, des identités fédérées, des prestataires externes, des logiciels tiers, des API, des outils de supervision, des sauvegardes, des chaînes d’approvisionnement logicielles et des droits d’accès imbriqués.
Cette architecture permet une efficacité considérable. Mais elle crée aussi des vulnérabilités systémiques.
Un fournisseur compromis peut affecter des centaines de clients. Une mise à jour défectueuse peut se propager en quelques heures. Un compte administrateur mal protégé peut ouvrir l’accès à un ensemble beaucoup plus large que prévu. Un ransomware peut toucher les sauvegardes si elles sont trop fortement synchronisées au système principal.
Le numérique est donc à la fois puissant et fragile. Sa vitesse, son interconnexion et son optimisation permanente réduisent parfois les délais de réaction. Plus l’infrastructure est fluide en temps normal, plus une crise peut se diffuser rapidement.
Ce que NIS2 cherche à rendre visible
La directive NIS2 vise à renforcer le niveau commun de cybersécurité dans l’Union européenne. Elle élargit le champ des secteurs concernés, insiste sur la gestion des risques, la responsabilité des entités essentielles ou importantes, et la déclaration des incidents significatifs. L’ENISA rappelle que NIS2 s’inscrit dans une continuité avec la première directive NIS, tout en consolidant les obligations de notification et de gestion des incidents.
Dans ce cadre, les modèles communs annoncés le 26 mai 2026 répondent à un besoin concret : éviter qu’une organisation transfrontalière doive déclarer un même incident selon des formats trop différents d’un État membre à l’autre.
La simplification n’est donc pas secondaire. En situation de crise, le temps passé à comprendre quel formulaire remplir, dans quelle langue, avec quels champs et selon quelle logique peut aggraver la confusion.
Harmoniser les modèles, c’est améliorer la lisibilité. C’est aussi faciliter la comparaison des incidents, la coordination entre autorités et la construction d’une mémoire commune.
Mais Perrow nous invite à ne pas confondre visibilité administrative et résilience réelle.
Harmoniser les formulaires ne suffit pas à supprimer les accidents
Un formulaire bien conçu peut aider à déclarer un incident. Il ne garantit pas que l’organisation était prête avant l’incident.
Une entreprise peut être conforme sur le papier tout en restant fragile dans ses architectures profondes : dépendance à un fournisseur unique, sauvegardes insuffisamment isolées, droits d’accès mal segmentés, absence de tests réguliers de restauration, cartographie incomplète des actifs critiques.
C’est l’un des apports essentiels de Perrow : il déplace l’attention de la faute individuelle vers la structure du système.
La question n’est pas seulement : « Qui a mal rempli le formulaire ? »
Elle devient : « Quelle architecture a permis à l’incident de se propager aussi vite ? »
Cette distinction est décisive. Une organisation peut améliorer sa documentation sans réduire suffisamment ses interdépendances. Elle peut produire des rapports sérieux sans avoir testé ses scénarios de crise. Elle peut respecter un délai de notification sans disposer d’une véritable capacité de reprise.
La responsabilité individuelle a ses limites
NIS2 renforce aussi la responsabilité des dirigeants et prévoit des mécanismes de supervision et de sanction. Cette logique peut être utile : sans incitation forte, certaines organisations repoussent les investissements de cybersécurité, surtout lorsqu’ils sont coûteux, peu visibles ou difficiles à valoriser à court terme.
Mais Perrow mettrait en garde contre un réflexe trop simple : croire qu’il suffit de désigner un responsable pour comprendre l’accident.
Dans les systèmes complexes, l’erreur humaine existe, mais elle n’explique pas tout. Elle est souvent le dernier maillon visible d’une chaîne plus longue : arbitrages budgétaires, dépendances techniques, pression de performance, manque de redondance, complexité organisationnelle, dette informatique, sous-traitance opaque.
Punir un dirigeant ou un responsable sécurité peut parfois être nécessaire. Mais cela ne remplace pas le travail plus difficile : réduire les dépendances critiques, segmenter les systèmes, tester les restaurations, construire une culture de crise, documenter les interconnexions et accepter que la sécurité n’est pas un état, mais un processus.
La transparence : utile, mais pas magique
Les obligations de notification ont une vertu importante : elles empêchent l’incident de rester entièrement dans l’ombre.
Un incident déclaré peut être analysé, comparé, partagé, intégré à une mémoire collective. Les autorités peuvent repérer des tendances, alerter d’autres acteurs, mesurer les vulnérabilités sectorielles. Les organisations peuvent apprendre des crises des autres au lieu de répéter les mêmes erreurs.
Mais la transparence post-incident n’est pas une garantie suffisante.
Si un système concentre trop de risques, si les dépendances critiques sont mal connues, si les plans de continuité ne sont jamais testés, si les sauvegardes sont vulnérables aux mêmes attaques que les systèmes principaux, alors la déclaration arrive après la fragilité.
Elle permet de voir. Elle ne suffit pas à réparer ce qui a été mal conçu.
Transposer Perrow au cyber : une lecture utile, mais à nuancer
La comparaison entre les catastrophes industrielles étudiées par Perrow et les incidents cyber contemporains doit rester prudente.
Un accident nucléaire, chimique ou aéronautique n’a pas la même matérialité qu’une attaque informatique. Dans le numérique, certaines atteintes peuvent être contenues, restaurées ou corrigées. Les architectures évoluent plus vite. Les correctifs logiciels, les solutions de détection et les outils de supervision progressent rapidement.
Autre différence majeure : Perrow s’intéressait surtout aux défaillances systémiques, tandis que la cybersécurité implique souvent des acteurs malveillants. Le ransomware, l’espionnage, le sabotage ou l’attaque de chaîne d’approvisionnement ajoutent une dimension stratégique : quelqu’un cherche activement la faille.
Mais cette différence ne rend pas Perrow obsolète. Au contraire, elle renforce parfois sa pertinence. Un attaquant exploite précisément les zones de complexité, les angles morts, les dépendances cachées et les couplages trop serrés.
La menace est intentionnelle, mais la propagation reste souvent systémique.
Quatre questions pour lire NIS2 avec Perrow
La pensée de Perrow peut devenir une grille pratique pour interroger les annonces européennes.
Première question : où se trouve le couplage serré dans mon organisation ?
Cloud, authentification unique, prestataires critiques, outils de sauvegarde, annuaires, chaînes CI/CD, solutions de supervision : quels éléments peuvent propager une crise plus vite qu’elle ne peut être comprise ?
Deuxième question : que voyons-nous réellement avant l’incident ?
Un inventaire incomplet, une cartographie obsolète ou des accès mal documentés transforment la crise en enquête improvisée. Or, en cybersécurité, ce que l’on découvre pendant l’incident aurait souvent dû être connu avant.
Troisième question : le formulaire sert-il l’apprentissage ou seulement la conformité ?
Un modèle commun peut devenir un outil de mémoire collective. Mais il peut aussi devenir une simple case administrative si les organisations remplissent les champs sans tirer de leçons structurelles.
Quatrième question : confondons-nous conformité et résilience ?
Être conforme, c’est répondre à une exigence réglementaire. Être résilient, c’est être capable d’absorber un choc, de limiter sa propagation, de restaurer les fonctions essentielles et d’apprendre de l’événement.
Les deux dimensions peuvent se renforcer. Mais elles ne sont pas identiques.
Ce que cette lecture apporte au Sentier du Savoir
Dans le Sentier du Savoir, cet article relève d’un apprentissage central : comprendre les systèmes avant de juger les événements.
L’actualité nous donne souvent des faits isolés : un communiqué, une directive, une déclaration, une sanction, une faille, une attaque. Le rôle du lecteur éclairé est de relier ces faits à des cadres d’analyse plus profonds.
Charles Perrow permet précisément ce déplacement. Il ne remplace pas la lecture juridique de NIS2. Il l’élargit. Il montre que derrière un formulaire de déclaration se cache une question de société : comment gouverner des infrastructures dont la complexité dépasse la perception ordinaire ?
Cette lecture invite aussi à résister à deux récits trop simples.
Le premier récit dit : « Avec assez de règles, il n’y aura plus d’accidents. »
Le second répond : « Puisqu’il y aura toujours des accidents, les règles ne servent à rien. »
Perrow aide à sortir de cette opposition. Les règles sont nécessaires, mais elles doivent être pensées comme des instruments de visibilité, de coordination et d’apprentissage — non comme des promesses de sécurité absolue.
Conclusion : accepter le risque pour mieux le gouverner
Les « accidents normaux » ne signifient pas que tout est perdu. Ils signifient que certains risques sont produits par les systèmes mêmes que nous construisons.
Dans le numérique, cette idée est essentielle. Nous avons bâti des infrastructures rapides, interconnectées, optimisées, dépendantes de multiples acteurs. Elles soutiennent nos hôpitaux, nos transports, nos administrations, nos entreprises, nos communications. Mais cette puissance a un revers : l’incident local peut devenir systémique.
Les modèles communs de déclaration NIS2 annoncés le 26 mai 2026 constituent donc une avancée utile. Ils peuvent simplifier les démarches, rendre les incidents plus lisibles, améliorer la coordination européenne.
Mais ils ne doivent pas nourrir une illusion : celle d’une cybersécurité réduite à des formulaires bien remplis.
Lire NIS2 avec Charles Perrow, c’est comprendre que la vraie question n’est pas seulement de déclarer l’accident. C’est de savoir pourquoi il pouvait se produire, comment il s’est propagé, quelles dépendances l’ont rendu possible, et ce que l’on accepte enfin d’apprendre de lui.
Dans un monde numérique complexe, la sécurité absolue est un mythe. La résilience, elle, peut devenir une méthode.
Repères de sources
- Charles Perrow, *Normal Accidents: Living with High-Risk Technologies*, Basic Books, 1984 (rééditions et traductions partielles en français sous le titre *Accidents normaux*).
- Charles Perrow, *The Next Catastrophe: Reducing Our Vulnerabilities to Natural, Industrial, and Terrorist Disasters*, Princeton University Press, 2007.
- Synthèse pédagogique (accès libre) : Stanford Encyclopedia of Philosophy — Risk (contexte philosophique du risque systémique).
Dans ce triptyque
Pour voir comment cette grille de lecture éclaire le sujet du jour :
- Revenir à l’actualité : NIS2 : quand Bruxelles harmonise les déclarations d’incident cyber — et que la contrainte se durcit au printemps 2026
- Prolonger avec le Sentier du Savoir : Décoder un formulaire de déclaration cyber européen : délais, champs et vocabulaire institutionnel
Vous devez être connecter pour pouvoir voter
