Dans la directive de la BCE sur la cybersécurité liée à l’IA : ce que les banques de l’UE doivent savoir

Directive de la BCE – 863×300

Une banque n’est pas seulement un coffre-fort qui abrite de l’argent. Il s’agit d’un mécanisme mû par une confiance publique implicite, entretenu par la conviction permanente que les capitaux restent protégés et disponibles sur simple demande. En cas de défaillance des risques opérationnels – qu’elle provienne de cyberattaques, de pannes informatiques ou de failles tierces –, cette confiance est brisée, ce qui compromet non seulement une entité isolée, mais l’équilibre de tout le réseau financier. Voilà pourquoi la supervision réglementaire dépasse le cadre de la simple conformité : les autorités exigent une gestion rigoureuse des risques opérationnels pour veiller à ce que les banques conservent la résilience requise pour protéger la confiance systémique, prévenir les crises par effet domino et garantir la fluidité de l’économie.

Bien que les perturbations des activités constituent le risque qui a traditionnellement le plus compté pour les banques, la Banque centrale européenne (BCE) et le Comité européen du risque systémique (CERS) considèrent les modèles d’IA de pointe (FAIM) comme une menace systémique pour la cyber-résilience du système financier européen, une préoccupation majeure qui doit être traitée rapidement.

Dans cette optique, le 07/07/2026, la Banque centrale européenne a informé les PDG de toutes les grandes banques européennes que les modèles d’IA de pointe peuvent désormais détecter et exploiter des vulnérabilités logicielles plus rapidement que tout processus au rythme humain ne peut réagir. Le Comité européen du risque systémique a confirmé la position de la BCE selon laquelle les modèles d’IA de pointe procurent aux acteurs malveillants un réel avantage à court et moyen terme.

Ce risque n’est pas d’un genre inédit. C’est un risque que chaque banque connaît déjà, mais qui évolue à une vitesse que la plupart des équipes de sécurité et d’ingénierie n’ont jamais été conçues pour gérer. Désormais, les 110 plus grandes banques européennes et, indirectement, 1 900 établissements de moindre taille ont jusqu’au 31 octobre 2026 pour soumettre à leur équipe de surveillance conjointe un plan d’action concret, précisant les contrôles, les ressources et les responsables désignés pour se protéger contre les menaces posées par les derniers modèles d’IA de pointe.
Qu’est-ce qui rend les attaques contre les modèles d’IA de pointe si dangereuses ?
Un attaquant doté de capacités d’IA peut transformer des failles à faible impact en un exploit fonctionnel et le déployer en quelques minutes, souvent avant même qu’une CVE ait été publiée ou évaluée. Le classement des priorités reposant uniquement sur le CVSS est incapable de rivaliser avec cette cadence, et de surcroît, il n’a jamais mesuré la gravité avec une grande fiabilité. La solution qui s’y substitue est l’accessibilité : cette faille concerne-t-elle concrètement ce que vous faites tourner ? Correctement exécutée, cette mesure réduit à elle seule le bruit de 80 à 90 %, de sorte que les équipes passent leur temps sur les menaces réelles au lieu d’un carnet de tickets interminable.
Où s’inscrit la chaîne d’approvisionnement logicielle
Une part importante de la directive concerne directement la chaîne d’approvisionnement logicielle : connaître l’ensemble des composants tiers et open source exécutés dans votre environnement, encadrer l’intégration de nouveaux éléments en amont, et réduire le délai entre la découverte d’une faille, l’évaluation du risque et sa correction, sans nuire à la conformité ni freiner les pipelines indispensables aux livraisons de vos équipes.
L’angle mort au sein de votre propre stack
La lettre de la BCE crée un autre vide crucial que presque aucun plan d’action ne couvre encore : les modèles d’IA, les serveurs MCP et les compétences d’agents déjà actifs dans votre environnement. La lettre vous invite à vous préparer aux menaces amplifiées par l’IA. Elle n’explique pas comment régir les composants d’IA intégrés à votre propre chaîne d’approvisionnement, et c’est l’aspect que la plupart des banques n’ont pas encore abordé. Si votre équipe de supervision conjointe vous demande de quelle manière vous encadrez vos composants autonomes aujourd’hui, et que vous devez honnêtement admettre que « c’est en cours », serez-vous réellement en mesure de déposer votre plan le 31 octobre ?

Voici un moyen rapide de tester où vous en êtes réellement :

Pouvez-vous répertorier tous les modèles d’IA, serveurs MCP et compétences d’agent utilisés aujourd’hui en production, sans devoir vous précipiter ?

Pouvez-vous présenter des preuves fondées sur l’accessibilité pour vos vulnérabilités critiques ouvertes, ou seulement un nombre de CVE ?

Pourriez-vous produire, en quelques minutes plutôt qu’en quelques jours, une SBOM signée et un calendrier de remédiation pour une version spécifique ?

Si l’une de ces considérations vous fait marquer un temps d’arrêt, c’est précisément le vide que votre plan doit combler.

Tout cela repose sur le cadre DORA, que la note de la BCE réaffirme expressément. Les autorités de supervision de DORA vous demandent de prouver, sur demande, qu’un contrôle précis a fonctionné au moment où il le devait : un SBOM signé, une attestation ou un enregistrement horodaté de la remédiation pour une version donnée. Ces justificatifs devraient découler naturellement de chaque mise en production, plutôt que d’exiger des semaines de mobilisation effrénée. Le processus d’audit existant de la plupart des banques n’est pas conçu pour fonctionner ainsi. Notre rapport 2026 sur l’état de la sécurité de la chaîne logistique logicielle montre que la majorité des structures prennent encore une semaine ou davantage pour rassembler de tels justificatifs sur demande, et qu’une infime minorité est capable de le faire en une journée.
L’approche de JFrog
Nous avons collaboré avec une entreprise mondiale de services financiers, dont le chiffre d’affaires dépasse 50 milliards $, présente dans plus de 160 pays, afin de mettre en place une réplication en temps réel, une disponibilité de 99,9 % et une validation rigoureuse de chaque package open source transitant par son pipeline. Voilà précisément le socle sur lequel doit s’appuyer un plan d’action conforme à DORA.

Voici par où nous commencerions, sur la base de notre expérience de ce qui a fonctionné pour d’autres banques :

Commencez par une analyse des écarts par rapport aux propres domaines d’intervention de la BCE, afin de savoir exactement où vous en êtes avant le 31 octobre.
Faites de la gouvernance une partie intégrante du processus en disposant d’un système d’enregistrement unique pour chaque artefact.
Intégrez la sécurité à chaque étape, de l’ingestion à la production.
Gouvernez les agents, les compétences et les MCP en tant que composants de premier ordre de votre chaîne d’approvisionnement.
Priorisez par accessibilité, afin que l’effort de votre équipe se concentre là où le risque est réellement réel.
Automatisez la détection jusqu’à la remédiation, tandis que les équipes définissent les politiques et conservent le contrôle des approbations. À une telle cadence, un processus reposant sur une validation humaine à chaque maillon de la chaîne sera incapable de tenir la distance.

Vos mesures de sécurité doivent opérer au rythme des menaces afin de préserver vos clients des risques et de satisfaire aux exigences de DORA. Afin de vous conformer aux exigences de la BCE, la meilleure approche initiale consiste à évaluer l’état actuel de votre chaîne logistique logicielle et à prendre des mesures correctives selon vos constats.

Pour aller plus loin, visionnez notre webinaire : nous y décryptons la portée pratique de la directive de la BCE et la manière dont les établissements bancaires s’organisent pour se plier à la date limite du 31 octobre.