Le règlement DORA s’applique depuis le 17 janvier 2025. En France, l’ACPR indique une remise des registres d’information au 31 mars 2026. Le sujet n’est donc plus de préparer un inventaire de principe, mais de maintenir une représentation exploitable des services ICT, des fonctions qu’ils soutiennent et des dépendances qui peuvent interrompre ces fonctions.
Synthèse exécutive
- Le registre DORA n’est pas un annuaire fournisseurs. Les modèles réglementaires relient un accord contractuel, un service ICT, une fonction utilisatrice et une chaîne de prestataires. Pour les fonctions critiques ou importantes, ils demandent aussi une appréciation de la substituabilité, de l’impact d’un arrêt, de l’existence d’un plan de sortie et des solutions alternatives.
- Le fournisseur direct ne résume pas le risque. Le règlement d’exécution 2024/2956 demande d’identifier les sous-traitants dont l’interruption compromettrait la sécurité ou la continuité du service critique. Le règlement délégué 2025/532 ajoute la localisation, la concentration, la longueur de chaîne, les données traitées et la transférabilité aux facteurs à évaluer.
- La clause contractuelle ne prouve pas la capacité de sortie. DORA exige des plans complets, documentés, testés et revus périodiquement. Une sortie crédible doit montrer que les données, accès, configurations, compétences et contrôles métier peuvent être transférés dans un délai compatible avec la continuité attendue.
- La surveillance européenne d’un prestataire critique ne transfère aucune responsabilité. La première liste de prestataires ICT critiques a été publiée le 18 novembre 2025 à partir des registres transmis. Ce dispositif traite un risque systémique, mais complète seulement la gestion des risques qui reste à la charge de chaque entité financière.
Conclusion courte : la preuve décisive n’est pas la présence d’un fournisseur dans un fichier. C’est la capacité à partir d’une fonction critique, parcourir toute sa chaîne de service, retrouver les droits contractuels applicables et démontrer qu’une interruption ou une sortie a été préparée dans des conditions réalistes.
Le registre relie quatre objets, pas quatre fichiers
L’article 28 du règlement DORA impose de maintenir et mettre à jour un registre relatif à tous les accords contractuels portant sur l’utilisation de services ICT fournis par des prestataires tiers. Les accords soutenant des fonctions critiques ou importantes doivent y être distingués des autres.
Le règlement d’exécution (UE) 2024/2956 donne au registre une structure relationnelle. Quatre clés relient ses modèles : la référence de l’accord contractuel, l’identifiant de l’entité ou du prestataire, l’identifiant de la fonction et le type de service ICT. Ce dessin change la nature du contrôle. Une ligne « fournisseur cloud » sans fonction utilisatrice, service précis ni contrat de rattachement ne permet pas de reconstituer l’exposition.
| Objet | Question de contrôle | Information attendue dans le registre |
|---|---|---|
| Accord contractuel | Quel texte ouvre le service, pour quelle entité et jusqu’à quand ? | Référence unique, nature de l’accord, dates, droit applicable, préavis |
| Service ICT | Quelle capacité technique est réellement consommée ? | Type de service, description, données, pays de fourniture et de stockage |
| Fonction | Quelle activité dépend du service et avec quel impact ? | Entité utilisatrice, identifiant de fonction, criticité, motif et impact d’une interruption |
| Chaîne de service | Qui contribue réellement à la fourniture ? | Prestataire direct, prestataires intragroupe, sous-traitants pertinents, rangs et liens de dépendance |
Le modèle B_07.01 va plus loin pour les services soutenant une fonction critique ou importante. Il demande notamment la substituabilité du prestataire, le motif d’une substitution difficile, la date du dernier audit, l’existence d’un plan de sortie, la possibilité de réinternalisation, l’impact d’un arrêt et l’identification éventuelle d’un autre prestataire.
Un champ « plan de sortie : oui » n’établit pourtant ni la qualité du plan ni son exécution. Il signale l’objet à vérifier. La valeur opérationnelle apparaît lorsque le registre renvoie vers le contrat, l’analyse de risque, le dernier test et les écarts encore ouverts.
La chaîne utile s’arrête au risque matériel, pas au premier nom connu
Le registre n’exige pas une collecte indifférenciée de toutes les entreprises qui composent Internet. Le modèle B_05.02 inclut tous les prestataires directs et intragroupe. Pour les services soutenant une fonction critique ou importante, il inclut aussi tous les sous-traitants qui sous-tendent effectivement le service, c’est-à-dire ceux dont l’interruption compromettrait sa sécurité ou sa continuité.
Cette règle donne un critère de profondeur. L’équipe doit pouvoir expliquer pourquoi un acteur a été inclus, pourquoi un autre ne l’a pas été et sur quelle information repose cette conclusion. Une liste de sous-traitants copiée depuis une page juridique publique peut servir d’amorce, mais elle ne précise pas nécessairement le service consommé, le rang dans la chaîne, la localisation effective ni l’impact d’une interruption.
Le règlement délégué (UE) 2025/532 impose, avant la conclusion du contrat, d’évaluer si le prestataire direct peut identifier les sous-traitants qui soutiennent la fonction critique ou importante, informer l’entité financière et lui fournir les informations nécessaires. L’entité doit aussi apprécier :
- la longueur et la complexité de la chaîne ;
- la nature des données partagées ;
- les pays où le service est effectivement fourni et où les données sont traitées ou stockées ;
- la concentration sur un sous-traitant unique ou un petit nombre d’acteurs ;
- l’effet de la sous-traitance sur la transférabilité du service ;
- l’impact d’une défaillance sur la continuité et la disponibilité ;
- les obstacles possibles à l’exercice des droits d’accès, d’inspection et d’audit.
L’évaluation doit être reprise périodiquement lorsque l’environnement évolue, notamment en présence de changements touchant les fonctions soutenues, les menaces ICT, la concentration ou les risques géopolitiques. S’appuyer sur l’évaluation réalisée par le fournisseur direct est possible, mais l’article 3 du règlement délégué précise que cette dépendance ne limite pas la responsabilité finale de l’entité financière.
Les changements de sous-traitance appellent une décision
Le contrat doit prévoir une information suffisamment anticipée sur les changements matériels de sous-traitance. Il doit aussi ménager un délai raisonnable pendant lequel l’entité financière peut approuver le changement ou s’y opposer. Si le changement dépasse sa tolérance au risque, elle doit pouvoir demander une modification avant sa mise en œuvre.
Le règlement délégué prévoit un droit de résiliation dans trois cas précis : mise en œuvre malgré une opposition, changement réalisé avant la fin du préavis sans approbation, ou sous-traitance d’un service critique ou important que le contrat n’autorisait pas explicitement à sous-traiter.
Un dispositif praticable doit donc distinguer quatre états : changement annoncé, analyse en cours, décision rendue et modification effectivement appliquée. Sans cette chronologie, l’organisation peut connaître la nouvelle chaîne sans pouvoir prouver qu’elle l’a évaluée à temps.
Le contrat fixe les leviers, l’exploitation montre s’ils fonctionnent
L’article 30 de DORA établit un socle pour les accords portant sur des services ICT. Il demande notamment une description complète des fonctions et services, les conditions de sous-traitance, les localisations, la protection des données, leur accès et leur restitution, les niveaux de service, l’assistance en cas d’incident, la coopération avec les autorités et les droits de résiliation.
Pour un service soutenant une fonction critique ou importante, le contrat doit ajouter des objectifs de service quantitatifs et qualitatifs précis, les notifications susceptibles d’affecter la fourniture, des plans de continuité testés, la coopération aux tests de pénétration fondés sur la menace lorsqu’ils sont applicables, des droits de contrôle et d’audit, ainsi qu’une période de transition adéquate permettant un transfert vers un autre prestataire ou une réinternalisation.
| Levier contractuel | Question à vérifier | Trace d’exécution utile |
|---|---|---|
| Description du service | Les composants, fonctions et sous-traitances autorisées sont-ils délimités ? | Annexe de service versionnée et reliée au registre |
| Localisations | Les pays de fourniture, de traitement et de stockage sont-ils connus et notifiés avant changement ? | Dernière déclaration reçue, analyse du changement et décision |
| Niveaux de service | Les seuils permettent-ils une action corrective rapide ? | Mesures brutes, écarts, escalades et clôtures |
| Audit et inspection | Le droit peut-il être exercé par l’entité, son mandataire et l’autorité ? | Plan d’audit, demandes, rapport, limites rencontrées et traitement |
| Restitution des données | Le format est-il accessible en cas d’arrêt ou de résiliation ? | Export réel, schéma, contrôle d’intégrité et test d’import |
| Transition | Le service continue-t-il assez longtemps pour migrer ou réinternaliser ? | Calendrier testé, ressources, dépendances et critères d’acceptation |
Une certification du prestataire, un rapport d’assurance ou un audit mutualisé peuvent alimenter l’analyse. Ils ne doivent pas être présentés comme couvrant automatiquement le bon service, la bonne période et toutes les dépendances. Le modèle B_07.01 distingue d’ailleurs la date d’un audit du service de la date de réception d’une certification ou d’un rapport d’audit interne du prestataire.
La liste des prestataires critiques n’est pas une liste d’approbation
Les autorités européennes de surveillance ont publié la première liste de prestataires tiers de services ICT critiques le 18 novembre 2025. La désignation s’est appuyée sur les registres d’information et sur des critères comprenant l’importance systémique, le soutien de fonctions critiques ou importantes et la substituabilité.
Cette désignation déclenche une surveillance européenne conduite par une autorité de surveillance principale. Elle n’est ni une certification du prestataire ni une garantie attachée à chaque service vendu. L’EBA précise que ce cadre complète, sans les remplacer, la responsabilité des entités financières dans la gestion de leurs risques ICT et leur supervision par les autorités compétentes.
Deux conclusions pratiques en découlent :
- un prestataire absent de la liste peut rester essentiel au fonctionnement d’une entité particulière et doit être traité selon la criticité du service réellement consommé ;
- la présence d’un prestataire dans la liste ne dispense pas de vérifier le contrat, la chaîne de sous-traitance, les localisations, le niveau de service et la capacité de sortie propres à l’accord concerné.
Le registre sert ainsi deux niveaux différents. Il permet à l’entité de gérer son exposition particulière et fournit aux autorités les données nécessaires pour détecter des dépendances systémiques. Confondre ces niveaux conduit soit à sous-estimer un fournisseur local difficile à remplacer, soit à croire qu’un grand fournisseur surveillé transfère sa résilience à tous ses clients.
Un plan de sortie crédible commence par un scénario réaliste
L’article 28 demande des stratégies de sortie pour les services soutenant des fonctions critiques ou importantes. L’entité doit pouvoir sortir sans interrompre ses activités, limiter sa conformité réglementaire ni dégrader la continuité et la qualité des services rendus aux clients. Les plans doivent être complets, documentés, suffisamment testés et revus périodiquement.
Le règlement délégué (UE) 2024/1773 précise que chaque accord concerné doit disposer d’un plan documenté, réaliste et réalisable, fondé sur des scénarios plausibles et des hypothèses raisonnables. Son calendrier doit être compatible avec les conditions de sortie et de résiliation du contrat. Les scénarios cités couvrent l’interruption imprévue et persistante, la prestation inappropriée ou défaillante et la fin inattendue de l’accord.
Les textes cités exigent une revue et un test périodiques, sans fixer dans ces dispositions un rythme uniforme pour tous les accords. La fréquence, la profondeur et la combinaison des scénarios doivent donc être justifiées par la criticité, l’impact, la substituabilité et l’évolution de la chaîne.
Un test utile produit un résultat falsifiable
Le test n’a pas besoin de provoquer une rupture de production pour être probant. Son périmètre et ses limites doivent en revanche être explicites. Un exercice peut, par exemple, isoler un jeu de données représentatif, utiliser le mécanisme d’export contractuel, restaurer le service dans un environnement alternatif et faire valider les fonctions essentielles par le métier.
| Étape | Contrôle à exécuter | Résultat à conserver |
|---|---|---|
| Scénario | Défaillance, interruption persistante, changement refusé ou résiliation | Hypothèses, périmètre, responsables et critères d’acceptation approuvés |
| Extraction | Récupérer données, configurations, journaux et documentation nécessaires | Horodatage, format, volume, contrôle d’intégrité et éléments manquants |
| Transfert | Charger les actifs chez un autre prestataire ou dans une solution interne | Scripts, erreurs, transformations, dépendances et temps observé |
| Remise en service | Rétablir identités, secrets, flux réseau, supervision et sauvegardes | Journaux techniques et contrôles de sécurité |
| Acceptation | Vérifier les opérations critiques et la qualité de service | Cas de test métier, résultat, réserves et décision de reprise |
| Clôture | Révoquer les accès devenus inutiles et traiter les résidus | Preuve de révocation, exceptions, actions correctives et prochaine échéance |
Les durées mesurées doivent être comparées aux objectifs de continuité, aux engagements contractuels et au calendrier du plan. Une durée théorique ou communiquée par le fournisseur ne remplace pas une observation. Si une migration complète est impossible ou disproportionnée, le dossier doit l’indiquer et préciser la partie testée, les contrôles compensatoires et le risque résiduel accepté.
Le Financial Stability Board propose lui aussi une gestion couvrant tout le cycle de la relation avec un tiers et la cartographie des concentrations jusque dans les chaînes de fourniture. Son cadre est un outil international flexible, pas une interprétation juridique de DORA. Il renforce néanmoins la cohérence opérationnelle d’une approche qui relie registre, suivi, continuité et sortie.
Un dossier de contrôle compact peut suffire
La matrice suivante est une proposition opérationnelle BLACKPROOF. Elle ne remplace ni les modèles du règlement d’exécution 2024/2956 ni les exigences propres de l’autorité compétente. Son rôle est de relier les informations déclaratives aux décisions et aux tests qui permettent de les défendre.
| Bloc | Pièces minimales | Critère de qualité |
|---|---|---|
| Périmètre | Fonction, entité utilisatrice, service ICT, criticité, accord | Une personne indépendante peut reconstituer la relation |
| Chaîne | Prestataire direct, rangs suivants, service soutenu, pays, données | Chaque inclusion ou exclusion importante est justifiée et datée |
| Risque | Interruption, concentration, substituabilité, auditabilité, géopolitique | Les hypothèses, sources et inconnues sont séparées |
| Contrat | Sous-traitance, notification, audit, restitution, résiliation, transition | La clause est reliée au contrat signé et à sa version en vigueur |
| Exploitation | Niveaux de service, incidents, changements, audits et actions | Les écarts conduisent à une décision, un responsable et une échéance |
| Sortie | Scénario, alternative, ressources, test, résultat et corrections | Le plan contient des observations, pas seulement des intentions |
| Gouvernance | Tolérance au risque, arbitrage, acceptation résiduelle et revue | Le décideur, la date, le périmètre et les réserves sont explicites |
La bibliothèque de preuves permet de structurer les pièces par nature et la dette de preuve aide à rendre visibles les affirmations qui restent insuffisamment étayées. La méthode ne consiste pas à accumuler des documents. Elle consiste à rendre chaque conclusion vérifiable, révisable et rattachée au bon service.
Quatre semaines pour reprendre le contrôle
Ce calendrier est une proposition de travail, pas un délai réglementaire.
Semaine 1 : partir des fonctions
- confirmer la liste des fonctions critiques ou importantes et leur propriétaire métier ;
- relier chaque fonction aux services ICT effectivement utilisés ;
- rapprocher les références contractuelles des identifiants présents dans le registre ;
- consigner les relations encore inconnues au lieu de les compléter par supposition.
Semaine 2 : parcourir les chaînes
- obtenir du prestataire direct les sous-traitants qui soutiennent effectivement chaque service critique ;
- documenter rangs, liens, pays de fourniture, lieux de traitement et catégories de données ;
- rechercher les concentrations communes à plusieurs services ou contrats ;
- dater la source de chaque information et le prochain événement de revue.
Semaine 3 : tester les leviers contractuels
- vérifier les droits de notification, d’objection, d’audit, de restitution, de résiliation et de transition ;
- comparer les clauses signées aux pratiques réelles du prestataire ;
- demander un export représentatif selon le mécanisme contractuel ;
- qualifier les écarts et les faire arbitrer par les équipes juridique, sécurité, achat et métier.
Semaine 4 : exécuter un test de sortie ciblé
- choisir un service dont l’impact et la substituabilité sont déjà évalués ;
- faire approuver le scénario, le périmètre et les critères d’acceptation ;
- exécuter l’extraction, le transfert et la validation métier sur un périmètre maîtrisé ;
- enregistrer les durées, les défauts, les décisions et la date du prochain test.
Limites et contresens à écarter
- « Le registre est remis une fois par an, donc une mise à jour annuelle suffit. » DORA impose de maintenir et mettre à jour le registre. La remise annuelle ne transforme pas une chaîne mouvante en photographie annuelle acceptable.
- « Tous les sous-traitants de tous les fournisseurs doivent être cartographiés sans limite. » Le modèle précise la profondeur attendue. Pour les fonctions critiques ou importantes, le critère porte sur les sous-traitants qui sous-tendent effectivement le service et dont l’interruption compromettrait sa sécurité ou sa continuité.
- « Le prestataire est sur la liste européenne, donc il est approuvé. » La désignation répond à des critères de criticité systémique et ouvre une surveillance. Elle ne certifie pas chaque service ni chaque contrat.
- « Une clause de portabilité vaut test de sortie. » La clause ouvre un droit. Le test établit si les formats, délais, dépendances et ressources permettent réellement de l’exercer.
- « Un autre fournisseur figure dans le registre, donc le service est substituable. » La substitution dépend aussi des données, de la technologie, des compétences, des coûts, des délais et des risques de migration.
- « L’intragroupe réduit naturellement le risque. » Le règlement 2024/1773 demande d’appliquer la politique aux prestataires ICT intragroupe. La proximité capitalistique ne supprime ni la dépendance technique ni les contraintes transfrontières.
- « DORA et NIS 2 produisent le même dossier. » Les textes peuvent se croiser, mais leurs périmètres, autorités et mécanismes ne sont pas identiques. Notre analyse NIS 2 détaille la qualification propre à cette directive.
BLACKPROOF peut relier attentes, pièces, réserves et décisions dans un dossier vérifiable. Sa méthode ne qualifie pas juridiquement une fonction, ne certifie pas un contrat et ne garantit pas qu’un plan de sortie réussira. Ces conclusions nécessitent les responsables métier, techniques, juridiques et de contrôle compétents.
Dix questions pour le prochain comité de résilience
- Quelle fonction critique ou importante dépend de quel service ICT, sous quel contrat ?
- Quel acteur fournit réellement chaque composant indispensable au-delà du fournisseur direct ?
- Quelle source établit la chaîne actuelle et quand a-t-elle été vérifiée ?
- Quels services partagent le même sous-traitant, la même région ou la même technologie propriétaire ?
- Quel changement matériel de sous-traitance avons-nous récemment approuvé, refusé ou laissé expirer ?
- Dans quel format récupérons-nous les données, configurations et journaux nécessaires à une sortie ?
- Quelle alternative a été identifiée et quelle partie de la migration a été réellement testée ?
- Combien de temps le dernier exercice a-t-il pris, et à quel objectif cette durée a-t-elle été comparée ?
- Quels écarts du dernier test restent ouverts, avec quel responsable et quelle échéance ?
- Quelle décision de risque résiduel a été prise lorsque la substitution complète n’était pas réaliste ?
Une organisation maîtrise sa dépendance lorsqu’elle peut répondre à ces questions avec des informations datées, des contrats en vigueur et des résultats observés. Le registre fournit l’ossature. La résilience apparaît dans les liens, les décisions et les tests.
État des textes et des sources vérifié le 21 juillet 2026. Cette analyse expose un cadre de travail documenté et ne constitue pas un avis juridique.