MiCA : conformité cloud pour les crypto-actifs

Le règlement MiCA encadre désormais les marchés de crypto-actifs dans toute l'Union européenne. Pour un prestataire de services sur crypto-actifs (CASP), la conformité ne se joue pas seulement dans le dossier d'agrément : elle se joue dans l'architecture qui héberge les portefeuilles, protège les clés privées, sépare les actifs des clients et prouve la résilience de la plateforme. Cette page adopte un angle strictement opérationnel de la conformité MiCA cloud : comment concevoir, sur Microsoft Azure ou AWS, une infrastructure qui soutient une conformité MiCA, de la conservation des clés (HSM/KMS) à la résilience exigée par DORA, avec le budget indicatif à prévoir.

• Règlement (UE) 2023/1114
• Agrément CASP
• Custody : HSM / KMS
• Résilience TIC (DORA)
• LCB-FT / Travel Rule

Qu'est-ce que le règlement MiCA et qui est concerné ?

MiCA (Markets in Crypto-Assets, règlement (UE) 2023/1114) est le premier cadre européen harmonisé pour les crypto-actifs qui n'entrent pas déjà dans la définition d'instrument financier. Son objectif : sécuriser les investisseurs, garantir l'intégrité du marché et fixer des exigences homogènes d'un pays à l'autre, avec un passeport européen à la clé. Un acteur agréé dans un État membre peut opérer dans les 27 sans nouvel agrément.

Le règlement distingue trois familles de crypto-actifs, et les obligations diffèrent selon la famille :

• Les jetons se référant à des actifs (ART, asset-referenced tokens) : ils cherchent à stabiliser leur valeur en se référant à un panier d'actifs, plusieurs monnaies, matières premières ou autres crypto-actifs.
• Les jetons de monnaie électronique (EMT, e-money tokens) : ils se réfèrent à une seule monnaie officielle, une forme de stablecoin adossé à l'euro ou au dollar par exemple.
• Les autres crypto-actifs, dont les jetons utilitaires (utility tokens), qui donnent accès à un bien ou un service.

Qui doit se mettre en conformité ?

Deux grandes catégories d'acteurs sont visées, et l'enjeu cloud n'est pas le même pour chacune.

• Les émetteurs de jetons (ART / EMT)

  Ils publient un livre blanc, respectent des exigences de fonds propres et de réserve d'actifs, et prouvent la gouvernance de l'émission. L'enjeu cloud : traçabilité, intégrité des données de réserve et résilience du système d'information.

• Les prestataires de services (CASP)

  Plateformes d'échange, services de conservation, exécution d'ordres, transfert. C'est ici que l'architecture cloud est déterminante : sécurité des clés, ségrégation des actifs, journalisation et continuité.

• Les prestataires TIC tiers

  Les fournisseurs cloud et éditeurs qui soutiennent ces plateformes entrent dans le périmètre indirect via la gestion du risque tiers imposée par DORA. Leur sélection et leur contractualisation deviennent un sujet de conformité.

Le calendrier d'application et le régime transitoire

MiCA s'applique par étapes. Les titres relatifs aux ART et EMT sont entrés en application le 30 juin 2024. Les dispositions relatives aux CASP et à l'agrément sont applicables depuis le 30 décembre 2024. En France, les prestataires déjà enregistrés ou agréés sous le régime national des prestataires de services sur actifs numériques (PSAN, issu de la loi PACTE) bénéficient d'une période transitoire pour basculer vers l'agrément CASP, fixée au 1er juillet 2026. Ce délai n'est pas une pause : construire l'architecture cloud attendue prend des mois, et l'autorité compétente examine la maturité réelle du dispositif, pas les intentions.

En France, l'agrément CASP est délivré par l'AMF (Autorité des marchés financiers), en lien avec l'ACPR pour les aspects prudentiels. Cette page ne traite pas le dossier juridique : elle traite ce qui le rend crédible sur le plan technique, l'architecture cloud.

