Depuis janvier, Plan R a traité le « quoi » : dépendances, chaîne d’approvisionnement, données, souveraineté, identité. Puis le « comment » : automatisation, IA, équilibre entre l’humain et la machine. Le quatrième trimestre a déplacé le regard vers la gouvernance. Une question a été contournée : qui porte tout cela jusqu’à la table où l’on décide ?

L’épisode 004 posait que la résilience est une décision politique. L’épisode 036 a montré que le dirigeant en répond désormais nommément, et qu’une délégation ne vaut que si le délégataire dispose d’autorité, de compétence et de moyens. L’épisode 037 rappelait qu’un conseil n’achète pas un indicateur, mais une position.

L’épisode 038 se terminait sur un constat : la résistance à découvrir qu’un partenaire ne tiendrait pas n’est pas technique, elle est humaine. Quelqu’un doit porter ce genre de constat devant ceux qui décident. Dans la plupart des organisations, c’est le CISO - ou le RSSI, le titre importe peu.

Or ce porteur est souvent placé deux ou trois niveaux sous la décision. On l’écoute pendant l’incident, on le consulte à la fin du projet, on le reçoit une fois par an. Cette chronique ne plaide pas pour une promotion. Elle cherche ce qui fait passer une parole du registre de l’avis technique à celui de l’arbitrage.

La vraie question n’est pas « à qui le CISO doit-il rendre compte ? ». C’est : « quand un arbitrage de résilience se joue, sa parole change-t-elle la décision ? »

1. Un plafond de verre fait de vocabulaire

Le scénario est familier à quiconque a exercé la fonction. Vingt minutes en fin d’ordre du jour. Un tableau de vulnérabilités, des voyants tricolores, un budget à défendre. Le comité remercie, pose une question sur la dernière attaque médiatisée, passe au point suivant.

Les chiffres sur la position réelle du CISO sont contradictoires, et cette contradiction est instructive. Le rapport 2026 d’IANS Research et Artico Search, portant sur 662 CISO, indique que 64 % d’entre eux rendent encore compte à la direction informatique, et 11 % seulement au directeur général.

L’enquête de Heidrick & Struggles publiée en février 2026, auprès de 371 CISO interrogés à l’été 2025, affiche au contraire 42 % de rattachements directs au directeur général, trois fois plus que l’année précédente. L’écart tient en partie aux échantillons : la seconde porte surtout sur de grandes entreprises et des profils de direction.

Deux photographies partielles, donc, pas une tendance établie. Ce qui converge, en revanche, c’est le discours : les deux études décrivent une fonction qui cesse d’être vue comme un sous-ensemble de l’informatique. Le mouvement est réel dans les intentions. Il l’est beaucoup moins dans les ordres du jour.

On trouve des CISO invités au comité. On en trouve rarement qui y font changer une décision.

Le plafond de verre du CISO n’est pas seulement fait d’organigramme. Il est fait de vocabulaire : tant qu’il parle de vulnérabilités, on le range avec la technique.

2. Le rattachement : un vrai sujet, mal posé

Le débat n’est pas futile. Un CISO placé sous la direction informatique évalue des risques dont une partie naît des choix de celui qui fixe ses objectifs. Le DSI est jugé sur la livraison et les coûts ; le CISO, sur des risques qui appellent souvent une dépense ou un délai. La tension est structurelle, pas personnelle.

Le secteur financier en a tiré une règle. L’article 6 du règlement DORA impose de confier la gestion et la surveillance du risque informatique à une fonction de contrôle dotée d’un niveau d’indépendance approprié, précisément pour éviter les conflits d’intérêts. NIS2, de son côté, fait remonter l’approbation des mesures à l’organe de direction (article 20).

Mais changer de case ne suffit pas. Un CISO rattaché au directeur général qui ne parle que de technologie obtiendra moins d’écoute qu’un CISO rattaché au DSI qui dispose d’un canal direct vers le comité des risques. Le critère posé dans l’épisode 036 - autorité, compétence, moyens - s’applique ici mot pour mot.

Trois garanties pèsent davantage que la position dans l’organigramme :

• un droit d’accès direct à la direction générale en cas de risque grave, sans filtre hiérarchique ;

• un budget identifié, arbitré distinctement de celui de l’informatique ;

• un droit d’escalade formalisé lorsque son avis n’est pas suivi, avec une trace écrite de l’arbitrage.

Le rattachement n’est pas un sujet d’organigramme. C’est un choix de gouvernance. Sans ces trois garanties, tout le reste est cosmétique.

L’organigramme donne une adresse. Il ne donne pas une voix. Ce qui donne une voix, c’est la garantie d’être entendu quand ça compte.

3. Changer de langue : le comité n’arbitre pas des menaces

Le Global Cybersecurity Outlook 2026 du Forum économique mondial le mesure. Les directeurs généraux placent en tête la fraude numérique et l’hameçonnage, puis les vulnérabilités liées à l’IA. Les CISO citent d’abord le rançongiciel, puis les ruptures de chaîne d’approvisionnement. Le rapport y lit des dirigeants tournés vers la perte financière, des CISO tournés vers la résilience opérationnelle.

L’épisode 037 y voyait un écart de vocabulaire. On peut aller plus loin : c’est un écart de grammaire. Le CISO décrit un état - exposition, conformité, menace. Le comité attend une décision - options, coûts, conséquences. Tant que le premier ne formule pas sa demande dans la syntaxe du second, il présente ; il n’influence pas.

Le NIST l’écrit sans détour dans le CSF 2.0 : le cadre aide à traduire la terminologie cyber dans le langage général de gestion des risques que les dirigeants comprennent. Sa fonction GOVERN demande que la gestion du risque cyber soit intégrée à la gestion des risques de l’entreprise (GV.RM-03).

Quelques traductions, à titre d’illustration :

Le comité n’arbitre pas des menaces. Il arbitre des options. Un CISO qui n’apporte pas d’options apporte un problème - et on finit par l’inviter moins souvent.

4. La posture : ni gardien, ni prophète, ni exécutant

Changer de langue ne suffit pas si la posture reste la même. Trois postures, répandues et compréhensibles, enferment le CISO dans le technique.

• Le gardien du temple. Il dit non, par principe et par prudence. Il gagne le respect, rarement l’invitation en amont des projets. On le contourne dès que l’enjeu devient commercial.

• Le prophète. Il mobilise par la peur. Cela fonctionne une fois. L’épisode 036 le notait : la peur mal calibrée produit de la conformité de façade.

• L’exécutant loyal. Il applique, n’escalade jamais, absorbe les arbitrages défavorables. Il est apprécié. Le jour de la crise, il découvre qu’il portait seul des risques que personne n’avait décidé d’accepter.

La posture qui ouvre la porte des arbitrages est celle du conseiller : il éclaire les options, recommande, et accepte d’être désavoué. À une condition non négociable : que le désaveu soit tracé. Un refus motivé et documenté protège mieux qu’un silence, et il protège tout le monde.

Le CSF 2.0 place d’ailleurs le principe au bon endroit : c’est la direction de l’organisation qui est responsable du risque cyber et qui en rend compte (GV.RR-01). Le CISO n’est pas le propriétaire du risque. Il est le garant que ce risque a été décidé en connaissance de cause.

Le CISO stratège ne cherche pas à avoir raison contre le comité. Il fait en sorte que le comité ne puisse plus décider sans savoir.

5. Les leviers qui font réellement bouger un comité

Un comité de direction ne change pas d’avis parce qu’on a raison. Il bouge sous l’effet de leviers précis. Cinq ont fait leurs preuves.

• La réglementation, utilisée comme trame. NIS2 et DORA ont rendu la direction nommément responsable. Brandie comme une menace, la règle crispe. Présentée comme la liste des arbitrages à documenter, elle structure l’ordre du jour.

• La crise, vécue ou simulée. L’épisode 035 le montrait pour la parole de crise : une demi-journée d’exercice avec le comité vaut dix présentations. Les dirigeants retiennent ce qu’ils ont eu à trancher eux-mêmes.

• La comparaison. Un chiffre isolé ne dit rien. Une position par rapport à son secteur, comme le proposait l’épisode 037, déclenche une réaction.

• Les alliés hors de l’informatique. Le guide de l’ANSSI et de l’AMRAE confie au risk manager la mission de rendre les scénarios de risque numérique intelligibles pour la direction. Finance, juridique et audit interne parlent déjà la langue du comité : ce sont des traducteurs, pas des concurrents.

• La régularité. Une présentation annuelle est un événement. Un point trimestriel, court, toujours bâti sur le même modèle, devient une habitude de gouvernance.

L’influence ne se gagne pas en une présentation brillante. Elle se construit dans la répétition d’échanges où le comité a appris que le CISO l’aide à décider.

6. Monter sans quitter la salle serveur

Il faut regarder aussi le risque inverse. Le CISO qui passe tout son temps en comité perd le contact avec ce qui fonde sa légitimité : la connaissance intime du système d’information, des équipes, des incidents. Un conseiller qui ne sait plus de quoi il parle est démasqué au premier incident sérieux.

La charge, elle, est déjà là. Selon le rapport IANS—Artico 2026, 52 % des CISO estiment que leur périmètre n’est plus entièrement gérable. Ajouter la dimension stratégique sans rien retirer, c’est organiser l’épuisement.

La réponse n’est pas de choisir entre les deux registres. Elle consiste à organiser la délégation technique : un responsable de la sécurité opérationnelle, une fonction GRC solide, des relais dans les métiers. Le CISO garde la vision d’ensemble et le pouvoir d’alerte ; il ne porte plus seul l’exécution.

C’est aussi une question de crédibilité. Un dirigeant fait confiance à celui qui peut, à la question suivante, descendre du principe au fait. Sans cette profondeur, le registre stratégique sonne creux.

Monter au comité ne veut pas dire quitter la salle serveur. Cela veut dire y laisser une équipe capable de tenir sans vous - et en garder les clés.

7. Se situer : la grille de maturité

La plupart des organisations se situent entre la première et la deuxième colonne. Ce n’est pas un jugement sur la personne : c’est souvent le poste qui a été dessiné ainsi.

La ligne « Langage » est la seule qui dépend entièrement du CISO. C’est par elle qu’il faut commencer : c’est elle qui rend les autres négociables.

L’ESSENTIEL POUR AGIR

1. Réécrire sa prochaine présentation en options —

Reprenez votre dernier support pour le comité et terminez chaque sujet par une décision attendue : deux ou trois options, leur coût, votre recommandation. Tout ce qui ne débouche sur aucune décision passe en annexe.

2. Faire formaliser ses trois garanties —

Accès direct à la direction générale, budget identifié, droit d’escalade avec trace de l’arbitrage. Une page validée par la direction générale suffit. Si elle est impossible à obtenir, la délégation décrite dans l’épisode 036 ne tient pas.

3. Nouer une alliance hors de la DSI —

Instaurez un point mensuel avec le risk manager ou le directeur financier. Objectif : relire ensemble les risques cyber dans le langage de la cartographie des risques de l’entreprise, avant qu’ils n’arrivent au comité.

CONCLUSION

La place du CISO dans la gouvernance ne se règle pas dans l’organigramme. Elle se gagne dans la qualité des décisions qu’il rend possibles. Le rattachement compte, les garanties comptent davantage, le langage compte avant tout.

Toute l’année, Plan R a décrit des sujets techniques qui étaient en réalité des choix stratégiques. Il fallait bien, un jour, parler de celui qui doit les porter jusqu’à la table.

Reste une limite que cette chronique n’a pas franchie. Un CISO peut obtenir sa place au comité, parler la langue des arbitrages, tracer chaque désaccord. Il ne peut pas, à lui seul, faire qu’une organisation entière ait envie d’entendre ce qu’il dit.

L’influence ne se décrète pas dans un organigramme. Elle se mérite, un arbitrage après l’autre.

Bibliographie

« The NIST Cybersecurity Framework (CSF) 2.0 - NIST CSWP 29 » - NIST, 26 février 2024

https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf

Référence de la fonction GOVERN : responsabilité de la direction (GV.RR-01), intégration du risque cyber à la gestion des risques de l’entreprise (GV.RM-03), et traduction de la terminologie cyber dans le langage des dirigeants. Fonde les sections 3 et 4.

« Règlement (UE) 2022/2554 du Parlement européen et du Conseil du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (DORA) » - Journal officiel de l’Union européenne

https://eur-lex.europa.eu/eli/reg/2022/2554/oj

Son article 6, paragraphe 4, impose de confier la gestion du risque informatique à une fonction de contrôle suffisamment indépendante pour éviter les conflits d’intérêts. Seul texte européen qui tranche explicitement la question de l’indépendance (section 2).

« Maîtrise du risque numérique - l’atout confiance » - ANSSI et AMRAE, novembre 2019

https://messervices.cyber.gouv.fr/documents-guides/anssi_amrae-guide-maitrise_risque_numerique-atout_confiance.pdf

Guide de gouvernance du risque numérique à destination des dirigeants : comité des risques numériques, articulation direction générale / risk manager / RSSI. Appui de la logique d’alliances développée en section 5.

« Global Cybersecurity Outlook 2026 - The view from the top: CEOs’ priorities in a shifting cyber landscape » - Forum économique mondial, avec Accenture, 12 janvier 2026

https://www.weforum.org/publications/global-cybersecurity-outlook-2026/in-full/2-the-view-from-the-top-ceos-priorities-in-a-shifting-cyber-landscape/

Compare les préoccupations des directeurs généraux (fraude numérique, vulnérabilités de l’IA) et des CISO (rançongiciel, chaîne d’approvisionnement). Base de l’analyse de l’écart de « grammaire » en section 3.

« 2025 Global Chief Information Security Officer (CISO) Compensation Survey » - Heidrick & Struggles, 26 février 2026

https://www.heidrick.com/en/insights/cybersecurity/2025-global-chief-information-security-officer-compensation-survey

Enquête auprès de 371 CISO, principalement États-Unis et Europe : 42 % déclarent un rattachement direct au directeur général. Échantillon orienté grandes entreprises, à lire avec la source suivante.

« 2026 Report Finds Executive-Level CISO Titles More Prevalent than Ever » - IANS Research et Artico Search, 15 janvier 2026

https://www.ians.com/press/2026-report-finds-executive-level-ciso-titles-more-prevalent-than-ever

Synthèse du 2026 State of the CISO Benchmark Report (662 CISO) : 64 % encore rattachés à l’informatique, 52 % jugeant leur périmètre plus entièrement gérable. Le taux de 11 % de rattachement au directeur général est détaillé par CSO Online (24 février 2026).

La chronique 008 de cette saison s’arrêtait aux lignes de code : bibliothèques open source, mises à jour empoisonnées, nomenclatures logicielles. Il laissait volontairement de côté une question plus large. Le logiciel n’est qu’un maillon. Derrière lui, il y a des hébergeurs, des intégrateurs, des infogérants, des prestataires de paie, des transporteurs, des centres d’appels.

Il y a un an, la chronique 043 de la saison 2025 posait le diagnostic des fournisseurs critiques : cartographier, qualifier la substituabilité, sortir du questionnaire Excel annuel. Le diagnostic tient toujours. Ce qui a changé, c’est que la réglementation a désormais des dents, et que les incidents de l’année ont montré où elles mordent.

La chronique 037 rappelait que la preuve est devenue un actif. Elle l’est aussi dans l’autre sens : ce que vous exigez de vos tiers, d’autres l’exigent de vous. Chaque organisation est à la fois cliente qui audite et fournisseur qu’on audite.

La tentation est double. Soit la naïveté — un certificat, une signature, et l’on passe à autre chose. Soit la défiance — des audits intrusifs, des clauses punitives, et une relation qui se raidit au moment précis où l’on aurait besoin de coopération.

La vraie question n’est pas « mon fournisseur est-il fiable ? ». C’est : « combien de temps mon activité tient-elle quand il ne l’est plus, et qui l’a vérifié ? »

1. Le questionnaire n’a jamais protégé personne

Commençons par un constat que tout RSSI connaît sans toujours oser le formuler. Le questionnaire de sécurité fournisseur est devenu un rituel d’échange de papier.

Les grands prestataires en reçoivent des centaines par an. Ils y répondent avec des équipes dédiées et des bibliothèques de réponses standard. Les petits y répondent comme ils peuvent, souvent en cochant « oui » pour ne pas perdre le contrat. Dans les deux cas, le document mesure la capacité à remplir un questionnaire.

Le vrai problème n’est pas l’outil. C’est ce qu’on lui demande. Un questionnaire interroge la conformité : avez-vous une politique, un certificat, un PCA ? Il interroge rarement la capacité : en combien de temps nous prévenez-vous, qui décroche la nuit, quand avez-vous testé votre bascule, et sur quel périmètre ?

Ajoutons l’angle mort structurel : le questionnaire ne voit que le rang 1. Le prestataire de votre prestataire, celui qui héberge son application ou maintient son réseau, reste hors champ. Or c’est souvent là que la défaillance naît.

Un questionnaire mesure l’aptitude à rassurer. La résilience se mesure à l’aptitude à tenir. Confondre les deux, c’est archiver une illusion.

2. Ce qui a changé en un an : la fin de l’excuse réglementaire

Pendant longtemps, le risque tiers souffrait d’un flou commode : chacun savait qu’il fallait s’en occuper, personne n’était tenu de le démontrer. Ce temps est terminé, au moins pour une partie du marché.

Côté financier, le règlement DORA, applicable depuis le 17 janvier 2025, a imposé un registre d’information recensant l’ensemble des contrats de services TIC. Il exige des stratégies de sortie documentées pour les fonctions critiques, et des clauses contractuelles minimales : droits d’accès et d’audit, notification d’incident, participation aux tests.

Le 18 novembre 2025, les trois autorités européennes de supervision ont désigné dix-neuf prestataires TIC critiques : hyperscalers, centres de données, opérateurs d’infrastructure, fournisseurs de technologies financières. Ils relèvent désormais d’une supervision directe à l’échelle européenne.

Côté NIS2, le règlement d’exécution (UE) 2024/2690 détaille ce qu’on attend d’une politique de sécurité de la chaîne d’approvisionnement : critères de sélection, évaluation, revue périodique, annuaire des fournisseurs. Son champ direct est limité aux fournisseurs de services numériques et d’infrastructure numérique, mais la guidance technique publiée par l’ENISA en juin 2025 est en train de devenir la grille de lecture commune.

Conséquence : la question n’est plus « faut-il évaluer ses tiers ? ». Elle est « pouvez-vous le démontrer à un superviseur, un assureur ou un client grand compte ? ».

La réglementation n’a pas créé le risque tiers. Elle a supprimé la possibilité de l’ignorer poliment.

3. Proportionner : tous les tiers ne méritent pas le même regard

L’erreur la plus fréquente, une fois l’obligation posée, est d’appliquer le même processus à tout le monde. Le fournisseur de fournitures de bureau reçoit le même questionnaire que l’hébergeur des données clients. Résultat : l’effort se dilue, les équipes saturent, et les tiers réellement critiques ne sont pas regardés de plus près que les autres.

La chronique 043 de 2025 proposait quatre critères de qualification : criticité, substituabilité, temporalité, exposition. Un an de pratique permet de les réduire à deux axes suffisants pour décider du niveau d’effort : l’impact d’une défaillance et la difficulté à remplacer.

La case en haut à droite est celle qui compte. Dans la plupart des organisations, elle ne contient qu’une poignée de noms. C’est là, et presque uniquement là, que l’effort d’audit doit se concentrer.

Auditer tout le monde, c’est n’auditer personne. La proportionnalité n’est pas un allègement : c’est la condition pour regarder vraiment ceux qui comptent.

4. Exiger sans braquer : l’art de la relation asymétrique

Deuxième réalité à regarder en face : le rapport de force n’est pas le même selon le tiers. On n’audite pas un hyperscaler comme on audite une PME d’intégration. Le premier ne vous ouvrira pas ses salles ; la seconde risque de se sentir menacée.

Face aux grands prestataires, la voie réaliste est la preuve indirecte : rapports d’audit tiers (SOC 2, ISO 27001 avec leur périmètre), attestations de qualification, et désormais les résultats de la supervision européenne pour les prestataires désignés critiques. Les textes associés à DORA admettent d’ailleurs les audits mutualisés entre plusieurs clients.

Face aux petits prestataires, la voie réaliste est la coconstruction. Un fournisseur de cinquante personnes ne dispose ni d’un RSSI à temps plein ni d’une équipe de conformité. Exiger de lui ce qu’on exige d’un grand compte, c’est le pousser à mentir ou à partir.

Dans les deux cas, trois exigences restent non négociables pour un tiers critique :

• un délai de notification d’incident précis, avec un contact nommé joignable hors heures ouvrées ;

• la transparence sur les sous-traitants qui touchent vos données ou vos flux ;

• un droit de regard sur les tests de continuité qui concernent votre service.

La fermeté se porte sur trois exigences, pas sur trois cents questions. Un partenaire accepte d’être exigé ; il refuse d’être soupçonné.

5. Tester les interfaces plutôt que les promesses

Voici le déplacement de regard que propose cette chronique. On ne peut pas vérifier en profondeur ce qui se passe chez un tiers. On peut, en revanche, vérifier tout ce qui se passe à la jonction entre lui et nous.

Septembre 2025 en a donné une illustration nette. Une attaque par rançongiciel contre un prestataire de logiciel d’enregistrement partagé a perturbé plusieurs grands aéroports européens, dont Bruxelles, Berlin et Londres Heathrow. L’ENISA a confirmé un incident chez un tiers. Les aéroports sont revenus à des procédures manuelles pendant plusieurs jours.

La leçon n’est pas que ce prestataire était mal protégé. C’est que la capacité à fonctionner en mode dégradé, côté client, a déterminé l’ampleur réelle de la crise. Et cette capacité-là se teste sans rien demander au fournisseur.

Concrètement, cinq interfaces se vérifient :

• l’alerte : le prestataire sait-il qui prévenir chez vous, et ce contact est-il encore en poste ?

• les accès : pouvez-vous couper instantanément ses accès à votre SI ?

• les données : pouvez-vous récupérer vos données, dans un format exploitable, dans un délai connu ?

• le mode dégradé : vos équipes savent-elles travailler sans le service, et pendant combien de temps ?

• la bascule : l’alternative existe-t-elle ailleurs que sur le papier ?

Ce qui se passe chez votre fournisseur vous échappe. Ce qui se passe à sa frontière vous appartient entièrement — et c’est là que se joue la durée de la crise.

6. Le tiers défaillant est un scénario, pas une surprise

Juillet 2024 reste l’exemple de référence. Une mise à jour défectueuse d’un éditeur de sécurité a rendu indisponibles environ 8,5 millions de postes Windows selon Microsoft. Pas d’attaque, pas de fournisseur négligent au sens classique : une erreur de déploiement chez un partenaire de confiance.

Les organisations qui s’en sont le mieux sorties n’étaient pas celles qui avaient le meilleur contrat. C’étaient celles qui avaient déjà imaginé qu’un outil présent sur tous leurs postes puisse les bloquer tous en même temps.

La chronique 005 de cette saison plaidait pour une crise pensée sur la planche à dessin. Appliqué aux tiers, cela signifie inscrire au programme d’exercices au moins un scénario par fournisseur de la case critique :

• indisponibilité brutale et prolongée du service ;

• compromission du fournisseur, avec suspicion de rebond vers votre SI ;

• défaillance économique ou rachat hostile ;

• rupture imposée par un contexte géopolitique ou juridique.

Et une question à poser à la fin de chaque exercice : le plan de sortie est-il financé, ou seulement rédigé ? Une réversibilité qui suppose dix-huit mois de migration n’est pas une sortie. C’est une clause.

Si la défaillance d’un tiers critique vous surprend, ce n’est pas lui qui a échoué. C’est votre préparation.

7. Se situer : la grille de maturité

La plupart des organisations se trouvent entre la première et la deuxième colonne. Ce n’est pas un échec. C’est un point de départ, à condition de savoir quelle ligne faire progresser en premier.

La ligne « Crise » est la plus rentable à faire bouger : un exercice révèle en une demi-journée ce qu’aucun questionnaire ne dira en dix ans.

L’ESSENTIEL POUR AGIR

1. Remplir la case critique —

Croisez impact et substituabilité sur vos cinquante principaux tiers. Isolez ceux qui sont à la fois critiques et non remplaçables à court terme. Cette liste, rarement plus de dix noms, devient votre périmètre prioritaire pour l’année.

2. Tester une interface par trimestre —

Choisissez un tiers critique et vérifiez une seule jonction : le contact d’alerte, la coupure d’accès ou la récupération des données. Un test court, documenté et daté vaut mieux qu’un audit annuel exhaustif jamais relu.

3. Inscrire un scénario tiers au prochain exercice de crise —

Faites jouer à votre cellule de crise la perte d’un fournisseur critique pendant soixante-douze heures. Mesurez ce qui tient, ce qui cède, et chiffrez le coût réel de la sortie.

CONCLUSION

La résilience d’un tiers ne s’achète pas avec un contrat et ne se vérifie pas avec un questionnaire. On ne la possède pas. On l’emprunte, à des conditions qu’il faut connaître.

Ce que l’on possède, en revanche, c’est sa propre préparation : la transparence qu’on exige, les interfaces qu’on éprouve, le scénario qu’on a déjà joué. Sans cette préparation, tout le reste est cosmétique.

Reste un angle mort que cette chronique a contourné. Nous avons parlé de ce qu’on vérifie chez les autres. Mais qui, dans l’organisation, a réellement envie de découvrir qu’un partenaire historique ne tiendrait pas ? La résistance au constat n’est pas technique. Elle est humaine.

On ne choisit pas la défaillance de ses partenaires. On choisit d’y être prêt.

Bibliographie

« Règlement (UE) 2022/2554 du Parlement européen et du Conseil du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (DORA) » - Journal officiel de l’Union européenne

https://eur-lex.europa.eu/eli/reg/2022/2554/oj

Texte de référence sur le risque lié aux prestataires TIC : registre d’information, stratégies de sortie, clauses contractuelles minimales et cadre de supervision des prestataires critiques. Fonde les sections 2 et 4.

« The European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act » - Autorité bancaire européenne (EBA), 18 novembre 2025

https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital

Annonce officielle de la première désignation des prestataires TIC critiques et de la méthode employée (importance systémique, rôle dans les fonctions critiques, substituabilité). Le nombre de dix-neuf figure dans la liste jointe au communiqué.

« Règlement d’exécution (UE) 2024/2690 de la Commission du 17 octobre 2024 » - Journal officiel de l’Union européenne

https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj

Précise les mesures de gestion des risques NIS2, dont la politique de sécurité de la chaîne d’approvisionnement et l’annuaire des fournisseurs. Champ direct limité aux fournisseurs de services et d’infrastructure numériques.

« Technical Implementation Guidance on cybersecurity risk management measures, version 1.0 » - ENISA, juin 2025

https://www.enisa.europa.eu/sites/default/files/2025-06/ENISA_Technical_implementation_guidance_on_cybersecurity_risk_management_measures_version_1.0.pdf

Guide d’application du règlement 2024/2690. Sa section consacrée à la chaîne d’approvisionnement détaille critères de sélection, évaluation et revue périodique des fournisseurs, et sert de grille de lecture au-delà de son champ strict.

« Good Practices for Supply Chain Cybersecurity » - ENISA, juin 2023

https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity

État des pratiques de gestion du risque chaîne d’approvisionnement chez les entités essentielles et importantes de l’Union. Utile pour situer son organisation par rapport à la pratique observée.

« NIST SP 800-161 Rev. 1 (Update 1) - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations » - NIST, mai 2022, mise à jour novembre 2024

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1-upd1.pdf

Cadre de référence pour intégrer le risque fournisseur à trois niveaux (entreprise, métier, opérationnel). Appui méthodologique de la logique de proportionnalité développée en section 3.

L’épisode 036 se terminait sur une question restée ouverte : quand tout repose sur la preuve, qui vérifie que cette preuve dit vrai ? Une partie de la réponse ne se trouve pas dans l’organisation. Elle se trouve dehors — chez ceux qui financent, assurent, notent et achètent.

Le bilan 2025 posait déjà l’intuition : la résilience commence à circuler comme un critère de sélection, pas seulement comme une ligne de coût. Un an plus tard, la matière existe. Un cadre de reporting de durabilité, des normes, des investisseurs qui posent des questions écrites.

Et une surprise, pour qui suit le sujet de loin : la contrainte réglementaire vient de reculer. L’Union européenne a allégé la CSRD en 2026, réduit le périmètre, simplifié les normes. Le raccourci commercial — « la CSRD va vous obliger à publier votre posture cyber » — est tout simplement faux.

Ce qui n’a pas reculé, c’est la demande. Elle ne vient plus principalement du régulateur. Elle vient du marché, et elle est nettement plus difficile à négocier.

👉 La vraie question n’est pas « suis-je obligé de publier ma résilience ? ». C’est : « que vaut-elle pour ceux qui décident de mon financement, de ma prime d’assurance et de mes contrats ? »

I. Ce que l’Omnibus a changé — et ce qu’il n’a pas changé

Commençons par corriger le récit ambiant.

La directive (UE) 2026/470, dite Omnibus I, adoptée le 24 février 2026 et entrée en vigueur le 18 mars 2026, revoit à la baisse le dispositif issu de la CSRD. Le seuil d’assujettissement passe à plus de 1 000 salariés en moyenne et plus de 450 M€ de chiffre d’affaires net. L’assurance exigée reste de niveau limité, et les normes sectorielles sont abandonnées.

Les normes ESRS révisées, publiées le 3 juillet 2026, poursuivent la même logique de simplification. Elles s’appliquent aux exercices ouverts à compter du 1er janvier 2027, avec une adoption anticipée possible pour l’exercice 2026.

S’y ajoute un plafond de sollicitation de la chaîne de valeur : les partenaires commerciaux de moins de 1 000 salariés peuvent refuser une demande d’information allant au-delà du standard volontaire prévu par la Commission.

Conséquence pratique pour un RSSI d’ETI : la probabilité que votre entreprise soit directement assujettie a fortement diminué. Celle qu’elle reçoive un questionnaire de son client grand compte, de son assureur ou de sa banque, elle, n’a pas bougé.

👉 L’obligation recule, la sollicitation reste. C’est la pire configuration pour qui attendait la réglementation pour se mettre en mouvement : il faudra répondre sans avoir de texte pour arbitrer le budget.

II. Où la cyber se loge réellement dans un état de durabilité

Deuxième malentendu à lever : il n’existe pas de norme ESRS dédiée à la cybersécurité. Ni dans la version initiale, ni dans la version révisée.

La cyber n’a donc pas de case. Elle a une porte — et cette porte s’appelle la double matérialité. L’entreprise identifie ses impacts, risques et opportunités ; si une défaillance numérique pèse sur ses résultats financiers ou sur des tiers, elle devient un sujet à traiter, quel que soit le chapitre où on l’inscrit.

En pratique, elle se loge à quatre endroits :

