MiCA Décrypté : Votre Livre Blanc Crypto Ne Peut Pas Être Simplement un Gitbook ou un PDF – Actualités Juridiques Bitcoin

MiCA Decoded est une série hebdomadaire de 12 articles pour Bitcoin.com News, co-rédigée par les Co-fondateurs et Directeurs Généraux de LegalBison : Aaron Glauberman, Viktor Juskin et Sabir Alijev. LegalBison conseille les entreprises crypto et FinTech sur les licences MiCA, les demandes CASP et VASP, et la structuration réglementaire en Europe et au-delà.

Dans le cadre de MiCA, un livre blanc est un instrument de divulgation juridique obligatoire. Son analogie la plus proche dans la finance traditionnelle est un prospectus de valeurs mobilières, et non un document marketing. Le règlement prescrit qui doit en préparer un, dans quel format, contenant quels identifiants, soumis à quelle validation automatisée, et avec une responsabilité attachée à une personne spécifiquement nommée.

Se tromper sur l'un de ces éléments signifie que le document n'existe pas aux yeux des régulateurs européens, quelle que soit la qualité de sa rédaction.

Ce sixième volet de MiCA Decoded décortique ce que cela signifie réellement, point par point.

Le mythe : Un livre blanc MiCA n'est qu'un GitBook ou un PDF

Un livre blanc MiCA porte le poids d'un dépôt réglementaire formel.

Le règlement d'exécution de la Commission (UE) 2024/2984, qui régit les formulaires, formats et modèles pour les livres blancs de crypto-actifs, exige que le document soit préparé dans un format numérique structuré conçu de sorte que l'ESMA et les autorités nationales compétentes de tous les États membres de l'UE puissent effectuer une analyse automatisée identique sur chaque soumission, quel que soit l'auteur du dépôt ou le lieu.

L'objectif juridique de ce choix de conception importe davantage que les spécificités techniques. MiCA est un règlement de marché unique, et la comparabilité entre les dépôts est un outil d'application essentiel.

