SovereigntyGap.
SovereigntyGap.sovereignty-gap.eu

Famille 3 · ~11 min de lecture

Les chaînes de distribution captives

Cas qui démontrent que l'usage de logiciel libre n'empêche pas la dépendance d'infrastructure : registres, CDN, forges sont massivement concentrés sous juridiction étrangère.

Thèses illustrées 06 · 07 · 11

Utiliser du logiciel libre n’empêche pas la dépendance d’infrastructure. Le code transite par des forges, les binaires sont distribués par des registres, les artefacts sont servis par des CDN. Or ces couches d’infrastructure sont massivement concentrées sous juridiction étrangère, et leurs incidents passés montrent qu’elles peuvent défaillir, bloquer ou disparaître. Les fiches qui suivent documentent cette captivité de la chaîne.

GitHub — La forge de référence mondiale sous propriété Microsoft#

Date du fait principal : rachat juin 2018, opération continue Statut : confirmé, en vigueur Thèses du manifeste illustrées : 2, 4, 7

Le fait#

GitHub est aujourd’hui la forge de code dominante mondialement, hébergeant environ 90 % des projets open source. Acquise par Microsoft en juin 2018 pour 7,5 milliards de dollars, elle est juridiquement une entreprise américaine soumise au droit américain, y compris pour ses utilisateurs européens. Le code source de la quasi-totalité des projets open source mondiaux — y compris les briques critiques de l’infrastructure européenne — y est versionné, partagé et collaboré.

Ce qu’il démontre#

Cette concentration crée une dépendance structurelle qui dépasse le simple choix d’outil. Quand le code source de l’écosystème ouvert mondial transite et est versionné sur l’infrastructure d’une seule entreprise privée américaine, c’est cette entreprise qui détient :

  • Les métadonnées de contribution (qui modifie quoi, quand, depuis où)
  • Le contrôle d’accès aux dépôts privés des organisations utilisatrices
  • L’application des sanctions américaines (voir famille 2)
  • L’écosystème de tooling associé : Issues, Pull Requests, Actions (CI/CD), Packages, Copilot

Cette concentration de fonctions essentielles à la production logicielle dans une juridiction étrangère est l’un des points les plus structurants du débat sur la souveraineté.

Des alternatives européennes existent — Codeberg (~117 000 projets, association allemande à but non lucratif), Forgejo (logiciel libre auto-hébergeable, fork de Gitea), et les instances GitLab self-hosted opérées en Europe — mais aucune n’approche la masse contributive de GitHub. La fédération inter-instances reste embryonnaire ; l’asymétrie d’adoption est elle-même un état des lieux que documente cette famille.

Sources#

npm — Le registre JavaScript dominant, propriété de Microsoft#

Date : rachat mars 2020 (npm Inc. par GitHub donc Microsoft) Statut : confirmé, en vigueur Thèses du manifeste illustrées : 2, 7

Le fait#

Le npm registry est le registre dominant des paquets JavaScript consommés dans le monde. Il est la propriété de GitHub, donc de Microsoft, depuis mars 2020. Plus de 3,1 millions de paquets y sont publiés, téléchargés des dizaines de milliards de fois par mois pour alimenter les builds frontend de la quasi-totalité des applications web et mobiles modernes.

Ce qu’il démontre#

Le npm registry est l’archétype du single point of failure d’un écosystème de programmation entier. Toute organisation qui développe en JavaScript ou TypeScript dépend, plusieurs fois par jour, d’un service géré par une seule entreprise américaine. Aucune alternative européenne d’envergure comparable n’existe. Cette dépendance est invisible — elle est cachée dans package.json et npm install — mais elle est universelle.

Sources#

  • npm registry : https://www.npmjs.com/
  • Microsoft, communiqué d’acquisition de npm Inc. par GitHub (mars 2020).
  • Statistiques de téléchargement npm.

Docker Hub — Le registre de conteneurs sans alternative européenne#

