hyper.dev

2026-04-19 · L’enclosure du code - 2 - L’ère de l’assemblage

Comment l’extraction de valeur à partir des communs logiciels est devenue invisible — et ce que cela a fait aux personnes qui écrivent du code

Deuxième session — La chaîne d’approvisionnement logicielle, des années 2010 à l’ère pré-générative

← L’enclosure du code — Série complète

1. Synthèse

[INTERPRÉTATION] Entre 2010 et 2022, le logiciel a cessé d’être quelque chose qu’on construit pour devenir quelque chose qu’on assemble. Les gestionnaires de paquets (npm, pip, Maven) ont transformé la production logicielle en un réseau de dépendances transitives si vaste que personne ne pouvait le gouverner. 🟢 90-100% Les plateformes cloud (AWS, GCP, Azure) sont devenues les nouveaux gardiens : elles n’hébergeaient pas simplement le logiciel — elles étaient la chaîne d’approvisionnement. 🟢 90-100% Deux incidents — left-pad (2016) et Log4Shell (2021) — ont rendu brièvement visible le travail invisible des mainteneurs non payés qui soutenaient cette infrastructure. 🟢 90-100%

Cette ère a normalisé l’extraction au point de l’invisibilité. Le modèle open core financé par le capital-risque a fait de la capture de valeur à partir des communs une stratégie d’affaires explicite et célébrée. 🟡 70-89% Simultanément — et c’est la tension qu’il faut tenir — cette même ère a représenté la plus grande démocratisation de la capacité à construire du logiciel de l’histoire humaine. Un développeur seul à Lagos, Dakar ou Tizi Ouzou pouvait expédier un produit qui aurait requis une équipe de dix personnes en 2005. Les deux choses sont vraies. La question est de savoir laquelle a laissé le plus de traces.

2. Résultats détaillés

2.1 L’explosion des dépendances : quand le logiciel est devenu un graphe

Le passage de « écrire » à « trouver »

[FAIT] npm, le gestionnaire de paquets pour JavaScript, a été lancé en 2010. En 2016, il hébergeait plus de 250 000 paquets. En 2025, le registre npm dépasse les 2 millions de paquets. PyPI (Python), Maven Central (Java), RubyGems et NuGet ont suivi des trajectoires similaires. 🟢 90-100%

[INTERPRÉTATION] Ce que ces chiffres décrivent n’est pas simplement une expansion. C’est un changement de nature dans ce que signifie « développer du logiciel ». Quand un développeur installe un framework front-end comme React ou Angular, il ne charge pas un outil — il charge un arbre de dépendances qui peut inclure des centaines, voire des milliers de paquets écrits par des personnes qu’il ne connaît pas, qu’il ne lira jamais, et dont il dépend entièrement. Le blogueur David Haney a découvert après l’incident left-pad qu’une installation fraîche de Babel incluait 41 000 fichiers. Un paquet appelé isArray — une seule ligne de code — était téléchargé 880 000 fois par jour.

L’analogie est celle de la grande distribution : comme un hypermarché qui assemble des produits de milliers de fournisseurs sur un linéaire que le consommateur parcourt sans voir la chaîne d’approvisionnement, le développeur moderne assemble du code qu’il n’a pas inspecté, dans un graphe de dépendances qu’il ne peut pas gouverner.

left-pad : onze lignes qui ont cassé Internet (2016)

[FAIT] Le 22 mars 2016, Azer Koçulu, un développeur basé à Oakland, a retiré de npm les 273 paquets qu’il avait publiés, dont left-pad — une fonction de 11 lignes qui ajoute des caractères au début d’une chaîne de texte. Des milliers de projets, dont Babel, Webpack et React, dépendaient de left-pad directement ou transitivement. Facebook, PayPal, Netflix, Spotify ont été affectés. Le paquet avait été téléchargé 2,5 millions de fois dans le mois précédant sa suppression. npm a restauré le paquet deux heures plus tard — un acte sans précédent. 🟢 90-100%

[FAIT] Koçulu avait agi en protestation contre npm Inc., qui avait transféré le nom de paquet « kik » à l’entreprise Kik Interactive après que celle-ci eut invoqué sa marque commerciale. Koçulu a écrit : « Cette situation m’a fait réaliser que npm est le terrain privé de quelqu’un, où les entreprises sont plus puissantes que les personnes. » 🟢 90-100%

