MiCA 2.0 se gagnera sur la responsabilité opérationnelle, pas sur les règles d’émission

J’ai un biais simple, forgé en pilotant des organisations transfrontalières : ce ne sont pas les règles qui protègent les clients, ce sont les systèmes d’exploitation. La loi peut dire « autorisé à émettre ». Elle peut définir les réserves. Elle peut définir l’information à fournir. Tout cela ne pèse plus grand-chose dès lors que les fonds d’un client restent coincés entre un distributeur dans l’UE, un émetteur hors UE, un wallet provider, une banque et une boîte support qui ne répond pas.

À ce moment-là, le client se pose trois questions : qui décroche. Qui peut annuler. Qui assume la perte.

C’est pour cela que je pense que la prochaine itération de la régulation crypto européenne — appelez-la MiCA 2.0 ou autrement — ne se jouera pas sur les règles d’émission. Elle se jouera sur la responsabilité ops et la tuyauterie des litiges. Le plus difficile n’est pas d’obtenir la « permission d’émettre ». Le vrai sujet, c’est de rendre les responsabilités explicites sur l’ensemble de la chaîne de distribution, entre juridictions, et entre intermédiaires aux incitations parfois opposées.

Quand je dirigeais une business unit multi-pays dans le smart building et la domotique, mon quotidien n’était pas dicté uniquement par les spécifications produit. Il l’était par les escalades. Un capteur qui lâche sur le terrain se moque de l’organigramme. Le client veut un responsable, un délai et une correction. Dans les paiements et la monnaie tokenisée, la « panne terrain » prend la forme d’un virement bloqué, d’un débit en double, d’un paiement on-chain envoyé au mauvais endroit ou d’une exposition à une contrepartie sanctionnée détectée trop tard. La mécanique change. La réalité opérationnelle, elle, reste la même.

Le « milieu de chaîne » est le produit

Beaucoup d’équipes traitent la distribution et la gestion des litiges comme un chantier « après le lancement ». C’est une erreur. Dans un mouvement de fonds régulé, le « milieu de chaîne » est le produit. Il couvre notamment :

• Les contrôles de distribution : qui peut onboarder, alimenter, racheter, et à quelles conditions.
• Le support client et les réclamations : réception, tri, délais et pistes d’audit.
• La gestion des exceptions : que se passe-t-il lorsqu’un transfert est retardé, des fonds sont gelés ou une contrepartie est signalée.
• Les parcours de litige : annulations de type chargeback, remboursements partiels, paiements envoyés au mauvais destinataire, et équivalents « monde réel » du double spend.
• L’allocation des pertes : qui paie quand une erreur n’est pas récupérable.

Le client ne se soucie pas de savoir si le rail sous-jacent est un stablecoin, un dépôt tokenisé ou un virement bancaire. Il veut un solde juste et utilisable, une aide accessible, et quelqu’un capable de remettre le système dans un état cohérent quand la réalité sort de votre scénario idéal.

C’est aussi là que nombre d’« innovations » réintroduisent discrètement du risque. La tokenisation supprime souvent un mécanisme d’annulation bien connu et le remplace par la « finalité ». La finalité est excellente pour le règlement. Elle est catastrophique pour l’expérience client dès qu’il y a fraude, erreur de saisie d’adresse, compte compromis ou litige commerçant. Si votre modèle opérationnel ne permet pas de rétablir l’équité rapidement, le régulateur le fera à votre place — et de la façon la plus coûteuse : en faisant porter la responsabilité à l’acteur le plus facile à superviser.

La réglementation devient tangible quand le SLA est explicite

Dans les technologies industrielles, j’ai appris qu’une gouvernance sans interfaces opposables relève de la mise en scène. Dans l’électronique de puissance, les problèmes qualité ne se résolvaient jamais en affirmant « nous tenons à la qualité ». Ils se résolvaient en définissant le contrat entre l’ingénierie, la production, les fournisseurs et le service : ce qui constitue un défaut, comment il est déclaré, qui pilote le confinement, qui porte la cause racine, et sous quels délais les actions correctives doivent être mises en œuvre.

La régulation financière suit le même schéma, avec de l’argent plutôt que du hardware. Si vous voulez savoir si un schéma de monnaie tokenisée tient la route, demandez le contrat opérationnel, pas le whitepaper.

En tant qu’opérateur et membre de board, je pousserais pour cinq SLA explicites sur toute la chaîne :

