Ressources › Guide

Pourquoi un dépôt DORA est rejeté

Lors de l'exercice à blanc de 2024, 6,5 % des entités seulement ont franchi l'ensemble des contrôles du premier coup. Les 93,5 % restantes n'avaient pas mal compris le règlement : elles avaient mal formé un fichier.

Les autorités européennes de surveillance publient 120 règles de contrôle appliquées au registre d'information. Elles ne s'exécutent pas toutes au même moment, et cet ordre est la clé : un dépôt peut être refusé avant qu'une seule de vos données n'ait été lue. Cet article parcourt les quatre étages du contrôle, dans l'ordre où ils s'appliquent, et indique à chacun ce qui échoue le plus souvent.

Les huit règles restantes portent sur la validité des identifiants auprès de GLEIF et de BRIS ; nous y revenons à la fin, car leur statut particulier est une source de mécompte.

Étage 1 — La réception : douze règles avant toute lecture

Ces contrôles s'appliquent à l'archive en tant que fichier. Un registre irréprochable dans une archive mal nommée est refusé ici, sans autre message.

• Extension — l'archive doit être un .zip, et pour DORA elle doit contenir du plain-csv, pas du XBRL.
• Intégrité — l'archive doit se décompresser et sa somme de contrôle être cohérente.
• Caractères autorisés — alphanumériques, tiret, tiret bas, point. Une espace ou un accent dans le nom du fichier suffit.
• Structure du nom — Sujet_Pays_CodeCadreVersionModule_Module_DateDeRéférence_Horodatage. Chaque segment est vérifié séparément.
• Cohérence du module — le module inscrit dans le nom doit correspondre à la catégorie déclarée, parmi SUP, REM, RES, PAY, DORA et PILLAR3.
• Cohérence du pays — pour un dépôt via une autorité compétente, le pays du chemin de soumission doit correspondre au code pays du nom de fichier.
• Date de référence — au format aaaa-mm-jj, valide, et jamais dans le futur. C'est un piège classique : un horodatage généré dans un fuseau en avance peut faire basculer la date.
• Unicité — un nom de fichier déjà soumis est refusé, même si le contenu a changé. Une correction doit porter un nouvel horodatage.
• Taille — 10 Go au maximum par SFTP. Sans objet pour un registre normal, mais la règle existe.
• Encodage — UTF-8.

Étage 2 — La structure : ce que l'archive doit contenir

Une fois ouverte, l'archive doit présenter trois fichiers techniques à un emplacement exact.

• reports/report.json — les métadonnées et la taxonomie visée ;
• reports/FilingIndicators.csv — la liste des modèles que vous déclarez transmettre ;
• reports/parameters.csv — les paramètres du dépôt.

Les indicateurs de dépôt sont l'endroit le plus souvent mal compris. Ce fichier ne contient pas vos données : il déclare, pour chaque modèle, si vous le transmettez ou non. Les règles associées sont sévères :

• le nombre de colonnes doit être exact ;
• un modèle ne peut être déclaré qu'une seule fois ;
• seules les valeurs booléennes sont admises — true, false, 1, 0 ;
• un code de modèle présent sans valeur associée est une erreur à part entière.

Du côté des paramètres, un contrôle mérite une mention à lui seul : le paramètre entityID doit exister et sa valeur correspondre au nom du fichier. Une entité qui renomme son archive après l'avoir générée casse cette correspondance sans le savoir. La ligne d'en-tête de parameters.csv doit par ailleurs contenir exactement name et value, dans cet ordre.

Enfin, les fichiers de données doivent porter des noms de tables valides : B_02.02.csv, pas contrats.csv.

Une dernière règle de cet étage est la plus laconique du catalogue : « No data was integratable ». Elle signifie que le paquet était formellement acceptable et que rien n'a pu en être extrait. C'est le rejet le moins instructif qui soit.

Étage 3 — Les contrôles techniques DPM

Onze règles vérifient que chaque valeur respecte le modèle de données : type attendu, appartenance à une liste fermée, cardinalité, unicité des identifiants de ligne.

Les listes fermées causent l'essentiel des échecs, et toujours de la même façon. La taxonomie attend un code, l'humain écrit un mot :

Aucune de ces saisies n'est absurde. Toutes sont refusées. C'est la raison d'être des listes déroulantes dans un outil dédié : elles rendent l'erreur impossible plutôt que détectable.

Étage 4 — Les 71 règles métier

C'est le cœur du contrôle, et le seul étage qui porte réellement sur la qualité de votre registre. Ces règles vérifient la cohérence entre les modèles. Trois familles reviennent constamment.

Les références orphelines

Une référence d'accord contractuel (CAR) citée dans B_02.02, B_03.01 ou B_07.01 doit exister dans B_02.01. Un prestataire cité dans une chaîne de sous-traitance doit exister dans B_05.01. Une entité utilisatrice doit figurer dans le périmètre. Chaque lien rompu est une erreur, et un identifiant mal recopié en produit souvent plusieurs d'un coup.

Les obligations conditionnelles

C'est ici que se loge l'erreur la plus coûteuse du registre. Déclarez une fonction critique ou importante dans B_06.01, et des colonnes jusque-là facultatives deviennent obligatoires dans B_02.02 : droit applicable, préavis de résiliation des deux côtés, pays de conservation des données, niveau de dépendance. Une évaluation devient exigible dans B_07.01.

Les cohérences arithmétiques et logiques

Une entité qui n'est pas une société holding doit déclarer un total de bilan, et ce total exige la devise correspondante. Une date de fin de contrat ne peut précéder sa date de début. Un rang de sous-traitance ne peut sauter un échelon.

Le cas particulier des identifiants

Huit règles vérifient l'existence réelle des identifiants : six pour le LEI auprès de GLEIF (VR_2, VR_12, VR_23, VR_71, VR_77), deux pour l'EUID auprès de BRIS (VR_72, VR_78).

Ces règles sont marquées « do not run rule » par les autorités elles-mêmes, faute d'accès garanti à ces bases au moment du contrôle. La conclusion que beaucoup en tirent est erronée.

Ce que cela signifie réellement : un LEI bien formé mais faux — celui d'une filiale voisine, ou d'une entité radiée — passe les contrôles automatiques sans un mot. Il ne sera relevé qu'ensuite, par un examinateur humain, dans un échange nettement moins agréable qu'un message d'erreur.

La validité formelle, elle, est vérifiable immédiatement et hors ligne : vingt caractères, alphabet contraint, deux chiffres de contrôle ISO 7064. Il n'y a aucune raison de déposer un LEI dont la clé de contrôle est fausse — et pourtant cela arrive, parce qu'un tableur ne calcule pas de clé de contrôle.

Ce qu'il faut en retenir

Les 120 règles ne testent pas votre compréhension de DORA. Elles testent la rigueur mécanique d'un fichier — un nom, une structure, des codes, des références croisées. C'est précisément le genre de travail qu'un humain fait mal et qu'un programme fait parfaitement.

La bonne méthode tient en une phrase : rejouer les contrôles avant de déposer, dans l'ordre où l'autorité les appliquera, et corriger jusqu'à zéro erreur. C'est ce que fait Obligia — 104 règles sur les 120 publiées, les 16 autres étant hors périmètre pour des raisons documentées et vérifiables.

Pour aller plus loin : le registre d'information, modèle par modèle et le format xBRL-CSV expliqué simplement.

Construire mon registre   Réserver une démonstration ›

Ce guide est une information générale et non un conseil réglementaire ; la responsabilité du dépôt incombe à l'entité.