[INTERPRÉTATION] L’incident est révélateur à trois niveaux. D’abord, il a montré que des entreprises valant des milliards de dollars dépendaient de onze lignes de code écrites par un développeur individuel, sans contrat, sans rémunération, sans même en être conscientes. Ensuite, la réponse de npm — restaurer un paquet contre la volonté de son auteur — a démontré que dans un système de dépendances massives, la propriété individuelle du développeur cède devant les « besoins du plus grand nombre ». Enfin, comme l’a observé Armin Ronacher, l’approche « micro-dépendance » de npm crée une surface d’attaque qu’aucune personne raisonnable ne peut inspecter. Un développeur individuel maintenait 827 modules séparés sur npm. 🟡 70-89%

Log4Shell : quand le commun s’effondre à l’échelle planétaire (2021)

[FAIT] En décembre 2021, la vulnérabilité Log4Shell (CVE-2021-44228) a été divulguée dans Apache Log4j, une bibliothèque Java de journalisation utilisée par la majorité des serveurs d’entreprise dans le monde. La vulnérabilité existait inaperçue depuis 2013. Apache lui a attribué un score CVSS de 10 — le maximum. La CISA a décrit Log4Shell comme potentiellement la vulnérabilité la plus grave jamais vue. Des centaines de millions d’appareils étaient affectés, y compris des systèmes d’Apple, Amazon, Cloudflare, Tesla, Twitter et Baidu. 🟢 90-100%

[FAIT] Log4j était maintenu par une poignée de bénévoles non payés. La FTC américaine a reconnu que ces projets sont « souvent créés et maintenus par des volontaires qui n’ont pas toujours les ressources adéquates pour la réponse aux incidents et la maintenance proactive, même quand leurs projets sont critiques ». L’Agence de cybersécurité de Singapour a comparé Log4j à « un type de vis largement utilisé dans les produits semi-finis et finis — moteurs, chaises, tables, automobiles — toute vulnérabilité dans un tel composant fondamental de la chaîne d’approvisionnement logicielle peut avoir des conséquences profondes ». 🟢 90-100%

[INTERPRÉTATION] Log4Shell n’est pas un incident isolé. C’est le fonctionnement normal d’un système où l’infrastructure critique est maintenue par des bénévoles. Le schéma est identique à Heartbleed (2014, OpenSSL) et à l’incident colors.js/faker.js (2022, où le mainteneur Marak Squires a délibérément saboté ses propres paquets en protestation contre le travail gratuit). Ces incidents ne sont pas des bugs — ce sont des révélations : des moments où la réalité du travail invisible devient brièvement visible avant que le système ne la recouvre. 🟡 70-89%

2.2 Les plateformes cloud comme nouveaux gardiens

« Vous le construisez, nous vous le relouons »

[FAIT] Amazon Web Services a lancé son service Amazon Elasticsearch en 2015, utilisant le projet open source Elasticsearch sous licence Apache 2.0. Elastic, l’entreprise qui avait créé et maintenait le projet, a protesté que ce service avait été lancé « sans collaborer avec nous » et qu’il créait de la confusion sur la responsabilité des bugs. En 2021, Elastic a changé sa licence vers la SSPL (Server Side Public License), conçue pour empêcher les fournisseurs cloud d’offrir le logiciel comme service sans contribuer en retour. AWS a répondu en forkant le projet sous le nom OpenSearch, maintenant la licence Apache 2.0. 🟢 90-100%

[FAIT] Le même schéma s’est répété : MongoDB a adopté la SSPL en 2018 pour se protéger d’AWS. Redis a changé de licence BSD vers SSPL/RSALv2 en mars 2024 ; la Linux Foundation a immédiatement annoncé Valkey, un fork soutenu par AWS, Google et d’autres. CockroachDB et Confluent (Apache Kafka) ont effectué des changements de licence similaires entre 2019 et 2020. 🟢 90-100%

[INTERPRÉTATION] Ces conflits ne sont pas des disputes commerciales ordinaires. Ce sont des moments où la communauté a débattu de la question : qui possède ce que les communs produisent ? D’un côté, Elastic et MongoDB argumentaient que les fournisseurs cloud capturaient la valeur créée par leurs développeurs sans rien retourner. De l’autre, AWS argumentait qu’elle défendait l’open source en maintenant des forks sous licence permissive. Les deux positions sont sincères. Mais la dynamique structurelle est claire : quand le fournisseur cloud peut forker n’importe quel projet open source et l’offrir comme service géré, le pouvoir ne réside plus dans le code — il réside dans l’infrastructure. C’est la même dynamique qui permet à un hypermarché d’imposer ses conditions à ses fournisseurs : celui qui contrôle le linéaire dicte les termes. 🟡 70-89%