L'agrément CASP : ce que MiCA exige côté système d'information

MiCA définit dix services sur crypto-actifs. Un CASP demande l'agrément pour un ou plusieurs d'entre eux, et le niveau d'exigence prudentiel varie selon la classe de services.

Au-delà du service lui-même, MiCA impose un socle organisationnel qui a des conséquences directes sur l'architecture : un dispositif de gouvernance clair, une gestion des conflits d'intérêts, un dispositif de continuité d'activité, des mécanismes de sécurité des systèmes TIC, un dispositif LCB-FT, et des exigences de fonds propres minimaux. Ces derniers sont échelonnés par classe de services, de l'ordre de 50 000 €, 125 000 € ou 150 000 € selon les services fournis. Ce sont des seuils réglementaires, pas un tarif de prestation : ils illustrent le niveau de sérieux attendu.

La conservation (custody) des crypto-actifs : le cœur du sujet cloud

Sur une plateforme de crypto-actifs, la donnée la plus sensible n'est pas une base clients : c'est la clé privée. Qui détient la clé détient les fonds. MiCA en tire une conséquence directe pour les services de conservation : le prestataire doit séparer les crypto-actifs de ses clients des siens, tenir un registre des positions ouvert au nom de chaque client, et répond de la perte des actifs conservés résultant d'un dysfonctionnement ou d'un piratage. Autrement dit, la sécurité des clés n'est pas une bonne pratique facultative : elle engage la responsabilité juridique du CASP.

Portefeuilles chauds et froids : une question d'architecture

La bonne pratique du secteur, cohérente avec l'esprit de MiCA, consiste à répartir les fonds entre plusieurs niveaux de portefeuille selon un arbitrage entre disponibilité et exposition :

• Portefeuille froid (cold wallet) : la majorité des actifs, conservée hors ligne, sans exposition réseau permanente. C'est le coffre. Les signatures y sont rares, encadrées, souvent multi-signatures.
• Portefeuille tiède (warm wallet) : un tampon opérationnel, avec des contrôles renforcés et des plafonds.
• Portefeuille chaud (hot wallet) : le strict nécessaire au fonctionnement quotidien et aux retraits, plafonné, surveillé en temps réel.

L'architecture cloud sert cette répartition : isolation réseau stricte des composants de signature, comptes ou abonnements dédiés à la conservation, absence totale de surface d'administration exposée sur Internet, et validation multi-parties (MPC ou multi-signature) pour qu'aucune personne seule ne puisse déplacer des fonds. Ce principe de séparation des pouvoirs prolonge, sur le terrain crypto, la démarche décrite sur notre pilier sécurisation d'infrastructure cloud.

HSM et gestion des clés : Azure et AWS

Les deux fournisseurs proposent des services de gestion de clés et des modules matériels de sécurité conformes aux standards du marché (FIPS 140-2 / 140-3), utilisables pour ancrer la conservation. Le choix entre KMS managé et HSM dédié dépend du niveau d'isolation attendu et du modèle de contrôle des clés.

Le HSM dédié (Managed HSM, CloudHSM) offre un environnement mono-locataire : vous ne partagez pas le module cryptographique avec d'autres clients, et vous conservez la maîtrise du matériel de clé. C'est le niveau attendu pour une conservation de crypto-actifs à volume significatif. Ce niveau a un coût récurrent non négligeable, à intégrer très tôt dans le modèle économique de la plateforme. Le dimensionnement et l'optimisation de ce poste relèvent d'une démarche FinOps d'optimisation des coûts, car un HSM sur-dimensionné ou dupliqué inutilement pèse durablement sur la marge.

Ségrégation des actifs clients et journalisation

MiCA insiste sur un principe simple et exigeant : les actifs des clients ne se mélangent pas avec ceux du prestataire. Cette ségrégation se traduit dans le cloud par plusieurs dispositifs concrets :

