Le règlement DORA est applicable depuis le 17 janvier 2025. La plupart des entités financières ont traité le volet sécurité : tests de résilience, gestion des incidents, gouvernance.
Le volet contractuel, lui, est souvent le moins avancé. C’est pourtant celui qui expose le plus directement votre conformité à un contrôle documentaire.
Note de cadrage : cet article décrit des obligations réglementaires sous l’angle de leur impact sur la gestion contractuelle. Il ne constitue pas un avis juridique. Le texte de référence est le règlement (UE) 2022/2554.
Ce que DORA exige de vos contrats
DORA ne se limite pas à demander des contrats « solides » avec vos prestataires de services TIC. Le règlement formule deux exigences contractuelles précises.
Un registre d’information complet et actualisé
L’article 28 impose de tenir un registre d’information recensant tous les accords contractuels portant sur l’utilisation de services TIC fournis par des prestataires tiers. Ce registre distingue les services qui soutiennent des fonctions critiques ou importantes des autres.
Les autorités de supervision peuvent demander ce registre. Concrètement, vous devez être capable de produire, sur demande, une vue exhaustive et à jour de vos contrats TIC, avec leur qualification.
Des clauses contractuelles obligatoires
L’article 30 liste les dispositions que les contrats avec les prestataires TIC doivent contenir : description complète des services, localisation des données, niveaux de service, obligations d’assistance en cas d’incident, droits d’accès et d’audit, conditions de résiliation, et stratégies de sortie pour les fonctions critiques ou importantes.
Ces clauses ne sont pas des recommandations. Leur absence constitue un écart de conformité identifiable par simple lecture du contrat.
Où en est la supervision en 2026
Le dispositif est entré dans sa phase opérationnelle. Les autorités nationales compétentes, en France l’ACPR ou l’AMF selon votre statut, collectent les registres d’information pour le compte des autorités européennes de surveillance. Les premières campagnes de remise ont eu lieu en 2025, sur la base de modèles normalisés qui imposent un format précis, champ par champ.
Cette normalisation change la nature de l’exercice. Un registre tenu dans un tableur approximatif ne passe pas les contrôles de cohérence automatisés appliqués aux remises. Les rejets pour données incomplètes ou incohérentes se traitent dans des délais courts, ce qui transforme chaque campagne de remise en test de la qualité réelle de votre référentiel contractuel.
La collecte sert aussi un objectif européen : désigner les prestataires TIC critiques qui feront l’objet d’une supervision directe. Vos données contractuelles alimentent ce mécanisme. Leur exactitude n’est donc pas qu’un enjeu interne.
La proportionnalité ne vous dispense pas du registre
Le règlement applique un principe de proportionnalité : les exigences sont modulées selon la taille, le profil de risque et la nature des activités. Les plus petites entités bénéficient d’aménagements réels sur certains volets.
Mais ne confondez pas allégé et optionnel. Le registre d’information et les clauses contractuelles de l’article 30 constituent le socle commun. Une entité de taille modeste avec quarante contrats TIC doit les connaître, les qualifier et les tenir à jour, exactement comme un grand groupe. Seule l’ampleur du chantier change.
Pourquoi c’est un problème de gestion contractuelle avant d’être un problème juridique
Relisez les deux exigences. Aucune ne demande de rédiger de meilleurs contrats. Les deux demandent de savoir ce que contiennent vos contrats existants, en permanence.
C’est là que la plupart des organisations butent. Le scénario type : les contrats TIC sont dispersés entre les achats, la DSI et le juridique. Personne ne sait combien il y en a. La qualification « fonction critique ou importante » n’est documentée nulle part. Vérifier la présence des clauses de l’article 30 exige de relire chaque contrat un par un.
Une entité avec 150 contrats TIC actifs, à raison d’une à deux heures de relecture et de qualification par contrat, fait face à 150 à 300 heures de travail juridique. Pour la seule constitution initiale du registre. Avant toute mise à jour.
Le problème n’est pas l’exigence réglementaire. C’est l’absence de visibilité sur le portefeuille contractuel qui la rend coûteuse.
La démarche en quatre temps
1. Inventorier les contrats TIC
Recensez tous les accords portant sur des services TIC : hébergement, logiciels, infogérance, télécommunications, services de données. Incluez les contrats signés par des entités ou directions différentes. Le registre exigé est consolidé. La méthode est celle d’un référentiel de contrats unique.
2. Qualifier les fonctions critiques ou importantes
Pour chaque contrat, documentez si le service soutient une fonction critique ou importante au sens du règlement. Cette qualification conditionne le niveau d’exigence contractuelle applicable, notamment les stratégies de sortie. Elle rejoint la cartographie des risques fournisseurs.
3. Auditer les clauses contre l’article 30
Vérifiez contrat par contrat la présence des dispositions obligatoires. Tracez les écarts dans une matrice : contrat, clause manquante, criticité, action de remédiation. Cette matrice devient votre plan de mise en conformité. C’est un cas d’application directe de l’audit de contrats.
4. Organiser la mise à jour continue
Le registre n’est pas un livrable ponctuel. Chaque nouveau contrat TIC, chaque avenant, chaque résiliation doit l’alimenter. Sans processus d’actualisation intégré au cycle de vie de vos contrats, le registre est obsolète six mois après sa création. Concrètement : des champs structurés dans votre référentiel (type de service, criticité, localisation des données, échéances), une alerte sur chaque renouvellement, et une règle simple qui conditionne la signature de tout avenant TIC à la mise à jour du registre.
Les quatre pièges classiques du registre
La granularité insuffisante
Un accord-cadre avec un grand fournisseur couvre souvent plusieurs services distincts : hébergement, support, licences. Le registre attend une description par service, pas une ligne par fournisseur. Un recensement mené au niveau du seul accord-cadre devra être repris.
Les chaînes de sous-traitance ignorées
Votre prestataire de rang 1 sous-traite une partie du service. Pour les fonctions critiques ou importantes, vous devez documenter cette chaîne. C’est l’angle mort le plus fréquent, car l’information ne figure pas toujours dans vos contrats et doit parfois être réclamée au prestataire.
Le périmètre intra-groupe oublié
Les services TIC fournis par une entité de votre propre groupe entrent dans le périmètre. Une DSI groupe qui héberge les systèmes d’une filiale régulée est un prestataire TIC au sens du règlement, avec les obligations contractuelles correspondantes.
La qualification figée
La criticité d’un service évolue avec votre activité. Un outil périphérique devient critique quand un processus métier s’y adosse. Sans revue périodique des qualifications, au moins annuelle, votre registre décrit votre organisation d’il y a deux ans.
Par où commencer si vous partez de zéro
Si aucun recensement n’existe, ne commencez pas par les contrats. Commencez par l’argent et par les flux.
Demandez à la comptabilité fournisseurs la liste des prestataires payés sur les douze derniers mois, filtrée sur les catégories TIC : éditeurs, hébergeurs, opérateurs, intégrateurs, infogéreurs. Croisez-la avec la cartographie applicative de la DSI. L’écart entre les deux listes est instructif : chaque fournisseur payé sans contrat retrouvé, et chaque application sans contrat identifié, est un point de non-conformité en puissance.
Cette approche par les flux vous donne en quelques jours un périmètre exhaustif à 90 %, là où une collecte déclarative auprès des directions prend des semaines et laisse des trous. Les 10 % restants émergent lors de la qualification, quand les métiers décrivent les services dont leurs fonctions critiques dépendent réellement.
Priorisez ensuite la relecture : d’abord les contrats soutenant des fonctions critiques ou importantes, ensuite les plus gros engagements financiers, enfin le reste du portefeuille. La conformité parfaite est un horizon. Un registre fiable sur les fonctions critiques est une exigence immédiate.
L’angle que beaucoup manquent : DORA comme révélateur
DORA agit comme un test de votre maîtrise contractuelle. Si la constitution du registre est un chantier douloureux, le problème ne date pas du règlement. Il révèle une absence de référentiel contractuel qui pénalisait déjà vos renégociations, votre gestion des risques fournisseurs et vos audits.
À l’inverse, une organisation qui maîtrise son portefeuille contractuel produit le registre en jours, pas en mois. La conformité devient un sous-produit de la bonne gestion, pas un projet en soi. C’est l’approche que permet une plateforme comme Pactolane, avec un référentiel centralisé et des clauses analysées en continu.
FAQ
Qui est concerné par les exigences contractuelles de DORA ?
Le règlement s’applique aux entités financières au sens large : établissements de crédit, entreprises d’investissement, sociétés de gestion, entreprises d’assurance et de réassurance, établissements de paiement, entre autres. Les prestataires TIC de ces entités sont indirectement concernés, car leurs clients doivent leur imposer les clauses de l’article 30.
Qu’est-ce que le registre d’information DORA ?
C’est un recensement structuré de tous les accords contractuels relatifs à l’utilisation de services TIC fournis par des prestataires tiers, prévu à l’article 28 du règlement. Il distingue les services soutenant des fonctions critiques ou importantes et doit être tenu à jour et communicable aux autorités de supervision sur demande.
Quelles clauses DORA impose-t-il dans les contrats avec les prestataires TIC ?
L’article 30 exige notamment : la description des services et leur localisation, les niveaux de service, l’assistance en cas d’incident TIC, les droits d’accès, d’inspection et d’audit, les conditions de résiliation et, pour les fonctions critiques ou importantes, des stratégies de sortie documentées et testables.