Ressources › Guide

xBRL-CSV expliqué à qui n'a jamais ouvert une taxonomie

Le mot fait peur, et c'est dommage, parce que la chose est simple. xBRL-CSV n'est pas un langage à apprendre. C'est une convention d'emballage : des fichiers CSV ordinaires, rangés d'une certaine façon, accompagnés de deux ou trois fichiers qui expliquent ce qu'ils contiennent.

Cet article décrit ce qu'il y a réellement dans le paquet, pourquoi les autorités l'exigent, et ce qui se passe si vous tentez de le fabriquer à la main depuis Excel.

D'où vient ce format

XBRL — eXtensible Business Reporting Language — est le standard mondial du reporting financier structuré. Il existe depuis le début des années 2000 et sert aux états financiers, aux déclarations prudentielles, aux rapports de durabilité.

Sa forme historique est le XML : puissante, verbeuse, et pénible à produire. Un dépôt XBRL classique pèse des dizaines de mégaoctets pour quelques milliers de valeurs.

xBRL-CSV est la réponse à ce reproche. Même modèle de données, même taxonomie, même rigueur — mais les valeurs sont écrites dans des fichiers CSV lisibles par n'importe quel tableur, et seul un petit fichier JSON décrit comment les relier au modèle. C'est nettement plus léger, et surtout inspectable à l'œil nu.

Pour le registre d'information DORA, les autorités européennes de surveillance ont retenu cette variante. Un point mérite d'être noté : les règles de réception précisent que le dépôt DORA doit être un zip contenant du plain-csv — la variante XML n'est pas acceptée ici.

Ce qu'il y a dans le paquet

Décompressez une archive conforme, et vous trouvez ceci :

Rien d'ésotérique. Chaque fichier de données est un CSV dont les colonnes portent les codes de la taxonomie — 0010, 0020, 0030 — et non leurs libellés en français ou en anglais. C'est le premier écart avec un tableur ordinaire.

Le manifeste

report.json indique contre quelle taxonomie le paquet doit être interprété. C'est ce qui permet à l'autorité de savoir que votre colonne 0110 de B_01.02 est un total de bilan exprimé dans la devise de la colonne 0100. Sans lui, les CSV ne sont que des chiffres sans signification.

Les indicateurs de dépôt

FilingIndicators.csv est régulièrement mal compris. Il ne contient aucune donnée métier : il déclare, pour chaque modèle, si vous le transmettez. Un modèle déclaré true mais absent est une incohérence ; un modèle présent mais non déclaré l'est également.

Les contraintes sont strictes : nombre de colonnes exact, un modèle déclaré une seule fois, valeurs booléennes uniquement (true, false, 1, 0), et jamais un code de modèle sans sa valeur.

Les paramètres

parameters.csv tient en quelques lignes, avec un en-tête qui doit contenir exactement name et value. Le paramètre décisif est entityID : sa valeur doit correspondre au nom du fichier. Renommer l'archive après l'avoir générée rompt cette correspondance et fait échouer le dépôt.

Le nom de l'archive

Le nom n'est pas décoratif. Il est analysé segment par segment :

Sujet_Pays_CodeCadreVersionModule_Module_DateDeRéférence_Horodatage.zip

Extension .zip obligatoire ; caractères limités aux alphanumériques, au tiret, au tiret bas et au point ; date de référence au format aaaa-mm-jj, valide, et jamais dans le futur ; nom unique — un nom déjà soumis est refusé même si le contenu a changé.

Pourquoi le faire à la main tourne mal

Rien dans ce qui précède n'est intellectuellement difficile. C'est justement le problème : chaque étape est simple, elles sont nombreuses, et aucune ne pardonne.

