Ce qui déclenche réellement les obligations MiCA pour les fondateurs crypto

Ce qui déclenche réellement les obligations MiCA

Une équipe est basée en Europe et construit un protocole DeFi. Il n'y a eu ni vente publique de tokens, ni prévente privée, ni levée de fonds libellée en euros, ni messaging d'investissement évident. Le token existe pour coordonner l'activité au sein du système. La documentation est en anglais parce que l'anglais est la langue par défaut de la crypto. Le site est public parce que tout en crypto est public. Il n'y a pas d'entité d'exploitation dans l'UE. Du point de vue des fondateurs, rien dans tout cela ne ressemble à une émission régulée ou à de la promotion financière.

Quand MiCA est évoqué, ils supposent qu'il s'applique aux plateformes d'échange centralisées, aux dépositaires et aux grands lancements grand public. Dans leur modèle mental, MiCA porte sur des étiquettes. Valeurs mobilières. Stablecoins. Ventes de tokens. Quelque chose d'explicite et d'intentionnel. Ils croient que MiCA est déclenché par l'objet.

Puis leur avocat demande où se trouve le livre blanc conforme à MiCA. Les fondateurs expliquent qu'ils ne vendent pas de token, ne ciblent pas l'Europe et n'offrent pas d'investissement. L'avocat explique que rien de tout cela n'est décisif. Ce qui compte, c'est que les utilisateurs de l'UE peuvent accéder au protocole, acquérir le token et l'utiliser. Cette seule combinaison peut déjà constituer une offre au public sous MiCA. C'est à ce moment que beaucoup de fondateurs rencontrent pour la première fois la véritable structure de MiCA. MiCA n'est pas déclenché par la manière dont vous appelez votre token. Il est déclenché par ce que votre système fait.

MiCA opère sur un modèle comportemental. Les régulateurs partent de la réalité observable, non du récit. L'analyse commence par ce qui se passe en pratique, non par la manière dont un projet se décrit. Une fois certains seuils comportementaux franchis, la question cesse d'être si MiCA s'applique et devient quelle catégorie MiCA s'applique.

À haut niveau, MiCA attache des obligations à trois types d'activité. Mettre des crypto-actifs à la disposition du public dans l'UE. Demander l'admission de crypto-actifs à la négociation sur des lieux de l'UE. Fournir des services sur crypto-actifs à titre commercial. Ces catégories sont délibérément larges et résistantes à l'évitement sémantique. Un token peut être appelé token utilitaire, token de gouvernance, clé d'accès ou système de points. Aucune de ces étiquettes ne détermine le traitement réglementaire. Ce qui compte, c'est si les personnes de l'UE peuvent l'obtenir et si le projet facilite significativement ce processus.

Cela représente une rupture structurelle avec les hypothèses réglementaires crypto antérieures. Pendant des années, les projets se sont appuyés sur la logique de sollicitation inversée. Si les utilisateurs découvraient indépendamment un protocole et choisissaient d'interagir, les équipes soutenaient qu'aucune offre n'avait eu lieu. Cette doctrine a toujours été fragile. Sous MiCA et les orientations ESMA qui ont suivi, elle est désormais largement inutilisable.

Sollicitation inversée et disponibilité passive

Les lignes directrices de l'ESMA de février 2025 indiquent que la sollicitation inversée doit relever entièrement de la propre initiative du client et n'impliquer aucune sollicitation de la part du prestataire. En pratique, cela place la barre extrêmement haut. Une simple présence de marque générique peut déjà empoisonner l'exemption. Du contenu éducatif sur un protocole accessible aux utilisateurs de l'UE peut compter comme sollicitation. Une présence sur les réseaux sociaux, même sans appel à l'action, peut annuler l'exemption. Dès qu'une sollicitation a lieu, toutes les transactions ultérieures relèvent de MiCA.

La conséquence pratique est simple. Si un projet exploite un site web public, publie de la documentation et permet aux utilisateurs de l'UE d'accéder à une infrastructure qu'il contrôle, la sollicitation inversée n'offre aucune protection significative. À moins qu'un projet n'ait une présence accessible depuis l'UE quasi nulle et que tous les accès utilisateur passent par des tiers indépendants, la doctrine ne fonctionne pas.

Sous MiCA, la disponibilité passive combinée à l'accessibilité pour les utilisateurs de l'UE peut suffire à constituer une offre au public. Si un site se charge dans l'UE, si la documentation est lisible, si les interfaces ne sont pas géobloquées et si les tokens peuvent être acquis via des flux que le projet contrôle ou influence fortement, les régulateurs peuvent y voir une offre. Aucun marketing actif n'est requis. Aucune publicité ciblée n'est requise. Aucune intention n'est requise.