• La gouvernance (ESRS 2) : rôles, compétences et surveillance des organes d’administration sur les sujets de durabilité. C’est le point de raccordement direct avec l’article 20 de NIS2 traité dans l’épisode 036.
• Les consommateurs et utilisateurs finaux : la protection des données personnelles et de la vie privée y figure explicitement comme sous-thème.
• La conduite des affaires : culture, éthique, relations fournisseurs — donc le risque de chaîne d’approvisionnement.
• Les informations spécifiques à l’entité, quand aucun chapitre existant ne couvre correctement un enjeu matériel.

Cette dispersion n’est pas un défaut de conception. Elle traduit une réalité : la résilience numérique n’est pas un thème de durabilité, c’est une condition de tous les autres. Une usine à l’arrêt ne produit ni valeur, ni emploi, ni transition énergétique.

👉 Chercher « où mettre la cyber » dans les normes est une mauvaise entrée. La bonne question est : quelle défaillance numérique, chez nous, aurait un effet financier ou sociétal significatif ? Le reste n’est que classement.

III. Ce que le marché sanctionne vraiment

Ici, l’honnêteté impose de contredire un argument que l’on entend souvent en comité de direction : « une cyberattaque, c’est le cours de bourse qui s’effondre ».

Les données disponibles ne disent pas cela. Le Fonds monétaire international a consacré en avril 2024 un chapitre entier de son rapport sur la stabilité financière mondiale au risque cyber. Ses mesures sont sobres : un incident malveillant s’accompagne en moyenne d’une baisse du cours de l’action de 0,1 à 0,2 point de pourcentage, et de 0,3 % à 0,6 % pour les entreprises de petite taille.

Autrement dit : le marché ne punit pas durement l’incident moyen.

Le même rapport documente pourtant l’autre bout de la distribution. Les pertes directes agrégées approchent 28 milliards de dollars depuis 2020. La perte annuelle maximale médiane par pays est passée de 58 M$ en 2017 à 141 M$ en 2021. Et un scénario décennal ressort autour de 2,5 milliards de dollars.

C’est exactement le profil d’un risque à queue épaisse : peu coûteux en moyenne, capable de détruire une entreprise dans la queue de distribution. Ce type de risque ne se price pas dans le cours de l’action au jour de l’incident. Il se price ailleurs — en prime d’assurance, en covenants bancaires, en conditions de notation, en exigences contractuelles.

👉 Le marché ne sanctionne pas l’incident. Il tarife l’incertitude. Et l’incertitude se réduit avec de la preuve, pas avec de la communication.

IV. Le revers : publier, c’est aussi s’exposer

Une chronique honnête doit présenter ce qui contredit sa thèse.

Publier sa posture de résilience comporte deux risques réels. Le premier est opérationnel : une description trop précise d’une architecture, d’un calendrier de migration ou d’une dépendance critique est un cadeau pour un attaquant en phase de reconnaissance.

Le second est juridique, et l’épisode 036 en a posé les termes. Une déclaration publique inexacte sur son niveau de maîtrise devient une déclaration trompeuse envers des investisseurs. C’est précisément ce terrain, aux États-Unis, qui a nourri la mise en cause du RSSI de SolarWinds.

Le débat outre-Atlantique n’est d’ailleurs pas clos : une pétition déposée auprès de la SEC en mai 2025 (dossier 4-856) demande le retrait pur et simple de l’obligation de déclaration d’incident significatif du formulaire 8-K. On ne peut pas prétendre que la trajectoire réglementaire mondiale soit uniformément orientée vers plus de transparence.

La ligne de partage est pourtant simple à tenir. On ne publie pas ce que l’on protège. On publie ce que l’on est capable de faire : des capacités testées, des délais démontrés, des couvertures mesurées, des dispositifs de gouvernance datés.

👉 Ne publiez jamais votre architecture. Publiez votre capacité à tenir. La première est une information exploitable par un attaquant ; la seconde est une information utile à un investisseur.

V. Huit indicateurs qui tiennent devant un investisseur

Un indicateur crédible répond à trois conditions : il prouve quelque chose, il repose sur une source vérifiable, et il ne s’améliore pas en communiquant davantage.

Et la grille de maturité, dans le format de référence de la chronique :

👉 Un indicateur qui s’améliore quand on communique mieux n’est pas un indicateur. C’est un élément de langage — et un investisseur expérimenté le repère en une question de relance.

VI. Du tableau de bord au récit : parler au conseil

Reste le point le plus difficile, et il n’est pas technique. Les chiffres ci-dessus ne se transportent pas seuls jusqu’à un conseil d’administration.

L’écart de langage est documenté. Le Global Cybersecurity Outlook 2026 du Forum économique mondial montre des dirigeants exécutifs préoccupés en premier lieu par la fraude facilitée par le numérique, quand les RSSI restent centrés sur le rançongiciel et la chaîne d’approvisionnement. Même sujet, deux vocabulaires, deux échelles de temps.

Deux appuis méthodologiques permettent de faire la jonction sans inventer de cadre maison.

Le premier est la fonction GOVERN du NIST Cybersecurity Framework 2.0 (février 2024), dont l’un des résultats attendus est explicite : les activités de gestion du risque cyber sont intégrées aux processus de gestion des risques de l’entreprise. Ce n’est pas une recommandation d’ingénieur, c’est une instruction de rattachement.

Le second est la comparaison sectorielle. Le rapport NIS360 2026 de l’ENISA (mai 2026) classe la maturité des secteurs critiques européens : banque, électricité et télécommunications en tête ; santé, ferroviaire, maritime, administrations publiques et eau potable encore en deçà du niveau que leur criticité exigerait. Se situer dans son secteur transforme un chiffre isolé en position relative — la seule forme qu’un conseil consomme naturellement.

👉 Un conseil d’administration n’achète pas un indicateur. Il achète une position : où nous sommes, par rapport à qui, et ce que coûterait de ne pas bouger.

L’ESSENTIEL POUR AGIR

1. Testez votre exposition réelle, pas votre assujettissement : Avant de vous demander si la CSRD vous concerne après l’Omnibus, comptez les questionnaires sécurité reçus l’an dernier de vos clients, assureurs et banques. Ce chiffre est votre véritable obligation de reporting, et il ne dépend d’aucune transposition.

2. Choisissez cinq indicateurs et tenez-les trois ans : Prenez cinq lignes du tableau de la section V, celles pour lesquelles vous disposez déjà d’une source de preuve, et publiez-les sans les changer pendant trois exercices. La valeur d’un indicateur ESG cyber ne vient pas de sa sophistication, mais de sa série temporelle.

3. Faites relire votre reporting par la direction financière avant la direction de la communication : La direction financière repérera ce qui n’est pas auditable ; la communication, elle, cherchera ce qui est valorisant. Dans cet ordre, vous obtenez un document crédible. Dans l’ordre inverse, un document fragile.

CONCLUSION

L’ESG cyber n’est pas un nouveau référentiel à déployer. C’est un changement de destinataire.

Les mêmes preuves qui protègent un dirigeant devant une autorité de contrôle — approbations datées, exercices tenus, dépendances cartographiées — servent aussi, mot pour mot, à démontrer une capacité à tenir devant un investisseur. L’épisode 036 les appelait un dossier de preuve. Vu de l’extérieur, ce dossier porte un autre nom : un actif.

Et il faut accepter la conséquence : un actif se démontre, se date, se compare. Il ne se raconte pas.

Reste alors la dernière pièce, et c’est peut-être la plus fragile. Ces chiffres sont produits par des femmes et des hommes, au quotidien, dans des équipes qui ne lisent pas les états de durabilité. Un reporting impeccable posé sur une culture interne qui ne suit pas ne tient pas trois exercices.

On ne valorise pas la résilience en la racontant mieux. On la valorise en acceptant qu’elle soit mesurée.

Bibliographie

« Directive (UE) 2026/470 du Parlement européen et du Conseil du 24 février 2026 (Omnibus I) » — Journal officiel de l’Union européenne https://eur-lex.europa.eu/eli/dir/2026/470/oj Texte source de l’allègement du reporting de durabilité, entré en vigueur le 18 mars 2026. Fonde le constat de la section I : relèvement des seuils, assurance limitée, abandon des normes sectorielles, plafonnement des sollicitations de la chaîne de valeur.

« European Commission Publishes Delegated Act on Revised ESRS and Voluntary Sustainability Reporting Standard » — EFRAG, 3 juillet 2026 https://www.efrag.org/en/news-and-calendar/news/european-commission-publishes-delegated-act-on-revised-esrs-and-voluntary-sustainability-reporting Annonce officielle de l’adoption des ESRS révisés, applicables aux exercices ouverts à compter du 1er janvier 2027 avec adoption anticipée possible pour 2026. Référence de calendrier utilisée en sections I et II.

« Global Financial Stability Report, April 2024 — Chapter 3: Cyber Risk: A Growing Concern for Macrofinancial Stability » — Fonds monétaire international https://www.imf.org/-/media/Files/Publications/GFSR/2024/April/English/ch3.ashx Source quantifiée de la section III : effet mesuré des incidents sur les cours boursiers, pertes directes agrégées depuis 2020, et modélisation des pertes extrêmes. Contredit utilement le récit de l’effondrement boursier systématique.

« The NIST Cybersecurity Framework (CSF) 2.0 » — National Institute of Standards and Technology, 26 février 2024 https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf Référentiel de la fonction GOVERN, qui pose l’intégration du risque cyber dans les processus de gestion des risques de l’entreprise. Support méthodologique du raccordement DSI / conseil d’administration décrit en section VI.

« NIS360 2026 » — ENISA, mai 2026 https://www.enisa.europa.eu/sites/default/files/2026-05/ENISA%20NIS360%202026.pdf Évaluation comparative de la maturité et de la criticité des secteurs NIS2 en Europe. Permet le positionnement sectoriel évoqué en section VI, et fournit une base de comparaison indépendante d’un fournisseur.

« Global Cybersecurity Outlook 2026 — Executive summary » — World Economic Forum https://www.weforum.org/publications/global-cybersecurity-outlook-2026/in-full/executive-summary-6efae97d74/ Documente l’écart de perception entre dirigeants exécutifs et RSSI ainsi que la place croissante de l’IA et du contexte géopolitique dans les stratégies. Source déclarative fondée sur enquête : à lire comme un indicateur de perception, non comme une mesure.

L’épisode 004 posait que la résilience est une décision politique : des arbitrages, des dépendances assumées, une gouvernance explicite. L’épisode 035 s’est arrêté sur la parole en crise, et s’est terminé sur une question laissée ouverte : quand tout est retombé, qui répond de ce qui a été dit, et de ce qui ne l’a pas été ?

On monte d’un cran. Après le « comment répondre », le « qui répond ».

Le sujet est inconfortable, et il est mal traité. D’un côté, un discours commercial qui agite la prison pour vendre du conseil. De l’autre, un réflexe de direction générale : « c’est un sujet technique, il est délégué ». Les deux sont faux, et pour la même raison — ils ignorent ce que les textes disent exactement.

Ce qui a changé n’est pas l’apparition d’un risque pénal inédit. C’est un déplacement plus discret et plus profond : la charge de la preuve. Le dirigeant ne doit plus seulement décider. Il doit pouvoir démontrer qu’il a décidé, quand, sur la base de quoi.

👉 La vraie question n’est pas « vais-je aller en prison ? ». C’est : « suis-je en mesure de prouver ce que j’ai arbitré, et ce que j’ai refusé ? »

I. Ce que les textes disent — et ce qu’ils ne disent pas

Commençons par le texte, pas par le commentaire.

L’article 20 de la directive NIS2 impose trois choses aux États membres : que les organes de direction des entités essentielles et importantes approuvent les mesures de gestion des risques, qu’ils en surveillent la mise en œuvre, et qu’ils puissent être tenus responsables des manquements de l’entité. Son second paragraphe ajoute une obligation de formation des membres de ces organes.

L’article 32 va plus loin. Lorsque les mesures correctives se révèlent inefficaces, l’autorité compétente peut demander l’interdiction temporaire, pour la personne exerçant les fonctions de directeur général ou de représentant légal, d’exercer des fonctions dirigeantes — jusqu’à correction du manquement. Cette mesure ne vise que les entités essentielles, et ne s’applique pas aux administrations.

DORA, applicable au secteur financier depuis le 17 janvier 2025, est encore plus direct : l’organe de direction définit, approuve, supervise le cadre de gestion du risque numérique et en porte la responsabilité ultime. Il doit lui aussi se former régulièrement.

Maintenant, ce que ces textes ne disent pas. Ni NIS2 ni DORA ne créent une infraction pénale nouvelle. Le régime qu’ils installent est administratif : amendes plafonnées à 10 M€ ou 2 % du chiffre d’affaires mondial pour les entités essentielles, 7 M€ ou 1,4 % pour les entités importantes, assorties de mesures d’exécution visant les personnes.

👉 Le cadre européen ne pénalise pas le dirigeant. Il le rend identifiable, formé, et personnellement atteignable par la sanction administrative. Ce n’est pas la même chose — c’est souvent plus rapide.

II. La France en retard : un répit qui n’en est pas un

Au 5 septembre 2026, la loi française de transposition n’est toujours pas promulguée. Le Sénat a adopté le texte les 11 et 12 mars 2025 ; l’Assemblée nationale l’a examiné en commission spéciale en septembre 2025, puis son inscription en séance a glissé — au plus tôt à la rentrée parlementaire de septembre 2026, notamment sur le point dur du chiffrement.

Ce retard a un coût public. Le 19 juin 2026, la Commission européenne a décidé de renvoyer l’Irlande, l’Espagne, la France et les Pays-Bas devant la Cour de justice de l’Union européenne pour défaut de notification des mesures de transposition de NIS2.

Le texte adopté par le Sénat donne pourtant déjà la mesure de ce qui vient. Son article 14 impose que les organes de direction approuvent et supervisent les mesures de sécurité, et que leurs membres soient formés. Son article 37 prévoit, en dernier recours et après une amende restée sans effet, l’interdiction pour un dirigeant d’exercer des responsabilités dirigeantes jusqu’à correction du manquement. Le périmètre annoncé est large : environ 15 000 entités essentielles et importantes, auxquelles s’ajoutent près de 1 500 collectivités territoriales.

Un point mérite une réserve explicite : les rapporteurs sénatoriaux envisageaient de différer d’au moins trois ans l’application du dispositif de contrôle et de sanction. Cette intention figure dans les travaux préparatoires, pas dans un texte définitif — à vérifier lors de la promulgation.

Et surtout : ce différé, s’il survit, ne portera que sur le régime NIS2. Il ne suspend ni DORA, déjà applicable, ni le droit commun de la responsabilité, qui n’a jamais attendu.

👉 L’absence de loi ne crée pas un vide de responsabilité. Elle crée un décalage entre le moment où l’on aurait pu se préparer et celui où l’on devra prouver.

III. Le pénal existe déjà, et il ne vient pas de NIS2

C’est le point que les COMEX découvrent le plus tard.

L’article 226-17 du code pénal punit de cinq ans d’emprisonnement et 300 000 € d’amende le fait de procéder à un traitement de données personnelles sans mettre en œuvre les mesures de sécurité prescrites par le RGPD. Ce texte est en vigueur depuis 2019. Il ne parle pas de cybersécurité au sens large, mais toute fuite de données significative entre dans son champ.

À côté, le droit des sociétés offre depuis longtemps des voies civiles : action en responsabilité pour faute de gestion, responsabilité pour insuffisance d’actif en cas de liquidation. Une défaillance cyber ayant conduit à l’arrêt durable d’une activité n’est pas juridiquement différente d’une autre imprudence de gestion.

Reste l’illusion la plus répandue : la délégation de pouvoirs. Elle fonctionne — à trois conditions cumulatives, constantes en jurisprudence française. Le délégataire doit disposer de l’autorité, de la compétence et des moyens nécessaires. Un RSSI sans budget arbitré, sans accès direct à la direction générale, sans pouvoir de blocage, ne constitue pas une délégation valable. C’est exactement la situation décrite dans l’épisode 004 : porter le risque sans maîtriser les choix.

👉 Une délégation mal constituée ne protège pas le dirigeant. Elle documente sa faute — en prouvant qu’il savait qui aurait dû décider, sans lui en donner les moyens.

IV. Le contre-exemple américain, et pourquoi il ne rassure pas

Un article honnête doit aussi présenter ce qui contredit sa thèse.

Aux États-Unis, la poursuite emblématique du RSSI de SolarWinds par la SEC, engagée en octobre 2023, s’est achevée par un abandon volontaire de l’action le 20 novembre 2025. La vague de mise en cause personnelle qu’on annonçait outre-Atlantique s’est, pour l’instant, retirée.

On pourrait en conclure que le sujet est surjoué. Ce serait une lecture rapide, pour trois raisons.

D’abord, l’abandon américain relève d’un choix d’opportunité d’une autorité de marché, pas d’une décision de fond invalidant le principe. Ensuite, les mécanismes européens ne sont pas de même nature : là où la SEC poursuivait une communication trompeuse envers des investisseurs, NIS2 et DORA visent un défaut de gouvernance, directement constatable par une autorité de contrôle sans passer par un juge. Enfin, l’imputation européenne vise le dirigeant exécutif, pas le RSSI.

Le déplacement réel est là. Pendant vingt ans, la mise en cause remontait rarement au-delà de la direction technique. Le cadre européen inverse la présomption : c’est l’organe de direction qui approuve, donc qui répond.

👉 Ce n’est pas une vague de procès qui arrive. C’est une charge de la preuve qui change de bureau.

V. Grille : qui répond de quoi

Cette grille sert à un usage précis : la poser sur la table d’un COMEX et faire nommer une personne par ligne. Une case vide est un risque, pas un oubli administratif.

Et la lecture décisionnelle, dans le format qu’un comité de direction consomme réellement :

👉 Une organisation mature ne se reconnaît pas au nombre de mesures déployées, mais à sa capacité à dire, ligne par ligne, qui a approuvé quoi et à quelle date.

VI. Le dossier de preuve du dirigeant

Sept pièces. Un dirigeant devrait pouvoir les réunir en dix minutes, sans réunion préalable. Si l’exercice prend une semaine, la réponse est déjà connue.

• La délibération d’approbation. Un document daté où l’organe de direction approuve explicitement la politique de gestion des risques numériques, avec sa version.
• La trace des arbitrages refusés. Les demandes d’investissement écartées, avec leur motivation. C’est contre-intuitif : un refus motivé et documenté protège mieux qu’un silence.
• Les attestations de formation nominatives. Membres de l’organe de direction inclus, pas seulement les équipes.
• La cartographie des dépendances critiques. Elle matérialise le fait que les risques structurants ont été identifiés, pas subis.
• L’acte de délégation, et sa preuve d’effectivité. Budget attribué, rattachement hiérarchique, pouvoir d’arrêt : les trois conditions de validité, démontrées.
• Le registre des incidents et de leurs notifications. Horodaté, avec les décisions de qualification et leur auteur.
• Le dernier rapport de contrôle ou d’audit, et son plan d’action daté. Un audit sans suite documentée est une preuve à charge.

Aucune de ces pièces n’est nouvelle. Toutes existent, dispersées, dans la plupart des organisations. Le travail à faire n’est pas de les produire, mais de les rassembler dans un lieu unique, tenu à jour, connu de la direction générale.

👉 Sans dossier de preuve consolidé, tout le reste est déclaratif. Et le déclaratif ne résiste pas à un contrôle.

L’ESSENTIEL POUR AGIR

1. Nommez une personne par ligne : Reprenez la grille de la section V en comité de direction et exigez un nom, pas une direction, pour chaque case « qui décide ». Les cases qui résistent à cet exercice sont précisément celles où personne ne répondra le jour venu.

2. Testez votre délégation, pas votre organigramme : Vérifiez que votre délégataire cyber dispose réellement des trois conditions — autorité, compétence, moyens. Si son budget est arbitré ailleurs et qu’il ne peut bloquer aucune mise en production, la délégation ne tient pas, quelle que soit la qualité du document signé.

3. Constituez le dossier de preuve avant d’en avoir besoin : Rassemblez les sept pièces de la section VI dans un espace unique, avec un responsable de mise à jour et une revue semestrielle. Chronométrez le premier assemblage : ce délai est votre meilleur indicateur de maturité de gouvernance.

CONCLUSION

La responsabilité du dirigeant en matière de résilience n’est pas devenue pénale par magie européenne. Elle est devenue traçable, nominative et opposable — ce qui, en pratique, change davantage les comportements qu’une menace d’emprisonnement dont personne ne croit vraiment qu’elle le concerne.

C’est aussi, disons-le, l’argument le plus efficace jamais mis entre les mains d’un RSSI pour faire bouger un COMEX. Il mérite d’être utilisé avec précision plutôt qu’avec emphase : la peur mal calibrée produit de la conformité de façade, exactement ce que le cadre cherche à éliminer.

L’épisode 004 concluait que la résilience est une ligne de gouvernance. Six mois plus tard, cette ligne porte une signature.

Reste la question suivante, et elle est presque plus dure. Quand tout repose sur la preuve — approbations, arbitrages, attestations, plans d’action — qui vérifie que cette preuve dit vrai ? Une organisation peut produire un dossier impeccable et rester fragile.

On ne juge pas un dirigeant sur ce qu’il a compris. On le juge sur ce qu’il a écrit, daté, et assumé.

Bibliographie

« Directive (UE) 2022/2555 (NIS 2) » — Journal officiel de l’Union européenne https://eur-lex.europa.eu/eli/dir/2022/2555/oj Texte source. Article 20 : approbation des mesures par les organes de direction, supervision, responsabilité et obligation de formation. Article 32 : interdiction temporaire d’exercer des fonctions dirigeantes. Article 34 : plafonds des amendes administratives.

« Règlement (UE) 2022/2554 (DORA) » — Journal officiel de l’Union européenne https://eur-lex.europa.eu/eli/reg/2022/2554/oj Applicable au secteur financier depuis le 17 janvier 2025. Son article 5 place la responsabilité ultime de la gestion du risque numérique sur l’organe de direction et impose une obligation de formation continue à ses membres.

« Commission refers Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose the rules on cybersecurity » — Commission européenne, 19 juin 2026 https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1499 Communiqué officiel du renvoi de la France devant la CJUE pour défaut de transposition de NIS2. Source directe du constat de retard français développé en section II.

« Projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité — texte adopté par le Sénat (n° 394) » — Sénat, mars 2025 https://www.senat.fr/leg/pjl24-394.html Version française en cours de navette. Article 14 : approbation, supervision et formation des organes de direction. Article 37 : interdiction pour un dirigeant d’exercer des responsabilités dirigeantes, en dernier recours.

« Avancement de la transposition de la directive NIS 2 » — ANSSI, FAQ MonEspaceNIS2 https://aide.monespacenis2.cyber.gouv.fr/fr/article/avancement-de-la-transposition-de-la-directive-nis-2-1b3j1da/ Position officielle de l’ANSSI sur l’état de la transposition et la séquence loi / décrets / arrêtés. Page dont la dernière mise à jour date de septembre 2025 : à recouper avec l’actualité parlementaire.

« Article 226-17 du code pénal » — Légifrance https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000037825504 Fondement du risque pénal réellement existant en droit français : cinq ans d’emprisonnement et 300 000 € d’amende pour absence de mise en œuvre des mesures de sécurité exigées par le RGPD. Antérieur à NIS2 et indépendant de sa transposition.

En 2025, cette chronique avait posé les fondamentaux de la communication de crise : parler vite, même pour dire qu’on enquête. Un canal officiel unique. Un porte-parole désigné. Une vérité partielle, assumée, plutôt qu’un silence prudent.

Rien de ce qui suit n’invalide ces principes. Ils tiennent. Ils ont même été confirmés par une année dense en ruptures.

Mais l’épisode 034 a montré qu’une organisation peut être attaquée par le récit avant de l’être par le code. L’épisode 018 avait établi qu’une crise produit toujours un récit, que vous l’écriviez ou non. Cette chronique fait la jonction entre les deux : quand la rupture est là, comment reprend-on la main sur la parole ?

Trois déplacements ont marqué 2026. La vitesse de propagation, qui a réduit la fenêtre de réaction à quelques minutes. L’exigence de transparence, qui n’est plus une posture mais un calendrier réglementaire opposable. Et l’authenticité de la parole elle-même, désormais falsifiable.

👉 La vraie question n’est plus : que dire ? Elle est : à quelle vitesse, sous quelle contrainte légale, et comment prouver que c’est bien vous qui parlez ?

I. La fenêtre s’est refermée

Le principe de 2025 — « parler vite » — supposait qu’une organisation disposait de quelques heures pour se structurer. Ce délai n’existe plus.

Trois phénomènes se cumulent. Les pannes majeures se concentrent sur un petit nombre de fournisseurs partagés, ce qui rend chaque incident immédiatement visible à l’échelle de milliers d’organisations. Les utilisateurs disposent d’outils de détection collective plus rapides que vos propres remontées internes. Et les attaques les plus fréquentes sont précisément celles qui produisent une visibilité maximale : l’ENISA relève que les attaques par déni de service représentent 76,7 % des incidents enregistrés dans son panorama 2025, très majoritairement d’origine hacktiviste — donc conçues pour être vues.

S’ajoute une réalité que 2026 a rendue tangible : l’incident n’est plus forcément chez vous. Le suivi des perturbations Internet du premier trimestre montre des pannes provoquées par des effondrements de réseaux électriques nationaux, des coupures décidées par des États, et même des centres de données de fournisseur cloud endommagés par des frappes de drones au Moyen-Orient début mars.

Conséquence directe : vos clients apprennent souvent la panne avant votre cellule de crise. Votre premier message n’est plus une annonce. C’est une reprise en main d’une conversation déjà commencée.

👉 Vous ne communiquez plus dans le silence. Vous communiquez dans un bruit déjà installé — et le premier message crédible emporte le cadrage.

II. La transparence est devenue un calendrier, pas une posture

C’est le deuxième déplacement de 2026, et le plus structurant pour les décideurs.

L’article 23 de la directive NIS2 pose une séquence en trois temps : une alerte précoce sous 24 heures, une notification circonstanciée sous 72 heures, un rapport final sous un mois. Il ajoute une obligation moins commentée mais tout aussi contraignante : informer les destinataires des services d’un incident important, et leur indiquer les mesures qu’ils peuvent prendre. Et il autorise l’autorité compétente à informer le public elle-même lorsque les circonstances le justifient.

Traduction opérationnelle : la transparence n’est plus arbitrable en interne. Elle est datée, tracée, et opposable.

En France, la mise en œuvre reste en cours à la fin août 2026. La loi de transposition n’est pas encore stabilisée, mais l’ANSSI diffuse depuis le 17 mars 2026 le Référentiel Cyber France comme document de travail. Attendre le texte définitif pour construire ses procédures de notification revient à préparer sa réponse pendant la crise.

Le vrai piège n’est pas juridique, il est temporel. Le calendrier réglementaire est calé sur la qualification technique de l’incident. Le calendrier médiatique, lui, court dès la première minute d’indisponibilité visible. Les deux ne sont pas alignés, et beaucoup d’organisations découvrent cet écart le jour où il coûte cher.

👉 Le régulateur vous impose un rythme. Le public vous en impose un autre, plus rapide. Une communication de crise mature tient les deux horloges en parallèle, pas l’une après l’autre.

III. Votre parole peut désormais être fabriquée

Voici la nouveauté 2026 que peu de plans de communication intègrent.

Jusqu’ici, le risque communicationnel en crise était l’erreur, la contradiction ou la fuite. Il faut y ajouter l’usurpation. Le contenu synthétique de qualité est devenu accessible, rapide et bon marché : l’ENISA relève que plus de 80 % des courriels de phishing identifiés entre septembre 2024 et février 2025 mobilisaient déjà des outils d’IA, et documente l’usage de deepfakes dans les campagnes d’usurpation d’identité.

Le scénario n’a rien de théorique. Pendant une rupture de service, votre organisation est justement dans l’état où une fausse communication devient plausible : les canaux sont saturés, les collaborateurs cherchent des consignes, les clients cherchent une explication. Un faux communiqué annonçant une fuite de données, un message vocal imitant un dirigeant, une vidéo de trente secondes suffisent à détourner le récit.

C’est l’exact prolongement de l’épisode 034 : la désinformation ne vise plus seulement à raconter autre chose que vous. Elle vise à parler à votre place.

Le cadre européen bouge sur ce point. Depuis le 2 août 2026, l’article 50 du règlement européen sur l’IA impose aux déployeurs de divulguer les contenus manipulés dès la première exposition, et aux fournisseurs d’apposer un marquage lisible par machine. C’est utile. Ce n’est pas protecteur : un attaquant ne respecte pas une obligation de marquage.

👉 La preuve d’authenticité ne viendra pas de la réglementation. Elle doit être organisée par vous, avant la crise, sur vos propres canaux.

IV. La grille des quatre fenêtres

Voici une grille de lecture opérationnelle, construite pour tenir les deux horloges de la section II. Elle ne remplace pas votre plan : elle en teste la complétude.

Trois erreurs classiques que cette grille révèle immédiatement :

• La page de statut hébergée sur l’infrastructure en panne. Elle tombe avec le reste, au pire moment.
• La cadence non annoncée. Dire « prochain point à 14 h » vaut mieux que promettre « des informations dès que possible ».
• Le RETEX non planifié en amont, donc jamais fait, donc jamais capitalisé.

👉 Si une seule colonne « ce qui doit déjà exister » est vide, votre plan repose sur l’improvisation d’une équipe fatiguée.

V. La checklist d’authenticité

Complément direct de la section III. Six points, activables en une réunion.

• Un canal de référence identifié publiquement. Une seule adresse, connue et communiquée à froid, où les parties prenantes savent qu’elles trouveront la parole officielle.
• Une redondance hors périmètre. Le canal de crise ne doit dépendre ni de votre messagerie, ni de votre hébergeur principal.
• Un signe de reconnaissance convenu. Signature cryptographique, mot de passe de rappel entre membres de la cellule, procédure de contre-appel pour toute consigne inhabituelle reçue en crise.
• Une règle de double validation. Aucune instruction financière ou technique sensible n’est exécutée sur la seule base d’un appel, d’une visio ou d’un message vocal.
• Une veille sur votre propre nom. Pendant la crise, quelqu’un doit surveiller ce qui se dit en votre nom, pas seulement ce qui se dit de vous.
• Un message de démenti pré-rédigé. Court, factuel, renvoyant au canal de référence. Sa rédaction à chaud coûte des heures que vous n’aurez pas.

Sur ce terrain, l’ANSSI a publié en juin 2026 une nouvelle version de son guide « Anticiper et gérer sa communication de crise cyber », structurée en dix fiches et une checklist. C’est aujourd’hui le document de référence le plus directement exploitable en français, nourri de l’accompagnement de victimes réelles.

👉 L’authenticité ne se déclare pas en crise. Elle se pré-installe à froid, sur des canaux que vous contrôlez.

