1. Introduction

Un grand groupe financier qui opère à travers l’Union européenne fonctionne rarement comme une entité juridique unique. Il fonctionne comme une société mère entourée d’une constellation de filiales, typiquement une société réglementée par État membre, chacune détenant son propre agrément, chacune répondant à son propre superviseur national, chacune façonnée par les règles locales qui se superposent aux règles européennes communes. La raison en est en partie historique, en partie réglementaire et en partie commerciale : les agréments sont nationaux, les superviseurs sont nationaux, et une entité locale dotée d’un nom local et d’un bilan local est plus facile à agréer, à superviser et à utiliser pour vendre. Ce que le groupe centralise, en revanche, presque toujours, c’est l’informatique. Il est dispendieux de bâtir onze fois la même plateforme bancaire centrale, le même système de gestion des polices, le même centre de données, le même centre des opérations de sécurité, aussi le groupe les construit-il une seule fois, dans la société mère ou dans une société informatique de groupe dédiée, et les fournit-il à chaque filiale comme un service partagé. L’activité est locale ; la tuyauterie est centrale.

Le règlement sur la résilience opérationnelle numérique traverse cet arrangement d’une manière facile à manquer tant qu’il n’est pas mis en œuvre. DORA, le règlement (UE) 2022/2554, s’applique depuis le 17 janvier 2025, et son unité de base est l’entité réglementée individuelle, non le groupe (DORA, art. 1 et 2). Chaque filiale doit elle-même tenir un cadre de gestion du risque lié aux TIC, classifier et notifier ses propres incidents majeurs, tester sa propre résilience, tenir son propre registre des tiers prestataires de TIC et les encadrer sous son propre conseil (DORA, art. 5 à 30). La réglementation se moque que la filiale n’ait pas construit la plateforme qu’elle exploite et ne puisse la modifier ; l’obligation est celle de la filiale malgré tout. Et lorsque le groupe se tourne vers l’entité qui a bel et bien construit la plateforme, la société mère, il découvre que DORA a déjà nommé la relation : une société de groupe qui fournit des TIC aux entités réglementées de son propre groupe est un prestataire de services TIC intragroupe, et DORA la traite, à presque toutes fins, comme un tiers (DORA, art. 3, point 20).

Deux problèmes en découlent, et ils font l’objet de cet article. Le premier est un décalage entre l’endroit où réside l’obligation et l’endroit où réside le contrôle. DORA met l’obligation sur la filiale et laisse le contrôle à la holding, et la holding, si elle n’est pas elle-même une entité financière réglementée, échappe à la portée directe de la réglementation, qui ne l’atteint qu’à travers les contrats et la surveillance que ses filiales sont tenues de lui imposer. Nous appelons cela l’asymétrie conformité–contrôle, et la section 3.1 en fait l’anatomie. Le second est que la centralisation des TIC concentre le risque. Un cœur partagé est un point unique dont la défaillance n’est pas le problème d’une seule filiale mais le problème de toutes les filiales à la fois, un événement corrélé de mode commun plutôt qu’un événement indépendant et diversifiable, et parce que chaque filiale touchée doit notifier à son propre superviseur, une seule défaillance technique devient une constellation de déclarations réglementaires simultanées à travers l’Union. La section 3.2 l’expose et la section 4 le modélise.

La contribution est un diagnostic et une conception, non un commentaire juridique. Nous énonçons les deux problèmes structurels sans détour, donnons un petit modèle quantitatif de celui de la concentration afin qu’un groupe puisse voir comment son degré de centralisation arbitre la fiabilité par entité contre le risque corrélé à l’échelle du groupe (section 4), et passons en revue ce que les principales obligations de DORA — le registre et les contrats (section 5), la notification des incidents (section 6), les tests (section 7) et la gouvernance (section 8) — exigent d’un groupe centralisé en particulier. La section 9 propose un modèle opérationnel cible qui satisfait la réglementation tout en conservant l’efficience qui a conduit le groupe à centraliser au départ. Les sections 10 à 12 répondent aux objections, énoncent les limites et concluent. La question qui traverse tout l’article est la suivante : comment un groupe se conforme-t-il, entité par entité, à une réglementation qui suppose que chaque entité contrôle ses propres TIC, alors qu’en réalité un seul cœur partagé les contrôle toutes ?

2. Ce que DORA exige, et de qui

2.1 Les cinq piliers

DORA organise la résilience opérationnelle d’une entité financière en cinq domaines, et il vaut la peine de les énoncer une fois car le problème du groupe touche aux cinq. Le premier est la gestion du risque lié aux TIC (chapitre II, art. 5 à 16) : un cadre de gouvernance et de contrôle, détenu par l’organe de direction, couvrant l’identification, la protection, la détection, la réponse et le rétablissement, avec un cadre simplifié plus léger ouvert à certaines entités de plus petite taille (art. 16). Le deuxième est la gestion et la notification des incidents liés aux TIC (chapitre III, art. 17 à 23) : un processus de détection et de traitement des incidents, une classification harmonisée de leur gravité (art. 18), et une obligation de notifier les incidents majeurs à l’autorité compétente selon un calendrier fixe de rapports initial, intermédiaire et final (art. 19). Le troisième est le test de résilience opérationnelle numérique (chapitre IV, art. 24 à 27) : un programme de tests réguliers pour chaque entité, et des tests avancés de pénétration fondés sur la menace (TLPT) au moins tous les trois ans pour celles que les autorités désignent comme significatives (art. 26 et 27). Le quatrième est la gestion du risque lié aux tiers prestataires de TIC (chapitre V, art. 28 à 44), là où la structure de groupe mord le plus fort, et que nous traitons longuement ci-dessous. Le cinquième est le partage d’informations sur les cybermenaces (chapitre VI, art. 45), qui est volontaire et n’a pas à nous retenir ici.

