La philosophie du dispositif#

La souveraineté technologique sert une finalité unique : permettre à une organisation — entreprise, administration, particulier — de continuer à exploiter ses données et à mener ses opérations, quels que soient les événements. Défaillance d’un fournisseur, conflit géopolitique, sanctions, rachat hostile, bascule unilatérale d’un éditeur. Tout le reste — licences, contrats, certifications — n’est qu’un moyen pour servir cette fin.

Comment un acheteur — DSI, RSSI, responsable des achats — peut-il savoir si un fournisseur lui permet effectivement cette continuité ? Et comment un fournisseur — éditeur de logiciel, hébergeur, fournisseur cloud, distributeur, intégrateur — peut-il en faire la démonstration sans passer par des dispositifs de certification lourds que seules les grandes entreprises peuvent absorber ?

Le manifeste propose un instrument simple, gratuit, public et vérifiable par tous : un fichier unique sovereignty.json qui couvre sept domaines, publié à un emplacement standardisé sur le domaine du déclarant, indexé sans note ni classement par le manifeste. Le dispositif ne distingue pas l’open source du propriétaire : il distingue les fournisseurs qui rendent leur chaîne lisible de ceux qui la masquent. Selon le profil du déclarant, on parle de Profil de souveraineté (les sept domaines remplis) ou de déclaration d’engagements (seul le domaine 7 rempli) — le format technique est le même.

Pourquoi cette forme plutôt que la certification#

La continuité d’exploitation dépend de toute la chaîne logicielle — éditeur, hébergeur, distributeur, registres, fondations. Si un seul maillon échappe au contrôle ou à la lisibilité, la souveraineté de l’ensemble est compromise. Le dispositif décrit ici existe pour rendre cette chaîne lisible, par un format public et standardisé plutôt que par des audits certifiants.

La souveraineté logicielle souffre d’une asymétrie d’information. Un acheteur — DSI, RSSI, responsable des achats — n’a pas les moyens, le temps, ni souvent la compétence pour démêler ce qu’un produit ou service implique réellement en matière de dépendances, de juridictions, de plans de continuité. Les déclarations marketing des fournisseurs sont peu comparables, peu vérifiables, et tendent à mettre en avant les points forts en taisant les points faibles.

Les réponses traditionnelles à cette asymétrie reposent sur la certification : audits par tiers, labellisation par organismes accrédités, conformité à des référentiels. Ces dispositifs ont leur utilité mais ils ont un coût. Un audit annuel sérieux représente plusieurs dizaines de milliers d’euros. Une qualification ISO ou SecNumCloud peut coûter beaucoup plus. Ce coût exclut de fait les TPE et PME éditrices européennes — précisément les acteurs que la souveraineté technologique européenne devrait promouvoir. Il enrichit en outre les cabinets d’audit, dont une part substantielle est anglo-saxonne, ce qui pose un problème de cohérence pour un dispositif de souveraineté.

Nous proposons une alternative. Pas en remplacement des dispositifs de qualification existants — qui restent pertinents pour les contextes où ils s’imposent — mais comme premier niveau, accessible à tous, qui rend lisible l’essentiel et permet une évaluation rapide de la posture d’un déclarant.

Cohabitation terminologique : Profil de souveraineté et déclaration d’engagements#

Le dispositif technique est unique : un seul format sovereignty.json, conforme à un schéma public (sovereignty-v1.json), dont chaque domaine est optionnel individuellement. Le déclarant remplit les domaines pertinents pour son cas. Le manifeste conserve néanmoins deux désignations communicationnelles, parce qu’elles renvoient à des situations éditoriales distinctes :

Profil de souveraineté. Désigne une déclaration qui couvre les sept domaines. Cette désignation est utilisée pour les fournisseurs technologiques — éditeurs de logiciel, hébergeurs, fournisseurs cloud, distributeurs, intégrateurs — qui documentent l’ensemble de leur chaîne. L’inspiration est le Nutri-Score : calcul public, affichage volontaire mais standardisé, et c’est l’opacité de qui ne l’affiche pas qui devient progressivement suspecte.

Déclaration d’engagements. Désigne une déclaration qui ne couvre que le domaine 7 (« engagements et limites assumés »). Cas typiques : une organisation utilisatrice qui formalise sa politique de souveraineté ; une administration qui rend publique sa trajectoire de réduction d’exposition ; un particulier ou une communauté professionnelle qui assume les principes du manifeste ; une entité non-fournisseur qui veut prendre date sur ses choix.

Les deux désignations renvoient au même fichier technique. Côté outillage, côté schéma, côté index public, il n’y a qu’un dispositif. La distinction n’a d’effet que dans la communication : un acheteur qui consulte un Profil sait qu’il aura les sept domaines à lire ; un lecteur qui consulte une déclaration d’engagements sait qu’il y trouvera des intentions et des angles morts assumés, pas l’inventaire complet d’une chaîne technique.

Les conditions d’équivalence pour le propriétaire#

