Propulsé par
Legal

MiCA décrypté : votre livre blanc sur les cryptomonnaies ne peut pas se limiter à un Gitbook ou à un PDF

Lorsque la plupart des gens entendent parler d’un « livre blanc » sur les cryptomonnaies, ils pensent au document de neuf pages de Satoshi Nakamoto, ou à un dossier de présentation de l’époque des ICO rédigé dans un jargon technique. La MiCA en donne une définition différente, et c’est précisément dans ce décalage entre la perception courante et la réalité juridique que naissent de nombreux manquements en matière de conformité.

ÉCRIT PAR
PARTAGER
MiCA décrypté : votre livre blanc sur les cryptomonnaies ne peut pas se limiter à un Gitbook ou à un PDF

« MiCA Decoded » est une série hebdomadaire de 12 articles pour Bitcoin.com News, co-rédigée par les cofondateurs et directeurs généraux de LegalBison : Aaron Glauberman, Viktor Juskin et Sabir Alijev. LegalBison conseille les entreprises de cryptomonnaie et de FinTech sur les licences MiCA, les demandes CASP et VASP, ainsi que sur la structuration réglementaire en Europe et au-delà.

Dans le cadre de la MiCA, un livre blanc est un instrument de divulgation légale obligatoire. Son équivalent le plus proche dans la finance traditionnelle est un prospectus de valeurs mobilières, et non un document marketing. La réglementation prescrit qui doit en préparer un, sous quel format, contenant quels identifiants, soumis à quelle validation automatisée, et avec une responsabilité attachée à une personne nommément désignée.

Si l'un de ces éléments est erroné, 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écrypte ce que cela signifie concrètement, point par point.

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

Un livre blanc MiCA a le poids d’un document réglementaire officiel. Le règlement d’exécution (UE) 2024/2984 de la Commission, qui régit les formulaires, les formats et les modèles des livres blancs sur les crypto-actifs, exige que le document soit préparé dans un format numérique structuré conçu de manière à ce que l’AEMF 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 son auteur ou son lieu d’origine.

