Le rapport d’incident et le registre des prestataires décrivent la même panne.

Ce qui s’est passé

Le règlement sur la résilience opérationnelle numérique (règlement (UE) 2022/2554, DORA) s’applique depuis le 17 janvier 2025 aux banques, assureurs, établissements de paiement et de monnaie électronique, entreprises d’investissement et autres entités financières. Les incidents majeurs liés aux TIC doivent être notifiés à l’autorité compétente en trois étapes : une notification initiale dans les quatre heures suivant la classification de l’incident comme majeur et au plus tard 24 heures après que l’entité en a eu connaissance, un rapport intermédiaire dans les 72 heures suivant la notification initiale, et un rapport final au plus tard un mois après le dernier rapport intermédiaire. Les critères de classification et le contenu des rapports sont fixés par les règlements délégués (UE) 2024/1772 et 2025/301 de la Commission.

En parallèle, chaque entité financière tient un registre d’informations sur ses accords contractuels avec des prestataires tiers de services TIC et le transmet chaque année à son superviseur. Pour le cycle 2026, De Nederlandsche Bank a demandé le registre au plus tard le 20 mars 2026, avec le 31 décembre 2025 comme date de référence. En Belgique, la Banque nationale de Belgique et la FSMA sont les autorités compétentes, chacune pour les entités qu’elle supervise.

Le 18 novembre 2025, les trois autorités européennes de surveillance (ABE, AEAPP et AEMF) ont publié la première liste des prestataires tiers critiques de services TIC : 19 fournisseurs de services cloud, de centres de données, de télécommunications, de données et de services informatiques, désormais soumis à une surveillance européenne directe. La désignation s’est appuyée sur les registres transmis par les entités financières.

Ce que la première année a montré

Le 3 juin 2026, les autorités européennes de surveillance ont publié leur premier rapport annuel sur les incidents TIC majeurs. Les entités financières de l’UE ont notifié 3 383 incidents majeurs en 2025. Les défaillances de systèmes et les événements externes en étaient les principales causes ; seuls 10 % environ étaient liés à la cybersécurité. Près d’un tiers provenait d’une défaillance chez un tiers, comme un prestataire TIC, une autre entité financière ou un fournisseur d’infrastructure, et environ un tiers avait un impact transfrontalier. Deux tiers n’ont causé aucune perturbation, ou seulement une perturbation mineure, pour les clients et les transactions.

Le rapport est franc sur les données. Pour environ 15 % des incidents majeurs notifiés en 2025, aucun rapport final n’était parvenu à la date limite du 5 février 2026, et les autorités constatent encore des pratiques de notification divergentes selon les secteurs et les pays. Elles disent aussi où elles veulent aller : relier les notifications d’incidents au registre d’informations, pour repérer les incidents qui naissent chez des prestataires critiques et comprendre où le risque TIC se concentre.

Une panne, deux documents

Au sein d’une entité financière, ce lien est nécessaire pendant l’incident lui-même. Quand le service d’un prestataire tombe, l’équipe d’incident doit savoir quels contrats, fonctions et services en dépendent, souvent dans la fenêtre de quatre heures. Cette information figure dans le registre, généralement tenu par les achats, la gestion des risques ou une équipe de gestion des tiers. La chronologie de l’incident, elle, se construit dans des tickets, des canaux de discussion et des appels. Ce sont des situations typiques, pas des constats sur une institution en particulier.

• Classer sous pression. Qu’un incident soit majeur dépend des clients, des transactions, de la durée, des données et des services critiques touchés. Ces faits viennent de plusieurs systèmes à la fois.
• Le prestataire derrière la panne. Le registre indique quelles fonctions un prestataire soutient. Pendant un incident, quelqu’un le cherche à la main.
• Trois rapports, une même histoire. La notification initiale, le rapport intermédiaire et le rapport final doivent concorder entre eux et avec les faits. C’est en reconstruisant cela après coup, de mémoire, que les erreurs s’installent.

Ce qui change avec une vision connectée

L’étape utile consiste à traiter la chronologie de l’incident et le registre comme un seul ensemble de données. Quand le registre, la liste des fonctions critiques ou importantes et le dossier d’incident se trouvent dans une même couche de données, un incident en cours montre directement quel prestataire, quel contrat et quelle fonction sont concernés. Chaque étape de la chronologie garde sa source : le ticket, l’alerte de supervision, la note d’appel. Les trois rapports puisent alors dans le même dossier plutôt que dans trois reconstructions séparées.

Meridian Platform place sa propre couche de données dans votre environnement, alimentée par des connecteurs en lecture seule, de sorte que les systèmes sources restent la référence. Les dossiers et chronologies de Meridian Platform sont des capacités existantes ; la connexion de vos outils de tickets, de supervision et de votre registre est une intégration de projet. Meridian AI peut résumer la chronologie et préparer un projet de rapport avec une référence à chaque source ; une personne vérifie chaque chiffre et décide de la classification et de la transmission. Meridian est conçu pour soutenir les processus DORA. Il ne rend pas une entité conforme à DORA et ne transmet rien de lui-même à un superviseur. Cet article ne constitue pas un avis juridique et ne laisse pas entendre qu’une organisation citée dans les sources utilise Meridian.

Commencer par un incident passé

Une première étape pratique prend un incident clos, majeur ou presque, et reconstruit sa chronologie à partir des sources d’origine, à côté des entrées du registre pour les prestataires concernés. Mesurez combien de temps il faut aujourd’hui pour répondre à trois questions : quelles fonctions critiques ont été touchées, quel prestataire était en cause, et les trois rapports concordent-ils ? Comparez ensuite avec un dossier connecté. Passez aux incidents en cours seulement si le résultat tient pour vos équipes incidents et risques.

Une panne chez un prestataire est un seul événement. Le rapport d’incident et le registre devraient la raconter de la même façon.