Une part substantielle des solutions logicielles européennes est et restera propriétaire — c’est légitime, et le manifeste le revendique. Mais cette légitimité ne se confond pas avec une garantie de souveraineté. Là où l’open source garantit structurellement la continuité d’usage (le code est public, la défaillance de l’éditeur n’empêche ni l’utilisation, ni le fork, ni l’auto-hébergement), le propriétaire ne peut s’appuyer sur cette structure. Il doit donc démontrer contractuellement ce que le libre offre structurellement.

Sept mécanismes établis permettent cette démonstration. Ils sont cumulables, et un éditeur propriétaire sérieux en combine plusieurs.

Mais ils ne se valent pas. La réversibilité est la priorité incontournable — particulièrement pour les modèles où le client confie son workload au fournisseur (SaaS, et plus encore PaaS). Sans réversibilité opérationnellement testée, les six autres mécanismes deviennent théoriques : le séquestre donne accès à un code qu’on ne peut pas exécuter ailleurs, le préavis n’est qu’un délai avant l’inéluctable, la continuité opérationnelle suppose qu’un repreneur puisse exploiter ce que le client ne peut pas reprendre lui-même, le droit d’audit ne change pas la dépendance, les statuts anti-rachat protègent l’avenir capitalistique sans assurer la sortie technique, et la release-on-trigger ne libère un code utilisable que si la cible d’exécution reste disponible. La réversibilité est ce qui rend les autres mécanismes opérables — c’est elle qui doit être conçue, contractualisée et testée en premier.

1. Clause de réversibilité standard — la condition incontournable. Selon le modèle de service, la réversibilité prend deux formes complémentaires.

— Pour les solutions SaaS (l’éditeur opère le service ; le client lui confie ses données) : le contrat comporte une clause d’export complet des données dans des formats ouverts documentés, avec scripts de migration testés et délai d’export contractuel (cf. fiche pub-009). L’enjeu est la portabilité des données.

— Pour les solutions PaaS (le fournisseur opère la plateforme ; le client y déploie son code) : le contrat garantit la portabilité applicative — packaging au format OCI standard, manifestes de déploiement portables vers des cibles diverses, services managés détachables avec procédure d’auto-hébergement documentée et testée, délai contractuel de relocalisation chiffré, démonstration publique périodique d’une migration réussie (cf. fiche pub-014). La cible privilégiée est le self-hosted via Docker Compose — accessible, exécutable sur un VPS standard sans cluster ni orchestrateur lourd à maintenir ; les autres options (autre PaaS conforme, Kubernetes managé ou auto-hébergé) restent ouvertes mais ne sont pas prescrites, Kubernetes étant lui-même un projet à gouvernance américaine sans alternative européenne établie — en faire le seul plan B reproduirait, au niveau de l’orchestrateur, la dépendance qu’on cherche à briser au niveau du PaaS. L’enjeu est la portabilité du workload applicatif, plus profonde et structurellement plus difficile que celle des seules données. C’est sur le PaaS que le coût d’une réversibilité non préparée est le plus lourd : si elle n’a pas été conçue dès l’origine, elle peut s’avérer impossible après.

La réversibilité ne se résume pas à la licence — elle se prouve par les outils, les formats et le temps imparti, dans le langage opérationnel propre à chaque modèle.

2. Séquestre logiciel. Le code source actualisé de la solution est déposé chez un tiers de confiance européen — notaire spécialisé, séquestre légal, fondation. Un contrat tripartite (éditeur, séquestre, clients) définit précisément les circonstances de libération du code aux clients : ouverture de procédure collective avec liquidation, cessation officielle annoncée, rachat finalisé par une entité hors UE. L’actualisation périodique du séquestre (typiquement trimestrielle) est essentielle à sa valeur protectrice.

3. Engagement public de release. À défaut ou en complément du séquestre, l’éditeur publie un engagement explicite — mécanisme dit release-on-trigger — à libérer le code source sous licence libre dans des circonstances déclenchantes nommées, avec un délai documenté (typiquement 30 à 90 jours après l’événement). L’engagement précise la licence applicable (par exemple AGPL v3) et le dépôt public où le code sera publié.

4. Préavis contractuel minimum. Avant tout arrêt de support, bascule unilatérale ou modification substantielle du service, l’éditeur s’engage par contrat à un préavis minimum (typiquement 6 à 12 mois). Cela donne au client le temps de migrer, de re-contracter ou de mobiliser son séquestre.

5. Engagement de continuité opérationnelle. En cas de cessation, un dispositif est prévu : transfert organisé de la relation client à un repreneur identifié, ou fonds de garantie sectoriel, ou accord de reprise mutuelle entre confrères. L’éditeur ne se contente pas de promettre un export — il prépare une trajectoire d’exploitation continue.

6. Clauses statutaires de protection. Pour les fournisseurs d’intérêt stratégique, des dispositions statutaires limitent les rachats hors UE : pacte d’actionnaires, droits de préemption pour des investisseurs européens, golden share publique, action spécifique à droits de blocage. Le domaine 6 du Profil les déclare explicitement.