Les régulateurs regardent des signaux factuels cumulatifs. Des sites se chargeant sans géoblocage. Une documentation disponible pour les utilisateurs de l'UE, en particulier en langues locales. L'intégration de moyens de paiement européens comme le SEPA ou des cartes émises dans l'UE. Une présence sur les réseaux sociaux ou auprès d'influenceurs orientée UE. Des sous-domaines ou rubriques spécifiques à un pays. Des contacts ou canaux de support clients dans l'UE. La construction de marque par des événements ou publications européens. Aucun de ces éléments ne garantit individuellement le statut d'émetteur. Ensemble, ils forment un faisceau d'indices.

MiCA est entré en pleine application le 30 décembre 2024. Depuis, l'ESMA a publié des orientations confirmant explicitement que la disponibilité passive peut constituer une offre au public et que l'exemption de sollicitation inversée est très étroitement encadrée et ne peut servir à contourner MiCA. La direction est cohérente. Si les tokens sont mis à disposition des utilisateurs de l'UE sans restriction significative, des obligations peuvent naître.

Livres blancs, catégories de tokens et couche de services

Une fois qu'un projet est traité comme faisant une offre, l'exigence de livre blanc apparaît. Un livre blanc MiCA n'est pas un document marketing. C'est une information réglementaire. Il identifie l'émetteur. Décrit le crypto-actif. Expose les droits et fonctionnalités. Explique les risques. Décrit le fonctionnement du système. Une fois publié, il devient un point de référence pour l'application de la loi.

Cela crée une surface de responsabilité que les fondateurs sous-estiment constamment. Chaque affirmation sur la fonctionnalité devient opposable. Une divergence entre les déclarations du livre blanc et le comportement réel du token constitue une fausse déclaration. Des votes de gouvernance ou décisions de DAO qui changent la fonctionnalité n'excusent pas les violations du livre blanc. Les informations sur l'impact environnemental relatives à la consommation énergétique sont obligatoires et auditables. La direction doit signer des déclarations de responsabilité confirmant l'exactitude sous peine de sanctions.

Beaucoup de projets traitent les livres blancs comme des documents marketing évolutifs qui suivent le produit. Sous MiCA, le livre blanc est le fondement de la responsabilité réglementaire dès le premier jour. Les projets dont l'historique d'exploitation s'étend sur plusieurs années découvrent souvent que leurs tokens ont évolué au-delà de ce que tout livre blanc conforme pourrait décrire en sécurité.

MiCA distingue entre tokens utilitaires, jetons se référant à des actifs et jetons de monnaie électronique. Les tokens utilitaires donnent accès à des biens ou services. Les jetons se référant à des actifs (ART) tentent de stabiliser la valeur en référence à plusieurs actifs. Les jetons de monnaie électronique (EMT) se réfèrent à une seule monnaie fiat et fonctionnent comme de la monnaie électronique. Ces catégories déterminent les obligations de capital, de réserve, de gouvernance et de supervision. La classification est créée par le comportement réel du token, non par son branding. Si un token se comporte comme un ART ou un EMT, les régulateurs le traiteront comme tel indépendamment de l'étiquette.

Même si un projet évite le statut d'émetteur, il peut encore tomber dans MiCA par la couche de services. MiCA régule les prestataires de services sur crypto-actifs. Un CASP est toute partie qui fournit, à titre commercial, des services sur crypto-actifs à des clients.

Les fondateurs supposent souvent que la décentralisation élimine le statut de prestataire de services. Sous MiCA, cette hypothèse est incorrecte. Si une équipe ou une entité liée exploite un frontend hébergé, maintient des interfaces utilisateur, route des transactions, agrège des données, perçoit des frais de protocole, fournit documentation ou support, contrôle des domaines ou API, ou a la capacité de mettre à jour des contrats ou d'influencer significativement la gouvernance, les régulateurs peuvent classer cette entité comme fournissant des services.

Le test crucial est le contrôle pratique. Si vous contrôlez la manière dont les utilisateurs accèdent au protocole, vous exploitez un service. Des smart contracts immuables ne nient pas l'existence d'un opérateur fournissant l'accès à ces contrats. Le statut CASP déclenche agrément, exigences organisationnelles, standards de gouvernance et supervision continue. Les obligations s'attachent dès que la prestation de service commence. Une restructuration ultérieure n'efface pas l'exposition antérieure.