2.2 Le principe de l’entité

Le trait de DORA qui gouverne tout dans cet article est que ses obligations s’attachent à l’entité agréée individuelle. Un groupe bancaire n’est pas agréé ; ses filiales bancaires le sont. La disposition de DORA relative au champ d’application énumère les types d’entités financières qu’il lie, et chacune est une entité qui détient un agrément (art. 2). La conséquence est que la conformité est appréciée, et imposée, une entité à la fois, par la propre autorité compétente de cette entité. Il n’existe pas d’agrément de groupe pour se conformer au nom des filiales, ni de superviseur européen unique auquel le groupe dans son ensemble répondrait de sa résilience. Le registre d’informations est le seul endroit où la dimension de groupe est explicite : une entité doit le tenir non seulement à son propre niveau mais, lorsqu’elle fait partie d’un groupe, aux niveaux sous-consolidé et consolidé également (art. 28, paragraphe 3), de sorte qu’une entité consolidante assemble une vue à l’échelle du groupe. Mais l’obligation de se conformer, d’encadrer, de notifier et de tester demeure celle de la filiale individuelle, et ne peut être acquittée en désignant la société mère plus haut.

2.3 Les TIC intragroupe sont des TIC de tiers

Le second trait qui gouverne cet article est le traitement par DORA des TIC fournies depuis l’intérieur du groupe. Il serait naturel de supposer que les services qu’une filiale reçoit de sa propre mère sont internes, et hors du régime des tiers que DORA vise pour les fournisseurs externes. DORA ferme cette supposition. Il définit un prestataire de services TIC intragroupe comme une entreprise qui fait partie du groupe et fournit des services TIC principalement à des entités du même groupe (art. 3, point 20), et il fait entrer un tel prestataire dans les règles relatives aux tiers : la filiale réceptrice doit consigner l’arrangement dans son registre (art. 28, paragraphe 3), l’encadrer par un contrat écrit comportant les dispositions obligatoires (art. 30), évaluer la concentration qu’il crée (art. 29) et détenir des stratégies de sortie pour lui lorsqu’il soutient une fonction critique ou importante (art. 28, paragraphe 8). La nature intragroupe de la relation est quelque chose à consigner, non un motif d’exemption. En bref, lorsque la société mère fournit la plateforme, DORA lit la mère comme un tiers prestataire et la filiale comme son client, avec toutes les obligations que porterait le client d’un fournisseur externe de cloud ou de logiciel. Un groupe qui traite la relation comme une affaire purement interne, régie par un catalogue de services et une refacturation intragroupe plutôt que par un contrat conforme à DORA, n’est pas en conformité.

3. Le schéma de la holding centralisée

La figure 1 dessine le schéma dont traite cet article. Une holding ou une société informatique de groupe exploite le cœur de TIC critiques et le fournit à plusieurs filiales réglementées, chacune dans son propre État membre et chacune supervisée par sa propre autorité nationale compétente. Les flèches de service descendent du cœur ; les flèches de supervision et de notification des incidents remontent de chaque filiale vers sa propre autorité. Les deux problèmes de l’introduction sont visibles dans l’image : ce qui lie le groupe ensemble, le cœur, est fourni par une entité que les régulateurs n’atteignent qu’indirectement, et une défaillance en haut du diagramme se propage à chaque branche à la fois tandis que la notification se fragmente entre toutes les autorités en bas.

3.1 L’asymétrie conformité–contrôle

Dans une entité d’école, l’entreprise qui porte l’obligation DORA exploite aussi les systèmes, de sorte que l’obligation et les leviers pour l’acquitter sont dans les mêmes mains. Le groupe centralisé les écarte l’un de l’autre. La filiale porte l’obligation, parce qu’elle est l’entité agréée, mais elle n’exploite pas le cœur, ne peut le corriger, ne peut choisir son architecture, ne peut fixer ses objectifs de rétablissement et ne peut, seule, le tester. La holding exploite le cœur et détient tous ces leviers, mais elle ne porte aucune obligation DORA directe si elle n’est pas elle-même une entité financière agréée, ce qu’une pure société informatique ou holding n’est généralement pas. La réglementation anticipe exactement cela et le contourne : elle atteint la holding à travers la filiale, en exigeant de la filiale qu’elle impose, par contrat, les droits d’accès, d’audit, de coopération, de notification d’incidents, de test et de sortie qui permettent à la filiale d’acquitter une obligation portant sur des systèmes qu’elle ne possède pas (art. 30). La conformité de la filiale dépend donc de son pouvoir contractuel sur sa propre mère, chose inhabituelle et inconfortable à devoir exercer.

