TARGET2: la reprise des paiements comme test de responsabilité

Résumé

• Les services de règlement de TARGET2 sont devenus indisponibles vers 14h40 heure d'Europe centrale le 23 octobre 2020. La reprise dans la même région n'a pas fonctionné, le module de secours était indisponible et l'Eurosystème a déplacé le service vers la région de secours. Le traitement complet des messages FIN a repris vers 1h20 le lendemain matin, après une séquence de reprises partielles et un redémarrage manuel des serveurs SWIFT.
• Le déclencheur immédiat était un défaut logiciel dans un équipement réseau tiers, activé par un paramètre de configuration lors de la préparation du travail réseau du week-end. Ce fait n'a pas transféré la responsabilité opérationnelle au fournisseur. L'opérateur contrôlait la classification du changement, le calendrier, les tests, la préparation au retour arrière, l'architecture du service, l'escalade de bascule et la communication avec les entités.
• Le dossier d'impact public fournit des preuves de trafic de paiement retardé et rejeté, de transferts de liquidités perturbés, d'effets sur les systèmes auxiliaires, de travaux de rapprochement et d'un comportement de liquidité inhabituel. Il ne fournit pas de chiffre fiable de pertes financières agrégées. Environ 12 milliards d'euros sur plus de 900 transactions rejetées représentaient la valeur du paiement, et non une perte avérée, et environ 400 milliards d'euros de moins dans les dépôts au jour le jour étaient une comparaison des flux de liquidités, et non un dommage.
• Un examen indépendant a trouvé 40 problèmes dans les cinq incidents des services TARGET de 2020, dont 17 constats de haute priorité. Sa conclusion la plus importante était systémique: la gestion des changements, la planification de la continuité, les tests de bascule, la documentation, les communications, la gouvernance et le cadre de contrôle ne formaient pas un système d'exploitation suffisamment intégré.
• L'Eurosystème a accepté les conclusions générales de l'examen et a créé 155 actions correctives. En juillet 2025, il a rapporté qu'une action restait à mettre en œuvre. Les preuves de service ultérieures montrent des changements significatifs, y compris un comité des risques indépendant et un règlement de secours utilisable lors d'une panne distincte en 2025, mais elles montrent également que la résilience des paiements de gros reste une obligation de responsabilité continue plutôt qu'un certificat de clôture unique.

Un système de paiement dont la reprise a des conséquences publiques

TARGET2 était le système de règlement brut en temps réel de l'Eurosystème pour les paiements en euros au moment de l'incident. Les banques commerciales, les banques centrales et les infrastructures de marché l'utilisaient pour régler des obligations de grande valeur et urgentes en monnaie de banque centrale. Le système n'était donc ni une application d'entreprise ordinaire ni un canal de commodité que les utilisateurs pouvaient simplement abandonner pendant quelques heures.

Sa disponibilité affectait les positions de liquidité des banques, les systèmes auxiliaires, le financement du règlement des titres et l'achèvement des paiements transmis par les banques aux clients.

L'échelle explique pourquoi la distinction importe. Lerapport annuel TARGET 2020indique que TARGET2 a traité 88,7 millions de transactions d'une valeur de 465 800 milliards d'euros cette année-là, soit une moyenne de 345 006 paiements et 1 800 milliards d'euros par jour ouvrable. Il représentait environ 90 % de la valeur réglée dans les systèmes de paiement de gros en euros. La majeure partie du volume des transactions n'était pas constituée par les banques centrales déplaçant leur propre argent: 83 % consistaient en paiements de clients et interbancaires classés comme transferts de tiers, tandis que le trafic des systèmes auxiliaires représentait une autre part importante.

Ce rôle public change le standard de responsabilité. Une explication techniquement correcte d'un commutateur défectueux est nécessaire, mais pas suffisante. L'opérateur doit être en mesure de démontrer qu'un changement risqué a été classé et testé de manière appropriée, que les sites redondants étaient véritablement récupérables, qu'une décision de bascule pouvait être prise avant l'expiration de l'objectif de reprise, que les entités savaient quoi faire et que les obligations de fin de journée étaient contrôlées.

Les preuves doivent également permettre aux organes de surveillance et aux entités concernés de distinguer un risque résiduel inévitable d'une défaillance de contrôle évitable.

TARGET2 avait une conception de résilience sophistiquée sur le papier. Il fonctionnait sur quatre sites dans deux régions, avec deux sites par région. La structure offrait à la fois un site secondaire dans la région active et une région de secours. Un module de secours séparé, communément appelé ECONS, était destiné à prendre en charge les paiements critiques lorsque le règlement normal était indisponible. L'incident a testé les trois couches: redondance des composants, reprise dans la même région et reprise inter-région.

Deux de ces couches n'ont pas produit de résultat opérationnel en temps utile, et la troisième n'a rétabli le service qu'après la prolongation de la journée ouvrable normale tard dans la nuit.

La leçon centrale n'est pas qu'une infrastructure complexe ne peut jamais échouer. C'est que la redondance est une revendication responsable. Elle ne doit être considérée comme prouvée que lorsque des tests en conditions de production, des droits de décision clairs, des opérateurs formés, des entités joignables et des preuves de reprise effective la rendent vraie en situation de stress.

Chronologie de l'incident, avec des limites de reprise explicites

Le premier récit opérationnel public est lacommunication de l'incident du 23 octobrede la BCE. Il indique que tous les services de règlement sont devenus indisponibles vers 14h40. Les instructions de paiement, les instructions des systèmes auxiliaires et les transferts de liquidités vers et depuis TARGET2-Securities et TARGET Instant Payment Settlement n'ont pas pu être traités. Le module d'information et de contrôle, l'interface principale par laquelle de nombreux entités surveillaient et géraient l'activité, était également indisponible.

Laprésentation conjointe de l'incident AMI-Pay et AMI-SeCofournit une séquence adaptée à l'audit, tout en laissant certains détails techniques minute par minute non publiés. La première conférence téléphonique des gestionnaires de crise de TARGET2 a eu lieu à 15h15, 35 minutes après la perte de service. La première communication aux entités a suivi à 15h30. À 16h30, ECONS avait été déclaré indisponible. Les opérateurs ont continué à tenter de récupérer dans la région active.