• Séparation logique et comptable : un registre interne des positions, réconcilié en continu avec l'état de la chaîne, qui permet de prouver à tout instant quel client détient quoi.
• Isolation des environnements : les comptes ou abonnements de conservation sont distincts des environnements applicatifs et de développement, avec des identités séparées, pour qu'une compromission d'un composant exposé n'atteigne jamais les clés.
• Journalisation inaltérable : chaque opération sensible, signature, mouvement de fonds, accès à une clé, modification de configuration, est journalisée dans un espace protégé, conservé selon les durées attendues et impossible à effacer, y compris par un administrateur.

La preuve tient à la traçabilité. Un contrôle, un incident ou un audit posera toujours la même question : pouvez-vous reconstituer, minute par minute, qui a fait quoi ? Une journalisation centralisée et immuable (Azure Monitor et Log Analytics côté Microsoft, AWS CloudTrail et CloudWatch côté AWS), couplée à des sauvegardes immuables, transforme cette exigence en routine plutôt qu'en épreuve. La méthode de durcissement de la journalisation et des sauvegardes est détaillée sur le pilier sécurisation d'infrastructure cloud.

Résilience opérationnelle : l'articulation avec DORA

C'est le point d'articulation majeur de MiCA. Un CASP est une entité financière au sens de DORA (Digital Operational Resilience Act), le règlement européen sur la résilience opérationnelle numérique du secteur financier, applicable depuis le 17 janvier 2025. MiCA fixe le cadre du marché crypto ; DORA fixe le niveau d'exigence sur la robustesse informatique. Les deux se lisent ensemble.

Concrètement, une plateforme crypto conforme doit démontrer :

• Un cadre de gestion du risque lié aux TIC documenté, avec cartographie des systèmes critiques et des dépendances.
• Un dispositif de continuité : plans de reprise (PRA) et de continuité (PCA), avec des objectifs RTO/RPO définis et testés par des exercices réels de bascule.
• La gestion du risque lié aux tiers : registre d'information recensant les contrats avec les prestataires TIC critiques (dont votre fournisseur cloud), clauses contractuelles renforcées, droit d'audit et stratégie de sortie documentée.
• Des tests de résilience, pouvant aller jusqu'aux tests de pénétration fondés sur la menace pour les entités les plus importantes.
• La notification des incidents majeurs liés aux TIC aux autorités, dans des délais courts.

Cette page ne réécrit pas DORA : elle en montre l'ancrage crypto. Le détail du cadre de résilience, du registre d'information et des tests figure sur la page sœur DORA : résilience opérationnelle dans le cloud. Pour un CASP, la conformité MiCA sans conformité DORA est incomplète : les deux dossiers se construisent en parallèle.

Architecture cloud conforme : isolation, chiffrement, sauvegardes

Une plateforme crypto conforme n'est pas une pile d'outils, c'est une architecture disciplinée. Voici les blocs structurants sur Azure et AWS, alignés sur les exigences MiCA et DORA.

1. Fondations gouvernées (landing zone) Structurer les comptes dès le départ : landing zone Azure via le Cloud Adoption Framework, ou AWS via Control Tower / Landing Zone Accelerator. Séparation stricte production, recette, développement et environnement de conservation.
2. Isolation de la conservation Les composants qui manipulent les clés vivent dans un périmètre dédié : réseau isolé, aucune exposition publique, accès uniquement via bastion ou session managée, signatures encadrées par MPC ou multi-signature.
3. Chiffrement et maîtrise des clés Chiffrement au repos et en transit systématique. Clés maîtrisées par le client (BYOK) dans un HSM dédié (Managed HSM, CloudHSM). Aucun secret en clair, jamais.
4. Identités au moindre privilège RBAC et accès juste-à-temps (Entra ID avec PIM côté Azure, IAM Identity Center côté AWS), MFA résistant au phishing sur tous les comptes sensibles, revues d'accès documentées.
5. Résilience et sauvegardes Sauvegardes immuables et isolées (règle 3-2-1 durcie), PRA/PCA testés, redondance multi-zones, réplication maîtrisée. Un plan de reprise non testé n'est pas un plan.
6. Détection et journalisation Journalisation centralisée inaltérable, détection continue (Microsoft Defender for Cloud, Amazon GuardDuty), SIEM et runbook d'incident daté, avec notification réglementaire prévue.
7. Contrôle continu (policy as code) Politiques de conformité écrites en code (Azure Policy, AWS Config), versionnées, appliquées à chaque déploiement pour empêcher toute dérive de configuration.

