Dans la deuxième semaine d’août 2026, un développeur Bitcoin pseudonyme connu sous le nom de Calle a publié une phrase qui a ricoché à travers l’industrie : « Everything is broken, Bitcoin is burning » — tout est cassé, Bitcoin brûle. Derrière l’hyperbole, il y avait un jeu de données. La Bitcoin Red Team, équipe bénévole, venait de faire passer Kimi K3 de Moonshot AI — un modèle de frontière chinois à poids ouverts publié deux semaines plus tôt seulement — sur pratiquement tout l’écosystème open source de Bitcoin : portefeuilles, applications Lightning, bibliothèques de paiement et l’outillage qui les entoure. Après environ 108 heures — temps de campagne écoulé, travaillé par une équipe montée à vingt-cinq personnes — sur 501 projets, l’équipe avait consigné 7 958 constats de sécurité potentiels, dont 1 280 classés élevés ou critiques.
Cette seule campagne condense tout ce dont parle cet article : ce que les modèles d’IA peuvent désormais faire à une base de code, qui les pointe vers Bitcoin, ce qu’ils trouvent — et pourquoi un règlement européen qui commence à mordre le 11 septembre 2026 transforme tout cela d’une histoire d’ingénierie en une histoire juridique.
Les attaquants sont arrivés les premiers
Avant que les défenseurs n’industrialisent, les attaquants l’ont fait. La chaîne d’approvisionnement open source dont dépendent Bitcoin et, plus largement, l’industrie des actifs numériques subit depuis des années un assaut soutenu et financièrement motivé — et l’écosystème crypto en a constamment été la victime désignée.
En septembre 2025, des attaquants ont hameçonné le mainteneur de chalk, debug et de seize
autres utilitaires npm — des paquets totalisant des milliards de téléchargements hebdomadaires —
et ont livré un « crypto-clipper » qui accrochait les API du navigateur et substituait
silencieusement les adresses de destination au moment précis où l’utilisateur d’un portefeuille
approuvait une transaction — en choisissant même les adresses de l’attaquant par similarité
visuelle pour échapper à la détection. Quelques semaines plus tard, le ver Shai-Hulud a ajouté
l’auto-propagation, transformant des compromissions isolées de mainteneurs en réactions en
chaîne. En mars 2026, la bibliothèque Axios — de l’ordre de cent millions de téléchargements
hebdomadaires — a été piégée pendant un peu moins de trois heures via un compte de mainteneur
détourné, en parallèle de la campagne TeamPCP qui a compromis quatre projets open source très
utilisés en une seule semaine. Et en juillet 2026, des attaquants ont glissé une porte dérobée
déguisée en « télémétrie » dans le SDK de la blockchain Injective, câblant l’exfiltration de
phrases de récupération et de clés privées directement dans les fonctions de dérivation de clés
des portefeuilles ; la publication automatisée l’a propagée à dix-huit paquets en quelques
minutes.
La direction du mouvement est mesurable. Le rapport State of the Software Supply Chain 2026 de Sonatype a compté plus de 454 600 nouveaux paquets open source malveillants pour la seule année 2025 — un bond de 75 % sur un an, portant son total cumulé de blocages au-delà de 1,2 million. Et l’outillage côté offensif évolue aussi : le Threat Intelligence Group de Google a rapporté en 2026 avoir identifié, pour la première fois, un acteur menaçant maniant un exploit zero-day qu’il estime développé avec de l’IA, destiné à un événement d’exploitation de masse.
Les dépôts open source sont ciblés précisément parce qu’ils sont la couche de confiance. Personne n’a besoin de percer votre infrastructure s’il peut empoisonner une dépendance que vous installez volontairement. Et nulle part ce levier n’est plus grand que dans du logiciel qui touche aux clés et à l’argent.
La débâcle ColdCard
Fin juillet, le risque abstrait est devenu un risque qui change des vies. À partir du 30 juillet 2026, un attaquant a commencé à vider ce qui était censé être la cachette la plus sûre de Bitcoin : le stockage à froid. Par vagues successives — la plus grande balayant 1 082 BTC de 1 196 portefeuilles en 41 minutes seulement, selon le décompte de Galaxy Research —, la perte a atteint 1 367 BTC — environ 88,6 millions de dollars — sur 4 585 adresses générées sur des portefeuilles matériels ColdCard de Coinkite, à la date du point de contrôle de Galaxy du 1er août. Des décomptes ultérieurs ont dépassé 1 800 BTC et approché 130 millions de dollars une fois intégrée une quatrième vague soupçonnée. (Correction : une version antérieure de cette note donnait 116 millions de dollars — repris d’une couverture en circulation et introuvable ensuite dans une source qui l’énonce, la date et la définisse. Les totaux plus élevés intègrent une vague encore décrite comme non confirmée des semaines plus tard, et la réserve de Galaxy mérite d’être portée avec le chiffre : ils ont apparié les adresses par motif et n’ont pas mobilisé de calcul pour prouver que ces graines étaient faibles.) Selon le mécanisme publié, rien de tout cela n’a exigé d’hameçonnage, d’appareil volé ni d’accès physique d’aucune sorte — les clés ont été reconstruites hors ligne. Ces exclusions découlent du fonctionnement de la faille ; les avis du fabricant ne prétendent pas avoir enquêté et écarté chacune d’elles. Des milliers de détenteurs de long terme, qui avaient fait tout ce que prescrit l’orthodoxie de l’auto-conservation — portefeuille matériel, clés hors ligne, isolation réseau intacte —, ont vu les économies d’une vie quitter des adresses qu’eux seuls étaient censés contrôler. La cause racine était d’une banalité dévastatrice : un drapeau de compilation du firmware, livré en mars 2021, faisait sauter aux appareils touchés leur puce matérielle dédiée à l’aléa pour retomber sur un PRNG logiciel faible, effondrant l’entropie effective — jusqu’à environ 40 bits sur les anciens Mk3 —, assez loin pour que des phrases de récupération puissent être reconstruites hors ligne. Les mathématiques de Bitcoin ont tenu ; le logiciel qui les enveloppait, non. Coinkite a livré un firmware d’urgence, détruit l’inventaire vulnérable et supplié les utilisateurs de migrer — tout en concédant qu’aucun correctif ne peut réparer une graine déjà générée sur un firmware vulnérable.
Puis vint la guerre des récits. Le PDG de Coinkite, Rodolfo Novak, a présenté l’exploit comme « a sober reality of the new AI paradigm » — une réalité sobre du nouveau paradigme de l’IA : la revue de code assistée par IA ferait désormais remonter les bugs latents plus vite que même les experts humains les plus chevronnés, et tout firmware public, ou l’ayant jamais été, devrait être présumé sous examen machinal, par les attaquants comme par les défenseurs. Cette affirmation est contestée, et l’honnêteté exige de le dire. Aucun attaquant n’a été identifié. Aucune preuve n’a émergé qu’un modèle ait trouvé la faille — la formulation de Coinkite est qu’il faut « supposer » (« we have to assume ») que quelqu’un a appliqué de l’IA au firmware publié, et dans le même document l’entreprise révèle que sa propre revue par IA, menée quelques semaines plus tôt, « n’a pas trouvé ce bug ni rien de sérieux » (« did not find this bug or anything serious »). Une version antérieure de cette note écrivait aussi que des spécialistes de la sécurité avaient vivement objecté — qu’un drapeau de compilation désactivant un RNG matériel est une défaillance d’ingénierie humaine qu’une revue conventionnelle aurait dû attraper des années plus tôt. Nous n’avons pas pu l’étayer en revérifiant : le seul billet que nous avions tracé se trouve sur un compte suspendu, et le commentateur nommé le plus proche que nous ayons trouvé donnait plutôt raison à Coinkite. L’argument nous semble toujours juste — mais il est désormais le nôtre, et non un argument attribué. En un sens, pourtant, le différend est secondaire. Qu’une IA ait trouvé ce bug ou non, l’écosystème sait désormais que les modèles peuvent démontrablement trouver des bugs exactement de cette classe, exactement à cette vitesse — et il a réagi comme si la menace était réelle. En quelques jours, la plateforme d’échange Boltz a suspendu ses opérations pour devancer des tentatives de piratage pilotées par IA. Et une contre-force bénévole s’est assemblée.
La montée de la red team dans Bitcoin
La Bitcoin Red Team s’est constituée en quelques jours après le siphonnage ColdCard : une contre-force d’urgence, bénévole, de seize chercheurs menés par Calle aux côtés du PDG d’AnchorWatch, Rob Hamilton, adossée à environ 40 000 dollars de calcul IA et soutenue par OpenSats, dont le nouveau programme de subventions Code RED récompense désormais la divulgation responsable de vulnérabilités à travers l’écosystème. La méthode marie l’analyse pilotée par IA et la vérification humaine — les modèles balaient portefeuilles, implémentations Lightning et bibliothèques ; les chercheurs reproduisent et apprécient ; les constats crédibles partent en privé vers les mainteneurs avant toute publication.
La trajectoire de ses chiffres raconte ce que l’IA fait à l’économie de la découverte de vulnérabilités. Le premier sprint a déposé 4 962 constats sur 390 projets en 27,5 heures — 85 critiques et 635 élevés, soit en moyenne, selon l’arithmétique de Calle au lancement, de l’ordre d’un exploit critique par chercheur et par heure. Quelques jours plus tard, le balayage élargi en était à 7 958 constats sur 501 projets. Le résumé de Calle : le scan de base de pratiquement tout l’écosystème open source de Bitcoin est terminé, et les fruits à portée de main sont cueillis.
Les constats arrivent avec une texture qui compte davantage que les totaux. Les vulnérabilités se concentraient dans les bases de code anciennes et peu relues. Le logiciel lié à Lightning — structurellement complexe, sensible à la performance, difficile à auditer — portait une exposition disproportionnée. La prévalence d’implémentations en C a été signalée comme un risque structurel persistant. Et la vitesse à laquelle un projet répondait à une divulgation privée s’est révélée être un diagnostic en soi : la vitesse de réponse, a noté l’équipe, est un proxy visible de la santé d’un projet. Les projets non maintenus, ont-ils averti, ne devraient pas être crus sur parole.
La campagne a déjà produit un impact réel et vérifié. BTCPay Server — l’un des processeurs de paiement Bitcoin auto-hébergés les plus déployés — a livré la version 2.4.2 le 7 août, corrigeant un contournement critique de l’authentification à deux facteurs crédité en partie aux chercheurs de la Bitcoin Red Team — et a confirmé ensuite que la faille avait déjà été exploitée en conditions réelles pour extraire des identifiants de portefeuilles Lightning. C’est toute la thèse en un incident : la vulnérabilité était réelle, elle était utilisée, et la revue assistée par machine l’a atteinte avant que la plupart des humains ne l’auraient fait.
Il vaut la peine de dire directement ce que cela a coûté. Seize bénévoles, environ 40 000 dollars de calcul, quelques semaines — et une discipline que la plupart des programmes de sécurité financés n’atteignent jamais : la divulgation privée d’abord, la publication seulement une fois les constats entre les mains des mainteneurs, et leur propre taux de reproduction énoncé en public plutôt qu’enterré. Ils ont cartographié un écosystème resté non cartographié pendant une décennie, et ils ont donné les résultats. Quoi qu’il suive dans cet article, voilà le standard de référence pour la conduite de ce travail, et l’écosystème Bitcoin est plus sûr ce mois-ci que le mois dernier — grâce à eux.
Une contrainte de ce travail mérite d’être énoncée clairement, car elle est régulièrement mal lue comme un choix méthodologique. L’équipe a rapporté que les restrictions d’usage des modèles américains pour la recherche en sécurité l’ont bloquée à répétition — la poussant vers des modèles à poids ouverts comme Kimi K3 et GLM 5.2 de Z.ai, exécutables localement sans portier de politique d’usage. Kimi K3 n’était pas un pis-aller ; pour ce travail, à ce moment-là, il comptait parmi les meilleurs instruments qu’elle avait réellement le droit d’utiliser.
C’est un échec de politique, pas un échec de recherche. Le choix d’outils en recherche de sécurité est désormais façonné moins par la qualité des modèles que par qui autorise le travail tout court — et une équipe qui prend le modèle qui exécutera réellement la tâche se comporte correctement. Cela devrait faire réfléchir les laboratoires occidentaux : la recherche défensive a lieu de toute façon. La seule question est de savoir sur les modèles de qui — et si ceux qui la mènent sont contraints à une boîte à outils plus étroite que celle des attaquants.
Ce que 7 958 constats signifient réellement
Ici, l’honnêteté est due — et l’équipe a été la première à la devoir. Sur les 7 958 constats, 24,7 % disposaient d’une preuve de concept reproductible — l’expression est de l’équipe — et 29,4 % avaient été signalés en amont au dernier décompte, des chiffres que l’équipe a publiés elle-même plutôt que de les arrondir. (Une version antérieure de cette note écrivait « reproduits dynamiquement » ; c’était notre glose, pas la leur, et le taux de signalement désigne des constats envoyés aux mainteneurs, non des constats acceptés par eux.) Une évaluation conjointe de l’AI Security Institute britannique et du CAISI américain a jugé Kimi K3 capable mais loin d’être infaillible — 32 % aux bancs d’essai de développement d’exploits, devant GLM-5.2 mais bien derrière les modèles fermés les plus forts, et une exécution de code arbitraire obtenue sur aucun des 41 échantillons testés.
Ce n’est donc pas une liste de 7 958 trous exploitables dans Bitcoin, et personne d’impliqué ne l’a prétendu. Le cadrage de Calle était sans détour : les candidats sont bon marché, et si vous ne pouvez pas gérer la surcharge d’information qui en résulte, utilisez l’IA pour la trier. C’est la bonne lecture, et elle pointe le vrai basculement. L’IA a rendu la génération de candidats presque gratuite. Ce qu’elle n’a pas rendu gratuit, c’est le jugement qui sépare une vulnérabilité confirmée, reproductible et correctement cotée d’une hallucination à l’air plausible — le même problème d’« AI slop » dans lequel les mainteneurs open source, depuis curl, sont en train de se noyer.
La ressource rare en sécurité a discrètement migré de la détection vers l’appréciation. C’est une propriété de la technologie, pas un défaut d’une campagne quelconque — et un balayage qui cartographie un écosystème entier et une évaluation signée d’une seule base de code sont simplement des métiers différents. Le premier vous dit où regarder. La seconde est ce qu’un régulateur, un acquéreur ou un assureur acceptera réellement. Tout acteur sérieux de ce domaine — attaquant, défenseur, mainteneur, régulateur — se trouve désormais en aval de ce goulot.
Bruxelles met le chronomètre
Dans cette collision s’avance le Cyber Resilience Act de l’UE, et son calendrier pouvait difficilement être plus tranchant.
À partir du 11 septembre 2026, l’article 14 du CRA oblige les fabricants de produits comportant des éléments numériques vendus dans l’UE à notifier toute vulnérabilité activement exploitée dont ils prennent connaissance — sous 24 heures pour l’alerte précoce, 72 heures pour la notification complète et 14 jours pour le rapport final — simultanément à l’ENISA et à leur CSIRT national désigné, via la plateforme unique de notification. Point décisif : cela s’applique aux produits déjà sur le marché, pas seulement aux nouvelles versions. Le règlement s’applique ensuite intégralement à partir du 11 décembre 2027, apportant des exigences contraignantes de sécurité dès la conception, l’obligation de l’annexe I de soumettre régulièrement les produits à des tests et examens de sécurité efficaces, une documentation technique contenant les rapports de ces essais, et des obligations de conservation s’étirant sur une décennie. Les amendes de l’article 64 atteignent 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu.
Assemblez maintenant les deux moitiés de cet article. Des campagnes assistées par IA font remonter des milliers de vulnérabilités candidates à travers les écosystèmes open source en quelques semaines — et certaines, comme la faille BTCPay, sont activement exploitées, ce qui est précisément le déclencheur de notification du CRA. Un fabricant dont le produit embarque une dépendance compromise — ou une faille qu’un balayage IA fait émerger et qu’un attaquant atteint le premier — ne fait plus face à une discrète correction d’ingénierie. Il fait face à un chronomètre juridique de 24 heures. Et un fabricant sans aucun processus de découverte pourrait violer l’article 14 non pas en omettant de notifier, mais en n’ayant jamais su qu’il y avait quelque chose à notifier.
Le corollaire inconfortable : une grande part du code qui embarque aujourd’hui dans ces produits est écrite par des machines, et une grande part de la revue qui lui est appliquée est effectuée par les mêmes modèles qui l’ont écrit. Un code écrit par un modèle et revu par le même modèle n’a été revu par personne. Régulateurs, acquéreurs, assureurs et équipes de sécurité d’entreprise convergent vers la même question — et « notre modèle a vérifié sa propre sortie » n’est une réponse qu’aucun d’eux n’accepte.
La réfutation comme discipline : la méthode CounterProof
Un balayage et une évaluation répondent à des questions différentes, et la seconde est là où se tient notre propre pratique. CounterProof n’a pas été conçu en atelier comme un produit ; il s’est accrété pendant que nous sécurisions notre propre infrastructure de paiement à cryptographie à seuil — où un défaut qui passe ne coûte pas une relation client : il coûte à l’opérateur ses propres fonds.
La contrainte qui l’a façonné était l’inverse de celle de la Red Team. Il leur fallait de l’étendue : 501 projets, vite, sur le modèle qui voudrait bien exécuter le travail. Il nous fallait qu’un seul constat survive au fait d’avoir tort en public, sur du code détenant notre propre argent. L’étendue pardonne un faux positif ; une évaluation signée, non. Autre problème, autre méthode — et nous avions le luxe de choisir nos instruments, ce que les restrictions de politique décrites plus haut leur refusait précisément.
CounterProof prend le goulot de l’appréciation de front, avec un protocole façonné par les modes de défaillance décrits ci-dessus. Chaque évaluation est une revue adversariale multi-lignées : des familles de modèles indépendantes — pas un second passage du même — attaquent chaque constat et tentent de le réfuter, les désaccords étant tranchés par la lecture de la source, pas par un vote.
Ce dernier point n’est pas une prétention à de meilleurs modèles. C’est une affirmation sur une propriété mesurée de tous : le verdict d’un relecteur est un échantillon, pas une mesure. Donnez au même modèle les mêmes octets deux fois, il ne rendra pas toujours la même réponse ; posez une question à plusieurs familles, elles échouent dans des directions différentes — la seule raison pour laquelle en faire tourner plusieurs vaut son coût. Nous avons vu un modèle « corriger » avec assurance une référence réglementaire et se tromper, pendant qu’un modèle sans accès à la source refusait, correctement, de répondre. La leçon n’est pas qu’une lignée est supérieure. C’est qu’une lignée seule — n’importe laquelle — ne peut pas se vérifier elle-même. Rien ne part sans avoir été soumis à réfutation. Chaque constat qui survit est ensuite soit confirmé contre la source réelle — fichier et ligne exacts, chemin de reproduction, classification d’impact, avec des citations résolues mécaniquement contre la révision précise examinée — soit explicitement étiqueté plausible seulement. Chaque constat nomme l’échelon de preuve qu’il a réellement atteint — trace dans la source, preuve de compilation, test, ou reproduction en exécution — et n’en laisse jamais entendre un plus élevé. Et chaque rapport porte un engagement permanent de rétractation : si un constat est démontré faux, il est rétracté par écrit.
Autrement dit : là où la revue de l’ère IA génère du bruit à l’échelle industrielle, la production de CounterProof est délibérément l’inverse d’une file de triage. C’est une évaluation signée, graduée par niveau de preuve, sous un identifiant d’engagement persistant — structurée pour être remise à une équipe de due diligence, à un assureur, ou intégrée à la documentation technique CRA comme rapport d’essais au format de l’annexe VII, point 6), attestant l’obligation d’essais. L’indépendance est structurelle : nous n’émettons aucune évaluation sur du code écrit par CounterProof ou par une société de notre groupe — et notre propre base de code, en grande partie écrite par des machines, passe en continu par le même registre adversarial. Nous avons été notre premier client, et nous restons notre plus exigeant.
Nous lancerons prochainement un nouveau service sur CounterProof.io, étendant cette pratique aux équipes confrontées exactement à la convergence que décrit cet article : du code écrit par des machines, des adversaires à la vitesse des machines, et le chronomètre d’un régulateur. Plus à ce sujet bientôt.
Où cela mène
Trois prédictions, tenues sans crispation.
Premièrement : l’écart de triage s’élargit avant de se refermer. Les modèles à poids ouverts vont continuer de progresser, des balayages comme celui de la Bitcoin Red Team seront répétés dans d’autres écosystèmes, et le ratio de constats candidats sur constats vérifiés empirera avant que l’outillage d’appréciation et des méthodes disciplinées ne rattrapent. Les projets seront de plus en plus jugés — par les utilisateurs, les assureurs et les acquéreurs — sur leur vitesse de réponse aux divulgations, exactement comme Calle l’a observé.
Deuxièmement : le CRA devient la fonction de forçage que les bug bounties n’ont jamais été. Les normes de divulgation volontaire ont produit une couverture lacunaire pendant une décennie ; une obligation de notification en 24 heures assortie d’amendes indexées sur le chiffre d’affaires fera en dix-huit mois ce que la bonne volonté n’a pas fait — et la demande d’essais de sécurité réguliers, indépendants et de qualité documentaire restructurera le marché de l’audit autour de la preuve plutôt que des badges.
Troisièmement, et le plus fondamental pour Bitcoin : un écosystème dont le modèle de sécurité repose sur la revue ouverte est sur le point de découvrir si la revue machinale compte. La réponse honnête : elle ne compte que lorsqu’une partie indépendante est prête à vérifier le constat, à graduer la preuve et à signer. La détection a été automatisée. La responsabilité, non — et elle ne peut pas l’être. C’est là que vivent désormais la valeur, et la responsabilité.
CounterProof est une pratique indépendante de revue adversariale de Clavestra Capital Limited (Malte). Proof atteste ; CounterProof réfute. counterproof.io — Cette page est une traduction de l’original anglais ; en cas de divergence, l’original prévaut.
Sources : avis de sécurité Coinkite et couverture de Forbes, Bloomberg, CBC et Galaxy Research sur l’exploit ColdCard (juil.–août 2026) ; divulgations de la Bitcoin Red Team via Bitcoin Magazine, Decrypt, crypto.news, Coinpaper et Metaverse Post (août 2026) ; notes de version de BTCPay Server 2.4.2 ; évaluation conjointe de modèles UK AISI / US CAISI ; Sonatype State of the Software Supply Chain 2026 ; Google Threat Intelligence Group, rapport sur l’activité de menace assistée par IA (2026) ; analyse StepSecurity de la compromission du SDK Injective (juil. 2026) ; couverture des incidents de chaîne d’approvisionnement npm (sept. 2025 – mars 2026) ; règlement (UE) 2024/2847 (Cyber Resilience Act), art. 13–14, 16, 69, annexes I et VII.