7. Droit d’audit du code source. Pour les clients dont le contrat le justifie — publics sensibles, infrastructures critiques, exigence souveraine forte — l’éditeur ouvre un droit d’audit du code source sous accord de confidentialité. Ce n’est pas une publication, mais une vérification possible par des yeux indépendants choisis par le client.

La thèse n’est pas que le propriétaire est interdit. Elle est que sans ces conditions explicitement déclarées, l’éditeur propriétaire ne peut prétendre à la même garantie de souveraineté qu’un éditeur open source. Le domaine 5 du Profil est l’endroit où chacune de ces conditions se déclare précisément ; le domaine 6 couvre le capital ; le domaine 7 explicite les angles morts qui subsistent. Chaque mécanisme dispose d’une ou plusieurs fiches d’engagement opérationnelles dans le dispositif (pub-009 et pub-014 pour la réversibilité, déclinée respectivement en SaaS et PaaS — la priorité ; pub-005 pour le couple séquestre + release ; pub-010, pub-011, pub-012 et pub-013 pour les conditions 4 à 7).

Un caveat sectoriel important. Le manifeste pose la lisibilité de la chaîne comme principe — pas la publication universelle du code source. Pour certains secteurs — défense, infrastructures critiques, énergie, santé, finance, administrations sensibles —, la publication open source du code peut elle-même constituer un risque actif. L’IA agentique permet désormais à un attaquant équipé de scanner silencieusement des millions de lignes, identifier des failles non triviales, et les exploiter sans alerter, sans contribuer de patch, sans responsible disclosure — l’opposé d’un cas comme Copy Fail (CVE-2026-31431) où la divulgation a été responsable, et qui est instructif précisément parce qu’il aurait pu rester silencieux. Dans ces contextes, le propriétaire assorti de mécanismes contractuels solides — réversibilité testée d’abord, droit d’audit ciblé ensuite, séquestre en filet — peut offrir un meilleur profil souverain qu’une publication open source qui exposerait la surface d’attaque sans contrepartie défensive proportionnée. Le dispositif Profil ne tranche pas pour le déclarant ; il rend visible le choix et les conditions de son équivalence souveraine.

Une page d’orientation dédiée s’adresse directement aux éditeurs propriétaires et aux startups européennes : Pour les éditeurs propriétaires européens — formulation condensée des sept mécanismes (avec la réversibilité en priorité), caveat sectoriel développé, et trajectoire spécifique pour les projets en amorçage.

Quatre profils de fournisseurs#

La souveraineté technologique ne se joue pas qu’au niveau de l’éditeur de logiciel. Elle se joue sur toute la chaîne : qui édite, qui héberge, qui exploite, qui distribue. Le dispositif couvre quatre catégories de fournisseurs, chacune avec ses questions spécifiques.

Catégorie A — Éditeur de logiciel#

Profil type : produit logiciel à installer ou en SaaS, avec dépendances tierces dans le code, équipe de développement propre. Exemples : un éditeur français de progiciel métier, un éditeur d’une solution open source européenne avec entité commerciale, un fournisseur de SaaS européen.

Les questions clés portent sur les composants tiers du logiciel, la juridiction des fondations open source utilisées, les conditions de continuité en cas de défaillance de l’éditeur, la structure capitalistique.

Catégorie B — Hébergeur, cloud, IaaS-PaaS#

Profil type : infrastructure d’exécution mise à disposition. Le client y déploie ses propres logiciels ou utilise des services managés. Exemples : OVHcloud, Scaleway, Outscale, Infomaniak, Hetzner, mais aussi tout opérateur d’hébergement traditionnel ou hébergeur web.

Les questions clés portent sur la localisation physique des datacenters et la hiérarchie capitalistique, le statut juridique vis-à-vis des lois extraterritoriales, les briques techniques sous-jacentes (OpenStack, VMware, stack hyperscaler revendue), les services managés proposés et leurs dépendances aux éditeurs étrangers, la réversibilité technique.

Catégorie C — MSP, infogéreur, opérateur de services managés#

Profil type : exploite pour le compte de ses clients une infrastructure et/ou des logiciels qu’il n’édite ni n’héberge nécessairement lui-même. Le client lui délègue l’administration courante. Exemples : un MSP qui infogère un parc Microsoft 365 et des serveurs sur AWS pour des PME françaises, un MSP qui exploite des environnements OVHcloud ou Scaleway pour des collectivités locales, un opérateur d’outillage RMM/PSA, un prestataire qui exploite la stack d’un éditeur tiers chez un hébergeur tiers.

Les questions clés portent sur les outils d’administration utilisés (RMM, PSA, monitoring) et leur juridiction, les accès délégués aux infrastructures clientes (qui peut faire quoi, où sont les credentials), la chaîne réelle des sous-traitants techniques derrière la prestation, la capacité du MSP à garantir la continuité de l’exploitation si l’un de ses propres outils ou sous-traitants défaille.

Catégorie D — Distributeur, revendeur, intégrateur#