• Les en-têtes. Vos colonnes doivent porter les codes de la taxonomie, pas vos intitulés métier. Un export Excel produit vos intitulés.
• Les listes fermées. FR et non « France », EUR et non « Euro », un code de service et non « hébergement ». Un tableur ne le sait pas.
• Les séparateurs et l'encodage. Excel en configuration française exporte volontiers en point-virgule et en Windows-1252. Le paquet attend de l'UTF-8.
• Les nombres. Une virgule décimale, un séparateur de milliers, un espace insécable recopié depuis un rapport — autant de valeurs invalides.
• Les indicateurs de dépôt. Ils doivent correspondre exactement aux fichiers présents.
• Le nom de fichier. Une convention à respecter au caractère près, avec un horodatage cohérent.
• Les références croisées. Les identifiants doivent se correspondre d'un fichier à l'autre. Un copier-coller décalé d'une ligne casse tout, silencieusement.

Chacun de ces points est vérifiable. Aucun n'est visible dans un tableur. C'est pourquoi l'exercice à blanc de 2024 a vu 6,5 % de réussite au premier essai, et pourquoi les cabinets facturent ces dépôts à cinq chiffres : ils ne vendent pas une expertise réglementaire, ils vendent de la patience mécanique.

À quoi ressemblent vraiment ces fichiers

Les trois fichiers techniques tiennent en quelques lignes. Voici leur allure, débarrassée du jargon.

FilingIndicators.csv ne contient que deux colonnes : le code du modèle, et un booléen disant si vous le transmettez. Une entité qui ne tient pas de succursales déclarera B_01.03 à false et ne joindra pas le fichier correspondant. Déclarer true sans joindre le fichier, ou l'inverse, est une incohérence relevée immédiatement.

parameters.csv est plus court encore : un en-tête name,value, puis les paramètres. Celui qui compte est entityID, dont la valeur doit correspondre au nom de l'archive. C'est le lien entre le contenu et son emballage, et c'est aussi le contrôle que casse le plus souvent un renommage bien intentionné — « je rajoute _v2 pour m'y retrouver ».

Les fichiers de données, eux, ont pour en-tête les codes de colonnes de la taxonomie. Dans B_01.02.csv, la colonne 0100 est la devise et la colonne 0110 le total de bilan. Un lecteur humain n'y comprend rien sans la documentation ; un validateur, lui, n'a besoin de rien d'autre. C'est un format écrit pour les machines, et c'est assumé.

Que faire d'un dépôt rejeté

Un rejet ne se corrige pas en renvoyant le même fichier. Deux règles s'y opposent : le nom doit être unique — un nom déjà soumis est refusé même si le contenu a changé — et l'horodatage de création doit donc être régénéré.

La marche à suivre est donc : corriger la donnée, régénérer entièrement le paquet avec un nouvel horodatage, et redéposer. Modifier un CSV à l'intérieur de l'archive existante puis la recompresser produit presque toujours un second rejet, parce que le nom n'a pas bougé.

Et surtout : ne comptez pas sur le message d'erreur pour vous instruire. Certains sont précis, d'autres se limitent à « No data was integratable ». Le seul moyen fiable de savoir ce qui ne va pas est de rejouer les contrôles avant de déposer, chez vous, où vous pouvez itérer en quelques secondes plutôt qu'en quelques jours.

Une remarque sur les tailles

Le plafond de réception est de 10 Go. Un registre d'entité de taille moyenne pèse quelques dizaines de kilooctets. Si votre paquet approche du mégaoctet, quelque chose ne va pas : ce sont généralement des lignes vides exportées par un tableur, ou un modèle dupliqué.

Ce qu'Obligia produit

Vous saisissez ou importez vos données dans une interface qui connaît les listes fermées et refuse une valeur invalide au moment de la frappe. L'outil rejoue ensuite les contrôles des autorités, vous liste ce qui bloque, et n'autorise l'export que lorsque le compte est à zéro.

Le paquet produit est nommé selon la convention, encodé en UTF-8, avec ses trois fichiers techniques et un CSV par modèle rempli. Vous le déposez tel quel.

Pour aller plus loin : le registre d'information, modèle par modèle et pourquoi un dépôt est rejeté.

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é.