De quoi traite ce domaine#
Le premier domaine du Profil de souveraineté demande au déclarant d’identifier les composants tiers — logiciels open source, briques propriétaires, services managés, solutions distribuées — dont la solution proposée dépend de manière non substituable. Non substituable ne veut pas dire impossible à remplacer dans l’absolu ; cela veut dire qu’un remplacement nécessiterait un effort substantiel et que l’absence du composant priverait la solution d’une fonctionnalité critique.
Pour chaque composant retenu, le déclarant indique son nom, sa version, sa licence, l’éditeur ou la fondation qui en assure la gouvernance, la juridiction de cette gouvernance, et son caractère essentiel ou périphérique dans la solution. L’objectif n’est pas l’exhaustivité — un projet typique a des centaines de dépendances transitives, leur liste exhaustive n’apporte rien à un acheteur. L’objectif est la liste des composants stratégiquement déterminants, qui se compte typiquement en quelques dizaines.
Pourquoi ce domaine compte#
Ce domaine est le point de départ de toute analyse de souveraineté sérieuse. La thèse 6 du manifeste l’énonce : « 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. » Sans visibilité sur les composants, l’acheteur ne peut pas évaluer son exposition propre via la solution. Or la dépendance se propage : si la solution dépend de Redis 7.4 sous BSL/SSPL depuis mars 2024, le client de la solution dépend lui aussi de cette situation, qu’il en ait conscience ou non.
À l’échelle agrégée, la publication massive de listes de composants stratégiques par les fournisseurs européens alimente l’observatoire des lacunes du manifeste. Les concentrations de dépendances apparaissent : tel composant single-vendor utilisé simultanément par des centaines d’organisations, telle brique cryptographique critique dont la maintenance repose sur un mainteneur unique non rémunéré. Cette visibilité collective oriente l’investissement public et privé vers les zones de risque les plus structurantes.
Pour le déclarant lui-même, l’exercice de remplissage du domaine 1 est souvent un déclencheur de travail interne. Beaucoup de fournisseurs découvrent en remplissant cette section des dépendances qu’ils n’avaient pas conscientisées, des composants qu’ils ne pensaient pas stratégiques mais qui le sont à l’examen, ou des bascules de licence récentes dont leurs équipes ne s’étaient pas alarmées.
Ce qui est demandé par catégorie de déclarant#
Pour un éditeur de logiciel. Liste des composants logiciels tiers (open source ou propriétaires) intégrés dans la solution ou indispensables à son exécution : bases de données, caches, files de messages, bibliothèques cryptographiques, frameworks structurants, services tiers connectés en mode API. Une vingtaine à une cinquantaine d’entrées est typique pour un produit SaaS de complexité moyenne.
Pour un hébergeur ou fournisseur cloud. Liste des briques techniques sous-jacentes de l’infrastructure : hyperviseur (VMware, Proxmox VE, KVM), orchestrateur de conteneurs (Kubernetes, OpenShift), bases de données managées proposées en service, services de stockage objet, systèmes d’exploitation des nœuds. La nature de l’éditeur ou de la fondation qui gouverne chaque brique est centrale — VMware sous Broadcom, OpenShift sous Red Hat / IBM, Kubernetes sous CNCF n’ont pas le même profil de souveraineté.
Pour un distributeur ou intégrateur. Liste des solutions distribuées dont l’éditeur d’origine est non-européen, avec part du chiffre d’affaires associée et nature de l’accord de distribution (revente simple, marque blanche, packaging avec valeur ajoutée). Cette catégorie est politiquement la plus sensible parce qu’elle révèle la part réelle d’activité « souveraine » au sens du manifeste.
Exemple de réponse honnête bien faite#
Un éditeur SaaS B2B européen de 28 personnes, qui propose une plateforme de gestion de tickets pour la maintenance industrielle, identifie 24 composants stratégiques dans son domaine 1. Pour chacun, la liste est précise. PostgreSQL 16 (PostgreSQL Global Development Group, gouvernance distribuée à dominante européenne, fondation neutre, essentiel). Valkey 7.2.4 (Linux Foundation, États-Unis, fondation neutre multi-vendor, essentiel — alternative adoptée à Redis suite à la bascule BSL/SSPL de mars 2024). RabbitMQ (Broadcom Inc., États-Unis, single-vendor, essentiel — surveillé depuis le rachat VMware-Broadcom de novembre 2023). PostgreSQL full-text search (avec OpenSearch en option pour les clients à fort volume, OpenSearch Software Foundation / Linux Foundation depuis septembre 2024, essentiel sur le scénario fort volume). Keycloak (Red Hat / IBM, États-Unis, single-vendor open source, essentiel). Grafana 11 (Grafana Labs Inc., États-Unis, single-vendor open source sous AGPL depuis avril 2024, périphérique).
L’éditeur publie aussi en parallèle de son sovereignty.json un fichier SBOM au format CycloneDX, ce qui permet aux clients d’intégrer la liste à leurs propres outils d’analyse. La liste est révisée annuellement et à chaque évolution majeure de la stack technique.
Anti-pattern à éviter#
Un domaine 1 qui se résume à « notre solution s’appuie sur les standards open source de l’industrie » sans nommer les composants ne donne aucune information utile. Symétriquement, une liste exhaustive de toutes les dépendances transitives au format technique illisible noie l’information stratégique. Une liste qui omet les composants problématiques (par exemple, qui ne mentionne pas que Redis utilisé est en version 7.4+ sous BSL/SSPL) sape la crédibilité de l’ensemble du Profil.
Articulation avec les autres domaines et engagements#
Le domaine 1 est le préalable du domaine 2 (qui demande pour chaque composant stratégique un plan de contournement) et alimente le domaine 7 (qui assume les angles morts identifiés). Il s’articule directement avec l’engagement pub-006-publish-component-jurisdiction-list : un fournisseur qui a pris cet engagement dispose déjà d’une grande partie du contenu du domaine 1. Il est également le miroir, côté fournisseur, de l’engagement utilisateur user-001-audit-dependencies : ce que le fournisseur déclare dans son domaine 1 nourrit directement l’audit que conduit son client.
Comment remplir le formulaire#
Le formulaire vous propose d’abord une bibliothèque de composants couramment utilisés (PostgreSQL, Kubernetes, Redis, etc.) que vous pouvez sélectionner d’un clic. Pour chaque composant retenu — depuis la bibliothèque ou ajouté librement — voici comment renseigner les champs.
Identification du composant#
- Nom et version : nommez précisément, version comprise quand elle conditionne les droits ou la gouvernance (ex. : Redis 7.4 — bascule sous BSL/SSPL — vs Redis 6.2 — encore BSD).
- Catégorie : libellé court qui aide à comprendre le rôle (hyperviseur, ORM, base de données, runtime JS, moteur de recherche, etc.).
- Éditeur ou fondation : entité qui contrôle effectivement la roadmap (ex. : PostgreSQL Global Development Group, Linux Foundation, MongoDB Inc., Oracle Corporation).
- Juridiction de gouvernance : pays sous le droit duquel opère cette entité. Code ISO simple (FR, US, DE, NL…).
Criticité et sources#
- Criticité : trois niveaux. Essentiel = sans ce composant, l’activité s’arrête sous 24 h. Important = dégradation majeure mais palliatif possible. Secondaire = remplaçable sans perturbation forte. Soyez sobre avec « essentiel » — si tout est essentiel, rien ne l’est.
- Source publique (URL) : un lien qui prouve la juridiction ou le contrôle déclaré (page « About » du projet, article Wikipédia, dépôt légal, document officiel). Utile pour que vos lecteurs vérifient.
Modèle de gouvernance#
Deux champs distincts, parce que la divergence entre les deux est elle-même une information.
- Formel : ce qu’annonce la documentation officielle (« fondation 501(c)(3) avec board élu », « single-vendor », « consortium d’éditeurs »).
- Pratique effective : ce que vous observez sur le terrain (« 80 % des commits proviennent d’un seul éditeur », « board présidé de fait par X », « décisions techniques prises hors gouvernance officielle »). Mention courte mais honnête.
Commentaire libre#
Tout ce qui ne rentre pas dans les cases mais que le lecteur a besoin de savoir : changement de licence en cours, fork stable maintenu en parallèle, dépendance critique non substituable identifiée comme angle mort, etc.