L’asymétrie a un tranchant pratique. DORA dit au conseil d’une filiale qu’il est responsable en dernier ressort du risque lié aux TIC de l’entité et qu’il ne peut déléguer cette responsabilité (art. 5, paragraphe 2) ; or l’influence réelle du conseil sur le cœur qui porte l’essentiel de ce risque passe par une fonction de groupe qui rend compte à la mère, non à lui. Si le conseil se contente de faire confiance au centre, il a délégué en substance ce qu’il ne peut déléguer en droit. S’il tente d’exercer une surveillance véritable, il lui faut des informations, des assurances et des droits qu’une relation intragroupe désinvolte ne fournit pas. La réponse de conception, développée en section 9, est de donner à la relation la formalité qu’elle aurait avec un fournisseur externe précisément pour que le conseil de la filiale puisse voir dans le cœur et le contester, et de bâtir le cadre de groupe de sorte que la surveillance de chaque conseil soit un apport réel plutôt qu’une courtoisie.

3.2 Le risque de concentration

Le second problème est que le cœur partagé est une concentration. DORA nomme directement le risque de concentration et exige de chaque entité qu’elle l’évalue avant de contracter et qu’elle le tienne sous surveillance, en incluant explicitement le risque issu des arrangements intragroupe et des prestataires difficiles à substituer (art. 29). Dans un groupe centralisé, la concentration est quasi totale : un seul cœur, un seul centre des opérations de sécurité, un seul ensemble de dispositifs de rétablissement, au service de toutes les entités réglementées du groupe. L’argument d’efficience en sa faveur est précisément son danger. La même plateforme unique, qui est moins chère à construire et plus facile à sécuriser une fois, est aussi un point unique dont la défaillance est partagée par tous ceux qui en dépendent. Là où un groupe fédéré de filiales exploitant chacune ses propres TIC subirait des défaillances une à une, indépendamment, un groupe centralisé les subit ensemble, parce que les défaillances ont une cause commune.

C’est la distinction entre défaillance indépendante et défaillance de mode commun sur laquelle les littératures de la sûreté et du risque systémique insistent de longue date (Perrow, 1999 ; Leveson, 2011 ; ESRB, 2022). Les défaillances indépendantes se diversifient : la chance que plusieurs surviennent à la fois est le produit de petites probabilités, et infime. Les défaillances de mode commun ne se diversifient pas : lorsque la cause partagée défaille, tout ce qui est en aval défaille ensemble, et la résilience du groupe est bornée par la résilience de son composant partagé le plus faible, et non améliorée par le nombre d’entités qui répartissent la charge. Concentrer les TIC ne répartit pas le risque entre les filiales ; il couple les filiales à un risque unique. La section suivante rend le propos précis.

4. Un modèle minimal du risque de groupe corrélé

Le modèle est une esquisse, destinée à rendre le mécanisme explicite et à permettre à un groupe de raisonner sur son propre degré de centralisation, non une estimation calibrée du risque. Il distingue la défaillance qu’une filiale subit seule de la défaillance que le groupe entier subit ensemble, et montre comment la centralisation déplace le risque du premier genre vers le second.

4.1 Altération par entité

Considérons un groupe de $n$ filiales réglementées. Une part $c$ d’entre elles, que nous traiterons comme la probabilité qu’une filiale donnée dépende du cœur partagé de la holding pour une fonction critique ou importante, sont raccordées au cœur ; appelons $c$ le ratio de centralisation. Au cours d’une période donnée, le cœur partagé subit une perturbation critique avec une probabilité $p_0$. C’est un événement de mode commun : lorsqu’il se produit, chaque filiale raccordée est altérée au même moment, pour la même raison. Indépendamment du cœur, les TIC locales propres de chaque filiale défaillent au cours de la période avec une probabilité $q$. Une filiale raccordée est donc altérée lorsque le cœur ou ses propres TIC locales défaillent,

qui est le chiffre que voit le conseil d’une filiale isolée lorsqu’il regarde son propre registre d’incidents. La centralisation qui raccorde la filiale à un cœur bien géré tend à abaisser $q$, parce qu’une plateforme partagée professionnelle est généralement mieux exploitée qu’une petite plateforme locale, de sorte que $u$ peut diminuer à mesure que le groupe centralise. Vue une entité à la fois, la centralisation améliore la résilience, et c’est la moitié honnête de l’argument d’efficience.

4.2 De l’indépendant au corrélé

Le groupe ne fait pas l’expérience de son risque une entité à la fois. Ce qui importe au groupe, et aux régulateurs, est la chance que plusieurs filiales soient altérées en même temps, parce que c’est l’événement qui est systémique, transfrontalier et simultanément notifiable. Sans cœur partagé, la seule façon pour deux filiales de tomber ensemble est que deux d’entre elles défaillent localement au cours de la même période, une coïncidence d’événements indépendants dont la probabilité est de l’ordre de $q^{2}$, c’est-à-dire petite au second ordre. Avec un cœur partagé, une seule perturbation du cœur abat toutes les filiales raccordées à la fois, de sorte que la probabilité d’un événement simultané, multi-entités, est de l’ordre de la propre probabilité de défaillance du cœur,