Vers 20h30, près de six heures après le début de la panne, l'Eurosystème a conclu que la reprise dans la même région n'était pas possible et a décidé de déplacer TARGET2 vers la région italienne. Le basculement technique inter-région a été achevé vers 22h30. Cette étape ne signifiait pas que tout le trafic de paiement avait repris. Le trafic des systèmes auxiliaires et des applications à applications a repris vers 23h10. Le trafic FIN a repris puis s'est arrêté à nouveau car les serveurs connectés à SWIFT nécessitaient un redémarrage manuel. Le traitement complet des messages FIN a repris vers 1h20 le samedi 24 octobre.

L'Eurosystème a prolongé le calendrier opérationnel. La date limite de paiement client a été fixée à 3h00 et la date limite interbancaire à 3h30. Son récit indique que toutes les instructions en file d'attente, y compris les transferts de liquidités de T2S, ont été traitées avant la clôture de la date de valeur à 3h30. Un blocage dans le module des facilités permanentes a été identifié vers 4h15. La date de valeur suivante a été ouverte à 5h10 et le règlement de nuit pour le lundi 26 octobre a commencé à 5h55.

Les opérateurs ont tenu 17 conférences de crise et envoyé 15 messages aux entités via les canaux de distribution d'informations de marché et RSS au cours de la réponse.

La durée nécessite de la prudence car les documents publics utilisent différents points de terminaison. L'annonce de l'examen indépendantde la BCE a décrit l'interruption comme durant "près de 10 heures". L'examen externe ultérieur a utilisé environ 11 heures. En comptant de 14h40 jusqu'au traitement complet FIN à 1h20, on obtient environ 10 heures et 40 minutes, tandis que l'achèvement technique inter-région à 22h30 produit un intervalle plus court et la clôture finale de la journée en produit un plus long. Ces descriptions sont conciliables une fois que la limite de service mesurée est énoncée. Elles ne doivent pas être réduites à un seul nombre faussement précis.

La chronologie évite également une erreur inverse. Il serait trompeur de dire que TARGET2 a simplement perdu la journée ouvrable et n'a jamais réglé ses files d'attente. Le dossier officiel indique que la date de valeur est restée ouverte et que les instructions en attente ont été traitées. Il serait tout aussi trompeur d'appeler cet achèvement de fin de journée un résultat de continuité réussi. Les services critiques ont été indisponibles pendant de nombreuses heures, les dates limites ont été déplacées, certains entités n'ont pas pu renvoyer le trafic, et les fichiers clients en aval ont été retardés.

La récupération du grand livre n'efface pas la perturbation opérationnelle nécessaire pour y parvenir.

Un dispositif défectueux était le déclencheur, pas la cause complète

Lamise à jour post-incidentde la BCE a identifié un défaut logiciel dans un dispositif réseau tiers à l'intérieur d'un réseau interne de banque centrale comme cause technique racine. L'Eurosystème a déclaré que le défaut n'était pas un incident cybernétique, que des mesures correctives avaient été prises et que TARGET2 et T2S fonctionnaient normalement les 26 et 27 octobre. Un petit nombre d'enquêtes de paiement restaient en rapprochement.

Le récit indépendant ultérieur fournit le contexte de contrôle. En préparation de l'activation de nouveaux commutateurs pendant le week-end à venir, les ingénieurs ont introduit un paramètre de configuration dans le réseau 4CBnet-NG. Le paramètre avait fonctionné sur six des huit dispositifs. Sur les dispositifs concernés, il a déclenché un comportement logiciel qui a déstabilisé la connectivité réseau et s'est propagé en cascade sur les deux sites de la région active.

La fonction d'assistance technique du fournisseur connaissait le défaut depuis mai 2020, mais le problème n'était pas apparu dans les manuels ou notes de version pertinents disponibles pour l'opérateur.

Cette séquence crée deux propositions de responsabilité différentes. La première est confirmée: un défaut latent du fournisseur a été activé par une modification du réseau de production. La seconde est une inférence institutionnelle étayée: la durée et l'ampleur de l'interruption dépendaient des défenses contrôlées par l'opérateur autour de ce défaut. Un fournisseur peut contrôler le code source, la divulgation des défauts et le support technique.

Il ne contrôle pas si le propriétaire du système classe un changement réseau comme pouvant avoir un impact commercial, le planifie pendant les heures de service, le teste dans un environnement représentatif, valide le retour arrière, protège les deux sites d'une défaillance de mode commun ou escalade vers la région de secours dans l'objectif de reprise.

L'examen externe de Deloitte, commandé par l'Eurosystème et publié sous forme abrégée, a trouvé des faiblesses à chacun de ces points de défense. Les changements traités comme n'ayant pas d'impact commercial n'avaient pas toujours une justification documentée. Les preuves de test étaient incomplètes. Certains changements apportés à l'infrastructure réseau, matérielle, d'alimentation et de refroidissement pouvaient être traités comme standard et à faible risque malgré leur capacité à arrêter les services. L'examen n'a trouvé aucun environnement de test fonctionnel pour les changements réseau, ce qui signifie que des changements importants pouvaient passer directement en production. Il a également constaté des lacunes dans l'examen des informations de version des fournisseurs.

Le modèle causal correct est donc en couches. Le défaut du fournisseur explique pourquoi le commutateur s'est comporté de manière inattendue. La gouvernance du changement explique pourquoi le comportement est entré en production sans confinement adéquat. L'architecture et la préparation au basculement expliquent pourquoi un défaut dans un domaine de changement a pu affecter les deux sites de la région active et résister à la reprise dans la même région. La gouvernance de crise explique le temps nécessaire pour choisir la région de secours.