Date : depuis 2014 Statut : continu Thèses du manifeste illustrées : 2, 7

Le fait#

Docker Hub est le registre de référence pour les images de conteneurs, propriété de Docker Inc. (entreprise américaine basée à Palo Alto). Il héberge plusieurs millions d’images, téléchargées des dizaines de milliards de fois par mois pour alimenter les déploiements Kubernetes et conteneurisés mondiaux. Aucun équivalent européen à échelle comparable n’existe à ce jour.

Ce qu’il démontre#

L’orchestration cloud-native moderne, dominée par Kubernetes (voir famille 4), repose mécaniquement sur Docker Hub pour la distribution de ses images de base et de ses composants. Les images officielles des projets open source critiques — Postgres, Redis, Nginx, Node, Python, etc. — sont distribuées prioritairement via Docker Hub. Les organisations européennes qui déploient des conteneurs consomment Docker Hub, même quand elles utilisent un cloud français ou européen pour l’exécution. La couche d’orchestration peut être souveraine, sa source d’approvisionnement ne l’est pas.

Sources#

PyPI et Maven Central — Les registres Python et Java captifs#

Date : continu Statut : confirmé Thèses du manifeste illustrées : 2, 7

Le fait#

PyPI (Python Package Index) est géré par la Python Software Foundation, association à but non lucratif américaine 501(c)(3). Il est hébergé techniquement sur Fastly, CDN également américain. Il distribue plus de 500 000 projets Python, soit plusieurs millions de fichiers, téléchargés des milliards de fois par mois.

Maven Central, le registre de référence pour les paquets Java et de l’écosystème JVM, est géré par Sonatype, entreprise américaine.

Ce qu’il démontre#

Les écosystèmes Python et Java — utilisés massivement par la recherche scientifique européenne, l’industrie financière européenne, et les applications d’entreprise — dépendent intégralement de registres américains pour leur approvisionnement quotidien. La fondation Python est juridiquement américaine, donc soumise aux sanctions américaines comme la Linux Foundation. Sonatype est une entreprise commerciale qui peut changer de stratégie ou d’actionnaire à tout moment.

Sources#

L’incident left-pad — La fragilité opérationnelle révélée#

Date du fait : 22 mars 2016 Statut : historique, exemplaire Thèses du manifeste illustrées : 2, 7, 8

Le fait#

Le 22 mars 2016, le développeur Azer Koçulu retire 273 paquets de npm, dont un mini-paquet de 11 lignes nommé left-pad, suite à un différend avec npm Inc. concernant un autre de ses paquets (Kik). Bien que le contenu de left-pad soit trivial — il ajoute des espaces ou des caractères à gauche d’une chaîne pour atteindre une longueur fixe — il était utilisé par des milliers de paquets dépendants (notamment via Babel, le transpileur JavaScript). En quelques heures, des milliers de builds dans le monde entier échouent : les pipelines de CI/CD se bloquent, des entreprises ne peuvent plus déployer leurs applications, et l’écosystème JavaScript mondial vacille pendant plusieurs heures.

Dans les dix minutes qui suivent, un autre développeur, Cameron Westland, republie une version 1.0.0 fonctionnellement identique. Mais comme de nombreuses chaînes de dépendances exigent explicitement la version 0.0.3 du paquet, les erreurs continuent. npm Inc. décide alors unilatéralement de restaurer la version 0.0.3 originale sous l’autorité d’un nouveau mainteneur, sans le consentement de l’auteur originel — ce qui crée à son tour une polémique sur la propriété et la liberté du logiciel. À la suite de l’incident, npm modifie sa politique : un paquet ne peut plus être désactivé après 24 heures s’il a au moins une dépendance.

Ce qu’il démontre#