Un livre blanc qui ne peut pas être lu par la même machine que tous les autres livres blancs déposés en Europe n'est pas conforme, quel que soit le contenu. L'ESMA a publié la taxonomie requise (le cadre structuré qui définit ce qu'un livre blanc conforme doit contenir) le 5 août 2025. Les règles s'appliquent à partir du 23 décembre 2025.

Les obligations de divulgation varient en fonction du type de crypto-actif concerné. MiCA distingue trois catégories distinctes, chacune avec son propre modèle de livre blanc et ses exigences de champ :

La catégorie détermine non seulement le contenu du livre blanc, mais aussi l'ensemble du parcours juridique pour en déposer un. Un projet ne peut pas choisir quelle catégorie s'applique selon ses préférences. Les caractéristiques de l'actif le déterminent, et les obligations de préparation en découlent.

Qui porte l'obligation juridique – et la responsabilité

Pour la grande majorité des tokens sur le marché (catégorisés comme « Autres » crypto-actifs, ou OTHR), l'obligation ne revient pas automatiquement à l'entité qui a créé le token. Pour ces actifs, MiCA place l'obligation sur l'offrant ou la personne demandant l'admission à la négociation, qui sont des rôles définis pouvant ou non coïncider avec l'émetteur initial.

Cette distinction a des conséquences réelles. Un projet relevant de la catégorie OTHR, lancé depuis les Îles Vierges britanniques, les Caïmans ou toute autre juridiction offshore, peut être l'offrant au titre de MiCA et assumer directement l'obligation du livre blanc, sans aucune exigence de relocaliser son siège social en Europe.

(Note : Cette flexibilité structurelle s'applique strictement aux tokens OTHR. Pour les Tokens référencés sur actifs et les Tokens de monnaie électronique, l'obligation juridique et la responsabilité civile stricte pour le livre blanc reposent entièrement sur l'émetteur autorisé de l'UE et ne peuvent être déléguées).

Comme nous l'avons examiné dans le deuxième volet de cette série, les registres de l'ESMA confirment qu'il s'agit déjà d'une pratique courante : la majorité des dépôts indépendants de tokens proviennent d'entités dont le siège est hors de l'UE.

Un CASP exploitant une plateforme de trading peut également assumer l'obligation du livre blanc, soit de sa propre initiative, soit par accord écrit avec l'équipe du projet. Ce n'est pas une faille ou une commodité administrative.

Lorsqu'un CASP dépose, il assume la responsabilité juridique de l'exactitude et de l'exhaustivité de la divulgation. Si le livre blanc contient des informations erronées ou ne respecte pas les normes réglementaires, la responsabilité appartient à celui qui l'a soumis.

La personne qui valide le livre blanc ne peut déléguer cette exposition à un éditeur de logiciels, un intégrateur technique ou un cabinet d'avocats. L'examen juridique du contenu et la validité technique sont deux obligations de conformité distinctes, et toutes deux incombent à l'offrant. C'est le point que la plupart des projets sous-estiment.

Deux codes qui doivent exister avant le début du dépôt

Deux identifiants obligatoires sont des prérequis pour tout livre blanc conforme. Les deux sont tirés de normes internationales antérieures à MiCA. Le règlement ne les a pas créés, il les a rendus obligatoires.

Le premier est le Legal Entity Identifier (LEI), un code ISO 17442 attribué aux entités juridiques et maintenu dans la base de données LEI mondiale administrée par GLEIF. Le mandat pour son utilisation couvre plusieurs normes réglementaires : tandis que l'article 14 du RTS sur la tenue de registres (règlement délégué de la Commission UE 2025/1140) impose les exigences LEI aux CASP pour leurs clients, l'article 3 du RTS de classification des livres blancs (règlement délégué de la Commission UE 2025/421) exige strictement que tous les préparateurs de livres blancs identifient leur propre entité juridique avec un code LEI valide. Pour toute entité qui n'en détient pas encore un, le processus de demande LEI doit être terminé avant le début de la préparation du livre blanc.

Le second est le Digital Token Identifier (DTI), un code ISO 24165 qui identifie le crypto-actif lui-même, maintenu dans le registre DTIF. L'article 15 du RTS sur la tenue de registres et l'article 3 du RTS de classification des livres blancs (règlement délégué de la Commission UE 2025/421) exigent son utilisation. Le point opérationnel pour tout projet lançant un nouveau token : si le DTI n'existe pas encore dans le registre, quelqu'un doit demander sa création avant que le livre blanc puisse être soumis. Lorsqu'un CASP dépose pour un actif sans émetteur centralisé et sans livre blanc existant, la plateforme est responsable de la récupération ou de la demande du DTI directement auprès du DTIF.

Source : le registre DTIF pour les crypto-actifs

Un livre blanc qui ne contient pas un LEI et un DTI valides échoue à la validation automatisée avant qu'un examinateur humain ne le voie. Les projets qui atteignent l'étape de soumission sans ces deux codes en main font face à un redémarrage complet.

Le portail automatisé et ce qu'il signifie juridiquement

Aucun humain d'une autorité nationale compétente n'examine un livre blanc qui échoue à ses contrôles automatisés. La taxonomie de l'ESMA définit 257 contrôles d'existence (vérifiant que les champs requis sont présents) et 223 contrôles de valeur (vérifiant que le contenu du champ est valide). Un dépôt qui échoue à un contrôle classé de gravité « Erreur » est techniquement invalide. Le document ne progresse pas.

L'implication juridique de cette architecture est directe : la validité technique et l'exactitude du contenu sont également la responsabilité de l'offrant. Une divulgation juridique parfaitement rédigée dans la mauvaise structure échoue. Un fichier structurellement valide avec un contenu erroné échoue également ; il échoue simplement à une étape différente et avec des conséquences différentes.

Les projets offrant des tokens dans plusieurs États membres de l'UE sont confrontés à une couche supplémentaire. Chaque version linguistique du livre blanc nécessite son propre fichier structuré séparément. Toutes les versions linguistiques doivent être cohérentes en interne et non seulement traduites, mais organisées de manière identique au niveau du champ. Une traduction qui ne reflète pas la structure de l'original est techniquement non conforme, quelle que soit sa précision linguistique.

Les divulgations sur la durabilité ajoutent une contrainte supplémentaire. La taxonomie impose des unités de mesure spécifiques pour la consommation d'énergie et les émissions de CO2 : kWh et tCO2, respectivement. Ce sont des exigences de divulgation juridique, pas des rapports environnementaux optionnels. Le dépôt avec des unités différentes ou l'omission des champs déclenche un échec de validation.

Le schéma à travers toutes ces exigences est le même : le livre blanc est un dépôt juridique avec des normes appliquées par machine. Les projets qui l'abordent comme un exercice de rédaction de document, plutôt qu'un processus de conformité avec des prérequis structurés et un contrôle automatisé, rencontreront cette application avant d'atteindre un régulateur humain.

Ce que cela signifie en pratique

La compréhension populaire d'un livre blanc crypto comme un argumentaire narratif (quelque chose écrit pour persuader plutôt que pour divulguer) décrit un type de document que MiCA a remplacé par quelque chose de catégoriquement différent.

Le livre blanc MiCA est un instrument juridique avec un contenu prescrit, des identifiants obligatoires, un format structuré conçu pour la comparabilité transfrontalière automatisée, et une responsabilité personnelle nommée attachée à celui qui le valide. La porte d'entrée du marché crypto européen passe par lui. Les projets qui comprennent le dépôt pour ce qu'il est juridiquement, plutôt que ce que le terme suggérait historiquement, sont ceux qui ne se font pas refouler au contrôle automatisé.

Points clés à retenir :

• Le livre blanc n'est pas un document marketing. MiCA a redéfini le terme. L'équivalent le plus proche dans la finance traditionnelle est un prospectus de valeurs mobilières, et il doit être traité avec le même poids juridique.
• Trois catégories d'actifs, trois parcours différents. OTHR, ART et EMT comportent chacun des exigences de livre blanc distinctes et des prérequis d'autorisation différents. Les caractéristiques de l'actif déterminent quelle catégorie s'applique, le projet ne choisit pas.
• La responsabilité suit le déposant, mais les règles dépendent de l'actif. Pour la grande majorité des tokens (OTHR), l'obligation juridique appartient à l'offrant ou à la personne demandant l'admission à la négociation, pas nécessairement au créateur original du token. Lorsqu'un CASP (tel qu'un opérateur de plateforme de trading) accepte de préparer et de publier un livre blanc au nom d'un projet OTHR, il assume des obligations réglementaires importantes, mais n'assume pas entièrement la responsabilité. En vertu de l'article 14(3) de MiCA, la personne originale demandant l'admission à la négociation reste légalement responsable si elle fournit des informations incomplètes, injustes, peu claires ou erronées au CASP. Vous pouvez externaliser la paperasse, mais vous ne pouvez pas externaliser entièrement la responsabilité.
• Pour les Tokens référencés sur actifs (ART) et les Tokens de monnaie électronique (EMT), la responsabilité civile stricte pour le livre blanc ne repose pas uniquement sur l'émetteur autorisé en tant qu'entité juridique ; elle s'étend explicitement aux membres de son organe administratif, de gestion ou de surveillance. Toute tentative contractuelle de limiter ou d'exclure cette responsabilité est juridiquement nulle.
• LEI et DTI sont des prérequis. Les deux identifiants doivent être en place avant le début de la préparation du livre blanc. Si un DTI n'existe pas pour l'actif, il doit être demandé au registre DTIF avant que quoi que ce soit d'autre n'avance.
• La validation automatisée est le premier gardien. 257 contrôles d'existence et 223 contrôles de valeur s'exécutent avant qu'un humain n'examine le fichier. Un document qui échoue à une assertion de niveau Erreur n'atteint pas un régulateur.
• Les dépôts multilingues comportent une obligation technique cachée. Chaque version linguistique nécessite son propre fichier structuré séparément, organisé de manière identique à l'original. Une traduction qui ne correspond pas à la structure source au niveau du champ n'est pas conforme.
• L'exactitude du contenu et la validité technique sont deux obligations distinctes. L'examen juridique couvre la première. La structuration technique couvre la seconde. Les deux incombent à l'offrant, et aucune ne se substitue à l'autre.

Cet article est basé sur une étude menée par LegalBison en avril 2026. Le contenu est fourni à titre informatif uniquement et ne constitue pas un conseil juridique.