où le crochet est la probabilité qu’au moins deux des $n$ filiales soient raccordées, de sorte qu’une défaillance du cœur en altère au moins deux à la fois. Le propos n’est pas la forme exacte mais l’ordre : la centralisation convertit la probabilité d’un événement à l’échelle du groupe d’un second ordre dans une petite probabilité locale à un premier ordre dans la probabilité du cœur. Un cœur qui ne défaille que rarement est encore, comme source de défaillance simultanée multi-entités, bien plus dangereux que la somme des risques indépendants des filiales, parce que ses défaillances sont partagées plutôt que réparties. La figure 2 trace cette probabilité en fonction du ratio de centralisation pour les deux architectures : un groupe fédéré, chaque filiale sur ses propres TIC, la maintient plate proche de zéro, tandis que celle d’un groupe centralisé s’élève au-dessus de cette ligne de base à mesure qu’une plus grande part du groupe est raccordée au cœur partagé.

4.3 Le multiplicateur de charge réglementaire

Il y a une seconde conséquence de l’événement de mode commun qui est propre à DORA et à la structure de groupe, et elle concerne non la résilience mais la notification. Parce que chaque filiale est une entité réglementée distincte répondant à sa propre autorité compétente (section 2.2), une seule défaillance du cœur ne génère pas une déclaration d’incident ; elle en génère une de chaque filiale qu’elle altère, chacune à une autorité différente, chacune sur l’horloge de cette autorité, éventuellement dans la langue de cette autorité. Le nombre attendu de déclarations d’incident majeur simultanées déclenchées par une seule perturbation du cœur est simplement le nombre attendu de filiales raccordées,

de sorte qu’un groupe d’une douzaine de filiales entièrement raccordées à un cœur partagé transforme un seul événement technique en une douzaine de déclarations réglementaires parallèles dans une douzaine de juridictions, dans le délai de rapport initial de DORA, toutes décrivant la même cause racine. Ce multiplicateur de charge réglementaire est invisible dans la planification de toute filiale isolée et ne devient visible qu’au niveau du groupe, qui est précisément le niveau dont DORA ne rend aucune entité unique responsable. C’est l’argument pratique le plus fort en faveur de la coordination au niveau du groupe que bâtit la section 9.

5. Le registre, la concentration et les contrats

Le chapitre de DORA sur les tiers donne au groupe centralisé trois instruments qu’il doit utiliser, et chacun d’eux, appliqué honnêtement, fait remonter les problèmes ci-dessus plutôt que de les cacher.

Le registre d’informations (art. 28, paragraphe 3) est un inventaire de chaque arrangement contractuel pour les services TIC, tenu selon un modèle standard fixé par des normes techniques d’exécution (ITS 2024/2956) et distinguant les arrangements qui soutiennent des fonctions critiques ou importantes de ceux qui ne le font pas. Pour un groupe centralisé, le registre est l’endroit où la dépendance intragroupe devient indéniable : le registre de chaque filiale cite la holding comme prestataire de ses services critiques, et le registre consolidé que le groupe doit assembler (art. 28, paragraphe 3) montre, sur une seule page, qu’un seul prestataire se tient derrière les fonctions critiques du groupe entier. Un groupe qui remplit correctement le registre a documenté sa propre concentration ; un groupe tenté de laisser l’arrangement intragroupe de côté, au motif qu’il est interne, à la fois enfreint l’obligation de registre et s’aveugle au risque même que le registre existe pour montrer. Le tableau 1 expose les trois niveaux auxquels le registre est tenu et à quoi chacun sert.

L’évaluation du risque de concentration (art. 29) pose ensuite la question que soulève le registre : qu’advient-il si ce prestataire défaille ou doit être remplacé ? Pour un prestataire externe, la réponse est une analyse de substitution ; pour le cœur intragroupe, c’est plus difficile, parce que le cœur n’est généralement pas substituable du tout à un horizon raisonnable, ayant été construit une fois pour le groupe entier. DORA n’interdit pas la concentration, mais il exige de l’entité qu’elle la voie et la pèse, et la réponse honnête d’un groupe centralisé — que le cœur est un point unique de défaillance pour le groupe et effectivement irremplaçable à court terme — est elle-même le constat qui devrait piloter l’investissement de résilience et la planification de sortie que la réglementation exige également (art. 28, paragraphe 8).

Les arrangements contractuels (art. 30) sont le mécanisme par lequel la filiale acquiert du pouvoir sur un cœur qu’elle ne possède pas. DORA prescrit un socle de dispositions pour chaque arrangement et une liste plus longue pour les arrangements soutenant des fonctions critiques ou importantes : des descriptions complètes des niveaux de service, les localisations du service et des données, les droits d’accès, d’inspection et d’audit, les obligations d’assistance en cas d’incident, la coopération avec les autorités, les droits de surveillance, les conditions de sous-traitance (désormais détaillées par le RTS 2025/532) et des stratégies de sortie documentées (art. 28, paragraphe 8, et art. 30, paragraphes 2 et 3). Le cadre intragroupe ne relâche rien de tout cela. L’instruction de conception, développée ci-dessous, est de rédiger le contrat intragroupe comme si la contrepartie était un fournisseur externe traitant dans des conditions de pleine concurrence, parce que c’est la seule façon pour le conseil de la filiale d’obtenir, sur le papier, les droits que l’asymétrie lui refuse autrement.

6. Un incident, de nombreux régulateurs

