Après Binance, les DSI européens face à une question qui ne peut plus attendre : à qui confions-nous nos flux financiers ?

# Après Binance, les DSI européens face à une question qui ne peut plus attendre : à qui confions-nous nos flux financiers ?

*En 2026, le piratage de Binance a remis sur la table une question que beaucoup de DSI d'ETI européennes avaient mise en attente : celle de la dépendance à des infrastructures de paiement dont on ne maîtrise ni les règles, ni la localisation des données, ni les conditions de résilience. Nous avons interrogé un DSI d'une ETI industrielle française de taille intermédiaire, qui gère à la fois des flux clients B2B et des paiements fournisseurs à l'échelle européenne. Il a souhaité rester anonyme.*

RiffLab : Le piratage de Binance a visé une plateforme crypto. En quoi cela concerne-t-il concrètement un DSI d'ETI qui n'est pas dans la finance décentralisée ?

C'est exactement la question que certains de mes collègues m'ont posée la semaine suivante, en mode « ce n'est pas notre problème ». Mais si on lit l'incident correctement, ce n'est pas un problème crypto. C'est un problème d'infrastructure de confiance. Binance était devenu, pour des centaines d'entreprises en Europe — y compris des PME qui utilisaient des services adossés à ses APIs de paiement —, un maillon silencieux dans leur chaîne de règlement. Quand ce maillon a sauté, les équipes IT ont découvert qu'elles avaient une dépendance qu'elles n'avaient pas documentée. C'est ça le vrai signal d'alarme pour un DSI : l'opacité de la chaîne de dépendance. Pas l'incident lui-même.

RiffLab : Concrètement, comment ce type d'incident modifie-t-il le travail des équipes IT au quotidien ?

Dans l'immédiat, ça génère une charge d'audit non planifiée. Mes équipes ont dû cartographier en urgence l'ensemble des connecteurs de paiement actifs dans notre SI — et je dis bien en urgence, parce que cette cartographie n'était pas à jour. C'est un aveu difficile à faire, mais c'est la réalité de beaucoup d'ETI : les intégrations de paiement s'accumulent au fil des projets métier, sans gouvernance centralisée. Un connecteur Stripe ici, une API tierce là, un prestataire de tokenisation dont le siège social est dans un territoire qu'on ne saurait même pas situer sur une carte. L'incident Binance a agi comme un révélateur. Après ça, on a imposé un registre des dépendances financières dans notre référentiel d'architecture. Ce n'était pas prévu dans la roadmap. Ça a coûté des semaines-homme. Et ça va continuer à coûter, parce que maintenant on audite ces connecteurs à chaque release.

RiffLab : Le terme « paiement souverain » circule depuis plusieurs années en Europe. En 2026, est-ce encore un concept abstrait ou c'est devenu opérationnel pour les équipes IT ?

C'est devenu opérationnel, mais de façon inégale. Ce qui a changé, c'est que des solutions comme celles portées autour de l'initiative EPI — l'European Payments Initiative — ont commencé à avoir une traduction concrète dans des outils que des intégrateurs proposent réellement. Ce n'est plus seulement un discours institutionnel. Mais il faut être honnête : la maturité n'est pas uniforme. Pour une équipe IT qui doit intégrer une brique de paiement dans un ERP, la friction technique reste plus faible du côté des acteurs américains dominants. Ils ont des SDKs bien documentés, des communautés de développeurs actives, des intégrations natives avec les outils qu'on utilise déjà. L'alternative européenne demande souvent plus d'effort d'intégration. C'est un investissement réel, pas une case à cocher.

RiffLab : Cet effort d'intégration supplémentaire, comment le justifiez-vous en interne face à une direction financière ou un COMEX qui raisonne en coût immédiat ?

Je le cadre comme un risque, pas comme un choix éthique. Le prisme éthique ou souverainiste, en comité de direction, il tient cinq minutes. Ce qui tient, c'est la question : que se passe-t-il si notre prestataire de paiement américain est soumis demain à une injonction réglementaire américaine qui le contraint à bloquer ou à exposer nos données de transaction ? C'est arrivé dans d'autres secteurs. Les équipes juridiques le savent depuis le Cloud Act. Appliqué aux flux financiers, c'est une exposition que personne autour de la table ne peut défendre sereinement. Ensuite, je pose la question de la résilience opérationnelle : si le service tombe, si les conditions tarifaires changent unilatéralement, si l'API est dépréciée, quel est notre plan B ? Avec un acteur dont les serveurs, les équipes de support et les décisions produit sont hors d'Europe, le plan B est très mince. C'est sur ces deux arguments — risque de conformité et risque de continuité — que j'obtiens les arbitrages.

RiffLab : Quels critères techniques utilisez-vous désormais pour évaluer une solution de paiement dans le cadre d'un appel d'offres IT ?

On a refondu notre grille d'évaluation après l'incident. Aujourd'hui, les critères non négociables sont : la localisation des données de transaction sur sol européen, avec justification contractuelle et pas seulement déclarative ; la capacité à auditer les logs de façon autonome sans dépendre d'une interface propriétaire qu'on ne contrôle pas ; la conformité DORA, qui depuis son entrée en vigueur effective a changé le niveau d'exigence sur la résilience des prestataires tiers. Et un critère qui peut paraître secondaire mais qui compte vraiment dans le travail quotidien des équipes : la qualité de la documentation en cas d'incident. Quand un paiement échoue à deux heures du matin, est-ce que mon équipe d'astreinte peut diagnostiquer sans avoir besoin d'appeler un support localisé en dehors du fuseau horaire européen ? C'est un critère de productivité réelle, pas un détail.

RiffLab : DORA, justement — est-ce que ce cadre réglementaire a réellement changé la façon dont les équipes IT abordent la question des prestataires de paiement tiers ?

Oui, et de manière concrète. DORA a imposé une rigueur documentaire sur les tiers critiques qui a obligé beaucoup d'équipes IT à sortir la tête du guidon opérationnel. On ne peut plus avoir une dépendance à un prestataire de paiement sans contrat de service qui précise les délais de notification d'incident, les tests de résilience partagés, les clauses de sortie. Ce formalisme, avant DORA, était souvent négligé parce que jugé trop contraignant face à la vélocité des projets. Maintenant c'est une obligation. Et honnêtement, ça a rendu service à des équipes comme la mienne pour imposer des discussions qu'on n'arrivait pas à faire aboutir en interne. Le régulateur a dit ce que le DSI n'arrivait pas à faire entendre. C'est un levier politique interne que je ne sous-estime pas.

RiffLab : Dernière question : dans votre lecture de l'incident Binance, y a-t-il un signal que les DSI européens ont collectivement sous-estimé ?

Oui. La vitesse à laquelle des dépendances invisibles se constituent dans un SI. Personne dans mon équipe n'a délibérément choisi de faire entrer Binance dans notre périmètre. C'est entré par capillarité — un prestataire de notre prestataire, une API intégrée dans un outil SaaS qu'on utilisait sans regarder ses propres dépendances. C'est ce que j'appelle la dette de souveraineté : elle s'accumule silencieusement, exactement comme la dette technique, et elle devient visible uniquement au moment de la crise. Le piratage Binance a été, pour beaucoup d'équipes IT européennes, le moment où cette dette est devenue audible. La vraie question maintenant, c'est combien d'équipes vont en profiter pour rembourser — et combien vont attendre le prochain incident.

*Interview réalisée par la rédaction de RiffLab Media. L'interlocuteur a souhaité conserver l'anonymat.*