VI. Le révélateur de maturité

Reste la dimension qui intéresse un COMEX.

La communication de crise est le seul moment où l’organisation est observée de l’extérieur en train de fonctionner. Elle expose en quelques heures ce que les audits mettent des mois à documenter : la clarté des rôles, la qualité des remontées d’information, la capacité de la direction générale à arbitrer sous incertitude.

Une communication confuse n’est presque jamais un problème de communicants. C’est le symptôme d’une chaîne de décision qui ne sait pas qui tranche, d’une cartographie des dépendances incomplète, ou d’une culture où remonter une mauvaise nouvelle coûte plus cher que la taire.

Le Panorama de la cybermenace 2025 publié par l’ANSSI en mars 2026 souligne d’ailleurs une difficulté croissante à caractériser et attribuer les attaques, dans un contexte où la frontière entre acteurs étatiques et criminels s’estompe. Traduction : vous communiquerez de plus en plus souvent sans savoir précisément qui vous a frappé, ni pourquoi. Ce n’est pas une raison de se taire. C’est une raison de savoir dire proprement ce que l’on ignore.

La norme ISO 22361 place d’ailleurs la communication de crise au même rang que le leadership et la prise de décision. Ce n’est pas un chapitre annexe. C’est un pilier.

👉 Ce n’est pas un sujet de communicants. C’est un choix de gouvernance, rendu visible sous contrainte.

L’ESSENTIEL POUR AGIR

1. Testez votre premier message, pas votre plan : Chronométrez le délai réel entre la détection d’une indisponibilité visible et la publication d’un message officiel daté. Si ce délai dépasse une heure, aucune autre optimisation ne compte. C’est votre indicateur le plus honnête.

2. Alignez les deux horloges : Placez côte à côte votre calendrier de notification réglementaire (24 h / 72 h / un mois) et votre calendrier de communication publique. Identifiez qui arbitre les écarts entre les deux, et faites valider cet arbitrage par la direction générale à froid, pas en cellule de crise.

3. Pré-installez la preuve d’authenticité : Déployez les six points de la checklist de la section V avant votre prochain exercice. Puis testez-les : injectez un faux communiqué dans votre prochain exercice de crise et observez combien de temps il faut à l’organisation pour le qualifier.

CONCLUSION

La communication de crise ne consiste pas à contrôler le récit. Elle consiste à rester la source la plus rapide, la plus datée et la plus vérifiable de sa propre histoire.

2026 a durci les trois conditions de cet exercice : moins de temps, plus d’obligations, et un doute nouveau sur l’origine des messages. Aucune de ces contraintes n’est insurmontable. Toutes se préparent à froid.

Sans capacité à prouver que c’est bien vous qui parlez, tout le reste est cosmétique.

Reste une question que cette chronique n’a fait qu’effleurer. Quand la crise est passée, quand les messages ont été envoyés et les délais tenus, qui répond de ce qui a été dit — et de ce qui ne l’a pas été ? La transparence a une suite logique, et elle porte un nom moins confortable.

Une organisation ne se juge pas à ce qu’elle promet en temps calme. Elle se juge à ce qu’elle assume à voix haute pendant que tout tombe.

Bibliographie

« Anticiper et gérer sa communication de crise cyber » — ANSSI, nouvelle version, juin 2026 https://messervices.cyber.gouv.fr/guides/anticiper-et-gerer-sa-communication-de-crise-cyber Document de référence francophone le plus directement opérationnel : dix fiches et une checklist, construites à partir de l’accompagnement de victimes réelles de cyberattaques. Base recommandée pour construire ou réviser un plan de communication de crise.

« Directive (UE) 2022/2555 (NIS 2) » — Journal officiel de l’Union européenne https://eur-lex.europa.eu/eli/dir/2022/2555/oj Texte source des obligations de notification (article 23) : alerte précoce sous 24 heures, notification sous 72 heures, rapport final sous un mois, information des destinataires des services et possibilité pour l’autorité d’informer le public.

« Transparency obligations under Article 50 of the AI Act » — Commission européenne https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act FAQ officielle précisant les obligations applicables depuis le 2 août 2026 : divulgation des contenus manipulés par les déployeurs et marquage lisible par machine par les fournisseurs. Cadre de référence pour traiter le risque deepfake dans la communication de crise.

« ENISA Threat Landscape » — Agence de l’Union européenne pour la cybersécurité https://www.enisa.europa.eu/topics/cyber-threats/threat-landscape Panorama annuel de la menace européenne (édition 2025, 4 875 incidents analysés). Source des données citées sur la part des attaques par déni de service et sur l’usage de l’IA dans les campagnes d’ingénierie sociale et d’usurpation.

« Panorama de la cybermenace 2025 » — ANSSI, publié le 11 mars 2026 https://cyber.gouv.fr/nous-connaitre/publications/panoramas-de-la-cybermenace/panorama-de-la-cybermenace-2025/ Analyse annuelle de la menace visant la France. Documente l’estompement de la frontière entre acteurs étatiques et criminels, et la difficulté croissante de caractérisation et d’attribution — deux facteurs qui pèsent directement sur ce qu’une organisation peut affirmer publiquement en crise.

« ISO 22361:2022 — Security and resilience — Crisis management — Guidelines » https://www.iso.org/standard/50267.html Norme internationale de gestion de crise. Elle traite la communication de crise (chapitre 8) au même niveau que le leadership et la prise de décision, ce qui fonde l’argument de gouvernance développé dans cette chronique.

L’épisode 033 refermait une année de construction sur une question simple : que pouvez-vous prouver ? Preuves, documentation, posture — l’audit comme épreuve de vérité interne.

Cette semaine, la vérité change de camp. Elle n’est plus ce que vous démontrez à un contrôleur. Elle est ce que vos parties prenantes croient.

En 007, nous avons vu que l’image et la voix d’un dirigeant pouvaient être clonées en flux direct. En 022, que la géopolitique était devenue un paramètre d’architecture. Ces deux fils se rejoignent ici, sur un terrain que la plupart des dispositifs de sécurité ne couvrent pas : le récit.

L’ENISA a consacré un chapitre entier de son panorama des menaces 2025 à la manipulation de l’information. Ce n’est pas un signal faible. C’est l’aveu qu’un pan entier de la menace échappe aux outils construits pour la détecter.

Alors la vraie question n’est pas : comment démentir plus vite ? C’est : qui, dans votre organisation, est responsable de ce que les autres croient de vous ?

I. La cible s’est déplacée

Pendant vingt ans, la sécurité s’est organisée autour d’un objet : le système d’information. Périmètre, actifs, vulnérabilités, journaux. Tout notre outillage suppose que l’attaquant vient chercher quelque chose chez vous.

La manipulation informationnelle inverse le postulat. Elle ne cherche rien chez vous. Elle travaille sur ce que les autres pensent de vous : clients, salariés, régulateur, marché, candidats, partenaires.

Le vocabulaire européen a d’ailleurs tranché. Le concept de FIMI — manipulation de l’information et ingérence étrangère — porté par le Service européen pour l’action extérieure puis repris par l’ENISA, déplace délibérément l’analyse : ce que l’on qualifie, ce n’est pas la fausseté du contenu, c’est le caractère manipulatoire du comportement.

La nuance est décisive. Elle sort le sujet du débat sur la vérité — insoluble, interminable, épuisant — pour le ramener sur un terrain que les équipes sécurité maîtrisent : des acteurs, des modes opératoires, des chaînes de diffusion.

👉 La désinformation n’est pas un problème de vérité. C’est un problème de comportement adverse. Donc un problème de sécurité.

II. Trois angles morts du dispositif classique

Pourquoi un SOC mature ne voit-il rien passer ?

• Pas de journal. L’attaque se déroule sur des plateformes que vous ne possédez pas, avec des comptes que vous n’administrez pas. Aucune télémétrie ne remonte.
• Pas de périmètre. Ni intrusion, ni exploitation de vulnérabilité, ni franchissement. Souvent, aucune infraction caractérisée.
• Pas de seuil. Un pic de mentions n’est pas une alerte. Sans critère de qualification, tout est bruit — ou rien ne l’est.

S’ajoute une asymétrie troublante : la compromission peut être revendiquée sans avoir eu lieu. Un groupe publie votre nom sur un site de fuite, joint quelques fichiers anodins récupérés ailleurs, et vous voilà à prouver une absence. Exercice notoirement difficile, y compris devant un régulateur.

👉 Une attaque qui ne laisse aucune trace dans vos journaux reste une attaque.

III. Cinq formes d’atteinte au capital confiance

Toutes ne relèvent pas de l’ingérence étatique. La plupart sont à la portée d’un concurrent, d’un militant, d’un ancien salarié ou d’un groupe d’extorsion.

1. L’extorsion sans intrusion. Revendication publique d’une compromission inexistante ou largement exagérée, pour forcer un paiement ou une réaction précipitée.
2. Le faux communiqué. Annonce financière, rappel produit, prise de position fabriquée puis relayée avant toute vérification.
3. La fuite empoisonnée. Documents authentiques et pièces falsifiées mélangés dans le même lot. Le vrai crédibilise le faux.
4. L’usurpation de porte-parole. Le deepfake du 007, appliqué non plus à l’ingénierie sociale interne, mais à la parole publique.
5. L’instrumentalisation d’un incident réel. Une panne ordinaire transformée en preuve d’incompétence, de dissimulation ou de défaillance systémique.

Le dénominateur commun mérite qu’on s’y arrête : dans quatre cas sur cinq, une partie du matériel diffusé est authentique. C’est précisément ce qui rend le démenti global inopérant — et souvent contre-productif.

👉 On ne réfute pas un mensonge partiel avec une vérité générale.

IV. Un risque sans propriétaire

Posez la question en comité de direction : qui pilote ce risque ?

Le RSSI répondra que ce n’est pas un incident de sécurité — ni compromission, ni périmètre, ni indicateur. La communication répondra qu’elle ne dispose ni de la capacité de détection ni de l’analyse technique. Le juridique demandera d’attendre la qualification. La direction générale découvrira le sujet quand il sera déjà sur les écrans.

Personne ne ment. Chacun a raison depuis sa fonction. Et c’est exactement ainsi qu’un risque devient orphelin.

L’épisode 033 rappelait qu’un contrôle ne mesure pas ce que vous faites, mais ce que vous pouvez démontrer. Appliquons la même exigence ici. Où est écrit qui décide de répondre ? Selon quels critères ? Dans quel délai ? Avec quelle validation, et quelle trace ?

Ne pas réagir est très souvent la bonne décision. Mais ne pas réagir faute d’avoir décidé n’est pas une décision. C’est une absence.

👉 Un risque sans propriétaire n’est pas un risque accepté. C’est un risque ignoré.

V. Détecter sans se noyer

La bonne nouvelle : le sujet s’outille, et il s’outille avec vos méthodes.

Le référentiel DISARM transpose la logique de MITRE ATT&CK aux opérations informationnelles. Un cadre « rouge » décrit les tactiques et techniques adverses, un cadre « bleu » les contre-mesures associées. Il est interopérable avec les formats STIX et MISP : votre équipe CTI peut l’ingérer sans changer de chaîne d’outils, et rattacher une opération informationnelle à un mode opératoire déjà suivi.

Reste à définir un périmètre de veille tenable. Quatre familles suffisent pour démarrer :

• Marque et dirigeants : mentions, usurpations de comptes, domaines typosquattés.
• Revendications : sites de fuite, forums spécialisés, canaux des groupes d’extorsion.
• Produits et services critiques : rumeurs de défaillance, faux rappels, avis coordonnés.
• Dépendances : ce qui se dit de vos fournisseurs clés vous concerne directement (cf. 022).

Attention à l’illusion outillée, déjà rencontrée sur la gestion des vulnérabilités. Une plateforme de veille sans critère de qualification produit des tableaux de bord, pas de la décision.

👉 Surveiller sans seuil d’alerte, c’est acheter du bruit au prix de l’information.

VI. Arbitrer la réponse : la matrice visibilité × crédibilité

C’est ici que se joue l’essentiel. Et c’est ici que l’on se trompe le plus souvent : répondre à un narratif confidentiel, c’est lui offrir l’audience qui lui manquait.

Deux variables suffisent à trancher. La visibilité effective — l’audience réelle, pas la volumétrie de mentions — et la crédibilité perçue par vos parties prenantes, qui n’a rien à voir avec la véracité des faits.

Deux repères pour l’usage :

• La matrice se relit toutes les heures en phase active. Une situation migre vite d’une case à l’autre, et presque toujours vers la droite.
• La case « Observer » exige la même rigueur documentaire que les autres. C’est elle qui justifiera, a posteriori, de n’avoir rien fait.

👉 Répondre est une option, pas un réflexe. Le choix se documente comme n’importe quel arbitrage de crise.

VII. Ce qui se prépare avant

Une crise informationnelle se gagne ou se perd sur des acquis antérieurs.

Le canal de référence

Une page d’information officielle, connue de vos parties prenantes, hébergée hors de votre infrastructure principale (cf. 002 sur les dépendances). Si votre seul canal de parole tombe en même temps que votre SI, vous n’avez plus de voix au moment précis où il faudrait en avoir une.

La preuve d’origine

Les mécanismes de certification de contenu évoqués en 007 prennent tout leur sens ici. Signer ses communications officielles ne rend pas le faux impossible : cela le rend coûteux à produire et rapide à écarter.

Le scénario informationnel dans l’exercice de crise

L’ISO 22361 consacre un chapitre entier à la communication de crise et fait de l’entraînement une composante à part entière de la capacité. Un exercice purement technique n’entraîne que la moitié du dispositif.

La réserve de crédibilité

C’est l’actif le moins mesuré et le plus déterminant. Une organisation qui communique honnêtement en temps calme dispose d’un capital de doute favorable en temps de crise. L’inverse est vrai aussi, et se paie très cher.

👉 On ne construit pas la confiance pendant la crise. On la dépense.

L’essentiel pour agir

1. Nommer un propriétaire du risque informationnel : Une personne, pas un comité. Son rôle n’est pas de communiquer, mais de qualifier et de déclencher. Sans nom en face du risque, la matrice de la section VI restera un document de plus.

2. Étendre le périmètre de veille au capital marque : Ajoutez à votre veille CTI existante les quatre familles de la section V. Le coût marginal est faible, l’angle mort supprimé est considérable.

3. Injecter un volet informationnel dans le prochain exercice de crise : Même scénario technique, mais avec une rumeur qui circule pendant que les équipes restaurent. C’est le test le plus révélateur de la coordination réelle entre sécurité, communication et direction générale.

Conclusion

La résilience ne consiste pas à empêcher qu’on parle mal de vous. Elle consiste à rester lisible, cohérent et crédible quand cela arrive.

L’attaque informationnelle est peut-être la plus honnête des menaces : elle ne révèle rien d’autre que l’état réel de votre relation avec vos parties prenantes. Un dispositif technique se remplace en quelques semaines. Une réputation se reconstitue en années.

Reste une question que ni la technique ni la communication ne tranchent. Quand la confiance est atteinte, quelqu’un doit en répondre — devant un conseil, un régulateur, parfois un tribunal. Nous verrons la semaine prochaine ce que cette responsabilité recouvre exactement, et sur qui elle pèse réellement.

Vos serveurs, on vous les rendra. Votre crédibilité, personne ne vous la restituera.

Bibliographie

« ENISA Threat Landscape 2025 » https://www.enisa.europa.eu/sites/default/files/2026-01/ENISA%20Threat%20Landscape%202025_v1.2.pdf Le panorama annuel des menaces de l’agence européenne de cybersécurité consacre un chapitre distinct à la manipulation de l’information et à l’ingérence étrangère. Il acte l’intégration du sujet dans le champ de la cybersécurité opérationnelle.

« 4th EEAS Annual Report on Foreign Information Manipulation and Interference Threats (mars 2026) » https://www.eeas.europa.eu/eeas/4th-eeas-annual-report-foreign-information-manipulation-and-interference-threats_en Le rapport annuel du Service européen pour l’action extérieure documente les modes opératoires observés et propose un cadre de dissuasion visant les infrastructures et intermédiaires qui soutiennent ces opérations.

« VIGINUM / SGDSN — Protection du débat public contre les ingérences numériques étrangères durant les élections municipales des 15 et 22 mars 2026 » https://www.sgdsn.gouv.fr/viginum/publications/protection-du-debat-public-contre-les-ingerences-numeriques-etrangeres-durant Rapport public français décrivant quatre opérations détectées, leurs narratifs, leurs chaînes de diffusion et les leviers de réponse mobilisés. Une référence utile pour comprendre ce que « caractériser » une opération signifie concrètement.

« VIGINUM / SGDSN — Intelligence artificielle générative et manipulation de l’information (février 2025) » https://www.sgdsn.gouv.fr/files/files/Publications/20250207_NP_SGDSN_VIGINUM_Rapport%20menace%20informationnelle%20IA_VF.pdf Documente les cas d’usage observés de l’IA générative à des fins d’ingérence. Prolonge directement les constats de l’épisode 007 sur l’industrialisation des contenus synthétiques.

« DISARM Frameworks — DISARM Foundation » https://github.com/DISARMFoundation/DISARMframeworks Référentiel ouvert des tactiques, techniques et procédures des opérations informationnelles (cadre « rouge ») et de leurs contre-mesures (cadre « bleu »), construit sur le modèle de MITRE ATT&CK et interopérable avec STIX et MISP.

« ISO 22361:2022 — Sécurité et résilience : management de crise — Lignes directrices » https://www.iso.org/standard/50267.html La norme de référence sur la capacité stratégique de gestion de crise. Son chapitre consacré à la communication de crise et son volet entraînement fondent la section VII de cette chronique.

Le trimestre qui s’achève nous a emmenés loin dans la machine. SOC de nouvelle génération, détection industrialisée, IA offensive, algorithmes de décision, équilibre humain-machine : le T3 a exploré ce que l’intelligence apporte - et ce qu’elle coûte - à la résilience.

Le T4 change de registre. On quitte les outils pour la gouvernance, la redevabilité et la culture. Et il commence par le sujet le plus concret qui soit : l’épreuve du contrôle.

NIS2 est cité dans cette chronique depuis le premier épisode. Nous l’avons croisée en parlant de « shift left » et de Compliance as Code (005), de cartographie des dépendances, de conformité continue (029), d’assurabilité (030). Le moment est venu de la regarder pour ce qu’elle est en train de devenir : un rendez-vous.

Un rendez-vous dont la date, en France, reste étrangement floue - et c’est précisément ce qui rend la préparation risquée.

La vraie question n’est pas : sommes-nous conformes ? C’est : sommes-nous capables de le démontrer ?

1. Le paradoxe français : une échéance sans date

L’échéance européenne de transposition de NIS2 était fixée au 17 octobre 2024. La France ne l’a pas tenue, et le retard s’est installé dans la durée.

Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité - qui transpose d’un seul mouvement les directives REC et NIS2 ainsi que des dispositions liées à DORA - a été adopté par le Sénat le 12 mars 2025, puis par une commission spéciale de l’Assemblée nationale le 10 septembre 2025. Le dossier législatif ne va pas plus loin à ce jour.

Beaucoup en tirent une conclusion rassurante : sans loi, pas d’obligation, donc pas d’urgence. Le raisonnement est juridiquement défendable et opérationnellement dangereux, pour trois raisons.

• Le contenu, lui, est stabilisé. Depuis le 17 mars 2026, l’ANSSI diffuse le Référentiel Cyber France (ReCyF), document de travail listant les mesures recommandées pour atteindre les objectifs de sécurité fixés par NIS2. Non obligatoire par défaut, il pourra être invoqué par les entités qui l’appliquent en cas de contrôle.

• Une partie du dispositif ne dépend pas de la France. Le règlement d’exécution (UE) 2024/2690 est d’application directe : pour les fournisseurs cloud, centres de données, CDN, MSP, MSSP, registres de noms de domaine ou prestataires de services de confiance, les exigences techniques sont déjà posées.

• Le temps de préparation ne se rattrape pas. Constituer un historique de revues annuelles, de comptes rendus d’exercices et de décisions tracées demande des mois. Une loi promulguée n’accélère pas la production de preuves passées.

L’incertitude porte sur le calendrier, pas sur le contenu. Attendre la date, c’est renoncer au seul avantage dont on dispose encore : le temps.

2. Ce qu’un contrôle regarde vraiment

Un contrôle n’évalue pas votre sécurité. Il évalue ce que vous pouvez lui montrer de votre sécurité. La nuance paraît triviale. Elle est structurante.

L’ENISA a publié en juin 2025 un guide technique d’implémentation adossé au règlement d’exécution. Sa particularité mérite d’être soulignée : pour chaque exigence, il propose non seulement des recommandations de mise en œuvre, mais aussi des exemples de preuves - les types d’éléments qui permettent d’établir qu’une exigence est en place.

C’est un document non contraignant, et l’ENISA précise elle-même qu’exiger l’intégralité des preuves listées relèverait d’une supervision très stricte. Mais en l’absence de doctrine de contrôle française publiée, c’est la meilleure grille de lecture disponible.

Ce qu’on y lit, en creux, c’est qu’une preuve utile réunit trois qualités.

• Elle existe : le document, le registre, le journal, l’enregistrement.

• Elle est approuvée : par qui, à quel niveau, à quelle date. La date d’approbation formelle par l’organe de direction est explicitement attendue dans la politique de sécurité.

• Elle est vivante : revue au moins annuellement, versionnée, avec un historique de modifications et une trace des décisions prises à l’issue de la revue.

Un document non daté et non approuvé n’est pas une preuve. C’est une intention.

3. La documentation : moins de classeurs, plus de traçabilité

Une idée fausse circule : NIS2 imposerait une inflation documentaire. La réalité est plus nuancée.

Le règlement d’exécution structure la documentation autour d’une politique de sécurité des réseaux et systèmes d’information - document de plus haut niveau, approuvé par l’organe de direction - complétée par une dizaine de politiques thématiques : gestion des risques, gestion des incidents, sécurité de la chaîne d’approvisionnement, tests de sécurité, évaluation de l’efficacité des mesures, cryptographie, contrôle d’accès, comptes à privilèges, traitement des actifs, supports amovibles.

Documenter ces sujets est obligatoire. Le format ne l’est pas. L’entité reste libre de produire des documents séparés, d’enrichir des politiques existantes, ou de tout regrouper dans un corpus unique.

Autrement dit : personne ne vous demande dix classeurs. On vous demande de pouvoir répondre, sur chacun de ces dix sujets, à quatre questions - que dit la règle, qui l’a approuvée, quand a-t-elle été revue, et comment vérifie-t-on qu’elle s’applique.

C’est exactement l’esprit du Compliance as Code évoqué dans l’épisode 005 et prolongé en 029 : la règle n’a de valeur que si sa vérification est outillée et répétable. Une politique dont le respect ne se mesure nulle part est un texte, pas un contrôle.

L’exigence porte sur la traçabilité, pas sur le volume. Un corpus court et tenu vaut mieux qu’une bibliothèque abandonnée.

4. Huit dossiers de preuve : la grille de préparation

Voici une grille de travail directement exploitable. Pour chaque domaine : la preuve type attendue, et le signal de faiblesse le plus fréquemment observé - celui qui transforme une organisation réellement solide en organisation difficilement démontrable.

Cette grille n’est pas exhaustive et ne se substitue à aucun référentiel. Elle sert à un exercice précis : passer en revue chaque ligne et répondre par oui ou par non à la question « si on me le demandait demain matin, qu’est-ce que je sors du tiroir, et est-ce daté ? ».

Le résultat de cet exercice est presque toujours le même. Les écarts ne portent pas sur les mesures de sécurité elles-mêmes. Ils portent sur leur formalisation : des choses faites, bien faites, mais non tracées.

Faites l’exercice à froid, sans enjeu. Un écart identifié six mois avant un contrôle est un plan d’action. Découvert pendant, c’est un constat.

5. Le piège de la documentation morte

Le risque le plus courant n’est pas l’absence de documentation. C’est sa fossilisation.

Le guide de l’ENISA revient avec insistance sur une exigence : réviser au moins annuellement, et à chaque incident significatif ou changement majeur d’activité ou de risque. Politique de sécurité, rôles et responsabilités, analyse de risques, plan de traitement, procédures de réponse à incident, périmètre de journalisation. Tous portent la même mention.

Et à chaque fois, la preuve attendue est du même ordre : un historique de versions, un journal de modifications, un compte rendu de revue, une trace d’approbation. Ce ne sont pas des artefacts bureaucratiques. Ce sont les seuls éléments qui distinguent un dispositif piloté d’un dispositif abandonné.

Trois symptômes doivent alerter :

• une politique dont la dernière version date de plus de deux ans, dans une organisation qui a changé de SI, de prestataires ou de périmètre ;

• un plan de continuité complet, cohérent, et dont aucun compte rendu d’exercice n’existe ;

• une revue de conformité conduite par la personne qui pilote le périmètre audité - l’impartialité de la revue indépendante est une exigence explicite, et une séparation hiérarchique impossible doit être compensée par des mesures documentées.

La parade est connue et elle rejoint l’automatisation défendue tout au long du T3 : plus la production de preuve est adossée aux outils qui exécutent déjà les contrôles, moins elle dépend de la disponibilité d’une équipe un vendredi soir. Une preuve générée est une preuve tenue.

Ce qui n’est pas revu n’est pas maintenu. Ce qui n’est pas daté n’est pas prouvable.

6. La direction dans la boucle : ce qui change vraiment

C’est le déplacement de fond de NIS2, et il est trop souvent traité comme une formalité.

Le ReCyF pose que le dirigeant exécutif de l’entité est responsable de la sécurité numérique en son sein, et en particulier du suivi de la conformité des systèmes d’information aux mesures attendues. Le règlement d’exécution exige que la politique de sécurité soit approuvée par l’organe de direction, que les résultats des revues indépendantes lui soient rapportés, que les risques résiduels soient formellement acceptés, et qu’au moins une personne lui rende compte directement sur les sujets de sécurité.

Le projet de loi français va plus loin encore, en prévoyant que la responsabilité des dirigeants puisse être engagée, avec la possibilité de suspendre temporairement l’exercice de fonctions de direction en cas de manquement grave d’une entité essentielle.

Les preuves attendues à ce niveau sont d’une simplicité désarmante - et souvent absentes : procès-verbaux de comités où la sécurité figure à l’ordre du jour, décisions d’allocation de ressources, attestations de formation des dirigeants, relevés de décisions d’acceptation de risque.

L’épisode 032 concluait le T3 sur l’équilibre humain-machine : ce que l’on automatise, ce que l’on garde en jugement humain. On retrouve ici la même logique, un cran plus haut. L’arbitrage réglementaire ne s’automatise pas et ne se sous-traite pas. Il se signe.

La conformité NIS2 ne se délègue pas au RSSI. Elle s’instruit par le RSSI et se décide en comité de direction.

7. Capitaliser : vous avez déjà une partie du dossier

Rien de tout cela n’impose de repartir d’une page blanche. Trois leviers existent, et ils sont sous-utilisés.

• Les certifications déjà détenues. Le ReCyF prévoit qu’un système de management de la sécurité de l’information certifié ISO/IEC 27001:2022 puisse être invoqué lors d’un contrôle pour apporter une présomption de conformité - sur les systèmes couverts par la certification. La restriction de périmètre est la clé : une certification qui ne couvre qu’un service ne démontre rien au-delà.

• Les prestations qualifiées. Le recours à une prestation d’accompagnement et de conseil en sécurité qualifiée par l’ANSSI peut également être présenté lors d’un contrôle, notamment pour la préparation du dispositif de gestion de crise.

• Les correspondances entre référentiels. L’ANSSI met à disposition un outil de comparaison entre le ReCyF et les autres référentiels, normes et réglementations existants. L’ENISA publie de son côté une table de correspondances vers ISO/IEC 27001 et 27002, le NIST Cybersecurity Framework 2.0 et d’autres cadres.

Une réserve, toutefois, et elle est de taille : ces correspondances ne sont pas des équivalences. Deux référentiels peuvent traiter le même sujet avec des niveaux d’exigence différents. Le mapping sert à éviter les doublons d’audit et à réutiliser des preuves existantes - pas à conclure qu’un contrôle est déjà satisfait.

On ne repart pas de zéro. Mais on vérifie ce que le périmètre couvre réellement, avant de s’en prévaloir.

L’Essentiel pour Agir

1. Constituez le dossier avant d’attendre le décret —

Le calendrier législatif est incertain, le contenu ne l’est plus. Prenez la grille des huit domaines, désignez un porteur par ligne, et fixez-vous une date de revue collective. L’objectif n’est pas d’être parfait : c’est de savoir précisément où sont vos trous.

2. Datez, approuvez, versionnez —

Trois gestes qui ne coûtent presque rien et qui transforment un document en preuve. Chaque politique doit porter une date d’approbation, un niveau d’approbation, un numéro de version et une date de prochaine revue. Sans cela, votre travail réel reste invisible pour un contrôleur.

3. Faites entrer la direction dans la boucle documentaire —

Mettez la sécurité à l’ordre du jour d’un comité de direction, faites-en un relevé de décisions, tracez l’acceptation des risques résiduels et la formation des dirigeants. C’est la catégorie de preuve la plus rapide à produire et la plus systématiquement absente.

Conclusion

La résilience ne consiste pas à cocher des cases avant une échéance. Elle consiste à tenir, dans la durée, un dispositif dont on peut rendre compte à tout moment - parce qu’il est piloté, revu, et signé par ceux qui en portent la responsabilité.

L’audit NIS2 ne mesurera pas la qualité de vos équipes. Il mesurera votre capacité à en apporter la preuve. Ce sont deux choses différentes, et la seconde ne s’improvise pas.

Reste une question que ce premier épisode du trimestre laisse ouverte. Une fois le dossier constitué, à qui rend-on compte, à quelle fréquence, et avec quels chiffres ? Documenter est une chose. Piloter par la mesure, sans se raconter d’histoires, en est une autre - et c’est là que la plupart des tableaux de bord se révèlent rassurants plutôt qu’utiles.

Un contrôle ne se prépare pas. Il se subit ou il se traverse - selon ce qu’on a écrit avant.

Bibliographie

« La directive NIS 2 - ANSSI »

https://cyber.gouv.fr/reglementation/cybersecurite-systemes-dinformation/directives-nis-nis2-et-dispositif-saiv/directive-nis-2/

Le portail officiel de l’autorité nationale : état de la transposition, accès au Référentiel Cyber France (ReCyF) et au comparateur de référentiels. La source de vérité sur le calendrier français.

« NIS 2 : l’ANSSI poursuit et renforce sa dynamique d’accompagnement - ANSSI »

https://cyber.gouv.fr/actualites/nis-2-lanssi-poursuit-et-renforce-sa-dynamique-daccompagnement/

Présentation du ReCyF, de son principe de proportionnalité et de l’outil de comparaison avec les référentiels existants. Utile pour calibrer l’effort attendu selon la maturité de l’entité.

