Risque lié aux tiers TIC selon DORA : quand un fournisseur d'IA devient un prestataire TIC critique

Le risque lié aux tiers TIC selon DORA désigne l'obligation pour les entités financières de gérer activement les risques découlant de services TIC externalisés. En vertu du règlement (UE) 2022/2554 (DORA, applicable depuis le 17 janvier 2025), les fournisseurs d'IA et de LLM peuvent être considérés comme des prestataires tiers de services TIC. L'entité financière qui les utilise doit alors les encadrer conformément aux articles 28 à 30 : registre d'informations, exigences contractuelles, gestion du risque de concentration. Si les Autorités européennes de surveillance (AES : EBA, EIOPA, ESMA) qualifient un prestataire de critique, celui-ci relève lui-même du cadre de supervision prévu aux art. 31 et suivants.

• Qui est concerné ? DORA s'adresse aux entités financières (notamment les établissements CRR et les assureurs soumis à Solvabilité II), pas directement aux fournisseurs d'IA. Le service d'IA est couvert par le biais de l'entité financière.
• Pourquoi l'IA ? Le guide d'orientation de la BaFin du 18 décembre 2025 classe les systèmes d'IA comme une sous-catégorie des « réseaux et systèmes d'information » au sens de l'art. 3, point 2, de DORA et fait ainsi entrer l'ensemble des obligations DORA dans la gouvernance de l'IA.
• L'obligation centrale d'abord : chaque service TIC fourni sous contrat, y compris un service de LLM utilisé en production, doit figurer dans le registre d'informations mis à la disposition des autorités de surveillance.

Pourquoi les fournisseurs d'IA/LLM deviennent des prestataires de services TIC

DORA ne réglemente pas l'IA en tant que technologie, mais la résilience opérationnelle numérique des entités financières. Le levier décisif est la définition large des services TIC et des réseaux et systèmes d'information. Dès qu'une entité financière utilise en production un service d'IA, par exemple un modèle de langage hébergé, une API de scoring de fraude ou un assistant documentaire dans le cloud, ce service fait partie de son risque lié aux tiers TIC.

Le guide d'orientation de la BaFin sur les risques TIC liés à l'utilisation de l'IA dans les entités financières du 18 décembre 2025 rend ce lien explicite dans la pratique de supervision allemande : les systèmes d'IA sont une sous-catégorie des « réseaux et systèmes d'information » au sens de l'art. 3, point 2, de DORA. Dès lors, les charges de travail reposant sur l'IA sont soumises aux obligations DORA relatives à la gestion du risque lié aux TIC (art. 5–15), aux tests de résilience, y compris les tests de pénétration fondés sur la menace (art. 24–27), ainsi qu'au risque lié aux tiers TIC (art. 28–30). Selon ses propres termes, ce guide est une aide non contraignante et ne définit pas d'attentes prudentielles. Il vise à aider les entités financières à mettre en œuvre les exigences de DORA lorsqu'elles recourent à l'IA. Il s'adresse principalement aux établissements CRR et aux assureurs soumis à Solvabilité II.

Conséquence pratique : un fournisseur d'IA ne relève pas « automatiquement » de DORA. Le service est couvert par le biais de l'entité financière qui l'utilise, et celle-ci doit encadrer son prestataire, le lier contractuellement et documenter la relation de manière à pouvoir satisfaire aux exigences de DORA.

Le registre d'informations (Register of Information)

L'instrument central de pilotage du risque lié aux tiers TIC est le registre d'informations. Les entités financières doivent tenir un inventaire complet de tous les accords contractuels portant sur des services TIC et le mettre à la disposition des autorités de surveillance compétentes. Ce registre indique quelle fonction un service soutient, s'il soutient une fonction critique ou importante, qui est le prestataire et quels sous-traitants interviennent.

Pour l'IA, cela signifie qu'un service de LLM ou de ML utilisé en production n'est pas un « outil financé par le budget marketing », mais un service TIC soumis à inscription au registre dès lors qu'il correspond à une externalisation contractuelle. Le registre constitue en outre la base de données qui permet aux AES de repérer les prestataires si répandus dans le secteur qu'ils doivent être qualifiés de critiques.

Prestataires tiers critiques de services TIC (CTPP) et cadre de supervision

DORA instaure un cadre de supervision propre (Oversight Framework) pour les prestataires tiers critiques de services TIC (Critical ICT Third-Party Providers, CTPP). Il figure aux art. 31 et suivants et se distingue donc des obligations des entités financières prévues aux art. 28 à 30. Le 18 novembre 2025, les AES ont désigné pour la première fois 19 CTPP, dont AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix et Bloomberg (liste des AES).

