La publication du code source a toujours été une garantie de sécurité car chacun peut l’examiner, identifier ses failles et contribuer à les corriger. Mais l’intelligence artificielle semble provoquer un déséquilibre entre ceux qui cherchent les vulnérabilités pour les corriger et ceux qui les cherchent pour les exploiter. C’est en tout cas ce que révèle l’affaire Coldcard.
L’intelligence artificielle rompt l’équilibre.
L’affaire Coldcard en offre une illustration aussi effrayante que spectaculaire.
Coldcard est un fabricant de portefeuilles bitcoin froid, totalement hors-ligne. Une erreur présente depuis plusieurs années dans le code a affaibli le niveau d’entropie de certaines clés privées. Des attaquants ont alors pu retrouver les clés de portefeuilles et déplacer les bitcoins qui y étaient stockés, depuis parfois plusieurs années.
Plus de 100 millions de dollars de bitcoins ont été volés au moment où j’écris ces lignes (1596 BTC sur 7300 adresses).
Précisons que ce n’est pas Bitcoin qui a été hacké. La vulnérabilité se trouvait dans le code chargé de produire la clé privée.
Et ce code était accessible publiquement, ce qui a permis à un modèle d’IA d’identifier la faille.
Une faille visible depuis plusieurs années
La vulnérabilité concernait le logiciel de certains portefeuilles Coldcard. Le bug réduisait le niveau d’aléa utilisé lors de la génération de certaines phrases de récupération.
En clair : une clé privée Bitcoin correctement créée est choisie dans un espace de possibilités tellement vaste qu’aucun ordinateur ne peut raisonnablement la deviner. Cette sécurité dépend notamment de l’entropie, c’est-à-dire de la quantité d’imprévisibilité utilisée au moment de produire la clé.
Lorsque l’entropie est suffisante, rechercher une clé privée par force brute est irréaliste. Mais si la source d’aléa est défectueuse, le nombre de possibilités diminue. La clé est en apparence parfaitement valide, mais elle a été sélectionnée dans un espace beaucoup plus restreint.
Il devient alors possible de la deviner.
Pour certains modèles concernés, les phrases de récupération auraient disposé d’environ 72 bits d’entropie au lieu des 128 bits attendus. Cela reste un nombre considérable de combinaisons mais plus nécessairement hors de portée.
Et bien sûr, une simple mise à jour ne suffit pas à protéger une clé déjà produite. Corriger le générateur empêche la production de nouvelles clés faibles, mais toutes les clés déjà produites restent vulnérables. Pour se protéger, les utilisateurs doivent alors déplacer leurs fonds vers une nouvelle adresse dont la clé a été générée avec un niveau d’entropie suffisant.
Ce qui est terrible dans cette affaire, c’est que les utilisateurs avaient tout fait correctement : un appareil hors ligne et un logiciel largement auditable.
Ils avaient suivi le modèle de sécurité considéré comme le plus exigeant. Et ce modèle n’a pas suffi.
Cette faille, elle est restée plusieurs années dans un dépôt accessible, au sein d’un produit conçu pour protéger des bitcoins de la manière la plus sécurisée qui soit.
Tout le monde pouvait voir cette faille. Personne ne l’a vue. Jusqu’à l’arrivée de l’IA.
L’open source dangereux ?
On pourrait conclure que publier son code est devenu dangereux.
Mais l’open source ne garantit pas qu’un logiciel est sûr. Il garantit seulement que son fonctionnement peut être examiné. La différence est essentielle.
Un logiciel peut être disponible sur GitHub sans que personne ne l’ait véritablement étudié.
Coinkite explique que le bug se trouvait à l’intersection de composants distincts, en dehors des parties cryptographiques généralement ciblées par les audits. Pris isolément, chaque morceau de code semblait correct. C’est leur interaction qui créait la vulnérabilité.
Jusqu’à présent, examiner un dépôt complexe demandait des compétences, du temps et des moyens.
Mais l’IA réduit désormais chacun de ces coûts.
Deux dollars pour trouver la faille
Le plus surprenant n’est peut-être même pas la faille elle-même, mais la facilité avec laquelle des modèles d’IA auraient pu la retrouver.
D’après Haseeb Qureshi, un audit réalisé avec Claude aurait identifié le problème en huit minutes. Une seconde expérimentation, menée avec un autre modèle, l’aurait reproduit en une vingtaine de minutes pour un coût estimé à environ deux dollars.
Une faille restée invisible pendant plusieurs années peut désormais devenir détectable par une IA en quelques minutes. Le véritable changement est là.
L’IA transforme la sécurité en course économique
La cybersécurité a toujours été une confrontation entre attaquants et défenseurs. Mais l’IA change le rapport de force.
Pour une entreprise, sécuriser un produit exige un effort continu : audits, corrections, mises à jour… Pour un attaquant, une seule faille rentable peut suffire.
Le code ouvert devient alors immédiatement exploitable par les modèles. L’IA peut lire les différentes versions, croiser le code avec la documentation, les tickets Github, les discussions des développeurs, l’historique des modifications…
Ce qui demandait auparavant plusieurs semaines de recherche peut être comprimé en quelques heures.
Problème : les attaquants peuvent automatiser la recherche de failles plus rapidement que les organisations n’automatisent leur correction.
Dans le cas d’un service classique, une vulnérabilité peut être corrigée sur un serveur central.
Mais dans le cas de Coldcard, l’erreur commise au moment de générer la clé survit à toutes les mises à jour ultérieures.
Les anciens codes exposés
L’une des conséquences les plus importantes de cette évolution concerne les logiciels déjà publiés.
Un programme audité en 2021 ne l’a pas été avec les capacités disponibles en 2026.
Une faille trop complexe, trop subtile ou trop coûteuse à rechercher il y a cinq ans peut aujourd’hui devenir accessible à un modèle disponible publiquement.
Cela signifie qu’un audit ne peut plus être considéré comme un certificat durable. Chaque progrès de l’intelligence artificielle augmente la surface d’attaque des anciens logiciels.
Le Web3 est particulièrement exposé car la transparence fait partie de la culture du secteur.
Elle permet de vérifier le fonctionnement des applications et de ne pas dépendre uniquement des promesses d’une entreprise.
Mais ces logiciels contrôlent parfois directement des centaines de millions de dollars. Ils constituent donc des cibles exceptionnellement rentables.
Ledger avait-il raison de fermer son code ?
Le cas Coldcard relance inévitablement le débat autour des portefeuilles propriétaires.
Ledger a souvent été critiqué parce qu’une partie de son code n’est pas publique.
Dans l’univers Bitcoin, cette fermeture oblige l’utilisateur à accorder une part de confiance au fabricant.
Or la philosophie des cryptomonnaies repose précisément sur la réduction des intermédiaires de confiance et sur la possibilité de vérifier plutôt que de croire. Don’t Trust, Verify.
Mais à l’ère de l’IA, la question devient plus complexe.
Faut-il revenir vers les plateformes centralisées ?
Certains en viennent à tirer une conclusion paradoxale : les bitcoins seraient désormais plus en sécurité sur une grande plateforme centralisée que dans un portefeuille personnel.
Un exchange important dispose d’équipes spécialisées, de systèmes de surveillance, de procédures internes, de portefeuilles multisignatures et de garanties. Pour un utilisateur peu expérimenté, déléguer la garde peut sembler moins risqué que générer, sauvegarder et protéger lui-même ses clés.
Mais cette conclusion entre directement en contradiction avec la raison d’être de Bitcoin.
« Not your keys, not your coins » ne cesse pas d’être vrai parce qu’un portefeuille matériel a connu une faille. Mais ce n’est pas un argument, c’est une conclusion.
L’argument, le voici : l’auto-conservation ne supprime pas le risque de confiance, elle le transforme en risque de compétence. Vous ne dépendez plus de la solvabilité d’une entreprise, vous dépendez de la qualité de votre propre dispositif.
Ce que cela impose
Face à la multiplication des agents IA capables d’analyser des dépôts publics, certaines entreprises pourraient décider de rendre leurs logiciels propriétaires. En retirant le code de Github, elles pensent réduire les informations accessibles aux attaquants.
Mais le code propriétaire contient lui aussi des vulnérabilités. Les attaquants disposent aussi de nombreux moyens d’étudier un logiciel depuis l’extérieur.
Fermer le code supprime surtout une partie des capacités de contrôle offertes aux chercheurs indépendants.
L’affaire Coldcard ne démontre pas que le logiciel propriétaire est plus sûr, mais plutôt qu’un projet open source ne peut plus se reposer uniquement sur la revue communautaire.
À l’ère de l’IA, publier son code impose une responsabilité supplémentaire : le tester au moins aussi intensément que le feront ceux qui chercheront à l’attaquer.
L’ouverture du code reste un atout majeur pour la transparence, l’interopérabilité et la confiance. Mais sa gouvernance doit évoluer.
Lorsqu’un attaquant peut mobiliser une IA performante pour quelques dollars, ne pas utiliser les mêmes outils en défense devient difficilement justifiable.
Rien de tout cela n’est spécifique au Web3. Le raisonnement s’applique à l’identique à une extension WordPress non maintenue depuis 2018, ou n’importe quel projet. La sécurité doit partir du principe que si une faille existe dans un code accessible, une IA finira probablement par la trouver.
