Une IA peut désormais aider un attaquant à exploiter une faille avant que la banque ait terminé de corriger son système.

Ces modèles d’IA peuvent notamment aider à :
— analyser le code d’un logiciel ;
— repérer une vulnérabilité exploitable ;
— générer ou adapter le code nécessaire pour déclencher l’attaque ;
— rechercher sur Internet les serveurs qui utilisent la version vulnérable ;
— automatiser l’attaque contre un grand nombre de systèmes.

Autrement dit, l’IA permet à l’attaquant d’aller beaucoup plus vite à chaque étape.

C’est le risque identifié par le European Systemic Risk Board qui souligne dans son avertissement du 25 juin 2026, que ces modèles d’IA peuvent réduire fortement le temps nécessaire pour découvrir une faille, produire un moyen de l’exploiter et lancer une attaque.

Le problème devient alors très concret. Lorsqu’une vulnérabilité est signalée, une banque doit généralement :
— identifier les systèmes concernés ;
— attendre ou obtenir le correctif de l’éditeur ;
— vérifier qu’il ne perturbe pas les applications existantes ;
— le tester ;
— l’approuver ;
— puis le déployer en production.

Ce processus peut prendre plusieurs heures ou plusieurs jours. Pendant ce temps, un attaquant assisté par une IA peut déjà avoir identifié la faille, préparé le code d’attaque et commencé à viser les systèmes exposés.

Il faut donc comparer deux délais :
1.    Le délai avant exploitation
Le temps nécessaire à un attaquant pour découvrir la faille → produire le code d’attaque → identifier les systèmes vulnérables → lancer l’attaque
2.    Le délai de correction sécurisée
Le temps nécessaire à l’établissement pour identifier les systèmes concernés → obtenir le correctif → le tester → l’approuver → le déployer

Lorsque le premier délai devient plus court que le second, la procédure normale de mise à jour n’est plus suffisante.

La banque doit alors être capable d’activer immédiatement d’autres mesures :
— isoler le serveur concerné ;
— fermer temporairement une interface exposée ;
— bloquer certains flux ;
— segmenter le réseau ;
— renforcer la surveillance ;
— basculer vers un système de secours ;
— ou interrompre temporairement un service.

Le registre des vulnérabilités critiques devrait donc documenter, pour chaque actif exposé :
— la vulnérabilité concernée ;
— le système et la fonction métier affectés ;
— le temps estimé avant exploitation ;
— le temps nécessaire pour corriger sans provoquer de panne ;
— les protections temporaires disponibles ;
— la personne habilitée à décider de l’isolement ou de l’interruption ;
— la durée maximale pendant laquelle l’exposition peut être acceptée.

Le contrôle doit désormais porter sur la capacité à protéger immédiatement le système pendant que le correctif est encore en préparation.