Dernière révision : juillet 2026

La gouvernance des contrats bancaires à l’ère DORA

Depuis le 17 janvier 2025, le règlement européen sur la résilience opérationnelle numérique — DORA, règlement (UE) 2022/2554 — fait de chaque contrat de prestataire TIC d’une entité financière un objet réglementé : inventorié dans un registre, mis en conformité par des clauses obligatoires, suivi pour ses renouvellements, ses sorties et sa sous-traitance. La plupart des banques gèrent cette obligation avec des dossiers partagés et un tableur.

La plupart des banques n’ont pas un problème de contrats. Elles ont un problème de visibilité — et DORA vient de faire de la visibilité une exigence réglementaire.

En 30 secondes

  • DORA impose aux entités financières de tenir — et de soumettre chaque année — un registre d’informations couvrant chaque accord contractuel avec des prestataires tiers de services TIC.
  • L’article 30 prescrit des clauses contractuelles obligatoires, avec un niveau renforcé pour les contrats soutenant des fonctions critiques ou importantes, y compris les stratégies de sortie et les droits d’audit.
  • Les superviseurs identifient systématiquement les dispositions relatives aux tiers (articles 28 à 30) comme le domaine présentant les plus grandes lacunes de conformité — registres incomplets, classifications de criticité manquantes, clauses non conformes.
  • bizSupply donne aux banques le socle contractuel dont tout cela dépend : trouver chaque contrat fournisseur, en extraire les conditions et contrôler les renouvellements.

Qu’exige DORA de vos contrats fournisseurs ?

Le chapitre de DORA sur le risque lié aux prestataires tiers de services TIC (articles 28 à 30) fait de la gouvernance contractuelle une affaire de supervision. Concrètement, une banque doit :

  • Tenir un registre d’informations (article 28, paragraphe 3) : un inventaire structuré de tous les accords contractuels avec des prestataires tiers de services TIC, au niveau de l’entité et, le cas échéant, consolidé — en distinguant les accords qui soutiennent des fonctions critiques ou importantes (fonctions dont la perturbation compromettrait sensiblement la performance financière de la banque, ou la solidité et la continuité de ses services).
  • Le déclarer chaque année à l’autorité compétente, selon les modèles standard des AES et dans un format lisible par machine.
  • Évaluer avant de signer (article 29) : diligence raisonnable et évaluation du risque de concentration TIC avant de conclure des accords.
  • Mettre les contrats eux-mêmes en conformité (article 30) : un socle de dispositions obligatoires dans chaque contrat de services TIC — descriptions des services, lieux de traitement des données, protection des données, accès/récupération/restitution des données à la résiliation, délais de préavis, assistance en cas d’incident, droits de résiliation — plus un niveau renforcé pour les fonctions critiques ou importantes : objectifs de performance quantitatifs et qualitatifs précis, droits illimités d’audit et d’inspection, participation aux tests de pénétration fondés sur la menace (TLPT), et stratégies de sortie avec une période de transition adéquate pour que la banque puisse changer de prestataire ou réinternaliser les services sans interruption (article 28, paragraphe 8).
  • Contrôler la sous-traitance : savoir quand vos prestataires sous-traitent des fonctions, et conserver la visibilité contractuelle tout au long de cette chaîne.

Texte intégral : règlement (UE) 2022/2554 sur EUR-Lex. Orientations sectorielles : le portail DORA de l’ABE et les documents des AES sur le registre d’informations.

Le registre d’informations est désormais une routine annuelle — pas un projet ponctuel

Le premier cycle de soumission a eu lieu en 2025. Il se répète désormais chaque année : les registres reflètent l’état de vos accords contractuels au 31 décembre, les autorités nationales les collectent au premier trimestre puis les transmettent aux AES — en 2026, les échéances nationales se situaient entre la mi-février et la fin mars, avant la consolidation des AES fin mars, au format xBRL-CSV imposé.

La vraie question n’est donc pas « pouvons-nous construire le registre une fois ? » — c’est « pouvons-nous maintenir un inventaire de contrats complet et à jour comme routine opérationnelle ? » Un registre ne vaut que par la visibilité contractuelle qui l’alimente. Si les anciens contrats ne peuvent être rattachés à leur origine, si les renouvellements vivent dans le tableur d’une seule personne, si chaque département garde ses accords dans son propre dossier partagé — chaque cycle annuel devient un chantier d’archéologie.

Pourquoi est-ce le plus difficile pour les petites et moyennes banques ?

DORA s’applique avec proportionnalité (article 4) : la profondeur de votre cadre de gestion du risque TIC peut refléter votre taille et votre profil de risque, et certains types d’entités plus petites relèvent du cadre simplifié de l’article 16. Ce que la proportionnalité ne fait pas : supprimer les obligations contractuelles relatives aux tiers — le registre, les clauses de l’article 30 et les stratégies de sortie restent applicables.