2.3 L’extraction comme modèle d’affaires célébré

[INTERPRÉTATION] Pendant cette ère, le capital-risque a explicitement financé la stratégie de construction sur des fondations open source tout en capturant la valeur en privé. Le modèle « open core » — un noyau open source gratuit surmonté de fonctionnalités propriétaires payantes — est devenu le playbook standard. MongoDB l’a décrit dans son introduction en bourse (S-1, 2017) : la version gratuite existe « pour encourager l’usage par les développeurs, la familiarité et l’adoption de notre plateforme ». C’est une stratégie de dépendance délibérée : l’open source crée l’addiction, la version payante capture la valeur. 🟡 70-89%

[FAIT] Les projets ayant changé de licence — MongoDB, Elastic, Redis, CockroachDB, Confluent — sont tous contrôlés par des entreprises uniques, généralement adossées à du capital-risque. Le capital-risque cherche des options de sortie (introduction en bourse, acquisition). Cette tension entre la logique communautaire de l’open source et la logique de sortie du capital-risque est structurelle, pas accidentelle. 🟡 70-89%

[INTERPRÉTATION] La reconnaissance de ce schéma par la communauté des développeurs a été progressive plutôt que soudaine. Des voix critiques existaient tôt — le mainteneur de Typesense a noté sur Hacker News que l’open source est « formidable pour attirer des contributeurs » mais devient « un albatros autour du cou » quand il s’agit de générer des revenus. Mais la prise de conscience collective s’est cristallisée autour des incidents concrets : les changements de licence, les forks par les géants du cloud, les burnouts publics de mainteneurs.

2.4 La « classe de configuration » : quand développer devient assembler

La fatigue des frameworks

[FAIT] L’enquête Stack Overflow 2024 (65 437 répondants de 185+ pays) révèle que le burnout n’est plus subtil — il est bruyant. Pour la première fois, les développeurs seniors rapportent une satisfaction professionnelle plus basse que les juniors. Une enquête Stack Overflow de 2022 a trouvé que 2 développeurs sur 5 présentent un risque élevé de burnout. 🟡 70-89%

[INTERPRÉTATION] Le phénomène de « JavaScript fatigue » ou « framework fatigue » a un nom depuis au moins 2016. Le cycle d’adoption, d’apprentissage et de migration entre frameworks crée ce qu’un analyste décrit comme « un burnout silencieux même parmi les équipes les plus dévouées ». Le problème n’est pas simplement qu’il y a trop d’outils — c’est que chaque changement de pile technologique impose un coût cognitif et temporel : configuration, débogage, nouvelles abstractions à comprendre. Le développeur moderne ne code pas tant qu’il ne configure : il assemble des services, relie des API, et gère des fichiers de configuration pour des outils qu’il n’a pas choisis et ne comprend pas pleinement.

David Haney posait la question dès 2016 : « Si vous ne pouvez pas écrire une fonction left-pad en 5 minutes, vous ne savez pas coder. Enfiler des appels d’API les uns aux autres et appeler ça de la programmation n’en fait pas de la programmation. C’est une forme délirante de piratage de dépendances impliquant le cloud, la sur-ingénierie et une complexité bien au-delà de ce qui est nécessaire. »

L’érosion de l’identité artisanale

[INTERPRÉTATION] Quand le travail passe de « construire » à « assembler », quelque chose se perd dans l’identité professionnelle. Le syndrome de l’imposteur dans les communautés de développeurs est omniprésent : le sentiment de ne pas « vraiment » comprendre la pile technologique qu’on utilise, l’anxiété de dépendre de code qu’on n’a jamais lu. L’ère artisanale avait produit un développeur dont la dignité venait de la maîtrise. L’ère de l’assemblage produit un développeur dont la productivité vient de la vitesse de configuration — et dont la dignité est menacée par la prochaine mise à jour de framework qui rend ses compétences obsolètes.

Le contraste avec l’ère 1 est frappant : le développeur des années 1990 savait ce que faisait chaque composant de sa pile. Le développeur de l’ère de l’assemblage gère un graphe de dépendances qu’aucune personne ne peut inspecter. Le premier avait une relation artisanale avec ses outils. Le second a une relation de dépendance avec ses fournisseurs — invisibles, non payés, et potentiellement en burnout.

2.5 Les enjeux humains

Le réveil politique : quand les gouvernements découvrent la chaîne d’approvisionnement