L'objectif juridique de ce choix de conception prime sur les spécificités techniques. La MiCA est une réglementation du marché unique, et la comparabilité entre les déclarations constitue 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 son contenu. L'AEMF a publié la taxonomie requise (le cadre structuré définissant ce qu'un livre blanc conforme doit contenir) le 5 août 2025. Les règles s'appliquent à compter du 23 décembre 2025. Les obligations de divulgation varient en fonction du type de crypto-actif concerné. La MiCA distingue trois catégories distinctes, chacune avec son propre modèle de livre blanc et ses propres exigences en matière de champs :

La catégorie détermine non seulement le contenu du livre blanc, mais aussi l'ensemble de la procédure juridique à suivre pour en déposer un. Un projet ne peut pas choisir la catégorie qui s'applique en fonction de ses préférences. Ce sont les caractéristiques de l'actif qui la déterminent, et les obligations de préparation en découlent.

Qui assume l'obligation légale – et la responsabilité

Pour la grande majorité des jetons sur le marché (classés dans la catégorie des « autres » crypto-actifs, ou OTHR), l'obligation n'incombe pas automatiquement à l'entité qui a créé le jeton. Pour ces actifs, la MiCA impose cette obligation à 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 d'origine.

Cette distinction a des conséquences concrètes. Un projet relevant de la catégorie OTHR, lancé depuis les Îles Vierges britanniques, les îles Caïmans ou toute autre juridiction offshore, peut être considéré comme l’offrant au sens de la MiCA et assumer directement l’obligation relative au livre blanc, sans avoir à transférer son siège social en Europe.

(Remarque : cette flexibilité structurelle s'applique strictement aux jetons OTHR. Pour les jetons référencés à des actifs et les jetons de monnaie électronique, l'obligation légale et la responsabilité civile stricte relatives au livre blanc incombent entièrement à 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'AEMF confirment qu'il s'agit déjà d'une pratique courante : la majorité des déclarations de jetons indépendantes proviennent d'entités dont le siège social est situé en dehors de l'UE.

Un CASP exploitant une plateforme de négociation peut également assumer l'obligation relative au livre blanc, soit de sa propre initiative, soit par accord écrit avec l'équipe du projet. Il ne s'agit ni d'une faille juridique ni d'une commodité administrative. Lorsqu'un CASP effectue un dépôt, il assume la responsabilité juridique de l'exactitude et de l'exhaustivité des informations divulguées. Si le livre blanc contient des informations trompeuses ou ne respecte pas les normes réglementaires, la responsabilité incombe à la personne qui l'a soumis.

La personne qui valide le livre blanc ne peut pas déléguer cette responsabilité à un fournisseur 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'émetteur. C'est le point que la plupart des projets sous-estiment.

Deux codes indispensables avant le dépôt

MiCA Decoded: Your Crypto White Paper Can’t Just Be a Gitbook or PDF

Deux identifiants obligatoires sont indispensables à tout livre blanc conforme. Tous deux sont issus de normes internationales antérieures à la MiCA. La réglementation ne les a pas créés, elle les a rendus obligatoires.

Le premier est l’identifiant d’entité juridique (LEI), un code ISO 17442 attribué aux entités juridiques et conservé dans la base de données Global LEI gérée par la GLEIF. L’obligation de l’utiliser s’étend à plusieurs normes réglementaires : alors que l’article 14 de la norme technique d’exécution (RTE) relative à la tenue des registres (règlement délégué (UE) 2025/1140 de la Commission) impose des exigences en matière de LEI aux CASP pour leurs clients, l'article 3 du RTS sur la classification des livres blancs (règlement délégué (UE) 2025/421 de la Commission) impose strictement à tous les rédacteurs de livres blancs d'identifier leur propre entité juridique à l'aide d'un code LEI valide. Pour toute entité qui n'en possède pas encore, la procédure de demande de LEI doit être menée à bien avant le début de la rédaction du livre blanc.

Le second est l'identifiant de jeton numérique (DTI), un code ISO 24165 qui identifie le crypto-actif lui-même, conservé dans le registre DTIF. L'article 15 de la RTS relative à la tenue des registres et l'article 3 de la RTS relative à la classification des livres blancs (règlement délégué (UE) 2025/421 de la Commission) en exigent l'utilisation. Point essentiel pour tout projet lançant un nouveau jeton : si le DTI n'existe pas encore dans le registre, quelqu'un doit en demander la création avant que le livre blanc puisse être soumis. Lorsqu'un CASP dépose une demande pour un actif sans émetteur centralisé et sans livre blanc existant, la plateforme est chargée de récupérer ou de demander le DTI directement auprès du DTIF.

MiCA Decoded: Your Crypto White Paper Can’t Just Be a Gitbook or PDF

Source : le registre DTIF des crypto-actifs Un livre blanc qui ne contient pas de LEI et de DTI valides échoue à la validation automatisée avant même qu'un réviseur humain ne l'examine. Les projets qui atteignent la phase de soumission sans disposer de ces deux codes doivent tout recommencer depuis le début.

La barrière automatisée et ses implications juridiques

Aucun agent humain d'une autorité nationale compétente n'examine un livre blanc qui échoue aux contrôles automatisés. La taxonomie de l'AEMF définit 257 contrôles d'existence (vérifiant que les champs obligatoires sont présents) et 223 contrôles de valeur (vérifiant que le contenu des champs est valide). Un dépôt qui échoue à un contrôle classé comme « Erreur » est techniquement invalide. Le document n'est pas traité.

L'implication juridique de cette architecture est directe : la validité technique et l'exactitude du contenu relèvent toutes deux de la responsabilité de l'émetteur. Une divulgation juridique parfaitement rédigée mais présentant une structure incorrecte échoue. Un fichier structurellement valide mais dont le contenu est trompeur échoue également ; il échoue simplement à une étape différente et avec des conséquences différentes.

Les projets proposant des jetons dans plusieurs États membres de l’UE sont confrontés à une contrainte 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 ne pas se limiter à une simple traduction, mais être organisées de manière identique au niveau des champs. Une traduction qui ne reflète pas la structure de l’original est techniquement non conforme, quelle que soit son exactitude linguistique.

Les informations relatives à 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 : respectivement le kWh et le tCO2. Il s'agit d'exigences légales en matière de divulgation, et non de rapports environnementaux facultatifs. Le dépôt avec des unités différentes ou l'omission de champs entraîne un échec de validation.

MiCA Decoded: Your Crypto White Paper Can’t Just Be a Gitbook or PDF

Le schéma est le même pour toutes ces exigences : le livre blanc est un document légal soumis à des normes appliquées automatiquement. Les projets qui l'abordent comme un simple exercice de rédaction, plutôt que comme un processus de conformité comportant des prérequis structurés et un contrôle automatisé, se heurteront à cette application avant même d'atteindre un régulateur humain.

Ce que cela signifie dans la pratique

La conception courante du livre blanc crypto comme un argumentaire narratif (un texte rédigé pour persuader plutôt que pour divulguer) décrit un type de document que la MiCA a remplacé par quelque chose de radicalement différent.

Le livre blanc MiCA est un instrument juridique doté d’un contenu prescrit, d’identifiants obligatoires, d’un format structuré conçu pour permettre une comparabilité transfrontalière automatisée, et d’une responsabilité personnelle nominative attachée à toute personne qui le valide. C’est par là que passe la porte d’entrée du marché européen des cryptomonnaies. Les projets qui comprennent ce qu’est juridiquement ce dépôt, plutôt que ce que le terme suggérait historiquement, sont ceux qui ne se font pas refouler lors du contrôle automatisé.

Tout savoir sur la MiCA : le 1er juillet n'est pas la date limite. Pour la plupart des prestataires de services, elle est déjà dépassée

Tout savoir sur la MiCA : le 1er juillet n'est pas la date limite. Pour la plupart des prestataires de services, elle est déjà dépassée

« MiCA Decoded » est une série hebdomadaire de 12 articles publiée sur Bitcoin.com News, rédigée conjointement par les cofondateurs et directeurs généraux de LegalBison. read more.

Lire

Points clés à retenir :

  • Le livre blanc n'est pas un document marketing. La MiCA a redéfini ce terme. Son équivalent le plus proche dans la finance traditionnelle est le prospectus de valeurs mobilières, et il doit être traité avec le même poids juridique.
  • Trois catégories d'actifs, trois voies différentes. Les OTHR, ART et EMT sont soumis à des exigences distinctes en matière de livre blanc et à des conditions préalables d'autorisation différentes. Ce sont les caractéristiques de l'actif qui déterminent la catégorie applicable, et non le projet.
  • La responsabilité incombe au déposant, mais les règles dépendent de l'actif. Pour la grande majorité des jetons (OTHR), l'obligation légale incombe à l'offrant ou à la personne demandant l'admission à la négociation, et non nécessairement au créateur initial du jeton. Lorsqu’un CASP (tel qu’un opérateur de plateforme de négociation) accepte de préparer et de publier un livre blanc pour le compte d’un projet OTHR, il assume des obligations réglementaires importantes, mais n’assume pas l’intégralité de la responsabilité. En vertu de l’article 14, paragraphe 3, de la MiCA, la personne à l’origine de la demande d’admission à la négociation reste légalement responsable si elle fournit des informations incomplètes, inéquitables, imprécises ou trompeuses au CASP. Vous pouvez externaliser les formalités administratives, mais vous ne pouvez pas externaliser entièrement la responsabilité.
  • Pour les jetons référencés sur des actifs (ART) et les jetons de monnaie électronique (EMT), la responsabilité civile stricte relative au livre blanc n'incombe pas uniquement à l'émetteur agréé en tant que personne morale ; elle s'étend explicitement aux membres de son organe d'administration, de gestion ou de surveillance. Toute tentative contractuelle visant à limiter ou à exclure cette responsabilité est juridiquement nulle.
  • Le LEI et le DTI sont des conditions préalables. Ces deux identifiants doivent être en place avant que la préparation du livre blanc ne commence. Si aucun DTI n'existe pour l'actif, il doit être demandé au registre DTIF avant que toute autre démarche ne puisse être entreprise.
  • La validation automatisée est le premier filtre. 257 contrôles d'existence et 223 contrôles de valeur sont effectués avant que le dossier ne soit examiné par un humain. Un document qui échoue à une assertion de niveau « Erreur » n'est pas transmis à l'autorité de régulation.
  • 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 des champs n'est pas conforme.
  • L'exactitude du contenu et la validité technique sont deux obligations distinctes. La révision juridique couvre la première. La structuration technique couvre la seconde. Les deux incombent à l'émetteur, et aucune ne se substitue à l'autre.

MiCA Decoded: Your Crypto White Paper Can’t Just Be a Gitbook or PDF

Cet article s'appuie sur une étude menée par LegalBison en avril 2026. Son contenu est fourni à titre informatif uniquement et ne constitue pas un avis juridique.

Tags dans cet article