Profil type : fournit aux clients européens des solutions développées ailleurs. C’est le cœur de la thèse 12 du manifeste, qui pointe le rôle des fournisseurs européens devenus distributeurs de briques étrangères. Exemples : un intégrateur français qui revend du Microsoft 365 sous prestation de service, un fournisseur dit « cloud souverain » qui revend de l’AWS sous marque blanche, un éditeur français qui packagise du logiciel américain avec du support local.

Les questions clés portent sur la part du chiffre d’affaires liée à des produits dont l’éditeur d’origine est non-européen, le contrôle effectif sur la roadmap des solutions distribuées, les garanties contractuelles que le distributeur peut transmettre au-delà de celles de l’éditeur d’origine, les compétences et l’accès au code en cas de défaillance de l’éditeur d’origine.

Cette catégorie est politiquement la plus sensible. Beaucoup d’acteurs français se présentent comme « souverains » alors qu’ils sont distributeurs de solutions américaines avec un contrat de revente. L’auto-déclaration les invite à le dire — ou à choisir le silence, qui devient lui-même un signal. Inversement, un distributeur de briques européennes — un intégrateur qui déploie PostgreSQL, Nextcloud ou un produit Mistral, par exemple — relève techniquement de la même catégorie sans incarner le syndrome ; le Profil rend cette distinction lisible plutôt que de la masquer derrière un même mot.

Le principe : l’auto-déclaration publique structurée#

Quel que soit son profil, le déclarant publie sur son propre domaine, à un emplacement standardisé, le fichier sovereignty.json. Il n’y a pas de validation préalable, pas de tiers de confiance qui « tamponne », pas de coût d’adhésion. La rigueur du dispositif tient à quatre principes.

D’abord, la publication publique structurée. Le document est visible par tous, dans un format standardisé qui permet la comparaison entre déclarants. Mentir publiquement dans un document structuré expose le déclarant à un démontage public par ses clients, ses concurrents, des journalistes ou des chercheurs.

Ensuite, la mise à jour annuelle datée. Une déclaration figée perd sa valeur. Un déclarant qui ne met pas à jour son fichier signale l’absence d’engagement réel. Le dispositif matérialise cette exigence par une vérification automatique quotidienne : une URL canonique qui cesse de répondre est marquée comme telle pendant trente jours, puis retirée automatiquement de l’index si elle n’a pas été restaurée.

Puis, la possibilité de contestation. Toute partie disposant d’éléments factuels peut contester une déclaration. Une procédure publique structurée — espace de signalement et de discussion ouvert — est en cours de mise en place ; en attendant, les signalements argumentés se font par mail (contact [at] sovereignty-gap.eu). Les contestations étayées peuvent conduire à un retrait manuel de l’indexation, tracé dans l’historique public.

Enfin, la transparence sur les angles morts. Un déclarant qui assume publiquement ses faiblesses devient plus crédible que celui qui prétend tout maîtriser. Le format encourage explicitement cette honnêteté ; le domaine 7 lui est entièrement consacré.

Inspirations du modèle#

Le dispositif emprunte à trois précédents éprouvés.

Le Nutri-Score. Le calcul est public, l’affichage est volontaire mais standardisé, et c’est l’opacité de qui ne l’affiche pas qui devient progressivement suspecte. La pression vient du marché et de la transparence, pas d’une autorité de contrôle lourde. Le manifeste reprend ce principe avec une différence importante : aucune note synthétique n’est calculée. La lisibilité tient à la structure du fichier, pas à un score agrégé.

Le SBOM (Software Bill of Materials). La liste structurée des composants logiciels d’un produit est devenue obligatoire aux États-Unis pour les fournisseurs fédéraux par décret de mai 2021. Les formats ouverts existants (SPDX, CycloneDX) permettent une production largement automatisée, ce qui réduit le coût de conformité. Le domaine 1 du dispositif s’inscrit dans cette filiation et se compose volontiers d’un SBOM publié en parallèle.

Les déclarations type Have I Been Pwned. Les opérateurs y sont jugés sur leur transparence et leur réactivité face aux incidents, pas sur l’absence d’incidents — une posture plus honnête et plus utile que la prétention au zéro défaut. Le domaine 7 du dispositif s’inspire de cette logique : déclarer ce qu’on ne maîtrise pas est plus crédible que prétendre tout maîtriser.

Les sept domaines#

Le fichier couvre sept domaines. Les questions de chaque domaine s’adaptent à la catégorie du déclarant. Pour chacun, le déclarant répond avec le niveau de précision qu’il juge approprié — sachant que les réponses vagues ou évasives constituent en elles-mêmes un signal pour les acheteurs.

Une fiche pédagogique détaillée est publiée pour chaque domaine — ce qu’il couvre, pourquoi il compte, ce qui est attendu par catégorie de déclarant, comment le remplir. L’ensemble est consultable et partageable depuis le catalogue public des sept domaines.

Domaine 1 — Composants tiers stratégiques#

Pour un éditeur : liste des composants logiciels tiers (open source ou propriétaires) dont la solution dépend de manière non substituable, c’est-à-dire dont l’absence ferait perdre une fonctionnalité critique du produit.

