CUSTOR 28 · Note réglementaire n° 005 · Lecture 4 min

Externaliser un service TIC ne transfère jamais la responsabilité réglementaire

« C'est notre prestataire cloud qui gère. » Cette phrase, fréquente et rassurante, repose sur une erreur de droit. Externaliser un service ne déplace pas l'obligation réglementaire — il l'élargit.

Version : 1.0
État du droit : 27 juin 2026
Dernière vérification des sources : 27 juin 2026
Statut : Document susceptible d'évoluer en fonction des publications officielles au Journal officiel de l'Union européenne (JOUE).

Méthodologie

Cette analyse distingue systématiquement :

Cette note porte sur le régime des prestataires tiers de services TIC au sens de DORA (articles 28 à 30), applicable depuis le 17 janvier 2025. Le principe de responsabilité finale qu'elle décrit est propre à DORA, mais il rejoint un principe de gouvernance plus ancien, posé par les orientations EBA sur l'externalisation. Les deux régimes ne se confondent pas : DORA est le cadre de référence pour les services TIC des entités financières régulées. C'est ce cadre qui fait foi ici.

Le malentendu qu'il faut lever

Quand un incident survient chez un prestataire cloud, le réflexe est compréhensible : ce n'est pas nous, c'est eux. Juridiquement, ce réflexe est faux. Et il est faux de manière structurante, parce qu'il touche à la nature même de la responsabilité réglementaire.

DORA pose un principe que rien ne vient atténuer : l'entité financière reste, en dernier ressort, responsable du respect de ses obligations. Autrement dit : vous pouvez confier l'exécution. Vous ne pouvez pas confier la conformité.

Est-ce que cette note vous concerne ?

Oui, si votre établissement a recours à un ou plusieurs prestataires tiers de services TIC — cloud, hébergement, infrastructure, logiciels critiques — pour soutenir tout ou partie de ses fonctions critiques ou importantes. C'est le cas de la quasi-totalité des entités financières régulées, quelle que soit leur taille.

Si votre établissement considère qu'un risque est « géré » du simple fait qu'il est externalisé, cette note vous concerne directement.

Ce qui est juridiquement acquis aujourd'hui

Le Règlement délégué (UE) 2025/532 de la Commission du 24 mars 2025, adopté sur le fondement de l'article 30(5), quatrième alinéa, de DORA, précise les éléments qu'une entité financière doit déterminer et évaluer lorsqu'elle autorise la sous-traitance de services TIC soutenant des fonctions critiques ou importantes. Il confirme explicitement que le recours aux résultats de l'évaluation des risques menée par le prestataire tiers de services TIC sur ses propres sous-traitants ne limite pas la responsabilité finale de l'entité financière de se conformer à ses obligations légales et réglementaires sous DORA.

Les orientations EBA sur l'externalisation (EBA/GL/2019/02) portent le même principe côté gouvernance : l'externalisation ne saurait entraîner la délégation des responsabilités de l'organe de direction.

Le point réellement mal compris : trois conséquences concrètes

Première conséquence : la responsabilité ne descend pas la chaîne, elle remonte. Votre prestataire TIC s'appuie sur un sous-traitant, qui s'appuie lui-même sur un autre. Chaque maillon ajoute une dépendance — mais aucun n'absorbe votre obligation. DORA exige que vous puissiez identifier et surveiller les sous-traitants qui soutiennent vos fonctions critiques, jusqu'au bout de la chaîne. Plus vous externalisez, plus votre périmètre de responsabilité s'étend. Il ne se réduit jamais.

Plus vous externalisez l'exécution, plus vous devez renforcer votre gouvernance. Jamais l'inverse.

Deuxième conséquence : « gérer » un prestataire a un sens contractuel précis. Dire « notre prestataire gère » ne suffit pas si le contrat ne le prouve pas. DORA (article 30) impose des clauses précises : droits d'accès et d'audit, niveaux de service mesurables, obligations de notification d'incident, conditions de sous-traitance, plans de réversibilité et de sortie. Un service souscrit sans ces clauses n'est pas un risque « géré » — c'est un risque non couvert, dont vous restez comptable.

Troisième conséquence : le jour d'un contrôle, c'est vous qu'on interroge, pas votre prestataire. L'autorité ne convoque pas votre hébergeur. Elle vous demande, à vous, de démontrer que vous saviez ce qui était externalisé, que vous l'aviez encadré contractuellement, et que vous étiez en mesure de le surveiller. La défaillance du prestataire peut expliquer un incident. Elle n'excuse jamais l'absence de dispositif chez vous.

À retenir

Vous pouvez externaliser l'exécution. Vous ne pouvez jamais externaliser la responsabilité.

La vérité qui survit aux évolutions

L'externalisation est un transfert d'exécution, pas un transfert d'obligation. Le cloud héberge vos données ; il n'héberge pas votre conformité. Et plus la chaîne de dépendances s'allonge, plus la question décisive se déplace — non pas qui exécute le service ?, mais pouvez-vous démontrer que vous le maîtrisez ?

Le jour où tout fonctionne, votre prestataire délivre un service. Le jour où tout s'arrête, c'est votre gouvernance que l'autorité évaluera.

Les questions à vous poser

Si, à l'issue de cette lecture, vous ne pouvez pas répondre avec certitude aux questions suivantes, votre dispositif de gouvernance des prestataires mérite probablement une revue :

  1. Vos contrats avec vos prestataires TIC critiques contiennent-ils les clauses exigées par l'article 30 (droits d'audit, niveaux de service, notification d'incident, réversibilité) ?
  2. Savez-vous identifier les sous-traitants de rang 2 ou plus qui soutiennent, de fait, vos fonctions critiques ou importantes ?
  3. Votre due diligence avant contractualisation évalue-t-elle les capacités techniques, opérationnelles et financières du prestataire, conformément au Règlement délégué (UE) 2025/532 ?
  4. Pourriez-vous démontrer, sans le concours de votre prestataire, que vous surveillez activement le risque externalisé ?
  5. Votre organe de direction a-t-il conservé, en pratique et pas seulement sur le papier, la responsabilité de ces dispositifs d'externalisation ?

Sources réglementaires

Les échéances et statuts mentionnés dans ce document reflètent l'état du droit à la date de dernière vérification indiquée en tête. Ils sont susceptibles d'évoluer dès publication de textes officiels au JOUE.

Auteur : Boumediene Fergani
Fondateur de CUSTOR 28. 15 ans d'expérience en paiements, réglementation bancaire et transformation des systèmes financiers (ISO 20022, moteurs de paiement, conformité DORA & AI Act).

Version 1.0 · Dernière vérification : 27 juin 2026
Sources officielles : EUR-Lex / Commission européenne.