Examiner la juridiction de gouvernance des composants tiers que vous utilisez dans vos projets professionnels#
De quoi s’agit-il concrètement#
Cet engagement consiste à examiner systématiquement, pour chaque projet professionnel que vous démarrez ou que vous reprenez, la juridiction de gouvernance des composants tiers que vous utilisez. Concrètement, cela signifie ouvrir le package.json, le requirements.txt, le Cargo.toml, le go.mod, le pom.xml ou l’équivalent, identifier les dépendances substantielles, et documenter pour chacune l’éditeur ou la fondation qui la gouverne, sa juridiction, et son modèle (single-vendor, fondation neutre, propriétaire).
L’engagement ne demande pas une analyse de chaque dépendance transitive — il vise les composants substantiels que vous avez consciemment choisis et dont la défaillance ou la bascule de licence aurait un impact réel sur le projet. La documentation peut prendre la forme d’une section « composants tiers » dans le README du projet, d’un fichier DEPENDENCIES.md séparé, ou d’un commentaire structuré dans la documentation d’architecture.
L’engagement vaut comme déclaration individuelle. Il porte sur vos projets professionnels (clients ou employeur) dans la mesure où vous avez le contrôle ou l’influence sur le choix des composants. Pour les projets où vous arrivez en cours de route sur une stack figée, l’engagement se traduit en une analyse documentaire que vous partagez à votre équipe ou à votre client.
Pourquoi cet engagement compte#
Beaucoup de développeurs choisissent leurs dépendances par habitude ou par effet de réseau, sans examiner leur gouvernance. Ce comportement est compréhensible — la pression du time-to-market est réelle, l’écosystème npm ou PyPI invite à ajouter des dépendances en quelques secondes — mais il a des conséquences cumulatives. La thèse 6 du manifeste rappelle que la souveraineté est un attribut de la chaîne entière : « la souveraineté technologique d’un logiciel se mesure sur sa chaîne entière : production, maintenance, distribution, gouvernance, financement, compétences. Aucun de ces maillons ne suffit ; chacun peut suffire à la rompre. »
L’examen de juridiction est l’étape de connaissance qui rend visibles les zones de risque. Une dépendance critique sous Redis BSL/SSPL depuis mars 2024, un composant essentiel sous HashiCorp BSL depuis août 2023, une bibliothèque single-vendor en concentration de mainteneurs unique : ces situations doivent être au minimum connues de votre équipe et de votre client. Sans documentation, elles sont invisibles jusqu’au jour où une bascule survient.
L’engagement résonne avec la thèse 5 : « un projet open source dont les contributions, les artefacts ou la roadmap dépendent d’un sponsor unique est un projet libre révocable. » En tant que développeur, vous êtes en première ligne pour identifier ces situations dans votre stack quotidienne. Votre documentation crée un signal que peuvent reprendre vos collègues, vos clients, et la communauté.
Exemple concret de mise en œuvre#
Une développeuse Python freelance qui travaille en parallèle sur trois projets clients prend cet engagement en mai 2026 avec un horizon de 6 mois. Pour chaque nouveau projet et pour les projets en cours qu’elle peut reprendre, elle ajoute un fichier DEPENDENCIES.md qui inventorie les dépendances substantielles avec quatre colonnes : nom, juridiction, modèle de gouvernance, commentaire éventuel.
Sur le premier projet (une application Django pour une petite collectivité), l’inventaire identifie une vingtaine de dépendances : Django (Django Software Foundation, États-Unis, fondation neutre), PostgreSQL via psycopg2 (PostgreSQL Global Development Group, gouvernance distribuée à dominante européenne), Celery (single-vendor open source), Redis-py (Redis Inc., États-Unis, à noter que la version 7.4+ de Redis est sous BSL/SSPL — alternative Valkey suggérée), Sentry SDK (Functional Software Inc., États-Unis), pytest (Python Software Foundation, États-Unis, fondation neutre).
Pour le deuxième projet, l’inventaire identifie une dépendance à Elasticsearch via la bibliothèque officielle ; la développeuse en discute avec le client et propose de basculer vers OpenSearch ou de réévaluer si PostgreSQL avec recherche full-text suffirait. Le client opte pour la deuxième solution. Au sixième mois, les trois projets disposent de leur fichier DEPENDENCIES.md à jour, et la pratique est intégrée à la documentation standard de la freelance pour ses futures missions.
Anti-pattern à éviter#
Une analyse menée mais non partagée avec l’équipe ou le client perd l’essentiel de sa valeur — la documentation n’est utile que si elle circule. Une liste exhaustive de toutes les dépendances transitives sans hiérarchisation rend le document illisible et personne ne le consulte. Un examen mené une seule fois sans actualisation perd progressivement sa valeur informationnelle au fil des évolutions de la stack et des bascules de licence.
Indicateurs de réussite#
À l’horizon de 6 mois, vous pouvez raisonnablement considérer cet engagement tenu si vos projets professionnels en cours disposent d’une documentation des composants tiers substantiels avec leur juridiction et leur modèle de gouvernance, si la pratique est intégrée à votre routine de démarrage de projet, et si la documentation est partagée avec l’équipe ou le client. À long terme, l’engagement prend forme avec l’actualisation régulière et l’éventuel partage public de retours d’expérience.
→ Documenté dans le dossier#
Catégorie dans le schéma JSON : audit. Horizon par défaut : 6 mois. Applicable à : déclarations individuelles uniquement.