Pour un hébergeur ou fournisseur cloud : liste des briques techniques sous-jacentes de l’infrastructure (hyperviseur, orchestrateur, base de données managée, services de stockage, etc.) et des éditeurs ou fondations dont ces briques relèvent.

Pour un distributeur ou intégrateur : liste des solutions distribuées dont l’éditeur d’origine est non-européen, avec part de chiffre d’affaires associée et nature de l’accord de distribution.

Pour chaque composant identifié, quelle que soit la catégorie : nom et version, type de licence, pays ou juridiction de l’éditeur ou de la fondation de gouvernance, caractère essentiel ou périphérique. L’objectif n’est pas l’exhaustivité technique — les dépendances transitives d’un projet peuvent se compter en centaines. Ce qui compte, c’est la liste des composants stratégiquement déterminants.

→ Fiche pédagogique du domaine 1

Domaine 2 — Plans de contournement#

Pour un éditeur : pour chaque composant tiers stratégique, existe-t-il une solution de remplacement identifiée en cas d’arrêt, de bascule de licence, ou de blocage juridictionnel ? Quelle estimation du temps et du coût de migration ? Cette migration a-t-elle été testée concrètement ?

Pour un hébergeur : que se passe-t-il si un composant central de la stack devient indisponible (par exemple : VMware racheté et licencié de manière restrictive, comme cela s’est produit en 2024) ? Quel plan de bascule vers une alternative ? Quel impact sur les clients ?

Pour un distributeur : que se passe-t-il si l’éditeur d’origine d’une solution distribuée modifie unilatéralement les conditions, augmente massivement les prix, ou cesse de servir le marché européen ? Quelle alternative pour les clients ? Le distributeur a-t-il les compétences pour assurer la continuité ?

Une réponse honnête « pas de solution identifiée à ce jour » vaut mieux qu’une fausse rassurance.

→ Fiche pédagogique du domaine 2

Domaine 3 — Dépendances de chaîne d’approvisionnement#

Liste des services tiers indispensables au fonctionnement du produit ou service : forge où le code est hébergé (GitHub, GitLab, Codeberg, autre), registre de paquets utilisé pour les dépendances (npm, PyPI, Maven Central, autre), registre de conteneurs (Docker Hub, registres privés, autre), CDN utilisés, services d’authentification tiers, plateformes de CI/CD critiques, services tiers d’infrastructure (DNS, certificats, monitoring).

Pour chacun : juridiction de l’opérateur, impact estimé en cas de coupure, plan de bascule envisagé.

→ Fiche pédagogique du domaine 3

Domaine 4 — Hébergement et données#

Pour un éditeur SaaS, ou pour les recommandations d’hébergement d’une solution on-premise : localisation des serveurs (pays, hébergeur, juridiction effective), trajectoire des données client (transitent-elles ou sont-elles stockées hors UE, dans quels cas, pour quelles finalités), garanties contractuelles sur cette localisation, procédure d’information du client en cas de réquisition extra-européenne.

Pour un hébergeur ou fournisseur cloud : localisation précise des datacenters, hiérarchie capitalistique des sociétés exploitantes, qualifications applicables (HDS, SecNumCloud, ISO 27001, etc.), résistance aux lois extraterritoriales (le CLOUD Act s’applique-t-il ? sur quel fondement l’hébergeur peut-il refuser une réquisition étrangère ?), engagement sur le pays d’exécution effective des données client.

Pour un distributeur : où sont effectivement hébergées les solutions distribuées ? Le distributeur peut-il garantir une localisation européenne, ou seulement transmettre les conditions de l’éditeur d’origine ? En cas de service managé revendu sous marque blanche, qui contrôle effectivement les serveurs ?

→ Fiche pédagogique du domaine 4

Domaine 5 — Continuité en cas de défaillance#

C’est le cœur du dispositif sur les dimensions où la solution propriétaire est intrinsèquement faible.

Pour un éditeur : existe-t-il un mécanisme de séquestre logiciel ? Si oui, chez quel tiers, dans quelle juridiction, avec quelles conditions de libération ? À défaut de séquestre formel, l’éditeur s’engage-t-il à publier le code source sous licence libre dans certaines circonstances précises (faillite, liquidation, arrêt définitif du produit, rachat par une entité hors UE) ? Quel préavis l’éditeur s’engage-t-il à donner avant un arrêt de support ? Existe-t-il une clause de réversibilité standard dans les contrats clients ?

Pour un hébergeur : que se passe-t-il pour les données et workloads des clients en cas de cessation d’activité ? Quel délai de préavis ? Quels outils d’export ? Quels formats interopérables ? Existe-t-il un fonds de garantie ou un dispositif de continuité opéré avec un confrère ?

Pour un distributeur : si le distributeur cesse son activité, quel impact pour les clients qui dépendent de lui pour le support des solutions revendues ? Existe-t-il un transfert possible de la relation client à un autre intégrateur, ou directement à l’éditeur d’origine ?

Les éditeurs open source répondent à ce domaine en précisant la licence des versions actuelles, les conditions de fork, la gouvernance du projet, et les mécanismes en cas de défaillance de l’entité commerciale qui le porte.