Ce socle recoupe les fondamentaux de sécurité, mais l'angle crypto ajoute deux invariants : rien de ce qui touche aux clés ne doit être accessible depuis Internet, et aucune personne seule ne doit pouvoir déplacer des fonds. Ces deux règles guident tous les arbitrages d'architecture. Pour les charges conteneurisées, souvent présentes dans ces plateformes, le durcissement spécifique est traité sur sécurité Kubernetes.

Lutte anti-blanchiment (LCB-FT) et traçabilité

MiCA ne vit pas seul sur le plan réglementaire. Il s'articule avec le cadre de lutte contre le blanchiment et le financement du terrorisme (LCB-FT) et, surtout, avec le règlement sur les transferts de fonds (règlement (UE) 2023/1113), qui transpose au crypto la « Travel Rule » et s'applique depuis le 30 décembre 2024. Cette règle impose de faire circuler, avec chaque transfert de crypto-actifs, les informations sur l'émetteur et le bénéficiaire.

Pour l'architecture cloud, cela se traduit par des exigences concrètes :

• Collecte et vérification d'identité (KYC) : parcours d'entrée en relation, conservation sécurisée des pièces justificatives, chiffrement renforcé, accès tracé.
• Filtrage et surveillance : rapprochement avec les listes de sanctions, détection des transactions suspectes, souvent via des services spécialisés intégrés à la plateforme.
• Traçabilité des transferts : capacité à joindre et à conserver les informations Travel Rule, à les produire sur demande, et à démontrer la chaîne de bout en bout.
• Conservation et protection des données : ces traitements portent sur des données personnelles sensibles, soumises au RGPD. Localisation maîtrisée, durées de conservation définies, contrats de sous-traitance en règle.

L'enjeu cloud est ici la rétention et la production de preuve : conserver longtemps, sans altération, des volumes importants de journaux et de données réglementaires, tout en respectant le RGPD sur les données personnelles qu'ils contiennent. Le panorama complet des obligations de protection des données figure sur notre page conformité cloud (RGPD, ISO 27001, HDS, DORA).

MiCA, DORA, DSP2 et RGPD : comment ça s'articule

Un acteur crypto se retrouve vite à l'intersection de plusieurs textes. Les confondre conduit à sur-traiter certains sujets et à en négliger d'autres. Voici la grille de lecture.

MiCA donne le « quoi » du métier crypto. DORA donne le « comment » de la résilience. La Travel Rule et le RGPD encadrent les flux et les données. Une démarche ISO 27001 n'est pas obligatoire, mais elle constitue un socle qui facilite l'ensemble : une bonne partie des mesures attendues se recoupe. Si votre activité comporte un volet paiement classique, l'articulation avec la DSP2 dans le cloud mérite d'être cadrée à part.

La démarche de mise en conformité cloud, étape par étape

Une plateforme crypto conforme se construit par trajectoire, pas d'un seul coup. Voici la séquence que nous cadrons avant de vous orienter vers les prestataires qui la mettent en œuvre.