Les communications et la préparation des entités expliquent pourquoi la restauration technique n'a pas immédiatement rétabli tous les flux de paiement. Aucune de ces couches ne nécessite de spéculation sur les motivations personnelles. Ce sont des domaines de contrôle documentés dans l'examen public.

Redondance nominale face à une défaillance de mode commun

La panne a exposé une faiblesse récurrente dans les affirmations de résilience: deux composants ou deux sites peuvent sembler redondants tout en partageant un chemin de défaillance. Les deux sites de la région active dépendaient de l'environnement réseau affecté. La tentative de reprise s'est donc heurtée à la même condition déstabilisante plutôt que de l'éviter. ECONS était également indisponible lorsque les gestionnaires de crise ont d'abord cherché l'option de secours.

Au moment où les opérateurs se sont engagés dans la région de secours, le seuil de reprise de deux heures utilisé pour les systèmes de paiement d'importance systémique était déjà dépassé.

Le problème n'était pas simplement qu'un basculement prenait du temps. L'examen a révélé que les scénarios de basculement étaient définis de manière incohérente et souvent spécifiques à un composant ou statiques plutôt qu'holistiques. Les sites primaires et secondaires n'étaient pas toujours fonctionnellement identiques. Il n'y avait pas de période de déclenchement suffisamment claire imposant une décision avant l'expiration de l'objectif de temps de reprise. Les tests de basculement de TARGET2 étaient liés aux rotations de sites, et l'examen a rapporté que ces tests n'avaient pas été effectués entre les rotations de 2019 et 2020.

Les rapports de test ne consolidaient pas systématiquement les leçons en amélioration continue.

Un incident antérieur fournit un contrefactuel utile mais limité. Le 11 août 2020, TARGET2 a subi une interruption différente et les opérateurs ont initié un basculement dans la même région à 15h45. Le nouveau site était techniquement disponible vers 16h43, bien que la restauration des services résiduels ait pris plus de temps. La comparaison dans le rapport annuel montre que la reprise dans la même région pouvait fonctionner dans certaines conditions de défaut. Elle montre également pourquoi un test réussi ou un basculement antérieur ne peut prouver la résilience face à un défaut réseau de mode commun.

Un ensemble de contrôle valide nécessitait des scénarios qui supprimaient les deux sites de la région active, altéraient l'interface de gestion, rendaient le canal de secours indisponible et forçaient une décision inter-région limitée dans le temps.

Le contrefactuel doit être formulé comme un test de contrôle, pas comme une affirmation qu'une décision non observée aurait certainement évité tout retard. Si la configuration avait été exercée dans un environnement réseau fonctionnellement représentatif, le défaut du fournisseur aurait pu être détecté avant la production. Si les sites avaient été isolés du même effet de changement, le site secondaire aurait pu rester utilisable. Si les règles de crise avaient exigé une décision inter-région assez tôt pour protéger l'objectif de deux heures, le traitement des paiements aurait pu reprendre plus tôt.

Si la préparation d'ECONS et la répétition des entités avaient été plus solides, le trafic critique aurait pu se poursuivre pendant la restauration du service normal. Chaque proposition est techniquement étayée par les recommandations de l'examen, mais le dossier public ne peut établir les minutes ou transactions exactes que chaque contrôle aurait économisées.

C'est le standard approprié pour la responsabilité contrefactuelle. Il identifie qui contrôlait une défense manquante et quel résultat observable la défense était conçue pour protéger. Il ne transforme pas une alternative plausible en une reconstruction fictive.

Le préjudice de paiement est plus large qu'une estimation de perte

Les pannes de paiement publiques créent plusieurs types de préjudices qui ne doivent pas être réduits à un seul nombre monétaire. Le premier est temporel: un paiement accepté ou attendu arrive plus tard que prévu par son émetteur, bénéficiaire ou système lié. Le second est lié à la liquidité: une banque ne peut pas déplacer des espèces entre comptes, financer des activités de titres, régler une position de système auxiliaire ou placer des réserves comme prévu.

Le troisième est opérationnel: le personnel doit surveiller les canaux, prolonger les heures d'ouverture, renvoyer les instructions, rapprocher les relevés et enquêter sur les exceptions. Le quatrième est lié à la confiance: les entités découvrent que les chemins de secours et de communication sont plus faibles que prévu.

La présentation de l'incident rapporte qu'environ 65 % du trafic du jour et 85 % de son chiffre d'affaires étaient déjà réglés au moment de l'interruption. Par rapport aux deux vendredis précédents, le chiffre d'affaires quotidien était inférieur de 10 à 15 % et le trafic de 3 à 5 %. Plus de 900 transactions, d'une valeur de paiement combinée d'environ 12 milliards d'euros, ont été rejetées. Les plus grands effets ont été signalés dans plusieurs composantes nationales majeures et dans le trafic interbancaire et des systèmes auxiliaires. Ce sont des indicateurs matériels de flux perturbé.

Ils ne sont pas une preuve que 12 milliards d'euros ont disparu ou sont devenus une perte économique.

Le dossier des entités ajoute des conséquences que le volume agrégé ne révèle pas. Certaines banques et systèmes auxiliaires n'ont pas pu renvoyer de messages car leurs propres systèmes en étaient incapables ou étaient déjà fermés. Les obligations critiques des systèmes auxiliaires ont été réglées, mais les fichiers manquants de chambre de compensation automatisée pour le trafic SEPA ont retardé les transferts aux bénéficiaires finaux. Certains entités directs à T2S ont rencontré des problèmes de réallocation de garanties. Des dizaines d'exceptions de paiement ont nécessité un rapprochement.

Ce sont des formes crédibles de préjudice opérationnel même lorsque les montants principaux finissent par être réglés.

Le comportement de liquidité a également changé. Onze banques ont utilisé la facilité de prêt marginal pour un total combiné de 19 millions d'euros. Les banques ont placé environ 400 milliards d'euros de moins en dépôts au jour le jour que ce qu'un modèle normal suggérerait, car l'opportunité de déplacer les réserves excédentaires était contrainte. Ces 400 milliards d'euros sont particulièrement faciles à utiliser à mauvais escient. Il s'agit d'un changement dans le placement des liquidités de la banque centrale, et non d'une estimation publique des dommages, pertes ou fonds clients gelés.