→ Fiche pédagogique du domaine 5

Domaine 6 — Gouvernance et capital#

Quelle que soit la catégorie : qui sont les actionnaires principaux à plus de 5 % du capital, quelle est la nationalité des actionnaires de référence, le déclarant est-il soumis à un dispositif de contrôle des investissements étrangers (en France : IEF, en Allemagne : AWG, en Italie : Golden Power), y a-t-il des dispositions statutaires de protection en cas de tentative de rachat hors UE.

Domaine sensible mais essentiel : un fournisseur français racheté demain par un acteur extra-européen change de profil de souveraineté du jour au lendemain, et le contrat client n’offre généralement aucune protection contre cet événement.

→ Fiche pédagogique du domaine 6

Domaine 7 — Engagements et limites assumés#

Le déclarant indique honnêtement :

ce qu’il garantit explicitement, et le niveau de ces garanties (engagement contractuel opposable, déclaration unilatérale publique, simple bonne pratique interne) ;
ce qu’il ne peut pas garantir, et pourquoi ;
les évolutions à venir qui pourraient modifier ce profil dans les douze à vingt-quatre prochains mois (changement de version, migration d’infrastructure, levée de fonds avec investisseurs étrangers en perspective, repositionnement stratégique) ;
les points où le déclarant sait être en faiblesse, et les actions engagées pour s’améliorer.

Ce septième domaine est le plus important politiquement. Il transforme la déclaration d’un exercice de communication en exercice d’honnêteté. Un déclarant qui assume ses faiblesses devient plus crédible que celui qui prétend tout maîtriser. C’est précisément le contraire de la posture marketing habituelle, et c’est ce qui distingue les déclarants sérieux des autres. C’est aussi le seul domaine que remplit, par construction, une organisation utilisatrice non-fournisseur qui souhaite formaliser sa propre trajectoire — d’où la désignation distincte de déclaration d’engagements.

→ Fiche pédagogique du domaine 7

Format technique#

La déclaration prend la forme d’un fichier sovereignty.json conforme à un schéma JSON public et versionné (sovereignty-v1.json). La structure permet la comparaison entre déclarants et l’agrégation par des outils tiers — par exemple, un site qui liste les hébergeurs déclarés selon leur juridiction, ou un observatoire qui suit l’évolution agrégée des angles morts les plus fréquemment déclarés.

Le fichier est publié à une URL canonique publique et stable, indiquée à la notification. L’emplacement recommandé est la racine du domaine du déclarant :

https://[domaine]/sovereignty.json

Ce choix d’emplacement standardisé suit la logique de fichiers comme robots.txt, humans.txt, security.txt. Il permet à des outils automatisés de découvrir les déclarations sans coordination centrale. Lorsque la racine n’est pas accessible (hébergement contraint, déclaration portée par un dépôt git public, sous-domaine dédié), une URL canonique alternative reste valable, à condition d’être publique, stable et indiquée explicitement à la notification.

Le schéma JSON, ses variantes par catégorie de déclarant, et le générateur web associé sont mis à disposition par le manifeste comme commun méthodologique. Le tout est sous licence permettant la réutilisation et la modification.

Le générateur de déclaration#

Pour faciliter la production d’une déclaration et garantir sa conformité au schéma de référence, le manifeste met à disposition un générateur web guidé sur la page /fr/profil/. Le générateur prend la forme d’un parcours en sept étapes successives — déclarant, engagements, domaines, détailler, produits, identité, vérifier — navigables librement via un sommaire latéral cliquable.

Le générateur fonctionne entièrement dans le navigateur. Aucune donnée saisie n’est transmise à un serveur : le brouillon en cours est sauvegardé localement (dans le navigateur du déclarant) et peut être repris d’une session à l’autre. Cette contrainte est essentielle : un déclarant qui formalise ses fragilités ne doit pas avoir à confier ces informations à un tiers, même au manifeste lui-même.

Une déclaration existante peut également être importée dans le générateur, depuis son URL canonique publique ou depuis un fichier .json local, pour la réviser, la mettre à jour ou la dériver.

Le générateur produit un fichier sovereignty.json conforme au schéma sovereignty-v1.json, prêt à être publié à l’URL canonique choisie. Le déclarant choisit les domaines qu’il renseigne ; les domaines vides sont valides. Le format distingue par ailleurs un domaine simplement laissé vide (signifiant : non déclaré à ce stade) d’un domaine explicitement marqué « non applicable », accompagné d’une raison brève — par exemple, un éditeur sans données client n’a pas à renseigner le domaine 4 sur l’hébergement. Cette distinction protège la lisibilité : un blanc n’est pas une assertion. Les champs sont accompagnés de courtes explications inspirées des sept fiches pédagogiques du dispositif, pour aider à formuler des réponses utilisables sans recopier de texte standardisé creux.

Le code du générateur est publié sous licence libre. Tout déclarant peut l’auditer, le forker, en proposer des variantes. La rigueur du dispositif ne dépend pas de la confiance dans le manifeste, mais de la transparence du processus et du format.