1. Cadrage du périmètre Quels services CASP visés, quel volume, quelles données, quels environnements cloud. Un périmètre net conditionne tout le reste.
2. Analyse d'écart Confronter l'architecture existante aux exigences MiCA et DORA : sécurité des clés, ségrégation, résilience, journalisation, risque tiers. Matrice d'écarts priorisée.
3. Conception de l'architecture cible Landing zone, isolation de la conservation, HSM et maîtrise des clés, PRA/PCA, journalisation immuable, tout décrit en Infrastructure as Code.
4. Mise en œuvre par les prestataires Construction du socle, durcissement, mise en place des contrôles automatisés (policy as code), tests de bascule et de restauration.
5. Preuve et documentation Registre d'information DORA, procédures, runbooks, matrice de conformité, éléments techniques du dossier d'agrément.
6. Exploitation et surveillance Détection continue, revue de posture, réversibilité maintenue, veille réglementaire au fil des évolutions.

• 3 à 10 jcadrage du périmètre cloud (selon maturité)
• 7 à 18 k€budget indicatif, sur devis selon le périmètre
• HSMclés de conservation en module matériel dédié
• IaCarchitecture versionnée, reprenable dans vos dépôts

Notre rôle : intermédiaire indépendant

Notre valeur tient à trois choses sur ce sujet : l'indépendance (nous ne revendons aucun cloud ni aucun éditeur, l'arbitrage Azure/AWS se fait au service de votre conformité et de votre budget), la profondeur réglementaire française couplée à la maîtrise technique, et l'autonomie du client (tout ce qui est construit vous appartient). Pour aller plus loin, voyez nos services de cybersécurité cloud, l'ensemble de nos services, notre approche du secteur finance et le guide du cloud.

FAQ : MiCA cloud

Qu'est-ce que le règlement MiCA ?

MiCA (Markets in Crypto-Assets, règlement (UE) 2023/1114) est le cadre européen harmonisé qui encadre les crypto-actifs ne relevant pas déjà de la réglementation financière. Il fixe des règles pour les émetteurs de jetons (ART, EMT) et pour les prestataires de services sur crypto-actifs (CASP), avec un passeport valable dans toute l'Union. Les règles sur les ART et EMT s'appliquent depuis juin 2024, celles sur les CASP depuis décembre 2024.

Qui est concerné par MiCA ?

Deux catégories principales : les émetteurs de jetons se référant à des actifs (ART) ou de jetons de monnaie électronique (EMT), et les prestataires de services sur crypto-actifs (CASP) comme les plateformes d'échange, les conservateurs, les intermédiaires d'exécution et de transfert. Indirectement, les fournisseurs TIC tiers qui soutiennent ces acteurs entrent dans le périmètre via la gestion du risque tiers imposée par DORA.

Qu'est-ce qu'un agrément CASP ?

C'est l'autorisation, délivrée par une autorité compétente (en France l'AMF, en lien avec l'ACPR), d'exercer un ou plusieurs des dix services sur crypto-actifs définis par MiCA. Il suppose de démontrer une gouvernance solide, un dispositif de sécurité des systèmes TIC, un dispositif LCB-FT, un plan de continuité et des fonds propres minimaux échelonnés selon la classe de services.

Comment MiCA impacte-t-il l'hébergement cloud d'une plateforme crypto ?

L'impact est direct sur l'architecture : sécurité des clés privées via HSM, isolation des composants de conservation, ségrégation des actifs des clients, journalisation inaltérable, sauvegardes immuables et résilience testée. Une plateforme conçue sans ces principes ne peut pas soutenir un dossier CASP crédible, quel que soit le fournisseur cloud retenu.

Comment sécuriser la conservation (custody) des crypto-actifs dans le cloud ?

En ne laissant jamais les clés privées en clair. Elles vivent dans un module matériel de sécurité (Azure Key Vault Managed HSM ou AWS CloudHSM), ne sortent pas du module, et leur usage est journalisé. On répartit les fonds entre portefeuilles froid, tiède et chaud, on isole strictement le réseau des composants de signature, et on impose une validation multi-parties (MPC ou multi-signature) pour qu'aucune personne seule ne puisse déplacer des fonds.

