La cartographie des risques ICT sous DORA est souvent présentée comme un exercice de conformité documentaire. Elle révèle, dans la pratique, quelque chose de plus inconfortable : la structure réelle des dépendances critiques d'une organisation, avec ses angles morts, ses chaînes d'interdépendances cachées, et ses plans de continuité qui ne tiendraient pas à l'examen. En 2025, l'EBA publiait son premier rapport sur la concentration des prestataires cloud dans le secteur financier européen. Le constat était sans ambiguïté : trois fournisseurs hyperscalers concentrent plus de 65 % des services cloud critiques déployés par les entités financières dans l'UE. DORA a anticipé cette réalité. L'Article 30.4 impose explicitement aux entités de considérer le risque de concentration ICT dans leur stratégie de gestion des tiers — au niveau de l'entité individuelle, mais aussi au niveau sectoriel.
Ce que DORA Article 30.4 impose concrètement
La majorité des travaux de conformité DORA s'est concentrée sur l'Article 30.2 : les exigences contractuelles avec les prestataires ICT critiques (clauses de résiliation, droits d'audit, niveaux de service). Ces exigences sont tangibles, négociables, et font l'objet de grilles de revue standardisées diffusées par l'EBA.
L'Article 30.4 est différent — et moins outillé. Il impose d'évaluer si les arrangements ICT créent un risque de concentration, en prenant en compte deux dimensions : l'entité peut-elle remplacer un prestataire dans des délais raisonnables si nécessaire ? La substitution de ce prestataire est-elle possible au niveau sectoriel, ou une défaillance de sa part affecterait-elle simultanément de nombreuses entités ?
La seconde question déplace la responsabilité au-delà de la stratégie individuelle. Votre conformité DORA ne s'évalue pas seulement en vous demandant si vous avez un plan de sortie — elle s'évalue aussi en vous demandant si votre secteur en a un. C'est une différence structurelle avec NIS2 ou le RGPD, qui restent centrés sur l'entité.
Les trois dimensions invisibles de la concentration ICT
Quand une organisation cartographie honnêtement ses dépendances ICT, elle découvre généralement trois formes de concentration qu'elle n'avait pas anticipées.
La concentration horizontale. Un même fournisseur est utilisé pour des services distincts : stockage, calcul, IA, sécurité, CDN. La dépendance individuelle à chaque service semble faible. La dépendance agrégée à un fournisseur unique sur l'ensemble du stack est, elle, structurelle. Un incident majeur chez ce fournisseur — panne régionale étendue, compromission systémique, décision réglementaire d'exclusion — n'affecte pas un service : il affecte la totalité des fonctions qu'il supporte.
La concentration verticale. Le chemin critique d'un service passe par un même fournisseur à plusieurs niveaux. Exemple fréquent : votre application métier est hébergée chez un ISV — mais cet ISV héberge lui-même son infrastructure chez le même hyperscaler que vous. Votre redondance apparente masque une dépendance partagée sur le fournisseur d'infrastructure en amont.
La concentration sectorielle. Vos concurrents directs ont les mêmes prestataires ICT critiques. Un incident affectant cet hyperscaler ne vous isole pas — il isole l'ensemble du secteur simultanément. Les effets systémiques sont alors amplifiés : la défaillance simultanée de nombreuses entités sature les équipes de support du prestataire, ralentit la résolution, et crée une compétition pour les ressources de remédiation.
La cartographie honnête — et ce qu'elle révèle systématiquement
L'exercice de cartographie des dépendances ICT produit des résultats systématiquement inconfortables pour trois raisons.
Premièrement, le nombre de dépendances critiques est généralement deux à trois fois supérieur à l'estimation initiale. La définition de « critique » sous DORA — systèmes dont l'interruption ou la dégradation affecterait de manière significative les fonctions commerciales — est plus large que celle qu'utilisent intuitivement les équipes IT. Les systèmes de surveillance, les outils GRC, les plateformes de communication sécurisée entrent dans le périmètre DORA plus souvent que prévu.
Deuxièmement, les dépendances indirectes sont systématiquement sous-documentées. Votre registre des tiers liste vos prestataires directs. Il ne documente pas les sous-traitants de vos sous-traitants. DORA exige pourtant une visibilité sur la chaîne complète pour les fonctions critiques. L'écart entre ce que vous pensez contrôler et ce que vous contrôlez effectivement est l'un des gaps les plus fréquemment identifiés lors des premières évaluations formelles.
Troisièmement, les plans de continuité ne couvrent pas le scénario de défaillance du prestataire. La grande majorité des plans de continuité d'activité ont été conçus pour des pannes internes : défaillance matérielle, incident réseau, erreur humaine. Le scénario d'une défaillance prolongée du prestataire cloud principal — ou d'une décision réglementaire d'exclusion d'un hyperscaler du marché européen — est rarement documenté, rarement testé, et rarement budgété.
L'exit plan : l'obligation que personne ne veut documenter
L'Article 28.8 de DORA impose aux entités de disposer de stratégies de sortie documentées pour leurs prestataires ICT de services critiques ou importants. Cet article est peut-être le plus systématiquement sous-traité de tout le règlement.
Documenter un exit plan pour un hyperscaler demande de répondre à des questions que peu d'organisations ont envie de poser formellement. En combien de temps pouvez-vous migrer vos workloads critiques vers un autre fournisseur ? Quel est le coût estimé de cette migration ? Avez-vous les compétences en interne pour l'exécuter sans ce prestataire comme support ? Quel est le délai minimum pour atteindre un niveau de service équivalent chez un concurrent ?
Les réponses honnêtes à ces questions font partie de l'évaluation du risque de concentration. Un exit plan qui conclut que la migration prendrait 18 à 24 mois n'est pas nécessairement non-conforme. Il est en revanche la documentation d'une dépendance structurelle que votre plan de continuité doit intégrer comme hypothèse de travail.
Préparer votre déclaration de concentration
Pour les entités financières soumises à la supervision des autorités compétentes (ACPR, AMF, BCE selon le périmètre), le registre d'information sur les arrangements ICT — attendu dans le format standardisé EBA — intègre une section dédiée au risque de concentration. Sa qualité est directement évaluable par l'autorité de supervision sans entretien préalable.
Une déclaration de concentration robuste s'appuie sur trois livrables : l'inventaire complet des prestataires ICT par fonction critique, avec niveau de criticité et nature de la dépendance (directe ou indirecte) ; la matrice de concentration horizontale et verticale par fournisseur ; et les exit plans documentés, avec délai estimé et conditions de déclenchement.
Presidio structure ces trois livrables en module dédié, aligné sur le format de registre EBA et connecté à la bibliothèque de contrôles DORA. Voir les fonctionnalités →
Conclusion
DORA Article 30.4 n'est pas un exercice de conformité documentaire. C'est une invitation à regarder en face la structure réelle des dépendances de votre organisation — et à décider, de manière informée, quel niveau de concentration est acceptable et à quelles conditions.
Les entités qui traversent cet exercice avec le plus de maturité partagent une approche commune : elles traitent la cartographie des dépendances ICT comme un outil de décision stratégique, pas comme une obligation réglementaire à cocher. La différence se voit dans la qualité de l'exit plan — et dans la capacité à répondre à la question que posera, un jour, votre autorité de supervision : si ce fournisseur disparaissait demain, combien de temps faudrait-il pour que votre activité soit à nouveau pleinement opérationnelle ?
Dans votre organisation, avez-vous une réponse documentée à cette question — ou seulement une intuition ?
Lire aussi : DORA à 18 mois : les lacunes persistantes dans la gouvernance ICT — Gouvernance des tiers : les angles morts du risque fournisseur NIS2 2026.