« Technical Implementation Guidance on Cybersecurity Risk-Management Measures - ENISA (juin 2025) »

https://www.enisa.europa.eu/sites/default/files/2025-06/ENISA_Technical_implementation_guidance_on_cybersecurity_risk_management_measures_version_1.0.pdf

Le document qui liste, exigence par exigence, des exemples de preuves attendues. C’est la meilleure grille de lecture publique pour construire un dossier de contrôle.

« Règlement d’exécution (UE) 2024/2690 de la Commission du 17 octobre 2024 »

https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R2690

Le texte qui fixe les exigences techniques et méthodologiques pour les acteurs numériques transfrontaliers, et précise les critères d’incident important. Directement applicable, sans attendre la loi nationale.

« Projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité - Dossier législatif, Assemblée nationale »

https://www.assemblee-nationale.fr/dyn/17/dossiers/DLR5L17N50731

Le suivi officiel du parcours parlementaire du texte de transposition. À consulter pour vérifier l’avancement réel plutôt que les annonces de calendrier.

« MonEspaceNIS2 - Simulateur d’assujettissement (ANSSI) »

https://monespacenis2.cyber.gouv.fr/simulateur

L’outil d’auto-évaluation du périmètre d’assujettissement. Premier réflexe pour toute entité qui doute de sa qualification en entité essentielle ou importante.

Neuf semaines. Huit épisodes. Un même fil : la machine au service de la défense.

Nous avons ouvert le trimestre sur le SOC augmenté par l’IA (024), puis regardé l’adversaire s’emparer des mêmes armes (025). Nous avons industrialisé la détection et la réponse (026), organisé le test offensif permanent (027). Nous avons posé le contrepoint indispensable : que reste-t-il quand l’automatisation tombe (028) ? Nous avons vu la conformité devenir continue (029), le marché de l’assurance imposer ses standards de fait (030), et l’algorithme s’installer en prescripteur silencieux (031).

Le trimestre a une conclusion nette. Sur la vitesse, la machine a gagné, et ce n’était pas un débat. Sur le jugement, elle n’a rien gagné du tout - mais elle a beaucoup pris.

Voilà l’héritage encombrant de ces neuf semaines. Nous avons déplacé une frontière sans jamais la formaliser. Dans aucune organisation, personne n’a signé de note définissant précisément ce que la machine décide et ce que l’humain arbitre. Le partage s’est fait par accumulation de choix techniques, chacun raisonnable pris isolément.

La vraie question n’est donc pas « faut-il automatiser ? ». C’est : qui a réglé le curseur, selon quels critères, et à quelle échéance le rediscute-t-on ?

1. Ce que le trimestre a réellement établi

Une synthèse n’est pas un résumé. Huit épisodes ont fait apparaître trois lignes de force - et une seule mérite qu’on s’y arrête longtemps.

La vitesse n’est plus un différenciateur. Trier, enrichir, isoler un poste compromis en quelques secondes : c’est devenu le socle, pas l’avantage. Une organisation qui ne le fait pas n’est pas prudente, elle est en retard. L’ENISA documente depuis plusieurs cycles une exploitation des vulnérabilités plus rapide que les cycles de correction.

L’asymétrie s’est reconstituée un cran plus haut. L’attaquant a industrialisé au même rythme (025). Le gain net de l’automatisation défensive est donc plus faible qu’annoncé. Ce qu’on achète, ce n’est pas de l’avance : c’est le droit de rester dans la course.

La dépendance a changé de nature. Elle n’est plus seulement d’infrastructure (002) ni de fournisseur (030). Elle est devenue cognitive : dépendance à un tri qu’on ne refait pas, à une priorisation qu’on ne conteste pas, à une synthèse qu’on ne relit pas (031).

Le trimestre n’a pas produit un gain de puissance. Il a produit un déplacement de dépendance - et un déplacement non documenté.

2. Le curseur n’est pas une position, c’est une capacité de retour

On se représente volontiers l’équilibre humain-machine comme un réglage : plus ou moins d’automatisation, selon l’appétence au risque. L’image est commode. Elle est fausse.

Un curseur suppose qu’on puisse le ramener en arrière. Or dans la plupart des organisations, l’automatisation fonctionne comme un cliquet : elle avance, elle ne recule jamais. Les procédures manuelles cessent d’être maintenues. Les personnes qui les connaissaient changent de poste. L’outil devient la seule façon connue de faire - puis la seule façon concevable.

À ce stade, il n’y a plus de curseur. Il ne reste qu’une position subie, qu’on présente ensuite comme une stratégie.

La résilience ne consiste pas à automatiser moins. Elle consiste à conserver la possibilité de faire autrement - et à en payer le prix : documentation tenue à jour, exercices réels, temps d’équipe immobilisé. C’est la logique de l’épisode 028, portée à l’échelle du trimestre entier.

Un degré d’automatisation qu’on ne peut pas réduire n’est pas un choix. C’est une dépendance qui s’ignore.

3. Les quatre variables qui règlent le curseur

Décider ce qu’on automatise n’est pas affaire de conviction. Quatre variables suffisent à trancher la grande majorité des cas.

• Réversibilité de l’action. Fermer une alerte en faux positif se rattrape. Isoler un automate industriel en pleine production, beaucoup moins. Plus l’action est irréversible, plus le point d’arrêt humain se justifie.

• Coût d’une erreur, pas sa probabilité. Un modèle fiable à 99 % reste inacceptable si le pour-cent restant coupe une chaîne de paiement. On dimensionne un contrôle sur le pire cas plausible, jamais sur la moyenne.

• Contrainte de temps réelle. Beaucoup d’actions ont été automatisées « pour aller vite » sans qu’aucune exigence de latence ne l’impose. Automatiser une tâche qui pouvait attendre trente minutes, c’est prendre un risque sans contrepartie.

• Traçabilité de la décision. Si personne ne peut reconstituer pourquoi l’action a eu lieu, l’analyse post-incident est perdue - et l’apprentissage avec elle.

Ces quatre variables se combinent en une règle tenable : on automatise ce qui est réversible, peu coûteux en cas d’erreur, réellement urgent et intégralement tracé. Dès qu’une de ces conditions tombe, la main humaine redevient un dispositif de sécurité, pas une lenteur à corriger.

Le bon critère n’est pas « la machine sait-elle le faire ? », mais « que se passe-t-il si elle le fait mal, et combien de temps avant qu’on s’en aperçoive ? »

4. L’érosion silencieuse : ce que l’automatisation prélève

Il existe un coût qui n’apparaît dans aucun business case : la compétence qui ne s’exerce plus.

Un analyste qui n’a pas mené d’investigation manuelle depuis dix-huit mois n’a pas oublié la théorie. Il a perdu les réflexes : par où commencer, quoi regarder en premier, à quel moment une hypothèse ne tient plus. Ce savoir-là ne se rattrape pas en relisant une procédure la veille d’une crise.

Le phénomène n’a rien d’inédit. L’aéronautique le traite depuis quarante ans sous le nom de dégradation des compétences manuelles, et en a tiré une réponse simple : on impose des heures de vol sans pilote automatique. La cybersécurité, elle, découvre le problème.

Il arrive au pire moment. L’ENISA place la pénurie de compétences parmi les toutes premières menaces à l’horizon 2030. Une organisation qui automatise pour compenser un manque d’effectifs accélère mécaniquement l’érosion de ceux qui restent - et se retrouve, à terme, avec des outils que plus personne ne sait contredire.

Ce n’est pas un argument contre l’automatisation. C’est un argument pour la budgéter honnêtement : le temps d’exercice manuel est une ligne de coût assumée, pas une variable d’ajustement de fin de trimestre.

Une compétence qui ne s’exerce pas ne se dégrade pas lentement. Elle disparaît d’un coup, le jour où l’on en a besoin.

5. Grille de maturité : évaluer votre équilibre humain-machine

Comme pour chaque synthèse, voici l’outil de positionnement. Il ne mesure pas votre niveau d’automatisation - indicateur sans intérêt - mais la qualité du réglage et sa réversibilité.

Le seul niveau qui compte est celui de votre ligne la plus faible. La maturité ne se moyenne pas : elle se lit au point de rupture.

6. Trois erreurs de réglage, toujours les mêmes

Automatiser une procédure immature. Le principe est ancien (026) : automatiser une mauvaise procédure ne la corrige pas, elle la répète plus vite et plus loin. L’orchestration n’est pas un outil de mise en ordre, c’est un amplificateur. Elle rend visible la maturité réelle des processus - parfois brutalement.

Confondre supervision et validation. Un opérateur à qui l’on demande d’approuver quarante recommandations par jour n’exerce aucun jugement : il tamponne. Le règlement européen sur l’IA nomme explicitement ce mécanisme le biais d’automatisation. Un contrôle humain qui ne dispose ni du temps, ni du contexte, ni du droit réel de dire non est un habillage de conformité, pas une sécurité.

Piloter au taux d’automatisation. C’est l’indicateur le plus flatteur et le moins informatif du domaine. Il monte toujours. Il ne dit rien de la réversibilité, rien de la compétence résiduelle, rien de la qualité des décisions prises. Et un tableau de bord entièrement vert n’a jamais empêché une crise (029).

Ces trois erreurs ont un point commun : elles se produisent partout où personne, à un niveau suffisant, n’a été rendu responsable du réglage.

7. Ce que ce trimestre laisse ouvert

Faisons le compte de l’année. Les fondations techniques sont posées (T1). Les dépendances sont cartographiées et les arbitrages assumés (T2). Les outils fonctionnent, les équipes montent en compétence, la frontière humain-machine commence à se documenter (T3).

Reste la partie la plus inconfortable. Elle n’est pas technique.

Qui, dans votre organisation, est nommément responsable de ce réglage ? Devant qui rend-il des comptes, et sur quelles preuves ? Avec quel budget - puisque la résilience figure encore, dans la plupart des comités, du côté des coûts et non des actifs ?

Le cadre européen a déjà tranché une partie de la question : la directive NIS2 fait remonter la responsabilité de la gestion des risques cyber aux organes de direction, avec obligation de formation. Ce n’est plus une bonne pratique, c’est une exigence. Reste à savoir ce qu’on en fait - et ce qu’on saura prouver le jour du contrôle.

Un réglage dont personne n’est responsable n’est pas une politique. C’est une habitude.

L’Essentiel pour Agir

1. Cartographier vos décisions déléguées —

Listez sur une seule page les actions que vos systèmes exécutent ou recommandent sans validation humaine effective. Pour chacune, notez la réversibilité et le coût d’une erreur. La plupart des organisations découvrent à cette étape des délégations que personne n’a jamais décidées.

2. Mesurer la réversibilité plutôt que le taux d’automatisation —

Prenez trois processus critiques et chronométrez leur exécution manuelle, sans outil, avec les personnes réellement disponibles un dimanche matin. Le chiffre obtenu vaut plus que n’importe quel indicateur de couverture.

3. Porter le réglage à l’ordre du jour du comité —

L’équilibre humain-machine est un arbitrage de gouvernance, pas un paramètre d’outil. Présentez-le comme tel : une position, ses raisons, son coût, et la date à laquelle elle sera réexaminée.

Conclusion

Ce trimestre s’était donné un titre : l’intelligence au service de la résilience. Il se referme sur une nuance. L’intelligence artificielle a servi la rapidité, la couverture, l’endurance. Elle n’a servi le jugement à aucun moment - et ce n’était pas son rôle.

La résilience ne consiste pas à choisir entre l’humain et la machine. Elle consiste à savoir, à tout instant, lequel des deux est en train de décider - et à conserver le pouvoir de changer d’avis.

Trois trimestres nous ont donné des outils, une cartographie et des arbitrages. Il manque encore la réponse à la question la plus simple, et la plus rarement posée à voix haute : le jour où tout cela échouera, qui devra l’expliquer, et avec quelles preuves ?

C’est par là que commence la suite.

Bibliographie

https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf

L’ajout de la fonction GOVERN en 2024 est exactement le mouvement décrit dans cet épisode : le pilotage du risque cyber cesse d’être un sujet d’équipe pour devenir un sujet de direction. Support direct de la grille de maturité.

« ENISA - Threat Landscape 2025 »

https://enisa.europa.eu/publications/enisa-threat-landscape-2025

Panorama européen fondé sur près de 4 900 incidents analysés. Documente l’accélération de l’exploitation des vulnérabilités qui justifie l’automatisation défensive - et ses limites.

« ENISA - Foresight Cybersecurity Threats for 2030 : pénurie de compétences et systèmes non corrigés »

https://www.enisa.europa.eu/news/skills-shortage-and-unpatched-systems-soar-to-high-ranking-2030-cyber-threats

Classe la pénurie de compétences au deuxième rang des menaces à l’horizon 2030. Source centrale de la section sur l’érosion des compétences manuelles.

« ANSSI - Recommandations de sécurité pour un système d’IA générative (avril 2024) »

https://messervices.cyber.gouv.fr/guides/recommandations-de-securite-pour-un-systeme-dia-generative

Guide de référence français sur la sécurisation des systèmes d’IA. L’ANSSI y proscrit explicitement les automatismes non validés par un humain sur les actions à impact - le principe même du point d’arrêt décrit ici.

« ISO/IEC 42001:2023 - Systèmes de management de l’intelligence artificielle »

https://www.iso.org/standard/42001

Première norme internationale de management de l’IA. Fournit le vocabulaire et la structure pour formaliser les critères d’automatisation et leur révision périodique.

« Directive (UE) 2022/2555 (NIS2) »

https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32022L2555

Fait remonter la responsabilité de la gestion des risques cyber aux organes de direction et impose leur formation. C’est le point d’appui juridique de la transition vers le prochain trimestre.

Le 2 août 2026 devait être une date de bascule : l’échéance à laquelle les obligations européennes sur les systèmes d’IA à haut risque devenaient applicables. Le 27 juillet, à six jours du terme, le règlement (UE) 2026/1744 est entré en vigueur et l’a repoussée au 2 décembre 2027.

Seize mois de plus. Le calendrier a bougé. Les algorithmes, eux, sont déjà en production.

Nous avons abordé l’IA comme un usage non gouverné (009), puis comme un outil de détection au sein du SOC (024). Il manque une troisième lecture, plus discrète et plus structurante : l’IA comme prescripteur. Elle ne se contente plus de voir. Elle classe, elle priorise, elle recommande. Et ce qu’elle recommande finit, dans les faits, par être appliqué.

C’est là que le sujet cesse d’être technique. Une organisation qui délègue son tri d’alertes, son scoring de tiers ou sa priorisation de correctifs à un modèle qu’elle n’audite pas a créé une dépendance. Pas une dépendance d’infrastructure : une dépendance de jugement.

La vraie question n’est pas de savoir si l’IA se trompe. Elle se trompe, comme tout système. C’est de savoir qui s’en apercevra, quand, et selon quelle procédure.

1. Du copilote au prescripteur : un glissement que personne n’a décidé

Aucune note de service n’a acté que l’IA déciderait. Le glissement s’est fait par accumulation.

Un modèle propose un score de criticité : l’analyste, débordé, traite d’abord ce qui est en haut de liste. Un moteur classe les vulnérabilités : l’équipe corrige dans l’ordre proposé. Un assistant rédige la synthèse de crise : le comité de direction lit la synthèse, pas les sources.

Aucune de ces étapes n’est une délégation formelle. Toutes ensemble en constituent une.

Une recommandation que l’on suit systématiquement n’est plus une recommandation. C’est une décision, assortie d’un intermédiaire humain qui tient lieu de signature.

Ce glissement déplace le point de défaillance. Il n’est plus dans l’infrastructure, il est dans l’ordonnancement de l’attention. Un modèle qui range une alerte réelle en position 400 sur 400 produit exactement le même effet qu’un capteur en panne - à ceci près qu’il ne remonte aucune erreur.

La délégation de décision ne se décrète pas. Elle s’installe. Et ce qui s’installe sans décision ne se gouverne pas.

2. Trois modes de défaillance, trois natures de risque

On confond volontiers les défaillances de l’IA. Elles n’ont ni les mêmes causes, ni les mêmes signatures, ni les mêmes contre-mesures.

Le biais est un héritage. Un modèle entraîné sur l’historique des incidents traités apprend aussi l’historique des incidents ignorés. Les angles morts du passé deviennent les règles du présent. Le biais ne produit pas d’erreur visible : il produit une cohérence trompeuse.

La corruption des données est une attaque. Le NIST la documente sous le terme d’empoisonnement dans sa taxonomie AI 100-2. Une analyse conjointe de l’UK AI Security Institute et de l’Alan Turing Institute, reprise par l’ANSSI en février 2026, indique qu’un empoisonnement peut être obtenu à partir de quelques centaines de documents malveillants seulement - et que ce volume varie peu avec la taille du corpus d’entraînement. Autrement dit : la masse de données ne protège pas.

L’hallucination est une production. Le modèle génère un contenu plausible et faux, sans signal de doute. Le CERT-FR en décrit une conséquence concrète : le « slopsquatting », qui consiste à enregistrer des noms de paquets logiciels inventés par des IA, puis à en diffuser des versions malveillantes. L’hallucination d’un modèle devient le point d’entrée d’une attaque par chaîne d’approvisionnement.

Un dispositif qui traite ces trois modes de la même façon n’en traite aucun.

3. Le vrai risque n’est pas la machine. C’est le biais d’automatisation.

Le règlement européen sur l’IA le nomme explicitement. Son article 14, consacré au contrôle humain, demande que les personnes chargées de la supervision restent conscientes de la tendance à se fier automatiquement aux sorties du système.

La formulation est rare dans un texte réglementaire : le législateur reconnaît que le problème ne tient pas seulement à l’outil, mais à la relation que l’on entretient avec lui.

En situation normale, un analyste conteste. En situation dégradée - fatigue, urgence, volume - il valide. C’est le mécanisme observé de longue date en aéronautique : la compétence de reprise en main s’atrophie précisément pendant les périodes où le système fonctionne bien.

Trois postures sont couramment confondues sous le terme de « supervision humaine » :

• L’humain dans la boucle : il décide, l’outil propose. Coûteux, lent, robuste.

• L’humain sur la boucle : l’outil agit, l’humain surveille et peut interrompre. Tenable si l’interruption est réellement exerçable.

• L’humain en garantie : l’outil agit, l’humain signe. Ce n’est pas de la supervision, c’est de la répartition de responsabilité.

Une supervision humaine qui n’a jamais contredit le modèle n’est pas une supervision. C’est un enregistrement.

4. Ce que le calendrier réglementaire vient de changer - et ce qu’il ne change pas

Le 24 juillet 2026, le règlement (UE) 2026/1744, dit « omnibus numérique sur l’IA », a été publié au Journal officiel de l’Union européenne. Entré en vigueur le 27 juillet, il modifie pour la première fois le règlement sur l’IA de 2024.

Ce qui change : les obligations lourdes pesant sur les systèmes à haut risque de l’annexe III - gestion des risques, documentation technique, journalisation, contrôle humain - passent du 2 août 2026 au 2 décembre 2027. Les systèmes intégrés à des produits déjà réglementés glissent, eux, à août 2028.

Ce qui ne change pas : les obligations de transparence de l’article 50 s’appliquent bien à compter du 2 août 2026, et l’approche par les risques reste intacte.

Il faut lire ce report pour ce qu’il est : non une annulation, mais un décalage motivé par l’absence de normes harmonisées et de dispositifs d’évaluation opérationnels. Le législateur a constaté qu’on ne pouvait exiger la conformité à des règles dont les outils de mise en œuvre n’existaient pas encore.

Pour une direction, la lecture est simple : l’échéance a bougé, l’exposition non. Une organisation qui avait bâti sa trajectoire autour d’une date se retrouve à replanifier. Une organisation qui l’avait bâtie autour d’une doctrine - traçabilité, supervision exerçable, séparation nette entre assistance et décision - a simplement gagné du temps.

Un calendrier réglementaire n’est pas une analyse de risque. Confondre les deux, c’est faire de la conformité, pas de la résilience.

5. Gouverner la confiance algorithmique comme on gouverne un fournisseur

Depuis le début de cette série, la thèse ne varie pas : la résilience ne consiste pas à supprimer la dépendance, mais à avoir conscience de ses dépendances.

Un modèle d’aide à la décision est une dépendance. Il a un fournisseur, une chaîne d’approvisionnement (données, poids, bibliothèques), une opacité, un coût de sortie et un mode dégradé. Exactement comme un hébergeur ou un éditeur.

Nous savons faire. Nous l’avons fait pour le cloud (002), pour les composants open source et propriétaires (003), pour les prestataires critiques. Il s’agit d’appliquer les mêmes réflexes de gouvernance à un objet qui n’a pas encore été reconnu comme un fournisseur.

La question n’est pas « faites-vous confiance à votre modèle ? ». C’est « à partir de quel indicateur cesseriez-vous de lui faire confiance ? ».

6. Sept questions avant de laisser un algorithme décider

Une checklist courte, utilisable en comité, sans prérequis technique :

• Quelle décision ce système influence-t-il réellement ? Non pas ce qu’il produit, mais ce qui change dans l’organisation à cause de ce qu’il produit.

• Quel est le coût d’un faux négatif ? Une alerte manquée coûte-t-elle plus cher qu’une alerte inutile ? Le réglage du modèle reflète-t-il ce coût ?

• D’où viennent les données d’entraînement, et qui peut les modifier ?

• Existe-t-il une version de référence à laquelle revenir ? Et l’a-t-on déjà restaurée pour de bon, hors exercice de papier ?

• Combien de fois, ces six derniers mois, un humain a-t-il écarté la recommandation ? Si la réponse est zéro, la supervision est théorique.

• Que se passe-t-il si le système est indisponible 72 heures ? Qui prend le relais, avec quelle procédure, à quel débit ?

• Peut-on reconstituer, six mois après, pourquoi cette décision a été prise ? Sans journalisation des entrées et des sorties, la réponse est non.

Sept questions. Si trois restent sans réponse, le système n’est pas gouverné : il est simplement en service.

7. Le mode dégradé cognitif

Nous avons appris, épisode après épisode, qu’une sauvegarde non restaurée n’est pas une sauvegarde. Le raisonnement vaut ici.

Une organisation qui a délégué son tri d’alertes à un modèle pendant deux ans a perdu quelque chose de plus difficile à reconstituer qu’un serveur : la routine de jugement. Les analystes savent lire une sortie de modèle. Savent-ils encore construire une hypothèse à partir de journaux bruts ?

Le fonctionnement sans IA n’est pas une clause de PCA. C’est un exercice. Il se planifie, il se chronomètre, il produit un écart mesurable - et cet écart est un indicateur de résilience aussi sérieux qu’un RTO.

L’ANSSI recommande, dans son guide sur les systèmes d’IA générative, de cloisonner les environnements, de journaliser l’ensemble des traitements et de conserver une version de référence permettant un retour arrière. Ce sont des mesures techniques. Leur finalité est organisationnelle : préserver la capacité de fonctionner sans.

Sans capacité à décider sans la machine, tout le reste est cosmétique.

L’Essentiel pour Agir

1. Inventorier les décisions, pas les outils —

Recensez les décisions opérationnelles influencées par un modèle - tri d’alertes, priorisation de correctifs, scoring de tiers, synthèses de crise. C’est cette liste, et non le catalogue d’outils, qui définit votre exposition réelle.

2. Mesurer le taux de contradiction —

Suivez la proportion de recommandations écartées par un humain. Un taux nul n’indique pas un bon modèle : il indique une supervision qui ne s’exerce plus. C’est l’indicateur le moins coûteux et le plus révélateur dont vous disposiez.

3. Exercer le mode dégradé —

Programmez, une fois par semestre, une séquence de travail sans assistance algorithmique sur un périmètre critique. Chronométrez. L’écart de performance constaté est votre véritable niveau de dépendance.

Conclusion

Un algorithme qui recommande de ne pas investiguer une alerte n’attaque rien, ne chiffre rien, ne déclenche aucune astreinte. Il produit simplement une organisation qui regarde ailleurs, avec constance et bonne foi. C’est une défaillance silencieuse - et les défaillances silencieuses sont les plus longues à corriger.

Le report européen offre seize mois. Ce n’est pas un répit, c’est une fenêtre : le temps de construire une doctrine plutôt qu’un dossier de conformité.

Reste une question que ce trimestre ne pourra pas éviter beaucoup plus longtemps. Nous avons outillé la détection, automatisé la réponse, fiabilisé la décision. À la fin de la chaîne subsiste pourtant un arbitrage que personne n’a encore accepté de confier à une machine. Lequel - et pourquoi celui-là ?

La résilience ne consiste pas à faire confiance à la machine. Elle consiste à savoir précisément où cette confiance s’arrête.

Bibliographie

ANSSI / CERT-FR - « L’IA générative face aux attaques informatiques : synthèse de la menace en 2025 » (CERTFR-2026-CTI-001, 4 février 2026)

https://www.cert.ssi.gouv.fr/uploads/CERTFR-2026-CTI-001.pdf

Source française de référence sur l’empoisonnement des modèles, le slopsquatting et le ciblage des systèmes d’IA. Fournit les éléments factuels des sections II et VII.

NIST - « Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations » (NIST AI 100-2 e2025)

https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf

Taxonomie de référence des attaques contre les systèmes d’IA prédictive et générative. Sert de base à la distinction entre biais, empoisonnement et détournement.

NIST - « Artificial Intelligence Risk Management Framework (AI RMF 1.0) », NIST AI 100-1

https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf

Cadre de gestion des risques liés à l’IA. Utile pour structurer la grille de maturité et la notion de fiabilité mesurable d’un système d’aide à la décision.

Règlement (UE) 2024/1689 établissant des règles harmonisées concernant l’intelligence artificielle (« AI Act »)

https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202401689

Texte de référence. L’article 14 sur le contrôle humain mentionne explicitement le biais d’automatisation, point central de la section III.

Règlement (UE) 2026/1744 - « train de mesures omnibus numérique sur l’IA » (publié au JOUE le 24 juillet 2026)

https://eur-lex.europa.eu/legal-content/FR/ALL/?uri=OJ%3AL_202601744

Première modification de l’AI Act. Reporte au 2 décembre 2027 les obligations applicables aux systèmes à haut risque de l’annexe III.

ANSSI - « Recommandations de sécurité pour un système d’IA générative » (ANSSI-PA-102, avril 2024)

https://cyber.gouv.fr/publications/recommandations-de-securite-pour-un-systeme-dia-generative

Guide opérationnel : cloisonnement des environnements, journalisation des traitements, conservation d’une version de référence du modèle.

Introduction

Il existe en France un acteur qui impose aujourd’hui un socle de sécurité à des dizaines de milliers d’organisations. Sans mandat public. Sans pouvoir de sanction. Sans texte de loi.

Ce n’est ni l’ANSSI, ni un régulateur sectoriel. C’est un souscripteur. Il travaille chez un assureur ou un courtier, il n’a jamais mis les pieds dans votre salle serveurs, et il détient pourtant un pouvoir que peu de RSSI possèdent : celui de dire non.

Depuis le début de ce trimestre, Plan R explore l’intelligence au service de la résilience : détection automatisée, IA offensive, défaillance de l’automatisation, conformité continue. Beaucoup de technique. Il est temps de changer de terrain.

L’épisode 004 posait un principe : certaines décisions techniques sont devenues des décisions politiques. La cyber-assurance en fournit la démonstration la plus brutale. Elle transforme la maturité en prix, l’écart en exclusion, et la négligence en refus pur et simple.

La vraie question n’est donc pas « sommes-nous assurés ? ». C’est : que révèle sur nous ce que le marché accepte de couvrir - et ce qu’il refuse ?

1. Un régulateur qui n’a jamais demandé à l’être

Un régulateur publie ses exigences en amont et contrôle en aval. L’assureur fait exactement l’inverse : il évalue en amont, et sanctionne au moment du sinistre. Cette inversion explique une grande part du malaise qu’il suscite.

Son pouvoir tient à trois leviers, tous économiques : le prix, l’exclusion, le refus. Aucun ne passe par une consultation publique. Aucun ne prévoit de délai de transposition, de période de grâce ou de débat sur la proportionnalité. Ils s’appliquent à l’échéance annuelle, mécaniquement.

Observons honnêtement le terrain. L’authentification multifacteur généralisée, les sauvegardes immuables et testées, l’EDR déployé partout, la segmentation réseau : ces pratiques ne se sont pas diffusées dans les PME et les ETI parce qu’une agence les recommandait depuis dix ans. Elles se sont diffusées parce que, sans elles, il n’y a plus de contrat - ou un contrat vidé de sa substance.

Ce constat n’est ni un éloge du marché, ni une critique de la puissance publique. C’est une observation de mécanique : la contrainte budgétaire circule plus vite que la contrainte normative.

L’assureur ne rédige pas de norme. Il fixe un prix. Et un prix, contrairement à une norme, ne se négocie pas en comité de pilotage.

2. Le questionnaire de souscription : l’audit que personne n’a commandé

Quarante à quatre-vingts questions. Sauvegardes, MFA, gestion des vulnérabilités, PRA, sous-traitance, sensibilisation. Le questionnaire de souscription arrive avant le contrat, et c’est précisément ce qui le rend redoutable.

Un audit interne produit des recommandations. Un questionnaire de souscription produit des engagements. Ce que vous y déclarez devient ce que vous devez prouver le jour où vous demandez à être indemnisé. La différence n’est pas de degré, elle est de nature.

L’épisode 029 défendait l’idée d’une conformité continue : produire la preuve en flux plutôt qu’en campagne. La cyber-assurance en est le prolongement naturel, avec une nuance importante. Le régulateur vous demande d’être conforme. L’assureur, lui, vous demande d’être démontrable.

Le point de vigilance est organisationnel, pas technique. Dans beaucoup de structures, ce questionnaire est renseigné par l’IT dans l’urgence, sans relecture du RSSI, sans le juridique, sans le risk manager. C’est un engagement contractuel piloté par personne.

Le questionnaire de souscription est le seul audit de sécurité dont les réponses vous engagent juridiquement. Il mérite le soin d’une réponse à appel d’offres.

3. 2026 : les primes baissent, les sinistres montent

L’édition 2026 de l’étude LUCY de l’AMRAE, sixième du nom, porte sur l’exercice 2025 et repose sur l’analyse de près de 21 000 polices et de plus de 1 200 sinistres. Elle décrit un marché en pleine détente tarifaire : recul marqué des taux de prime, notamment pour les grandes entreprises, baisse des franchises, hausse des capacités souscrites.

La pénétration progresse fortement sur les segments intermédiaires - le nombre d’ETI et d’entreprises moyennes assurées a bondi en un an, porté par la concurrence, l’arrivée de MGA et d’assurtechs, et des parcours de souscription simplifiés.

Voilà pour la bonne nouvelle. Le revers est net : la sinistralité progresse fortement, et particulièrement chez les ETI, dont les coûts d’indemnisation ont explosé. Au niveau international, les travaux publiés en juin 2026 par le Financial Stability Institute et l’IAIS confirment que le rançongiciel reste la première cause de perte, et que la perte d’exploitation en constitue désormais la composante la plus lourde.

