MiCA plus EMI rend les paiements en stablecoins commercialisables, pas gagnants

Les paiements en stablecoins n’ont jamais manqué de démos. Ils ont manqué de quelque chose de plus ennuyeux, et plus précieux : un cadre de conformité qu’un CFO, un auditeur et une banque peuvent accepter pendant des années.

Quand vous combinez un jeu d’autorisations de prestataire de services sur crypto-actifs avec une licence de type monnaie électronique (autrement dit : la capacité à gérer des fonds avec des exigences claires en matière de cantonnement, de gouvernance et de reporting), les stablecoins cessent d’être un projet de laboratoire. Ils deviennent un produit que l’on peut payer. Vous pouvez le tarifer. Vous pouvez staffer l’équipe. Vous pouvez le documenter. Vous pouvez le vendre sans devoir créer une exception pour chaque client et chaque corridor.

C’est la bonne nouvelle.

La mauvaise nouvelle, c’est que la réglementation n’a jamais fait gagner un produit de paiement. Ce sont la distribution et la gestion des litiges qui font gagner. L’opérateur qui maîtrise l’onboarding, le rapprochement, le support et le traitement des incidents battra celui qui a les rails les plus élégants.

J’ai vu ce schéma sous d’autres formes : dans les technologies industrielles, où la fiche technique semblait parfaite jusqu’à la première panne, et dans le SaaS, où la fonctionnalité existait mais pas le workflow. Quand je dirigeais une business unit internationale dans les smart buildings et la domotique, la fiabilité n’était pas un slogan. C’était un modèle opérationnel qui couvrait le produit, la supply chain, le support et la formation des partenaires. Le même état d’esprit s’applique aux flux d’argent. Les équipes finance n’achètent pas des rails. Elles achètent des résultats et de la responsabilité.

La réglementation vous amène à « oui, c’est possible ». Elle ne vous amène pas à « on devrait le faire ».

Une posture réglementaire combinée compte, parce qu’elle transforme les inconnues en checklists. Elle clarifie les responsabilités : contrôles KYC et AML, règles de cantonnement, cadence de reporting, exigences de gouvernance et supervision. Cela change immédiatement deux choses.

• La vente devient répétable. Vous pouvez proposer le même produit au client suivant sans renégocier ce que vous avez le droit de faire.
• Les opérations deviennent scalables. Vous pouvez bâtir des playbooks standard et recruter en conséquence, plutôt que de dépendre de quelques généralistes conformité « héroïques ».

Mais vos acheteurs n’évaluent pas votre licence. Ils évaluent votre surface de risque. Un emballage réglementé réduit le risque perçu, mais il ne fait pas disparaître le risque opérationnel. Et c’est ce risque opérationnel qui remonte dans la clôture mensuelle, la boîte support et le board pack.

Si vous voulez faire passer les paiements en stablecoins de « possible » à « préféré », vous devez répondre, en termes simples, à quatre questions de la finance :

1. Que se passe-t-il quand quelque chose se passe mal ?
2. Qui porte la perte pendant l’enquête ?
3. Comment rapproche-t-on cela avec notre grand livre sans travail manuel ?
4. En combien de temps peut-on joindre un humain capable de résoudre le problème ?

Ce ne sont pas des questions de crypto. Ce sont des questions de paiement. Et c’est pour cela que la plupart des produits de paiement perdent, même avec une excellente technologie.

Le règlement final n’est pas une responsabilité finale

On présente souvent les rails stablecoin comme « définitifs ». C’est vrai dans un sens technique étroit. Ce n’est pas vrai dans un sens business.

Dans les paiements par carte, les annulations et chargebacks sont un système d’arbitrage intégré. Les marchands détestent la friction, mais les équipes finance apprécient la prévisibilité : il y a un processus connu, un calendrier et une manière d’allouer la responsabilité. Le règlement en stablecoins supprime certains intermédiaires, mais il ne supprime pas les litiges. Il déplace simplement leur traitement plus haut dans la pile : dans votre produit et votre modèle opérationnel.