Le régime de notification des incidents est l’endroit où le multiplicateur de charge réglementaire de la section 4 devient un problème opérationnel. DORA exige d’une entité qu’elle classifie un incident lié aux TIC au regard de critères harmonisés, et, s’il est majeur, qu’elle notifie son autorité compétente par un rapport initial dans un délai court, puis un rapport intermédiaire à mesure que le tableau se précise, puis un rapport final avec la cause racine (art. 18 et 19). Les critères de classification, les seuils et les modèles sont harmonisés à travers l’Union par des règles de niveau 2, ce qui est une aide ; mais les rapports vont toujours à la propre autorité de chaque entité, et l’horloge démarre pour chaque entité lorsque cette entité en prend connaissance.

Pour un groupe centralisé, une seule défaillance du cœur est, simultanément, un incident majeur pour chaque filiale qu’elle altère. Chaque filiale doit le classifier, chacune doit décider s’il franchit le seuil de majeur, et chacune doit déclarer, à sa propre autorité, dans le délai. Si les filiales classifient indépendamment et rédigent indépendamment, le groupe produit une dispersion de rapports qui décrivent le même événement de façon incohérente, arrivent à des moments différents, et exposent le groupe à la question de supervision évidente de savoir pourquoi ses entités sont en désaccord sur ce qui est arrivé à leur système partagé. Le mode de défaillance n’est pas la sous-déclaration mais la surdéclaration incohérente. Le remède n’est pas de centraliser la déclaration, que DORA n’autorise pas, puisque l’obligation est celle de chaque entité, mais de centraliser les faits : une seule taxonomie d’incidents, une seule détermination de la cause racine et une seule horloge menée depuis le centre des opérations de sécurité du groupe, alimentant un noyau de faits cohérent dans la propre déclaration de chaque filiale, que la propre fonction responsable de chaque filiale détient, signe et soumet ensuite à sa propre autorité. Le groupe fournit la vérité ; chaque entité fournit la déclaration. La section 9 rend cela concret.

7. Tester un cœur partagé

Le régime de tests de DORA comporte deux niveaux, et la structure de groupe complique les deux. Le niveau de base exige de chaque entité qu’elle mène un programme de tests de résilience, proportionné à sa taille et à son risque (art. 24 et 25). Le niveau avancé exige des tests de pénétration fondés sur la menace, à peu près tous les trois ans, pour les entités que les autorités identifient comme suffisamment significatives pour le justifier (art. 26 et 27). Dans un groupe centralisé, l’objet qui vaut la peine d’être testé est en grande partie le cœur partagé, parce que c’est là que résident les systèmes critiques et la concentration ; mais l’obligation de tester repose sur les filiales, qui n’exploitent pas le cœur.

Tester le même cœur partagé séparément pour chaque filiale serait dispendieux et, pire, risqué, puisque des exercices répétés de red team en direct sur une plateforme de production qui sert le groupe entier multiplient la chance qu’un test cause lui-même un incident. DORA anticipe les prestataires partagés et autorise, sous conditions, que les tests soient mutualisés ou conduits conjointement lorsque plusieurs entités s’appuient sur le même prestataire de TIC ou appartiennent au même groupe et partagent des systèmes, de sorte qu’un seul test dûment encadré du cœur partagé puisse satisfaire les entités participantes (art. 26 et 27 et les normes techniques TLPT). La mutualisation ne dissout pas l’obligation individuelle : chaque filiale participante doit toujours être partie à l’arrangement, doit toujours s’assurer que le test couvre ses propres fonctions critiques, et doit toujours agir sur les constats. Mais elle permet au groupe de tester la chose qui importe vraiment, le cœur, une fois et bien, plutôt que de nombreuses fois et mal. L’implication de conception est que le groupe devrait planifier les tests du cœur vers l’extérieur, inscrire les fonctions critiques de chaque filiale dans le test partagé, et détenir les droits contractuels (art. 30) qui permettent à une filiale d’exiger de son prestataire — ici sa propre mère — qu’il participe.

8. Une responsabilité qui ne peut être déléguée vers le haut

Le fil qui court à travers chaque section est l’insistance de DORA sur le fait que l’organe de direction de chaque entité porte la responsabilité en dernier ressort du risque lié aux TIC de cette entité, et que cette responsabilité ne peut être contractée ni déléguée (art. 5). Dans un groupe centralisé, c’est la disposition la plus en tension avec la réalité opérationnelle, parce que la réalité est que les filiales ont délégué les TIC, en substance, au groupe. DORA n’interdit pas au groupe d’exploiter les TIC de façon centralisée ; ce qu’il interdit, c’est que le conseil de la filiale traite cet arrangement comme un motif pour cesser d’être responsable. Le conseil doit conserver une compréhension suffisante du cœur dont il dépend, des informations suffisantes sur la manière dont il est exploité et dont il défaille, et un pouvoir contractuel et de gouvernance suffisant pour contester et, in extremis, pour agir, de sorte que sa responsabilité statutaire soit réelle plutôt que nominale.

Cela va à l’encontre d’un instinct centralisateur naturel et généralement bien intentionné, qui est d’épargner aux conseils des filiales le détail technique et de laisser les experts du centre s’en occuper. DORA exige l’inverse : que chaque conseil de filiale soit outillé et obligé d’encadrer un risque qu’il a externalisé à sa propre mère. Les conséquences pratiques sont une ligne de reporting de la fonction TIC de groupe vers chaque conseil de filiale, et non seulement vers celui de la mère ; une culture du risque lié aux TIC au niveau du conseil dans chaque filiale, et non seulement au centre ; et un cadre de groupe conçu de sorte que la surveillance de chaque conseil soit un véritable point de contrôle. Un groupe qui bâtit le cœur partagé mais laisse les conseils des filiales non informés a créé l’asymétrie conformité–contrôle sous sa forme la plus dangereuse, où les personnes responsables en droit sont les moins capables en fait d’exercer la responsabilité.