La source ne quantifie pas les intérêts perdus, les dépenses de personnel des entités, l'indemnisation des clients ou les coûts commerciaux induits.

L'effet sur l'infrastructure des titres était sélectif plutôt que total. Selon lerapport annuel T2S 2020, le règlement des titres dans T2S est resté disponible, mais les transferts de liquidités entre T2S et TARGET2 n'ont pas pu être traités. T2S a prolongé son propre calendrier, fermant à 3h30 et commençant le règlement de nuit suivant à 6h05. Cette distinction importe: l'incident n'a pas rendu tous les enregistrements de titres indisponibles, mais il a altéré la mobilité des liquidités dont dépendent les opérations de livraison contre paiement et de garantie.

Aucun dossier public accessible consulté pour cette analyse ne fournit un chiffre vérifié de perte économique agrégée, un décompte complet des bénéficiaires finaux retardés ou un calendrier d'indemnisation entité par entité. Un journalisme responsable doit conserver ces éléments comme inconnus. Un système peut causer de graves perturbations sans produire un total de pertes publiable, et l'absence de ce total ne doit pas être confondue avec une preuve d'absence de préjudice.

Qui contrôlait quoi

La responsabilité devient plus claire lorsque le contrôle est attribué par fonction plutôt que par seul nom institutionnel.

La structure de gouvernance de l'opérateur faisait elle-même partie de l'examen. Les fonctions de niveau 1 relevaient du Conseil des gouverneurs, le niveau 2 du Comité des infrastructures de marché et le niveau 3 des banques centrales prestataires de services. Deloitte a décrit la prise de décision comme concentrée à des niveaux élevés et le paysage des comités comme complexe. La documentation n'établissait pas toujours des responsabilités complètes. Une fonction de contrôle centrale de deuxième ligne disposant d'une autorité suffisante et d'un cadre de contrôle interne global n'était pas pleinement en place.

Certains problèmes de contrôle précédemment identifiés avaient mis trop de temps à être résolus.

Cela ne signifie pas que chaque entité était passif ou que chaque retard en aval était contrôlé centralement. Une banque qui manquait de capacité de renvoi contrôlait cette faiblesse locale. Un système auxiliaire qui avait fermé contrôlait une partie de sa propre disponibilité. Les entités étaient également censés surveiller les canaux d'information spécifiés. Cependant, ces responsabilités n'annulent pas les devoirs de l'opérateur d'infrastructure. L'opérateur a choisi l'architecture de communication, fourni les règles de secours, fixé le calendrier de service et représenté la résilience de la plateforme partagée.

La responsabilité est concurrente, non un concours dans lequel la faiblesse d'une partie en absout une autre.

La relation avec le fournisseur suit la même logique. Un défaut logiciel connu mais non divulgué est un fait grave de contrôle du fournisseur. Le dossier public n'identifie pas le fournisseur, ne divulgue pas le contrat, ne montre pas si un devoir d'avis a été violé, ni si l'Eurosystème a récupéré de l'argent. Ces inconnues empêchent un jugement juridique sur la responsabilité du fournisseur. Elles n'empêchent pas un jugement opérationnel selon lequel le propriétaire du système avait besoin de contrôles indépendants capables de contenir un défaut du fournisseur.

Le référentiel réglementaire et les limites du dossier juridique public

Au moment de la panne, TARGET2 était régi en tant que système de paiement d'importance systémique en vertu durèglement de la BCE sur les exigences de contrôle pour les systèmes de paiement d'importance systémique. L'article 15 exigeait un cadre robuste de risque opérationnel, des dispositifs de continuité des activités et un site secondaire. Les dispositifs devaient être conçus pour que les systèmes informatiques critiques puissent reprendre dans les deux heures suivant des événements perturbateurs et que le règlement puisse être achevé avant la fin de la journée ouvrable. Les plans devaient être testés et revus au moins une fois par an. Le règlement exigeait également la gestion des risques provenant des entités critiques, des autres infrastructures et des prestataires de services.

La référence internationale était cohérente. Le principe 17 desPrinciples for financial market infrastructuresdu CPMI-IOSCO appelle à l'identification des risques opérationnels internes et externes, à des systèmes et contrôles appropriés, à un site secondaire, à la reprise des opérations critiques dans les deux heures et à l'achèvement du règlement avant la fin du jour de perturbation. Il traite également des risques créés par les prestataires de services critiques et les infrastructures liées. Ces dispositions faisaient du temps de reprise un objectif de gouvernance, et non simplement une mesure de performance technique.

Sur la chronologie publique, le traitement complet des paiements n'a pas repris en deux heures. Le site de la même région et le module de secours étaient indisponibles, tandis que la décision inter-région est intervenue plusieurs heures après le début de l'interruption. C'est une base solide pour comparer les performances avec le référentiel réglementaire. Ce n'est pas, en soi, une preuve de violation formellement jugée.

Les documents examinés ici ne contiennent pas de décision publique d'application imposant une sanction pour l'incident d'octobre, de jugement de tribunal attribuant une responsabilité, ou de constatation d'un régulateur résolvant chaque élément de conformité.

Le cadre institutionnel rend les preuves particulièrement importantes. Ladescription de la politique de contrôle de la BCEexplique que l'Eurosystème collecte des informations, évalue les systèmes par rapport aux normes et induit des changements si nécessaire. Les services TARGET sont également exploités au sein de l'Eurosystème. Les fonctions opérationnelles et de contrôle sont distinctes, mais elles existent au sein de la même institution publique plus large. Il serait spéculatif d'affirmer que l'indépendance du contrôle a été compromise dans ce cas. Il est néanmoins raisonnable d'exiger une séparation visible des rôles, une contestation documentée et des preuves de clôture afin que le public n'ait pas à se fier uniquement à l'assurance institutionnelle.

