Igor Kulatov, ancien cofondateur et CTO de NAGA Group AG, sur les décisions d’ingénierie qui ont fait de NAGA la référence que le marché a suivi
En tant que cofondateur et CTO de NAGA Group AG, Igor Kulatov a développé Swipestox – la plateforme de trading social qui a propulsé l’entreprise jusqu’à son introduction en bourse à la Bourse de Francfort en juillet 2017. Après l’introduction en bourse, il a mené le développement crypto : moteur de matching, architecture de garde multi-chaînes et intégration des plateformes multi-actifs, le tout aboutissant à l’offre initiale de pièces de NAGA (la vente du token NGC) la même année. Il dirige aujourd’hui Aurora Borealis, une entreprise autonome B2B (business-to-business) dédiée au commerce, opérant en production alors que l’industrie était encore en train de déterminer comment appeler cette catégorie. Les deux sont de vrais exemples de construction, tandis que la plupart du marché ne comprend pas encore pourquoi, ou n’attend que le bon moment pour effectuer sa prochaine manœuvre. Nous avons parlé de la façon dont il lit cette direction, de ce qui a imposé les choix précis chez NAGA, et de ce qui a été transféré à ce qu’il construit maintenant.
Q1. Votre carrière suit un schéma précis. Avant NAGA ou la société de commerce autonome, la plupart des ingénieurs autour de vous auraient eu besoin, sur leurs tableaux blancs, d’un ensemble totalement différent de nombres. Qu’est-ce que vous regardez quand vous essayez de déterminer où se trouvera un marché dans cinq ou sept ans ?
Je n’avais pas besoin de prédire l’avenir des crypto. Je disposais d’une image de travail de ce à quoi ressemble une bourse mature : j’avais construit des systèmes d’échange avant NAGA, et je savais quelle était la norme du côté traditionnel. En 2016 et 2017, la plupart des plateformes crypto ont été construites par des équipes qui abordaient le problème dans l’autre sens — du crypto vers l’extérieur, et non avec la discipline de l’échange en place. Elles manquaient donc des éléments qu’une bourse mature tient pour acquis : les performances du moteur de matching pour des flux institutionnels, une frontière de conservation que le régulateur peut lire sur papier, et une structure juridique capable de porter à la fois un carnet d’actions et de la vraie crypto. Ma règle de travail était simple : concevoir pour la norme qui arrive, pas pour celle qui est pratique maintenant. En crypto en 2017, la norme pratique consistait à tout écrire vite et à repousser les parties difficiles. La norme à venir allait ressembler beaucoup plus à un échange réglementé. J’ai donc conçu en ce sens.
Q2. Prenez un de ces chiffres. En 2017, la référence open-source du moteur de matching était Liquibook, à environ deux à deux millions et demi d’insertions par seconde. Vous en avez construit un autour de huit millions de matches par seconde sur des tests synthétiques. Qu’est-ce qui vous a fait penser que le plafond devait être aussi élevé ?
Ce manque paraît plus grand qu’il ne l’est en réalité — Liquibook publie le débit d’insertion, et le matching est une opération plus lourde par événement. Le chiffre brut n’a pas poussé la conception. Ce qui l’a motivée, c’est que nous construisions pour une catégorie de flux que le camp crypto n’avait pas encore vue. Les traders institutionnels apportent des machines qui ne s’arrêtent jamais. L’écart entre un plafond de 500 000 matches par seconde et un plafond de 8 millions, c’est la différence entre reconstruire votre moteur la troisième année et faire tourner le même pendant la huitième. Donc nous en avons la maîtrise de bout en bout. Un moteur de matching est suffisamment petit pour que quelques milliers de lignes de votre propre code surpassent une bibliothèque qui doit rester sûre pour tout le monde. Binance a reconstruit son moteur de matching en juin 2020 — en le réécrivant de zéro dans un nouveau langage, environ deux ans de travail d’ingénierie, avec un gain de performance d’environ dix fois. Ce type de reconstruction n’est pas seulement un coût de développement : c’est deux années pendant lesquelles le système tourne sous une charge pour laquelle il n’avait pas été conçu — ce qui signifie de la mise en file d’attente lors des pics de volatilité, des ordres retardés, et un flux qui se dirige vers celui qui peut l’encaisser. La raison pour laquelle nous n’avons pas eu à faire cela en 2020, c’est que nous avions déjà conçu pour ce plafond en 2017.
Q3. Même logique côté conservation. Vous êtes passé en non-conservation en 2017, avant que Fireblocks n’existe comme produit. Quel signal vous a indiqué que le défaut commercial — une conservation en custody avec une assurance derrière — serait la mauvaise réponse ?
Mt. Gox était encore tout frais, Coincheck a été touché au début de 2018 pour l’équivalent d’environ un demi-milliard de dollars, et la solution « simple » vers laquelle tout le monde se tournait côté commercial était : une assurance derrière la conservation en custody. Vous gardez les clés, vous payez une prime, et vous espérez que personne ne vient les réclamer. Le problème, c’est que l’assurance ne répare pas un piratage ; elle ne fait que le monétiser. Si la crypto d’un client disparaît, le client a perdu l’actif, même si la bourse a été payée. Nous avons donc construit une architecture plus difficile : sur chaque chaîne supportée, la plateforme détenait une part de signature et le client détenait l’autre, et aucun des deux côtés ne pouvait déplacer des fonds à lui seul ; et ce modèle de conservation était lui-même une option — les clients pouvaient conserver leur crypto dans leurs propres portefeuilles externes et déposer ou retirer directement vers l’échange, en portant eux-mêmes tout le risque de conservation. Si notre base de données avait fuité, un attaquant aurait obtenu les parts de la plateforme et rien d’autre — aucun solde, aucune identité, aucun moyen de signer. Ce que nous avons combiné n’étaient pas de nouveaux principes ; nous avons juste choisi de les intégrer à la structure d’un courtier réglementé en 2017, alors que l’option la plus confortable était de détenir toutes les clés nous-mêmes et d’acheter la police.
Q4. eToro est passé par la voie des produits dérivés avec des CFD crypto. Interactive Brokers a choisi les futures ensuite. Vous avez opté pour le spot — le coin réel, sur le même compte que des valeurs mobilières classiques. Qu’est-ce qui vous a fait penser que la voie des dérivés ne serait pas l’avenir ?
Les deux routes étaient plus faciles commercialement et plus silencieuses côté régulation, et toutes deux offraient aux clients quelque chose qui ressemblait à une exposition à la crypto sans leur donner l’actif. Un CFD ou un contrat à terme suit l’évolution du prix. Il ne met pas une cryptomonnaie entre les mains d’un client. Si le client veut envoyer la pièce quelque part, la retirer vers un portefeuille personnel, l’utiliser en dehors de la plateforme — le dérivé ne peut pas le faire. Vous vendez de l’exposition, pas la propriété. La crypto spot sur le même compte que les valeurs mobilières réglementées du client leur donne l’actif et le régime réglementaire du groupe qui l’encadre. Ce n’était pas une revendication que le camp crypto, en soi, était autorisé à faire — aucune juridiction n’avait un cadre pour cela en 2017 — mais cela fonctionnait au sein de la même entité corporative qu’un courtier réglementé. La combinaison était rare parce qu’elle vous obligeait à résoudre vous-même le problème de la conservation. C’était la seule voie qui traitait la crypto comme un vrai instrument financier, et pas comme une surface synthétique construite par-dessus. Le cadre européen a rattrapé en 2024, avec MiCA ; et chaque courtier de détail qui a ajouté du spot crypto après 2020 (Trade Republic en Allemagne, Robinhood aux États-Unis, Revolut qui arrive en ligne) a abouti à la même intégration que celle que nous avons livrée en 2017.
Q5. Certaines de ces décisions ont aujourd’hui sept ou huit ans. Qu’est-ce qui vous dit qu’elles sont encore essentielles aujourd’hui, plutôt que de n’être qu’un héritage du passé ?
Ce sont des décisions qui portent la charge, et c’est le test. Une architecture bien conçue est celle vers laquelle les autres convergent indépendamment — pas parce qu’ils l’ont copiée, mais parce que le problème sous-jacent impose la même réponse. Le moteur de matching que j’ai décrit tourne encore en production aujourd’hui. Avant son lancement, il a subi plus de deux ans de tests bêta, et un cabinet indépendant de teneurs de marché a effectué des tests de résistance externes à travers lui. Si le pari avait été mauvais, on l’aurait découvert maintenant. Si le pari avait été mauvais, on l’aurait découvert maintenant. TCP/IP a été conçu dans les années 1970 et fonctionne encore sur Internet. SQL a cinquante ans et demeure dominant. Les bons choix architecturaux ne paraissent historiques qu’à distance. Ce qui a été transféré dans ce que je fais tourner depuis 2020, c’est l’hypothèse opérationnelle derrière ces choix : construire pour la norme à venir, pas pour celle qui est pratique. Le travail actuel se situe dans le commerce autonome inter-entreprises, et la discussion réglementaire à ce sujet se construit encore. La même discipline s’applique.
Q6. Si quelqu’un démarrait aujourd’hui au même carrefour — finance réglementée, vraie crypto, flux piloté par la machine — que lui diriez-vous ?
Trois choses, aucune d’elles n’était vraiment nouvelle. Premièrement : faire de l’architecture de la licence la décision principale — vous ne pourrez pas surpasser, à grande échelle, une erreur de conformité, et le nombre de choix de conception qui découlent de la structure de la licence est plus grand que ce que la plupart des équipes techniques anticipent au départ. Deuxièmement : traiter la conservation comme une préoccupation architecturale de premier plan, et pas comme un simple ajout sécurité — si vous pouvez intégrer la frontière de conservation dans vos propres systèmes et la décrire avec précision à un régulateur, vous vous évitez toute une catégorie d’incidents que d’autres passeront la décennie suivante à contester en justice. Et enfin : l’ingénierie « ennuyeuse » gagne le match du débit. En 2017, il y avait beaucoup de bruit autour de structures de données ingénieuses et de matériel exotique, mais les plateformes qui sont arrivées à de vrais chiffres étaient celles qui prenaient des décisions peu glamour, de façon constante. Cela n’a pas changé.