9. Un modèle opérationnel cible pour le groupe

La conception qui répond aux deux problèmes n’est pas de décentraliser les TIC, ce qui jetterait l’efficience et, selon le modèle de la section 4, pourrait même ne pas améliorer la résilience du groupe une fois le cœur partagé bien exploité. C’est de conserver le cœur central et de l’envelopper dans la structure que DORA exige, de sorte que l’obligation et le contrôle soient reconnectés par la gouvernance et le contrat plutôt que par la propriété. Cinq gestes découlent de l’analyse.

Gérer un seul cadre de gestion du risque lié aux TIC de groupe, visible par chaque conseil. Bâtir le cadre de gestion du risque lié aux TIC une fois, au niveau du groupe, à la norme que DORA et ses RTS exigent (art. 6 ; RTS 2024/1774), mais câbler son reporting vers l’organe de direction de chaque filiale et non seulement vers celui de la mère, de sorte que chaque conseil encadre le risque partagé avec une information réelle. Le cadre est central ; la responsabilité reste distribuée, comme la réglementation l’exige.

Contracter avec la mère comme si elle était un fournisseur. Donner à chaque fourniture intragroupe d’une fonction critique ou importante un contrat écrit comportant l’ensemble des dispositions de l’article 30 — droits d’accès et d’audit, devoirs d’assistance en cas d’incident et de coopération, conditions de sous-traitance et stratégie de sortie documentée — exactement comme une filiale l’imposerait à un fournisseur de cloud externe. La formalité n’est pas une surcharge bureaucratique ; c’est l’instrument qui convertit la responsabilité de papier de la filiale en un pouvoir réel sur le cœur.

Tenir un registre consolidé et le lire comme une carte des risques. Maintenir le registre aux niveaux entité, sous-consolidé et consolidé (art. 28, paragraphe 3) et traiter la vue consolidée non comme une corvée de déclaration mais comme la carte, par le groupe, de sa propre concentration, l’apport à l’évaluation du risque de concentration (art. 29) et à l’investissement de résilience qui en découle.

Centraliser les faits d’un incident, distribuer la déclaration. Mener une seule taxonomie d’incidents, un seul processus de cause racine et une seule horloge depuis le centre des opérations de sécurité du groupe, et alimenter un récit unique et cohérent de tout incident du cœur dans la propre déclaration de chaque filiale touchée, que cette filiale détient et dépose auprès de sa propre autorité (art. 18 et 19). Le groupe fournit une seule vérité ; chaque entité remplit sa propre obligation.

Tester le cœur une fois, pour tous ceux qui en dépendent. Planifier les tests de résilience et les tests fondés sur la menace du cœur partagé vers l’extérieur, en utilisant les dispositions de DORA sur les tests mutualisés et de groupe (art. 26 et 27) de sorte que la chose qui porte la concentration soit testée correctement et rarement plutôt que de façon répétée et superficielle, avec les fonctions critiques de chaque filiale inscrites dans le périmètre et chaque filiale agissant sur les constats.

Aucun de ces gestes ne défait la centralisation ; chacun reconnecte une obligation que DORA a placée sur la filiale à un contrôle que le groupe a placé dans la holding. Ensemble, ils permettent à un groupe de conserver la plateforme qu’il a construite une fois et de donner tout de même à chaque entité réglementée, et à chaque superviseur national, la relation encadrée, contractée, documentée et testée que la réglementation exige.

10. Objections et réponses

La mère n’est pas une entité réglementée, donc DORA ne s’applique pas à elle. Directement, non ; à travers ses filiales, entièrement. DORA atteint la holding en tant que prestataire de services TIC intragroupe en obligeant chaque filiale à l’encadrer, à contracter avec elle et à la surveiller (art. 3, point 20, et art. 30). Un groupe qui lit l’absence d’agrément de la mère comme une liberté à l’égard de DORA a confondu l’itinéraire de l’obligation avec son absence, et trouvera l’obligation qui l’attend dans le registre, le contrat et l’audit de chaque filiale.

La centralisation des TIC améliore la résilience, donc la concentration est une caractéristique, non un risque. Les deux sont vrais, ce qui est le propos de la section 4. Un cœur partagé bien exploité abaisse la propre probabilité de défaillance indépendante de chaque filiale ; il élève simultanément la probabilité d’un seul événement corrélé qui altère le groupe entier à la fois. Les dispositions de DORA sur la concentration (art. 29) existent précisément parce que le second effet est réel et est invisible depuis l’intérieur de toute entité isolée. La tâche de conception est de capter le premier bénéfice tout en voyant, en tarifant et en atténuant le second, non de nier que l’arbitrage existe.

Rédiger un contrat complet au titre de l’article 30 entre une mère et sa propre filiale est du théâtre juridique. Ce le serait, si l’unique objet du contrat était de satisfaire une liste de contrôle. Son objet réel est de donner au conseil de la filiale, responsable en droit d’un cœur qu’il ne possède pas, des droits opposables à l’information, à l’audit, à l’assistance et à la sortie sur ce cœur. Sans eux, la responsabilité statutaire du conseil (art. 5) est nominale. La formalité est le mécanisme qui rend la responsabilité exerçable, et le cadre intragroupe, où la contrepartie est une entité sœur au même propriétaire ultime, est exactement l’endroit où les arrangements informels tendent à laisser ces droits non écrits.