Vous avez donc besoin d’un « équivalent chargeback », même si le transfert blockchain est irréversible. Pas une copie des règles cartes, mais un processus maîtrisé qui donne au marchand une réponse crédible à :

• « Le client dit ne pas avoir autorisé l’opération. »
• « Les biens n’ont pas été livrés. »
• « Nous avons remboursé, mais le client affirme ne rien avoir reçu. »
• « Nous avons envoyé les fonds, mais à la mauvaise adresse ou sur le mauvais réseau. »

Concrètement, cela vous amène à construire des mécanismes de mise en attente type escrow, des libérations pilotées par le risque, des outils de remboursement, de la collecte de preuves et des SLA côté marchand. Si vous ne le faites pas, vos plus gros clients ne feront pas passer de volume par vous. Non pas parce qu’ils n’aiment pas les stablecoins, mais parce qu’ils ne peuvent pas faire tourner leur activité sur le mode « définitif = débrouillez-vous ».

C’est la même logique que j’ai apprise plus tôt dans ma carrière, en électronique de puissance. Un variateur peut être excellent sur le papier ; le client achète du temps de fonctionnement, des diagnostics et la capacité à se remettre d’une panne sans drame. Le paiement est aussi un métier de fiabilité. Si vous voulez un parallèle utile : le produit, ce n’est pas le rail. Le produit, c’est le chemin de reprise. J’ai abordé cette logique de « contrat de fiabilité » dans Ruggedization Isn’t a Checkbox.

L’économie unitaire se joue dans le milieu, là où c’est moche

Une fois l’exploitation légale possible, le goulot d’étranglement suivant, ce sont les economics à l’échelle. La plupart des équipes modélisent les frais sur le scénario nominal. Les vraies marges se décident dans le milieu, là où c’est moche : on-ramps, off-ramps, FX, trésorerie, fraude, remboursements et support.

Voici la grille de lecture que j’utilise côté opérateur. Les paiements en stablecoins deviennent un business quand vous maîtrisez trois centres de coûts :

• Coût du mouvement d’argent. Pas seulement les frais on-chain. Le coût complet entre financement, cash-out et gestion des spreads FX.
• Coût des exceptions. Chaque enquête manuelle grignote la marge. Chaque statut flou génère des tickets et du churn.
• Coût du risque. Fraude, account takeover, exposition aux sanctions et erreurs opérationnelles deviennent des lignes de P&L dès que vous proposez des garanties.

Les équipes sous-estiment à quelle vitesse le volume d’exceptions augmente. Ce n’est pas linéaire. Une faible proportion de transactions problématiques se transforme en une grosse machine support quand le volume monte : parce que les clients touchés sont bruyants et urgents, et parce que les équipes finance regroupent les sujets dans la panique de fin de mois.

Quand j’étais interim CEO et cofondateur de EatMore, nous avons appris une vérité simple dans l’hospitality : l’adoption suivait le workflow, pas la fonctionnalité. Si le statut de commande ne reflétait pas la réalité, si les remboursements étaient pénibles, si le staff ne pouvait pas résoudre un problème en une minute aux heures de pointe, le produit n’avait aucune importance. Le paiement fonctionne pareil. Si le rapprochement et la résolution ne sont pas natifs au produit, les marchands ne lui confieront pas de volume significatif.

La distribution bat les rails, mais seulement si le workflow est natif

La « distribution », ce n’est pas seulement avoir une équipe commerciale ou des partenaires. Dans le paiement, la distribution consiste à vivre dans les systèmes qui font déjà tourner l’entreprise :

• Parcours de checkout et de facturation
• Exports ERP et comptables
• Files de remboursements et de litiges
• Tableaux de bord de trésorerie
• Outils support

Le produit stablecoin qui gagnera ne demandera pas aux marchands de changer leur manière de clôturer le mois. Il s’adaptera à leur clôture. Cela impose des choix d’intégration peu glamour, mais déterminants.

