Champs obligatoires du registre d'information DORA

Dans le registre d'information DORA, « obligatoire » ne veut pas dire « tout remplir partout ». Le règlement d'exécution (UE) 2024/2956 distingue clairement :

• Obligatoire — à renseigner dans tous les cas applicables au template
• Conditionnel — obligatoire seulement si une condition est vraie (fonction critique, type d'accord, stockage de données, etc.)
• Optionnel — facultatif

Mal comprendre cette logique produit deux échecs symétriques : des fichiers incomplets ou des équipes qui bloquent sur des champs qui ne s'appliquent pas encore.

Cet article détaille les familles de champs qui font le plus souvent défaut. Pour la vue d'ensemble des 13 templates : guide complet du registre.

1. Identité de l'entité déclarante (B_01.01)

Une seule ligne. Champs structurants :

Champ	Portée
LEI de l'entité tenant le registre	Obligatoire — format 20 caractères
Nom / pays	Obligatoires
Type d'entité financière	Obligatoire — liste fermée EBA (22 valeurs en B_01.01, ex. sociétés de gestion eba_CT:x639, établissements de paiement eba_CT:x300)
Autorité compétente + date de communication	Conditionnels — si communication au superviseur

Sans LEI valide et type d'entité correct, le reste du package est difficilement cohérent (listes d'activités autorisées en B_06.01 filtrées selon le type).

2. Accords contractuels — général (B_02.01)

Chaque accord reçoit un numéro de référence unique et stable, attribué par l'entité. C'est la clé universelle du registre.

Champs obligatoires typiques :

• Type d'accord : standalone, overarching (cadre / général), ou subsequent / associated (ultérieur ou associé)
• Monnaie + dépense annuelle ou coût estimé (année écoulée), en unités (pas en milliers)

Conditionnel critique : si le type est « accord ultérieur ou associé », la référence vers l'accord général est obligatoire. Pour un cadre + avenants, la somme des dépenses des accords ultérieurs doit correspondre au total du général (sans double comptage).

C'est aussi là que naît l'erreur classique « confusion contrat cadre / standalone » observée en 2025.

3. Accords — spécifique (B_02.02), le template le plus dense

Une ligne par combinaison accord × bénéficiaire × prestataire × fonction × type de service TIC.

Toujours structurants

• Référence d'accord, LEI bénéficiaire, code prestataire + type de code
• Identifiant de fonction (F1…)
• Type de service TIC — 19 valeurs S01→S19 (project management, cloud IaaS/PaaS/SaaS, telecom, software licensing hors SaaS, etc.)
• Dates de début / fin (9999-12-31 si durée indéterminée)
• Raison de résiliation — conditionnelle si l'accord est résilié (6 motifs numériques)

Conditionnels si la fonction est critique ou importante

Dès que B_06.01 classe la fonction comme critique/importante, deviennent notamment exigibles :

• Délais de préavis (jours) pour l'entité et pour le prestataire
• Pays du droit applicable et pays de fourniture des services
• Stockage des données (oui/non) puis localisation des données au repos
• Localisation de la gestion / traitement des données (si service de traitement)
• Sensibilité des données stockées (faible / moyen / élevé)
• Niveau de dépendance au service TIC (insignifiant → dépendance totale)

Implication pratique : tant que votre référentiel de fonctions (B_06.01) est flou, vous ne savez pas quels champs de B_02.02 sont réellement dus.

4. Prestataires (B_05.01) — bien plus qu'un nom

Pour chaque prestataire (direct, sous-traitant, mère ultime le cas échéant) :

• Code d'identification + type de code
• Raison sociale + nom en alphabet latin
• Type de personne (morale vs individu agissant à titre professionnel)
• Pays du siège
• Dépenses totales annuelles + devise — conditionnels selon le cas
• Entreprise mère ultime + type de code — si le prestataire n'est pas lui-même la mère ultime

Règle d'identifiant (à connaître par cœur)