Deux lectures sont possibles. Optimiste : la prévention a payé, le marché se démocratise. Lucide : les niveaux tarifaires actuels rejoignent ceux de 2020, une période où ils étaient jugés insuffisants au regard du risque réel.

Pour un praticien de la résilience, la conséquence est contre-intuitive. Quand le ticket d’entrée baisse, l’effet disciplinant de l’assureur s’affaiblit - au moment précis où la menace s’intensifie. L’AMRAE le dit d’ailleurs sans détour : la baisse des taux doit être réinvestie dans la prévention, pas encaissée.

Une prime qui baisse n’est pas un signal de sécurité. C’est un signal de concurrence. Ne confondez pas les deux.

4. Ce que l’assureur refuse de couvrir est votre vrai rapport d’audit

Un audit vous remet un score. Un assureur vous remet une décision. La seconde est plus difficile à ignorer.

Voici comment lire cette décision comme un diagnostic :

• Refus de couverture : un écart structurel, pas un détail. Le marché estime le risque non modélisable en l’état.

• Sous-limite ciblée (perte d’exploitation, dépendance à un prestataire, fraude) : l’assureur a identifié une concentration que vous n’aviez pas cartographiée.

• Franchise relevée : il doute de votre capacité à détecter tôt et à contenir. C’est un jugement sur votre chaîne de détection.

• Exclusion nommant un fournisseur ou une technologie : votre risque tiers est lisible de l’extérieur. Il devrait l’être de l’intérieur.

• Non-renouvellement après sinistre : votre plan de remédiation n’a convaincu personne.

L’assureur regarde votre organisation comme un attaquant la regarde : par la perte, pas par l’organigramme. Il n’a aucun intérêt à vous flatter, et un intérêt financier direct à ne pas se tromper. C’est, à bien des égards, le regard extérieur le plus honnête dont vous disposez.

L’inversion que propose Plan R est simple : cessez de recevoir une exclusion comme un échec commercial à contester. Recevez-la comme un livrable.

Une exclusion n’est pas une clause à négocier. C’est un risque non traité, que quelqu’un a chiffré à votre place.

5. Les 72 heures qui décident de l’indemnisation

Depuis avril 2023, l’article L. 12-10-1 du code des assurances, issu de la LOPMI, conditionne le versement d’une indemnité au dépôt d’une plainte auprès des autorités compétentes, au plus tard soixante-douze heures après la connaissance de l’atteinte par la victime.

Trois points méritent l’attention des praticiens.

D’abord, le champ est large. Le texte ne parle pas de rançon mais d’atteinte à un système de traitement automatisé de données. Il couvre donc bien au-delà du rançongiciel.

Ensuite, le point de départ du délai est la connaissance de l’atteinte - une notion que la loi ne définit pas. Concrètement, l’horloge peut démarrer dans un SOC un vendredi soir, alors que la direction juridique n’apprendra l’incident que le lundi matin. Le délai, lui, aura couru.

Enfin, la sanction est sèche : l’assureur peut opposer une déchéance de garantie. Toute la préparation technique du monde ne rattrape pas une plainte déposée le quatrième jour.

L’épisode 028 rappelait qu’une chaîne de reprise doit rester exécutable manuellement quand l’automatisation lâche. Le même raisonnement vaut ici : votre chaîne d’escalade de crise doit comporter un fil juridique, pas seulement un fil technique. Modèle de plainte pré-rédigé, autorité identifiée, porteur nommé, suppléant désigné.

En crise, l’indemnisation ne se joue pas au moment de l’expertise. Elle se joue dans les soixante-douze premières heures.

6. Grille de maturité assurantielle

La grille ci-dessous applique le triptyque Réactif / Structuré / Natif à la relation assurantielle. Elle se lit en dix minutes en comité des risques, et elle n’exige aucun budget pour être remplie honnêtement.

Passer du Réactif au Natif ne coûte pas une prime. Cela coûte une décision de gouvernance : faire entrer l’assureur dans la conversation risque, au lieu de le laisser à la porte du service achats.

7. Ce que le transfert de risque ne transférera jamais

Un contrat transfère une conséquence financière. Il ne transfère pas l’incident, ni l’indisponibilité, ni la perte de confiance des clients, ni la décision à prendre à trois heures du matin.

Il faut aussi regarder le miroir sans complaisance. L’ENISA a documenté, du côté de la demande, la difficulté persistante des entités essentielles à comparer les offres, faute de terminologie partagée. L’EIOPA, de son côté, a dû formuler des attentes prudentielles sur les expositions cyber non affirmatives - autrement dit sur les risques que les assureurs couvrent sans l’avoir explicitement voulu.

Le marché qui discipline notre résilience gère donc lui-même une part d’incertitude. C’est une raison supplémentaire de l’utiliser comme miroir, et non comme oracle.

L’assureur tarife votre risque résiduel. Il ne pilote pas votre PRA. Il ne restaure pas votre annuaire. Il n’explique pas à vos clients pourquoi la commande n’est pas partie.

La résilience ne consiste pas à transférer le risque. Elle consiste à savoir précisément ce que le transfert ne couvre pas.

L’Essentiel pour Agir

1. Traitez le questionnaire de souscription comme un engagement contractuel —

Instaurez un circuit de validation RSSI / juridique / risk manager avant tout envoi. Chaque réponse doit s’appuyer sur une preuve datée et archivée, pas sur une conviction. Ce que vous déclarez aujourd’hui, vous devrez le démontrer en crise.

2. Faites du refus de l’assureur un livrable de gouvernance —

Exclusions, sous-limites et franchises relevées ne sont pas des sujets d’achat. Cartographiez-les, présentez-les au comité des risques, et traduisez chacune en action avec un porteur et une échéance. Un risque chiffré par un tiers mérite mieux qu’un classement.

3. Câblez le délai de 72 heures dans votre dispositif de crise —

Modèle de plainte pré-rédigé, autorité compétente identifiée, responsable et suppléant nommés, déclencheur intégré au playbook et testé en exercice. Le délai court dès la connaissance de l’atteinte, pas dès l’ouverture de la cellule de crise.

Conclusion

L’assureur est devenu, sans l’avoir demandé, l’un des prescripteurs les plus efficaces de la résilience numérique. Non parce qu’il serait plus compétent que le régulateur, mais parce qu’il est le seul à payer.

Cette discipline a pourtant une limite, et 2026 la met en pleine lumière : quand la concurrence relâche les prix, elle relâche aussi les exigences. Une résilience qui ne tient que parce qu’un tiers l’impose n’est pas une résilience acquise. C’est une résilience louée.

Nous avons délégué la preuve à l’automatisation, une partie de la remédiation à la machine, et voici que nous déléguons le risque lui-même au marché. À force de confier, une question finit par s’imposer d’elle-même : jusqu’où peut-on déléguer avant de ne plus rien maîtriser ? Ce sera le fil de nos prochains rendez-vous.

Un contrat peut absorber une perte. Il n’a jamais redémarré un système.

Bibliographie

« LUCY - Lumière sur la cyberassurance, édition 2026 (AMRAE) »

https://www.amrae.fr/recherche?search_api_fulltext=lucy

L’étude de référence du marché français, fondée sur l’analyse des portefeuilles de courtiers représentatifs. La sixième édition documente la détente tarifaire de 2025 et la hausse concomitante de la sinistralité, en particulier chez les ETI.

« Cyber insurance unpacked: the corporate digital safety net (FSI - BIS / IAIS, juin 2026) »

https://www.iais.org/uploads/2026/06/FSI-IAIS-Insights-Cyber-insurance-unpacked-the-corporate-digital-safety-net.pdf

Note conjointe du Financial Stability Institute et de l’association internationale des superviseurs d’assurance. Elle confirme le poids de la perte d’exploitation dans les sinistres cyber et détaille les attentes prudentielles en matière de souscription.

« Article L. 12-10-1 du code des assurances (Légifrance) »

https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000047048152

Le texte issu de la LOPMI qui subordonne l’indemnisation au dépôt d’une plainte dans un délai de soixante-douze heures. Source primaire indispensable pour calibrer le volet juridique d’un playbook de crise.

« Demand Side of Cyber Insurance in the EU (ENISA, 2023) »

https://www.enisa.europa.eu/publications/demand-side-of-cyber-insurance-in-the-eu

Analyse européenne du point de vue des entités essentielles : difficultés d’accès, comparabilité des offres et absence de terminologie partagée. Utile pour objectiver le déséquilibre d’information entre assureur et assuré.

« Cyber insurance - dossier thématique (EIOPA) »

https://www.eiopa.europa.eu/browse/digitalisation-and-financial-innovation/cyber-insurance_en

Le portail de l’autorité européenne des assurances, incluant ses travaux sur les expositions cyber non affirmatives. Il éclaire l’incertitude que le marché gère lui-même sur son propre périmètre de couverture.

« Panorama de la cybermenace 2025 (ANSSI) »

https://cyber.gouv.fr/nous-connaitre/publications/panoramas-de-la-cybermenace/panorama-de-la-cybermenace-2025/

Le bilan annuel de l’agence : 3 586 événements de sécurité traités et une progression marquée des incidents d’exfiltration de données. Le contexte de menace qui alimente, en amont, la tarification des assureurs.

En 2014, obtenir l’homologation de sécurité d’un système, c’était décrocher un tampon valable trois ans. Une photographie. On vérifiait, on signait, on rangeait le dossier. Entre deux contrôles, le système vivait sa vie - et dérivait.

Ce modèle a longtemps tenu. Il ne tient plus. Les infrastructures changent chaque jour, parfois chaque heure. Un déploiement, une dépendance mise à jour, une règle de pare-feu modifiée : la conformité d’hier n’est déjà plus celle d’aujourd’hui.

Dès l’épisode 005, nous avons posé un principe : la conformité doit descendre dans le code (« Compliance as Code »). C’était le début du « Shift Left » - déplacer le contrôle au plus tôt. Ce qui n’était qu’une intuition en début d’année est devenu une pratique mature. La suite logique porte un nom : la conformité continue.

Le raisonnement est implacable. Si la conformité vit dans le code, elle se vérifie à la vitesse du code. En permanence. Le tableau de bord passe au vert, et reste vert.

Et c’est précisément là que le piège se referme. Car un voyant vert n’a jamais empêché une crise. La vraie question n’est pas : « suis-je conforme en continu ? » C’est : « que mesure réellement ce vert qui me rassure ? »

1. De la photographie au flux

Toute la logique de l’audit classique repose sur un instantané. On fige un état, on le compare à un référentiel, on conclut. Le problème n’est pas la méthode : c’est sa fréquence. Entre l’audit de janvier et celui de l’année suivante, onze mois d’angle mort.

L’ANSSI le reconnaît elle-même : une homologation « doit être reconduite au maximum tous les trois ans ». Trois ans, à l’échelle d’un système d’information moderne, c’est une éternité géologique. Le référentiel évolue, l’infrastructure mute, les dépendances se multiplient - et le tampon, lui, ne bouge pas.

La conformité continue inverse la logique. Elle ne demande plus « étiez-vous conforme le jour de l’audit ? » mais « l’êtes-vous maintenant, à cette seconde ? ». Elle transforme un jugement rétrospectif en signal temps réel.

Ce glissement n’est pas qu’une affaire d’outils. Il est philosophique. On passe d’une conformité-preuve - je démontre que j’étais en règle - à une conformité-état - je surveille que je le reste.

La dérive ne se produit pas pendant l’audit. Elle se produit entre deux audits. La conformité continue attaque exactement cet intervalle.

2. L’aboutissement du « Shift Left »

Si la conformité est écrite en code, la vérifier devient une opération machine. C’est tout l’objet du « policy as code » : traduire une exigence réglementaire en règle exécutable, testée à chaque déploiement, exactement comme on teste une fonctionnalité.

Le NIST a formalisé cette bascule avec OSCAL (Open Security Controls Assessment Language) : un format lisible par la machine qui décrit les contrôles, leur implémentation et les résultats d’évaluation. La conformité cesse d’être un document Word ; elle devient une donnée structurée, échangeable, automatisable.

Concrètement, la promesse est spectaculaire. Un audit qui prenait des mois se rejoue en minutes. L’écart n’est plus découvert un an trop tard : il est signalé au moment où il apparaît. Trois briques rendent cela possible :

• Les contrôles comme code : chaque exigence devient un test automatisé et rejouable.

• Le pipeline comme point de contrôle : rien ne se déploie sans franchir les barrières définies.

• La preuve comme flux : les résultats alimentent un tableau de bord vivant, pas un classeur mort.

Le « Shift Left » de l’épisode 005 déplaçait le contrôle vers la gauche. La conformité continue le déplace partout, tout le temps.

3. Ce que la conformité continue résout vraiment

Ne boudons pas le progrès. Le gain est réel, et il touche au cœur de la résilience.

Le NIST, dans sa publication fondatrice sur la surveillance continue (SP 800-137), résume l’enjeu d’une formule juste : passer d’une gestion du risque « pilotée par la conformité » à une gestion « pilotée par la donnée ». Cocher la case ne suffit plus ; il s’agit de savoir, en continu, où l’on en est réellement.

Les bénéfices sont tangibles :

• Fin de l’angle mort : la dérive de configuration se détecte en heures, plus en mois.

• Preuve permanente : face à un régulateur (NIS2, DORA), on démontre un état, pas une intention.

• Coût d’audit réduit : la preuve est produite en continu, pas reconstituée dans l’urgence de l’inspection.

Le secteur financier ne s’y est pas trompé. Le règlement DORA impose désormais des tests de résilience réguliers et structurés : la conformité-photographie y est explicitement jugée insuffisante. Le message du législateur est clair - prouver qu’on résiste vaut mieux que promettre qu’on résisterait.

La conformité continue ne rend pas seulement l’audit plus rapide. Elle rend la dérive visible avant qu’elle ne devienne incident.

4. Le piège du tableau de bord vert

Voici le revers. Et il est redoutable, car il se déguise en réussite.

Un tableau de bord vert mesure une chose : la présence des contrôles attendus. Il ne mesure pas leur pertinence. Il ne dit pas si les bons risques ont été couverts, ni si un contrôle coché protège réellement de quelque chose. Il atteste d’une conformité au référentiel, pas d’une solidité face au réel.

Nous l’avons vu à l’épisode 028 : l’automatisation qui tombe en panne est d’autant plus dangereuse qu’elle inspirait confiance. Le tableau de bord vert est cousin de ce danger. Il crée un confort. Et le confort endort la vigilance.

Rappelons une évidence de terrain, déjà croisée dans ces chroniques : un indicateur qui reste éternellement au vert n’est pas rassurant, il est suspect. Soit l’organisation est parfaite - cela n’existe pas -, soit le tableau de bord mesure ce qui est facile à mesurer, et non ce qui compte.

Le risque porte un nom : le « théâtre de la conformité ». Une scène impeccable, des voyants alignés, et derrière le décor, des risques bien réels que plus personne ne regarde - précisément parce que tout paraît vert.

Un tableau de bord vert prouve que vous vérifiez ce que vous avez décidé de vérifier. Rien de plus. La question reste entière : avez-vous décidé de vérifier ce qui compte ?

5. Grille de maturité : où en êtes-vous vraiment ?

Pour sortir des postures, une grille de lecture en trois niveaux - Réactif, Structuré, Natif -, appliquée cette fois à la conformité. Elle ne sert pas à se noter, mais à situer honnêtement son point de départ.

Le niveau « Natif » n’est pas le bout du chemin. C’est le niveau où le vrai travail - juger ce que le vert ne dit pas - commence enfin.

6. Gouverner le signal, pas seulement le produire

Automatiser la vérification, c’est la partie facile. Gouverner ce qu’elle produit, c’est la partie difficile - et c’est là que se joue vraiment la résilience.

La version 2.0 du cadre du NIST (CSF) l’a acté en érigeant la gouvernance en fonction à part entière : établir la stratégie, mais aussi la surveiller. Un tableau de bord sans autorité qui le lit, l’interroge et arbitre n’est qu’un écran de plus dans une salle déjà saturée d’écrans.

Trois questions de gouvernance doivent accompagner tout dispositif de conformité continue :

• Qui décide de ce qu’on mesure ? Le périmètre du contrôle est un choix stratégique, pas un réglage technique.

• Qui lit le rouge - et le vert ? Un écart signalé sans destinataire responsable est un écart ignoré.

• Qui garde le droit de douter du vert ? La conformité continue crée une dépendance nouvelle : celle envers son propre système de mesure.

Et nous retrouvons le fil rouge de cette chronique, épisode après épisode : la résilience n’est pas l’absence de dépendance, c’est la gestion consciente de nos dépendances. Dépendre d’un tableau de bord sans jamais le questionner, c’est troquer un angle mort contre un autre.

La conformité continue est un formidable capteur. Un capteur ne décide rien. La décision, elle, ne se délègue pas.

L’Essentiel pour Agir

1. Codez vos contrôles, mais choisissez-les en conscience —

Traduire une exigence en test automatisé (policy as code, OSCAL) est un gain majeur. Mais l’automatisation fige vos priorités : ne codez pas ce qui est facile à mesurer, codez ce qui protège vraiment.

2. Traitez l’écart, pas le voyant —

Un tableau de bord n’a de valeur que par ce qu’il déclenche. À chaque signal, associez un responsable et une remédiation. Un vert permanent doit vous alerter autant qu’un rouge.

3. Gardez une autorité qui doute —

Instituez une revue périodique qui ne regarde pas le tableau de bord, mais le remet en question : mesure-t-il encore les bons risques ? La vigilance ne se met jamais en pilote automatique.

Conclusion

La conformité continue est une belle victoire d’ingénierie. Elle referme un angle mort qui hantait la sécurité depuis toujours : l’intervalle entre deux contrôles. Ce qui n’était qu’un principe en début d’année est devenu une capacité opérationnelle.

Mais une capacité n’est pas une garantie. Le vert permanent ne prouve pas la résilience ; il prouve la vérification. Confondre les deux, c’est reconstruire, à grande vitesse et en temps réel, la vieille illusion du dossier bien rangé.

Reste alors la question qui nous accompagnera vers la fin de ce trimestre : quand la machine mesure, surveille et signale sans relâche, que reste-t-il, exactement, qui exige encore un jugement humain ? Où finit la vérification, où commence la responsabilité ?

Automatiser la preuve était l’enjeu de 2026. Assumer la décision derrière la preuve sera celui de demain.

Bibliographie

« OSCAL - Open Security Controls Assessment Language (NIST) »

https://pages.nist.gov/OSCAL/

Le format machine développé par le NIST pour décrire, échanger et automatiser l’évaluation des contrôles de sécurité - socle technique de la conformité continue.

« NIST SP 800-137 - Information Security Continuous Monitoring (ISCM) »

https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-137.pdf

La publication fondatrice du NIST sur la surveillance continue : elle formalise le passage d’une gestion du risque pilotée par la conformité à une gestion pilotée par la donnée.

« Règlement DORA (UE) 2022/2554 - Résilience opérationnelle numérique »

https://eur-lex.europa.eu/FR/legal-content/summary/digital-operational-resilience-for-the-financial-sector.html

Le règlement européen qui impose au secteur financier des tests de résilience réguliers et structurés - illustration réglementaire de l’insuffisance de la conformité ponctuelle.

« L’homologation de sécurité (ANSSI) »

https://cyber.gouv.fr/securisation/homologation-de-securite/

La démarche de référence française : une homologation reconductible tous les trois ans au maximum, parfait contrepoint du modèle « photographie » que la conformité continue dépasse.

« NIST Cybersecurity Framework (CSF) 2.0 »

https://www.nist.gov/cyberframework

La version 2.0 du cadre du NIST érige la gouvernance (« Govern ») en fonction centrale : établir la stratégie et la surveiller, au-delà de la seule production d’indicateurs.

Depuis quatre semaines, ce trimestre chante les louanges de la machine. Le SOC augmenté par l’IA (024), l’IA offensive comme industrialisateur des attaques (025), la détection et la réponse automatisées (026), le test offensif permanent (027). Un fil cohérent : l’intelligence au service de la résilience.

Il manque un contrepoint. Le voici.

Car derrière chaque playbook qui s’exécute en trois secondes, chaque poste isolé automatiquement, chaque alerte triée par un modèle, se cache une hypothèse tacite : que la machine sera là. Toujours. Disponible, fiable, non compromise.

Et si elle ne l’est pas ?

On a passé une décennie à déléguer à l’automatisation nos gestes les plus répétitifs. On a rarement demandé ce qu’il resterait le jour où elle s’arrêterait. C’est pourtant une question de résilience de premier ordre - la même, au fond, que celle du cloud (002) : non pas l’absence de dépendance, mais la conscience de ses dépendances.

La vraie question n’est pas de savoir si l’automatisation tombera un jour. C’est de savoir si nous saurons encore reprendre la main quand elle tombera.

1. Le paradoxe qu’on a préféré oublier

Nous l’avons croisé à l’épisode 026, sous le nom de Bainbridge. En 1983, la psychologue Lisanne Bainbridge formule les « ironies de l’automatisation ». Son constat, écrit quarante ans avant nos SOAR, reste d’une actualité gênante.

L’automatisation prend en charge le routinier. Elle laisse à l’humain… l’exceptionnel. C’est-à-dire précisément les situations les plus rares, les plus complexes, les plus stressantes. Celles où l’on a le plus besoin de compétence.

• Première ironie : plus on automatise, plus l’intervention humaine résiduelle devient critique.

• Seconde ironie : cette intervention, on ne s’y entraîne plus - puisque la machine fait le quotidien à notre place.

On a donc conçu des systèmes qui réclament un opérateur d’exception, tout en le privant des occasions de le devenir. La panne, quand elle survient, tombe sur des équipes désentraînées.

L’automatisation ne supprime pas le besoin de compétence humaine. Elle le déplace vers le moment le plus difficile : la panne.

2. La dépendance à l’automatisation, nouvelle dépendance critique

À l’épisode 002, nous avions posé une règle : le cloud n’est pas un problème ; l’inconscience de sa dépendance au cloud en est un. Cette logique s’applique, mot pour mot, à l’automatisation.

Regardez la pile dont dépend un SOC moderne :

• des playbooks SOAR qui orchestrent la réponse,

• un EDR qui isole les postes tout seul,

• un moteur d’IA qui trie et priorise les alertes,

• des remédiations déclenchées sans aucune main humaine.

Chacune de ces briques est un point de dépendance. Et aucune n’est infaillible : un orchestrateur tombe, un connecteur casse, une licence expire, un playbook peut être empoisonné, un modèle peut halluciner. Le SIEM cloud lui-même peut devenir indisponible au pire moment.

Le jour où cette couche s’effondre, l’organisation ne perd pas un outil. Elle perd sa capacité d’agir - si elle n’a rien gardé d’autre.

Automatiser sans savoir faire sans, ce n’est pas gagner en résilience. C’est déplacer sa fragilité d’un cran vers le haut.

3. La compétence qui ne s’exerce pas disparaît

C’est ici que le sujet rejoint la résilience humaine, explorée à l’épisode 012. Nous y ajoutons une dimension : la compétence.

Une compétence n’est pas un acquis. C’est un muscle. Elle s’atrophie si elle ne travaille pas. L’aviation l’a appris dans la douleur : à force de voler au pilote automatique, certains équipages ont perdu les réflexes du pilotage manuel - au point que l’incapacité à reprendre les commandes a figuré parmi les causes premières de plusieurs accidents.

Le SOC n’échappe pas à la règle. Un analyste qui n’a jamais fait qu’appuyer sur « exécuter le playbook » saura-t-il trier une alerte à partir d’un log brut ? Mener une investigation sans la console qui fait tout à sa place ? Reconstruire une chronologie à la main ?

Le contexte aggrave le risque. Le dernier panorama ENISA sur les investissements (NIS Investments 2025) montre un basculement net : les organisations réallouent leurs moyens de l’humain vers la technologie et les services externalisés, tandis que le déficit de talents se creuse et qu’un tiers seulement prévoit de recruter. On automatise pendant qu’on amincit la couche humaine. Le pire moment pour perdre le geste.

Une capacité qu’on ne teste jamais n’est pas une capacité. C’est une supposition.

4. Reprendre la main : l’équivalent cyber de l’exercice de crise

Bonne nouvelle : on sait faire. Depuis longtemps.

Personne n’improvise une gestion de crise. On l’entraîne, encore et encore, par des exercices. C’est toute la logique du guide de l’ANSSI sur les exercices de gestion de crise cyber : les réflexes se construisent exercice après exercice, pour être prêts le jour où l’attaque survient.

La reprise manuelle relève exactement de la même discipline. Elle est l’exercice de crise de la couche automatisée.

Le NIST le formalise depuis quinze ans. Son guide de planification de la continuité (SP 800-34) inscrit noir sur blanc le recours à des « méthodes manuelles » comme mesure intérimaire de reprise - et impose que ces plans soient testés, éprouvés, entraînés. Documenter un mode dégradé sans jamais l’exécuter ne vaut rien.

Concrètement :

• Un « jour sans automatisation » : couper volontairement le SOAR le temps d’un exercice, et traiter les incidents à la main.

• Des runbooks de mode dégradé : la procédure exacte quand l’orchestrateur est indisponible.

• Une rotation des gestes manuels : pour que le savoir-faire ne repose pas sur une seule personne, un seul point de défaillance.

Un mode dégradé qui n’a jamais tourné n’est pas un plan. C’est un espoir.

5. Grille de maturité - la capacité de reprise manuelle

Comme à chaque épisode opérationnel, une grille pour se situer honnêtement - sans complaisance.

On ne vise pas le « tout manuel ». On vise la capacité intacte de basculer quand il le faut.

6. Concevoir pour la panne : la dégradation gracieuse

Un système résilient n’est pas un système qui ne tombe jamais. C’est un système qui tombe bien.

Le NIST, dans son guide sur les systèmes cyber-résilients (SP 800-160 vol. 2), fixe l’objectif : anticiper, résister, se rétablir, s’adapter - et réduire le risque de dépendre de ses ressources numériques. Traduit dans nos SOC, cela signifie concevoir le chemin de repli dès le départ, pas après la panne.

• Une dégradation gracieuse plutôt qu’un effondrement : quand l’automatisation lâche, le système bascule en mode manuel supervisé, pas dans le vide.

• Une commande manuelle prévue par conception : le fameux « bouton rouge », l’override humain, accessible et documenté.

• Un mode dégradé qui n’exige pas la couche perdue : évidence trop souvent oubliée - le repli ne doit pas dépendre de ce qui vient de tomber.

C’est aussi une question de gouvernance. La bonne question pour un COMEX n’est pas « notre SOC est-il automatisé ? ». C’est : « combien de temps tenons-nous sans notre couche d’automatisation - et l’avons-nous vérifié une seule fois ? »

La résilience ne se conçoit pas contre la panne. Elle se conçoit avec elle.

7. Le bon niveau de délégation

Que les choses soient claires : rien de ceci n’est un plaidoyer contre l’automatisation. Revenir au tout-manuel serait absurde, et perdant. L’enjeu n’est pas de déléguer moins. Il est de déléguer lucidement - en gardant, à côté de chaque geste confié à la machine, un humain encore capable de le reprendre.

C’est un arbitrage. Que délègue-t-on ? Jusqu’où ? Que garde-t-on littéralement sous la main ? Ce curseur - entre ce qu’on confie et ce qu’on retient - est le vrai sujet. Il ouvre une question que ce trimestre ne pouvait pas éviter, et que la prochaine chronique regardera en face.

Déléguer n’est pas abdiquer. Encore faut-il l’avoir décidé.

L’Essentiel pour Agir

1. Cartographiez vos dépendances à l’automatisation : listez chaque geste critique aujourd’hui confié à une machine (tri, isolement, remédiation, corrélation) et identifiez, pour chacun, ce qui se passe s’il s’arrête. Une dépendance non cartographiée est une surprise programmée.

2. Documentez ET testez le mode dégradé : écrivez les runbooks de reprise manuelle, puis exécutez-les pour de vrai. Un plan de repli qui n’a jamais tourné ne prouve rien le jour de l’incident.

3. Entraînez la reprise, régulièrement : instaurez un « jour sans automatisation » et faites tourner les gestes manuels dans l’équipe. La compétence se muscle par la répétition, comme un exercice de crise.

Conclusion

L’automatisation est un accélérateur formidable. Elle ne devient un piège que le jour où elle est aussi devenue notre seule option.

Reprendre la main n’est pas un retour en arrière. C’est la preuve qu’on maîtrise encore ce qu’on a confié à la machine. Une capacité qu’on ne peut plus exercer n’est pas une force acquise : c’est une dépendance qu’on ne contrôle plus.

Reste alors le curseur. Jusqu’où déléguer à la machine ce que nous ne saurons peut-être plus reprendre ? C’est la dernière question de ce trimestre. La plus inconfortable, aussi.

Ce n’est pas un statut. C’est une capacité. Et une capacité, ça s’entretient.

Bibliographie

« Lisanne Bainbridge — Ironies of Automation (Automatica, 1983) »

https://www.sciencedirect.com/science/article/abs/pii/0005109883900468

Le texte fondateur du paradoxe : automatiser le routinier laisse à l’humain les seules tâches rares et difficiles, et les compétences non exercées se dégradent. Le socle théorique de tout l’épisode.

« ANSSI — Organiser un exercice de gestion de crise cyber »

https://cyber.gouv.fr/publications/organiser-un-exercice-de-gestion-de-crise-cyber

Guide de référence français sur l’entraînement à la crise : les réflexes se construisent par l’exercice. La reprise manuelle relève exactement de la même discipline.

« NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems »

https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final

Inscrit noir sur blanc le recours à des « méthodes manuelles » comme mesure intérimaire de reprise, et impose de tester, entraîner et maintenir ces plans de continuité.

« NIST SP 800-160 Vol. 2 Rev. 1 — Developing Cyber-Resilient Systems »

https://csrc.nist.gov/pubs/sp/800/160/v2/r1/final

Cadre d’ingénierie de la cyber-résilience - anticiper, résister, se rétablir, s’adapter - et réduire le risque de dépendre de ses ressources numériques : la base de la dégradation gracieuse « by design ».

« ENISA — NIS Investments 2025 »

https://www.enisa.europa.eu/publications/nis-investments-2025

Enquête auprès de 1 080 organisations européennes : bascule des investissements de l’humain vers la technologie et les services, aggravation du déficit de talents. La toile de fond empirique de l’atrophie des compétences.

La semaine dernière, nous cherchions à automatiser la détection et la réponse sans anesthésier les équipes : garder l’humain dans la boucle, préserver la capacité de reprise en main. L’automatisation nous a fait gagner en vitesse de réaction.

Mais réagir vite, c’est encore réagir. C’est attendre que quelque chose se déclenche.