Trois choix d’intégration que je prioriserais si je construisais ce produit demain :

1. Rendre le rapprochement déterministe. Chaque transaction doit avoir une identité stable qui tient à travers l’autorisation, le règlement, les remboursements, les remboursements partiels et les ajustements de frais. Si vous ne pouvez pas la mapper proprement à une écriture comptable, vous ne scalerez pas sur le mid-market, et vous n’atteindrez jamais l’enterprise.
2. Livrer un reporting de niveau finance, pas des logs développeur. La finance veut des synthèses, des explications d’écarts et des preuves exportables. L’ingénierie veut des traces. Il vous faut les deux, mais le renouvellement se joue sur la sortie finance.
3. Proposer des garanties de façon sélective. Vous ne pouvez pas tout garantir au départ. En revanche, vous pouvez définir des paliers : règlement instantané au risque du marchand, libération différée avec votre prise de risque, ou corridors assurés. Des options claires valent mieux que des promesses vagues.

C’est pour cela que je reviens souvent à l’idée d’un control plane dans le paiement. Le rail compte, mais le control plane décide de l’adoption. Pour aller plus loin, mon article A Debit Network Is Not a Network. It Is the Checkout Control Plane. exprime la même logique sous un autre angle.

La checklist opérateur pour rendre les stablecoins « acceptables pour une équipe finance »

Si vous êtes membre de board ou opérateur et que vous évaluez une stratégie de paiements en stablecoins, je la challengerais avec une checklist qui force de la clarté au-delà de la seule posture réglementaire.

• Onboarding : Peut-on terminer KYC et KYB sans bloquer les deals, et a-t-on un chemin pour les cas limites (actionnariat complexe, entités cross-border) ?
• Cantonnement et ségrégation : L’histoire de l’argent client est-elle assez simple pour être expliquée à un auditeur en une page ?
• Rapprochement : Le marchand peut-il rapprocher automatiquement au quotidien, et peut-on expliquer chaque écart avec des preuves ?
• Litiges : Quel est notre process, notre calendrier et notre modèle de responsabilité pour les paiements non autorisés, les réclamations de non-livraison et les conflits de remboursement ?
• Remboursements : Un marchand peut-il rembourser en quelques secondes, y compris partiellement, et peut-il prouver que cela a été fait ?
• FX et trésorerie : Qui gère l’exposition, où fixe-t-on les limites, et que se passe-t-il quand la liquidité se tend ?
• Support : Existe-t-il un circuit d’escalade tenu et doté d’une vraie autorité, pas un chatbot et une file e-mail ?
• Contrôles risque : A-t-on des mises en attente configurables, des limites de vélocité, un screening sanctions et de la détection d’anomalies, ajustables par segment de marchands ?
• Packaging commercial : Le pricing est-il aligné sur la valeur perçue par le marchand (vitesse, coût, acceptation), et tient-il encore quand vous intégrez le traitement des exceptions ?

Si vous ne savez pas répondre clairement, la licence peut vous ouvrir la porte, mais elle ne vous y maintiendra pas.

Mon point de vue : MiCA plus EMI, c’est la ligne de départ. Le produit, ce sont les opérations.

J’apprécie la clarté réglementaire parce qu’elle transforme des opinions en exigences. C’est ainsi qu’on scale de manière responsable. Mais je n’ai jamais vu la conformité, seule, créer un avantage durable.

Dans mes propres ventures, notamment Shopeno et IBHQ, la leçon a toujours été la même : on gagne quand le workflow devient évident et que les modes de défaillance sont traités comme un produit à part entière. Les paiements en stablecoins suivront le même chemin. Les gagnants ne seront pas les équipes qui parlent le plus des rails. Ce seront celles qui considèrent les litiges, le rapprochement et les garanties comme le cœur du produit, puis qui distribuent ce produit dans les outils que les équipes finance utilisent déjà.

C’est ainsi que les stablecoins passent de « payable » à « préféré ».