Régimes transitoires et application nationale

MiCA contient des régimes transitoires, tels que l'article 143, autorisant certains prestataires existants à continuer d'opérer temporairement pendant qu'ils sollicitent un agrément. Ces régimes sont étroits et ouverts seulement aux entités déjà enregistrées à des fins LCB-FT avant le 30 décembre 2024. Les nouveaux entrants ne bénéficient d'aucune protection transitoire. Le passporting transfrontalier n'est pas disponible pendant la transition. L'ESMA a averti que des demandes tardives ou faibles font face à un examen renforcé et à de potentielles fermetures forcées.

Pour les projets lancés après décembre 2024, le choix est binaire. Soit opérer en pleine conformité dès le premier jour, soit exclure entièrement l'UE.

MiCA est harmonisé au niveau de l'UE mais appliqué nationalement. La BaFin allemande est largement perçue comme conservatrice. L'AMF française applique activement l'activité tournée vers les consommateurs. L'AFM néerlandaise fournit une orientation procédurale relativement claire. L'Italie et l'Autriche ont imposé des calendriers transitoires plus courts que la base européenne. En pratique, les structures doivent survivre à l'interprétation plausible la plus stricte, non à la plus permissive.

Choisir une posture réglementaire

Une fois que les fondateurs comprennent que MiCA est piloté par le comportement, les choix structurels changent. Certaines équipes optent pour une exclusion stricte de l'UE. Géoblocage complet, documentation inaccessible depuis l'UE et structures de distribution qui empêchent l'acquisition par des Européens. Cela réduit l'exposition mais sacrifie un marché majeur et exige une discipline constante.

Certaines équipes optent pour une conformité MiCA complète. Livres blancs, agrément CASP, conseil juridique et opérations de conformité dès le premier jour. Cela préserve l'accès à l'UE mais introduit coût, itération plus lente et charge réglementaire permanente.

Certaines équipes optent pour un positionnement de pure infrastructure. Aucune relation directe avec les utilisateurs, pas de frontends, outillage intégré par des parties régulées. Cela repousse la surface réglementaire vers l'extérieur mais contraint les modèles d'affaires. Aucune de ces postures n'est intrinsèquement correcte. Dériver dans l'une par accident est ce qui crée le danger.

Nous voyons régulièrement des projets découvrir des obligations MiCA seulement après avoir reçu des avis de retrait de plateforme demandant un livre blanc. Nous voyons des équipes tenter de rédiger des livres blancs rétrospectifs et réaliser que leurs tokens ne correspondent plus à aucun modèle d'information sûr. Nous voyons des opérateurs de frontends supposés être des bénévoles communautaires découvrir qu'ils ont besoin d'un agrément CASP. Nous voyons un géoblocage partiel mis en place comme correctif temporaire qui n'offre aucune protection. Nous voyons une incompréhension généralisée des régimes transitoires.

Le schéma est cohérent. MiCA s'attache plus tôt, plus largement et plus définitivement que ne s'y attendent les fondateurs.

Les choix structurels sont des choix stratégiques

C'est l'environnement que les structures Spindipper ont été conçues pour naviguer. Nous cartographions la manière dont les produits se comportent réellement face aux points de déclenchement MiCA avant le lancement. Nous concevons la séparation d'entités pour que risque d'émission, prestation de services et développement ne s'effondrent pas sur une unique surface juridique. Nous aidons les fondateurs à choisir délibérément entre exclusion de l'UE, conformité complète ou positionnement de pure infrastructure, et nous bâtissons des structures qui soutiennent ce choix. Si un livre blanc est requis, nous veillons à ce qu'il corresponde à la réalité technique et à l'évolution anticipée. Nous planifions autour du fait qu'aucun régime transitoire n'existe pour les nouveaux entrants et que les obligations s'attachent à la première interaction utilisateur.

MiCA ne porte ni sur les étiquettes ni sur l'intention. Il porte sur le comportement observable et la maîtrise de l'accès utilisateur. La question n'est plus de savoir si MiCA s'applique. La question est de savoir quels comportements vous allez adopter et ce que ces comportements créent juridiquement.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique ou fiscal. Compte tenu de la nature en évolution rapide de la réglementation des actifs numériques, un conseil professionnel propre à la juridiction doit être obtenu avant la mise en œuvre de toute structure ici décrite.

Si vous voulez de l'aide pour concevoir la bonne architecture d'entité pour votre projet de token, n'hésitez pas à nous contacter pour une discussion cordiale, sans pression.