Il existe une posture plus inconfortable, et plus mûre : ne pas attendre l’incident. Aller chercher soi-même ses propres failles, avant qu’un adversaire ne s’en charge. C’est le terrain des tests offensifs et du Bug Bounty.

L’épisode 005 posait déjà l’idée : la résilience se joue avant l’incident, dans la conception, pas seulement dans la salle de crise. Éprouver ses défenses en conditions réelles, c’est pousser cette logique jusqu’au bout - se faire attaquer pour de faux, pour ne pas l’être pour de vrai sans le savoir.

Le sujet n’est pas technique. Il est de gouvernance. Car décider d’ouvrir ses systèmes à des chercheurs que l’on ne connaît pas suppose une forme rare d’assurance.

La vraie question n’est donc pas : avons-nous des failles ? Nous en avons tous. La vraie question est : sommes-nous assez mûrs pour vouloir les connaître avant l’attaquant - et pour agir une fois que nous les connaissons ?

1. De la défense qui attend à la défense qui provoque

Toute la cybersécurité défensive repose sur une posture d’attente. On attend l’alerte. On attend le signal faible. On attend le scan qui révèle une vulnérabilité connue. Même le SOC le plus automatisé, celui de l’épisode précédent, reste suspendu à un déclencheur.

Le test offensif renverse cette logique. Il ne demande pas « que va-t-il se passer ? ». Il demande : « que se passerait-il si quelqu’un essayait vraiment, maintenant, avec les moyens d’un attaquant ? »

Cette bascule change tout. Un scanner liste des failles théoriques. Un test offensif prouve qu’elles sont exploitables - ou non. Il transforme une hypothèse en démonstration.

Il y a une différence essentielle entre découvrir une faille chez soi, volontairement, dans un cadre maîtrisé, et la découvrir parce qu’un rançongiciel vient de chiffrer la production. Dans le premier cas, on choisit le moment, le périmètre et le coût. Dans le second, l’attaquant les choisit pour nous.

Point clé — éprouver ses défenses, c’est reprendre à l’adversaire le privilège de la surprise.

2. Trois dispositifs, une même intention : se faire attaquer pour de faux

Le vocabulaire offensif est souvent confondu. Pentest, Red Team et Bug Bounty ne sont ni des synonymes, ni des concurrents. Ce sont trois couches complémentaires.

Le test d’intrusion (pentest) est un audit mandaté, sur un périmètre défini, à un instant donné. Le NIST, dans son guide SP 800-115, en décrit la méthode : planification, règles d’engagement, exploitation contrôlée, remédiation. Utile - mais photographie figée.

La Red Team va plus loin. Elle simule un adversaire réaliste, avec ses tactiques, dans la durée, sans prévenir les équipes de défense. Elle ne teste pas que les failles techniques : elle éprouve la détection, la réponse, la coordination. Autrement dit, tout ce que nous avons construit dans les épisodes précédents.

Le Bug Bounty, lui, ouvre la recherche à une foule de chercheurs indépendants, rémunérés au résultat, en continu. Là où l’audit offre une photo, le Bug Bounty offre un film.

Point clé — ces dispositifs ne s’opposent pas. Ils se superposent - du ponctuel au continu, du connu à l’inconnu.

3. Ce que le Bug Bounty révèle vraiment d’une organisation

Voici le paradoxe que peu de dirigeants perçoivent : le Bug Bounty n’est pas d’abord un outil de découverte de failles. C’est un révélateur de maturité.

Ouvrir un programme suppose d’avoir déjà réglé une série de prérequis exigeants :

• un périmètre clair - le scope - qui dit ce qui peut être testé, et ce qui ne peut pas ;

• un canal de réception et une équipe capable de qualifier les rapports ;

• une chaîne de correction qui fonctionne réellement ;

• un cadre juridique protecteur et un budget de primes.

On n’ouvre pas un Bug Bounty pour devenir mûr. On l’ouvre parce qu’on l’est déjà.

L’État français l’a compris. Via la DINUM, il expose ses briques les plus sensibles - FranceConnect, ProConnect, la messagerie Tchap - à la communauté des chercheurs éthiques. L’argument officiel est limpide : repérer des failles inconnues en continu, là où un audit ne donne qu’un instantané, tout en faisant monter les équipes en maturité.

Accepter que des inconnus cherchent la faille chez soi, c’est afficher une confiance que peu d’organisations assument. Ce n’est pas une faiblesse exposée. C’est une force démontrée.

Point clé — le Bug Bounty ne fabrique pas la maturité. Il la rend visible.

4. Le piège fatal : trouver ne suffit pas

Nous l’avons déjà écrit à propos de la gestion des vulnérabilités : scanner ne sécurise rien. Ce qui compte, ce n’est pas la découverte, c’est ce qu’on en fait. L’inaction organisée reste le premier facteur de compromission.

Le Bug Bounty n’échappe pas à cette règle - il l’aggrave. Car ici, la faille n’est pas remontée par un outil silencieux, mais par un humain qui attend une réponse.

Un rapport ignoré, un triage qui traîne des semaines, une prime versée trop tard : et le chercheur ne reviendra pas. Pire, il en parlera. La réputation d’un programme se construit sur la vitesse de réponse, bien avant le montant des primes.

Autrement dit, un Bug Bounty ne mesure pas d’abord votre capacité à trouver des failles. Il mesure, impitoyablement, votre capacité à les corriger. Sans chaîne de remédiation fluide, tout le reste est cosmétique.

Point clé — un programme offensif expose vos délais de correction au grand jour. C’est un miroir, pas un bouclier.

5. Le crowdsourcing n’est pas le Far West : le cadre juridique et éthique

Inviter des inconnus à tester ses systèmes sans cadre serait irresponsable. Le crowdsourcing éthique repose précisément sur un contrat clair entre l’organisation et le chercheur.

Ce cadre tient en quelques piliers : un périmètre autorisé (ce qui peut être testé, et ce qui ne peut pas), des règles d’engagement (pas de destruction, pas d’exfiltration de données réelles), et une protection du chercheur de bonne foi - le fameux « safe harbor ».

En France, l’ANSSI joue un rôle de coordonnateur : elle reçoit les signalements de vulnérabilités, peut servir d’intermédiaire entre un chercheur et une organisation, et protège l’anonymat de celui qui alerte de bonne foi. Au niveau européen, l’ENISA structure la divulgation coordonnée (CVD), désormais adossée à la directive NIS2.

Sans ce cadre, deux dérives guettent : le risque juridique pour le chercheur honnête, et la divulgation sauvage - le full disclosure - qui expose la faille avant tout correctif.

Point clé — la confiance ne se décrète pas. Elle s’organise, par un cadre qui protège les deux parties.

6. Quand l’offensif devient une obligation : le signal réglementaire

Ce qui relevait hier du volontariat devient aujourd’hui une exigence. Avec DORA, le règlement européen sur la résilience opérationnelle du secteur financier, les tests offensifs entrent dans la loi.

Ses articles 26 et 27 imposent aux entités financières jugées significatives un test d’intrusion fondé sur la menace (TLPT), au moins tous les trois ans, sur les systèmes de production réels, à partir de scénarios tirés de la menace effective. Non plus une case à cocher, mais une preuve de résilience en conditions réalistes.

Le régulateur acte ainsi une conviction que Plan R défend depuis l’épisode 005 : la robustesse ne se déclare pas, elle se démontre. Le « shift left » - éprouver au plus tôt - franchit un cap : il devient une norme opposable.

Pour les organisations hors du champ financier, le message reste le même. Ce que DORA rend obligatoire pour les banques, la logique de résilience le recommande à toutes : ne pas attendre la contrainte pour se faire éprouver.

Point clé — le test offensif n’est plus un luxe de maturité. Il devient un standard de gouvernance.

L’Essentiel pour Agir

1. Commencez par la chaîne de remédiation, pas par le programme : avant d’ouvrir le moindre canal de signalement, assurez-vous de savoir qualifier, prioriser et corriger une faille dans des délais tenus. Un programme sans capacité de correction produit de la dette, pas de la sécurité.

2. Choisissez le dispositif adapté à votre niveau de maturité : un audit ponctuel pour cadrer, une Red Team pour éprouver la détection, un Bug Bounty pour la couverture continue. Ne sautez pas les étapes : le crowdsourcing suppose des fondations déjà solides.

3. Formalisez le cadre avant d’ouvrir la porte : périmètre, règles d’engagement, protection du chercheur, articulation avec l’ANSSI pour la divulgation coordonnée. La confiance envers des inconnus ne s’improvise pas - elle se contractualise.

Conclusion

Éprouver ses défenses avant l’attaquant n’est pas un exercice technique. C’est une décision de gouvernance, et un aveu de lucidité : admettre que l’on a des failles, et vouloir les connaître pendant qu’il en est encore temps.

Le Bug Bounty et les tests offensifs ne rendent aucune organisation invulnérable. Ils rendent visible ce qu’elle refusait de regarder - et mesurent sa capacité à y répondre.

Mais tout cela repose sur une hypothèse que nous n’avons pas encore interrogée : jusqu’où peut-on confier à d’autres - des inconnus, des tiers, des machines - le soin de nous éprouver, et de décider à notre place ? Où s’arrête la délégation, et où commence la responsabilité que nul ne peut déléguer ?

C’est là que se jouera la suite.

La résilience n’est pas l’art de ne jamais tomber. C’est celui de choisir, soi-même, le terrain de l’épreuve.

Bibliographie

Sources institutionnelles, vérifiées en direct le 3 juillet 2026.

« NIST SP 800-115 - Technical Guide to Information Security Testing and Assessment »

https://csrc.nist.gov/pubs/sp/800/115/final

Guide méthodologique de référence sur les tests de sécurité et l’intrusion : planification, règles d’engagement, exploitation contrôlée et remédiation. Le socle pour cadrer un pentest sérieux.

« ENISA - Coordinated Vulnerability Disclosure »

https://www.enisa.europa.eu/topics/vulnerability-disclosure

Cadre européen de divulgation coordonnée des vulnérabilités : rôles des chercheurs, coordinateurs et éditeurs, articulation avec NIS2 et la base européenne des vulnérabilités (EUVD).

« ANSSI / CERT-FR - Signalement et déclaration de vulnérabilités »

https://cyber.gouv.fr/declaration-vulnerabilites

Le CERT-FR coordonne le traitement des vulnérabilités signalées et peut servir d’intermédiaire entre un chercheur et une organisation, en préservant l’anonymat du lanceur d’alerte de bonne foi.

« DINUM - Le Bug Bounty, un dispositif pour renforcer la sécurité des services numériques de l’État »

https://www.numerique.gouv.fr/actualites/le-bug-bounty-un-dispositif-innovant-pour-renforcer-la-securite-des-services-numeriques/

Cas réel de l’État français (FranceConnect, ProConnect, Tchap) : le Bug Bounty y est présenté comme un moyen de repérer des failles inconnues en continu - à la différence d’un audit ponctuel - et de faire monter les équipes en maturité.

« Règlement (UE) 2022/2554 (DORA), articles 26-27 - Tests d’intrusion fondés sur la menace (TLPT) »

https://eur-lex.europa.eu/eli/reg/2022/2554/oj?locale=fr

Texte réglementaire qui rend les tests offensifs (TLPT) obligatoires, au moins tous les trois ans, pour les entités financières significatives. La preuve que l’épreuve offensive devient une norme de gouvernance opposable.

Il est 3h17. Une alerte se déclenche. Le temps que l’analyste de garde émerge, la machine a déjà fait le travail : poste isolé, accès réinitialisé, ticket ouvert et documenté. Au réveil, tout est sous contrôle. C’est exactement ce qu’on attend d’un SOC moderne.

Depuis deux épisodes, nous suivons le fil de l’intelligence au service de la résilience : l’IA défensive qui augmente la détection (024), l’IA offensive qui industrialise l’attaque (025). La suite logique, c’est le passage de la détection à la réponse. Comment standardiser ce que l’on cherche, puis automatiser ce que l’on fait une fois qu’on l’a trouvé ?

Deux approches répondent à cette question : le Detection as Code et le SOAR. La première traite les règles de détection comme du code. La seconde transforme la réponse en chaîne d’exécution automatisée. Ensemble, elles promettent vitesse, cohérence et sérénité.

Le gain de résilience est réel. Mais il a une contrepartie qu’on évoque rarement. À force de confier les gestes aux automatismes, on cesse de les pratiquer. Et le jour où l’attaque sort du cadre prévu, c’est un muscle atrophié qu’on somme de réagir.

La vraie question n’est donc pas : jusqu’où automatiser ? C’est : que reste-t-il d’humain quand tout fonctionne tout seul - et ce jour-là, sait-il encore agir ?

1. Detection as Code : la détection sort de l’artisanat

Pendant longtemps, la détection a été un artisanat. Une règle de corrélation écrite à la main dans la console d’un SIEM, ajustée un soir d’astreinte, jamais documentée. Elle fonctionne - tant que son auteur est là. Le jour où il part, plus personne ne sait pourquoi elle existe, ni si on peut la modifier sans tout casser.

Le Detection as Code applique à la détection les principes qui ont fait leurs preuves dans le développement logiciel. Une règle devient un artefact versionné : stockée dans un dépôt Git, revue par un pair, testée automatiquement, déployée par un pipeline d’intégration continue. On sait qui l’a écrite, quand, pourquoi, et ce qu’elle a changé.

Le standard ouvert de référence s’appelle Sigma : un format générique qui décrit une détection une seule fois, puis se traduit vers n’importe quel SIEM. On retrouve ici un fil tendu depuis l’épisode 002 : écrire ses détections dans un format ouvert, c’est refuser le verrouillage propriétaire. La logique de défense ne doit pas être l’otage d’un éditeur.

Reste à savoir ce que l’on couvre. C’est le rôle de MITRE ATT&CK : cartographier ses règles contre les techniques d’attaque connues permet de mesurer sa couverture - et surtout de voir ses angles morts. Car une carte de couverture, c’est d’abord une carte de ce que l’on ne voit pas encore.

Standardiser la détection n’est pas un confort d’ingénieur. C’est rendre visible ce que l’on ne voyait pas, et reproductible ce que l’on aurait, sinon, fini par oublier.

2. SOAR : du diagnostic à l’action

Le Detection as Code répond à la question « que cherche-t-on ? ». Le SOAR répond à la suivante : « que fait-on quand on a trouvé ? ». Security Orchestration, Automation and Response : il connecte les outils, exécute des tâches sans intervention humaine, et applique des playbooks pré-écrits pour répondre aux incidents. Il est le bras opérationnel de la réponse.

Les gains sont concrets. Sur les incidents répétitifs - tri d’un phishing, mise en quarantaine d’un e-mail, isolement d’un poste, enrichissement d’une alerte - le temps de réponse s’effondre. L’analyste cesse de crouler sous des centaines de notifications quotidiennes. La réaction devient cohérente : plus d’improvisation à 3h du matin sur un cas pourtant connu.

Mais l’ordre des opérations compte. La CISA, dans ses recommandations 2025 sur le SIEM et le SOAR, le rappelle sans détour : on ne déploie pas un SOAR avant que la détection soit fiable. Automatiser une réponse sur la base d’alertes bruitées, c’est industrialiser l’erreur. La détection d’abord ; l’automatisation ensuite.

Surtout, ces recommandations insistent sur un point essentiel : ni le SIEM ni le SOAR ne sont des outils « à installer et oublier ». Ce sont des chantiers permanents, qui exigent du personnel hautement qualifié pour concevoir, maintenir et corriger les playbooks. L’automatisation ne réduit pas le besoin de compétence. Elle le déplace.

Le SOAR ne remplace pas la décision. Il exécute, à grande vitesse, une décision déjà prise à froid - celle que l’on a inscrite dans un playbook.

3. Le vrai bénéfice : libérer du temps de cerveau

On présente souvent l’automatisation comme un moyen de « faire plus avec moins ». C’est une lecture comptable, et elle passe à côté de l’essentiel. Le véritable enjeu n’est pas de réduire les effectifs. C’est de réallouer la ressource la plus rare d’un SOC : l’attention experte.

Le raisonnement est simple. Le répétitif, le connu, le faible enjeu - on l’automatise. Le nouveau, l’ambigu, le critique - on le réserve à l’humain. Chaque faux positif fermé automatiquement, c’est une minute rendue à l’analyste pour traiter le signal faible qui, lui, mérite un cerveau.

C’est exactement la posture défendue à l’épisode 024 : l’IA défensive comme copilote, pas comme pilote automatique. La machine industrialise le geste connu pour que l’humain se concentre sur ce qu’aucune règle n’a anticipé. La valeur d’un expert ne réside pas dans le tri de masse. Elle réside dans le jugement.

Encore faut-il que ce temps libéré soit réinvesti là où il compte - chasse aux menaces, analyse des angles morts, conception de nouveaux scénarios. S’il est simplement supprimé, on n’a pas gagné en résilience : on a réduit la voilure en attendant la tempête.

Automatiser les cas connus pour réserver les neurones aux cas inconnus : voilà l’arbitrage. Il ne s’agit pas de remplacer l’humain, mais de le déplacer là où il est irremplaçable.

4. Le piège : l’anesthésie

Voici le paradoxe que personne n’affiche sur les plaquettes commerciales. En 1983, la chercheuse Lisanne Bainbridge le formulait dans un texte resté célèbre, « Ironies of Automation ». Son constat : en automatisant l’essentiel d’une tâche, on confie à l’humain précisément la part qui ne s’automatise pas - la situation rare, anormale, imprévue - tout en le privant de la pratique quotidienne qui le maintenait compétent.

Transposez au SOC. Quand la machine traite 95 % des alertes, l’analyste perd ses réflexes sur les 5 % restants. Le jour où survient le scénario hors playbook - une attaque inédite, une opération autonome pilotée par IA comme l’espionnage évoqué à l’épisode 025, un enchaînement qu’aucune règle n’avait prévu - il faut improviser. Avec un muscle qui ne s’est pas entraîné depuis des mois.

S’ajoute le paradoxe de la vigilance. L’humain ne fait plus : il surveille une machine qui fait. Or surveiller passivement est épuisant et propice à l’erreur. Pire, un biais s’installe - le biais d’automatisation : on finit par faire confiance au verdict automatique même quand il se trompe. Une isolation déclenchée à tort sur un compte VIP, et la mini-crise interne est garantie.

L’anesthésie, ce n’est donc pas l’automatisation elle-même. C’est l’automatisation que l’on a cessé de questionner. Le système tourne, les voyants sont verts, et l’on confond « ça fonctionne » avec « nous sommes prêts ». Ce sont deux choses différentes.

Plus on automatise, plus la compétence humaine résiduelle devient rare - et plus elle devient précieuse. Le danger n’est pas la machine qui agit. C’est l’humain qui désapprend.

5. Garder l’humain dans la boucle (vraiment)

« Human in the loop » est devenu un slogan. Pour qu’il veuille dire quelque chose, il faut décider, action par action, où placer le curseur. Et ce curseur n’est pas technique : il dépend de deux critères simples - la réversibilité de l’action, et son rayon d’impact. Plus une action est irréversible et large, plus l’humain doit rester à la manœuvre.

Cette gradation n’est pas de la timidité. C’est du discernement. Le retour d’expérience industriel est connu : automatiser l’isolement de systèmes OT a déjà provoqué des blocages intempestifs de production, imposant un retour à la supervision humaine. Tout ce qui touche au critique se décide ; cela ne se script pas aveuglément.

Reste à situer son organisation. La grille de maturité Plan R offre trois paliers :

Le bon niveau d’automatisation n’est pas une question d’outil, mais d’arbitrage : il se règle sur la réversibilité et l’impact. L’irréversible reste humain.

6. Entretenir le muscle

Si l’automatisation atrophie la compétence, alors la compétence doit s’entretenir comme un muscle : par l’exercice. Le NIST, dans la version 3 de son guide de réponse aux incidents (SP 800-61, 2025), le pose noir sur blanc : il est impossible de disposer d’une procédure pour chaque situation. On documente les incidents les plus courants, mais on mise sur l’amélioration continue, nourrie par les leçons de chaque exercice.

Concrètement, cela veut dire débrancher régulièrement le pilote automatique. Faire tourner les analystes sur des investigations manuelles. Organiser des exercices red team / purple team qui génèrent, volontairement, des scénarios hors playbook. Traiter chaque angle mort de couverture ATT&CK comme une découverte à exploiter, pas comme une statistique à ranger.

Car un playbook est une photographie. Il fige la connaissance des menaces d’hier. L’attaquant, lui, cherche précisément la faille que le playbook n’a pas prévue. La couverture de détection d’aujourd’hui dessine, en creux, les angles morts de demain.

C’est là que la boucle se referme avec le bénéfice de la section III : le temps libéré par l’automatisation n’a de sens que s’il est réinvesti dans la chasse à l’inconnu. Automatiser pour cesser de chercher, c’est offrir l’avantage à l’adversaire - et ne s’en apercevoir qu’au prochain scénario inédit.

Un playbook n’est jamais terminé. Le jour où l’on cesse d’en écrire de nouveaux, c’est que l’on a renoncé à anticiper. L’exercice n’est pas un luxe : c’est l’anesthésiant que l’on refuse de prendre.

L’Essentiel pour Agir

1. Versionnez votre détection. Sortez vos règles des consoles : Git, revue par les pairs, tests automatisés, cartographie ATT&CK. Une détection que l’on ne peut ni tracer ni rejouer est une dépendance cachée - celle qui disparaît avec son auteur.

2. Graduez l’automatisation par la réversibilité. Refusez le « tout ou rien ». Croisez réversibilité et rayon d’impact pour chaque action : l’irréversible et le critique restent une décision humaine. Le SOAR exécute ; il n’arbitre pas.

3. Exercez le scénario hors playbook. Débranchez le pilote automatique à intervalles réguliers. Investigations manuelles, exercices red/purple team, simulations de cas inédits : la compétence est un muscle, et le muscle s’entretient ou s’atrophie.

Conclusion

L’automatisation de la détection et de la réponse est un gain de résilience que nul ne devrait bouder. Elle apporte vitesse, cohérence, endurance. Mais elle introduit une dépendance nouvelle, et invisible : envers le playbook, envers le verdict de la machine, envers le confort du voyant vert. Or la résilience, depuis le premier épisode, n’a jamais été l’absence de dépendance. Elle est la conscience de ses dépendances.

Reste alors une question qui monte, et qui sera bientôt la nôtre. Si la machine exécute et que l’humain arbitre, où passe exactement la frontière ? Qu’a-t-on le droit de déléguer à un automatisme - et qu’est-ce que l’on ne devrait jamais lui abandonner, même quand il fait mieux que nous ? Plus nous déléguons, plus cette frontière devient le vrai sujet.

Automatiser, c’est déléguer l’exécution. Ce n’est jamais déléguer le jugement. Le jour où l’on confond les deux, on n’a pas gagné du temps : on a perdu la main.

Bibliographie

« CISA / ACSC - Implementing SIEM and SOAR Platforms: Executive Guidance (2025) »

https://www.cisa.gov/resources-tools/resources/guidance-siem-and-soar-implementation

Recommandations conjointes US/Australie sur le SIEM et le SOAR : déployer le SIEM avant le SOAR, et rappel que ce ne sont pas des outils « à installer et oublier ». Source directe des sections II et V.

« NIST SP 800-61r3 - Incident Response Recommendations and Considerations (2025) »

https://csrc.nist.gov/pubs/sp/800/61/r3/final

Référence de la réponse à incident, alignée sur le CSF 2.0. Pose le principe clé de la section VI : on ne peut documenter chaque situation ; il faut miser sur l’amélioration continue.

« ANSSI (PA-022) - Recommandations de sécurité pour l’architecture d’un système de journalisation (2022) »

https://cyber.gouv.fr/sites/default/files/2022/01/anssi-guide-recommandations_securite_architecture_systeme_journalisation.pdf

Socle français de la détection : journalisation, corrélation et déclenchement d’alertes au SOC (annexe C). Le prérequis indispensable avant toute automatisation de la réponse.

« SigmaHQ - Generic Signature Format for SIEM Systems »

https://sigmahq.io/

Le standard ouvert du Detection as Code : décrire une détection une fois, la versionner, la partager et la déployer vers n’importe quel SIEM. Cœur de la section I et levier anti-verrouillage propriétaire.

« MITRE ATT&CK - Adversary Tactics and Techniques Knowledge Base »

https://attack.mitre.org/

Référentiel de cartographie des techniques d’attaque. Permet de mesurer la couverture de détection et, surtout, de rendre visibles les angles morts à traiter en priorité.

« Lisanne Bainbridge - « Ironies of Automation », Automatica, vol. 19 (1983) »

https://en.wikipedia.org/wiki/Ironies_of_Automation

Texte fondateur sur le paradoxe de l’automatisation : automatiser l’essentiel laisse à l’humain l’imprévu, tout en érodant la compétence nécessaire pour y faire face. Clé de voûte de la section IV.

La semaine dernière (024), nous avons regardé l’IA du bon côté de la barricade : le SOC qui se réinvente, l’analyste augmenté, le copilote qui trie, corrèle et accélère. Une bonne nouvelle. Mais une moitié d’histoire seulement.

Car la même technologie qui muscle nos défenses arme aussi nos adversaires. Le copilote du défenseur a un jumeau sombre : l’opérateur de l’attaquant.

En 2026, l’attaquant n’a plus besoin d’être un génie. Il lui suffit de bien prompter. Un courriel d’hameçonnage sans accroc, un script malveillant généré à la demande, une reconnaissance automatisée sur des centaines de cibles : ce qui exigeait des semaines de travail qualifié se commande désormais en langage naturel.

Au numéro 007, nous avions entrouvert cette porte avec les deepfakes en temps réel. Élargissons-la. Le deepfake n’était qu’une facette d’un spectre offensif bien plus vaste, qui couvre aujourd’hui toute la chaîne d’attaque.

Connaître l’adversaire n’est pas un luxe d’expert. C’est un fondement de la résilience : on ne se défend bien que contre ce qu’on comprend. Et ce qu’il faut comprendre, en 2026, est plus nuancé que les gros titres ne le laissent croire.

La vraie question n’est pas de savoir si l’IA transforme l’attaque. C’est de savoir où se situe la rupture réelle — et pourquoi la réponse ne pourra jamais être seulement technologique.

1. Industrialisation, pas (encore) révolution

Commençons par désamorcer le fantasme. Non, l’IA n’a pas réinventé la cyberattaque. Les vecteurs restent les mêmes : hameçonnage, exploitation de vulnérabilités, vol d’identifiants, mouvement latéral. Ce que l’IA change, c’est l’échelle, la vitesse et le coût.

L’ANSSI le formule avec une prudence salutaire dans son Panorama de la cybermenace 2025 : les attaquants montrent un intérêt pour ces outils, sans qu’il soit pour autant pertinent de parler de changement de paradigme. Même lucidité outre-Atlantique : Google observe une intégration croissante de l’IA, mais aucune capacité de rupture qui bouleverserait fondamentalement le paysage.

Le chiffre qui compte est ailleurs. Selon l’ENISA, plus de 80 % des campagnes d’ingénierie sociale s’appuient désormais sur l’IA pour produire ou enrichir leurs contenus. L’hameçonnage truffé de fautes a vécu. Place au message contextualisé, fluide, parfois multilingue, fabriqué à l’échelle industrielle.

C’est le vrai basculement : l’IA n’invente pas de nouvelles attaques, elle rend les anciennes accessibles, crédibles et massives. L’hameçonnage devient un service (PhaaS), le rançongiciel un abonnement (RaaS), la fraude une chaîne de production.

L’IA offensive est d’abord un multiplicateur. Elle ne crée pas la menace : elle en abaisse le coût et en démultiplie la portée.

2. Le spectre offensif : l’IA sur toute la chaîne d’attaque

Pour se défendre, il faut cartographier. Voici comment l’IA s’invite à chaque étape de la chaîne d’attaque.

Ce tableau n’a rien de théorique. Google a documenté en 2025 et 2026 des familles de maliciels — PROMPTFLUX, PROMPTSTEAL — qui interrogent un modèle de langage pendant leur exécution pour réécrire leur propre code ou générer leurs commandes à la volée, plutôt que de les coder en dur. L’antivirus à signatures, qui cherche un motif connu, perd pied face à un code qui se réinvente chaque heure.

L’ANSSI, de son côté, a repéré des infrastructures offensives — pages de collecte, sites d’hameçonnage — manifestement générées à l’aide d’IA.

L’IA ne se contente pas d’aider l’attaquant en amont. Elle s’embarque désormais dans l’arme elle-même.

3. Le vrai point de bascule : l’autonomie agentique

S’il existe une rupture, elle est là. Pas dans le phishing mieux écrit, mais dans l’IA qui agit seule.

En novembre 2025, un éditeur d’IA a détecté et publié le premier cas documenté de campagne de cyberespionnage orchestrée par IA à grande échelle. Un groupe affilié à un État (désigné GTG-1002) a détourné un assistant de codage agentique pour mener une opération contre une trentaine de cibles — entreprises technologiques, institutions financières, industriels, agences gouvernementales — avec une poignée d’intrusions réussies.

Le détail qui glace : l’IA a exécuté 80 à 90 % des tâches tactiques de manière autonome. Reconnaissance, découverte de vulnérabilités, développement d’exploits, collecte d’identifiants, mouvement latéral, exfiltration. L’humain n’était plus l’opérateur. Il était le superviseur. Et la machine enchaînait des milliers de requêtes par seconde — un rythme qu’aucune équipe humaine ne peut tenir.

Souvenons-nous du 024 : nous y célébrions l’IA comme copilote du défenseur. Voici son miroir exact. Le même paradigme — déléguer l’exécution à la machine, garder l’humain à la supervision — sert désormais l’attaque. La symétrie est troublante.

Comment ont-ils franchi les garde-fous ? En découpant la tâche malveillante en sous-tâches anodines, en faisant croire au modèle qu’il menait un test de sécurité légitime. La même ingénierie sociale qu’on applique aux humains, appliquée à la machine.

La rupture n’est pas que l’IA attaque mieux. C’est qu’elle attaque seule, vite, et à une échelle inédite.

4. L’asymétrie qui s’aggrave — et ce qui la nuance

Pourquoi tout cela favorise-t-il l’attaquant ? Pour trois raisons structurelles.

D’abord, la barrière à l’entrée s’effondre. Des modèles « jailbreakés » ou malveillants — WormGPT hier, Xanthorox aujourd’hui — se vendent au marché noir. Un acteur peu qualifié commande désormais ce que seul un expert produisait. L’ENISA et l’ANSSI le confirment : la sophistication n’est plus réservée aux groupes d’élite.

Ensuite, l’asymétrie d’effort. L’attaquant doit réussir une fois ; le défenseur, à chaque fois. L’IA démultiplie le nombre de tentatives sans démultiplier le coût. Mille hameçonnages personnalisés valent désormais le prix d’un.

Enfin, la vitesse. Quand une faille connue est exploitée en quelques jours après sa publication, et que la machine ne dort jamais, la fenêtre de réaction du défenseur se réduit à peau de chagrin.