L'indemnisation des paiements est un autre domaine où la précision importe. Ladirective TARGET2alors applicable incluait un régime d'indemnisation pour les ordres de paiement acceptés qui n'ont pas pu être réglés le même jour ouvrable en raison d'un dysfonctionnement technique. Il traitait des frais d'administration, de l'indemnisation des intérêts, des exclusions et de la relation entre l'indemnisation acceptée et les autres réclamations. Comme l'Eurosystème déclare que toutes les instructions en file d'attente ont été traitées avant la clôture de la date de valeur prolongée, le dossier public de l'incident n'établit pas combien d'ordres, le cas échéant, étaient éligibles, si des réclamations ont été déposées ou ce qui a été payé. Les messages rejetés et les fichiers en aval peuvent également soulever des questions juridiques différentes de celles des ordres acceptés dans le système central.

La responsabilité juridique a donc un plancher documenté et un résultat non documenté. Le plancher est l'objectif de conception de reprise de deux heures, le règlement de fin de journée, les tests annuels et la gestion des risques des prestataires de services. Le résultat qui reste inconnu comprend le traitement de l'application, les réclamations privées, les montants d'indemnisation et le recours contractuel contre le fournisseur. Une évaluation crédible doit énoncer les deux.

L'examen indépendant a transformé un incident en diagnostic systémique

L'Eurosystème a commandé à Deloitte d'examiner cinq incidents majeurs des services informatiques des services TARGET survenus en 2020. Les travaux se sont déroulés de fin décembre 2020 à mars 2021 et ont utilisé des documents, des entretiens et des tests selon une méthodologie d'assurance définie. Le rapport publié a été abrégé et expurgé pour des raisons de sécurité et de confidentialité des clients. Il ne s'agissait pas d'un audit général de tous les contrôles. Ces limites de portée importent, mais elles n'affaiblissent pas la signification des problèmes que l'examen a effectivement étayés.

L'examen a rapporté 40 constats: 17 classés comme haute priorité, 17 comme moyenne et six comme faible, aucun n'étant classé comme très élevé. Il les a regroupés en six grands domaines problématiques: gestion des changements et des versions; gestion de la continuité des activités; tests de basculement et de reprise; protocoles de communication; gouvernance; et opérations des centres de données et informatiques. L'incident d'octobre touchait les six.

La documentation sur la continuité des activités était fragmentée et parfois obsolète. Les rôles détaillés n'étaient pas systématiquement définis et les preuves de formation étaient insuffisantes. L'examen n'a pas reçu d'analyse d'impact commercial valide et à jour couvrant à la fois TARGET2 et T2S. L'analyse T2S disponible datait d'avant le lancement du service en 2015 et n'avait pas été tenue à jour. Sans analyse d'impact actualisée, les priorités de reprise, les dépendances et les hypothèses de temps d'arrêt tolérable ne peuvent pas être liées de manière fiable à la réalité commerciale actuelle.

La gestion des changements manquait d'un cycle de vie commun et riche en preuves. L'examen a trouvé des faiblesses dans l'évaluation des risques, la classification, la documentation des tests, l'approbation et la planification de la mise en œuvre. Les changements pendant les heures opérationnelles ne recevaient pas toujours un traitement proportionnel à leur impact possible. La préparation au retour arrière et les dépendances d'infrastructure nécessitaient des contrôles plus stricts.

Les informations de version des fournisseurs et l'absence d'un environnement de test réseau représentatif augmentaient la dépendance au comportement de production comme test ultime.

La communication fonctionnait mieux à l'intérieur de la gouvernance de crise qu'à travers le périmètre des entités. L'examen a constaté que les conférences téléphoniques de crise et la coordination internes étaient généralement efficaces. À l'externe, certains entités ne connaissaient pas le site Web de TARGET2 ou n'étaient pas abonnés à son canal RSS. Les messages des banques centrales nationales pouvaient diverger, et les communications n'indiquaient pas toujours aux entités quelles mesures prendre. Les leçons apprises ne recevaient pas systématiquement des propriétaires formels et des dates d'achèvement.

La documentation et la gestion de la configuration traversaient tous ces domaines. L'examen a trouvé du matériel opérationnel fragmenté ou obsolète et aucune base de données complète de gestion de la configuration capable de relier les actifs, les propriétaires, les dépendances et les changements. Les preuves de contrôle étaient parfois indisponibles. Cette déficience importe car la responsabilité après une défaillance complexe dépend de la reconstruction de quel composant a changé, qui en était propriétaire, de quels services il dépendait, quel test le couvrait et quelle approbation a accepté le risque résiduel.

Le résultat le plus important de l'examen n'était donc pas une liste de 40 défauts isolés. C'était la preuve que les défenses autour de l'infrastructure de paiement critique n'étaient pas gérées comme un système cohérent. Un défaut de dispositif est devenu une panne de production; des dépendances communes ont vaincu la redondance locale; des déclencheurs peu clairs ont consommé du temps de reprise; des faiblesses de communication ont réduit l'agence des entités; et des preuves fragmentées ont rendu l'assurance plus difficile.

Le diagnostic justifiait une remédiation à travers la gouvernance, et non seulement le remplacement ou le correctif de l'équipement réseau.

Le programme de réparation et ce que ses mesures prouvent, et ne prouvent pas

Laréponse formelle de l'Eurosystème à l'examen indépendanta accepté les conclusions générales et les recommandations du rapport. L'acceptation était une étape importante de responsabilité car elle évitait de traiter l'incident comme une anomalie de fournisseur non répétable. L'étape la plus difficile était de convertir les recommandations en contrôles observables et testables.

Leplan d'action des services TARGETpublié l'a fait à travers six flux de travail correspondant à l'examen. Les actions de gestion des changements comprenaient un cycle de vie standardisé, une évaluation des risques et de la sécurité renforcée, une documentation commune, des vérifications explicites de retour arrière, une approbation plus élevée pour les changements en dehors des fenêtres de maintenance et une analyse d'un environnement de test réseau dédié. Les actions de continuité comprenaient des procédures de crise révisées, un guide pour les gestionnaires de crise, la formation du personnel, des dispositifs de continuité holistiques et un examen annuel des analyses d'impact commercial et des plans de continuité.

