« Prêt pour MiCA » décrit une plateforme d'échange dont l'architecture peut démontrer les exigences applicables à un prestataire de services sur crypto-actifs agréé, et non une plateforme ayant acquis un label. Le cadre relatif aux marchés de crypto-actifs s'applique pleinement depuis le 30 décembre 2024, et les mesures transitoires qui permettaient aux entreprises d'opérer sous les régimes nationaux ont désormais pris fin. La question qui se pose à un nouveau projet n'est donc pas de savoir si le cadre s'applique, mais si ses systèmes peuvent démontrer les contrôles que le cadre suppose déjà en place.
La période de transition MiCA est terminée. Les nouveaux projets crypto de l'UE doivent être conçus dès le départ pour un modèle opérationnel de CASP agréé. Une plateforme assemblée d'abord, puis mise en conformité avec les exigences ensuite, hérite d'un programme de remédiation avant même d'avoir reçu son premier ordre ; une plateforme conçue autour du modèle opérationnel produit l'essentiel des preuves requises par une demande comme sous-produit de son fonctionnement normal.
Cet article expose ce que la préparation à MiCA signifie au niveau de l'architecture : comment la conservation, la négociation, la lutte contre la criminalité financière et la résilience sont structurées afin qu'une autorité nationale compétente, un auditeur externe ou la fonction de conformité de la plateforme puisse voir comment celle-ci se comporte et qui l'a modifiée. La perspective est celle de la conception et de l'achat, non celle d'une recette de mise en œuvre.
Ce que « prêt pour MiCA » signifie pour l'architecture
La préparation est souvent confondue avec un certificat. Il n'existe pas de plateforme certifiée MiCA, et l'agrément n'est pas délivré directement par l'ESMA ; il est délivré par l'autorité nationale compétente de l'État membre où le prestataire s'établit, l'ESMA tenant le registre public des entreprises agréées. « Prêt pour MiCA » désigne donc une architecture structurée autour des exigences pertinentes, de sorte que l'agrément soit atteignable et, une fois obtenu, demeure démontrable sous supervision.
La conséquence pratique est que la préparation est une propriété de la preuve plutôt que des fonctionnalités. Deux plateformes peuvent offrir les mêmes fonctions de négociation, alors qu'une seule peut montrer, sur demande, comment les actifs des clients sont séparés, comment un ordre a été traité ou qui a validé une modification de configuration. L'architecture capable de fournir ces réponses sans les reconstituer après coup est celle qui porte une revendication défendable de préparation à MiCA.
Le modèle opérationnel de CASP comme base de conception
Un prestataire de services sur crypto-actifs est agréé pour des services précis, et chaque service offert emporte ses propres obligations. Exploiter une plateforme de négociation, assurer la conservation, échanger des crypto-actifs contre des fonds et exécuter des ordres pour le compte de clients sont des activités distinctes assorties de contrôles distincts, et la combinaison qu'une plateforme entend proposer définit le modèle opérationnel que son architecture doit soutenir. Choisir cette combinaison tardivement, après avoir bâti la plateforme autour d'une hypothèse plus étroite, compte parmi les corrections les plus coûteuses d'un projet.
La fenêtre transitoire étant fermée, il n'existe aucun droit acquis permettant à une plateforme de démarrer son activité puis de s'aligner plus tard. La gouvernance attendue par le cadre — une répartition claire des responsabilités, la séparation des tâches incompatibles et une responsabilité nommée pour les fonctions de contrôle — doit être exprimée dans la plateforme elle-même : par la conception des rôles et des habilitations, les circuits de validation et la séparation entre ceux qui négocient, ceux qui déplacent des actifs et ceux qui modifient le système. Ce sont des décisions d'architecture avant d'être des énoncés de politique.
Conservation et ségrégation des actifs des clients
Lorsqu'une plateforme détient des crypto-actifs ou des fonds pour ses clients, le cadre exige que ces avoirs soient protégés et tenus séparés des ressources propres de l'entreprise. Au niveau de l'architecture, cela se traduit par une conception des wallets et du ledger qui maintient les positions des clients séparées, les rapproche en continu des soldes on-chain et des enregistrements internes, et restreint qui peut autoriser le mouvement des actifs. La répartition des avoirs entre dispositifs hot, cold et multisig est une décision de contrôle, et non purement opérationnelle, car elle détermine la limitation de l'exposition et la validation des retraits.
Les preuves qu'une telle conception doit produire sont précises. Il doit être possible de démontrer, à tout moment, que les soldes clients enregistrés correspondent aux actifs réellement détenus, que l'accès aux clés est restreint et imputable, et que chaque mouvement porte un validateur et un motif. Le détail des procédures de gestion des clés et des seuils de signature relève de la fonction de sécurité et non d'une description publique, mais l'exigence architecturale reste constante : la ségrégation et le rapprochement doivent être continus et prouvables, et non périodiques et affirmés.
Remarque : La ségrégation est d'abord un problème de rapprochement avant d'être un problème de stockage. Une plateforme incapable de rapprocher les avoirs des clients de son ledger en temps quasi réel ne peut pas démontrer la protection des avoirs, quelle que soit la manière dont ses clés sont détenues, et l'écart se révèle généralement lors d'un incident plutôt qu'au moment de la conception.
Négociation ordonnée et intégrité du marché
L'exploitation d'une plateforme de négociation emporte des obligations qui atteignent le cœur de la plateforme. La négociation doit se dérouler selon des règles transparentes et appliquées de manière cohérente, les ordres et leur traitement doivent être enregistrés, et la plateforme doit permettre la détection et la déclaration des comportements susceptibles de constituer un abus de marché. Sur le plan architectural, cela relie la couche de matching, la couche de données de marché et la couche de surveillance : la plateforme doit pouvoir reconstituer comment un ordre a été reçu, priorisé et exécuté, et faire apparaître les schémas qui justifient une investigation.
L'intégrité du marché dépend aussi de la gestion des conflits d'intérêts, qui comporte une dimension architecturale lorsqu'une plateforme négocie pour compte propre, exploite une fonction de liquidité liée ou liste des actifs dans lesquels elle a un intérêt. Les contrôles qui séparent ces activités, et les enregistrements qui attestent cette séparation, appartiennent à la même base de preuves qu'examine une évaluation d'agrément. Une plateforme dont le cycle de vie des ordres et les sorties de surveillance ne peuvent être exportés ni expliqués est difficile à défendre sous supervision, quelles que soient ses performances.
Lutte contre la criminalité financière et Travel Rule
Une plateforme agréée évolue dans le régime de lutte contre le blanchiment autant que dans le cadre de marché, et les deux sont de plus en plus supervisés ensemble. La vigilance à l'entrée en relation, la surveillance continue, le filtrage des sanctions et des PEP, ainsi que l'obligation d'accompagner les transferts de crypto-actifs des informations sur le donneur d'ordre et le bénéficiaire au titre de la Travel Rule font partie du modèle opérationnel. L'autorité européenne de lutte contre le blanchiment est désormais en fonction et la supervision se consolide à l'échelle de l'UE, avec un corpus de règles unique qui prendra effet au cours de la période à venir ; une architecture conçue pour la base actuelle devrait donc anticiper des attentes plus strictes et plus uniformes plutôt que le régime fragmenté qu'elle remplace.
Pour l'architecture, l'exigence est l'intégration plutôt que la juxtaposition. La vérification d'identité et le filtrage ne peuvent résider dans un outil séparé dont les résultats sont ressaisis à la main ; ils appartiennent aux parcours d'entrée en relation et de transaction, les résultats étant enregistrés en regard du client et de la transaction afin qu'un examinateur puisse voir pourquoi un compte a été accepté ou un transfert suspendu. Les considérations de conception derrière ces contrôles sont exposées sous logiciel de contrôle AML et logiciel de vérification KYC.
Résilience opérationnelle et risque lié aux tiers
Une plateforme prête pour MiCA doit également satisfaire aux attentes de résilience opérationnelle qui s'appliquent désormais aux entités financières de l'UE. DORA s'applique depuis le 17 janvier 2025 et traite la résilience comme quelque chose qui doit être testé et démontré : la gestion des risques liés aux technologies de l'information et de la communication, le traitement et la déclaration des incidents, les tests de résilience et la surveillance des tiers critiques relèvent tous de son champ. Pour une plateforme d'échange, cela fait passer la disponibilité d'une aspiration opérationnelle à un contrôle qui doit être exercé, mesuré et prouvé efficace.
La dépendance à l'égard des tiers est le point où la résilience et l'architecture se rencontrent le plus directement. Lorsque la conservation, l'hébergement, le matching ou le filtrage sont fournis par des tiers, ces prestataires font partie de l'environnement de contrôle de la plateforme, et le cadre attend une évaluation, des tests et un plan de sortie praticable plutôt qu'une simple assurance contractuelle. Une plateforme qui ne peut revenir à un objectif défini sans l'intervention d'un prestataire, ou qui ne peut quitter un prestataire sans tout reconstruire, présente une lacune de résilience qu'aucun document ne comble. Des considérations techniques connexes sont exposées sous préparation réglementaire pour l'Union européenne.
Périmètre : Nous ne fournissons pas d'avis juridiques et ne garantissons aucun agrément. Nous mettons en œuvre les exigences réglementaires et d'audit dans la technologie, l'infrastructure et l'exploitation.
Preuves et dossier d'agrément
Une évaluation d'agrément, et la supervision qui la suit, vérifient si la plateforme peut montrer ce qu'elle prétend faire. Chaque domaine d'architecture comporte donc une question correspondante sur la preuve, et une plateforme est prête lorsque ces questions trouvent réponse dans le système plutôt que dans l'intention. Le tableau ci-dessous met en regard les domaines examinés plus haut et la démonstration que chacun doit soutenir.
| Domaine d'architecture | Ce que la plateforme doit pouvoir démontrer |
|---|---|
| Conservation et ségrégation | Les avoirs des clients correspondent aux actifs détenus ; les mouvements d'actifs sont validés et imputables |
| Négociation et intégrité | Le cycle de vie des ordres est reconstituable ; les sorties de surveillance peuvent être exportées et expliquées |
| Criminalité financière | Les résultats de vérification et de filtrage sont enregistrés en regard du client et de la transaction |
| Résilience opérationnelle | Les objectifs de reprise sont exercés ; la sortie des tiers est planifiée et testée |
| Contrôle des changements et des accès | Les modifications de configuration portent des validateurs nommés et des versions datées |
Rassembler ces preuves après la construction de la plateforme est possible mais coûteux, car des enregistrements qui n'ont pas été saisis au moment voulu ne peuvent être recréés fidèlement. La voie efficace consiste à traiter le dossier d'agrément comme un produit de l'exploitation ordinaire, généré en continu par une plateforme dont l'architecture a été conçue en tenant compte du modèle CASP. La perspective de planification plus large est décrite sous logiciel de plateforme d'échange crypto.
Synthèse et prochaines étapes
La préparation à MiCA n'est pas un insigne apposé sur une plateforme achevée ; c'est une propriété d'une architecture capable de séparer les actifs des clients, d'exploiter un marché ordonné, d'intégrer les contrôles de lutte contre la criminalité financière, de résister aux perturbations et de démontrer chacun de ces éléments sur demande. La période transitoire étant close, cette architecture est la condition de départ d'une nouvelle plateforme de l'UE et non un perfectionnement ultérieur, et le coût d'un rattrapage est constamment supérieur au coût d'une conception anticipée.
L'étape pratique suivante consiste à préciser, pour chacun des domaines ci-dessus, ce que la plateforme devra démontrer et d'où proviendra cette preuve. Une plateforme capable de répondre à ces questions avant de sélectionner un logiciel est en mesure d'évaluer les fournisseurs au regard du modèle opérationnel qu'elle doit réellement satisfaire, plutôt qu'au regard d'une liste de fonctionnalités.
La préparation à MiCA est une décision d'architecture, non un certificat. Grumpio conçoit et livre une technologie d'échange autour du modèle opérationnel de CASP, avec les contrôles de conservation, de surveillance, de lutte contre la criminalité financière et de résilience qu'un dossier d'agrément doit prouver.