Mais — et c’est tout l’esprit de Plan R — l’asymétrie n’est pas une fatalité. La même IA arme aussi la défense (024). Le défenseur connaît son terrain ; l’attaquant doit le découvrir. Les éditeurs, eux, détectent, désactivent, publient. L’attaquant n’a pas gagné. Il a accéléré.

L’IA ne rend pas la défense impossible. Elle rend l’impréparation beaucoup plus coûteuse.

5. Connaître l’adversaire : une grille de maturité

Comprendre l’IA offensive ne sert à rien si cela ne se traduit pas en posture. Voici où situer la vôtre.

Cette grille n’est pas un examen. C’est une boussole. L’objectif n’est pas d’être « natif » partout dès demain, mais de repérer où l’on reste réactif — c’est-à-dire en retard d’une attaque.

On ne se défend pas contre l’IA offensive avec un produit. On s’en défend avec un niveau de maturité.

6. Pourquoi la réponse ne peut pas être que technologique

Voici la tentation : répondre à l’IA offensive par l’IA défensive, et clore le dossier. Erreur. Empiler une couche d’IA sur une organisation immature, c’est accélérer ses erreurs au lieu de les corriger.

L’ANSSI, dans ses recommandations pour les systèmes d’IA générative, pose un principe non négociable : proscrire l’usage automatisé de l’IA pour les actions critiques sur le système d’information. Autrement dit, garder l’humain dans la boucle là où ça compte. Le réflexe qui vaut pour notre IA défensive (024) vaut pour notre rapport à la menace.

Car les parades les plus efficaces contre l’IA offensive restent humaines et procédurales. Le mot de passe d’équipe contre un deepfake (007). La contre-validation sur un autre canal avant un virement. La culture du doute légitime face à l’urgence fabriquée. Aucune IA ne remplace cela.

L’attaquant automatise pour gagner en vitesse. Le défenseur, lui, doit savoir où ralentir volontairement — où insérer un point de friction humain qui casse l’automatisme de l’attaque.

Contre une attaque qui pense à la vitesse de la machine, le dernier rempart est souvent un processus humain, lent et délibéré.

L’Essentiel pour Agir

1. Cartographiez l’IA offensive sur votre chaîne d’attaque :

Reprenez la grille de la section II et demandez-vous, à chaque étape, ce que l’IA change pour vos adversaires. On ne protège que ce qu’on a vu venir.

2. Posez des points de friction humains sur vos actions critiques :

Virements, changements d’accès, partages de données sensibles : exigez une contre-validation hors-bande. C’est l’antidote le plus simple à l’automatisation de l’attaque.

3. Encadrez vos propres usages de l’IA avant qu’on ne les détourne :

Charte d’usage, validation humaine sur les actions critiques, journalisation. Votre IA défensive est aussi une cible.

Conclusion

Connaître l’adversaire n’a jamais été un aveu de faiblesse. C’est le premier geste de la résilience. L’IA offensive de 2026 n’est ni la fin du monde brandie par les marchands de peur, ni un gadget. C’est un accélérateur qui industrialise l’ancien et, par l’agentique, ouvre une page réellement nouvelle.

La résilience ne consiste pas à espérer un outil qui annulera l’asymétrie. Elle consiste à comprendre cette asymétrie pour décider, lucidement, où placer l’humain et où laisser faire la machine.

Et c’est précisément là que se loge la prochaine question. Nous avons vu l’IA défendre, puis attaquer. Reste la plus difficile : jusqu’où déléguer ? Où la machine doit-elle agir, et où l’humain demeure-t-il irremplaçable ? Le bon réglage du curseur n’est pas technique. Il est, déjà, une décision de gouvernance.

Bibliographie

« ANSSI — Panorama de la cybermenace 2025 (CERTFR-2026-CTI-002) »

https://www.cert.ssi.gouv.fr/cti/CERTFR-2026-CTI-002/

Le bilan annuel de référence pour la France. L’ANSSI y constate l’intérêt des attaquants pour l’IA générative (phishing crédibles, infrastructures malveillantes générées) tout en refusant de parler de « changement de paradigme » — une nuance précieuse contre le sensationnalisme.

« ENISA — Threat Landscape 2025 »

https://www.enisa.europa.eu/sites/default/files/2026-01/ENISA%20Threat%20Landscape%202025_v1.2.pdf

Panorama européen fondé sur près de 4 900 incidents. Source du chiffre clé : plus de 80 % des campagnes d’ingénierie sociale s’appuient désormais sur l’IA. Documente aussi l’IA comme arme et comme cible, et l’émergence de modèles malveillants autonomes.

« Google Threat Intelligence Group — AI Threat Tracker (février 2026) »

https://cloud.google.com/blog/topics/threat-intelligence/distillation-experimentation-integration-ai-adversarial-use

Cas réels d’IA intégrée à toute la chaîne d’attaque (maliciels « just-in-time » PROMPTFLUX et PROMPTSTEAL, attaques par distillation). Même lucidité que l’ANSSI : pas de capacité de rupture observée à ce stade.

« Anthropic — Disrupting the first reported AI-orchestrated cyber espionage campaign (nov. 2025) »

https://assets.anthropic.com/m/ec212e6566a0d47/original/Disrupting-the-first-reported-AI-orchestrated-cyber-espionage-campaign.pdf

Premier cas documenté d’une campagne d’espionnage orchestrée par IA agentique (GTG-1002) : ~30 cibles, 80 à 90 % des tâches exécutées de façon autonome. L’ancrage concret du vrai point de bascule analysé en section 3.

« ANSSI — Recommandations de sécurité pour un système d’IA générative (PA-102, avril 2024) »

https://messervices.cyber.gouv.fr/documents-guides/Recommandations_de_s%C3%A9curit%C3%A9_pour_un_syst%C3%A8me_d_IA_g%C3%A9n%C3%A9rative.pdf

35 recommandations dont un principe non négociable : proscrire l’usage automatisé de l’IA pour les actions critiques. Le contrepoint « gouvernance » qui fonde la thèse : la réponse ne peut pas être que technologique.

Un analyste de SOC reçoit aujourd’hui des centaines d’alertes par jour. Il en traite une fraction. Le reste s’accumule, se périme, ou se dilue dans la masse. Ce n’est pas un défaut de compétence. C’est une question d’échelle.

Pendant ce temps, l’attaquant ne ralentit pas. Un rançongiciel chiffre un parc en quelques heures. Une compromission d’identité se propage en quelques minutes. Dans son panorama 2025, l’ENISA est sans ambiguïté : l’IA est désormais présente à chaque étape de la chaîne d’attaque, de la reconnaissance à la diffusion de la charge.

Le rapport de force est limpide. D’un côté, des attaques qui s’industrialisent et accélèrent. De l’autre, une capacité humaine d’analyse qui, elle, reste constante.

Au trimestre précédent, nous avons cartographié ce qui compte (épisode 023) : données, infrastructures, identité, souveraineté. Nous savons désormais ce que nous protégeons. Reste une question plus brutale : comment tenir quand le choc arrive à la vitesse de la machine ?

La réponse passe par l’automatisation. Elle est inévitable. Mais elle ouvre un piège : à force d’accélérer la défense, on finit parfois par déléguer le jugement. Or le jugement, lui, ne s’automatise pas.

La vraie question n’est pas « quel outil choisir ? ». C’est : quelle place reste à l’analyste quand la machine filtre 95 % du bruit ?

1. L’écart de vitesse : l’automatisation n’est plus une option

Pendant longtemps, le SOC a fonctionné de façon artisanale : une alerte arrive, un humain enquête, décide, agit. Ce modèle a tenu tant que les volumes étaient gérables. Ils ne le sont plus.

Trois réalités l’ont rendu intenable :

• L’explosion des alertes : entre logs applicatifs, détections EDR et signaux réseau, un analyste croule sous des centaines de notifications quotidiennes. La « fatigue d’alerte » est devenue chronique.

• La vitesse des attaques : chaque minute perdue accroît l’impact et le coût. L’humain n’est pas conçu pour réagir à l’échelle de la seconde.

• Le coût humain : la pression permanente nourrit un turnover élevé dans les SOC. Automatiser le répétitif, c’est aussi préserver les équipes de l’épuisement.

Refuser l’automatisation, ce n’est pas protéger l’humain. C’est le condamner à réagir toujours trop tard. L’IA défensive n’est pas un gadget de modernité : c’est une réponse structurelle à un déséquilibre devenu insoutenable.

Sans automatisation, l’organisation ne réagit pas plus prudemment. Elle réagit simplement trop lentement.

2. Co-pilote, pas pilote : ce que l’IA sait faire, et ce qu’elle ne fera pas

L’IA appliquée à la détection excelle sur un terrain précis : le volume, la répétition, la corrélation. Elle trie les faux positifs évidents, croise un indicateur avec des bases de threat intelligence, repère une anomalie comportementale invisible à l’œil humain, et restitue un contexte enrichi en quelques secondes.

C’est considérable. Sur ces tâches, elle ne fatigue pas, ne décroche pas à 3 heures du matin, et ne laisse pas une alerte filer faute de temps.

Mais il y a une frontière qu’elle ne franchit pas. L’IA voit des motifs ; elle ne comprend pas les enjeux. Elle détecte une connexion anormale ; elle ignore que ce compte appartient au directeur financier en déplacement à l’étranger. Elle signale un transfert massif ; elle ne sait pas qu’une clôture comptable est en cours.

Le diagnostic — relier un signal technique à une réalité métier, arbitrer sous incertitude, décider quand l’information est incomplète — reste un acte de jugement. Et le jugement engage une responsabilité que nulle machine n’assume.

L’IA accélère la détection. Elle ne remplace pas le diagnostic. Confondre les deux, c’est confondre le bruit et le sens.

3. Quand l’outil devient le risque

Le fantasme du « SOC sans humain » est séduisant sur une slide. Sur le terrain, il fabrique de nouveaux risques.

Une action automatisée déclenchée sur un faux positif peut provoquer une mini-crise interne : bloquer le compte d’un dirigeant en pleine négociation, isoler à tort un système industriel critique. Un grand industriel énergétique a tenté d’automatiser l’isolement de ses systèmes OT : résultat, des blocages intempestifs de systèmes vitaux, et un retour en arrière vers la supervision humaine obligatoire.

Le second risque est plus insidieux : la boîte noire. Quand une IA déclenche une action sans trace explicable, qui peut justifier la décision en revue post-incident ? Sans traçabilité, l’efficacité d’aujourd’hui devient l’angle mort de demain.

C’est le prolongement direct du fil rouge du T2 : automatiser sans gouverner, c’est créer une dépendance invisible. On gagne en vitesse ce qu’on perd en maîtrise. Et la résilience n’a jamais été une affaire de vitesse seule.

Automatiser une mauvaise procédure ne la corrige pas. Cela accélère l’erreur.

4. La grille de répartition humain-machine

Le débat « faut-il automatiser ? » est mal posé. La vraie question est : où placer la validation humaine ? Voici une grille de maturité pour situer son SOC, dimension par dimension.

Aucune organisation n’est « Native » partout, et ce n’est pas l’objectif. Une cible « Native » sur la supervision de l’IA mais « Réactive » sur la gouvernance des playbooks est un déséquilibre dangereux : on automatise vite ce qu’on ne maîtrise pas encore. La maturité, ici, c’est la cohérence entre les lignes, pas la course à la dernière colonne.

La bonne question n’est pas « qu’automatiser ? » mais « où la validation humaine reste-t-elle non négociable ? ».

5. « Human in the loop » : calibrer l’autonomie sur la réversibilité

Garder l’humain dans la boucle n’est pas un slogan. C’est un choix d’architecture qui se décline en trois niveaux d’autonomie, à attribuer action par action :

• Humain dans la boucle (in the loop) : l’IA propose, l’humain valide avant toute exécution. Réservé aux actions critiques ou irréversibles — couper un réseau de production, isoler un système industriel, bloquer un compte sensible.

• Humain sur la boucle (on the loop) : l’IA agit, l’humain supervise et peut interrompre. Pour les actions standardisées à impact modéré, déjà éprouvées.

• Humain hors de la boucle (out of the loop) : l’IA agit seule. À réserver aux actions triviales et parfaitement réversibles : fermeture de faux positifs connus, enrichissement d’alerte.

Le principe est simple à énoncer, exigeant à tenir : le niveau d’autonomie doit être proportionnel à la réversibilité de l’action. Plus une action est difficile à défaire, plus la main humaine doit rester sur le déclencheur.

C’est exactement la logique que porte le cadre AI RMF du NIST : gouverner, cartographier, mesurer, maîtriser. Une IA défensive est un système à risque comme un autre. Elle se gouverne — on ne la « fait pas confiance », on l’encadre, on la mesure, on l’audite.

Le degré d’autonomie accordé à la machine doit se mesurer à l’aune d’une seule question : et si elle se trompe, peut-on revenir en arrière ?

6. Du projet technologique au projet organisationnel

On présente souvent le SOC augmenté comme un achat d’outils. C’est une erreur de cadrage. C’est d’abord une transformation des métiers.

Quand la machine filtre 95 % du bruit, l’analyste ne disparaît pas : son rôle se déplace. Il passe d’exécutant — qui trie à la main — à superviseur et concepteur. Il conçoit les playbooks, calibre les seuils, arbitre les cas ambigus, audite les décisions de l’IA. C’est un travail plus rare, plus exigeant, et plus stratégique.

Cette montée en exigence a des prérequis. Les recommandations conjointes de la CISA sur le SIEM et le SOAR le rappellent crûment : on déploie un SIEM correctement réglé avant d’automatiser la réponse. Automatiser sur des fondations bancales, c’est industrialiser le désordre.

En France, la doctrine de l’ANSSI sur la supervision de sécurité — et le cadre de qualification PDIS qui en découle — fixe le même cap : la qualité d’un SOC se juge sur l’organisation, la gouvernance et la compétence des équipes, pas sur la seule sophistication des outils.

La technologie se déploie en quelques mois. La maturité organisationnelle, elle, se construit en années. C’est là que se gagne ou se perd la résilience.

L’Essentiel pour Agir

1. Cartographier avant d’automatiser — Listez vos cas d’usage, classez-les par fréquence et par réversibilité. On n’automatise pas ce qu’on n’a pas d’abord compris et documenté.

2. Calibrer l’autonomie sur la réversibilité — Pour chaque action automatisable, posez la question du retour arrière. Action irréversible ou critique : validation humaine obligatoire. Action triviale et réversible : autonomie possible.

3. Requalifier l’analyste, pas le remplacer — Investissez dans la compétence : conception de playbooks, supervision de l’IA, lecture du contexte métier. L’analyste de demain n’exécute pas — il gouverne la machine.

Conclusion

L’automatisation de la défense est inévitable. Ce n’est pas une menace pour l’humain : c’est la condition pour qu’il reste pertinent face à des attaques qui vont plus vite que lui. Mais la résilience ne naît pas de la machine seule. Elle naît d’une alliance lucide : l’IA produit, l’humain gouverne ; l’IA détecte, l’humain décide.

Le SOC augmenté n’est pas un projet d’outillage. C’est un choix d’organisation, de compétences et de gouvernance. On y gagne en vitesse à condition de ne jamais y perdre le discernement.

Reste une dernière inquiétude, que ce trimestre devra regarder en face. Nous venons de mettre l’IA au service de la défense. Mais cette même intelligence, entre d’autres mains, apprend aussi à attaquer — plus vite, à plus grande échelle, avec moins de signaux. Que devient l’équilibre humain-machine le jour où la machine d’en face accélère, elle aussi ?

La meilleure défense automatisée n’est pas celle qui retire l’humain de la boucle. C’est celle qui lui rend le temps de penser.

Bibliographie

ENISA — Threat Landscape 2025

https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025

Panorama annuel des menaces dans l’UE. Documente la place désormais centrale de l’IA dans la chaîne d’attaque (reconnaissance, phishing, automatisation) — la justification chiffrée de l’écart de vitesse qui rend l’automatisation défensive incontournable.

ANSSI — Appel à commentaires sur la doctrine de supervision de sécurité (2026)

https://cyber.gouv.fr/actualites/lanssi-lance-un-appel-a-commentaires-supervision-de-securite/

Travaux de l’ANSSI servant de base au futur référentiel PDIS, intégrant cloud, délégation de service et diversité technologique. Ancre le propos dans le cadre français de qualification des SOC, où la gouvernance prime sur l’outil.

NIST — AI Risk Management Framework (AI RMF 1.0)

https://www.nist.gov/itl/ai-risk-management-framework

Cadre de référence pour gouverner les systèmes d’IA (Gouverner, Cartographier, Mesurer, Maîtriser). Directement applicable à l’IA défensive : on ne « fait pas confiance » à un algorithme, on l’encadre, on le mesure et on l’audite.

CISA — Guidance for SIEM and SOAR Implementation (2025)

https://www.cisa.gov/resources-tools/resources/guidance-siem-and-soar-implementation

Recommandations conjointes CISA/ACSC sur le déploiement du SIEM et du SOAR. Rappelle une règle structurante : régler correctement la détection avant d’automatiser la réponse, sous peine d’industrialiser le désordre.

ENISA — How to set up CSIRT and SOC

https://www.enisa.europa.eu/sites/default/files/publications/ENISA%20Report%20-%20How%20to%20setup%20CSIRT%20and%20SOC.pdf

Guide opérationnel pour bâtir ou moderniser un CSIRT/SOC : prérequis, services, intégrations. Le socle organisationnel indispensable avant toute démarche d’automatisation et d’augmentation par l’IA.

Introduction

Pendant trois mois, Plan R a posé la même question, déguisée à chaque fois.

Le cloud et sa dépendance durable (épisode 002). L’open source face au propriétaire (003). Puis les données, les infrastructures critiques, la souveraineté, l’identité devenue périmètre, et la géopolitique entrée par effraction dans nos architectures.

Sept variations. Une seule obsession : de quoi dépendons-nous, et l’avons-nous choisi en conscience ?

Le trimestre s’achève. L’heure n’est pas au bilan administratif, ni aux indicateurs verts qui rassurent sans rien dire.

Elle est à la consolidation : rassembler ce qui a été posé, en faire une carte lisible, et transformer cette carte en outil de décision.

Car une dépendance qu’on ne voit pas ne se gouverne pas. Elle se subit, le jour où elle cède.

La vraie question de cette synthèse n’est donc pas « avons-nous progressé ? ». C’est : sommes-nous capables de dessiner, aujourd’hui, la carte de ce qui nous tient debout ?

1. Trois mois, une seule obsession : voir ce dont on dépend

Le fil rouge du trimestre n’a jamais été technique. Il a été le même à chaque épisode : la lucidité sur la dépendance.

Le cloud nous a appris qu’un choix d’hébergement engage l’organisation bien au-delà du SI. L’open source et le propriétaire, que chaque licence est un pari de long terme. Les données, qu’on protège mal ce qu’on n’a pas classé.

Les infrastructures critiques ont rappelé que le numérique touche désormais le monde physique. L’identité, qu’elle est devenue la vraie frontière. Et la géopolitique, qu’un câble coupé ou une loi extraterritoriale peut redessiner nos options du jour au lendemain.

Chacun de ces sujets a été tiré vers le même point : un arbitrage. Pas une fiche technique, un choix assumé.

On se souvient du dilemme entre disponibilité et confidentialité en pleine crise, ou de l’identité érigée en nouveau périmètre quand les murs réseau ont cessé d’exister. À chaque fois, la même bascule : un détail technique devenait une décision de direction.

Le trimestre n’a pas additionné des sujets. Il a décliné une seule discipline : regarder ses dépendances en face.

2. La dépendance n’est pas un défaut. C’est un état.

Une idée traverse tout le trimestre, et il faut la dire sans détour : aucune organisation moderne n’est autonome.

Dépendre d’un hyperscaler, d’un éditeur unique, de quelques experts rares ou d’une chaîne logistique étrangère n’est pas un échec. C’est la conséquence logique d’un monde interconnecté.

Le problème n’est jamais la dépendance elle-même. C’est la dépendance ignorée, héritée, jamais débattue.

L’histoire récente le rappelle sans ménagement : SolarWinds, Kaseya, l’incendie d’un datacenter. Aucune de ces crises n’a frappé directement les victimes. Toutes sont passées par un maillon que personne n’avait cartographié comme critique.

L’ANSSI le formule à sa manière dans son Panorama de la cybermenace 2025 : un « brouillard technologique et organisationnel » s’est installé, et ce flou profite directement aux attaquants. On ne défend pas ce qu’on ne voit pas.

La résilience ne consiste pas à supprimer la dépendance. Elle consiste à en avoir conscience, et à la maîtriser.

3. La souveraineté n’est pas un statut. C’est une capacité.

Le trimestre a mis un mot sous tension : souveraineté. Trop souvent réduite à la localisation des données, comme si un drapeau sur un datacenter suffisait.

Ce n’est pas ça. La souveraineté, c’est la capacité à décider, arbitrer et prioriser en situation dégradée - quand le contexte juridique, géopolitique ou contractuel se retourne.

Une région européenne n’efface pas l’extraterritorialité. Un label de confiance ne garantit pas la réversibilité réelle. Et reconnaître sa dépendance à des infrastructures étrangères, comme l’Europe le fait désormais ouvertement, est le premier acte souverain, pas une capitulation.

La souveraineté n’est donc pas une case à cocher. C’est une marge de manœuvre, qui se mesure le jour où tout se complique.

Ce n’est pas un statut qu’on affiche. C’est une capacité de décision qu’on conserve, ou qu’on a déjà cédée sans le mesurer.

4. La grille : cartographier ce qui compte

Assez de concepts. Voici l’outil promis : une grille pour qualifier chacune de vos dépendances critiques.

Elle ne demande pas de tout cartographier. Elle demande de qualifier ce qui, en tombant, vous met à l’arrêt. Cinq axes, cinq questions, trois signaux.

Cette grille n’invente rien : elle condense des cadres éprouvés. La fonction « Identify » du NIST CSF 2.0 (catégorie ID.AM) impose déjà l’inventaire des actifs, des fournisseurs et des flux. Le règlement DORA en fait une obligation chiffrée avec son registre d’informations des prestataires TIC. Et l’ISO 22301 relie tout cela à l’analyse d’impact sur l’activité.

Un actif qui cumule trois signaux rouges n’est pas une dépendance. C’est un point de défaillance unique qui s’ignore.

5. Les verrous qu’on découvre trop tard

Cartographier, c’est aussi nommer les verrous. Ceux qu’on signe sans les voir, et qu’on découvre sous contrainte.

• La réversibilité fantôme : écrite dans le contrat, jamais testée dans la réalité.

• Le lock-in silencieux : chaque service managé, chaque intégration spécifique resserre l’ancrage.

• L’extraterritorialité : une loi étrangère qui prime, quelle que soit la localisation des serveurs.

• La dépendance aux compétences rares : une poignée d’experts sans qui rien ne redémarre.

Ces verrous ne font pas la une des slides. Ils ne se voient pas tant que tout fonctionne. Et c’est précisément ce qui les rend dangereux.

Un verrou non identifié n’est pas neutre. C’est une décision déjà prise, mais par quelqu’un d’autre que vous.

6. De la carte à la décision : où en est votre gouvernance ?

Une carte ne sert à rien si personne ne décide à partir d’elle. La cartographie n’est pas un livrable de DSI : c’est une matière à arbitrage pour le COMEX.

Voici, pour clore le trimestre, une grille de maturité simple. Pas pour se noter. Pour se situer honnêtement.

Le but n’est pas d’être « Natif » partout. C’est de savoir où l’on est, et de l’avoir choisi.

7. Et maintenant ? La carte est dessinée, l’attaque accélère

Supposons la carte faite. Les dépendances qualifiées, les verrous nommés, les arbitrages posés au bon niveau. Le trimestre a répondu à « que protège-t-on, et pourquoi ? ».

Reste une question que la cartographie ne résout pas : à quelle vitesse devrons-nous défendre cette carte ?

L’ENISA, dans son Threat Landscape 2025, décrit une bascule. Plus de quatre campagnes d’ingénierie sociale sur cinq s’appuient désormais sur l’IA. Les vulnérabilités sont exploitées en quelques jours, parfois quelques heures, après leur divulgation. L’attaque est passée à l’échelle de la machine.

Or une cartographie, aussi belle soit-elle, reste statique. Une défense pilotée uniquement par des humains, à la main, ne suivra plus le rythme. L’écart se creuse entre la vitesse du code et la capacité de réaction humaine.

Savoir ce qu’on protège ne suffit plus. Encore faut-il pouvoir le défendre au rythme imposé par l’adversaire.

L’Essentiel pour Agir

1. Transformez votre inventaire en cartographie. — Reprenez vos dépendances critiques et passez-les dans la grille des cinq axes. L’objectif n’est pas l’exhaustivité, mais de faire apparaître les signaux rouges qui dormaient dans un tableur.

2. Nommez vos verrous au bon niveau. — Réversibilité, lock-in, extraterritorialité, compétences rares : portez-les explicitement à l’arbitrage. Une dépendance débattue est une dépendance assumée ; une dépendance tue est une dette.

3. Posez la question de la vitesse. — Pour chaque dépendance critique, demandez-vous : si elle était attaquée maintenant, notre temps de réaction serait-il compatible avec la vitesse de l’attaque ? C’est le chantier du trimestre qui s’ouvre.

Conclusion

Un trimestre pour une seule leçon : on ne gouverne que ce que l’on voit.

La résilience ne commence pas avec un outil ou une norme. Elle commence avec une carte - honnête, vivante, partagée - de ce dont on dépend vraiment, et de ce qu’on a accepté de céder.

Mais une carte n’est qu’un point de départ. Car pendant qu’on la dessine, l’adversaire, lui, a déjà automatisé son offensive.

La prochaine étape n’est plus de savoir quoi protéger. C’est d’apprendre à répondre à la vitesse du code - sans jamais perdre l’humain qui décide.

Bibliographie

ANSSI - Panorama de la cybermenace 2025

https://cyber.gouv.fr/actualites/panorama-de-la-cybermenace-2025/

Le bilan annuel de référence de l’agence française : il documente le « brouillard technologique et organisationnel » qui profite aux attaquants et confirme pourquoi la cartographie des flux et des prestataires est une priorité opérationnelle.

NIST - Cybersecurity Framework (CSF) 2.0

https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf

Le cadre de référence international : sa fonction « Identify » (catégorie ID.AM) pose l’inventaire des actifs, services, fournisseurs et flux comme socle de toute démarche de résilience - l’ossature méthodologique de la grille proposée.

Règlement (UE) 2022/2554 (DORA) - texte officiel

https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022R2554

Le règlement européen transforme la cartographie des dépendances en obligation : registre d’informations des prestataires TIC, supervision des tiers critiques et stratégies de sortie. Une illustration réglementaire directe du propos de la chronique.

ISO 22301:2019 - Systèmes de management de la continuité d’activité

https://www.iso.org/standard/75106.html

La norme internationale de continuité d’activité : elle relie l’identification des dépendances à l’analyse d’impact sur l’activité (BIA), c’est-à-dire à la hiérarchisation de « ce qui compte ».

ENISA - Threat Landscape 2025

https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025

Le panorama européen des menaces : il documente l’industrialisation des attaques par l’IA et l’exploitation des vulnérabilités en quelques jours. La source qui ouvre le trimestre suivant sur la question de la vitesse de défense.

Introduction - La géopolitique a quitté les chancelleries

En mai 2025, un homme s’est connecté à sa messagerie professionnelle. Elle ne répondait plus.

Pas de panne. Pas de piratage. Une signature, à Washington. Le procureur de la Cour pénale internationale venait de perdre l’accès à sa boîte mail Microsoft, après des sanctions américaines visant sa personne.

On a longtemps rangé la géopolitique loin des salles serveurs. Cette frontière a cédé. Les sanctions touchent des comptes. Les tensions maritimes coupent des câbles. Les régions cloud peuvent devenir inaccessibles.

La compilation 2025 de Plan R évoquait les menaces hybrides et le splinternet. Nous ne les avions jamais regardés frontalement. L’épisode 002 parlait de dépendance au cloud, l’épisode 004 de gouvernance, et nous avons questionné la souveraineté. Il manquait une pièce : la dimension géopolitique.

La thèse de cette chronique est simple. Le risque géopolitique n’est plus une externalité diplomatique. Il est devenu un paramètre de conception de vos systèmes.

La vraie question n’est plus : « mon fournisseur va-t-il tomber en panne ? ». C’est : « que se passe-t-il si quelqu’un, ailleurs, décide de me couper ? »

1. Le jour où un e-mail disparaît sur ordre politique

Reprenons le cas de la CPI. En février 2025, des sanctions américaines visent son procureur. Dans les semaines qui suivent, son compte Microsoft devient inaccessible. Il bascule sur une messagerie suisse. À l’automne, l’institution abandonne les outils Microsoft pour une alternative open source souveraine.

Microsoft a contesté avoir « suspendu » ses services. Peu importe le détail des responsabilités. Le précédent, lui, est posé.

Ce n’est pas un incident technique. C’est une décision politique, appliquée par un fournisseur privé, sur un service que l’on croyait neutre.

Le CLOUD Act américain oblige les entreprises américaines à fournir les données placées sous leur contrôle, même hébergées ailleurs. La localisation des données ne suffit donc pas à garantir la maîtrise.

La disponibilité de votre SI ne dépend pas que de votre architecture. Elle dépend aussi de juridictions sur lesquelles vous n’avez aucune prise.

2. Les câbles sous-marins : l’angle mort le plus stratégique

On imagine le cloud dans les airs. Il dort surtout au fond des océans.

Près de 99 % du trafic internet intercontinental transite par des câbles sous-marins. L’OTAN rappelle qu’ils sécurisent l’équivalent de 10 000 milliards de dollars de transactions financières chaque jour.

Or, depuis fin 2024, la mer Baltique enchaîne les incidents. En décembre, le navire Eagle S est soupçonné d’avoir sectionné quatre câbles de données ainsi qu’un câble électrique reliant la Finlande à l’Estonie. D’autres cas ont suivi, impliquant des navires civils traînant leur ancre sur les fonds marins.

C’est exactement cela, une menace hybride : une agression difficile à attribuer, déguisée en accident, exécutée par une flotte fantôme. La déniabilité fait partie de l’arme.

Votre cloud « multi-régions » repose physiquement sur quelques câbles que personne, dans votre COMEX, n’a jamais cartographiés.

3. Quand les États déploient des frégates

Les États, eux, ont compris l’enjeu. En janvier 2025, l’OTAN lance Baltic Sentry : frégates, avions de patrouille, drones et surveillance accrue de la Baltique pour protéger les infrastructures sous-marines.

En février 2025, la Commission européenne adopte un Plan d’action sur la sécurité des câbles, couvrant prévention, détection, réponse, réparation et dissuasion. Une évaluation des risques a suivi à l’automne, accompagnée d’une liste de projets prioritaires et de financements dédiés.

