La BCE a lancé le compte à rebours : votre feuille de route jusqu’au 31 octobre 2026

La BCE demande aux banques placées sous sa supervision directe de présenter un plan d’action face aux cyberattaques pilotées par l’IA. L’enjeu ne se limite toutefois pas à produire une stratégie : il s’agit de démontrer une capacité opérationnelle concrète. Cet article revient sur les attentes précises du superviseur, les difficultés pratiques qu’elles soulèvent et la manière de mettre à profit les semaines restantes.

Le 7 juillet, la supervision bancaire de la BCE a adressé un courrier à environ 110 établissements dits « importants ». Sa demande est claire : remettre, d’ici au 31 octobre 2026, un plan d’action dédié aux cyberattaques pilotées par l’IA. Si l’intérêt du superviseur pour ce sujet n’a rien de surprenant, le niveau de précision de ses attentes marque une étape nouvelle. Un document de stratégie ne suffit plus ; la BCE attend la preuve d’une capacité à agir. Le rythme de correction des vulnérabilités en est un exemple parlant : là où un délai de trois mois pouvait auparavant sembler acceptable, la référence se compte désormais en heures. Et cette responsabilité relève directement du conseil d’administration.

Le fait que ce courrier ait été adressé à la direction générale, et non aux seules équipes informatiques, est révélateur. Il s’inscrit dans le prolongement de l’avertissement publié le 25 juin par le CERS sur les risques cyber systémiques liés aux modèles d’IA, tandis que le superviseur a parallèlement reporté son questionnaire annuel sur les risques informatiques. Le message est sans ambiguïté : la cyber-résilience face à l’IA doit désormais être traitée comme un sujet de gouvernance, au niveau du conseil d’administration.

Les fondements du plan d’action

Le plan d’action demandé ne crée pas un nouveau cadre réglementaire. Il donne une traduction opérationnelle à ce que DORA impose déjà, avec une exigence renforcée en matière de rapidité, de traçabilité et de preuve. Applicable depuis le 17 janvier 2025, le règlement (UE) 2022/2554 sur la résilience opérationnelle numérique structure la résilience du secteur financier autour de cinq piliers : la gestion du risque lié aux TIC, le traitement et la notification des incidents TIC, les tests de résilience numérique, la gestion du risque lié aux prestataires tiers et le partage d’informations.

Le plan d’action cyber IA ne consiste donc pas à repartir de zéro. Il oblige surtout les établissements à renforcer trois piliers sous la pression d’attaques désormais accélérées par l’IA : la gestion du risque TIC (savoir précisément ce qu’il faut protéger et à quelle vitesse réagir), les tests de résilience (vérifier que les hypothèses résistent à un stress réel) et le risque lié aux tiers (mesurer le niveau de dépendance et identifier les acteurs critiques). Les organisations qui ont déjà abordé DORA comme un chantier opérationnel disposent d’un socle. Celles qui l’ont traité comme un exercice documentaire verront apparaître les failles.

Ce que cela signifie pour les établissements français

Le courrier de la BCE concerne les établissements placés sous sa supervision directe, parmi lesquels figurent les grands groupes bancaires français. Pour les autres acteurs, la mise en œuvre de DORA relève en France de l’ACPR pour les banques et les assureurs, et de l’AMF pour les acteurs de marché. Les obligations sont déjà en vigueur : notification des incidents majeurs liés aux TIC depuis le 17 janvier 2025, puis transmission, depuis avril 2025, du registre d’information recensant les prestataires TIC via le portail OneGate de la Banque de France.

Cette dynamique s’inscrit aussi dans le cadre de la transposition de la directive NIS2, portée par le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, toujours en cours d’examen au Parlement. Le texte désignera l’ANSSI comme autorité nationale et élargira les obligations de cybersécurité à près de 15 000 entités françaises, avec des sanctions pouvant atteindre 10 millions d’euros ou 2 % du chiffre d’affaires mondial. L’ACPR l’a toutefois rappelé dans sa FAQ : le calendrier parlementaire n’a aucune incidence sur DORA, déjà applicable. Attendre la loi n’est donc pas une option crédible.

Comment le superviseur évaluera la mise en œuvre

L’équipe de surveillance conjointe compétente (JST) ne se limitera pas à examiner l’existence du document : elle en évaluera la substance, la précision et le caractère démontrable. Quatre critères distingueront un plan robuste d’une simple déclaration d’intention :

• Des mesures concrètes plutôt que des principes : le plan doit montrer quels systèmes sont concernés, dans quel ordre ils seront traités et quelles valeurs cibles s’appliquent. De intentions d’amélioration ne suffisent pas.
• Des personnes nommées, pas seulement des comités : il faut désigner une personne propriétaire du plan, dotée d’un vrai mandat et pas seulement d’une responsabilité.
• Des ressources allouées : budget et effectifs, engagés de façon visible plutôt que vaguement promis.

Le quatrième critère est le plus déterminant : êtes-vous en mesure de prouver ce que vous affirmez ? Concrètement, cela signifie pouvoir présenter, à la demande, trois éléments factuels qui donneront au plan sa crédibilité auprès de la JST :

