À partir du 1er juillet, les acteurs européens qui n’ont pas d’agrément MiCA ne pourront plus exercer leur activité. Dfns s’était enregistré en 2023 comme PSAN auprès de l'AMF sur la partie custody. C'était un pari défensif ?
Complètement. Nous nous percevons comme un fournisseur de technologie, pas comme un prestataire de services financiers. Cette distinction est ancienne. Dans la finance traditionnelle, il y a toujours eu une cohabitation entre les entreprises qui font de la technologie et celles qui fournissent des services financiers réglementés.
Le débat avait été posé au Parlement français autour du cas de Ledger : si détenir des clés cryptographiques fait de vous un dépositaire, alors AWS ou Google deviennent des custodians financiers. C'est absurde. L'AMF avait alors produit un mémo en juin 2021 avec une position plutôt business-friendly et assez unique au monde : on pouvait interagir à distance avec une clé via API et être considéré comme dépositaire, sous certaines conditions.
Par précaution, nous avons créé une filiale, enregistrée PSAN sur la seule partie custody. L'idée était simple : si le régulateur changeait d'avis, nous pouvions y migrer nos clients. Mais nous n'avons jamais eu besoin de l'utiliser.
Vous ne cherchez pas à obtenir un agrément pour autant ?
Non. Nous ne voulons pas envoyer de signaux contradictoires ni concurrencer nos propres clients. Imaginez : vous êtes dans le hall d'entrée d'une banque pour signer un contrat technologique et vous croisez votre client qui vient pitcher le même service régulé juste à côté. Ce n'est pas tenable. Nous restons un pure player technologique.
"Le premier vecteur de risque, c'est de protéger l'utilisateur contre lui-même"
Votre approche de la custody est très différente du reste du marché. Comment l'expliquez-vous ?
Il faut distinguer deux choses. La custody au sens juridique (le recours, le contrat, la possibilité d'attaquer en justice) c'est fondamentalement une affaire de droit. Et puis il y a la custody technique : le contrôle matériel des clés. C'est ce second sujet qui nous passionne. Nous sommes arrivés sur le marché avec un constat simple : selon Chainalysis, environ 20 % des bitcoins ont été perdus parce que des gens ont égaré leurs clés privées. Clarisse Hagège, ma co-CEO, qui est banquière depuis dix ans, et moi, qui viens des consumer apps, nous avons eu la même réaction : le premier vecteur de risque, c'est l'utilisateur lui-même.
Nous sommes arrivés avec un point de vue complètement assumé, à contre-courant du "not your keys, not your coins". Nous avons choisi le MPC (la cryptographie multipartite) avec un schéma 3 sur 5, avec cinq fragments de clé répartis entre deux data centers AWS à Francfort et Paris.
Et surtout, contrairement à quasiment tous nos concurrents, nous ne mettons aucun fragment de clé privée dans les téléphones des utilisateurs. Les utilisateurs reçoivent des clés d'authentification. S'ils perdent leur téléphone, la récupération est toujours possible. Ce modèle n'est pas conçu pour les gens qui veulent devenir des parias du système financier. Il est conçu pour ceux qui vivent en société et qui veulent que leurs actifs soient protégés.
Comment l'offre a-t-elle évolué depuis ?
Elle est devenue beaucoup plus modulaire, sous la pression des banques. Au départ, tout tournait dans notre infrastructure AWS, en 3 sur 5. Puis les banques nous ont dit : “Nous avons nos propres ingénieurs, nos propres normes, nos propres réglementations, adaptez-vous”.
Première étape : nous avons permis de distribuer les fragments de clé chez le client, dans son compte AWS, Azure, peu importe, avec des schémas mixtes.
Deuxième étape : certaines banques utilisent des HSM et se fichent du MPC. Nous avons donc rendu possible le branchement de leur propre HSM. La signature est générée dans leur appareil, injectée dans une transaction que nous construisons et envoyons sur la blockchain. La clé ne transite jamais dans notre périmètre.
Troisième étape, sous l'impulsion d'IBM avec qui nous travaillons désormais : le déploiement complet on-premise. Un client peut installer et faire tourner l'intégralité des services sur ses propres machines, dans son propre environnement. Cet été, toute notre couche applicative (policies, permissions, broadcasting) pourra tourner intégralement chez le client. Nous sommes passés d'un produit monolithique à une architecture composable et agnostique. Les réglementations ont tellement changé, se sont affinées, ont changé d'opinion, que nous avons été contraints de rester flexibles.
"Dfns contre Fireblocks, c'est de plus en plus HubSpot contre Salesforce"
Les banques sont toutes en train de s'y mettre, mais elles ont tendance à vouloir gérer leur infrastructure de custody de A à Z. Comment vous inscrivez-vous dans cette demande ?
Nous leur proposons un choix clair : acheter notre technologie, la prendre en interne avec la licence, le code source, jusqu'au compte séquestre du code en cas de faillite. Elles avancent de cinq ans d'un coup. Mais il y a toujours la même question qui revient : comment intégrer cette nouvelle plateforme avec les systèmes existants. Et là, même quand notre technologie est la bonne, beaucoup préfèrent gérer la passerelle en interne.
Je pense qu'on va voir trois profils se dessiner. Des banques qui achètent tout clé en main. Des banques qui achètent un socle et construisent par-dessus. Et des banques comme Citi, avec leur plateforme CIDAP (Citi Integrated Digital Assets Platform), qui construisent quasiment tout en interne depuis deux ans et ne prendront que des composants mineurs. Notre stratégie, c'est de convaincre les indécis du milieu. Et d'attendre patiemment que ceux qui ont tout construit en interne constatent, dans cinq ou dix ans, qu'ils ont perdu de la vitesse.
>> Benchmark : l’adoption des actifs numériques par les banques françaises
La comparaison avec Fireblocks est inévitable. Comment vous distinguez-vous ?
Ça devient de plus en plus HubSpot contre Salesforce. Trois grandes différences structurelles persistent. D'abord, nous avons commencé comme une API, eux comme une interface graphique. Ça se sent partout dans le produit. Nous avons 150 API qu'ils n'ont pas, mais ils ont une UI plus complète que la nôtre. Si vous êtes un CFO qui déplace des fonds à la souris, Fireblocks sera plus confortable. Si vous êtes développeur et que vous voulez tout automatiser, vous aurez plus d'outils chez nous.
Ensuite, grâce à IBM, nous pouvons déployer l'intégralité de la plateforme en on-premise. Fireblocks fonctionne beaucoup en SaaS : les clés peuvent aller en local, mais le reste de la logique applicative, non. Or certains régulateurs l'exigent. Enfin, le pricing. Ce n'est pas tant que nous sommes moins chers, nous pouvons être très chers si nous le voulons, mais notre logique est différente. Nous ne voulons pas qu'un fournisseur d'infrastructure gagne de l'argent avant que l'application de son client n'en gagne. Ça n'a pas de sens. Nous préférons que nos clients décollent d'abord. Nous avons le temps, nous sommes patients.
Le consortium de banques européennes Qivalis a choisi Fireblocks pour son stablecoin euro. Comment jugez-vous cette décision ?
Il faut distinguer deux choses. Qivalis en tant que société a choisi Fireblocks pour stocker et émettre son stablecoin, et les banques fondatrices du consortium, ING, Danske Bank et quelques autres, ont été embarquées dans cette logique. Mais beaucoup de banques qui ont rejoint le consortium par la suite utilisent d'autres solutions, et c'est parfaitement accepté. Ce n'est pas un club où il faut utiliser Fireblocks pour entrer.
Notre lecture, c'est que le choix initial est surtout court-termiste et crypto-natif : distribuer rapidement un stablecoin euro sur les rails existants de la DeFi, comme instrument de liquidité pour les traders qui veulent réduire leur exposition au dollar. Pour ça, Fireblocks est un choix pratique. Mais il ne faut pas confondre cela avec un choix d'infrastructure bancaire de moyen et long terme.
Ce qui est révélateur, d'ailleurs, c'est que cette annonce a surtout été amplifiée par Fireblocks. Ce n'est pas anodin. Dans les RFP bancaires, là où les décisions se prennent vraiment, ils perdent du terrain face à des acteurs plus adaptés aux exigences d'intégration, de gouvernance et de contrôle des grandes institutions.
La question d'une licence aux États-Unis se pose-t-elle pour vous, afin d’être plus compétitif sur ce marché ? Votre concurrent BitGo, par exemple, a notamment décroché le contrat avec Robinhood pour cette raison…
Certains dans notre équipe nous poussent à y réfléchir. Il y a du business à faire avec une licence bancaire. Mais à chaque fois que nous allons au bout de cette réflexion (compliance, recrutement, changement de culture interne, etc.), la conclusion est souvent la même : ce n'est pas notre métier. Après il y a de la place dans ce monde-là, à condition de rester soi-même. Nous, nous sommes là pour construire des autoroutes. Ça va prendre du temps, et il faut s'installer dans cette logique.
"Aucune blockchain n'a prouvé qu'elle pouvait fonctionner à l'échelle d'un Visa"
Dfns est devenu validateur Canton. Comment voyez-vous ce réseau ?
Canton est intéressant parce que son architecture de chaînes privées avec un coordinateur public (le Global Synchronizer, géré par la Fondation Linux) offre une réponse crédible au problème de la confidentialité. On peut mener des activités privées et régler publiquement quand on le souhaite. Le meilleur des deux mondes. Aujourd'hui, l'enjeu est de faire en sorte que suffisamment de contreparties qui traitent déjà ensemble dans le monde réel créent des chaînes privées sur Canton. La chaîne publique, elle, est encore sous-utilisée.
Mais je note que depuis le succès de Canton, il y a eu une grosse vague privacy dans l'industrie : Hedera Hashgraph, Solana qui relance les confidential balances, Zama sur Ethereum, etc.. Canton domine cette narrative actuellement. Son CEO Yuval Rooz fait partie des personnes les plus intelligentes que je connaisse dans cette industrie.
Après nous restons agnostiques : Polygon et Ethereum restent les chaînes les plus utilisées par nos clients, mais nous regardons tout.
>> Canton Network : analyse de la blockchain conçue pour les institutionnels
Plus largement, une blockchain a-t-elle prouvé sa capacité à fonctionner à l'échelle institutionnelle ?
Non. Nous avons fait des tests avec Visa sur Solana, qui est présentée comme l’une des blockchains les plus véloces. Quand on retire les signatures de votes (de DAO par exemple, ndlr), qui représentent environ 2 000 des 3 000 transactions par seconde sur Solana, il ne reste qu'un millier de vraies transactions financières. D’un point de vue Visa, ce n'est vraiment pas suffisant.
On est en 2026 et aucune blockchain ne s'est réellement prouvée capable de fonctionner en production, à l'échelle, avec les contraintes d'un Visa, d'un IBM ou d'un Oracle. La quantité de prérequis corporate qu'il faut remplir (policies, certifications, audits) est énorme. C'est pour ça qu'il y a encore autant d'excitation autour des projets qui promettent du progrès. Et c'est pour ça que nous restons agnostiques.
"Aux Émirats, récemment, après des bombardements, nous avons été capables de remettre des clients sur pied en une journée"
Vous confiez récemment que les data centers étaient des cibles en période de guerre, comme on a pu le voir récemment au Moyen-Orient. C'est un discours inhabituel pour un fournisseur d'infrastructure…
Ça fait longtemps que je le dis en interne, pas publiquement. Un data center, en période de guerre, c'est une cible irrésistible. Regardez les zones de disponibilité d'AWS aux Émirats : il y en a un à Abu Dhabi, un à Dubaï. C'est à une heure de route. Si une zone est touchée, le risque de cascade est réel.
Pourquoi le MPC offre-t-il un avantage dans ce contexte précis ?
Grâce à la cryptographie à seuil, vous pouvez rafraîchir une clé privée sans changer la clé publique. Si vous avez cinq fragments distribués entre Bahreïn, Abu Dhabi et un troisième site, et que deux d'entre eux sont compromis, vous pouvez régénérer les fragments ailleurs. C'est une capacité que n'offre pas un HSM classique, où la clé est générée de manière unique dans un device physique. Le backup existe, mais c'est plus lourd, moins agile.
Aux Émirats, récemment, après des bombardements, nous avons été capables de remettre des clients sur pied en une journée, ailleurs. Ceux qui utilisaient du HSM n'ont pas été remis en service aussi rapidement. C'est un fait. Mais sauver la clé ne suffit pas. Il faut aussi que la plateforme puisse tourner ailleurs.
Nous développons une architecture active-active : notre code tourne simultanément dans plusieurs environnements, et si l'un tombe, l'autre prend le relais. L'idéal, c'est du multi-cloud, Google avec Azure, Azure avec AWS, etc. C'est complexe, mais indispensable dans une période turbulente.
Conseillez-vous à vos clients de quitter les data centers au Moyen-Orient ?
Ce n'est pas si simple. Les régulateurs locaux exigent souvent que l'infrastructure soit sur le sol national, saisissable par la police. Dans beaucoup de pays, il n'y a pas d'AWS ni de Google, il y a des data centers privés certifiés. Ce que nous avons fait avec IBM, c'est rendre chaque composant de notre plateforme agnostique : du code open source compatible avec n'importe quel environnement, y compris IBM Cloud.
En Europe, il y a DORA. Aux États-Unis, il y a FISMA depuis 2002. La tendance de fond est la même partout : chaque composant jugé critique doit avoir un plan B, et si possible un plan C. C'est un travail lourd. Nous ne sommes pas parfaits là-dessus. Nos concurrents le sont encore moins.
"On va publier le quatrième papier au monde sur la signature post-quantique à seuil"
Google a beaucoup fait parler en estimant que le quantique pourrait arriver plus vite que prévu. Le post-quantique, c'est un vrai sujet opérationnel pour vous dès aujourd'hui ?
Nous travaillons avec l'École polytechnique sur un papier de signature à seuil post-quantique, c’est-à-dire du TSS post-quantique. Ce sera le quatrième papier au monde sur le sujet. Nous prévoyons une première implémentation cette année. Nous avons commencé avant même que Google ne publie son propre papier. Nous prenons ça très au sérieux. Et les blockchains doivent faire de même : se préparer à une migration, toutes sans exception. Si elles ne bougent pas assez vite, de nouvelles blockchains apparaîtront pour les remplacer.
L'IA représente-t-elle un danger pour la sécurité de vos infrastructures ?
Bien sûr. Mais nous nous battons avec de l'IA aussi. Nous utilisons Almanax depuis un an et demi pour scanner le code open source, les dépendances et les vulnérabilités. L'IA est à la fois la menace et l'arme de défense. Sur la vérification formelle, qui est parfois présentée comme la solution absolue, la vraie limite est connue : tout repose sur la qualité des hypothèses de départ. Si vos hypothèses sont fausses, tous vos calculs le sont aussi. C'est comme en physique. Mais nous allons y venir. Et au-delà de la sécurité, l'IA va transformer la façon dont nous produisons et testons le code. Nous allons shipper à une vitesse inédite. Notre équipe sécurité a un peu plus peur, elle veut des guardrails partout. C'est un vrai travail d'équilibre.
Un dernier message ?
J'appelle les régulateurs à inviter les fournisseurs de technologie à la table, directement, pas seulement à travers leurs clients financiers. Aujourd'hui, chaque banque présente son fournisseur d'infrastructure, nous, Fireblocks, Taurus, à sa façon au régulateur. Il y a une déperdition d’informations importante. Il y a un niveau de détail technique que nos clients ne maîtrisent pas aussi bien que nous. Quand j'entends que certaines entreprises américaines clament qu’elles ont l'oreille de l'AMF, alors que nous, acteur européen, n'avons pas cet accès direct... Il y a quelque chose à corriger. Les régulateurs seraient plus efficaces s'ils entendaient directement les ingénieurs qui construisent ces systèmes.
%201.png)
%201.png)
%201.png)
%201.png)
%201.png)
