MiCA, DORA, et après ? Comment la régulation européenne force les DSI à repenser leur chaîne crypto sans dépendre de Wall Street

# MiCA, DORA, et après ? Comment la régulation européenne force les DSI à repenser leur chaîne crypto sans dépendre de Wall Street

Il y a une ironie assez cruelle dans la situation actuelle : l'Europe a produit le cadre réglementaire crypto le plus complet au monde — MiCA est entré en application pleine en 2025, DORA a durci les exigences de résilience pour les actifs numériques dans les institutions financières — et pourtant, une majorité d'entreprises européennes qui cherchent à se conformer finissent par s'outiller auprès de plateformes américaines. Coinbase Institutional, Fireblocks, Chainalysis : le triptyque dominant. Le droit est européen. L'infrastructure reste américaine. C'est précisément là que le problème commence.

Pour un DSI ou un RSSI d'une PME ou ETI européenne qui doit intégrer la gestion d'actifs numériques dans son SI — que ce soit pour des paiements cross-border, de la tokenisation d'actifs, ou simplement pour se conformer aux obligations de reporting imposées par MiCA — la question de l'outillage est devenue centrale. Et elle est rarement posée avec la clarté qu'elle mérite.

Quand la conformité européenne génère une dépendance américaine

Partons d'un constat concret. MiCA impose aux entreprises qui émettent ou négocient des crypto-actifs une série d'obligations : agrément CASP (Crypto-Asset Service Provider), exigences de fonds propres, politiques de gouvernance, obligations de transparence et de reporting. DORA ajoute une couche de résilience opérationnelle : tests de pénétration, gestion des tiers critiques, plans de continuité spécifiques aux actifs numériques.

Pour gérer tout cela, une équipe IT a besoin d'outils. Custody des clés cryptographiques, surveillance des transactions on-chain, reporting réglementaire automatisé, intégration avec les systèmes comptables existants. Et c'est ici que le marché révèle sa géographie réelle : les outils les plus matures, les mieux documentés, les plus facilement intégrables… sont américains. Fireblocks pour la custody institutionnelle. Chainalysis pour la conformité AML et le suivi des flux. Elliptic pour l'analyse de risque.

Le piège est subtil. Ces plateformes ne sont pas illégales au sens de MiCA. Elles ne violent pas la lettre du règlement. Mais elles créent une dépendance opérationnelle profonde : les données transactionnelles de l'entreprise, les clés de custody, les workflows de conformité sont hébergés, traités, analysés sur des infrastructures soumises au droit américain — et notamment au Cloud Act, qui permet aux autorités américaines d'accéder à ces données sans notification préalable à l'entreprise concernée ni aux autorités européennes.

Un RSSI qui a passé six mois à construire une politique de conformité MiCA solide peut très bien avoir créé, sans s'en rendre compte, une exposition réglementaire symétrique côté américain.

Ce que les équipes IT ne voient pas quand elles évaluent ces outils

La question de l'outillage crypto n'est pas traitée comme une question stratégique dans la plupart des équipes IT européennes. Elle est traitée comme une question technique. "Quel outil s'intègre le mieux à notre ERP ? Quelle API est la mieux documentée ? Quel vendor propose le meilleur support ?" Ces critères sont légitimes. Ils ne sont pas suffisants.

Prenons la question de la custody. Déléguer la garde des clés cryptographiques à un prestataire américain, c'est accepter que la capacité à signer des transactions — c'est-à-dire à disposer effectivement des actifs — dépende de la continuité de service d'une entité soumise à une juridiction étrangère. En cas de sanctions internationales, de faillite du prestataire, ou de décision administrative américaine, l'entreprise européenne peut se retrouver dans l'incapacité d'accéder à ses propres actifs. Ce n'est pas un scénario théorique : la faillite de FTX en 2022 a gelé des actifs d'entreprises européennes qui n'avaient rien à voir avec les malversations de Sam Bankman-Fried.