• Sur le rythme de correction : une analyse qui montre, pour les dernières vulnérabilités critiques publiées, combien d’heures ou de jours se sont écoulés entre la publication et le déploiement du correctif sur l’ensemble du parc. Elle doit présenter les chiffres sous forme de distribution et dans le temps, avec horodatage. Une moyenne arrondie ne satisfera pas le superviseur.
• Sur la transparence des actifs : un rapprochement entre l’inventaire réellement découvert et votre CMDB, qui rende l’écart visible. Il montre combien de terminaux, de serveurs et de charges de travail cloud existent sans figurer sur aucune liste officielle, et par quels moyens vous traquez ces systèmes non gérés et obsolètes. L’écart lui-même est la preuve la plus parlante.
• Sur l’avancement : un rapport que vous pouvez générer à bref délai, c’est-à-dire en quelques minutes et à partir d’une source de données unique, daté et traçable. Si la JST pose la question aujourd’hui, la réponse doit être prête, et non assemblée manuellement à partir de différents systèmes.

Le point commun à ces exigences est clair : des données horodatées, fiables, reproductibles et disponibles à tout moment.

Où résident les difficultés

Sur le papier, ces exigences peuvent sembler évidentes. Dans la pratique, beaucoup d’établissements risquent pourtant de s’y heurter, non par manque de volonté, mais parce que leurs architectures, leurs processus et leurs outils se sont empilés au fil du temps.

Cinq obstacles reviennent particulièrement souvent :

• Un paysage d’outils fragmenté : inventaire, vulnérabilités, correctifs et reporting sont répartis entre des solutions distinctes. Chaque question du superviseur se transforme en collecte de données à travers les frontières des systèmes.
• Une CMDB à la traîne : la base de configuration reflète l’état cible, pas l’état réel. Entre la réalité et la base s’étend un écart que personne ne peut combler en temps réel.
• Des angles morts : appareils non gérés, shadow IT et systèmes obsolètes n’apparaissent sur aucune liste. Ce sont précisément les points d’entrée que visent les attaquants.
• Des mondes séparés entre IT et sécurité : celui qui trouve une vulnérabilité n’est souvent pas celui qui la corrige. Chaque passage de relais coûte un temps qui manque aujourd’hui.
• La dépendance à la fenêtre de maintenance : quand l’IA produit des exploits en quelques heures, des cycles de correctifs réactifs et périodiques ne suffisent plus.

À cette complexité s’ajoute une faiblesse persistante : dans de nombreuses organisations, les preuves destinées au superviseur restent produites manuellement, souvent à partir de tableurs consolidés dans l’urgence. Ce mode de fonctionnement n’est ni répétable, ni robuste, ni adapté à une demande de la JST formulée à bref délai.

Les organisations les mieux préparées seront celles qui considéreront cette échéance non comme une contrainte de conformité supplémentaire, mais comme l’occasion d’accélérer l’automatisation et les transformations opérationnelles attendues depuis longtemps.

Votre feuille de route pour les prochaines semaines

À quelques semaines de l’échéance du 31 octobre, la priorité n’est plus de définir l’ambition du plan, mais d’en sécuriser le socle opérationnel.

Quatre chantiers doivent avancer de manière coordonnée :

1. Établissez votre inventaire complet. Obtenez une vue complète et en temps réel de tous les terminaux, serveurs et charges de travail cloud, y compris les systèmes non gérés et obsolètes. Rapprochez le résultat de votre CMDB, car l’écart constitue votre risque. Ce n’est qu’en sachant ce que vous exploitez que vous pouvez prioriser.
2. Rendez la vitesse mesurable. Définissez comme indicateur le délai entre la publication d’une vulnérabilité critique et le déploiement du correctif sur l’ensemble du parc (mean time to patch) et commencez à le mesurer. Découplez la mesure de la fenêtre de maintenance, sinon vous mesurez votre calendrier, pas votre capacité de réaction.
3. Mettez en place les preuves. Assurez-vous que l’avancement puisse être démontré en un clic, à partir d’une source de données unique, horodaté et prêt à être remis à la JST. Un rapport généré en quelques minutes est plus convaincant qu’un rapport compilé en plusieurs jours.
4. Ancrez la responsabilité. Désignez un responsable doté d’un mandat et d’un budget, et inscrivez le sujet dans une cadence régulière du conseil d’administration, sur la base des mêmes indicateurs que ceux utilisés par le superviseur.

En pratique, l’ordre des priorités est simple : établir d’abord la transparence et les indicateurs, puis bâtir l’automatisation et les preuves sur cette base, tout en installant la gouvernance dès le départ. Les établissements qui suivront cette trajectoire disposeront, au 31 octobre, non seulement d’un plan, mais surtout des éléments nécessaires pour le démontrer.

Du plan à la réalité démontrable

En tant que plateforme d’IT autonome, Tanium rassemble l’inventaire, la gestion des vulnérabilités, le déploiement des correctifs et la production de preuves dans un socle de données commun, fiable et continuellement actualisé. Un agent léger permet de remplacer la fragmentation des outils par une visibilité en temps réel sur l’ensemble des terminaux, associée à une capacité d’exécution automatisée et de réaction rapide. Le plan d’action cesse alors d’être un document déclaratif : il devient une réalité opérationnelle démontrable, capable de soutenir l’examen du superviseur.

L’échéance est fixée. L’enjeu n’est plus simplement de remettre un plan, mais de pouvoir démontrer qu’il repose sur une réalité opérationnelle solide.