[FAIT] L’Executive Order 14028 du président Biden (mai 2021) a rendu les Software Bills of Materials (SBOM) obligatoires pour les fournisseurs du gouvernement fédéral américain. Le EU Cyber Resilience Act (CRA), proposé en 2022 et adopté en 2024 (Règlement 2024/2847), impose des exigences de cybersécurité obligatoires pour tous les fabricants vendant des produits numériques sur le marché européen, avec entrée en vigueur complète en décembre 2027. Le CRA exige explicitement un SBOM dans la documentation technique et la capacité de rappeler des produits défectueux — allant plus loin que l’approche américaine. 🟢 90-100%

[INTERPRÉTATION] Ces réponses politiques sont significatives mais tardives. Elles arrivent après deux décennies pendant lesquelles la chaîne d’approvisionnement logicielle s’est construite sans supervision. L’approche CRA — qui impose non seulement la transparence mais la capacité de rappel — est structurellement plus ambitieuse que l’approche américaine. Mais un acteur est absent de la conversation : les mainteneurs eux-mêmes. Comme le note Sonatype, le CRA pourrait être « bon pour la sécurité de la chaîne d’approvisionnement, mauvais pour l’open source » — en imposant des obligations de conformité à des bénévoles qui n’ont déjà pas les ressources pour maintenir leurs projets. 🟡 70-89%

L’asymétrie globale

[INTERPRÉTATION] L’ère de l’assemblage a démocratisé l’accès aux outils de développement. Un développeur à Abidjan installe les mêmes paquets npm qu’un développeur à San Francisco. Mais l’asymétrie persiste : moins de bande passante pour télécharger les dépendances, moins d’infrastructure pour les tests, et aucun siège à la table de gouvernance. Les communautés francophones du logiciel libre (les RAFLL, Ovillage en Côte d’Ivoire, les communautés OpenStreetMap en Afrique de l’Ouest) continuent de construire des alternatives, mais elles opèrent à l’intérieur d’un écosystème de dépendances qu’elles ne contrôlent pas.

Le paradoxe est complet : npm, pip et Maven ont donné au monde entier les mêmes briques de base. Mais la gouvernance de ces briques — les décisions sur les licences, les politiques de suppression, les priorités de maintenance — reste concentrée dans une poignée d’entreprises américaines. La démocratisation de l’usage n’est pas la démocratisation du pouvoir.

3. Contradictions et signaux faibles

L’assemblage : asservissement ou émancipation ?

Argument pour l’asservissement : L’ère de l’assemblage a créé une dépendance structurelle envers des communs non financés, des plateformes cloud oligopolistiques, et un écosystème de frameworks en rotation permanente. Le développeur individuel a perdu la maîtrise de ses outils au profit de la vitesse de livraison. Le burnout est devenu endémique. L’extraction est devenue invisible.

Argument pour l’émancipation : Cette même ère a permis à plus de personnes de construire du logiciel que jamais dans l’histoire. Un développeur autodidacte avec un ordinateur et une connexion Internet peut expédier un produit fonctionnel en quelques semaines. L’enquête Stack Overflow 2024 montre que les développeurs n’attendent plus la permission d’une institution pour apprendre — « ils trouvent la documentation, vont sur YouTube, et apprennent en public ». Les barrières d’infrastructure ont été écrasées par le cloud. Les barrières de connaissance ont été écrasées par les gestionnaires de paquets.

Le signal faible : Les deux sont vrais, mais ils ne sont pas vrais pour les mêmes personnes. L’émancipation profite au développeur qui assemble un produit pour expédier. L’asservissement frappe le mainteneur qui maintient les briques que tout le monde utilise. Le premier est célébré. Le second est invisible. C’est la même structure que dans la grande distribution : le consommateur bénéficie de prix bas ; le producteur est écrasé par la pression sur les marges. La question n’est pas « est-ce que c’est bon ou mauvais ? » mais « pour qui ? ».

Le silence autour du modèle d’affaires du cloud

Le débat Elastic/AWS a été traité par la presse spécialisée comme un conflit commercial entre entreprises. Il est rarement formulé dans les termes qui lui conviendraient : un débat sur l’enclosure des communs numériques. Quand un fournisseur cloud peut forker n’importe quel projet open source et l’offrir comme service géré, les incitations à contribuer au commun s’effondrent pour tous ceux qui ne sont pas le fournisseur cloud. C’est le mécanisme classique de la tragédie des communs — mais avec cette différence que la tragédie est organisée, financée et célébrée comme innovation.