Les établissements plus petits se retrouvent ainsi pris en étau :

  • Trop réglementés pour des tableurs. Un inventaire Excel et des dossiers réseau par département ne peuvent pas démontrer à un superviseur une couverture contractuelle complète et à jour.
  • Trop petits pour un GRC d’entreprise. Les plateformes conçues pour cela — les suites GRC d’entreprise — sont tarifées et dimensionnées pour des établissements dotés d’équipes dédiées au risque des tiers. Une banque de quelques centaines de salariés reçoit la même obligation avec une fraction du budget outillage.
  • Le savoir est concentré. Dans les petits établissements, l’historique des contrats vit souvent chez une poignée de collaborateurs de longue date. Le registre DORA le demande sous forme structurée et déclarable.

Les chiffres

8,6 % de la valeur contractuelle annuelle s’évapore par mauvaise gouvernance des contrats — renouvellements manqués, clauses non appliquées, remises non exercées (WorldCC / Deloitte, 2023). Pour une banque, DORA transforme ce coût silencieux en constat explicite de supervision.

DORA s’applique à une vingtaine de catégories d’entités financières — banques, établissements de paiement et de monnaie électronique, entreprises d’investissement, assureurs et plus — depuis le 17 janvier 2025 (règlement (UE) 2022/2554).

Les registres d’informations sont soumis chaque année, sur la base des données au 31 décembre, au format xBRL-CSV des AES.

Les superviseurs européens identifient systématiquement les articles 28 à 30 — le registre et les dispositions contractuelles — comme le domaine présentant les plus grandes lacunes de conformité parmi les entités financières.

Où bizSupply s’inscrit-il — et où pas ?

bizSupply n’est pas une plateforme GRC et ne prétend pas vous rendre conforme à DORA. Il résout la couche sous-jacente, celle dont dépend chaque obligation contractuelle de DORA : savoir quels contrats vous avez, ce qu’ils contiennent et quand ils changent.

Ce que DORA attend de vousCe que bizSupply fait aujourd’hui
Un inventaire complet des contrats fournisseursDécouvre les contrats dans les boîtes mail, les espaces de stockage, par transfert et dépôt manuel — y compris ceux dont personne ne se souvenait — dans un inventaire centralisé
Les conditions qui alimentent votre registre et votre gouvernanceExtrait les métadonnées : parties, prix, dates de renouvellement, délais de préavis, clauses de pénalité, conditions de paiement
Des contrats renouvelés ou mis en conformité à temps, pas découverts expirésContrôle des renouvellements : alertes et déclencheurs sur les dates de renouvellement et les fenêtres de préavis, en remplacement du tableur
Un levier de négociation quand les contrats passent en mise en conformitéBenchmarking : compare vos coûts contractuels pour que la renégociation et la remise à plat imposée par DORA partent des données

Ce que bizSupply n’est pas :

  • Pas un outil GRC ni de reporting réglementaire — il ne génère pas et ne soumet pas votre registre xBRL-CSV. Il tient l’inventaire des contrats et les métadonnées dont votre équipe registre se sert.
  • Pas une certification de conformité, et pas un conseil juridique. Vos obligations DORA restent les vôtres ; bizSupply fournit la base de preuve côté contrats.
  • Pas bizAPIs. bizAPIs est le produit d’API d’infrastructure de conformité d’Infosistema (KYC, données de registres). bizSupply, c’est la visibilité des contrats fournisseurs. Même groupe — produits différents, missions différentes.
  • Pas un déploiement CLM. Pas d’implémentation de six mois : la découverte des contrats travaille sur ce que vos boîtes mail et vos espaces de stockage contiennent déjà. S’il vous faut six mois d’implémentation pour comprendre vos contrats, vous avez déjà perdu.

Commencez par le socle contractuel

Si votre établissement se situe quelque part entre « l’auditeur a demandé notre registre de contrats » et « nous ne pouvons pas justifier une suite GRC d’entreprise », le point de départ est le socle dont dépend chaque obligation contractuelle de DORA : un inventaire complet, des conditions extraites, un contrôle des renouvellements. C’est ce que bizSupply fait aujourd’hui.

En cours d’évaluation pour la feuille de route

Rien de tout cela n’est construit aujourd’hui. Nos échanges avec des entités financières font remonter les mêmes besoins spécifiques à DORA, et nous les évaluons pour la feuille de route — l’intérêt des établissements détermine directement leur priorité :

  • Marquage des prestataires TIC et vues de criticité alignées sur les catégories du registre d’informations
  • Suivi des avenants DORA et de la mise en conformité — quels contrats ont l’avenant, lesquels doivent être repris
  • Rapprochement contrats-factures
  • Appui à l’évaluation du risque lié aux prestataires tiers TIC

Si l’un de ces points changerait la façon dont votre établissement gère la gouvernance des contrats DORA, dites-le-nous — c’est précisément ce signal qui fait passer un sujet de l’évaluation au développement.

