En une phrase. Depuis le 17 janvier 2025, le règlement DORA impose à toute entité financière de sécuriser ses contrats TIC par des clauses obligatoires fixées à l’article 30 : un socle commun pour tous les contrats (art. 30§2) et un régime renforcé — droits d’audit, participation aux tests, stratégie de sortie — pour les contrats supportant une fonction critique ou importante (art. 30§3), sous peine d’astreintes pouvant atteindre 1 % du chiffre d’affaires quotidien moyen mondial pour les prestataires tiers critiques (CTPP) supervisés directement par les autorités européennes.
Le pilier 4 de DORA (articles 28 à 44) est, dans la pratique, le plus lourd à mettre en œuvre : il ne s’agit plus de sécuriser son propre système d’information, mais de réécrire les contrats avec chaque fournisseur cloud, hébergeur, éditeur SaaS ou centre de données. L’ACPR et l’AMF, superviseurs français de DORA, examinent désormais ces clauses lors de leurs contrôles, au même titre que le registre d’informations. Une clause manquante ou mal rédigée n’est pas un détail administratif : c’est un manquement direct à un règlement européen d’application immédiate.
Ce guide détaille les exigences de l’article 30, la distinction entre les deux niveaux de clauses, la stratégie de sortie, le régime des prestataires critiques et l’articulation avec l’encadrement RGPD des sous-traitants.
Points clés
- L’article 30§2 fixe un socle de clauses obligatoires pour tous les contrats TIC, quelle que soit leur importance.
- L’article 30§3 ajoute un régime renforcé pour les contrats supportant une fonction critique ou importante : audit, tests, stratégie de sortie.
- La stratégie de sortie doit être documentée et testée, pas seulement rédigée pour la forme.
- Les prestataires tiers critiques (CTPP) sont désignés et supervisés directement par les autorités européennes de surveillance (AES), avec un pouvoir d’astreinte propre.
- Le régime recoupe fortement l’article 28 du RGPD, mais reste juridiquement distinct : deux finalités, deux registres, deux jeux de clauses.
1. Le pilier 4 de DORA : gérer le risque lié aux tiers TIC
Les articles 28 à 44 de DORA structurent la gestion du risque tiers TIC autour de quatre exigences posées par l’article 28 : une stratégie relative au risque tiers TIC validée par l’organe de direction, la tenue d’un registre d’informations exhaustif sur tous les contrats TIC, une analyse préalable à la contractualisation (due diligence sur le prestataire, évaluation du risque de concentration lorsque plusieurs fonctions critiques dépendent du même fournisseur), et une évaluation continue pendant toute la durée du contrat, et non plus seulement à la signature.
Le registre d’informations est le pivot documentaire de ce pilier : c’est lui qui permet à l’entité financière — et à son superviseur — de savoir quels contrats existent, lesquels supportent une fonction critique ou importante, et lesquels doivent donc respecter le régime renforcé de l’article 30§3. Sans registre à jour, impossible de savoir quels contrats revoir en priorité. Notre guide DORA France détaille l’ensemble des cinq piliers et la répartition de compétences entre ACPR et AMF.
2. Article 30 : les clauses contractuelles obligatoires
L’article 30 ne se contente pas de recommander des bonnes pratiques contractuelles : il impose un contenu minimal, avec deux niveaux d’exigence selon la nature du contrat.
2.1 Le socle commun de l’article 30§2
Pour tout contrat TIC, quelle que soit son importance, le contrat doit décrire précisément : les services fournis et leur périmètre, la localisation des données et des lieux de traitement (y compris en cas de sous-traitance), les engagements de disponibilité, intégrité, confidentialité et sécurité des données, les modalités de coopération en cas d’inspection ou d’audit, l’assistance du prestataire en cas d’incident TIC lié au service fourni, et les droits de résiliation avec un préavis suffisant pour permettre une transition ordonnée.
2.2 Le régime renforcé de l’article 30§3
Pour les contrats qui supportent une fonction critique ou importante, ce socle ne suffit pas. L’article 30§3 ajoute : des niveaux de service (SLA) complets et quantifiés, assortis d’objectifs de performance précis ; des droits d’accès, d’inspection et d’audit illimités de l’entité financière (ou d’un tiers mandaté) sur les locaux et systèmes du prestataire ; la participation du prestataire aux tests de résilience, y compris les tests de pénétration ; des stratégies de sortie documentées et éprouvées ; une obligation de coopération avec les autorités compétentes ; et un encadrement strict de la sous-traitance en cascade, c’est-à-dire des sous-traitants du prestataire lui-même.
| Exigence contractuelle | Art. 30§2 (tous les contrats TIC) | Art. 30§3 (fonctions critiques ou importantes) |
|---|---|---|
| Description des services et localisation des données | Obligatoire | Obligatoire (renforcée) |
| Sécurité, disponibilité, intégrité, confidentialité | Engagements généraux | Niveaux de service quantifiés (SLA complets) |
| Coopération / assistance en cas d’incident | Obligatoire | Obligatoire, avec délais précisés |
| Droits d’accès, d’inspection et d’audit | Non exigé | Obligatoire, accès illimité |
| Participation aux tests de résilience | Non exigé | Obligatoire |
| Stratégie de sortie documentée et testée | Non exigé | Obligatoire |
| Encadrement de la sous-traitance en cascade | Non exigé | Obligatoire |
| Droits de résiliation et préavis | Obligatoire | Obligatoire, avec conditions renforcées |
3. La stratégie de sortie : documenter, mais surtout tester
C’est l’exigence la plus souvent négligée. Une stratégie de sortie qui se limite à une clause de principe (“l’entité peut résilier le contrat”) ne satisfait pas l’article 30§3. DORA attend un plan opérationnel : identification des alternatives (autre prestataire, réinternalisation), estimation du délai et du coût de la migration, modalités de récupération des données dans un format exploitable, et — point clé — une mise à l’épreuve périodique de ce plan, au même titre qu’un plan de continuité d’activité ou un plan de reprise d’activité. Pour les entités désignées, cette logique de test rejoint celle des tests de pénétration fondés sur la menace (TLPT) : DORA ne veut pas de documentation statique, mais des dispositifs éprouvés dans des conditions proches du réel.
4. Prestataires tiers critiques (CTPP) : supervision directe et sanctions
Au-delà de la relation contractuelle bilatérale, DORA crée une catégorie de prestataires tiers critiques (CTPP) : des fournisseurs (essentiellement cloud) dont la défaillance mettrait en péril la stabilité du secteur financier européen. Ces prestataires sont désignés par les autorités européennes de surveillance (AES) selon des critères de dépendance systémique, puis supervisés directement au niveau européen, indépendamment de chaque contrat individuel. Les AES disposent d’un pouvoir d’astreinte propre, pouvant atteindre 1 % du chiffre d’affaires quotidien moyen mondial, par jour, pendant une durée maximale de six mois — un mécanisme de pression financière sans équivalent dans le RGPD ou dans NIS2. Pour l’entité financière cliente, la désignation d’un fournisseur comme CTPP ne dispense pas de ses propres obligations contractuelles : elle s’y ajoute.
5. DORA et RGPD : deux registres, deux finalités
La quasi-totalité des prestataires TIC visés par DORA (cloud, hébergement, SaaS) sont aussi des sous-traitants au sens du RGPD dès qu’ils traitent des données personnelles. Le réflexe naturel — fusionner les deux démarches — est une erreur. L’article 28 du RGPD encadre le traitement des données personnelles (finalités, durées, sécurité, sort des données en fin de contrat) tandis que l’article 30 de DORA encadre la résilience opérationnelle du service TIC lui-même (disponibilité, auditabilité, sortie). Ce sont deux corpus de clauses, deux registres — le registre des sous-traitants RGPD d’un côté, le registre d’informations DORA de l’autre — et souvent deux interlocuteurs différents chez le même fournisseur. La sous-traitance cloud illustre bien ce doublement : un même contrat d’hébergement doit désormais satisfaire simultanément l’article 28 RGPD et l’article 30 DORA, sans que l’un dispense de l’autre. Pour les données les plus sensibles, le recours à une offre qualifiée SecNumCloud simplifie une partie de la démonstration de sécurité, mais ne remplace pas la revue contractuelle article 30.
6. Checklist 2026 pour sécuriser vos contrats TIC
- Cartographier tous les contrats TIC dans le registre d’informations et identifier ceux qui supportent une fonction critique ou importante.
- Auditer chaque contrat existant au regard de la grille de l’article 30§2 (socle) puis 30§3 (renforcé) selon le cas.
- Négocier des avenants pour les clauses manquantes : localisation des données, droits d’audit, participation aux tests, sous-traitance en cascade.
- Rédiger et tester une stratégie de sortie pour chaque fonction critique ou importante.
- Vérifier le statut CTPP des principaux fournisseurs cloud et anticiper les conséquences d’une désignation.
- Séparer explicitement le suivi contractuel DORA du registre des sous-traitants RGPD, tout en croisant les deux pour éviter les doublons de négociation.
La difficulté, en pratique, c’est le volume : des dizaines de contrats à revoir, avec des clauses différentes selon qu’ils portent ou non une fonction critique. Legiscope permet de cartographier les fournisseurs et les contrats une seule fois, puis d’en dériver les registres RGPD et DORA, plutôt que de reconstruire deux bases indépendantes.
FAQ
L’article 30 s’applique-t-il à tous les contrats TIC, même les plus mineurs ?
Oui, au moins pour son socle commun (art. 30§2) : description des services, localisation des données, engagements de sécurité, coopération et droits de résiliation sont exigés pour tout contrat TIC. Le régime renforcé de l’art. 30§3 (audit, tests, stratégie de sortie) ne s’applique en revanche qu’aux contrats supportant une fonction critique ou importante, identifiée via l’analyse de risque préalable de l’article 28.
Que se passe-t-il si un contrat existant ne respecte pas l’article 30 ?
L’entité financière reste responsable devant son superviseur (ACPR ou AMF), même si le manquement provient de la rédaction du contrat par le prestataire. La priorité 2026 est donc d’auditer les contrats en cours et de négocier des avenants, en commençant par ceux qui supportent une fonction critique ou importante — ce sont eux que les superviseurs contrôlent en premier.
Un fournisseur cloud déjà conforme à l’article 28 du RGPD est-il automatiquement conforme à l’article 30 de DORA ?
Non. Les deux articles poursuivent des finalités différentes et ne se recoupent que partiellement. Un DPA RGPD solide traite la protection des données personnelles, pas les droits d’audit opérationnel, la participation aux tests de résilience ni la stratégie de sortie exigés par DORA. Les deux clauses doivent coexister dans — ou en annexe de — le même contrat.
Conclusion
L’article 30 de DORA transforme la gestion des fournisseurs TIC d’une pratique d’achat en une obligation réglementaire documentée, graduée selon la criticité du contrat. En 2026, les entités financières qui n’ont pas encore audité leurs contrats à l’aune du socle commun et du régime renforcé s’exposent à un constat de non-conformité dès le premier contrôle ACPR ou AMF — sans compter le risque, propre aux prestataires tiers critiques, d’astreintes journalières calculées sur le chiffre d’affaires mondial. La méthode qui fonctionne : cartographier, prioriser les fonctions critiques, négocier les avenants, tester la stratégie de sortie, et garder ce chantier distinct — mais coordonné — de la conformité RGPD des mêmes fournisseurs.
Legiscope automates this for you
Stop doing compliance manually. Legiscope's AI handles ROPA creation, DPA audits, and gap analysis — in minutes, not weeks.
Start free trial