4. Angles morts

L’économie politique du capital-risque dans l’open source. Les dynamiques de pouvoir entre investisseurs, fondateurs et communautés dans les entreprises open core méritent une analyse dédiée. La pression vers la sortie (IPO, acquisition) déforme systématiquement les incitations communautaires.

Les développeurs du Sud global. Cette recherche manque de données primaires sur l’expérience vécue par les développeurs en Afrique, en Asie du Sud et en Amérique latine face à la dépendance aux plateformes. Les RAFLL et les communautés similaires sont documentées, mais l’expérience quotidienne du développeur qui assemble des paquets npm depuis Dakar ou Dhaka reste sous-étudiée.

Les alternatives concrètes. Deno, Bun, et d’autres projets tentent de réduire l’explosion des dépendances. Les « vendored dependencies » (copie des dépendances dans l’arbre source) sont une pratique ancienne qui connaît un regain d’intérêt. Ces alternatives n’ont pas été explorées ici.

Le genre et la diversité dans la maintenance. Qui sont les mainteneurs ? Les données d’Eghbal et de Tidelift montrent que ce sont souvent des individus isolés, mais l’analyse genrée et géographique de cette population est insuffisante.

5. Synthèse actionnable

L’ère de l’assemblage a établi quatre conditions qui rendent l’ère générative (ère 3) non seulement possible mais prévisible :

Première condition : un corpus massif de code sur GitHub. L’explosion des dépendances et la centralisation du code sur GitHub (racheté par Microsoft en 2018) ont créé le plus grand corpus de code jamais assemblé. Ce corpus est la matière première sur laquelle les modèles de langage ont été entraînés. Sans l’ère de l’assemblage, il n’y aurait pas de Copilot.

Deuxième condition : une main-d’œuvre habituée à assembler plutôt qu’à construire. La « classe de configuration » — les développeurs dont le travail consiste à câbler des services plutôt qu’à écrire des algorithmes — est la population la plus immédiatement menacée par les outils de génération de code. Si votre travail est déjà d’assembler des appels d’API, un modèle de langage peut le faire aussi.

Troisième condition : une attente normalisée que les communs existent pour être moissonnés. Le recadrage « open source » de l’ère 1, renforcé par le modèle open core de l’ère 2, a normalisé l’idée que le code des communs est un input pour la création de valeur privée. L’entraînement de modèles de langage sur des corpus de code open source est la conclusion logique de cette normalisation.

Quatrième condition : un paysage politique qui commence à peine à comprendre les enjeux. L’Executive Order de 2021 et le CRA européen sont des réponses à des incidents passés (SolarWinds, Log4Shell). Ils ne sont pas conçus pour les enjeux de l’ère générative — l’extraction de savoir-faire à partir du corpus GitHub, la commodification de l’écriture de code, la question de ce qui revient aux auteurs du code sur lequel les modèles sont entraînés.

6. Pistes d’approfondissement

Session 3 (prévue) : L’ère générative. Comment l’entraînement de modèles de langage sur des corpus de code open source constitue la forme la plus radicale d’extraction à ce jour. Le code est transformé en poids statistiques qui remplacent le développeur lui-même. La question des droits d’auteur, la commodification de l’écriture de code, et l’impact sur l’identité professionnelle des développeurs.

Approfondissement nécessaire : l’économie politique du capital-risque dans l’open source ; l’expérience vécue des développeurs du Sud global face à la dépendance aux plateformes ; les alternatives concrètes au modèle de dépendances massives (vendored dependencies, Deno, Guix, Nix) ; la gouvernance des fondations open source (Apache, Linux Foundation, CNCF) et leur relation aux entreprises qui les financent.

7. Pont vers l’ère 3

L’ère 2 a laissé sur la table exactement ce que l’ère 3 avait besoin de trouver.

Un corpus. GitHub héberge plus de 200 millions de dépôts. La quasi-totalité du code public produit pendant l’ère de l’assemblage est indexé, accessible, et stocké dans un format que les modèles de langage peuvent ingérer. Ce n’est pas un accident — c’est la conséquence directe du choix de centraliser le développement logiciel mondial sur une plateforme unique, rachetée par Microsoft pour 7,5 milliards de dollars en 2018.

Une main-d’œuvre. Des millions de développeurs dont le travail quotidien consiste déjà à assembler plutôt qu’à construire — et qui sont donc les premiers candidats à la commodification par des outils qui assemblent plus vite qu’eux.

