'Nous sommes dans le secteur de la DeFi, donc la MiCA ne s'applique pas à nous.' Désolé, mais l'ABE et l'AEMF ne sont pas du même avis

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 crypto et de FinTech sur les licences MiCA, les demandes CASP et VASP, ainsi que sur la structuration réglementaire en Europe et au-delà.

L'article de cette semaine a été rédigé par Eira Järvi, avocate senior chez LegalBison, qui dirige la recherche réglementaire mondiale et la mise en œuvre des licences CASP et d'autres licences complexes. Eira met activement en œuvre la recherche mondiale dans des produits destinés aux clients.

La DeFi en plein essor

La finance décentralisée (DeFi) est en plein essor depuis quelques années. Le secteur des cryptomonnaies assiste à l'émergence de nouveaux projets DeFi presque quotidiennement. Les nouveaux réseaux blockchain, protocoles et applications décentralisées (dApps) constituent un sujet de discussion récurrent parmi les passionnés de DeFi et dans les newsletters. Les débats tournent autour des thèmes de l'efficacité, de la transparence, de la composabilité, de la confidentialité et de l'accessibilité de la DeFi. Avec l'entrée en vigueur du MiCAR (règlement sur les marchés d'actifs cryptographiques), de nombreuses équipes de développement DeFi envisagent désormais d'étendre leurs projets aux marchés de l'UE. Cependant, dans ce contexte, un sujet reste plus crucial que tous les autres. Comment l'équipe s'assure-t-elle que le projet qu'elle développe est conforme à la législation ?

Pour la plupart des startups DeFi, la réponse peut sembler simple : le MiCAR prévoit une exemption pour les projets « entièrement décentralisés » sur laquelle de nombreuses startups s'appuient avec assurance pour justifier leur confiance dans le lancement de leurs projets au sein de l'UE sans solliciter aucun conseil juridique, et encore moins se conformer au MiCAR. Cet article vise à dissiper la croyance répandue selon laquelle si un projet est suffisamment décentralisé, le MiCAR ne concerne pas l'équipe. Désolé, mais les directives réglementaires démystifient ce mythe !

Le mythe : le MiCA n'affecte pas les prestataires de services DeFi et non dépositaires

L'article 3, paragraphe 1, point 1, du MiCAR définit la technologie des registres distribués (« DLT ») comme « une technologie qui permet le fonctionnement et l'utilisation de registres distribués », et le point 2 définit le « registre distribué » comme « un référentiel d'informations qui conserve les enregistrements des transactions et qui est partagé et synchronisé entre un ensemble de nœuds du réseau DLT à l'aide d'un mécanisme de consensus ».

Le considérant 22 du MiCAR fournit les orientations les plus cruciales concernant la relation entre la DeFi et le règlement. Il stipule que le MiCAR est conçu pour englober les services et activités exercés, fournis ou contrôlés, directement ou indirectement, par des personnes physiques ou morales et certaines entreprises fournissant des services liés aux crypto-actifs, même dans les cas où la décentralisation est en jeu.

Toutefois, le considérant contient la formulation cruciale suivante : « Lorsque les services liés aux crypto-actifs sont fournis de manière entièrement décentralisée sans aucun intermédiaire, ils ne devraient pas relever du champ d’application du présent règlement. » L’importance de cette disposition réside dans deux expressions clés : « entièrement décentralisée » et « sans aucun intermédiaire ». Le texte du règlement lui-même ne définit nulle part le terme « entièrement décentralisée » dans ses dispositions opérationnelles. La seule source de ce terme se trouve dans le considérant 22, qui fait partie du préambule plutôt que des dispositions formelles juridiquement contraignantes. Le considérant 83 prévoit en outre que « les fournisseurs de matériel ou de logiciels de portefeuilles non dépositaires ne devraient pas relever du champ d’application du présent règlement », sans définir explicitement dans quelle mesure la fourniture de matériel ou de logiciels constitue un service entièrement décentralisé exclu du champ d’application du MiCAR.

Le considérant 109 reconnaît ces difficultés d’interprétation et confie l’élaboration de projets de normes techniques de réglementation et d’exécution à l’Autorité bancaire européenne (« ABE ») et à l’Autorité européenne des marchés financiers (« AEMF »).

Pour déterminer si des services relèvent du champ d'application du MiCAR, deux conditions peuvent être dégagées du considérant 22 et des orientations réglementaires qui s'ensuivent :

• Premièrement, aucune entité ne peut exercer de contrôle sur les paramètres du protocole, les mécanismes de gouvernance ou l’infrastructure technologique de base sur laquelle le service de crypto-actifs opère.
• Deuxièmement, les utilisateurs doivent accéder à ce qui constitue une « ressource d'intérêt général » plutôt que d'acheter des services auprès d'un prestataire désigné avec lequel existe une relation contractuelle de prestation de services.

Ces conditions sont essentielles pour déterminer si un projet DeFi relève ou non du champ d'application de la MiCAR.

Le piège de la surestimation du degré de décentralisation

Dans un monde caractérisé par l’émergence rapide de nouvelles technologies, l’instabilité géopolitique et la fragmentation des systèmes financiers dépendant de processus manuels et d’intermédiaires, la DeFi offre une solution transparente et sans frontières qui modifie fondamentalement la manière dont les transactions sont initiées, traitées et exécutées. Au lieu des modèles de systèmes financiers traditionnels où les transactions doivent d'abord passer par un certain nombre d'intermédiaires et d'infrastructures institutionnelles avant d'être exécutées et réglées, dans la DeFi, les utilisateurs effectuent des transactions en interagissant directement avec le réseau blockchain sous-jacent via des protocoles et des interfaces décentralisés, éliminant ainsi le besoin d'intermédiaires et d'infrastructures système complexes.

Dans le monde du droit on-chain, la frontière entre la décentralisation totale et son absence est plus ténue qu’il n’y paraît. Avant que tout travail ne puisse commencer, un avocat travaillant sur un projet Web3 décentralisé déterminera d’abord si le projet peut être considéré comme décentralisé en analysant et en évaluant les couches du projet, leur état de décentralisation, ainsi que les plans de l’équipe concernant la propriété et la gouvernance.

À ce stade initial de l’élaboration de la stratégie juridique, de nombreux éléments techniques et architecturaux doivent être évalués par un avocat afin de parvenir à un accord définitif sur l’état de décentralisation du projet. Alors que l’équipe peut être convaincue que son projet est entièrement décentralisé, avec tous ses éléments, tels que la DLT, le protocole et la dApp, en réalité, l’évaluation initiale peut révéler le contraire.

Pour parvenir à une véritable décentralisation totale, tous les éléments du projet doivent répondre aux critères d’autonomie totale et d’absence d’influence interne ou externe dans l’ensemble de l’écosystème du projet et de ses nombreux éléments, y compris, mais sans s’y limiter, la gouvernance, la propriété, les interfaces, etc., ce que, à y regarder de plus près, très peu de projets parviennent à réaliser. Cette conclusion peut être illustrée au mieux par un événement récent dans le monde de la DeFi. Le 21 avril 2026, le Conseil de sécurité d'Arbitrum a gelé plus de 30 ETH (environ 71 millions de dollars) liés à l'exploitation de Kelp DAO. Un organe directeur composé de 12 membres a pu réagir à cette compromission en transférant les fonds vers un portefeuille intermédiaire, dont la libération ne peut se faire qu'à l'issue d'un vote de gouvernance, ce qui a effectivement bloqué les fonds dans ce portefeuille.

Cet exemple met en évidence l’existence d’un contrôle opérationnel discrétionnaire : même si Arbitrum est, par définition, un réseau de couche 2 sans autorisation et apparemment entièrement décentralisé, l’exercice d’un contrôle sur les actifs des utilisateurs est précisément ce qui ferait échouer le test de décentralisation totale de MiCAR. Dans ce cas, c’est la prévalence du fond sur la forme qui détermine le champ d’application réglementaire, indépendamment du caractère sans autorisation du registre sous-jacent.

Ainsi, une simple affirmation selon laquelle un projet DeFi est entièrement décentralisé ne suffit pas à exclure l’obligation de se conformer à la directive MiCAR et d’obtenir l’autorisation nécessaire en tant que CASP. Les juristes évalueront principalement l’architecture technique du projet, la logique de propriété et les règles de gouvernance, ce qui signifie qu’ils privilégieront l’évaluation de la prééminence du fond sur la forme plutôt que la sémantique. Les organismes de réglementation européens, tels que l'Autorité bancaire européenne (ABE) et l'Autorité européenne des marchés financiers (AEMF), soutiennent pleinement cette approche.

Le point de vue de l'AEMF et de l'ABE sur la DeFi

Le point de vue de l'AEMF sur la finance décentralisée a considérablement évolué à travers de multiples séries de consultations et, surtout, grâce au rapport conjoint avec l'ABE sur les développements récents en matière de crypto-actifs publié le 13 janvier 2025 (ESMA75-453128700-1391 / EBA/Rep/2025/01), élaboré conformément à l'article 142 de la directive MiCAR.

Le raisonnement de l’AEMF concernant le spectre de la décentralisation est fondamental pour cette évaluation. Dans son deuxième ensemble de consultations sur les normes techniques de réglementation et de mise en œuvre, l’AEMF a proposé une définition de la « technologie de registre distribué sans autorisation » comme « une technologie qui permet le fonctionnement et l’utilisation de registres distribués dans lesquels aucune entité ne contrôle le registre distribué ou son utilisation, ni ne fournit de services essentiels pour l’utilisation de ce registre distribué, et où les nœuds du réseau DLT peuvent être mis en place par toute personne respectant les exigences techniques et les protocoles ».

Cette définition s’inspire du document de consultation du Conseil de stabilité financière, qui établit une distinction entre la DLT sans autorisation (entièrement décentralisée), la DLT avec autorisation permettant un certain degré de centralisation, et les plateformes centralisées. L’AEMF reconnaît que « la portée exacte de cette exemption reste incertaine » et estime qu’une évaluation de chaque système devrait être effectuée au cas par cas, en tenant compte des caractéristiques du système.

L’AEMF reconnaît que la décentralisation n’est pas un concept binaire mais s’inscrit dans un continuum allant de la centralisation à divers degrés de décentralisation : « Avec les DEX, la blockchain remplace l’intermédiaire. Les DEX utilisent un code autonome (souvent appelé « contrats intelligents ») pour exécuter des transactions directement sur la couche de règlement de la blockchain (avec des degrés de décentralisation variables). »

Le rapport conjoint de janvier 2025 fournit des données empiriques étayant le cadre analytique. La DeFi représente environ 4 % de la capitalisation boursière mondiale des crypto-actifs, avec des taux de pénétration légèrement plus élevés observés chez les utilisateurs basés dans l’UE. Le rapport confirme que très peu de systèmes DeFi parviennent à une décentralisation véritablement complète au sens envisagé par le considérant 22. Le rapport identifie que même les protocoles ostensiblement décentralisés comportent généralement des entités identifiables qui exercent des degrés variables de contrôle sur la gouvernance, les mises à niveau du protocole, le déploiement des contrats intelligents et les structures tarifaires.

En ce qui concerne les fournisseurs de matériel et de logiciels proposant des services auxiliaires aux CASP, la position qui se dégage des orientations de l’AEMF est que les entités qui se contentent de créer et de vendre des outils de développement logiciel, des applications ou des plateformes pour la fourniture ou le négoce de crypto-actifs ne sont pas automatiquement classées comme CASP si leurs activités se limitent à la création et à la vente desdits services.

Toutefois, les entités supervisant la création et le développement de logiciels ou de plateformes destinés à fournir des services liés aux crypto-actifs peuvent être considérées comme des CASP si elles conservent un contrôle ou une influence suffisante sur les crypto-actifs, les logiciels, le protocole, la plateforme ou les relations commerciales avec les utilisateurs. Le critère déterminant est donc celui du contrôle et de l’influence plutôt que la simple implication technologique.

Le rôle des relations contractuelles dans la définition de la décentralisation totale est encore souligné par l’analyse de l’AEMF de l’article 73 du MiCAR, qui concerne l’externalisation de services ou d’activités à des tiers. L’AEMF conclut qu’il n’existe aucune base juridique permettant de classer les DLT sans autorisation utilisées par les CASP comme des prestataires tiers, car aucune relation contractuelle formelle n’est requise pour interagir avec des blockchains sans autorisation. Cela conduit à la conclusion importante selon laquelle les DLT sans autorisation peuvent être considérées comme une forme de ressource d’« intérêt général », tandis que les DLT autorisées exploitées par des entreprises commerciales impliquent généralement des accords contractuels formels et constituent donc une relation de « fournisseur tiers ». Cette distinction est le fondement de l’évaluation approfondie présentée dans le présent mémorandum.

Le rapport conjoint aborde en outre les risques liés au blanchiment de capitaux et au financement du terrorisme (ML/TF) ainsi que les considérations relatives aux TIC applicables aux systèmes décentralisés. L'absence de contrôles traditionnels en matière de lutte contre le blanchiment de capitaux et le financement du terrorisme (AML/CFT) dans les systèmes purement décentralisés soulève d'importantes préoccupations réglementaires, car les procédures de connaissance du client et la surveillance des transactions sont généralement absentes ou incomplètes. Le rapport note que les risques liés aux TIC figurent parmi les principales préoccupations, la majorité des pertes financières liées à la DeFi étant attribuables à des vulnérabilités des contrats intelligents, à la manipulation des oracles et à des attaques de front-running, y compris l’exploitation de la valeur maximale extractible (« MEV »). Ces facteurs de risque, bien qu’ils ne soient pas déterminants pour la classification réglementaire, éclairent l’approche de surveillance des entités opérant à différents niveaux du spectre de la décentralisation.

Cadre du GAFI et relations contractuelles

Les orientations du GAFI sur les prestataires de services d'actifs virtuels (VASP) et la DeFi fournissent un cadre analytique fondamental qui a été adopté et développé par l'AEMF. Selon les lignes directrices actualisées du GAFI pour une approche fondée sur les risques concernant les actifs virtuels et les prestataires de services d’actifs virtuels (octobre 2021), une personne qui crée ou vend une application logicielle ou une plateforme d’actifs virtuels peut ne pas être considérée comme un prestataire de services d’actifs virtuels lorsqu’elle se consacre exclusivement à la création ou à la vente de l’application ou de la plateforme, l’accent étant mis sur le mot « exclusivement ».

Dans les cas où les créateurs, propriétaires, opérateurs ou autres personnes semblent exercer un contrôle ou une influence suffisante sur des dispositifs DeFi, même si ces dispositifs semblent décentralisés, ils peuvent relever de la définition du GAFI d’un prestataire de services d’actifs virtuels (VASP) s’ils fournissent ou facilitent activement des services de VASP. Le contrôle ou l’influence significative peut se manifester par le contrôle des actifs ou de certains aspects du protocole du service, ainsi que par une relation commerciale continue entre l’opérateur et les utilisateurs, même si ce contrôle est exercé par le biais d’un contrat intelligent ou, dans certains cas, par le biais de protocoles de vote. Le raisonnement du GAFI jette les bases de l’évaluation de la décentralisation au titre du MiCAR en établissant deux principes essentiels :

• Premièrement, les propriétaires et les opérateurs, ainsi que leur degré de contrôle sur la DeFi, peuvent souvent être identifiés par leur relation avec les activités menées plutôt que par les étiquettes appliquées à l'arrangement.
• Deuxièmement, une centralisation partielle ne peut être automatiquement exclue, même si des parties autres que le principal prestataire de services sont impliquées dans le service ou si certaines parties du processus sont automatisées par le biais de contrats intelligents.

Le rôle des relations contractuelles dans l’évaluation de la décentralisation mérite une attention particulière. L’article 73 du MiCAR, qui concerne l’externalisation de services ou d’activités à des tiers pour l’exécution de fonctions opérationnelles, réglemente la manière dont les CASP doivent gérer les risques associés aux prestataires tiers.

Toutefois, comme le reconnaît le deuxième document de consultation de l’AEMF, il n’existe aucune base juridique permettant de classer les DLT sans autorisation utilisées par les CASP comme des prestataires tiers, car aucune relation contractuelle formelle, telle qu’un accord de niveau de service, n’est requise pour interagir avec des blockchains sans autorisation. L'AEMF conclut que les DLT sans autorisation peuvent être considérées comme une forme de ressource d'« intérêt général », tandis que les DLT autorisées exploitées par des entreprises commerciales impliquent généralement des contrats disponibles pour des produits blockchain en marque blanche, constituant ainsi une relation de prestataire tiers.

Cette conclusion a des implications profondes pour l’évaluation réglementaire des plateformes construites sur une infrastructure sans autorisation. Si une plateforme déploie des contrats intelligents sur une blockchain sans autorisation telle qu’Ethereum, l’utilisation de cette infrastructure blockchain n’établit pas, en soi, une relation de prestataire de services tiers.

Toutefois, si l’opérateur de la plateforme conserve le contrôle des contrats intelligents, peut mettre à niveau ou modifier leurs fonctionnalités, contrôle l’accès à l’interface frontale ou détient des clés administratives permettant de suspendre, de geler ou de modifier le protocole, ces éléments centralisés font entrer l’opérateur dans le champ d’application du MiCAR, quelle que soit la nature sans autorisation du registre sous-jacent.

Le critère est donc fonctionnel plutôt que technologique : il s'agit de déterminer quel contrôle l'opérateur exerce réellement, et non sur quelle technologie le système est construit.

Points clés à retenir :

Compte tenu de l’analyse qui précède, et en particulier du raisonnement de l’AEMF tel qu’il est exposé dans les documents de consultation et le rapport conjoint de janvier 2025, nous estimons que les propositions suivantes s’appliquent aux fins de la présente évaluation.

• Premièrement, tant qu’aucun individu ou entité ne contrôle un protocole ou une plateforme DeFi et son utilisation, et qu’aucun individu ne remplit un rôle fondamental et indispensable à son fonctionnement sans lequel la technologie ne peut être utilisée, le protocole ou la plateforme DeFi peut être considéré comme exempté du champ d’application de la MiCAR en vertu du fait qu’il est « entièrement décentralisé » au sens du considérant 22.
• Deuxièmement, le simple développement de logiciels ou d’outils auxiliaires pour les CASP n’est pas considéré comme un service de crypto-actifs, à moins que des aspects supplémentaires réglementés par la MiCAR, tels que l’influence sur l’offre, la vente, le transfert, la conservation ou la négociation de crypto-actifs, ne soient inclus dans le champ des activités menées par le développeur.

Toutefois, l'application pratique de ces principes à tout projet DeFi nécessite un examen minutieux de la gouvernance effective et des caractéristiques opérationnelles de son écosystème. Si l'architecture d'un projet indique un contrôle centralisé sur l'émission de jetons, les paramètres du protocole ou la gouvernance de l'écosystème, il est peu probable qu'il satisfasse à l'exemption de « décentralisation totale » du considérant 22, et les services fournis en relation avec un tel projet doivent être évalués au regard des dispositions du MiCAR.

Ce que nous avons déduit

L'exemption « entièrement décentralisée » est extrêmement restrictive : le considérant 22 du MiCA stipule que les services fournis de manière « entièrement décentralisée sans aucun intermédiaire » ne relèvent pas du champ d'application du règlement, mais il est extrêmement rare d'atteindre ce véritable état de décentralisation totale. Si une seule entité exerce un contrôle sur la gouvernance, les paramètres du protocole ou l'infrastructure de base, l'exemption ne s'applique pas.

La substance prime sur la forme pour déterminer la conformité : les régulateurs ne se limitent pas aux arguments marketing et à la sémantique technique pour évaluer le contrôle opérationnel réel. Le critère réglementaire est fonctionnel, et non technologique : si un opérateur détient des clés administratives, contrôle l’interface frontale ou a la capacité de mettre à jour ou de suspendre des contrats intelligents, il relève du champ d’application du MiCA.

La décentralisation s'inscrit dans un continuum : l'AEMF ne considère pas la décentralisation comme un concept binaire. Même si un projet repose largement sur du code autonome et des contrats intelligents, la présence d'entités identifiables exerçant divers degrés de contrôle sur les structures tarifaires, les mises à niveau du protocole ou la gouvernance déclenchera un examen réglementaire.

Les blockchains sans autorisation sont des « biens communs » : le fait de s'appuyer sur une blockchain publique et sans autorisation n'établit pas de relation formelle d'externalisation à un tiers au sens de l'article 73 de la MiCA, car l'AEMF les classe comme des ressources de « biens communs ». Cependant, le déploiement de contrats intelligents sur une infrastructure de biens communs ne protège pas l'opérateur de la plateforme de la MiCA s'il conserve un contrôle fonctionnel sur ces contrats.

Les développeurs de logiciels ne sont pas automatiquement des CASP : le simple fait de créer et de vendre des logiciels ou du matériel non dépositaires ne classe pas automatiquement une entité comme prestataire de services d'actifs cryptographiques (CASP). Toutefois, si les développeurs ou les opérateurs conservent une influence suffisante sur les actifs cryptographiques, la plateforme ou les relations commerciales en cours avec les utilisateurs, ils franchissent le seuil réglementaire et seront réglementés en tant que CASP.

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.