1. Délai d’accusé de réception : à quelle vitesse une réclamation utilisateur reçoit un numéro de ticket validé par un humain, et pas une réponse automatique.
2. Délai de gel : à quelle vitesse vous pouvez stopper l’aggravation quand une fraude est suspectée. C’est le « stop button » des paiements.
3. Délai de réconciliation : à quelle vitesse vous pouvez prouver ce qui s’est passé entre ledger, comptes bancaires et intermédiaires.
4. Délai de crédit provisoire ou de refus : quand le client est temporairement remis dans ses droits, ou quand vous refusez formellement en motivant la décision.
5. Délai de résolution finale : clôture avec piste d’audit complète et allocation de la perte.

Si vous n’êtes pas capables de les écrire noir sur blanc et d’y associer un responsable, vous n’avez pas un système conforme. Vous avez une démo.

C’est aussi pour cela que je recommande souvent aux équipes fintech d’étudier la réponse aux incidents dans l’industrie. Dans une usine, on ne « attend pas de voir » quand une température sort de la plage. On arrête la ligne, on isole le problème, et on ne redémarre qu’une fois la stabilité démontrée. Les flux d’argent méritent la même discipline. J’ai détaillé ce modèle mental dans AI Value Isn’t in the Org Chart. It’s in the Stop Button. Le principe est identique : le pouvoir d’arrêter fait partie de la gouvernance.

Responsabilité ops : tranchez tôt, ou cela sera tranché à votre place

Dans les montages transfrontaliers, l’issue par défaut est prévisible. Le risque glisse vers le maillon le plus faible. Le distributeur dit « problème d’émetteur ». L’émetteur dit « problème de wallet ». Le wallet dit « erreur utilisateur ». Le client dit « ce n’est pas mon problème ». Le régulateur dit « tout le monde est responsable », puis cible l’entité qu’il peut sanctionner.

Pour éviter cela, il vous faut un modèle de responsabilité conçu, pas implicite.

Je l’aborde comme un RACI simple, adossé à une réalité de bilan :

• Responsible : qui opère le processus au quotidien (l’équipe qui actionne réellement les leviers).
• Accountable : qui signe la politique et en répond quand elle échoue (une entité, pas un comité).
• Consulted : qui apporte l’expertise (compliance, partenaires bancaires, chain analytics, prestataires fraude).
• Informed : qui doit avoir de la visibilité (board, régulateurs, partenaires de distribution clés).

Puis j’ajoute deux questions que beaucoup d’équipes évitent :

• Qui a l’autorité pour annuler ou compenser quand le rail ne permet pas l’annulation ?
• Où la perte est-elle absorbée quand la récupération est impossible, et comment cette réserve est-elle financée ?

Si vous construisez une distribution de stablecoin ou de monnaie tokenisée, vous construisez de facto une couche de protection du consommateur. Vous pouvez faire comme si ce n’était pas le cas ; vous ferez quand même le travail quand les litiges passeront à l’échelle.

Dans mes propres constructions entrepreneuriales, je traite ce sujet comme une contrainte de design, pas comme une surcharge compliance. Avec IBHQ, où les workflows touchent l’onboarding, les contrôles de risque et les opérations partenaires, je ne supporte pas le raisonnement « quelqu’un d’autre s’en occupera ». Dès que vous scalez, « quelqu’un d’autre » devient « personne », et vous vous retrouvez avec un stock d’exceptions qui détruit la confiance.

Le control plane des litiges : construisez-le comme un vrai système

La tuyauterie des litiges a l’air ennuyeuse jusqu’à ce que vous en mesuriez l’impact. Elle pèse sur la conversion, la rétention, les coûts de support, les pertes fraude et le risque réglementaire. C’est aussi le point faible de la plupart des schémas tokenisés, parce que les rails sous-jacents n’ont pas été conçus pour des litiges de consommation.

Construisez donc explicitement un control plane de litiges. Concrètement :

1) Un modèle d’événements partagé entre les parties

Si votre distributeur, votre émetteur et votre wallet provider utilisent chacun des identifiants de transaction différents, vous ne réconcilierez jamais vite. Il vous faut un modèle de référence commun qui relie : l’utilisateur, la source de funding, la tx on-chain, les écritures off-chain, les fees et l’état de règlement.