Une norme. L’idée que le code produit dans les communs est un input librement disponible pour la création de valeur privée. Si IBM pouvait construire un milliard de dollars de ventes sur Linux, si AWS pouvait forker Elasticsearch et l’offrir comme service, alors pourquoi OpenAI ne pourrait-il pas entraîner un modèle sur l’intégralité de GitHub ?

Un vide politique. Les régulateurs commencent à peine à comprendre les SBOM et les chaînes de dépendances. La question de savoir ce qui revient aux auteurs du code sur lequel les modèles sont entraînés n’a pas encore de cadre juridique. Quand l’ère générative arrive, elle trouve un terrain sans clôtures.

Le logiciel est « open » mais l’utilisateur est enfermé dans des plateformes. La route est libre — mais le péage est à la sortie.

8. Table des sources

#	Source	Type	Date	Langue
1	Wikipedia, « npm left-pad incident »	📝 Encyclopédie	2026	EN
2	The Register, « How one developer just broke Node, Babel and thousands of projects »	📰 Presse spéc.	03/2016	EN
3	Quartz, « How one programmer broke the internet by deleting a tiny piece of code »	📰 Presse gén.	03/2016	EN
4	D. Haney, « NPM & left-pad: Have We Forgotten How To Program? »	📝 Blog	03/2016	EN
5	npm Blog, « kik, left-pad, and npm » (post-mortem officiel)	🏛️ Primaire	03/2016	EN
6	LWN.net, « A single Node of failure »	📰 Presse spéc.	03/2016	EN
7	Wikipedia, « Log4Shell »	📝 Encyclopédie	12/2025	EN
8	CISA, « Apache Log4j Vulnerability Guidance »	🏛️ Primaire	12/2021	EN
9	CISA/FBI/NSA, « Mitigating Log4Shell and Other Log4j-Related Vulnerabilities »	🏛️ Primaire	12/2021	EN
10	PMC/NIH, « Log Jam: Lessons Learned from the Log4Shell Vulnerability »	🎓 Académique	2023	EN
11	DataCenter Knowledge, « Log4Shell Vulnerability Highlights Software Supply Chain Issues »	📰 Presse spéc.	01/2022	EN
12	CSA Singapore, « The Log4Shell Vulnerability »	🏛️ Primaire	2022	EN
13	Wikipedia, « Server Side Public License »	📝 Encyclopédie	01/2026	EN
14	TechTarget, « Elastic vs. AWS highlights open source monetization dilemma »	📰 Presse spéc.	2021	EN
15	The Register, « OpenSearch, the AWS-sponsored Elasticsearch fork, reaches 1.0 »	📰 Presse spéc.	07/2021	EN
16	Computing.co.uk, « Elastic has stretched the patience of many in open source »	📰 Presse spéc.	01/2021	EN
17	Architecture Weekly, « Why Open Source Isn’t Always Fair »	📝 Blog	08/2025	EN
18	Stack Overflow, « 2024 Developer Survey »	🏛️ Primaire	05/2024	EN
19	ShiftMag, « Stack Overflow Survey: 80% of developers are unhappy »	📰 Presse spéc.	01/2025	EN
20	Medium/Devglyph, « How Chasing Every New JavaScript Framework Burned Me Out »	📝 Blog	10/2025	EN
21	N. Eghbal, « Roads and Bridges », Ford Foundation	🏛️ Primaire	2016	EN
22	N. Eghbal, « Working in Public », Stripe Press	🏛️ Primaire	2020	EN
23	TechCrunch, « Open source sustainability »	📰 Presse spéc.	06/2018	EN
24	The Register, « When software depends on a random guy in Nebraska »	📰 Presse spéc.	05/2021	EN
25	OpenSSF, « SBOM Standards: EU CRA and OpenSSF »	🏛️ Primaire	10/2025	EN
26	Sonatype, « EU CRA: Good for Software Supply Chain Security, Bad for Open Source? »	📰 Presse spéc.	12/2022	EN
27	NCSC UK, « SBOMs and the importance of inventory »	🏛️ Primaire	03/2025	EN
28	Commission européenne, « Cyber Resilience Act »	🏛️ Primaire	2024	EN
29	FOSSA, « SBOM Requirements in the EU’s CRA »	📰 Presse spéc.	09/2024	EN

Recherche effectuée en mars 2026. Langues : français, anglais. Sources sur le Sud global issues de la session 1 (RAFLL, communautés francophones du libre). Toutes les URL visitées pendant la recherche.