Les éléments en cours d’évaluation ne sont pas des engagements. État : juillet 2026.

Questions fréquentes

Que demande DORA aux banques concernant les contrats de prestataires TIC ?

Trois choses : tenir un registre d’informations couvrant chaque accord contractuel avec des prestataires tiers de services TIC (article 28, paragraphe 3), le soumettre chaque année à l’autorité compétente, et veiller à ce que les contrats eux-mêmes contiennent les dispositions obligatoires de DORA (article 30) — avec des exigences renforcées, dont les stratégies de sortie et les droits d’audit, lorsque le service soutient une fonction critique ou importante.

Qu’est-ce que le registre d’informations DORA ?

Un inventaire structuré et lisible par machine de tous les accords contractuels d’une entité financière avec des prestataires tiers de services TIC, tenu au niveau de l’entité (et, le cas échéant, consolidé), en distinguant les accords qui soutiennent des fonctions critiques ou importantes. Il suit les modèles des AES et est soumis chaque année au format xBRL-CSV, sur la base des données au 31 décembre.

Quand le registre d’informations doit-il être remis ?

Chaque année. Les autorités nationales compétentes (pour les banques en France : l’ACPR) fixent des fenêtres de collecte au premier trimestre (en 2026, généralement de mi-février à fin mars selon les pays), puis transmettent les registres aux AES avant fin mars. Vérifiez l’échéance exacte auprès de votre autorité nationale.

Quelles clauses contractuelles l’article 30 de DORA exige-t-il ?

Un socle pour tous les contrats de services TIC : descriptions complètes des services, lieux de traitement des données, dispositions de protection des données, accès/récupération/restitution des données en cas de résiliation ou d’insolvabilité, niveaux de service, assistance en cas d’incident, coopération avec les autorités, et droits de résiliation avec préavis minimal. Pour les fonctions critiques ou importantes, s’y ajoutent : des objectifs de performance quantitatifs et qualitatifs précis, une notification élargie des incidents, des droits illimités d’audit, d’accès et d’inspection, la participation aux tests de pénétration fondés sur la menace (TLPT), et des stratégies de sortie avec une période de transition adéquate.

DORA s’applique-t-il aux petites banques ?

Oui. La proportionnalité (article 4) module la profondeur du cadre de gestion du risque lié aux TIC, et l’article 16 accorde à certains types d’entités plus petites un cadre simplifié — mais les dispositions relatives aux tiers, y compris le registre d’informations et les clauses contractuelles de l’article 30, s’appliquent quelle que soit la taille.

Cela s’applique-t-il au-delà des banques ?

Oui. DORA couvre une vingtaine de catégories d’entités financières — établissements de paiement et de monnaie électronique, entreprises d’investissement, gestionnaires de fonds, assureurs et plus encore — et les obligations décrites ici concernant le registre d’informations et l’article 30 s’appliquent à elles de la même manière. Tout ce qui figure sur cette page est transposable.

bizSupply est-il un outil de conformité DORA ou un GRC ?

Non. bizSupply est un produit de visibilité contractuelle : il découvre les contrats fournisseurs dans vos boîtes mail et vos espaces de stockage, en extrait les conditions commerciales et contrôle les renouvellements. C’est le socle contractuel dont dépend la gouvernance DORA — mais la production du registre, sa soumission et la responsabilité de conformité relèvent de votre fonction conformité et de ses outils de reporting.

bizSupply génère-t-il la soumission du registre au format xBRL-CSV ?

Non. bizSupply tient l’inventaire des contrats et les métadonnées à partir desquels votre registre est construit ; il ne produit ni ne dépose de déclarations réglementaires.

bizSupply dispose-t-il de fonctionnalités spécifiques à DORA, comme le suivi des avenants ou la classification des prestataires TIC ?

Pas aujourd’hui. Ces fonctionnalités sont en cours d’évaluation pour la feuille de route, et l’intérêt des entités financières détermine leur priorité. Ce que bizSupply fournit aujourd’hui, c’est l’inventaire des contrats, l’extraction des métadonnées et le contrôle des renouvellements sur lesquels ces capacités s’appuieraient.

En quoi bizSupply diffère-t-il de bizAPIs ?

Les deux sont des produits Infosistema. bizAPIs fournit des API d’infrastructure de conformité (KYC, données de registres officiels) pour construire des parcours de vérification. bizSupply est un produit de visibilité des contrats fournisseurs pour les équipes finance et gestion des tiers. Ils résolvent des problèmes différents et ne partagent aucune donnée.

Cette page est une information générale sur le règlement (UE) 2022/2554 (DORA) et sur les capacités de bizSupply, revue pour la dernière fois à la date indiquée ci-dessus. Elle ne constitue pas un conseil juridique ou réglementaire. Les obligations au titre de DORA incombent à chaque entité financière ; consultez votre fonction conformité et votre conseil juridique. bizSupply est un produit d’Infosistema (groupe Joyn).