L’incident left-pad est l’un des cas-école les plus pédagogiques de la fragilité de la chaîne d’approvisionnement logicielle moderne. Il montre simultanément :

  1. L’opacité des dépendances. Personne ne savait, avant l’incident, à quel point l’écosystème JavaScript dépendait d’un paquet de 11 lignes. C’est un proxy pour l’invisibilité générale des dépendances transitives.
  2. Le pouvoir unilatéral du registre. npm Inc. a pu restaurer un paquet contre la volonté de son auteur. Cela montre que le contrôle du registre prime sur la propriété intellectuelle individuelle.
  3. L’absence de plan de continuité. Aucune organisation utilisatrice ne disposait de miroir local ou de stratégie de fallback. La rupture était immédiate et irrécupérable sans intervention de npm.

Sources#

  • The Register (mars 2016), How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript : https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
  • Azer Koçulu, billet personnel, I’ve Just Liberated My Modules (mars 2016).
  • David Haney, NPM & left-pad: Have We Forgotten How To Program?

OpenShift — Un produit Red Hat redistribué comme infrastructure souveraine#

Date du fait : produit lancé 2011 ; analyse à avril 2026 Statut : continu Thèses du manifeste illustrées : 5, 6, 7, 12

Le fait#

OpenShift Container Platform est un produit propriétaire de Red Hat, filiale d’IBM depuis le rachat de juillet 2019 (35 milliards de dollars). C’est un point juridique et industriel important : OpenShift n’est pas un projet de gouvernance ouverte, ce n’est pas un projet CNCF, ce n’est pas une fondation.

OpenShift est construit sur des composants open source — principalement Kubernetes, mais aussi de nombreux autres projets CNCF — auxquels Red Hat ajoute une couche d’intégration, des outils de développement (OpenShift Developer Tools), des opérateurs Kubernetes spécifiques, des composants de sécurité (Red Hat Advanced Cluster Security, ex-StackRox), et un cycle de support entreprise. Cette couche d’intégration est sous contrôle exclusif de Red Hat. La roadmap d’OpenShift, son calendrier de support, sa politique de pricing, ses conditions de licence, ses choix d’intégration tierce sont arbitrés au siège Red Hat à Raleigh (Caroline du Nord) et en dernière instance au siège IBM à Armonk (État de New York).

Une partie d’OpenShift est publiée en open source sous le nom OKD (Origin Community Distribution of Kubernetes), mais OKD n’est pas équivalent à OpenShift Container Platform : l’écart porte précisément sur les composants entreprise qui font la valeur du produit. Construire son offre PaaS sur OKD ne procure pas l’accès aux fonctions intégrées qui justifient une qualification souveraine — c’est tout l’enjeu commercial du produit.

Trois acteurs structurants du paysage SecNumCloud français s’appuient explicitement sur OpenShift dans leur offre PaaS :

  • Cloud Temple. En juin 2023, Cloud Temple annonce une offre PaaS basée sur Red Hat OpenShift, dans son cloud SecNumCloud qualifié depuis 2022. Cloud Temple a obtenu la qualification SecNumCloud pour son PaaS OpenShift en mai 2024, devenant le premier opérateur français à obtenir cette qualification sur cette pile. Le développement de cette offre a bénéficié du soutien de Bpifrance dans le cadre du guichet d’accompagnement à la qualification SecNumCloud.

  • NumSpot. Consortium fondé en 2023 par la Banque des Territoires (36 %), Docaposte (26 %), Dassault Systèmes (19 %) et Bouygues Telecom (19 %), NumSpot a fait du service managé Red Hat OpenShift l’une des briques fondatrices de son offre. Son CTO Éric Fredj a déclaré au MagIT en octobre 2024 : « Nous avons un certain nombre de prospects, notamment dans les ministères, qui ont investi dans OpenShift et qui veulent retrouver cet écosystème offrant une plus-value au-dessus d’un cluster Kubernetes. » NumSpot a déposé son dossier de qualification SecNumCloud en septembre 2024 et vise une qualification au S1 2026, qui couvrirait l’ensemble de la pile y compris OpenShift managé.

  • S3NS. Coentreprise Thales–Google Cloud, S3NS a obtenu sa qualification SecNumCloud 3.2 le 17 décembre 2025, en couvrant en une seule décision IaaS, PaaS et CaaS — première décision ANSSI à couvrir ces trois niveaux ensemble. La couche conteneurs de S3NS s’appuie sur Google Kubernetes Engine (GKE) en mode autopilot, avec les versions Kubernetes 1.28 à 1.34. C’est techniquement différent d’OpenShift, mais le pattern de redistribution est analogue : un fournisseur français qualifié SecNumCloud distribue, sous une étiquette souveraine, une distribution Kubernetes managée dont la roadmap est arbitrée à Mountain View.