Pour comprendre par la lecture avant la rédaction, des exemples annotés couvrent différents cas typiques — voir exemples de Profils.

Notification, challenge et indexation#

Une fois le fichier publié, le déclarant notifie le manifeste depuis /fr/profil/notifier. Cette notification déclenche un challenge dont l’objet est de prouver que celui-ci maîtrise effectivement le domaine — ou le dépôt — sur lequel il publie.

À la notification, le manifeste émet un token unique : une chaîne aléatoire de 32 caractères hexadécimaux, valable sept jours. Le déclarant doit la publier à un endroit que seul un titulaire légitime du domaine ou du dépôt peut atteindre — un enregistrement DNS, un fichier sur le serveur web, un fichier dans le dépôt git. Le manifeste vérifie ensuite cette publication par lui-même : si le token est trouvé, le challenge est passé. C’est le même paradigme que celui utilisé par Let’s Encrypt ou les outils de vérification de propriété de domaine.

Les méthodes proposées dépendent du type de déclarant. Dans les exemples ci-dessous, le token est a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0 (placeholder) et le domaine déclaré est example.eu.

Pour une organisation (entreprise, administration, association, fournisseur), trois méthodes au choix.

Challenge DNS TXT (recommandé) — enregistrement TXT sur le domaine :

sovereignty-gap-challenge.example.eu.  IN TXT  "sovereignty-verify=a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0"

Challenge HTTP racine — fichier hébergé à la racine du domaine :

URL      https://example.eu/sovereignty-challenge.txt
Contenu  a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0

Challenge HTTP .well-known — variante du précédent, pour les hébergements qui ne permettent pas l’écriture à la racine :

URL      https://example.eu/.well-known/sovereignty/challenge.txt
Contenu  a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0

Pour un déclarant individuel (particulier, communauté professionnelle dont la déclaration est hébergée sur une forge git publique).

Challenge git — fichier adjacent à la déclaration dans le dépôt git public, récupéré par requête HTTP brute (raw). Si la déclaration est publiée à https://codeberg.org/exemple/sovereignty/raw/main/sovereignty.json, le fichier de challenge attendu est :

URL      https://codeberg.org/exemple/sovereignty/raw/main/sovereignty-challenge.txt
Contenu  a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0

Le challenge est vérifié automatiquement avant toute action humaine côté modération. Une fois passé, il prouve la maîtrise du domaine ou du dépôt et n’a pas besoin d’être renouvelé. La vérification quotidienne ultérieure ne re-challenge pas — elle contrôle simplement que l’URL canonique répond toujours et que son contenu reste conforme au schéma.

Après la modération (délai indicatif : cinq jours ouvrés), la déclaration apparaît dans l’index public à /fr/profil/index, listée par ordre antéchronologique de mise à jour. L’email fourni à la notification est supprimé immédiatement après modération. Aucune comparaison hiérarchique entre déclarants n’est proposée, et aucune n’est calculable à partir des champs du schéma.

Ce que le dispositif n’est pas#

Pour éviter toute confusion :

Pas un label. Aucun organisme ne tamponne ni ne valide. C’est une déclaration unilatérale du déclarant.
Pas une qualification, pas une certification. Pas d’audit, pas de référentiel à respecter, pas d’accréditation.
Pas une norme contraignante. L’adhésion est volontaire. Aucune sanction ne vient frapper qui ne publie pas.
Pas un classement. Aucun score, aucune note, aucune couleur axiologique. Les déclarations sont indexées, pas hiérarchisées. Aucune note de complétude n’est calculée à partir des domaines remplis ou vides.
Pas un substitut aux dispositifs de qualification existants lorsqu’ils sont pertinents (HDS, SecNumCloud, ISO 27001). C’est un premier niveau de transparence, complémentaire et accessible.

Pour la liste complète des limites assumées du projet — ce que le dispositif ne mesure pas, ne garantit pas, et l’écart entre le manifeste et l’outil — voir Limites assumées du dispositif.

Ce que le dispositif demande aux acheteurs#

Pour que le dispositif ait un effet réel, il doit être pris au sérieux par ceux qui achètent du logiciel et du service :

Demander la déclaration comme prérequis de référencement dans les processus d’achat publics et privés.
Donner une préférence, à équivalence fonctionnelle, aux fournisseurs qui publient leur déclaration sur ceux qui ne la publient pas.
Faire de l’absence de déclaration un signal négatif aussi explicite que sa présence est un signal positif.
Exiger les déclarations de toute la chaîne : éditeur, hébergeur, et intégrateur. Un seul maillon non transparent suffit à compromettre la souveraineté d’ensemble.
Utiliser les déclarations dans les analyses de risque, plutôt que de se contenter des arguments commerciaux des fournisseurs.
Contester publiquement, avec preuves, les déclarations qui se révéleraient trompeuses, et s’attendre à ce que d’autres acteurs en fassent autant.

Le dispositif ne crée pas seul un marché plus souverain. Il nécessite la mobilisation des acheteurs, qui sont les véritables arbitres.

Pour aider à exploiter un Profil côté acheteur, voir le guide de lecture par persona — en particulier la page acheteur.