Quelle est la différence entre Azure Key Vault et AWS CloudHSM pour la custody ?

Azure Key Vault et AWS KMS sont des services de gestion de clés managés, adaptés à la plupart des besoins de chiffrement. Pour une conservation à enjeu, on privilégie un HSM mono-locataire : Azure Key Vault Managed HSM ou AWS CloudHSM, certifiés FIPS 140-2 niveau 3, où vous ne partagez pas le module cryptographique et gardez la maîtrise du matériel de clé. Le HSM dédié a un coût récurrent à intégrer tôt dans le modèle économique.

Quel est le lien entre MiCA et DORA ?

Un CASP est une entité financière au sens de DORA, le règlement européen sur la résilience opérationnelle numérique applicable depuis janvier 2025. MiCA exige un dispositif de continuité et de sécurité des systèmes TIC ; DORA en précise les modalités : cartographie des risques, tests de résilience, gestion du risque lié aux prestataires tiers, stratégie de sortie et notification des incidents. Les deux dossiers se construisent en parallèle.

MiCA impose-t-il la ségrégation des actifs des clients ?

Oui. Un prestataire qui conserve des crypto-actifs doit séparer ceux de ses clients des siens, tenir un registre des positions au nom de chaque client, et il répond de la perte des actifs conservés en cas de dysfonctionnement ou de piratage. Dans le cloud, cela se traduit par une isolation des environnements, une comptabilité réconciliée en continu avec la chaîne et une journalisation inaltérable de chaque opération.

Qu'est-ce que la Travel Rule pour les crypto-actifs ?

C'est l'obligation, portée par le règlement sur les transferts de fonds (UE) 2023/1113 applicable depuis décembre 2024, de faire circuler avec chaque transfert de crypto-actifs les informations sur l'émetteur et le bénéficiaire. Elle s'inscrit dans la lutte anti-blanchiment (LCB-FT) et impose, côté cloud, la collecte, la conservation sécurisée et la capacité de production de ces informations, dans le respect du RGPD.

MiCA remplace-t-il le RGPD ?

Non. MiCA encadre le marché des crypto-actifs, le RGPD protège les données personnelles. Une plateforme crypto traite des données sensibles (KYC, transactions, journaux) qui restent soumises au RGPD : contrat de sous-traitance article 28, mesures de sécurité article 32, localisation maîtrisée et durées de conservation définies. Les deux cadres se cumulent et se complètent.

Combien de temps et quel budget pour cadrer le socle cloud MiCA ?

Le cadrage du périmètre cloud et l'analyse d'écart représentent un accompagnement de l'ordre de 3 à 10 jours, pour un budget indicatif de 7 000 à 18 000 €, sur devis selon le périmètre. Cette fourchette couvre le cadrage et l'orientation de l'architecture, hors coût récurrent d'un HSM dédié et hors frais d'instruction de l'agrément par l'autorité compétente. La mise en œuvre est ensuite chiffrée par les prestataires du réseau.

Faut-il être certifié ISO 27001 pour un agrément CASP ?

Non, MiCA n'impose pas la certification ISO 27001. Mais une démarche ISO 27001 constitue un socle utile : une bonne partie des mesures attendues, gouvernance de la sécurité, gestion des accès, journalisation, continuité, se recoupe avec les exigences MiCA et DORA. Structurer un système de management de la sécurité facilite l'ensemble des démarches et rassure l'autorité comme les partenaires.

Vous préparez un agrément CASP ou vous devez aligner une plateforme crypto existante sur MiCA et DORA ? Faites le point en quelques minutes avec notre diagnostic en ligne, ou contactez notre équipe : nous cadrons votre besoin et vous orientons vers des prestataires qualifiés Azure et AWS. Réponse sous 48 h ouvrées.