Les actions de basculement étaient particulièrement pertinentes par rapport aux preuves d'octobre. Elles appelaient à des rôles clarifiés, une fréquence de test définie, un déclencheur de décision protégeant l'objectif de deux heures, des scénarios plus représentatifs, des rapports de test communs, des tests de transaction périodiques et des simulations avec les entités.

Les actions de communication cherchaient des avis factuels plus rapides, de meilleurs canaux de statut et d'abonnement, un contact direct avec des groupes de entités critiques, des messages alignés entre banques centrales et dépositaires de titres, et un apprentissage post-incident formel.

Les actions de gouvernance et de technologie couvraient un modèle opérationnel simplifié, un inventaire juridique, une fonction de risque et de contrôle habilitée, une meilleure surveillance, un accès à la surveillance de la région de secours, des règles pour les tiers, des opérations auditées et une base de données de configuration avec des propriétaires identifiés.

Le plan d'action rapportait également des changements opérationnels plutôt que de simples promesses. Les procédures d'activation d'ECONS ont été mises en œuvre et le personnel formé. Les conseils de crise ont été révisés pour inciter les décideurs à envisager une activation précoce du secours et à limiter les temps d'arrêt par rapport à l'objectif de reprise de deux heures. Des vérifications régulières ont été introduites pour la connectivité des banques centrales au réseau de secours, ainsi que des tests de transaction périodiques et des exercices plus larges. Ce sont les types de contrôles qui abordent directement la voie défaillante.

Les rapports d'avancement ont ensuite fourni des preuves intermédiaires. Unemise à jour de mise en œuvre de décembre 2022a consolidé 155 actions découlant de l'examen externe, des constats de contrôle et de l'audit interne. Le Comité des infrastructures de marché supervisait les travaux mensuellement; l'audit interne et les contrôleurs principaux évaluaient les preuves justificatives; et le Conseil des gouverneurs recevait des rapports semestriels. Au 31 mars 2022, les évaluateurs avaient examiné 79 actions: 58 étaient closes et 21 nécessitaient plus de preuves ou d'amélioration. Au 30 septembre, le comité rapportait 121 des 155 achevées, 16 en bonne voie et 18 en retard, principalement parce qu'elles dépendaient du programme de consolidation TARGET2-T2S.

La distinction entre "achevé par la direction" et "clos après évaluation" est essentielle. Une équipe de projet peut terminer une action sans prouver que le contrôle fonctionne. L'utilisation par le rapport de 2022 d'un examen des preuves par l'audit interne et le contrôle était donc plus solide qu'un simple pourcentage d'achèvement. Il a également divulgué des glissements plutôt que de réinitialiser silencieusement la base de référence.

À la fin de 2023, lerapport annuel T2S 2023indiquait que plus de 90 % des mesures prévues avaient été mises en œuvre, le reste étant attendu en 2024. En juillet 2025, lesdécisions publiées du Conseil des gouverneursindiquaient qu'une seule des 155 actions nécessitait encore une mise en œuvre et que le Comité des auditeurs internes continuerait à la surveiller. Le Conseil a mis fin au cycle de rapport annuel. C'est une preuve solide d'une exécution soutenue du programme. Ce n'est pas une preuve que les 155 actions étaient closes en juillet 2025, car le Conseil a explicitement préservé un élément ouvert.

La gouvernance a également continué d'évoluer. En septembre 2025, leConseil des gouverneurs a divulguéqu'un examen organisationnel de la gouvernance des services TARGET, initialement demandé en 2021, avait été achevé et que d'autres mesures devaient être rapportées d'ici 2027. Ce travail ultérieur ne doit pas être confondu automatiquement avec la seule action restante, dont le sujet n'est pas spécifié dans l'avis public. Il montre pourquoi "les rapports de programme ont pris fin" n'est pas la même chose que "l'amélioration de la gouvernance a pris fin".

Les opérations ultérieures sont le véritable test de durabilité

Les documents politiques peuvent montrer que des contrôles ont été conçus et attribués. Seules les opérations ultérieures peuvent montrer s'ils restent utilisables. Lerapport annuel TARGET 2023enregistre que le service T2 consolidé n'a pas subi de suspension complète en 2023, bien qu'il ait connu des incidents plus petits. Il rapporte également la création d'un comité des risques des services TARGET indépendant à la fin de 2023, soutenu par des cadres de risque et de contrôle révisés. C'est une preuve pertinente que la faiblesse de gouvernance de deuxième ligne identifiée après 2020 a reçu une réponse institutionnelle.

Un test beaucoup plus difficile est survenu le 27 février 2025. Lerapport annuel des services TARGET 2025, publié en 2026, décrit une panne distincte de matériel et de stockage qui a perturbé à la fois T2 et T2S pendant de nombreuses heures. T2 a été indisponible pendant environ 10 heures et T2S pendant environ huit heures. Le matériel critique et sa redondance ont échoué. Le diagnostic initial s'est concentré sur un problème de base de données, ce qui a retardé la décision de changer de région. Les services sont revenus après 18h00 et la journée ouvrable s'est terminée autour de minuit.

L'événement de 2025 ne peut pas être présenté comme une répétition du même défaut réseau, et il ne prouve pas que le plan d'action de 2020 a échoué en bloc. Sa valeur est celle d'un test de résistance en conditions réelles. ECONS a pris en charge les paiements T2 critiques lors de la panne ultérieure, preuve qu'une capacité de secours indisponible en octobre 2020 était devenue opérationnellement utile. Dans le même temps, la perte simultanée de T2 et T2S a rendu la mobilisation des garanties difficile et a retardé les processus connectés.

L'examen post-incident a généré 20 actions; le rapport indique que la plupart ont été achevées au quatrième trimestre 2025, tandis que quelques éléments non critiques en termes de temps restaient en cours.