Les tests mutualisés dispensent le groupe de l’obligation de test individuelle. Non. La mutualisation (art. 26 et 27) est une façon de tester le cœur partagé efficacement et en sécurité, non une façon d’acquitter l’obligation d’une entité en désignant le test d’un autre. Chaque filiale participante demeure individuellement obligée de s’assurer que ses propres fonctions critiques sont dans le périmètre et d’agir sur les constats ; la mutualisation concerne la manière dont le test est mené, non à qui incombe l’obligation.

11. Limites

Il s’agit d’une analyse destinée aux praticiens, et ses limites devraient être énoncées sans détour. Ce n’est pas un avis juridique ; le texte qui fait foi est le règlement et ses actes de niveau 2, lus avec les orientations des autorités européennes de surveillance et de chaque autorité nationale compétente pertinente, et le conseil propre d’un groupe doit cartographier la structure générale exposée ici sur ses entités, ses agréments et ses États membres spécifiques. Les références d’articles renvoient à DORA tel qu’il se présentait au début de 2025, avec les actes délégués et d’exécution alors adoptés ; le détail des normes techniques, et la pratique de supervision à leur égard, continueront d’évoluer. Le modèle de la section 4 est une esquisse dont les quantités sont définies assez clairement pour être mesurées mais dont les formes fonctionnelles et les valeurs illustratives sont choisies pour rendre le mécanisme visible, non estimées à partir des données d’un groupe ; un groupe devrait renseigner $c$, $p_0$ et $q$ à partir de sa propre architecture et de son historique d’incidents avant de tirer la moindre conclusion des courbes. L’article traite aussi le cas courant et net d’un seul cœur central et d’une séparation mère–filiale claire ; les groupes réels ont plusieurs cœurs, une centralisation partielle, des holdings intermédiaires, des prestataires externes partagés derrière le prestataire intragroupe, et des fonctions critiques dans un État membre et non dans un autre, chacun compliquant le tableau sans en changer les deux problèmes de base.

12. Conclusion

Un groupe financier paneuropéen qui exploite ses TIC critiques depuis le centre et son activité réglementée depuis les marges a bâti la structure la plus sensée pour l’efficience et la plus malcommode pour DORA. La réglementation lie chaque filiale individuellement, suppose que chacune contrôle ses propres TIC, et trouve au lieu de cela qu’un seul cœur partagé, fourni par une mère que la réglementation n’atteint qu’en seconde main, les contrôle toutes. Deux problèmes en découlent : l’obligation de se conformer réside là où le contrôle ne réside pas, et la centralisation des TIC concentre le risque du groupe en un seul point corrélé dont la défaillance altère chaque filiale à la fois et est notifiée séparément à chaque superviseur. Nous avons exposé les deux, modélisé le second pour montrer que la centralisation échange une probabilité de défaillance par entité plus basse contre une probabilité corrélée à l’échelle du groupe plus haute, et lu le résultat à l’aune des dispositions de DORA sur le registre, la concentration, les contrats, les incidents, les tests et la gouvernance.

La réponse n’est pas d’abandonner le cœur central mais de l’encadrer comme DORA l’exige : un seul cadre de groupe visible par chaque conseil, des contrats intragroupe rédigés comme à destination d’un fournisseur externe, un registre consolidé lu comme une carte de concentration, un seul ensemble de faits d’incident distribué dans de nombreuses déclarations, et le cœur partagé testé une fois pour tous ceux qui en dépendent. Chaque geste reconnecte une obligation que la réglementation a placée sur la filiale à un contrôle que le groupe a placé dans la holding, de sorte que la chose que le groupe a construite une fois puisse être exploitée en conformité par chaque entité qui en dépend. La leçon plus profonde est celle que DORA a été écrit pour enseigner : que la résilience opérationnelle n’est pas une propriété d’une plateforme mais des arrangements qui l’entourent, et que dans un groupe ce sont ces arrangements, non l’organigramme de propriété, qui décident si un point unique d’efficience est aussi un point unique de défaillance.

Annexe A. Le modèle au complet

Le modèle de la section 4 utilise quatre quantités, que toutes un groupe peut estimer à partir de sa propre architecture et de son historique d’incidents. Le ratio de centralisation $c$ est la part des filiales réglementées du groupe dont les fonctions critiques ou importantes dépendent du cœur partagé ; un groupe peut le lire dans le registre consolidé (art. 28, paragraphe 3) en comptant, parmi ses filiales, combien citent le cœur intragroupe derrière une fonction critique. La probabilité de défaillance du cœur $p_0$ est la probabilité que le cœur partagé subisse une perturbation assez grave pour altérer la fonction critique d’une filiale dépendante au cours d’une période choisie ; elle est estimée à partir du propre registre d’incidents du cœur, non à partir de celui d’une filiale isolée. La probabilité de défaillance locale $q$ est la probabilité correspondante pour les propres TIC non partagées d’une filiale. Le compte $n$ est le nombre de filiales réglementées.