Le directeur général de l’ANSSI, Vincent Strubel, a déclaré devant la commission d’enquête sénatoriale sur la commande publique le 28 mai 2025 que les montages de Bleu (Microsoft) et S3NS (Google) sont « conformes, sur le papier, aux exigences du SecNumCloud » et qu’ils sont, d’après les analyses juridiques commandées par l’ANSSI, « en principe immunes au Cloud Act et au FISA Act ». Cette protection est réelle : elle porte sur l’inaccessibilité des données et des opérations à des requêtes extraterritoriales américaines, ce qui est l’objectif premier du référentiel.

Ce qu’il démontre#

Cette protection ne couvre pas, en revanche, les décisions unilatérales que pourrait prendre Red Hat-IBM sur OpenShift, ou Google sur GKE, dans leur rôle de producteur de la brique. Si Red Hat décidait demain de modifier les conditions de licence d’OpenShift (comme elle l’a fait en juin 2023 sur les sources RHEL — voir famille 1), de retirer certains opérateurs tiers, de cesser la prise en charge de certaines configurations, ou de modifier la politique de pricing, les fournisseurs SecNumCloud distribuant OpenShift seraient dans la même position que les distributeurs CentOS de juin 2023 : informés en même temps que leurs clients, sans recours.

Cette dimension est, par construction, hors du périmètre actuel du référentiel SecNumCloud. Le référentiel vérifie l’opération souveraine, pas la souveraineté du producteur de la brique. C’est cohérent avec son mandat. Mais c’est une dimension que les acheteurs publics qui interprètent SecNumCloud comme une garantie de souveraineté de bout en bout devraient explicitement traiter, soit par exigence supplémentaire dans les marchés (plan de continuité technologique en cas de bascule du producteur), soit par demande de Profil de souveraineté détaillé sur le statut contributif du fournisseur.

Précision : ce que cette analyse n’est pas. Cette fiche n’est pas une critique des fournisseurs nommés (Cloud Temple, NumSpot, S3NS), qui font un travail réel et documenté de qualification, d’opération, de sécurisation. Elle n’est pas non plus une critique du référentiel SecNumCloud, qui couvre rigoureusement ce qu’il prétend couvrir. Elle est un constat structurel sur une dimension non couverte : l’indépendance technologique des briques redistribuées, distincte de l’indépendance opérationnelle que le référentiel vérifie. Les acheteurs publics et privés qui comprennent cette distinction sont mieux armés pour décider en connaissance de cause ; ceux qui l’ignorent risquent de prendre des engagements qu’ils ne pourront pas tenir si le producteur de la brique change unilatéralement les règles.

Cette dissociation entre indépendance opérationnelle et indépendance technologique est précisément ce que la nouvelle section transverse de l’inventaire des lacunes (« Le syndrome du distributeur ») opérationnalise, et ce que le format du Profil de souveraineté propose de rendre lisible publiquement.

Sources#

→ Engagements opérationnels associés#

La captivité d’infrastructure ne se résout pas par le choix de licence : elle se résout par des choix d’hébergement, de forge, de distribution et par l’exigence de visibilité sur la chaîne réelle.

Catalogue complet des engagements →

Lire le manifeste →