Après leur désignation, ces prestataires sont soumis à une surveillance directe au niveau de l'UE. Pour chaque CTPP, l'une des trois AES (EBA, EIOPA ou ESMA) est compétente en tant que superviseur principal, ou Lead Overseer (art. 31, paragraphe 1, point b). Elle est assistée d'une équipe d'examen conjointe (Joint Examination Team, art. 40) et peut émettre des recommandations (art. 35). Ces recommandations ne sont pas juridiquement contraignantes. Le prestataire doit toutefois indiquer dans un délai de 60 jours calendaires s'il entend les suivre, ou expliquer pourquoi il ne le fait pas. En l'absence de réponse ou si l'explication est insuffisante, le superviseur principal le rend public. En dernier recours, les autorités de surveillance nationales peuvent obliger les entités financières à suspendre l'utilisation du service (art. 42).

Point important pour le débat sur l'IA : la plupart des charges de travail d'IA/LLM en production tournent aujourd'hui sur des hyperscalers désignés comme AWS, Microsoft Azure ou Google Cloud. Même si une startup d'IA n'est pas (encore) désignée elle-même comme CTPP, elle repose souvent techniquement sur un prestataire désigné. La surveillance de l'hyperscaler sous-jacent ne change rien à la responsabilité propre de l'entité financière en matière d'externalisation, de capacité de sortie et de risque de concentration.

Quand un prestataire est considéré comme critique

Les AES désignent selon quatre critères de l'art. 31, paragraphe 2, de DORA : l'impact systémique d'une défaillance à grande échelle sur les services financiers, l'importance systémique des entités financières dépendantes (par exemple les établissements d'importance systémique mondiale et les autres établissements d'importance systémique, EISm et autres EIS), la dépendance des fonctions critiques ou importantes à l'égard du prestataire et la substituabilité. Le règlement délégué (UE) 2024/1502 en fait une procédure en deux étapes. À l'étape 1, un prestataire doit atteindre tous les seuils quantitatifs. L'un d'eux : il soutient des fonctions critiques ou importantes chez au moins 10 % des entités financières d'une catégorie, et celles-ci détiennent ensemble au moins 10 % des actifs de cette catégorie. Seul un prestataire qui atteint tous les seuils fait l'objet d'une évaluation qualitative à l'étape 2. Les données proviennent des registres d'informations des entités financières.

Aucun prestataire dont le cœur de métier est constitué de modèles d'IA, comme OpenAI, Anthropic ou Mistral, ne figure sur la première liste. Notre analyse : les purs fournisseurs d'IA et de LLM atteignent rarement les seuils à l'heure actuelle, car leurs services soutiennent encore peu de fonctions critiques ou importantes dans les banques et chez les assureurs, et sont souvent achetés via les plateformes des hyperscalers. Un prestataire qui ne figure pas sur la liste peut, en vertu de l'art. 31, paragraphe 11, demander lui-même à être désigné comme critique. Les prestataires de services TIC intragroupe et les prestataires qui opèrent dans un seul État membre pour des entités financières actives uniquement dans cet État ne sont pas désignés (art. 31, paragraphe 8).

Risque de concentration et stratégie de sortie

Le risque de concentration est particulièrement marqué dans le contexte de l'IA. Si presque toutes les banques de l'UE dépendent, pour leurs charges de travail d'IA, de l'un des rares hyperscalers désignés ou de solutions centralisées de leur réseau bancaire, il en résulte une concentration systémique. DORA exige donc que les entités financières gèrent activement leur dépendance. Avant de conclure un contrat de services TIC pour des fonctions critiques ou importantes, elles vérifient si le prestataire est difficilement remplaçable ou si les contrats s'accumulent chez un même prestataire (art. 29). Pour ces services, il leur faut des stratégies de sortie. Les plans de sortie doivent être complets et documentés, et suffisamment testés et réexaminés régulièrement (art. 28, paragraphe 8). DORA ne fixe pas de fréquence précise pour cela, contrairement aux plans de continuité des activités de TIC, qui doivent être testés au moins une fois par an (art. 11, paragraphe 6).

En pratique, une architecture d'IA multicloud systématique reste en 2026 exigeante sur les plans technique et commercial. Entre un plan de sortie sur le papier et un changement de prestataire réellement réalisable, il y a donc souvent un fossé.

Exigences en matière d'externalisation et de contrats (art. 30)

