# Les machines lisent le code

> L'IA a fait s'effondrer le coût de la découverte de vulnérabilités. Dans l'écosystème open source de Bitcoin, cette collision est arrivée ce mois-ci — et Bruxelles a mis un chronomètre sur la suite.

Source: https://counterproof.io/fr/notes/les-machines-lisent-le-code/ · Published 14 August 2026 · CounterProof est une pratique de Clavestra Capital Limited (Malte, C 113987).


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.