Un dispositif évolutif#

Le format des sept domaines présenté ici est une proposition de départ. Il est destiné à évoluer collectivement, au rythme de l’apparition de nouveaux risques et des retours d’expérience.

Une procédure publique permet à la communauté de proposer chaque année des améliorations : nouveaux risques identifiés, nouvelles bonnes pratiques constatées, simplifications de questions devenues redondantes. Les évolutions du format sont publiques, datées, et accompagnent les déclarations dans leur version applicable. Le numéro de version du schéma — sovereignty-v1.json aujourd’hui — est inscrit dans chaque fichier publié, ce qui permet aux déclarations existantes de rester lisibles même après une évolution majeure du format.

Le manifeste s’engage à maintenir cette infrastructure collective : schéma de référence, procédure d’évolution, index public des déclarations, procédure de contestation publique. Cette mission n’a pas de coût d’adhésion ; elle est portée par les ressources de l’écosystème.

Comment commencer, en pratique#

Pour un déclarant qui souhaite publier sa première déclaration :

Aller sur /fr/profil/ et lancer le parcours guidé. Choisir, à la première étape, sa catégorie (éditeur, hébergeur/cloud, distributeur/intégrateur, ou organisation utilisatrice qui ne renseigne que le domaine 7). Les étapes et les questions s’adaptent en conséquence.
Remplir les domaines pertinents au fil des étapes successives. Le brouillon est sauvegardé localement et peut être repris à tout moment ; le sommaire latéral permet de naviguer librement entre les étapes. En cas d’incertitude, mieux vaut décrire l’incertitude que prétendre à une certitude qui n’existe pas. Les domaines non pertinents pour le cas d’usage peuvent être laissés vides — aucune note de complétude n’est calculée.
Télécharger le fichier sovereignty.json produit à l’étape Vérifier.
Publier le fichier à l’emplacement standardisé sur le domaine du déclarant, à la racine : https://[votre-domaine]/sovereignty.json.
Notifier le manifeste depuis /fr/profil/notifier, en indiquant l’URL canonique, le nom du déclarant et un email de modération (supprimé après validation).
Choisir et passer le challenge (DNS, HTTP ou git) qui prouve la maîtrise du domaine.
Attendre la modération (délai indicatif : cinq jours ouvrés). À la validation, la déclaration apparaît dans l’index public à /fr/profil/index.
Mettre à jour annuellement, en datant la nouvelle version. La vérification quotidienne s’assure entre-temps que l’URL répond toujours et que son contenu reste conforme au schéma.

Le coût pour le déclarant est essentiellement celui du temps consacré à la rédaction honnête. Aucun frais externe n’est imposé. Aucun audit n’est requis. La rigueur du dispositif tient à la publication publique structurée et à la possibilité pour quiconque de contester avec preuves.

Une voie ouverte à tous#

Cette page s’adresse à tous les acteurs qui constituent la chaîne technologique européenne — éditeurs propriétaires, éditeurs open source, hébergeurs, fournisseurs cloud, intégrateurs, revendeurs — ainsi qu’aux organisations utilisatrices qui souhaitent formaliser publiquement leurs propres engagements.

Le manifeste plaide pour que cette voie soit reconnue, encouragée par les acheteurs publics et privés, et inscrite explicitement dans le programme de souveraineté technologique européenne. Les déclarants qui s’y engagent sont des alliés ; le manifeste les soutient.

Pour les éditeurs propriétaires européens parfois lus à tort comme moins « souverains » que les solutions open source, le dispositif permet de démontrer concrètement leurs garanties sur les dimensions où la licence propriétaire est intrinsèquement faible — réversibilité, continuité —, par des engagements contractuels et des mécanismes de séquestre publiquement déclarés.

Pour les hébergeurs et fournisseurs cloud européens confrontés à la concurrence des hyperscalers américains, le dispositif permet de rendre lisible ce qui les distingue véritablement : juridiction, capital, briques techniques sous-jacentes, engagements de continuité.

Pour les distributeurs et intégrateurs dont l’activité repose en partie ou en totalité sur la revente de solutions étrangères, le dispositif permet de clarifier honnêtement le périmètre de leur valeur ajoutée et leur capacité à assurer la continuité de service au-delà du simple contrat de revente. Ceux qui assument cette transparence se distinguent de ceux qui jouent sur l’ambiguïté entre nationalité de la marque et nationalité de la technologie.

Pour les organisations utilisatrices — administrations, entreprises, associations, communautés professionnelles — qui ne fournissent pas de technologie mais souhaitent prendre date sur leur propre trajectoire de réduction d’exposition, la déclaration d’engagements (domaine 7 seul) offre un cadre lisible, sans jouer la fausse symétrie d’un Profil de fournisseur qui ne leur correspond pas.

Cette page sera enrichie au fil des contributions et des cas concrets. Les fournisseurs et les acheteurs qui souhaitent participer à l’évolution du format, et les organisations utilisatrices qui souhaitent intégrer le dispositif dans leurs processus internes, sont invités à se manifester via la page À propos du site.