Seize bénévoles. Vingt-sept heures et demie. Trois cent quatre-vingt-dix projets Bitcoin à code source ouvert. Quatre mille neuf cent soixante-deux constats de sécurité, dont quatre-vingt-cinq classés critiques et six cent trente-cinq de gravité élevée.
Voilà le bilan du premier sprint de la Bitcoin Red Team. Quelle que soit votre opinion sur la méthode, le fait brut mérite qu’on s’y attarde : un groupe bénévole a accompli en un peu plus d’une journée ce que les cabinets d’audit professionnels facturent sur plusieurs mois. La question évidente est de savoir pourquoi une telle initiative n’existait pas déjà.
Bitcoin est un pot de miel — et l’a toujours été
Bitcoin représente environ deux mille milliards de dollars en instruments au porteur, protégés par des logiciels, sans mécanisme d’annulation ni assureur de dernier recours. C’est la cible la plus pure de l’histoire informatique : entièrement numérique, irrévocablement définitive et continuellement en ligne. Tous les incitatifs qui ont déjà fait naître un chercheur en sécurité convergent vers lui, tout comme ceux qui ont déjà fait naître un voleur.
Le protocole a remarquablement bien résisté à cette pression. Le bilan des logiciels qui l’entourent — portefeuilles, serveurs de paiement, services d’échange, bibliothèques et l’immense surface logicielle avec laquelle les utilisateurs interagissent réellement — est plus partagé, et les deux sont constamment confondus dans le débat public. Bitcoin n’a jamais été cassé. Les systèmes qui communiquent avec Bitcoin, eux, le sont régulièrement.
Ce constat n’est pas nouveau, et la Red Team n’est pas le premier effort défensif sérieux dans cet espace. Bitcoin Core applique depuis bien plus d’une décennie un processus rigoureux de divulgation des vulnérabilités. Sa culture de révision — plusieurs réviseurs indépendants pour les changements critiques au consensus et une aversion pour la complexité inutile — explique pourquoi la liste d’incidents de la couche de base est si courte. Des organismes comme Brink, Chaincode Labs, HRF et OpenSats financent discrètement depuis des années les développeurs qui accomplissent ce travail de révision peu prestigieux. L’histoire est instructive : le bogue de dépassement de valeur de 2010, qui a créé 184 milliards de BTC, et le bogue d’inflation de 2018 dans Core, resté inconnu pendant deux ans, ont tous deux été découverts par des humains qui lisaient attentivement le code. Cette tradition constitue le socle de tout ce qui suit, et le financement de la Red Team provient précisément de cette lignée.
Ce qui manquait, ce n’était pas la diligence, mais la couverture. La révision minutieuse s’est toujours concentrée là où se trouvent la valeur et les réviseurs : Core, quelques grandes bibliothèques et les principaux portefeuilles. La longue traîne — les centaines de dépôts dont dépend réellement l’installation d’un véritable utilisateur — n’a jamais reçu une attention proportionnelle, faute de temps humain suffisamment qualifié. C’est précisément cette contrainte qui a changé cette année.
Ce que l’équipe a réellement fait
La Bitcoin Red Team a été mise sur pied à la fin juillet et au début août 2026 par Calle, le développeur du protocole d’argent électronique Cashu, et Rob Hamilton, PDG d’AnchorWatch, une entreprise d’assurance spécialisée dans l’auto-garde de Bitcoin. Elle répondait directement au désastre de génération des phrases de récupération Coldcard, qui avait déjà coûté bien plus de 100 millions de dollars aux utilisateurs. Le raisonnement était simple : si un défaut de configuration de compilation vieux de quatre ans pouvait rester indétecté dans l’un des portefeuilles matériels les plus examinés du secteur, que restait-il encore à découvrir ailleurs?
Le groupe a réuni seize chercheurs travaillant sans interruption, répartis sur plusieurs fuseaux horaires. Voici les chiffres clés publiés par Calle après 27,5 heures :
- 4 962 constats consignés dans 390 projets
- 85 problèmes critiques et 635 de gravité élevée
- Une moyenne de 2,31 constats de gravité élevée ou critique par personne et par heure
- Un taux de vérification déclaré de 21 %
- Plus de 40 000 $ en coûts d’inférence d’IA, financés par OpenSats, à raison d’environ 10 000 $ par jour
Le moteur sous-jacent était un banc d’essai conçu sur mesure d’environ 171 599 lignes de code, destiné non seulement à signaler du code suspect, mais aussi à accompagner chaque constat tout au long de son cycle : repérage, test, reproduction et documentation. C’est ce dernier élément qui distingue un rapport de sécurité utile du bruit. L’équipe a déclaré vouloir publier le banc d’essai en code source ouvert, y compris pour les entreprises qui doivent tester du code propriétaire. Les outils, et pas seulement les constats, pourraient ainsi devenir son apport durable.
Les constats ont été communiqués directement aux projets touchés plutôt que publiés. C’était la bonne décision, et il importe de le souligner puisque la couverture médiatique s’est surtout concentrée sur le nombre spectaculaire de résultats.
Ce que tout le monde oublie : les humains demeuraient indispensables
Hamilton a soulevé dans les reportages un point qui méritait davantage d’attention. Les meilleurs résultats provenaient de l’association d’ingénieurs experts du domaine avec les modèles, car l’IA pouvait, selon sa formule, « sentir que quelque chose cloche », tout en ne disposant pas du contexte spécialisé nécessaire pour déterminer si le problème avait une importance réelle.
Cela concorde avec notre propre expérience de conception et de livraison de micrologiciels et d’outils matériels. Un modèle qui lit du code inconnu excelle à remarquer qu’un motif est anormal. Il est beaucoup moins apte à déterminer si cette anomalie joue un rôle déterminant : cette valeur non vérifiée est-elle accessible depuis un chemin contrôlé par un attaquant dans ce déploiement précis, ou s’agit-il de code mort derrière un indicateur de compilation désactivé depuis 2019? Les experts du domaine apportent ce jugement. C’est leur association qui constitue le produit; aucune des deux composantes ne suffit seule.
La critique honnête
Il s’agit d’une évolution réellement positive, et nous souhaitons qu’elle se poursuive. Elle comporte aussi deux problèmes bien réels. L’initiative gagnera davantage à les nommer qu’à recevoir des applaudissements.
Le taux de vérification. Un taux de 21 % signifie qu’environ quatre constats consignés sur cinq n’avaient pas été confirmés au moment de la publication. Ce n’est pas un scandale : un triage préliminaire ressemble toujours à cela, et il faut reconnaître à l’équipe le mérite d’avoir communiqué ce chiffre plutôt que de le cacher. Toutefois, les manchettes annonçant « 4 962 constats » et « 85 problèmes critiques » circulent beaucoup plus loin et plus vite que la réserve concernant leur vérification. C’est dans l’écart entre ces chiffres que se dépense la crédibilité d’une bonne initiative.
Le fardeau imposé aux mainteneurs. Depuis des années, les mainteneurs de logiciels libres dénoncent le coût des rapports de vulnérabilité automatisés de piètre qualité. Un rapport vraisemblable, mais erroné, n’est pas gratuit : il consomme la ressource la plus rare du logiciel libre, soit l’attention de la ou des deux personnes qui comprennent véritablement le code. Consigner des milliers de constats dans des centaines de projets en une journée constitue un immense cadeau si le rapport signal-bruit est élevé, et une immense taxe dans le cas contraire. Les 79 % de constats qui n’avaient pas encore été vérifiés retombent sur des bénévoles.
Aucun de ces problèmes ne constitue un argument contre le projet. Ils plaident plutôt pour ce qui fait l’objet du troisième article de cette série : si l’on déploie des modèles à cette échelle contre du code réel, il faut utiliser ceux qui peuvent prouver qu’un constat est fondé, et non seulement le soupçonner. La différence entre « ceci semble incorrect » et « voici une preuve fonctionnelle de son exploitabilité » est celle qui sépare la soirée perdue d’un mainteneur d’une vulnérabilité corrigée. Elle est mesurable dans des bancs d’essai publiés, avec des résultats qui devraient modifier la configuration du prochain sprint.
Pourquoi Boltz est pertinent ici
Quatre jours avant la publication des chiffres du sprint de la Red Team, le service d’échange Boltz a fermé pour une durée indéterminée, invoquant des attaques automatisées assistées par l’IA qui dépassaient la capacité de correction de son équipe. Nous avons traité cet événement dans le premier article de cette série.
Placez les deux événements côte à côte et vous obtenez tout le portrait stratégique de la sécurité de Bitcoin en 2026. La capacité qui a permis à seize bénévoles d’auditer 390 dépôts en une journée est accessible, au même prix, à quiconque souhaite attaquer ces dépôts, sans éthique, sans processus de divulgation et sans besoin de dormir. Boltz a perdu cette course. La Red Team cherche à éviter que le reste de l’écosystème connaisse le même sort.
Voilà pourquoi la question « une telle initiative devrait-elle exister? » est réglée. L’offensive est déjà automatisée. Une défense tout aussi sophistiquée ne constitue pas une escalade : c’est la réponse minimale viable à un changement déjà survenu. La critique honnête de la Bitcoin Red Team n’est pas qu’elle est allée trop loin. C’est qu’elle aurait dû commencer il y a des années et qu’elle combat actuellement avec une main attachée derrière le dos, pour des raisons qui n’ont rien à voir avec Bitcoin.
Cette contrainte — les modèles que les défenseurs étaient autorisés à utiliser et ce que les données de performance publiées révèlent sur ce choix — fait l’objet du dernier article de cette série. C’est, selon nous, la partie de l’histoire qui a été rapportée avec le moins de justesse et celle dont D-Central possède une expérience directe.