Le message est clair : la connectivité est désormais traitée comme une infrastructure critique de défense, au même titre que l’énergie.

Mais cette protection est collective, lente et hors de votre contrôle direct. Votre continuité, elle, ne peut pas attendre l’arrivée d’un navire de guerre.

Quand l’OTAN mobilise des frégates pour protéger votre connectivité, ce n’est plus un risque théorique. C’est une ligne de votre plan de continuité.

4. Sanctions et « kill switch » : le verrouillage devient politique

L’affaire de la CPI a ravivé une crainte européenne : celle d’un « kill switch ». L’idée qu’un compte, une région ou un service puisse être coupé, non par une attaque, mais par simple conformité à une décision étrangère.

Les régimes de sanctions évoluent vite. Les obligations de vos fournisseurs ne sont pas les vôtres, et elles peuvent changer du jour au lendemain, sans que vous ayez voix au chapitre.

Cela oblige à relire l’épisode 002 autrement. Le verrouillage fournisseur n’est pas seulement un coût de sortie élevé. C’est une exposition à une décision politique étrangère sur laquelle vous ne votez pas.

Le lock-in n’est pas qu’un problème commercial. C’est une dépendance à la stabilité diplomatique d’un pays tiers.

5. Le splinternet : la fin de l’internet « par défaut »

Pendant trente ans, nous avons conçu nos systèmes sur une hypothèse implicite : un internet mondial, ouvert et stable.

Cette hypothèse se fissure. Clouds nationaux, localisation forcée des données, réglementations divergentes entre l’Europe, les États-Unis et l’Asie : le cyberespace se fragmente. C’est le splinternet.

L’ENISA le confirme dans son panorama des menaces 2025 : la géopolitique est un moteur majeur des opérations malveillantes, avec une convergence croissante entre hacktivistes, criminels et acteurs étatiques.

Le réseau « sans frontières » sur lequel reposent vos architectures se reterritorialise. Silencieusement, mais sûrement.

L’internet ouvert et stable que vos systèmes tiennent pour acquis n’est plus une garantie. C’est une hypothèse à réévaluer.

6. Cartographier son exposition géopolitique

On ne pilote pas ce qu’on n’a pas mesuré. Voici une grille pour situer votre maturité face au risque géopolitique, du réflexe subi à l’intégration native.

La première vulnérabilité géopolitique, ce n’est pas un câble. C’est l’ignorance de sa propre exposition.

7. Du risque subi au risque arbitré

Soyons clairs : il ne s’agit pas de « sortir du cloud » ni de viser l’autarcie numérique. Ce serait coûteux, lent et souvent illusoire.

Il s’agit de faire ses choix en conscience - exactement comme nous le disions de la dépendance au cloud. Tout ne mérite pas d’être souverain.

La clé est d’identifier le petit noyau de fonctions vitales qui doivent survivre à une coupure géopolitique, et de leur prévoir un vrai plan B. Diversification réelle, réversibilité testée, clauses contractuelles sur les sanctions, scénarios de crise non techniques : autant de leviers concrets et activables.

La souveraineté totale est une illusion coûteuse. La conscience de son exposition est une nécessité stratégique.

L’Essentiel pour Agir

1. Cartographier vos dépendances géopolitiques :

Identifiez la juridiction de vos fournisseurs critiques et les routes physiques (câbles, régions) qui soutiennent vos services essentiels. Sans cette carte, tout arbitrage reste aveugle.

2. Tester un scénario de coupure non technique :

Simulez la perte d’une région ou d’un compte par sanction, ou d’un câble par sabotage - pas un piratage. Vous découvrirez vos angles morts avant qu’ils ne vous découvrent.

3. Définir votre périmètre souverain minimal :

Listez les quelques fonctions qui doivent absolument survivre à un choc géopolitique, et provisionnez un plan B réel pour celles-là seulement. La souveraineté se concentre, elle ne se saupoudre pas.

Conclusion

La géopolitique a quitté les chancelleries pour entrer dans vos datacenters. Sanctions, câbles, fragmentation : ce ne sont plus des sujets pour diplomates, mais des paramètres d’architecture.

La bonne nouvelle, c’est qu’aucune de ces menaces n’impose la fatalité. Elle impose la lucidité.

Reste une dernière inconnue. Quand le câble est coupé, quand la région tombe, quand la décision vient d’ailleurs - qui, dans votre organisation, tranche ? Avec quel sang-froid, à quelle vitesse, sur quelles informations ?

Car la technologie peut être souveraine. Encore faut-il que la décision le soit aussi.

Bibliographie

ENISA - Threat Landscape 2025

https://www.enisa.europa.eu/topics/cyber-threats/threat-landscape

Panorama annuel des menaces cyber de l’Union européenne. Confirme que la géopolitique est un moteur majeur des opérations malveillantes et la convergence entre hacktivistes, criminels et acteurs étatiques.

Commission européenne - EU Action Plan on Cable Security / Submarine Cable Security Toolbox

https://digital-strategy.ec.europa.eu/en/library/submarine-cable-security-toolbox-and-cable-projects-european-interest

Texte de référence sur la sécurité des câbles sous-marins européens (prévention, détection, réponse, dissuasion) et le rappel que 99 % du trafic intercontinental passe par ces câbles.

NATO - Baltic Sentry steps up patrols to safeguard Critical Undersea Infrastructure

https://mc.nato.int/media-centre/news/2025/nato-baltic-sentry-steps-up-patrols-in-the-baltic-sea-to-safeguard-critical-undersea-infrastructure.aspx

Communiqué officiel de l’OTAN décrivant le dispositif Baltic Sentry, illustrant la militarisation de la protection des infrastructures sous-marines critiques.

Carnegie Endowment - The Baltic Sea at a Boil: Shadow Fleet and Subsea Infrastructure Sabotage

https://carnegieendowment.org/research/2025/06/baltic-russia-maritime-cable-sabotage?lang=en

Analyse de référence sur les sabotages de câbles en Baltique (Eagle S, flotte fantôme) et la logique de menace hybride à déniabilité plausible.

Parlement européen - Question parlementaire P-002270/2025 (sanctions américaines et CPI)

https://www.europarl.europa.eu/doceo/document/P-10-2025-002270_EN.html

Source institutionnelle documentant la perte d’accès à la messagerie Microsoft du procureur de la CPI à la suite de sanctions, cas emblématique de la dépendance numérique à une juridiction étrangère.

Dans l’épisode 007, nous avons acté une rupture : en 2026, voir et entendre ne suffisent plus à prouver une identité. Le deepfake en temps réel a fait voler en éclats la preuve sensorielle. Notre réponse fut le « Zéro Trust Relationnel » : ne plus croire, toujours vérifier.

Mais ce principe ne s’arrête pas aux interactions humaines. Il structure désormais toute l’architecture de sécurité. Et il converge vers un point unique : l’identité.

Le château fort est tombé. Plus de douves, plus de pont-levis. À la place, une question posée à chaque accès : « Qui es-tu, et as-tu le droit ? »

Celui qui répond à cette question, c’est votre système de gestion des identités — l’IAM. Il est devenu le véritable plan de contrôle de la sécurité moderne.

Et c’est précisément là que naît le risque. En concentrant la confiance dans un seul système, nous avons fabriqué une nouvelle dépendance critique.

La vraie question n’est donc pas : « comment mieux authentifier ? » C’est : « que se passe-t-il le jour où c’est votre IAM, lui-même, qui tombe ? »

1. Le périmètre est mort, l’identité prend sa place

Pendant trente ans, la sécurité s’est pensée comme une frontière. Un dedans réputé sûr, un dehors hostile, un mur entre les deux. Ce modèle est mort avec le cloud, le télétravail et la sous-traitance numérique : l’attaquant est déjà dedans, via un compte légitime.

Le Zero Trust a tiré la conséquence de cette disparition. Si la localisation réseau ne prouve plus rien, alors c’est l’identité — de l’utilisateur, du service, de la machine — qui devient le critère de décision à chaque requête.

Concrètement, l’identité est promue au rang de plan de contrôle. Chaque accès passe par elle. Elle remplace le pare-feu comme premier point de décision. Le périmètre n’a pas disparu : il s’est déplacé, et il tient désormais dans un identifiant.

Le nouveau périmètre n’est plus une ligne sur une carte réseau. C’est une réponse à la question « qui es-tu ? ».

2. Le paradoxe de l’IAM : la béquille devient la colonne vertébrale

Centraliser les identités est une excellente idée de sécurité. Un seul annuaire, un SSO, des politiques homogènes : on supprime les comptes orphelins, on applique la MFA partout, on tranche net dans le désordre.

Mais cette centralisation a un revers que nous connaissons bien dans Plan R. En 006, nous parlions des « Single Points of Failure » — ces systèmes qui, s’ils tombent, entraînent tout le reste. L’IAM est devenu le SPOF par excellence.

Car en faisant converger toute la confiance vers un point unique, on y concentre aussi tout le risque. La béquille pratique est devenue la colonne vertébrale : on ne peut plus s’en passer, et on ne peut plus se permettre qu’elle casse.

C’est une dépendance, au sens où nous l’entendions en 004 : un choix structurant, souvent présenté comme technique, mais qui engage la trajectoire entière de l’organisation. Et comme toute dépendance, elle se gouverne — ou elle se subit.

L’IAM n’est pas qu’un outil de sécurité. C’est une dépendance critique. La résilience commence par en avoir conscience.

3. Anatomie d’une dépendance : de quoi est fait « votre IAM » ?

Avant de protéger une chose, il faut savoir de quoi elle est faite. « L’IAM » n’est pas un produit unique, mais un empilement de briques, chacune étant un point de rupture potentiel :

• L’annuaire (Active Directory, Entra ID…) : le référentiel central des comptes et des droits.

• Le fournisseur d’identité / SSO : le service qui émet les jetons d’accès aux applications.

• La MFA : le second facteur qui renforce — ou fragilise — l’authentification.

• Le PAM : la gestion des comptes à privilèges, les « clés du royaume ».

• La fédération : les liens de confiance avec des partenaires, fournisseurs et services cloud.

Chaque brique étend la surface. Et chacune peut défaillir de deux manières radicalement différentes — c’est tout l’objet de la section suivante.

On ne reconstruit pas en urgence ce qu’on n’a jamais cartographié. La carte de l’identité précède sa défense.

4. Les deux visages de la défaillance

Premier visage : la compromission. L’attaquant ne force plus un mur, il vole une identité. Hameçonnage du second facteur, vol de jetons de session, prise de contrôle d’un compte à privilèges, fabrication d’assertions d’authentification : une fois maître de l’IAM, il n’est pas « entré » quelque part — il est partout, légitimement.

C’est l’effet domino vu de l’intérieur : un seul compte Tier 0 compromis sur l’annuaire peut suffire à basculer l’ensemble du système d’information. Le mouvement latéral ne rencontre plus d’obstacle, puisque l’attaquant détient la clé maîtresse.

Second visage, trop souvent oublié : l’indisponibilité. Aucun attaquant, aucune faille — juste votre fournisseur d’identité qui tombe. Et soudain, plus personne ne peut s’authentifier. Les applications fonctionnent, les données sont intactes, mais la porte est bloquée. L’activité s’arrête net.

Nous avons déjà vu cette logique dans la série : la panne d’un acteur central paralyse tout l’écosystème qui en dépend. L’IAM ajoute une cruauté supplémentaire : c’est la panne qui vous empêche d’entrer chez vous.

Un IAM compromis ouvre toutes les portes à l’attaquant. Un IAM indisponible les ferme toutes, pour vous. Les deux sont des scénarios de crise.

5. Renforcer le socle : la MFA résistante au phishing

La première ligne de défense reste l’authentification. Mais toutes les MFA ne se valent pas. L’ANSSI le rappelle clairement : le SMS s’appuie sur des protocoles vulnérables (SIM swapping) et ne doit pas servir de second facteur.

La CISA va plus loin et fixe le standard : la MFA résistante au phishing — typiquement FIDO2/WebAuthn et les clés matérielles — est la seule réellement robuste face aux attaques modernes (hameçonnage du code, fatigue MFA, vol de jeton). Le NIST en fait son niveau d’assurance le plus élevé (AAL3).

Traduction opérationnelle : sur les comptes à privilèges et les accès critiques, le mot de passe seul ou la notification push ne suffisent plus. C’est l’inhameçonnable ou rien. La grille ci-dessous situe les paliers de maturité.

Grille de maturité IAM — du réactif au natif :

Une MFA contournable donne l’illusion de la sécurité. Sans authentification résistante au phishing sur le cœur, tout le reste est cosmétique.

6. Cloisonner l’identité : tiering et moindre privilège

Renforcer la porte ne suffit pas si, une fois entré, on peut tout faire. C’est ici que l’on applique à l’identité la leçon de segmentation vue en 006 : cloisonner pour contenir.

Le tiering de l’Active Directory en est l’illustration. L’ANSSI constate un manque de maturité récurrent sur la sécurité des annuaires, et recommande un modèle en niveaux : les comptes les plus puissants (Tier 0) ne doivent jamais s’exposer sur des environnements moins sûrs. Objectif : qu’un poste de travail compromis ne débouche pas sur un contrôle total du domaine.

À cela s’ajoute le moindre privilège, décliné dans le temps : non plus des droits permanents, mais des accès juste-à-temps, accordés pour une tâche, puis révoqués. Un privilège qui n’existe que quand il sert ne peut pas être volé quand il dort.

Cloisonner l’identité, c’est accepter que la compromission arrivera — et faire en sorte qu’elle reste locale plutôt que systémique.

Un IAM résilient n’empêche pas toute intrusion. Il garantit qu’une intrusion ne devienne pas une prise de contrôle totale.

7. La résilience de l’IAM lui-même : avez-vous un plan B ?

Voici la question que presque personne ne se pose : si votre fournisseur d’identité devient indisponible demain matin, comment vos équipes se connectent-elles ? Dans la majorité des organisations, la réponse honnête est : elles ne se connectent pas.

Or un SPOF se traite comme un SPOF. Cela suppose trois réflexes de continuité. D’abord, des comptes de secours « break-glass » : des accès d’urgence, sous scellés, hors du flux normal, testés régulièrement — et surveillés de près.

Ensuite, la redondance : ne pas dépendre d’un seul point d’authentification pour les fonctions vitales, prévoir des chemins de secours documentés. Enfin, une procédure de reprise de l’identité, intégrée au plan de continuité au même titre que les données ou les applications.

L’IAM n’est pas qu’un sujet de RSSI. C’est un sujet de continuité d’activité — donc de COMEX. Le jour de la panne, l’improvisation se compte en heures d’arrêt, parfois en jours.

La résilience de l’identité ne se mesure pas quand tout va bien. Elle se mesure le jour où l’IAM tombe — et où il faut quand même entrer.

L’Essentiel pour Agir

1. Cartographiez votre dépendance identitaire — Annuaire, fournisseur d’identité, fédérations, comptes de service : listez tout ce qui décide d’un accès. On ne protège — ni ne reconstruit — que ce que l’on a cartographié.

2. Rendez vos comptes critiques inhameçonnables — Sur les accès à privilèges et les comptes d’administration, exigez une MFA résistante au phishing (FIDO2, clés matérielles). Le SMS et la simple notification push ne tiennent plus.

3. Préparez la panne de votre IAM — Comptes « break-glass » sous scellés, redondance du fournisseur d’identité, procédure de reprise testée. Traitez l’identité comme une ligne à part entière de votre plan de continuité.

Conclusion

L’identité n’est pas un sujet technique de plus. C’est le point où convergent l’humain et la machine, la sécurité et la continuité. En faire la pierre angulaire de l’architecture est une bonne décision. L’oublier dans les plans de résilience en est une mauvaise.

La résilience ne consiste pas à supprimer cette dépendance — elle est inévitable. Elle consiste à en avoir conscience, à la cloisonner, et à prévoir le jour où elle nous lâchera.

Nous savons désormais protéger la clé. Reste une question : que protège-t-elle, au juste ? Une clé n’a de valeur que par ce qu’elle ouvre. Et ce que nos identités déverrouillent, c’est le véritable trésor — celui que nous explorerons la prochaine fois.

Bibliographie

NIST — SP 800-63-4, Digital Identity Guidelines (version finale, 2025)

https://pages.nist.gov/800-63-4/sp800-63.html

Référence mondiale sur les niveaux d’assurance d’identité et d’authentification (IAL/AAL/FAL). Fonde la notion de MFA de haut niveau (AAL3) et la logique d’authentification résistante au phishing.

NIST — SP 800-207, Zero Trust Architecture (2020)

https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf

Le cadre conceptuel du Zero Trust qui place l’identité et la vérification continue au centre de l’architecture. Socle théorique du basculement « périmètre réseau → identité ».

ANSSI — Recommandations relatives à l’authentification multifacteur et aux mots de passe

https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe

Guide de référence (avec la CNIL) sur la MFA et les mots de passe. Détaille notamment pourquoi le SMS ne doit pas servir de second facteur. Base opérationnelle pour durcir l’authentification.

CISA — Implementing Phishing-Resistant MFA (fact sheet)

https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf

Fiche pratique qui désigne FIDO2/WebAuthn et la PKI comme la forme la plus robuste de MFA, et alerte sur les limites de l’OTP et du push. Cœur de la section V.

ANSSI / CERT-FR — Points de contrôle Active Directory

https://www.cert.ssi.gouv.fr/uploads/guide-ad.html

Liste de points de contrôle pour sécuriser un annuaire AD, en lien avec le modèle de cloisonnement en tiers (Tier 0). Appui direct de la section VI sur le cloisonnement de l’identité.

Introduction

3h du matin. La cellule de crise est réunie. Le ransomware a chiffré une partie du SI. Des données ont probablement été exfiltrées avant le chiffrement. Le service client est à l’arrêt. Les équipes techniques ont restauré une partie des systèmes depuis les sauvegardes - mais on ne sait pas encore si le vecteur initial a été neutralisé.

Le directeur général pose deux questions. Dans le même souffle.

« Quand est-ce qu’on remet le service en ligne ? »

« Est-ce qu’on est sûrs que c’est propre ? »

Et c’est exactement à ce moment-là que tout se joue. Parce qu’on ne peut pas répondre oui aux deux. Pas en même temps. Pas vite.

Dans l’épisode 018, on a vécu une crise de l’intérieur. Dans l’épisode 004, on a posé que la résilience n’est pas un état, mais un arbitrage. L’épisode 020 prolonge ces deux pistes en posant la question que la plupart des référentiels évitent soigneusement : quand les priorités deviennent incompatibles, comment choisit-on ?

1. Le triangle DIC : un confort de temps de paix

La sécurité de l’information repose sur trois propriétés cardinales : Disponibilité, Intégrité, Confidentialité. On les présente comme un triangle, comme si elles vivaient en bonne intelligence.

En temps de paix, c’est vrai. On peut concevoir un SI qui assure les trois, à des niveaux ajustés au besoin métier. Les architectures, les contrôles, les contrats fournisseurs sont calibrés pour ça.

En crise, le triangle se brise.

• Remettre vite en ligne (disponibilité) → c’est accepter le risque que la compromission ne soit pas totalement assainie (confidentialité, intégrité encore vulnérables).

• Tout couper pour assainir proprement (confidentialité, intégrité) → c’est arrêter l’activité (disponibilité à zéro).

• Restaurer depuis une sauvegarde ancienne → c’est risquer la perte de données récentes (intégrité métier).

Le triangle DIC n’est pas un équilibre, c’est un système de vases communicants. Quand l’un déborde, les autres se vident.

La crise révèle que les trois propriétés ne sont pas compatibles à 100 %. Elles sont arbitrables.

2. Le dilemme central : on ne sauve pas tout

Toute crise cyber sérieuse impose un choix. La question n’est jamais « comment tout sauver ». La question est : qu’est-ce qu’on accepte de sacrifier temporairement pour sauver le reste ?

L’ANSSI le formule directement : la gestion de crise consiste à « bien gérer les seuils d’escalade », à « articuler le pilotage de la crise et la réponse à incident », et à « impliquer les métiers dans la construction du plan de remédiation ». Autrement dit : la crise n’est pas un sujet technique pur. C’est un sujet d’arbitrage entre fonctions.

Ce qui rend ce dilemme particulièrement piégeux :

• Il est asymétrique. Une mauvaise décision sur la disponibilité se voit immédiatement (clients, médias, régulateurs). Une mauvaise décision sur la confidentialité ne se voit parfois que des mois plus tard, quand les données refont surface.

• Il est temporellement contraint. En crise, on décide en heures, parfois en minutes, avec une information incomplète.

• Il est juridiquement asymétrique aussi. RGPD : 72h pour notifier. NIS2 : 24h pour l’alerte précoce. CRA : obligations spécifiques produits. Le temps de la décision n’est pas le temps du droit.

Le vrai sujet n’est pas « éviter le dilemme ». C’est l’avoir tranché avant qu’il ne survienne.

3. Quatre dilemmes concrets que toute organisation rencontre

Ces situations ne sont pas théoriques. Elles arrivent dans presque toutes les crises cyber d’ampleur.

Dilemme 1 - Restaurer ou investiguer.

La sauvegarde est saine. Mais si on restaure tout de suite, on écrase des artefacts utiles à l’investigation forensique. Si on investigue d’abord, le service reste à l’arrêt 24h de plus.

Dilemme 2 - Couper ou contenir.

Maersk a coupé l’intégralité de son infrastructure mondiale en 2017 face à NotPetya. Choix radical, lourd financièrement. Mais qui a évité une propagation pire. À l’inverse, une organisation qui cherche à contenir « chirurgicalement » sans couper risque la propagation latérale.

Dilemme 3 - Communiquer ou attendre.

Norsk Hydro, attaqué par LockerGoga en 2019, a choisi la transparence totale dès le premier jour. Conférences de presse quotidiennes, communication ouverte, refus de payer la rançon. Choix salué par les experts du secteur, parce qu’il a préservé la confiance des parties prenantes. À l’inverse, attendre d’avoir toutes les informations peut être perçu comme de la dissimulation - et cela aggrave la crise réputationnelle.

Dilemme 4 - Payer ou tenir.

La rançon, c’est la disponibilité achetée au prix de la confidentialité (les attaquants ont vos données) et de l’intégrité (rien ne garantit qu’ils livreront une clé propre). Et c’est un signal envoyé au marché des attaquants.

Aucun de ces dilemmes n’a de bonne réponse universelle. Tous ont une bonne réponse contextuelle - à condition de l’avoir préparée.

4. Ce n’est pas un choix technique. C’est un choix de gouvernance

Voici le point que la plupart des organisations manquent : l’arbitrage entre disponibilité et confidentialité n’appartient pas au RSSI seul. Ni au DSI seul. Ni au DG seul.

Il appartient à une instance qui doit avoir été constituée à froid, avec un mandat clair :

• Cellule décisionnelle (niveau Gold) : Direction Générale, arbitre les impacts majeurs.

• Cellule de pilotage (niveau Silver) : DSI, GRC, DPO, juridique, communication. Coordonne.

• Cellule opérationnelle (niveau Bronze) : équipes techniques, SOC, CSIRT. Exécute.

C’est exactement le modèle préconisé par l’ANSSI dans son guide sur la gestion de crise cyber. Et c’est aussi celui que l’ENISA recommande au niveau européen.

Pourquoi cette gouvernance multi-niveaux ? Parce que les décisions d’arbitrage ont des conséquences :

• Financières (perte de CA, pénalités contractuelles).

• Juridiques (notifications RGPD, NIS2, CRA, contentieux).

• Réputationnelles (médias, clients, marchés).

• Opérationnelles (continuité, RH, partenaires).

Aucun de ces axes n’est porté par une seule fonction. Donc aucune fonction seule ne peut arbitrer.

Sans gouvernance pré-définie, l’arbitrage de crise se fait à 3h du matin par la personne la plus stressée dans la pièce. C’est la pire configuration possible.

5. Pré-arbitrer à froid : la grille à construire avant la crise

Le bon moment pour décider qu’on coupe ou pas, ce n’est pas pendant la crise. C’est six mois avant.

Voici une grille d’arbitrage à pré-remplir, par service critique, avec le COMEX :

Cette grille n’est pas figée. Elle est un cadre de discussion. Elle force le COMEX à expliciter ses priorités avant d’être en mode panique.

• ✔️ Elle s’inscrit dans le Plan de Continuité d’Activité.

• ✔️ Elle alimente les playbooks de la cellule de crise.

• ✔️ Elle se teste en exercice (kit ANSSI, scénarios sectoriels).

Une grille d’arbitrage non testée vaut zéro. Une grille testée vaut son poids en heures de sommeil en crise.

6. Norsk Hydro et Maersk : deux choix opposés, deux réussites

Les deux cas les plus emblématiques de la décennie illustrent que l’arbitrage est contextuel, pas universel.

Maersk (NotPetya, 2017). Choix radical : couper l’intégralité du réseau mondial. Restauration manuelle de plus de 4 000 serveurs et 45 000 postes. Coût estimé à 300 M$. Mais propagation arrêtée. Disponibilité sacrifiée. Intégrité préservée.

Norsk Hydro (LockerGoga, 2019). Choix de continuité dégradée : passage en production manuelle dans les usines, refus de payer la rançon, transparence totale. 35 000 employés dans 40 pays affectés. Trois décisions clés : ne pas payer, faire appel à une équipe d’intervention externe, communiquer ouvertement. Disponibilité partielle maintenue. Confidentialité acceptée comme compromise. Réputation préservée - et même renforcée.

Aucun de ces deux choix n’est « le bon ». Les deux sont cohérents avec le contexte métier, la culture, les contraintes réglementaires et la gouvernance préparée.

C’est le sens du choix qui compte, pas le contenu du choix.

Une organisation qui ne sait pas pourquoi elle arbitre comme elle arbitre, n’arbitre pas. Elle subit.

7. Le coût caché de la non-décision

Le pire arbitrage, c’est l’absence d’arbitrage. C’est la cellule de crise qui tourne en rond pendant six heures, parce que personne n’a le mandat de trancher. C’est l’équipe technique qui restaure « par défaut » sans valider auprès du juridique. C’est le COMEX qui demande des chiffres précis quand seule une décision est attendue.

La non-décision a trois effets toxiques :

• Elle dégrade les trois dimensions à la fois. Pendant qu’on hésite, la disponibilité reste à zéro, la confidentialité continue d’être grignotée, l’intégrité devient incertaine.

• Elle disqualifie la gouvernance. Les équipes opérationnelles perdent confiance dans la chaîne de décision et commencent à improviser localement.

• Elle aggrave le post-crise. L’absence de décisions traçables rend les retours d’expérience inopérants et les notifications réglementaires fragiles.

Sans mandat d’arbitrage explicite donné à une instance identifiée, tout le reste est cosmétique.

Une cellule de crise sans pouvoir d’arbitrage n’est pas une cellule de crise. C’est un comité de constatation.

L’Essentiel pour Agir

1. Cartographier la criticité par axe DIC, pas en bloc — Pour chaque service critique, distinguer la tolérance à la perte de disponibilité, à la perte de confidentialité, à la perte d’intégrité. Trois colonnes, pas une. C’est le point d’entrée de tout arbitrage utile.

2. Pré-arbitrer avec le COMEX, par écrit — Faire valider la grille d’arbitrage par la Direction Générale avant la crise, pas pendant. Un document signé qui dit « en cas de conflit DIC sur le service X, la priorité par défaut est Y, sauf décision contraire de la cellule Gold ». Cela libère la chaîne de décision en crise.

3. Tester l’arbitrage en exercice, pas le déclenchement — La plupart des exercices testent « est-ce qu’on déclenche la cellule de crise ». Le bon test, c’est : « la cellule est déclenchée, on lui pose deux questions contradictoires en même temps, comment tranche-t-elle ? ». C’est là que se révèle la maturité réelle.

Conclusion

La résilience ne consiste pas à tout sauver. Elle consiste à savoir ce qu’on accepte de perdre, dans quel ordre, et qui décide.

Toute organisation qui prétend que la disponibilité, l’intégrité et la confidentialité sont compatibles en toutes circonstances n’a pas encore vécu de vraie crise. Ou alors elle l’a oubliée.

L’arbitrage est inconfortable. Il oblige à des choix politiques, à des renoncements explicites, à des conversations difficiles avec le COMEX. Mais c’est précisément cet inconfort qui sépare les organisations résilientes de celles qui se contentent de cocher des cases.

Et derrière cet inconfort, une autre question se profile, encore plus rarement traitée frontalement. Quand on sait ce qu’on est prêt à sacrifier, encore faut-il savoir à qui on appartient. Car en cas de crise majeure, la souveraineté de la décision ne va pas toujours de soi.

À la semaine prochaine.

Bibliographie

« Anticiper et gérer une crise cyber » - ANSSI

https://cyber.gouv.fr/anticiper-et-gerer-une-crise-cyber

Page de référence de l’ANSSI sur la gestion de crise cyber, regroupant le guide « Crise d’origine cyber, les clés d’une gestion opérationnelle et stratégique » (co-réalisé avec le Club de la Continuité d’Activité). Cadre méthodologique central pour la structuration des cellules Gold/Silver/Bronze évoquée dans l’article.

« Organiser un exercice de gestion de crise cyber » - ANSSI

https://cyber.gouv.fr/publications/organiser-un-exercice-de-gestion-de-crise-cyber

Guide opérationnel ANSSI pour la conception d’exercices de crise. Source directe pour la recommandation de tester l’arbitrage en exercice, notamment via le scénario fil rouge RANSOM20.

« Best Practices for Cyber Crisis Management » - ENISA

https://www.enisa.europa.eu/publications/best-practices-for-cyber-crisis-management

Étude ENISA sur l’élévation d’un incident cyber en crise et sur la dimension politique de cette bascule. Source pour la lecture de la crise comme décision de gouvernance, pas comme événement technique.

« Guide for Cybersecurity Event Recovery » (NIST SP 800-184) - NIST

https://csrc.nist.gov/pubs/sp/800/184/final

Référentiel américain sur la planification de la reprise après incident cyber. Source pour les arbitrages entre restauration rapide et investigation, et pour la logique de playbooks pré-construits.

« Violations de données personnelles : les règles à suivre » - CNIL

https://www.cnil.fr/fr/violations-de-donnees-personnelles-les-regles-suivre

Page CNIL de référence sur les obligations RGPD (articles 33 et 34) et le délai de notification de 72 heures. Source pour la dimension juridique asymétrique des arbitrages de crise.

« Hackers hit Norsk Hydro with ransomware. The company responded with transparency » - Microsoft Source

https://news.microsoft.com/source/features/digital-transformation/hackers-hit-norsk-hydro-ransomware-company-responded-transparency/

Reportage détaillé sur la gestion par Norsk Hydro de l’attaque LockerGoga (mars 2019). Source pour l’analyse du choix de transparence radicale comme stratégie d’arbitrage entre confidentialité acceptée comme compromise et préservation de la confiance des parties prenantes.