**Même lorsque les clés privées n’ont pas nécessairement été divulguées, les fonds peuvent tout de même être transférés. Le secteur des cryptomonnaies doit repenser sa conception de la « sécurité des portefeuilles ».**
*Cet article s’appuie sur des informations publiques vérifiées au 30 octobre 2026. L’état des services est celui indiqué dans la mise à jour officielle de 12 h 36, heure de Pékin. L’incident fait toujours l’objet d’une enquête ; les conclusions préliminaires ne constituent pas la cause première définitive. Texte soumis à relecture, non publié.*
## I. Commençons par clarifier les faits
Au petit matin du 30 octobre, heure de Pékin, Binance a été victime d’un grave incident de sécurité.
Mais il faut d’abord corriger une affirmation qui risque d’induire en erreur : les éléments disponibles indiquent qu’il s’agit du **portefeuille chaud et de l’infrastructure de retrait de l’exchange centralisé Binance**, et non d’une vulnérabilité avérée du produit d’auto-conservation Binance Wallet. Bien qu’ils partagent une marque, les deux produits ont des modes de contrôle des actifs et des périmètres de sécurité différents.
Selon le rapport d’enquête préliminaire publié par Binance à 10 h 25, heure de Pékin, l’impact total de l’incident est estimé à environ 6,3 milliards de dollars, et environ 3 milliards de dollars ont été gelés sur la chaîne. Binance a déclaré que le fonds SAFU et les fonds de l’entreprise couvriraient l’intégralité des pertes, et qu’aucune preuve de fuite de clés privées de portefeuilles n’avait été trouvée à ce stade.[1]
Ces affirmations doivent être comprises séparément.
L’« impact total » n’est pas la perte nette définitivement établie ; le « gel » ne signifie pas que les fonds ont été restitués ; la « prise en charge de l’intégralité des pertes » est une promesse d’indemnisation de l’entreprise, et non la preuve que l’indemnisation et la récupération des actifs sont déjà achevées.
Selon la dernière mise à jour officielle des services prise en compte dans cet article, les dépôts fonctionnent normalement, mais les retraits restent suspendus. Binance prévoit de les rétablir dans les 48 heures. Il s’agit d’une prévision de reprise, et non d’un service déjà rétabli ni d’une garantie inconditionnelle.[2]
Pour les utilisateurs, cet incident a déjà eu deux conséquences distinctes : la question de savoir qui prendra en charge les pertes d’actifs et celle de savoir quand les fonds pourront de nouveau être utilisés librement. Même si la plateforme finit par indemniser intégralement les utilisateurs, les contraintes de liquidité causées par la suspension des retraits ne disparaîtront pas automatiquement.
## II. Pourquoi l’évolution des informations au fil de quelques heures est importante
La société d’analyse on-chain TRM indique que les principaux transferts de fonds ont commencé vers 4 h 05, le 30 octobre, heure de Pékin.
À 8 h 30, heure de Pékin, TRM avait recensé des actifs transférés depuis dix chaînes, pour une valeur d’environ 6,36 milliards de dollars au moment des transferts, et des fonds gelés à hauteur d’environ 2,7 milliards de dollars.[3]
Par la suite, à 10 h 25, Binance a annoncé un impact total estimé à environ 6,3 milliards de dollars, dont environ 3 milliards déjà gelés, et a communiqué les premières pistes sur l’intrusion.
À 12 h 36, les autorités de Binance ont précisé que l’incident impliquait plusieurs facteurs, que l’ordinateur d’un ingénieur compromis avait pu servir de point d’entrée et que le rapport complet sur les causes premières restait à venir. Elles ont également mis à jour l’état des dépôts et des retraits.
Cette chronologie explique pourquoi les articles mentionnent à la fois 6,3 milliards, 6,36 milliards, 2,7 milliards et 3 milliards de dollars.
Ces chiffres ne sont pas nécessairement contradictoires : l’heure des statistiques, celle de l’évaluation des actifs et le périmètre pris en compte peuvent différer. Combiner les statistiques on-chain les plus anciennes avec les annonces officielles ultérieures pour calculer une « perte restante » apparemment précise risque plutôt d’induire en erreur.
De même, les premiers messages indiquant que « les dépôts et les retraits sont suspendus » ne remplacent pas l’état des services communiqué un peu plus tard : « les dépôts fonctionnent normalement, les retraits restent suspendus ».
Lorsqu’on rend compte d’un incident de sécurité majeur, il ne suffit pas de se demander si les chiffres proviennent de sources fiables. Il faut aussi demander : **à quel moment et selon quelle méthode ont-ils été établis, et ont-ils été mis à jour depuis ?**
## III. Pourquoi des fonds peuvent-ils être volés alors qu’aucune fuite de clés privées n’a été démontrée ?
C’est la question qui mérite le plus d’être approfondie dans cette affaire.
L’enquête préliminaire de Binance indique que l’incident pourrait impliquer l’ordinateur portable compromis d’un ingénieur DevOps. Les attaquants auraient ainsi accédé à des conteneurs de services et soumis des transactions de retrait non autorisées.
Ici, le mot-clé n’est pas « ordinateur portable », mais la chaîne d’autorisations reliant un terminal aux opérations sur les fonds.
Dans une grande plateforme, le transfert d’actifs ne se résume généralement pas à quelqu’un qui ouvre un portefeuille et saisit un mot de passe manuellement. Il s’agit plutôt d’un processus automatisé : le système métier émet une requête, le système de gestion des risques vérifie la transaction, le service de signature la signe et le service de diffusion la transmet à la chaîne.
Les attaquants n’ont donc pas nécessairement besoin de copier les clés privées.
Si les attaquants parviennent à usurper l’identité d’un service de confiance, à modifier une demande de transaction ou à inciter un dispositif de signature légitime à approuver une transaction malveillante, ils peuvent également obtenir la capacité de transférer effectivement des fonds.
C’est comme si la clé du coffre-fort d’une banque n’avait pas été dérobée, mais que quelqu’un avait émis un ordre de paiement valide par l’intermédiaire du système interne.
Selon l’analyse de TRM, les attaquants auraient très probablement réussi à faire signer par le système de signature du portefeuille chaud de l’exchange les transactions inter-chaînes de leur choix.[3]
Cela n’est pas nécessairement incompatible avec l’affirmation de Binance selon laquelle elle n’a « pas encore trouvé de preuve d’une fuite de clés privées ». La première affirmation porte sur l’éventuel détournement de la capacité de signature, la seconde sur l’éventuelle fuite de clés privées. Ces deux risques peuvent se recouper, mais il ne s’agit pas de la même chose.
Toutefois, à ce stade, on ne peut pas non plus affirmer que des vulnérabilités précises du système de signature, des conteneurs ou d’un mécanisme d’approbation ont été définitivement démontrées. Le rapport d’expertise devra encore établir la chaîne complète de l’attaque.
La vraie question est la suivante : après la compromission d’un terminal de développement et d’exploitation, pourquoi celui-ci pouvait-il potentiellement accéder aux opérations sur les fonds ? Quels contrôles auraient dû bloquer cet accès ? Qu’ont-ils détecté pendant l’attaque et qu’ont-ils autorisé ?
## IV. EIP-7702 : il ne s’agit pas seulement de « transférer », mais aussi d’« autoriser »
L’enquête de TRM indique également que les activités d’attaque sur Ethereum impliquaient EIP-7702 et 50 autorisations pré-signées.[3]
EIP-7702 permet à un compte externe, au moyen d’une autorisation signée, de déléguer l’exécution d’un code donné dans le contexte de ce compte, et prend en charge des fonctions telles que les opérations groupées et le paiement des frais de transaction par un tiers.[4]
Ce qui change, c’est qu’une signature peut ne pas se limiter à autoriser un transfert : elle peut aussi modifier la manière dont le compte exécutera les opérations suivantes.
La sécurité des portefeuilles ne doit donc pas seulement vérifier « à qui transférer » et « quel montant », mais aussi :
Cette signature délègue-t-elle l’exécution d’un code ? La cible de cette délégation a-t-elle été auditée ? De quelles capacités d’action sur le compte disposera-t-elle ? L’autorisation restera-t-elle active ?
Il faut toutefois bien délimiter ce que cela signifie.
**La présence d’une autorisation EIP-7702 ne signifie pas que la cryptographie d’Ethereum a été compromise et ne prouve pas automatiquement l’existence d’une vulnérabilité fondamentale dans le protocole.** Le risque peut provenir de la génération de l’autorisation, de l’approbation de la signature, du code cible ou du détournement de services associés. Le type de transaction, à lui seul, ne suffit pas à établir la cause première.
Cela ne permet pas non plus d’expliquer à lui seul tous les transferts anormaux observés sur différentes blockchains.
La question plus générale soulevée par cet incident est la suivante : à mesure que les fonctionnalités des comptes se multiplient, les systèmes de sécurité savent-ils toujours comprendre les changements d’autorisations, au lieu de les traiter comme de simples transferts ?
## V. Le gel de 3 milliards de dollars : un progrès pour limiter les pertes, mais aussi une leçon sur la structure des actifs
Le gel d’environ 3 milliards de dollars sur la chaîne montre que le suivi des fonds et la coordination des interventions ont permis de limiter les pertes de manière significative.
Mais tous les actifs ne peuvent pas être traités de la même façon.
Certains émetteurs de stablecoins peuvent geler les actifs associés à une adresse ; certains réseaux ou protocoles disposent également de mécanismes d’urgence spécifiques. Pour les actifs natifs dépourvus de mécanismes de contrôle similaires, le suivi et la récupération dépendent généralement davantage de la trajectoire ultérieure des fonds, de la coopération des plateformes d’échange et des actions des autorités.
Cela remet en évidence la tension entre « décentralisation » et « possibilité de récupération ».
Dans les discussions courantes, le pouvoir de gel est souvent considéré comme un risque de centralisation. Après un vol de grande ampleur, cette même capacité peut devenir un outil de protection des victimes. Ces deux aspects sont bien réels : le succès d’une opération visant à limiter les pertes ne doit pas faire oublier le coût de gouvernance qu’elle implique.
Le passage du gel à la restitution peut aussi nécessiter des procédures judiciaires, la confirmation de la propriété des fonds et une coordination transfrontalière.
Le montant des fonds gelés est donc un indicateur de progrès important, mais ne peut pas être assimilé directement au taux de récupération final. La plateforme doit encore préciser quels fonds sont sous contrôle, lesquels ont été restitués et lesquels ne peuvent faire l’objet que d’un suivi.
## VI. La capacité d’indemnisation, la solvabilité et la confiance sont trois choses différentes
L’engagement de Binance à couvrir l’intégralité des pertes au moyen du fonds SAFU et des fonds de l’entreprise est important pour stabiliser les attentes des utilisateurs.
Mais l’indemnisation financière et la réparation du système sont deux examens distincts.
Le premier examen est financier : comment les pertes seront-elles évaluées ? D’où viendront les fonds nécessaires ? Après la prise en charge des pertes, les actifs et les passifs resteront-ils équilibrés ?
Le deuxième examen est technique : la voie d’attaque a-t-elle réellement été neutralisée ? Les autorisations concernées ont-elles été révoquées ? Les adresses, les identités des services et l’infrastructure ont-elles été vérifiées et reconstruites ?
Le troisième examen est opérationnel : quand les retraits reprendront-ils ? La reprise se fera-t-elle réseau par réseau ? Comment les demandes en attente seront-elles traitées ? Les clients institutionnels pourront-ils ajuster à temps leurs garanties et leurs modalités de règlement ?
Les preuves de réserves peuvent apporter une certaine transparence sur les actifs, mais elles ne prouvent pas à elles seules que le système n’a pas été compromis et ne couvrent pas, à elles seules, l’ensemble des passifs, des charges pesant sur les actifs ni les problèmes de liquidité.
Pour les traders, le risque ne se limite pas à une éventuelle diminution du solde affiché. Lorsque les actifs ne peuvent temporairement pas être transférés, l’arbitrage entre plateformes, l’ajout de marge et la couverture des risques peuvent également être affectés.
En l’absence de données suffisantes, il est déconseillé d’attribuer toutes les fluctuations d’un actif à cet incident, et encore moins d’en tirer des prévisions de prix catégoriques. Il est plus utile de suivre la reprise des retraits, les écarts de prix entre plateformes, la profondeur du marché, ainsi que la capacité des informations sur les indemnisations et les réserves à résister à un examen continu.
## VII. La sécurité du secteur délaisse progressivement la « garde des clés » au profit du « contrôle des autorisations »
Si les conclusions de l’enquête confirment la piste d’intrusion actuellement décrite, l’importance de cet incident ne se limitera pas à l’ampleur des pertes.
Il rappelle au secteur que protéger les clés privées reste nécessaire, mais ne suffit plus à garantir la sécurité des fonds dans son ensemble.
Les signatures multiples, le MPC et les modules de sécurité matériels peuvent réduire certains risques liés aux clés, mais ils ne suppriment pas automatiquement les risques de falsification des requêtes métier, de corruption du contexte d’approbation ou de dépendance de plusieurs signataires à un même système compromis.
Si tous les approbateurs voient les mêmes informations erronées sur une transaction, le fait de disposer de « plusieurs signatures » ne signifie pas nécessairement qu’il y a « plusieurs avis indépendants ».
On peut en tirer trois tendances.
Premièrement, les audits de sécurité accorderont davantage d’importance aux autorisations financières de bout en bout, et pas seulement au mode de stockage des clés. Chaque transfert de confiance entre les terminaux, les identités des services, les conteneurs, les systèmes de gestion des risques et les dispositifs de signature devrait faire l’objet d’un audit.
Deuxièmement, les opérations inter-chaînes nécessitent une isolation plus claire en cas de défaillance. Le fait que les adresses soient réparties sur plusieurs chaînes ne signifie pas que les plans de contrôle sont indépendants ; un point d’accès commun aux autorisations peut regrouper des actifs dispersés en un seul point de risque.
Enfin, l’efficacité de la défense dépendra de plus en plus de la limitation des pertes maximales. Des plafonds de transfert sur de courtes périodes, des délais d’attente avant l’utilisation de nouvelles adresses, la simulation indépendante des transactions et le blocage des autorisations anormales ne garantissent pas une absence totale d’intrusion, mais peuvent empêcher qu’une compromission localisée ne se transforme en sortie massive de fonds.
Il s’agit de pistes d’analyse tirées de l’incident, et non de la confirmation que Binance ne disposait pas de ces mesures.
## VIII. IA et sécurité : ne pas inventer son implication dans l’attaque, mais ne pas sous-estimer les évolutions
À la date de rédaction, les sources vérifiables utilisées ne contiennent aucun élément prouvant que l’IA a été utilisée dans cette attaque.
Il ne faut pas transformer la compromission d’un ordinateur d’ingénieur en « hameçonnage par IA », ni présenter ce vol de grande ampleur comme un « piratage de clés privées par l’IA ».
La discussion sur l’IA et la sécurité reste toutefois nécessaire, à condition de la distinguer des faits établis dans cette affaire.
À propos d’une opération d’espionnage informatique distincte révélée en 2025, Anthropic a déclaré que les attaquants avaient utilisé ses outils pour mener des reconnaissances, étudier des vulnérabilités et effectuer d’autres opérations d’attaque. Le rapport reconnaissait également que le modèle pouvait inventer des identifiants ou mal interpréter les informations obtenues.[5]
Il s’agit d’informations communiquées par un fournisseur au sujet d’un autre incident, et non d’éléments de preuve concernant l’affaire Binance. Elles révèlent toutefois une tendance réelle : l’IA peut réduire le temps et les ressources humaines nécessaires à certaines opérations d’attaque, tout comme elle peut aider les défenseurs à traiter d’immenses volumes de journaux et à repérer des anomalies liées entre elles.
Dans les systèmes financiers, le rôle qui convient le mieux à l’IA est celui d’analyste et d’outil d’aide à l’examen : relier les connexions anormales, les accès aux services et les flux de fonds, expliquer des autorisations complexes et signaler les transactions nécessitant une vérification humaine.
En revanche, elle ne devrait pas être l’arbitre final disposant d’autorisations illimitées sur les fonds.
Un modèle peut se tromper ou être induit en erreur par des entrées malveillantes. Si l’on donne directement à l’IA les identifiants de retrait, la possibilité de modifier des listes d’autorisation ou d’approuver des transactions de grande ampleur, on risque d’ajouter un nouveau point d’accès à privilèges élevés en dehors des anciens systèmes.
Une architecture plus raisonnable serait la suivante : l’IA aide à détecter les problèmes, des règles indépendantes limitent les autorisations, les opérations à haut risque nécessitent une approbation explicite et toutes les actions exécutées sont auditables. Même si le modèle se trompe, le système doit maintenir des limites financières difficiles à contourner.
À l’ère de l’IA, l’amélioration de sécurité la plus importante ne consiste pas à connecter chaque étape à un modèle, mais à veiller à ce qu’une automatisation plus rapide n’augmente pas le rayon d’impact d’une perte de contrôle.
## IX. Ce qu’il faut vraiment attendre maintenant, ce n’est pas une simple affirmation du type « tout est sécurisé »
Après un incident, les chiffres des pertes attirent facilement l’attention, mais la qualité des réparations est beaucoup plus difficile à suivre dans la durée.
Il faudra notamment attendre de voir si le rapport complet sur les causes premières explique le parcours depuis le point d’entrée initial jusqu’au transfert des fonds ; quels contrôles ont échoué et lesquels ont permis de limiter les pertes ; si les fonds gelés ont effectivement été restitués ; et si la nouvelle séparation des autorisations et les limites de risque pourront être vérifiées après la reprise des services.
L’identité des attaquants doit également être établie dans le respect des limites imposées par les preuves. Sur la base de ses renseignements sur et hors chaîne, TRM attribue l’incident, avec un niveau de confiance élevé, au groupe nord-coréen TraderTraitor. Il s’agit de l’évaluation de cette société, qui ne remplace pas une confirmation définitive de Binance ou des autorités chargées de l’enquête.[3]
Pour les utilisateurs ordinaires, le risque immédiat comprend également les escroqueries secondaires après l’incident : des imposteurs se faisant passer pour le service client et demandant une phrase de récupération, réclamant des frais de déblocage ou incitant à signer une prétendue autorisation de « migration sécurisée ». Vérifiez les informations en accédant vous-même aux canaux officiels, sans suivre les instructions reçues par message privé d’inconnus.
Cet incident ne devrait pas laisser comme seule impression qu’« une autre plateforme a été attaquée ».
Il rappelle au marché qu’une signature valide sur la chaîne ne représente pas nécessairement une intention réelle hors chaîne, et que l’absence de preuve de fuite de clés privées ne signifie pas que la chaîne de contrôle des fonds n’a pas été compromise.
**À l’avenir, la sécurité des portefeuilles ne consistera pas seulement à mettre les clés à l’abri, mais aussi à veiller à ce que personne ne puisse contourner le véritable propriétaire et faire ouvrir la porte par tout le système.**
---
**Sources principales**
[1] [Rapport d’enquête préliminaire de Binance](https://x.com/binance/status/2115993361517891592), le 30 octobre à 10 h 25, heure de Pékin.
[2] [Mise à jour des services de Binance](https://x.com/binance/status/2116026356740034858), le 30 octobre à 12 h 36, heure de Pékin.
[3] [Enquête de TRM sur l’incident](https://www.trmlabs.com/resources/blog/north-korea-steals-usd-6-36-billion-from-binance-in-the-largest-hack-in-history), données arrêtées à 8 h 30, heure de Pékin.
[4] [Spécification officielle d’EIP-7702](https://eips.ethereum.org/EIPS/eip-7702).
[5] [Cas distinct d’espionnage informatique utilisant l’IA, révélé par Anthropic](https://www.anthropic.com/news/disrupting-AI-espionage).