Ce résultat mitigé est plus instructif qu'une revendication de victoire ou qu'une revendication d'échec. Un canal de secours a traité les paiements critiques, mais le diagnostic et la reprise dans la région de secours ont de nouveau consommé un temps considérable. Le système a démontré une capacité améliorée et exposé des dépendances résiduelles. Une responsabilité durable exige que les deux faits restent visibles.

Les travaux étaient encore actifs en 2026. Lerésultat de la réunion AMI-Pay de mai 2026enregistre une consultation sur les prolongations de la journée opérationnelle et l'utilisation d'ECONS après l'incident de 2025. L'Eurosystème et les banques centrales nationales déterminaient encore combien d'heures seraient nécessaires pour traiter la plupart des paiements critiques sur ECONS et quand les préparatifs devraient commencer pour clore la journée là-bas. Les entités ont également souligné la nécessité d'éviter les instructions en double et les effets néfastes sur leurs systèmes internes. Ce n'est pas une preuve d'une action non résolue de 2020. C'est une preuve que le règlement de secours est un écosystème opérationnel impliquant le comportement de l'opérateur et des entités, et que ses procédures doivent continuer à être affinées après des événements réels.

Faits confirmés, inférence étayée et inconnues

Faits confirmés.Les services de règlement de TARGET2 sont devenus indisponibles vers 14h40 le 23 octobre 2020. Le module d'information et de contrôle, les transferts de liquidités impliquant T2S et TIPS, le règlement normal des paiements et les instructions des systèmes auxiliaires ont été affectés. La reprise dans la même région n'a pas rétabli le service, ECONS était indisponible lors de la réponse initiale, et l'Eurosystème a choisi le basculement inter-région vers 20h30. Le traitement complet FIN a repris vers 1h20. La date de valeur a été prolongée, et l'opérateur déclare que toutes les files d'attente restantes ont été traitées avant la clôture de 3h30.

Il est également confirmé qu'un paramètre de configuration a activé un défaut logiciel dans un équipement réseau tiers, que le fournisseur connaissait le défaut et que le défaut n'était pas documenté pour l'opérateur dans le matériel de version pertinent. L'incident n'a pas été attribué à une cyberattaque. Les rapports publics enregistrent un trafic rejeté, des fichiers en aval retardés, des transferts de liquidités contraints, des travaux de rapprochement et un comportement modifié des dépôts au jour le jour.

L'examen indépendant a documenté 40 constats dans les incidents de 2020 et l'Eurosystème a créé 155 actions correctives, dont une attendait encore d'être mise en œuvre en juillet 2025.

Inférence étayée.L'ampleur et la durée de la panne n'ont pas été déterminées par le seul défaut du dispositif. Des faiblesses dans l'évaluation des changements, les tests représentatifs, l'isolation en mode commun, les déclencheurs de basculement, la préparation au secours et la communication avec les entités ont supprimé ou retardé des défenses qui étaient sous le contrôle de l'opérateur. Cette inférence est étayée par l'examen externe et par la correspondance directe entre ses constats et le plan d'action.

Il est également raisonnable d'inférer que la préservation de la date de valeur et le traitement de toutes les files d'attente ont réduit les conséquences de finalité de règlement et de risque principal par rapport à une journée non récupérée. Les sources ne permettent pas de quantifier cette réduction. De même, l'utilisation ultérieure réussie d'ECONS en 2025 soutient l'inférence que la capacité de secours s'est améliorée après 2020, mais elle n'isole pas quelle action a produit l'amélioration ni ne prouve que chaque scénario est désormais couvert.

Inconnues.Le dossier public ne nomme pas le fournisseur d'équipement, ne divulgue pas son contrat et ne montre pas si des recours contractuels ont été exercés. Il ne fournit pas les journaux de configuration complets, tous les enregistrements de décisions internes, les files d'attente au niveau des entités ou la raison exacte pour laquelle chaque banque n'a pas pu renvoyer le trafic. L'examen abrégé retient des informations techniques et client sensibles. Ces limites empêchent une reconstruction complète des actions individuelles et de la responsabilité juridique.

Le coût économique total est inconnu. Il n'existe pas d'agrégat vérifié des pertes client, du coût de liquidité, des heures supplémentaires du personnel, du coût d'opportunité, des indemnités, des réclamations ou du recouvrement auprès du fournisseur. Les sources publiques n'établissent pas si la panne d'octobre a donné lieu à une décision formelle de violation réglementaire, à une sanction ou à une action en justice. Elles n'identifient pas non plus le dernier élément restant parmi les 155 actions dans l'avis de juillet 2025 ni ne fournissent de preuve de test publique pour chaque action close.

Ces absences doivent rester visibles plutôt que d'être comblées par des estimations.

Un test de responsabilité durable pour l'infrastructure de paiement de gros

L'incident soutient un test pratique qui peut être appliqué aux services TARGET et à d'autres plateformes de paiement d'importance systémique. La responsabilité n'est durable que lorsque les propositions suivantes peuvent être répondues avec des preuves plutôt qu'avec une assurance.

Premièrement, l'opérateur peut-il cartographier chaque service critique vers une infrastructure et des dépendances possédées?Une base de données de configuration à jour doit relier les dispositifs, logiciels, sites, réseaux, fournisseurs, services métier, propriétaires responsables et procédures de reprise. Une modification d'un paramètre réseau doit révéler tous les services et domaines de redondance qu'elle peut affecter.

Deuxièmement, les décisions de changement sont-elles proportionnées à l'impact potentiel sur le service?La classification ne doit pas faire du travail réseau, d'alimentation, de stockage ou de refroidissement fondamental un travail à faible risque simplement parce qu'il semble routinier. Les preuves doivent inclure un raisonnement d'impact commercial, des tests représentatifs, une revue par les pairs, des fenêtres de mise en œuvre approuvées, une surveillance, des conditions d'arrêt et un retour arrière répété.

