La gestion des risques liés aux prestataires ICT tiers est sans doute le chapitre le plus transformateur du règlement DORA. Articles 28 à 44 — dix-sept articles entiers consacrés à un sujet que beaucoup d'établissements traitaient jusqu'ici avec une poignée de clauses standard et un tableur Excel mal maintenu.
Votre banque utilise combien de prestataires ICT ? Si vous répondez spontanément "une trentaine", vous êtes probablement loin du compte. Un audit récent dans une banque de taille intermédiaire en a recensé 287. Avec des chaînes de sous-traitance parfois sur quatre niveaux.
Ce que DORA change fondamentalement dans la gestion des tiers ICT
Avant DORA, la gestion des risques tiers reposait essentiellement sur les guidelines EBA/2019/02 sur l'externalisation et les recommandations EIOPA pour les assureurs. Des textes importants, mais avec deux limites majeures : ils n'avaient pas force de règlement, et ils ne couvraient pas l'ensemble des prestataires ICT (seulement ceux fournissant des services externalisés).
DORA élargit considérablement le périmètre. Tous les prestataires ICT tiers sont concernés — pas seulement ceux qui fournissent des services externalisés au sens strict. Votre fournisseur de licences logicielles, votre prestataire de maintenance réseau, votre éditeur de solution SIEM — tous entrent dans le champ.
Les trois niveaux d'exigences
| Niveau | Périmètre | Exigences principales |
|---|---|---|
| Base | Tous les prestataires ICT tiers | Registre d'informations, évaluation des risques, clauses contractuelles minimales |
| Renforcé | Prestataires supportant des fonctions critiques ou importantes | Clauses renforcées (article 30), droits d'audit étendus, plans de sortie, tests de sécurité |
| Supervision directe | Prestataires ICT désignés comme critiques par les AES | Contrôle direct par un superviseur principal, inspections, astreintes |
Le registre d'informations — colonne vertébrale de la conformité tiers
L'article 28(3) impose à chaque entité financière de tenir et maintenir un registre d'informations sur l'ensemble de ses accords contractuels avec des prestataires ICT tiers. Ce registre doit être disponible pour l'autorité compétente sur demande. Pour creuser ce sujet, consultez notre article dédié au registre d'informations DORA.
Que doit contenir le registre ?
Les RTS publiés par les AES en janvier 2024 détaillent le contenu attendu. En substance :
| Catégorie | Informations requises |
|---|---|
| Identification du prestataire | Raison sociale, LEI, juridiction, groupe d'appartenance |
| Nature du contrat | Type de service ICT, date de début/fin, renouvellement |
| Fonctions supportées | Description, classification critique/importante ou non |
| Sous-traitance | Chaîne complète de sous-traitance, juridictions |
| Localisation données | Pays de traitement et de stockage des données |
| Évaluation du risque | Résultat de la due diligence, risque de concentration |
| Stratégie de sortie | Plan de transition, délai de préavis, alternatives identifiées |
Un responsable conformité d'un assureur mutualiste me racontait que la constitution du registre avait pris huit mois à son équipe. Huit mois. Et encore, ils avaient déjà un inventaire partiel dans le cadre des guidelines EBA. Le point de blocage principal ? Obtenir les informations sur les chaînes de sous-traitance de chaque prestataire. Certains ont refusé de communiquer ces données, invoquant le secret commercial.
Les clauses contractuelles de l'article 30 — le cœur juridique
L'article 30 liste les clauses minimales que doit contenir tout contrat avec un prestataire ICT tiers. C'est probablement la disposition qui génère le plus de travail opérationnel, parce qu'elle implique de revoir — et souvent renégocier — l'ensemble du parc contractuel.
Clauses obligatoires pour TOUS les contrats ICT
Description claire et complète des services fournis. Lieux de traitement des données. Dispositions sur la disponibilité, l'authenticité, l'intégrité et la confidentialité des données. Obligations de notification d'incidents. Droits de résiliation. Dispositions de sortie — avec période de transition suffisante et assistance à la migration.
Clauses supplémentaires pour les fonctions critiques ou importantes
Quand le contrat porte sur une fonction critique, les exigences montent d'un cran :
Niveaux de service précis et mesurables. Droits d'audit illimités — y compris inspection sur site du prestataire et de ses sous-traitants. Obligation pour le prestataire de participer aux tests de résilience de l'entité financière, y compris les TLPT. Stratégie de sortie détaillée avec plan de transition, délais et coûts. Encadrement strict de la sous-traitance — avec droit de véto de l'entité financière sur les sous-traitants critiques.
Concrètement, combien de contrats cloud actuels incluent un droit d'audit illimité sur les datacenters du fournisseur ET de ses sous-traitants ? Très peu. Et les hyperscalers ne sont pas exactement enthousiastes à l'idée d'ouvrir leurs portes à chaque client individuellement. D'où l'émergence de mécanismes de pooled audits — des audits mutualisés entre plusieurs entités financières.
La question de la concentration des risques
DORA aborde frontalement un sujet que le régulateur évitait jusque-là : la concentration des risques chez quelques prestataires ICT dominants. Quand trois hyperscalers hébergent la majorité des infrastructures critiques du secteur financier européen, une panne chez l'un d'eux devient un risque systémique.
L'article 29 impose aux entités financières d'évaluer le risque de concentration dans leur portefeuille de prestataires ICT. Est-ce que 80% de vos services cloud sont chez le même fournisseur ? Est-ce que votre prestataire de middleware est irremplaçable ? Quelles alternatives existent si votre principal fournisseur fait défaut ?
Les autorités compétentes peuvent, sur la base du registre d'informations agrégé, identifier des situations de concentration à l'échelle du marché et prendre des mesures pour réduire ce risque.
La supervision directe des prestataires ICT critiques — une première mondiale
Les articles 31 à 44 instituent un mécanisme sans précédent : la supervision directe de prestataires technologiques par des autorités de régulation financière. Jusqu'ici, un hyperscaler n'avait aucun régulateur financier en face. DORA change la donne.
Comment un prestataire est-il désigné comme critique ?
Les AES évaluent plusieurs critères définis dans les RTS du lot 2 (juillet 2024) :
| Critère | Indicateurs |
|---|---|
| Impact systémique | Nombre d'entités financières dépendantes, part de marché |
| Substituabilité | Existence d'alternatives, coûts de migration, complexité technique |
| Interconnexion | Dépendances croisées, chaînes de sous-traitance |
| Importance des fonctions supportées | Fonctions critiques ou importantes des entités clientes |
Le superviseur principal — l'une des trois AES (EBA, EIOPA ou ESMA selon la nature des entités clientes) — dispose de pouvoirs étendus. Il peut demander des informations, réaliser des inspections générales et sur site, émettre des recommandations et, surtout, imposer des astreintes allant jusqu'à 1% du chiffre d'affaires mondial journalier moyen en cas de non-coopération.
Pour comprendre en détail le mécanisme de désignation, consultez notre article sur les prestataires ICT critiques DORA.
Stratégie de sortie — anticiper l'impensable
DORA exige des plans de sortie pour chaque prestataire supportant une fonction critique. Pas un document théorique rédigé pour cocher une case — un plan opérationnel testé, avec des scénarios précis.
Les composantes d'une stratégie de sortie conforme
Identification de prestataires alternatifs ou de solutions internes. Estimation réaliste des délais de migration (souvent sous-estimés — une migration cloud complexe peut prendre 12 à 18 mois). Calcul des coûts de transition. Mesures de continuité pendant la période de transition. Plan de récupération des données avec formats et délais garantis. Tests périodiques du plan de sortie.
Un DSI de banque privée m'expliquait qu'il avait découvert, en préparant son plan de sortie, que migrer hors de son fournisseur de core banking nécessiterait 24 mois minimum et un budget de 15 millions d'euros. Autant dire que le choix initial du prestataire revêt désormais une importance stratégique qu'on ne mesurait pas forcément avant.
Bonnes pratiques — ce que font les établissements les plus avancés
1. Centraliser la gouvernance tiers
Les établissements qui s'en sortent le mieux ont créé une fonction dédiée à la gestion des risques tiers ICT, rattachée au RSSI ou au CRO. Cette fonction centralise l'évaluation, le suivi et le reporting de l'ensemble du portefeuille de prestataires.
2. Automatiser le registre
Un registre Excel ne tient pas à l'échelle. Les outils de Third-Party Risk Management (TPRM) comme ServiceNow VRM, OneTrust ou Prevalent permettent d'automatiser la collecte, la mise à jour et le reporting. Le coût de licence est significatif, mais le gain de temps et la fiabilité justifient l'investissement.
3. Mutualiser les audits
Les pooled audits permettent de partager les coûts d'audit entre plusieurs entités financières clientes d'un même prestataire. Certains prestataires cloud proposent désormais des rapports SOC 2 Type II enrichis intégrant les exigences spécifiques de DORA — une bonne base, mais qui ne dispense pas du droit d'audit individuel.
4. Intégrer la due diligence ICT dans les achats
La due diligence DORA ne doit pas être un exercice ex post. Elle doit être intégrée dans le processus d'achat dès la phase de sélection. Grille d'évaluation standardisée, questionnaire de sécurité aligné sur les exigences DORA, vérification des certifications (ISO 27001, SOC 2, C5 pour les prestataires cloud allemands).
Les écueils les plus fréquents
Après avoir accompagné plusieurs établissements dans leur mise en conformité, voici les erreurs récurrentes.
Sous-estimer le périmètre. DORA couvre TOUS les prestataires ICT, pas seulement les externalisations critiques. Le fournisseur de votre solution de visioconférence, votre outil de ticketing, votre plateforme de signature électronique — tous entrent dans le registre.
Traiter le registre comme un one-shot. Le registre doit être maintenu à jour en continu. Chaque nouveau contrat, chaque renouvellement, chaque changement de sous-traitant doit être reflété.
Ignorer la sous-traitance en cascade. Votre prestataire héberge ses données chez un hyperscaler qui lui-même utilise des datacenters d'un tiers ? Cette chaîne doit être documentée.
Négliger les plans de sortie. Rédiger un plan de sortie théorique ne suffit pas. Il doit être réaliste, chiffré, et idéalement testé.
FAQ — Gestion des risques ICT tiers sous DORA
Les prestataires ICT intra-groupe sont-ils exemptés ?
Non. Les accords intra-groupe doivent figurer dans le registre et respecter les mêmes exigences contractuelles. DORA prévoit toutefois des dispositions spécifiques pour les accords intra-groupe (article 29(2)).
Que faire si un prestataire refuse de modifier son contrat ?
C'est un cas de figure fréquent, notamment avec les grands éditeurs de logiciels. L'entité financière doit documenter ses efforts de négociation et évaluer si le risque résiduel est acceptable. Si la fonction est critique et que le contrat n'est pas conforme, le régulateur pourrait exiger un changement de prestataire.
Le registre doit-il être certifié ?
Non — il n'y a pas de certification requise. Mais le registre doit être fiable, complet et actualisé. L'autorité compétente peut le demander à tout moment et vérifier sa conformité avec les RTS.
Comment gérer les prestataires ICT hors UE ?
DORA ne les exclut pas. Les obligations contractuelles de l'article 30 s'appliquent indépendamment de la localisation du prestataire. La localisation des données fait l'objet de dispositions spécifiques, et le risque pays doit être évalué dans la due diligence. Pour les prestataires critiques hors UE, le mécanisme de supervision directe peut s'appliquer via des filiales ou succursales européennes.
La gestion des tiers ICT est probablement le chantier le plus lourd de DORA. Mais c'est aussi celui qui apporte le plus de valeur — au-delà de la conformité, c'est une vraie opportunité de rationaliser son portefeuille de prestataires et de réduire des risques jusqu'ici mal identifiés. Pour situer DORA dans le paysage réglementaire plus large, notre guide complet du règlement DORA offre une vue d'ensemble.