SovereigntyGap.

Documenter publiquement la juridiction de gouvernance des principaux composants de notre chaîne d'approvisionnement

Publier sur votre site une documentation lisible des composants de votre chaîne d'approvisionnement avec leur juridiction.
Lecture estimée : ~3 minutes. Fiche d’engagement publiée dans le programme positif du manifeste, déclarable depuis le Profil de souveraineté.

Documenter publiquement la juridiction de gouvernance des principaux composants de notre chaîne d’approvisionnement#

De quoi s’agit-il concrètement#

Cet engagement consiste à publier, sur votre site, une documentation lisible des principaux composants de votre chaîne d’approvisionnement logicielle avec leur juridiction de gouvernance. La chaîne d’approvisionnement, au sens du manifeste, ne se limite pas aux logiciels que vous utilisez : elle inclut la forge où réside votre code source (GitHub, GitLab, Codeberg, instance interne), les registres de paquets qui livrent vos dépendances quotidiennement (npm, PyPI, Maven Central, RubyGems, crates.io), les registres de conteneurs (Docker Hub, GitHub Container Registry, Quay.io), les services d’intégration continue (GitHub Actions, GitLab CI, CircleCI, Jenkins), et les fournisseurs de certificats (Let’s Encrypt, DigiCert, Certigna, CertEurope).

L’engagement ne demande pas une cartographie technique exhaustive de votre code source — il demande une visibilité publique sur les rails par lesquels passe votre activité. Le format peut être une page web simple, un tableau, ou un document inclus dans un Profil de souveraineté plus large si vous publiez aussi un Profil d’éditeur. La précision recommandée : nom du service, juridiction de gouvernance, modèle (commercial, fondation, association), commentaire éventuel sur l’historique ou les alternatives connues.

Pourquoi cet engagement compte#

La chaîne d’approvisionnement est l’angle mort le plus souvent oublié des analyses de souveraineté. Les organisations qui examinent attentivement leurs logiciels et leurs hébergeurs négligent fréquemment les registres et les forges, alors que leur défaillance ou leur captation aurait des effets opérationnels immédiats. La thèse 7 du manifeste l’énonce sans détour : « distribuer du logiciel libre par des registres et des réseaux soumis à une juridiction étrangère, c’est offrir à cette juridiction un droit de regard et de coupure sur ce que nous croyons posséder. »

Les incidents historiques l’ont illustré. La crise left-pad en mars 2016, où le retrait d’un paquet npm minuscule a fait échouer des dizaines de milliers de builds dans le monde, a démontré la fragilité structurelle de cette chaîne. La limitation des téléchargements anonymes Docker Hub en novembre 2020, les retraits volontaires de paquets colors.js et faker.js en janvier 2022, plus récemment les suspensions de services à destination de la Russie en mars 2022 (Microsoft, Adobe, Visa, Mastercard), montrent que les juridictions et les opérateurs de cette chaîne sont des leviers réels.

L’engagement contribue à un bien commun plus large : si plusieurs organisations européennes documentent publiquement leurs dépendances de chaîne, l’observatoire des lacunes du manifeste peut agréger ces données et rendre visibles les concentrations critiques. La thèse 6 résume l’esprit : « la souveraineté technologique d’un logiciel se mesure sur sa chaîne entière. »

Exemple concret de mise en œuvre#

Une institution culturelle publique française avec une équipe SI de 8 personnes prend cet engagement en mars 2026 avec un horizon de 9 mois. L’équipe inventorie les services par catégorie. Forge : GitLab auto-hébergé sur infrastructure interne en France (gouvernance européenne pour l’instance, code GitLab CE sous gouvernance américaine). Registres de paquets : npm pour le frontend (gouvernance américaine, Microsoft), PyPI pour le backend Python (gouvernance américaine, PSF, infrastructure AWS et Fastly), Maven Central pour quelques outils Java (gouvernance américaine, Sonatype). Registre de conteneurs : Harbor auto-hébergé qui mirrore Docker Hub. CI/CD : GitLab CI sur l’instance interne. Certificats : Let’s Encrypt pour les services publics, Certigna pour les certificats qualifiés eIDAS.

L’institution publie un tableau lisible sur son site avec une note pédagogique d’introduction qui explique pourquoi la documentation est utile au public et aux pairs. La page est mise à jour annuellement. Six mois après publication, deux autres institutions culturelles régionales prennent le même engagement en s’inspirant du tableau publié.

Anti-pattern à éviter#

Une documentation interne classée « confidentielle » ne tient pas l’engagement, qui est explicitement de publier. Une documentation publique mais réduite à « nous utilisons les standards de l’industrie » ne dit rien d’utilisable. La valeur tient à la précision du nom des services et à la mention de juridiction.

Indicateurs de réussite#

À l’horizon de 9 mois, vous pouvez raisonnablement considérer cet engagement tenu si une page publique de votre site documente nominativement les services de votre chaîne d’approvisionnement avec leur juridiction, si la liste couvre au minimum forge, registres de paquets utilisés, registre de conteneurs, CI/CD et certificats, et si une procédure de mise à jour annuelle est définie en interne.

→ Documenté dans le dossier#

Catégorie dans le schéma JSON : audit. Horizon par défaut : 9 mois. Applicable à : entreprises, administrations publiques, associations, fondations, institutions de recherche.

Thèmes

Fiches connexes


Bibliothèque des engagementsuser-005-document-jurisdiction-supply-chainCC BY-SA 4.0