Rédigé par : Juan Galt
Compilé par : AididiaoJP, Foresight News
Le débat entre logiciel libre et propriétaire perdure depuis plus de dix ans dans l'industrie du Bitcoin, voire de la cryptographie en général. Les partisans du Bitcoin affirment depuis longtemps que les infrastructures financières mondiales doivent être construites publiquement, et que la transparence et l'auditabilité sont des principes non négociables lorsqu'il s'agit d'argent réel. Cependant, les applications et la finance traditionnelle ne sont souvent pas convaincues.
Le récent piratage du portefeuille matériel Coldcard a propulsé le terme « open source » et son véritable sens sous les projecteurs. Les utilisateurs ont perdu plus de 100 millions de dollars en Bitcoin (plus de 1500 BTC). Cet incident a mis en lumière une réalité gênante : même parmi de nombreux passionnés de Bitcoin, la compréhension de la philosophie du développement logiciel open source et de ses scénarios de défaillance est en réalité assez limitée.
Principes et terminologie
La terminologie liée à l'open source n'est pas simple. Les termes logiciel libre et open source (FOSS) et logiciel libre / open source (FLOSS) désignent un logiciel conforme à une définition formelle des libertés de l'utilisateur.
La Free Software Foundation (FSF) définit le « logiciel libre » par quatre libertés fondamentales :
- Liberté 0 : Exécuter le programme comme on le souhaite, pour n'importe quel usage.
- Liberté 1 : Étudier le fonctionnement du programme et l'adapter à ses besoins (condition préalable : avoir accès au code source).
- Liberté 2 : Redistribuer des copies pour aider son prochain.
- Liberté 3 : Distribuer des versions modifiées du programme (condition préalable : avoir accès au code source).
La FSF insiste sur le fait que « free » signifie libre, et non gratuit. Le mantra souvent répété par les défenseurs de l'open source est : « 'free' as in 'free speech', not 'free beer' » (« libre » comme dans « liberté d'expression », pas « gratuit » comme dans « bière gratuite »).
La définition de l'open source de l'Open Source Initiative (OSI) énumère dix critères pratiques supplémentaires, notamment : redistribution libre sans redevance, mise à disposition du code source sous une forme adaptée à la modification, autorisation de créer et distribuer des œuvres dérivées, non-discrimination envers toute personne, groupe ou usage (y compris commercial). Seules les licences satisfaisant pleinement ces dix critères peuvent être officiellement qualifiées d'« open source ».
Le « source visible » ou « code source consultable » est une autre affaire. Le code peut être lu publiquement, mais la licence peut restreindre les droits de vente commerciale. Le firmware de Coldcard en est un exemple – il utilise la licence MIT avec une clause additionnelle de licence conditionnelle. Cette clause interdit explicitement la « vente » du logiciel, définie comme la fourniture du logiciel à un tiers contre rémunération ou autre contrepartie, et où la valeur du produit ou du service provient entièrement ou substantiellement du logiciel lui-même. En d'autres termes, le firmware de Coldcard ne peut être utilisé à des fins commerciales.
La clause de licence est claire : « Est-ce de l'open source ? Non. » Elle indique qu'avec cette clause additionnelle, bien que le logiciel satisfasse de nombreux éléments de la définition de l'open source, il ne les satisfait pas tous et ne devrait donc pas être appelé open source.
Ces distinctions sont importantes. Rendre le code source public ne crée que la possibilité d'être examiné ; accorder toutes les libertés de la définition du logiciel libre ou de l'open source, c'est cela le FOSS. Mais arborer le badge « open source » n'est pas un but en soi. Les critiques estiment que c'est la liberté commerciale au sein de l'open source qui peut débloquer les incitations pour que des tiers testent et inspectent le code, incitations qui pourraient autrement ne pas exister.
Les quatre libertés sont le cœur philosophique de l'open source. Mais en pratique, cela repose sur une hypothèse économique : qu'il y aura suffisamment de personnes motivées pour réellement examiner le code. Lorsque cette hypothèse échoue, le système joue la tragédie classique des biens communs – une ressource partagée est surexploitée ou négligée par l'intérêt personnel à court terme, menant finalement à sa dégradation. Chacun a intérêt à en prendre un peu plus (ou à contribuer un peu moins), le résultat étant que la ressource dans son ensemble en souffre. Parfois les incitations sont alignées, parfois elles ne le sont pas du tout.
Un développeur Bitcoin le dit plus directement : « Utiliser des substituts de test (mocks et stubs) avec du code open source dans les tests est irresponsable et à courte vue. Le code open source est considéré comme sûr parce que n'importe qui peut le vérifier. Si vous n'êtes même pas prêt à faire le minimum de test sur les fonctionnalités dont vous dépendez réellement, alors vous êtes un parasite. »
Ainsi, l'open source ne crée pas automatiquement la sécurité, il ne crée que la possibilité de vérification. Que cette vérification ait réellement lieu dépend des incitations, des compétences et de l'attention. Historiquement, les bons projets FOSS se renforcent progressivement à mesure que les vulnérabilités sont découvertes, divulguées et corrigées, devenant une base solide sur laquelle d'autres peuvent construire. Le noyau Linux en est l'exemple parfait – il alimente la grande majorité des serveurs mondiaux, de l'infrastructure cloud, des appareils Android et des systèmes embarqués, l'un des logiciels les plus largement déployés de l'histoire.
Bitcoin Core : Un exemple concret de l'open source en action
Bitcoin Core, l'implémentation de référence de Bitcoin, est un autre exemple classique de logiciel purement open source à grande échelle en action. Il utilise la licence MIT, et son processus de développement est public par conception.
N'importe qui peut soumettre une demande de tirage (pull request). La revue de code est le principal mécanisme de filtrage, et aussi la voie d'entrée recommandée pour les nouveaux venus. Les relecteurs utilisent une terminologie formelle : Concept ACK (accord sur l'objectif), Approach ACK (accord sur l'objectif et la méthode), ACK avec un hash de commit spécifique (testé et approuvé pour fusion), ou NACK (désaccord, doit être accompagné d'une raison technique).
Les mainteneurs pèsent le consensus des contributeurs contre les mérites techniques avant de fusionner. Les changements critiques au consensus ont un seuil plus élevé, nécessitant généralement une proposition d'amélioration Bitcoin (BIP) et des années de discussions approfondies sur la liste de diffusion bitcoin-dev et l'IRC.
Il n'y a pas ici de caste privilégiée de « développeurs Bitcoin Core ». La confiance se gagne en démontrant ses compétences sur le long terme. L'existence de mainteneurs est simplement due à des besoins pratiques – auditer le code fusionné, gérer les versions, un audit de base – mais le résultat est un code purement open source que n'importe qui peut inspecter, compiler, bifurquer (fork) ou exécuter. Les personnes dont le code est fusionné dans Bitcoin Core sont généralement appelées contributeurs à Bitcoin Core.
Le développeur open source Bitcoin de longue date Calle a récemment résumé : « Ceux qui pensent que Core est une sorte d'entité opaque opérant dans l'ombre sont soit trop paresseux, soit trop stupides pour aller regarder par eux-mêmes. Tout ce qu'ils font est public, n'importe qui peut participer, et le résultat final est du code purement open source. »
Le financement de ce travail provient principalement de structures à but non lucratif et de subventions, comme Brink, OpenSats, Spiral, etc., et non de feuilles de route produits d'entreprises traditionnelles. Les discussions techniques ont lieu sur la liste de diffusion publique bitcoin-dev et le canal IRC #bitcoin-core-dev sur Libera Chat ; les propositions sont examinées rigoureusement avant et après la soumission d'une pull request. Les issues et pull requests sur GitHub ont souvent des historiques de commentaires couvrant une décennie. Le résultat est une culture de développement qui privilégie la justesse et l'auditabilité, plutôt que la vitesse ou la cadence d'itération des fonctionnalités commerciales.
L'économie de l'open source
La plupart des utilisateurs de logiciels open source ou à code source visible ne lisent jamais le code eux-mêmes. Ils s'appuient sur l'hypothèse que « quelqu'un d'autre l'examine ». Dans le cas de Coldcard, un défaut critique lié à l'entropie est resté latent dans le firmware public pendant environ cinq ans avant d'être exploité et ainsi découvert.
Ce bug a été introduit lors d'une réécriture majeure en 2021. Cette réécriture a également supprimé le code GPL restant hérité de Trezor. Trezor fut le premier portefeuille matériel, et est actuellement le deuxième du secteur de l'autocustodie. La bibliothèque au cœur du problème s'appelle libngu ; elle a remplacé trezor-crypto, mais a reçu très peu d'examen externe – après plus de cinq ans d'utilisation en production, seulement 7 étoiles (stars) et moins de 20 forks. En comparaison, trezor-crypto a 512 étoiles et 212 forks, et le plus moderne trezor-firmware a 793 forks et 1800 étoiles. Le code source visible n'a pas, en lui-même, généré l'examen véritablement important. Les critiques estiment que la raison est le manque d'incitations commerciales, car d'autres entreprises rentables avec des moyens et des compétences sont limitées dans leur utilisation. Note : Les étoiles (Stars) et les forks (Forks) sont deux indicateurs clés sur GitHub mesurant la popularité et l'activité d'un projet. Star signifie ajouter aux favoris ; Fork signifie copier le dépôt.
Les enjeux dans l'écosystème Bitcoin sont bien plus élevés que dans la plupart des domaines logiciels. Un défaut critique peut se traduire directement en liquidités sur le marché public. La première moitié des fonds volés à Coldcard est toujours stockée sur quelques adresses ; le pirate pourrait un jour être attrapé, mais les imitateurs ultérieurs ont été plus prudents, certains ayant réussi à voler plus de bitcoins et à les blanchir (selon les données de Galaxy Research, les pertes totales atteignent au moins 1700 BTC). La nature anticensure et immuable des transactions Bitcoin fournit à la fois une forte incitation aux attaquants et un filtrage darwinien : seuls les projets qui attirent continuellement un examen de haute qualité, et dont les utilisateurs et entreprises prennent des mesures de protection sérieuses, ont une chance de survivre à long terme.
Le choix de la licence façonne ces incitations. Une licence purement open source maximise le bassin potentiel d'examinateurs et de forks. Une licence « source visible » restrictive peut réduire le « free riding » commercial, mais réduit aussi le nombre de personnes ayant à la fois le droit légal et la motivation économique pour y consacrer une attention approfondie. En conséquence, le fardeau de l'examen du code retombe sur l'entreprise elle-même, la rapprochant dans une certaine mesure d'un modèle propriétaire plutôt qu'open source.
Comment l'IA change le développement open source et propriétaire
L'intelligence artificielle est en train de changer l'équilibre entre open source et propriétaire.
Après l'incident Coldcard, un projet bénévole soutenu par OpenSats, Bitcoin Red Team, dirigé par des développeurs comme Calle et Rob Hamilton d'AnchorWatch, a utilisé des modèles d'IA de pointe pour scanner des centaines de dépôts de code Bitcoin open source. Sur une période intense, l'équipe a soumis des milliers de découvertes, dont des dizaines ont été classées critiques ou de haute gravité, couvrant des centaines de projets. Une divulgation responsable a d'abord été faite aux mainteneurs, puis publique. Cela a prouvé qu'un examen assisté par l'IA systématique pouvait découvrir des vulnérabilités à une échelle et une vitesse difficiles à atteindre auparavant pour des équipes humaines.
Il est à noter que Bitcoin Red Team a constaté que les modèles open source chinois étaient bien plus fiables que les modèles propriétaires américains. Même les modèles américains ayant un accès réseau et des droits d'accès élevés refusaient de répondre aux requêtes de Bitcoin Red Team, ce que les développeurs américains ont trouvé regrettable.
Parallèlement, le flux de code généré par l'IA exerce une nouvelle pression de type « déni de service » sur les mainteneurs de projets FOSS. Examiner la sortie de l'IA prend souvent plus de temps que de la générer. Certains projets open source en dehors de Bitcoin ont commencé à limiter leur suivi des problèmes (issue tracker), ou à établir des règles strictes contre les contributions d'IA, juste pour maintenir des opérations basiques.
Du côté propriétaire, l'avantage traditionnel de la « sécurité par l'obscurité » est en train de s'éroder. Les modèles d'IA modernes peuvent lire, désobfusquer, sonder des points de terminaison et raisonner sur le code à une vitesse extrêmement élevée. La différence pratique entre open source et propriétaire se réduit désormais principalement au code backend qui n'a jamais été mis en ligne. Le code propriétaire ne peut finalement compter que sur la qualité des audits professionnels, la vitesse de déploiement des correctifs, et une structure d'incitations qui maintient l'attention sérieuse des personnes ayant un accès privilégié.
Bitcoin et l'industrie cryptographique au sens large exercent une pression inhabituelle sur le logiciel libre et open source. La valeur monétaire réelle, l'économie adversarialiste, et maintenant l'analyse à l'échelle de l'IA, forcent les modèles logiciels à évoluer continuellement. Revenir à des systèmes analogiques pré-numériques n'est guère une option pour les infrastructures qui soutiennent les sociétés modernes. Seuls les projets suffisamment audités ont une chance de survivre sous la pression combinée des pirates assistés par l'IA et de la finance numérique.