Troisièmement, la redondance est-elle indépendante dans les scénarios qui comptent?Deux sites ne fournissent pas deux défenses lorsqu'un seul changement ou plan de contrôle peut désactiver les deux. Les tests doivent inclure la perte d'une région active, la perte d'interfaces de gestion, la dégradation des services connectés et l'échec du chemin de secours nominal. Les configurations de production et de sauvegarde doivent être fonctionnellement équivalentes lorsque la reprise dépend de l'équivalence.

Quatrièmement, la gouvernance de crise force-t-elle une décision avant l'expiration de l'objectif de reprise?Les règles d'escalade doivent spécifier qui peut invoquer le traitement dans la même région, la région de secours et le traitement de secours, quelles preuves ils nécessitent et la dernière heure de décision. Un objectif de reprise de deux heures ne peut pas être atteint par un comité autorisé à continuer le diagnostic au-delà de deux heures sans choisir un chemin alternatif.

Cinquièmement, les entités peuvent-ils agir sur la communication?Un message de statut doit être opportun, accessible et opérationnellement spécifique. Il doit indiquer quels services sont affectés, ce que les entités doivent arrêter ou continuer, si les messages doivent être renvoyés, quelle date limite s'applique et quand la prochaine mise à jour arrivera. Les groupes critiques nécessitent des chemins de contact testés au-delà d'une page Web que certains utilisateurs ne savent pas exister.

Sixièmement, le traitement de secours peut-il gérer un trafic critique réaliste?ECONS ou toute capacité successorale doit être testé avec les banques centrales, les banques commerciales et les systèmes auxiliaires en utilisant des modèles de messages réels et des volumes réalistes. Les tests doivent couvrir l'évitement des doublons, la liquidité, les contraintes de garantie, la clôture de fin de journée et la transition vers le service normal. La connectivité seule n'est pas suffisante.

Septièmement, les préjudices et les exceptions sont-ils mesurés tout au long de la chaîne de paiement?Les métriques de l'opérateur doivent distinguer les instructions en file d'attente, rejetées, renvoyées, dupliquées, retardées et finalement réglées. Elles doivent capturer les fichiers auxiliaires, les transferts de liquidités, les cas de rapprochement et les retards des bénéficiaires en aval sans étiqueter le principal de paiement comme une perte financière.

Huitièmement, une fonction de contrôle indépendante conteste-t-elle la clôture?L'achèvement par la direction, la validation de deuxième ligne, l'évaluation de l'audit interne et la clôture par le contrôle sont des étapes différentes. Les actions de haute priorité doivent conserver des propriétaires, des délais et des preuves jusqu'à ce qu'un examinateur indépendant confirme l'opération, et non seulement la conception.

Neuvièmement, les recours juridiques et des entités sont-ils visibles?Une infrastructure publique n'a pas besoin de divulguer les réclamations sensibles, mais elle doit expliquer le cadre d'indemnisation applicable, le traitement agrégé des réclamations lorsque la loi le permet, et si la responsabilité du fournisseur ou du entité a été poursuivie. Le silence ne doit pas être transformé en hypothèse qu'aucun recours n'était disponible ou nécessaire.

Dixièmement, l'institution apprend-elle à nouveau après l'incident suivant?Un échec ultérieur doit être comparé aux engagements de contrôle antérieurs. La preuve d'une utilisation améliorée du secours mérite d'être reconnue; un retard répété dans le diagnostic ou le basculement mérite un examen. Un programme achevé doit devenir une base de référence opérationnelle maintenue, et non une archive.

Ces tests évitent deux extrêmes inutiles. L'un traite chaque panne comme une preuve que les dépenses de résilience ont échoué, un standard impossible pour les systèmes complexes. L'autre accepte les diagrammes d'architecture, les décomptes d'actions et une disponibilité annuelle élevée comme preuve que la continuité fonctionne. Le juste milieu défendable est exigeant mais mesurable: des défaillances se produiront, et l'institution responsable doit montrer que la prévention était proportionnée, la reprise rapide, les préjudices contrôlés, les décisions reconstructibles et les mêmes faiblesses ne persistent pas sans être contestées.

Conclusion

La panne d'octobre 2020 de TARGET2 a commencé par un défaut logiciel tiers, mais elle est devenue un événement de responsabilité car plusieurs défenses de l'opérateur ont échoué ensemble. Une modification du réseau de production a activé le défaut. Les deux sites de la région active étaient exposés. La reprise dans la même région et le règlement de secours étaient indisponibles. Le basculement inter-région est intervenu après des heures de tentatives de reprise. Les communications n'ont pas équipé chaque entité pour répondre, et la journée ouvrable a dû être prolongée jusqu'au samedi matin.

L'Eurosystème a finalement traité ses files d'attente et préservé la date de valeur, commandé un examen indépendant, accepté un diagnostic systémique et poursuivi un programme de réparation important avec des rapports d'avancement externalisés. Ce sont des actions de responsabilité substantielles. La création ultérieure d'un comité des risques indépendant et l'utilisation opérationnelle d'ECONS lors d'une panne distincte en 2025 ajoutent des preuves que certains contrôles importants ont changé.

Le dossier n'est pas une base pour déclarer la résilience complète. Une des 155 actions restait ouverte en juillet 2025, les mesures de gouvernance se sont poursuivies selon un calendrier ultérieur, et l'incident de 2025 a exposé de nouvelles difficultés dans le diagnostic, la redondance et les dépendances de service simultanées. Le dossier n'est pas non plus une base pour inventer des pertes, des violations juridiques ou des reproches individuels que les preuves officielles n'établissent pas.

TARGET2 a fait de la reprise elle-même le test. Pour une infrastructure de paiement partagée, la responsabilité n'est pas satisfaite en identifiant le composant défectueux ou en rapportant une disponibilité annuelle.

Elle est satisfaite lorsque les institutions qui ont le contrôle pratique peuvent prouver que les changements sont contenus, que les décisions de basculement protègent le temps de reprise promis, que les canaux de secours fonctionnent avec de vrais entités, que les paiements retardés et les effets de liquidité sont mesurés honnêtement, que le contrôle peut contester l'opérateur et que les réparations survivent au prochain choc opérationnel.