L'art. 30 de DORA définit un ensemble obligatoire de clauses contractuelles pour les services TIC. Pour ces services, les art. 28–30 de DORA priment ainsi sur les orientations de l'EBA relatives à l'externalisation (EBA/GL/2019/02) et sur les orientations correspondantes de l'ESMA. Éléments clés des clauses :

• Description des services avec les conditions applicables au recours à des sous-traitants (sous-traitants ultérieurs) (paragraphe 2, point a)
• Lieux de prestation des services et de traitement des données, y compris le lieu de stockage, et information préalable en cas de changements prévus (paragraphe 2, point b)
• Descriptions des niveaux de service (paragraphe 2, point e), assorties d'objectifs de performance quantitatifs et qualitatifs précis pour les fonctions critiques ou importantes (paragraphe 3, point a)
• Droits de résiliation (paragraphe 2, point h) et, pour les fonctions critiques ou importantes, des stratégies de sortie avec une période de transition obligatoire (paragraphe 3, point f)
• Pour les fonctions critiques ou importantes, des droits d'accès, d'inspection et d'audit illimités pour les entités financières et l'autorité de surveillance (paragraphe 3, point e)

DORA n'impose pas expressément d'engagements en matière de latence ou de capacité de calcul. Si tu en as besoin, cela découle des objectifs de performance de la fonction concernée.

À notre avis, ces clauses relèvent largement du texte standard chez les hyperscalers, mais constituent un point de blocage fréquent dans les achats avec les startups d'IA. Pour les fournisseurs d'IA dépourvus de droits d'audit solides, de transparence sur les sous-traitants ultérieurs et de lieux de traitement documentés, le processus de sélection auprès des entités financières de l'UE s'arrête souvent avant le dernier tour.

Vue d'ensemble : obligation, entités concernées, base juridique

Exemple pratique : assistant LLM dans une banque régionale

Une banque de taille moyenne déploie un assistant de connaissances interne basé sur un LLM, qui fonctionne via l'API d'un fournisseur d'IA lui-même hébergé sur Microsoft Azure. Étapes pertinentes au regard de DORA :

1. Classer : l'assistant soutient-il une fonction critique ou importante ? Si oui, les exigences se renforcent.
2. Enregistrer : le contrat et le service sont inscrits au registre d'informations, y compris le sous-traitant Azure (CTPP désigné).
3. Sécuriser le contrat (art. 30) : droits d'audit, stratégie de sortie avec période de transition, conditions applicables aux sous-traitants, lieux définis de prestation des services et de traitement des données (ici, la banque choisit l'UE) et SLA avec des objectifs de performance quantitatifs.
4. Évaluer le risque de concentration : une fonction critique repose-t-elle sur un seul hyperscaler ? Documenter le plan de sortie et le tester régulièrement.
5. Processus de gestion des incidents : les incidents majeurs liés aux TIC touchant le service, par exemple des citations réglementaires hallucinées constituant un événement significatif de risque opérationnel, doivent être notifiés au titre de DORA.

Pseudocode de la logique de gouvernance :

```
si service_IA.est_externalisation_contractuelle:
Registre.inscrire(service_IA, sous_traitants_ulterieurs=[Hyperscaler])
si service_IA.soutient_fonction_critique:
Contrat.verifier(clauses_Art30) # audit, sortie, SLA, sous-traitants
PlanSortie.tester(intervalle="régulier")
RisqueConcentration.evaluer(prestataire, fonction)
Incident.activer_circuit_notification(gravite="majeur")
```

Les références aux articles renvoient au texte du règlement DORA, le statut de CTPP à la liste des AES du 18 novembre 2025. Cet article ne constitue pas un conseil juridique ; savoir si et comment DORA s'applique à un service d'IA donné exige un examen au cas par cas par un conseil juridique et réglementaire spécialisé.

Pour les agences et les décideurs B2B

Pour les agences marketing et les prestataires qui fournissent des fonctionnalités d'IA à des banques, des assureurs ou d'autres entités financières, DORA est un critère commercial décisif, pas un détail. Si tu veux vendre des solutions basées sur des LLM au secteur financier réglementé, intègre dès le départ l'auditabilité, la transparence sur les sous-traitants ultérieurs, la résidence des données dans l'UE et une voie de sortie solide, sinon le projet échouera non pas sur la qualité du modèle, mais au stade des achats. Blck Alpaca t'accompagne dans la conception de workflows d'IA conformes à DORA et dans leur ancrage dans les processus d'externalisation et de gestion des fournisseurs, pour que ton initiative d'IA dans le secteur financier atteigne au moins le dernier tour de sélection. L'examen juridique au cas par cas, tu le demandes en complément à un conseil spécialisé.