La question du reporting réglementaire est tout aussi structurante. MiCA impose des rapports précis aux autorités nationales compétentes (l'AMF en France, la BaFin en Allemagne). Si ces rapports sont générés par un outil américain, sur la base d'une modélisation des données propriétaire, l'entreprise n'a pas de visibilité complète sur la logique de calcul. En cas de contrôle, elle dépend de la bonne volonté et de la disponibilité du vendor pour expliquer ses propres chiffres. C'est une position de faiblesse considérable.

Enfin, DORA exige une cartographie précise des tiers critiques et une évaluation de leur résilience. Les grands vendors américains ont des processus d'audit bien rodés — ils savent répondre aux questionnaires de due diligence. Mais une chose est de passer un audit, une autre est d'accepter un audit approfondi incluant un accès aux logs, aux configurations de sécurité, aux pratiques d'accès des employés. Sur ce point, la transparence des acteurs américains a des limites qui ne sont pas toujours explicitées dans les contrats.

Les alternatives européennes existent — mais elles demandent un effort d'intégration que peu d'équipes IT sont prêtes à assumer

Soyons honnêtes : l'écosystème européen des outils crypto institutionnels est en retard. Pas absent — en retard. Et ce retard a des conséquences directes sur la charge de travail des équipes IT qui font le choix souverain.

Des acteurs comme Metaco (racheté par Ripple, ce qui pose d'autres questions) ou Ledger Enterprise (acteur français, ce qui est notable) existent et servent des clients institutionnels. Des solutions de custody MPC (Multi-Party Computation) développées en Europe commencent à atteindre un niveau de maturité utilisable. Certains acteurs bancaires européens — la Société Générale avec FORGE, la Deutsche Bank avec ses expérimentations tokenisation — développent des briques d'infrastructure qui pourraient, à terme, servir de référence.

Mais voici ce que les comparatifs marketing ne disent pas : choisir un outil européen moins mature implique souvent des efforts d'intégration significativement plus élevés. Documentation moins riche, communauté de développeurs plus petite, connecteurs natifs vers les ERP classiques (SAP, Sage, Cegid) moins nombreux. Pour une équipe IT déjà sous pression, c'est un argument difficile à ignorer. Le vendor américain s'intègre en deux semaines. L'alternative européenne demande trois mois de travail sur mesure.

C'est précisément ce différentiel de productivité immédiate — réel, mesurable — qui perpétue la dépendance. Les DSI ne font pas un choix idéologique quand ils choisissent Fireblocks plutôt qu'une solution européenne. Ils font un choix rationnel à court terme. La question est de savoir qui paie le coût réel de ce choix à moyen terme.

Ce que MiCA et DORA changent concrètement dans le quotidien des équipes IT

Parlons d'opérations. Avant MiCA, une entreprise européenne qui touchait aux crypto-actifs pouvait naviguer dans un flou réglementaire relatif. Les équipes IT géraient ça comme un projet annexe, souvent sous-dimensionné. Après MiCA, la gestion des crypto-actifs devient une fonction métier régulée, avec des obligations de traçabilité, d'audit, et de reporting qui s'imposent à toute la chaîne SI.

Concrètement, ça change plusieurs choses. D'abord, la gestion des identités et des habilitations : les workflows d'approbation pour les transactions crypto doivent être documentés, horodatés, auditables. Ça demande une intégration réelle avec les outils IAM existants de l'entreprise — et beaucoup de plateformes américaines proposent leurs propres systèmes d'IAM propriétaires, ce qui crée des silos supplémentaires dans le SI.

Ensuite, la gestion des incidents : DORA impose des délais de notification stricts en cas d'incident affectant des actifs numériques. Si l'outil de monitoring des transactions est chez un vendor américain, le temps de réaction dépend en partie de la disponibilité de ce vendor. Pour un RSSI, c'est un risque opérationnel direct.

Enfin, la question de l'interopérabilité avec les systèmes comptables et fiscaux. MiCA génère des obligations de valorisation des actifs, de calcul des plus-values, de reporting TVA dans certains cas. Ces données doivent alimenter des systèmes comptables qui, eux, sont souvent on-premise ou sur des clouds européens. La plomberie entre les deux — l'API, le format des données, la fréquence des mises à jour — est rarement fluide avec des outils américains qui n'ont pas été conçus pour les spécificités fiscales européennes.

Le vrai enjeu : construire une doctrine, pas juste choisir des outils

La question qui devrait animer les comités de direction IT européens en 2026 n'est pas "quel outil crypto choisir". C'est : "quelle doctrine de souveraineté numérique appliquons-nous à notre chaîne de valeur crypto, et quels compromis sommes-nous prêts à assumer pour la tenir ?"

Cette formulation change tout. Elle sort la décision du domaine purement technique pour la placer au niveau stratégique où elle appartient. Un DSI qui se dote d'une doctrine explicite — par exemple : "toutes les clés cryptographiques restent sous custody européenne, tous les outils de reporting sont hébergés dans l'UE, tous les contrats incluent une clause de portabilité des données" — peut ensuite évaluer les outils avec des critères cohérents, et défendre ses choix en interne et vis-à-vis des auditeurs.

Cette doctrine implique aussi d'accepter des coûts. Le surcoût de l'option souveraine — en temps d'intégration, en limitation fonctionnelle temporaire, parfois en coût direct — doit être quantifié et assumé explicitement, pas nié. C'est la seule façon d'éviter que le prochain projet pilote ne revienne silencieusement vers Fireblocks parce que "c'est plus simple".

Il faut aussi poser la question que personne ne pose vraiment : est-ce que MiCA, dans sa forme actuelle, favorise effectivement l'émergence d'un écosystème d'outils européens compétitifs ? Ou est-ce qu'un cadre réglementaire très exigeant — qui favorise mécaniquement les acteurs déjà établis, avec les ressources pour se conformer rapidement — a paradoxalement consolidé la position des grands vendors américains au détriment des alternatives européennes naissantes ?

C'est la question inconfortable. Et elle mérite une réponse honnête de la part des régulateurs autant que des équipes IT.

*La souveraineté numérique ne se décrète pas dans un règlement. Elle se construit, ou ne se construit pas, dans les choix d'outillage que les équipes IT font chaque trimestre. MiCA et DORA ont créé le cadre. Reste à savoir qui construit l'infrastructure.*