La référence indépendante est la comparaison qui rend la concentration visible. S’il n’y avait pas de cœur partagé, chaque filiale défaillant indépendamment avec une probabilité $q$, la probabilité qu’au moins deux filiales soient altérées au cours de la même période serait $1-(1-q)^{n}-nq(1-q)^{n-1}$, qui pour un $q$ petit est approximativement $\binom{n}{2}q^{2}$, une quantité de second ordre. Avec le cœur partagé, le terme dominant de la même probabilité est $p_0$ multiplié par la chance qu’au moins deux filiales soient raccordées, une quantité de premier ordre en $p_0$. Le rapport des deux est le facteur par lequel la centralisation élève l’exposition du groupe aux événements simultanés, multi-entités, et il est grand chaque fois que $p_0$ n’est pas beaucoup plus petit que $q^{2}$, ce qu’il n’est presque jamais. C’est le contenu formel de l’affirmation selon laquelle la concentration couple les filiales à un risque unique plutôt que de répartir le risque entre elles.

Deux pièges méritent une note. Le premier est d’estimer $p_0$ à partir de l’expérience du cœur d’une seule filiale, ce qui le sous-estime, parce qu’une filiale donnée ne voit que les incidents du cœur qui se sont trouvés l’altérer ; $p_0$ doit être lu à partir du propre registre du cœur à travers tous les dépendants. Le second est de traiter $c$ comme fixe alors qu’il est une décision : le groupe choisit, fonction par fonction, quelle part raccorder au cœur, et la valeur du modèle est de montrer le coût, en risque corrélé à l’échelle du groupe, de chaque incrément de ce choix, de sorte que le choix soit fait avec l’arbitrage de la figure 2 en vue plutôt que sur le seul fondement de l’efficience.

Annexe B. Une liste de contrôle des dispositions contractuelles intragroupe

La liste de contrôle ci-dessous rassemble les dispositions de l’article 30 qu’une filiale devrait obtenir dans son contrat pour la fourniture intragroupe d’une fonction critique ou importante. Elle ne remplace ni le règlement ni l’avis juridique ; c’est une liste de travail pour la conversation de conception entre la fonction informatique centrale d’un groupe et les conseils de ses filiales. Chaque disposition est une disposition dont la filiale a besoin pour acquitter, sur un cœur qu’elle ne possède pas, une obligation que DORA place sur elle ; le cadre intragroupe est l’endroit où chacune est le plus souvent laissée implicite et devrait au contraire être écrite.

Références

European Union (2022). Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (Digital Operational Resilience Act). Official Journal of the European Union, L 333, 1–79. https://eur-lex.europa.eu/eli/reg/2022/2554/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1774 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes and policies and the simplified ICT risk management framework. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1773 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards on the policy on contractual arrangements on the use of ICT services supporting critical or important functions. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj

European Commission (2024). Commission Delegated Regulation (EU) 2024/1502 supplementing Regulation (EU) 2022/2554 with regard to criteria for the designation of ICT third-party service providers as critical for financial entities. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2024/1502/oj

European Commission (2024). Commission Implementing Regulation (EU) 2024/2956 laying down implementing technical standards for the application of Regulation (EU) 2022/2554 with regard to the standard templates for the register of information. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj

European Commission (2025). Commission Delegated Regulation (EU) 2025/532 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the elements a financial entity must determine and assess when subcontracting ICT services supporting critical or important functions. Official Journal of the European Union, L series. https://eur-lex.europa.eu/eli/reg_del/2025/532/oj

European Supervisory Authorities (EBA, EIOPA and ESMA) (2024). Final report on draft regulatory technical standards on subcontracting under Article 30(5) of Regulation (EU) 2022/2554 (JC 2024 53). Joint Committee of the European Supervisory Authorities. https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024_53_Final_report_DORA_RTS_on_subcontracting.pdf

Basel Committee on Banking Supervision (2021). Principles for operational resilience. Bank for International Settlements. https://www.bis.org/bcbs/publ/d516.htm

Financial Stability Board (2019). Third-party dependencies in cloud services: Considerations on financial stability implications. https://www.fsb.org/2019/12/third-party-dependencies-in-cloud-services-considerations-on-financial-stability-implications/

Financial Stability Board (2023). Enhancing third-party risk management and oversight: A toolkit for financial institutions and financial authorities. https://www.fsb.org/2023/12/enhancing-third-party-risk-management-and-oversight-a-toolkit/

European Systemic Risk Board (2022). Mitigating systemic cyber risk. European Systemic Risk Board. https://www.esrb.europa.eu/pub/pdf/reports/esrb.SystemicCyberRisk220127~b6655fa027.en.pdf

European Banking Authority (2019). Guidelines on outsourcing arrangements (EBA/GL/2019/02). https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-outsourcing-arrangements

European Union Agency for Cybersecurity (ENISA) (2023). ENISA threat landscape 2023. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023

Perrow, C. (1999). Normal accidents: Living with high-risk technologies (Updated ed.). Princeton University Press. ISBN 978-0-691-00412-9.

Leveson, N. G. (2011). Engineering a safer world: Systems thinking applied to safety. MIT Press. ISBN 978-0-262-01662-9.

Kaufman, G. G., & Scott, K. E. (2003). What is systemic risk, and do bank regulators retard or contribute to it? The Independent Review, 7(3), 371–391. https://www.independent.org/pdf/tir/tir_07_3_scott.pdf