C’est similaire à ce que j’ai vu en manufacturing et dans les objets connectés : si les tickets service ne peuvent pas être rattachés à une révision hardware, une version firmware et un lot, vous n’avez pas de traçabilité. Les paiements, c’est pareil. La traçabilité est la base de la résolution.

2) Une chaîne d’escalade claire, au-delà des frontières d’entreprise

Quand un incident traverse des juridictions, l’escalade doit rester à un saut. Pas cinq e-mails et un point hebdomadaire. Définissez la chaîne d’escalade, l’organisation d’astreinte et les droits de décision. Si ce n’est pas testé, cela n’existe pas.

3) Des types de litiges et des playbooks pré-définis

Ne traitez pas chaque cas comme du sur-mesure. Construisez une taxonomie : transfert non autorisé, débit en double, mauvais destinataire, litige commerçant, gel lié aux sanctions, panne technique, incohérence KYC, etc. Chaque type a son playbook, sa checklist de données et sa cible de délai de résolution.

4) Un mécanisme « équivalent à une annulation »

La finalité on-chain ne supprime pas le besoin d’annuler. Elle change la manière de l’implémenter. Il vous faut une politique et un mécanisme de restitution client : ajustements de ledger interne, crédits financés par une réserve, clawback quand c’est possible légalement et techniquement, et des critères d’éligibilité explicites.

C’est là que beaucoup confondent architecture technique et architecture d’exploitation. L’architecture d’exploitation, c’est ce que régulateurs et clients ressentiront.

5) Un error budget mesurable

En opérations industrielles, on pilote la fiabilité avec des error budgets et du confinement. Appliquez la même rigueur aux litiges. Fixez des seuils acceptables de règlements échoués, de ruptures de réconciliation, de délais de réponse du support et de pertes fraude. Puis dimensionnez les équipes et l’automatisation pour rester dans ces seuils.

Cela rejoint ma manière de penser les control planes dans les paiements. Le rail n’est pas le produit. Le control plane l’est. Si cela vous parle, A Debit Network Is Not a Network. It Is the Checkout Control Plane. développe la même idée sous un autre angle.

Ce que je demanderais au board ce trimestre

Si vous êtes membre de board ou opérateur et que vous supervisez une distribution de stablecoin ou de monnaie tokenisée vers l’Europe, ne commencez pas par la licence d’émission. Commencez par l’opérabilité.

• Montrez-moi la cartographie des litiges : toutes les parties, toutes les passations, et les points où des fonds peuvent se bloquer.
• Montrez-moi la table de responsabilité : pour chaque mode de panne, qui paie, qui décide et quelles preuves sont requises.
• Montrez-moi les SLA : accusé de réception, gel, réconciliation, crédit provisoire, résolution finale.
• Montrez-moi le stop button : qui peut mettre en pause l’onboarding, les rachats, ou arrêter un canal de distribution, et selon quels critères.
• Montrez-moi la vérité de réconciliation : un ledger canonique, et comment il se raccorde aux comptes bancaires et aux transactions on-chain.
• Montrez-moi comment vous formez les partenaires : parce que votre maillon faible sera un tiers avec un script et sans contexte.

Si les réponses restent floues, la stratégie n’est pas « en avance ». Elle est inachevée.

Quand j’ai construit et dirigé EatMore, une plateforme de commande et de fidélité pour l’hospitality, nous gagnions ou perdions sur des détails d’exécution que personne ne mettait sur la homepage : remboursements, litiges de paiement, commandes manquantes, et capacité à résoudre vite entre commerçants et utilisateurs. Cette expérience m’a rendu intransigeant sur la responsabilité opérationnelle. Dans la monnaie tokenisée régulée, cette exigence n’est pas optionnelle. C’est le cœur du business.

Le marché récompensera le token qui paraît « ennuyeux » en opérations : prévisible, joignable, réversible quand il le faut, et explicite sur qui porte le risque.

Ma position est simple. Si MiCA évolue pour couvrir davantage d’instruments et davantage d’empreintes d’émetteurs, les gagnants ne seront pas les équipes capables d’écrire la note d’émission la plus propre. Ce seront celles capables de prouver, de bout en bout, que les litiges se résolvent dans un délai défini, avec un responsable défini, et un modèle de perte défini. Voilà à quoi ressemble la confiance, en pratique.

Le reste, c’est déplacer le risque le long de la chaîne jusqu’à ce qu’il retombe sur le client.