• Personnes morales établies dans l'UE : LEI ou EUID uniquement
• Personnes morales hors UE : LEI uniquement
• Codes alternatifs (CRN, VAT, passeport, etc.) : uniquement pour les personnes physiques agissant à titre professionnel

Chaque sous-traitant présent dans B_05.02 doit aussi exister dans B_05.01.

5. Chaînes d'approvisionnement (B_05.02)

Pour chaque service TIC d'un accord :

• Type de service, code prestataire, rang (≥ 1 ; 1 = direct)
• Si rang > 1 : code du destinataire des services sous-traités au rang précédent

Tous les acteurs d'une même chaîne partagent le même numéro d'accord et le même type de service. En pratique, seuls sont à déclarer les sous-traitants qui sous-tendent des fonctions critiques ou importantes (avec des règles spécifiques quand la chaîne est intra-groupe).

6. Fonctions (B_06.01) — le registre souvent manquant

Chaque fonction reçoit un identifiant F + nombre naturel, unique pour la combinaison :

• LEI de l'entité bénéficiaire
• Activité autorisée (Annexe II — centaines de valeurs selon le type d'entité ; ou « fonctions de soutien »)
• Nom interne de la fonction

Champs obligatoires notables :

• Évaluation de la criticité / importance (oui / non / évaluation non réalisée)
• Date de dernière évaluation (9999-12-31 si jamais évaluée)
• RTO et RPO en heures entières (valeur < 1h → déclarer 1 ; 0 si non défini)
• Incidence de l'interruption (faible / moyen / élevé / non réalisée)

Sans ce module, B_02.02 ne peut pas référencer correctement les fonctions — et les champs conditionnels « critiques » restent indéterminés.

7. Évaluations (B_07.01) — pour les fonctions critiques

Pour chaque accord couvrant une fonction critique ou importante :

• Substituabilité (non substituable → facilement substituable)
• Raison de non-substituabilité — conditionnelle si non substituable ou très complexe
• Date du dernier audit du prestataire — audits menés par l'entité ou un tiers mandaté, pas une certification fournisseur reçue passivement (9999-12-31 si aucun)
• Existence d'un plan de sortie
• Possibilité de réintégration (facile / difficile / très complexe)
• Incidence de la cessation des services
• Alternatives recensées (oui / non / non évalué)

8. Règles de validation EBA à avoir en tête

Environ 71 règles de validation EBA, souvent en sévérité warning. Familles utiles pour prioriser la qualité :

• Existence — champs obligatoires non nuls (ex. B_02.02 colonnes type service / dates ; B_05.01 identité ; B_06.01 RTO/RPO…)
• Conditionnelles — ex. accord ultérieur ⇒ référence au cadre ; substituabilité faible ⇒ raison obligatoire ; montant ⇒ devise
• Complétude de ligne — si une ligne est commencée, les obligatoires de la ligne doivent l'être
• Format LEI — regex ^[A-Z0-9]{18}[0-9]{2}$ (certaines règles LEI sur d'autres templates ont été désactivées temporairement par l'EBA — à surveiller)

Checklist de priorisation (entité individuelle)

1. LEI + type d'entité (B_01.01)
2. Fonctions + criticité + RTO/RPO (B_06.01)
3. Prestataires avec LEI/EUID et mère ultime (B_05.01)
4. Accords : type cadre/standalone/ultérieur + coûts (B_02.01)
5. Lignes spécifiques B_02.02 (y compris champs critiques conditionnels)
6. Chaînes B_05.02 et évaluations B_07.01 sur le périmètre critique

Pour aller plus loin

• Guide complet du registre d'information DORA
• Format XBRL-CSV
• Modèle opérationnel / template

Le rôle d'Axenia. Axenia aide à structurer ces champs à partir des contrats et référentiels existants, à distinguer le obligatoire du conditionnel selon la criticité des fonctions, et à signaler les manques avant export.

---

À partir du règlement d'exécution (UE) 2024/2956. Ne constitue pas un avis juridique.