Cette FAQ accompagne le manifeste « La souveraineté n’est pas une licence — Manifeste pour une autonomie technologique européenne réelle ». Elle est rédigée pour répondre aussi bien aux personnes qui découvrent le sujet qu’à celles qui souhaitent débattre des thèses. Les réponses renvoient aux annexes documentaires lorsque la question demande des éléments factuels précis.
I. Comprendre le projet#
De quoi parle ce manifeste ?#
Le manifeste porte sur un constat simple : on peut être totalement open source et totalement dépendant. La souveraineté technologique d’une organisation ne se réduit pas à la licence du code qu’elle utilise. Elle dépend aussi de qui héberge ce code, qui en contrôle la chaîne de distribution, qui en finance la maintenance, à quelle juridiction est soumise sa coordination, et qui peut en changer les règles. Le manifeste documente cette confusion entre liberté juridique du code et autonomie réelle, et propose un programme positif en quatre axes : investir dans la maintenance des fondations ouvertes, bâtir l’infrastructure européenne de la chaîne, mesurer la souveraineté réelle, garantir la continuité par la transparence. Voir Limites assumées pour comprendre lequel de ces axes le dispositif opérationnalise effectivement aujourd’hui.
Pourquoi maintenant ?#
Plusieurs faits récents convergent et créent un moment où le sujet ne peut plus être éludé. Les bascules de licence d’éditeurs majeurs (Hashicorp, Redis, Elastic, MongoDB) ont rappelé que les licences libres permissives sont révocables pour les versions futures. Le retrait par la Linux Foundation de mainteneurs russes en octobre 2024 a montré qu’une fondation américaine applique la politique étrangère américaine, même quand l’obligation juridique stricte est contestée. La fragilité du supply chain open source a été rendue visible par les cas XZ Utils, IngressNightmare, Heartbleed, Log4Shell. Et l’arrivée d’agents d’intelligence artificielle capables d’auditer le code à grande échelle modifie l’équation historique entre défenseurs et attaquants. L’ensemble de ces faits donne au manifeste une matière empirique qu’il n’aurait pas eue il y a cinq ans.
À qui s’adresse-t-il ?#
À trois publics complémentaires : les DSI et RSSI européens qui doivent évaluer leur dépendance technologique réelle ; les éditeurs et fournisseurs de services européens qui veulent positionner leur offre sur l’axe souveraineté sans naviguer à vue ; les décideurs publics et législateurs qui doivent arbitrer entre soutien aux industriels nationaux, normalisation européenne et investissement dans les communs numériques. Au-delà, le manifeste s’adresse à toute personne qui s’intéresse aux conditions concrètes d’une autonomie technologique européenne réelle.
Quel est votre lien avec l’open source ?#
Nous sommes des praticiens de l’open source, pas des adversaires. Plusieurs des signataires utilisent, contribuent à, et maintiennent des projets libres depuis des années. Le manifeste n’est pas anti-open source : il est anti-confusion. La confusion entre licence libre et souveraineté arrange les acteurs dominants — qui peuvent prétendre au label « open source » tout en concentrant la gouvernance, la propriété intellectuelle, et le contrôle de la chaîne de distribution. Lever cette confusion sert le mouvement libre plutôt qu’il ne le dessert.
À quoi sert vraiment la souveraineté technologique ? N’est-ce pas un débat d’experts ?#
Non. La souveraineté technologique n’est pas une fin en soi, et ce n’est pas un débat technique réservé aux experts. Elle est l’instrument d’un droit fondamental : la garantie pour toute organisation — entreprise, administration, particulier — de pouvoir continuer à exploiter ses données et à mener ses opérations quels que soient les événements.
Considérez ce qui peut interrompre l’usage d’un système d’information aujourd’hui : la défaillance commerciale d’un fournisseur clé, un conflit géopolitique qui entraîne des sanctions, une bascule unilatérale de licence, le rachat d’un partenaire de confiance par une puissance étrangère, une réquisition extraterritoriale qui contraint un fournisseur à coopérer avec une justice non européenne, une simple coupure de service. Dans chacun de ces cas, ce qui est en jeu n’est pas un débat sur l’open source ou sur les licences. C’est la capacité concrète d’une organisation à accéder à ses données — qui sont, pour la plupart, sa seule véritable valeur stratégique.
Le RGPD a posé en droit que les données personnelles appartiennent à ceux qui les produisent. Le Data Act a étendu ce principe aux données industrielles. La souveraineté technologique est ce qui permet de transformer ce droit en réalité opérationnelle. Sans elle, la propriété formelle des données ne suffit pas à garantir leur usage effectif quand les circonstances changent.
C’est pourquoi le manifeste s’adresse au-delà des seuls experts. Il s’adresse à toute organisation qui dépend de logiciels et de services pour exister — c’est-à-dire aujourd’hui, pratiquement, à toutes.
II. Réponses aux objections#
Vous attaquez l’open source, alors qu’il est notre meilleur allié ?#
Au contraire. Notre thèse est que l’open source est nécessaire mais pas suffisant. Une licence libre est une condition pour la souveraineté ; elle n’en est pas la garantie. Un projet open source peut être contrôlé par un acteur unique qui en change la licence du jour au lendemain pour les versions futures (cas Hashicorp). Il peut être hébergé dans une infrastructure soumise à une juridiction étrangère qui décide qui peut y contribuer (cas Linux Foundation 2024). Il peut dépendre d’une chaîne de distribution monopolistique américaine (cas npm, GitHub, PyPI). Reconnaître ces limites n’est pas critiquer l’open source — c’est lui rendre service en distinguant la liberté juridique du code de la maîtrise stratégique de son écosystème.
Vous prônez un protectionnisme européen ?#
Non. Nous prônons une autonomie stratégique, ce qui n’est pas la même chose. Le protectionnisme consiste à fermer des marchés. L’autonomie stratégique consiste à se donner les moyens de faire des choix indépendants, y compris le choix d’utiliser des technologies non européennes lorsque c’est pertinent. Le manifeste ne demande pas l’exclusion des solutions américaines ou chinoises ; il demande qu’on cesse de prendre la licence open source pour une autonomie qu’elle ne procure pas, et qu’on construise les capacités européennes manquantes. Un acteur autonome peut choisir la dépendance ; un acteur dépendant ne peut pas choisir l’autonomie.
Sans les Américains, l’Europe n’a rien. Vous ignorez ce fait ?#
Nous le posons explicitement. La famille 5 des annexes (« contre-exemples positifs ») reconnaît honnêtement l’asymétrie d’échelle : le Sovereign Tech Fund allemand distribue 17 millions d’euros par an, à comparer aux dizaines de milliards investis dans l’écosystème américain. Codeberg accueille environ 117 000 projets, contre plus de 100 millions sur GitHub. Notre thèse n’est pas qu’une autonomie complète existe déjà ; c’est qu’elle est techniquement, juridiquement, économiquement possible et qu’il faut décider de la construire. Le programme positif du manifeste prend acte de l’asymétrie actuelle et propose les leviers pour la corriger.
L’IRN (Indice de Résilience Numérique) existe déjà. À quoi sert un nouveau manifeste ?#
L’IRN, lancé en janvier 2026 par Bercy avec l’association aDRI, est un référentiel d’évaluation par labellisation. Il joue un rôle utile dans le dispositif français. Notre manifeste ne le concurrence pas : il vise un objectif différent. L’IRN évalue des produits ou services individuellement ; le manifeste pose une analyse politique et structurelle de la souveraineté open source à l’échelle européenne. L’IRN est un instrument ; le manifeste est une thèse. Les deux peuvent coexister et se compléter — le manifeste fournit le cadre intellectuel, l’IRN un outil d’évaluation parmi d’autres possibles.
N’est-ce pas surinterpréter le retrait des mainteneurs russes par la Linux Foundation en 2024 ?#
Le mainteneur Felipe Contreras et la Software Freedom Conservancy ont publiquement contesté la nécessité juridique stricte de cette décision : approuver un patch n’est pas évidemment une « transaction » au sens des sanctions américaines, et la portée exacte de l’OFAC sur des contributions non rémunérées reste juridiquement ouverte. Nous reprenons cette nuance dans nos annexes. Mais l’objection en question manque le cœur de notre argument. Que la décision ait été juridiquement obligatoire ou seulement défensive, son effet pratique est le même : une fondation américaine a exclu des contributeurs étrangers sur la base d’arbitrages issus de la politique étrangère de Washington. Pour la souveraineté technologique, la posture juridique de prudence d’une entité américaine produit les mêmes conséquences que l’obligation formelle. C’est précisément ce caractère structurel — qui dépasse la question de l’obligation stricte — qui justifie le manifeste.
Les bascules de licence ne révoquent pas les versions déjà publiées. Vous exagérez le risque ?#
Vous avez raison sur le point juridique : les versions publiées sous licence libre restent libres pour toujours. Personne ne peut révoquer rétroactivement la GPL ou la BSD sur du code déjà distribué. Nous le précisons explicitement dans nos annexes. Mais cette précision technique ne console pas pratiquement : un utilisateur figé sur une version libre obsolète perd progressivement les correctifs de sécurité, les nouvelles fonctionnalités et les patchs de compatibilité. La liberté juridique sur le code passé devient inutile lorsqu’on doit utiliser le code présent. C’est ce que nous appelons le caractère « révocable pour les versions futures » de la licence libre — non pas une révocation rétroactive, mais une révocation de fait pour quiconque veut rester à jour.
Vous présentez Project Mythos comme un événement structurant. N’est-ce pas céder à un coup de communication d’Anthropic ?#
C’est une critique légitime, et nous l’intégrons explicitement dans nos annexes. Une partie de la communauté sécurité — notamment l’analyse publiée par Tom’s Hardware — considère que les revendications d’Anthropic relèvent en grande partie d’un argument commercial, et que les capacités annoncées s’appuient sur 198 revues manuelles dont l’indépendance complète n’a pas encore été validée. Nous reproduisons ces objections. Surtout, nous précisons que même si Mythos était surévalué, la thèse 9 du manifeste reste valide pour des raisons antérieures à cet événement : la fragilité documentée du supply chain open source (XZ, Heartbleed, Log4Shell, IngressNightmare) suffit à établir l’asymétrie défensive entre attaquants et défenseurs. Notre argument ne dépend pas d’un seul événement récent.
Pourquoi cibler Hashicorp, Redis, Elastic et pas d’autres exemples ?#
Parce que ces cas sont les plus documentés, les plus récents, les plus pédagogiques pour illustrer les mécanismes que nous décrivons. Nous aurions pu inclure d’autres exemples (Cockroach Labs, Sentry, Akka). Le choix vise la clarté, pas l’exhaustivité. Les annexes documentaires totalisent une trentaine de cas et couvrent sept familles de mécanismes différents. Toute personne qui souhaite ajouter ou contester un cas peut nous contacter — le manifeste est un point de départ, pas un texte clos.
Qu’est-ce qui est plus souverain : une brique open source à gouvernance étrangère, ou une brique propriétaire française ?#
C’est probablement la question la plus importante que pose le manifeste, et elle mérite une réponse précise plutôt qu’un slogan. La réponse honnête est : cela dépend de quelle propriété de la souveraineté on privilégie.
La souveraineté n’est pas une propriété simple. C’est un faisceau de propriétés qui peuvent se renforcer ou s’opposer : indépendance juridictionnelle (ne pas être soumis à une politique étrangère), auditabilité (savoir ce que fait réellement le code), réversibilité (pouvoir changer de fournisseur sans réécrire ses applications), continuité (pouvoir utiliser le logiciel dans dix ans), maîtrise économique (ne pas subir les prix d’un acteur dominant), contribution à un commun (enrichir un patrimoine partagé), adéquation aux normes européennes (intégrer nativement RGPD, NIS2, DORA, AI Act).
Sur certaines de ces propriétés, la brique propriétaire française est plus souveraine : indépendance juridictionnelle (soumise au droit français et européen, pas au CLOUD Act ni à l’OFAC), adéquation native aux normes européennes (l’éditeur étant lui-même européen, il les intègre par construction). Sur d’autres, la brique open source est plus souveraine : auditabilité (le code est lisible), réversibilité (le code est forkable en droit), contribution à un commun. Sur d’autres encore, le résultat est nuancé : la maîtrise économique dépend autant de politiques actives que de la nature open source ou propriétaire du logiciel ; un éditeur français peut être prédateur sur ses prix, un service managé open source peut verrouiller ses utilisateurs aussi efficacement qu’un produit propriétaire.
Mais surtout, la question oppose deux options là où il en existe quatre :
- Propriétaire à gouvernance étrangère (la grande majorité du marché B2B mondial)
- Propriétaire à gouvernance européenne (Cegid, Sage, BlueMind, Dassault Systèmes, certaines briques industrielles allemandes)
- Open source à gouvernance étrangère (la majorité de l’écosystème CNCF, Apache Software Foundation, Linux Foundation)
- Open source à gouvernance européenne (PostgreSQL, Odoo, Forgejo/Codeberg, Eclipse Foundation depuis 2021, projets soutenus par NLnet et le Sovereign Tech Fund)
La vraie hiérarchie de souveraineté est : 4 > 2 et 3 selon les propriétés qui priment > 1. Le piège stratégique européen est de ne penser qu’à l’opposition open source / propriétaire, qui occulte la vraie variable discriminante : la gouvernance, le financement, le contrôle.
C’est exactement la thèse du manifeste. La licence ne suffit pas. Ce qui compte, c’est qui contrôle, qui finance, qui décide. Cette question se pose autant pour les solutions propriétaires que pour les solutions open source. Une brique propriétaire française dont la gouvernance reste française et dont le financement est européen peut être un choix de souveraineté pleinement légitime, parfois supérieur à un projet open source dont la fondation est américaine. Notre programme positif appelle à investir simultanément dans les communs numériques européens, dans des structures juridiques européennes, et dans la mesure différenciée des dimensions de souveraineté — sans préjuger de la nature open source ou propriétaire des solutions, qui est seconde par rapport à la maîtrise effective.
Comment un fournisseur — éditeur, hébergeur ou distributeur — peut-il rassurer ses clients sur les dimensions de souveraineté ?#
C’est la question complémentaire de la précédente, et elle commande l’axe 4 du programme positif (« Garantir »). La souveraineté ne se joue pas qu’au niveau de l’éditeur de logiciel : elle se joue sur toute la chaîne, du code à l’hébergement et à la distribution. Un éditeur français propriétaire dont le produit est hébergé sur AWS, ou un fournisseur dit « cloud souverain » qui revend en réalité de l’infrastructure américaine sous marque blanche, ne peut pas prétendre à la souveraineté quel que soit son discours marketing. Symétriquement, un éditeur qui assume publiquement ses dépendances et offre des garanties contractuelles précises devient un acteur crédible de l’autonomie technologique.
Plutôt que de proposer une réglementation lourde qui n’enrichirait que les cabinets d’audit et exclurait les petits acteurs européens, nous proposons un instrument simple : le Profil de souveraineté. Le fournisseur publie, sur son propre site, à un emplacement standardisé (/sovereignty.json), un fichier qui répond à un nombre limité de questions concrètes — composants tiers stratégiques, plans de contournement, dépendances de chaîne d’approvisionnement, hébergement des données, continuité, gouvernance et capital, engagements et limites assumés. Cette déclaration est librement vérifiable, contestable publiquement avec preuves, et mise à jour annuellement.
Le format s’inspire du Nutri-Score (calcul public, affichage volontaire, l’opacité de qui ne le publie pas devient suspecte) et du SBOM (Software Bill of Materials, devenu standard aux États-Unis pour les fournisseurs fédéraux). Pas de label, pas de certificateur, pas de coût d’adhésion. La rigueur tient à la publication structurée et à la possibilité pour quiconque de contester avec preuves.
Pour faciliter la production d’un Profil, le site met à disposition un générateur web à la page /fr/profil/ qui fonctionne entièrement dans le navigateur. Aucune donnée saisie ne transite vers un serveur. Le fournisseur télécharge son fichier sovereignty.json en local et le publie lui-même sur son site. Le code du générateur est sous licence libre, auditable et forkable.
La page /fr/profil/a-propos détaille ce dispositif et explique les sept domaines couverts. Les fournisseurs qui adhèrent à cette démarche se distinguent visiblement des autres, sans pour autant subir une procédure coûteuse — ce qui est précisément l’enjeu, surtout pour les TPE et PME éditrices européennes.
En quoi les profils individuels servent-ils un intérêt collectif ?#
C’est une dimension essentielle du dispositif et qui est souvent mal comprise. Les profils de souveraineté ne sont pas seulement utiles à l’acheteur qui consulte celui de son fournisseur — ils sont aussi, agrégés, un instrument d’observation collective de la dépendance technologique européenne.
Quand cinquante éditeurs déclarent dépendre de la même brique américaine sans alternative testée, ce n’est plus un risque individuel — c’est un signal stratégique majeur. Une lacune identifiable, mesurable, qui justifie un investissement public ou un consortium privé pour développer une alternative européenne. Quand un type de service entier (par exemple les bases de données analytiques managées, ou les outils de CI/CD) ne dispose d’aucune alternative européenne crédible, l’agrégation des déclarations le rend visible.
Le manifeste s’engage à publier et maintenir un observatoire des lacunes, alimenté par l’agrégation des déclarations indexées et par l’analyse qualitative des sources publiques disponibles. Cet observatoire ne juge pas les fournisseurs individuellement ; il rend visibles les concentrations de dépendances, les briques sans alternative, les couches stratégiques sous-investies. Il est conçu comme un outil de prévention des risques pour les DSI et un outil d’aide à la décision pour les pouvoirs publics et les investisseurs.
L’index public à /fr/profil/index présente l’état actuel des déclarations indexées, par ordre antéchronologique de mise à jour, sans note ni classement.
Comment cet outil aide-t-il concrètement à prévenir les risques ?#
Le dispositif Profil de souveraineté + observatoire des lacunes sert à plusieurs niveaux de prévention.
Pour une DSI ou un RSSI, il permet d’évaluer en amont la véritable exposition de son organisation aux événements perturbateurs. Plutôt que d’attendre qu’un fournisseur change ses conditions ou disparaisse, on peut consulter son profil, identifier les dépendances critiques, et anticiper les plans de migration nécessaires. C’est un outil d’analyse de risque concret et lisible, qui complète sans la remplacer la cartographie SI traditionnelle.
Pour un acheteur public ou privé, il permet de comparer objectivement plusieurs fournisseurs sur la dimension souveraineté, et d’éviter de choisir une solution qui semble « française » sur l’enseigne mais qui, à l’examen, repose entièrement sur une chaîne de dépendances étrangères. La transparence sur la chaîne complète prévient le faux confort des achats apparemment souverains.
Pour un fournisseur lui-même, l’exercice de production du profil est un audit interne salutaire. Beaucoup d’éditeurs découvrent à cette occasion des dépendances critiques qu’ils n’avaient pas mesurées, ou des fragilités contractuelles qu’ils peuvent corriger avant qu’elles deviennent des crises.
Pour un investisseur ou un décideur public, l’observatoire agrégé permet d’identifier les zones où l’investissement aurait le plus d’impact — celles où l’absence d’alternative européenne crée un risque collectif documenté.
L’objectif est simple : transformer la souveraineté technologique en une dimension mesurable et anticipable, plutôt qu’un sujet qu’on ne traite qu’après qu’une crise est survenue.
Vous critiquez la concentration des contributions Linux et Chromium, mais ne sont-ce pas les conséquences naturelles de qui fait le travail ?#
Cette objection est valide sur le plan descriptif et nous la mentionnons dans nos annexes. Un économiste libéral peut légitimement répondre : « Google contribue à 94 % de Chromium parce que personne d’autre ne le fait, ce n’est pas une capture mais un effet du marché ». Notre réponse n’est pas de contester ce constat. Elle est d’en tirer une conclusion politique : si les Européens veulent influer sur les standards technologiques mondiaux, ils doivent y consacrer la masse contributive qui n’existe pas aujourd’hui. La concentration n’est pas un complot, c’est un état des lieux. Le manifeste n’accuse personne ; il invite à transformer cet état.
Le manifeste est trop long, trop technique, trop français.#
Le manifeste fait environ 1 500 mots, ce qui est court pour un texte qui veut éviter la simplification politique. Les annexes documentaires sont longues parce que nous voulons que chaque affirmation soit vérifiable. Sur la dimension française : le texte est rédigé en français mais son référentiel est explicitement européen, et une version anglaise est en préparation. Sur la technicité : nous avons fait le pari qu’un manifeste sérieux sur la souveraineté technologique ne peut pas faire l’économie d’une certaine technicité, sous peine de tomber dans l’incantation. Ceux qui jugent le texte trop technique sont précisément ceux que les acteurs dominants peuvent continuer à instrumentaliser par la confusion entre licence libre et souveraineté.
III. Méthodologie et rigueur#
Comment avez-vous vérifié les faits cités ?#
Chaque cas documenté dans les annexes a été vérifié contre des sources de première main : communiqués officiels des entités concernées, rapports techniques (CVE, audits de sécurité), publications académiques, et couverture par des médias techniques de référence. Les sources sont systématiquement liées en fin de fiche. Lorsqu’un fait n’a pas pu être confirmé directement, nous le signalons par une formulation prudente plutôt que par une affirmation catégorique. Le dossier compte plus de cent sources de première main.
Que faites-vous des cas où votre argument peut sembler faible ?#
Nous les signalons. Plusieurs préfaces dans les annexes documentent honnêtement les limites de notre démonstration : asymétrie d’échelle entre les contre-exemples européens et les écosystèmes américains qu’ils prétendent remplacer (famille 5), caractère récent d’événements comme Project Mythos dont la portée structurelle ne sera connue qu’avec quelques mois de recul (famille 7), nuances juridiques sur la portée des sanctions américaines applicables aux fondations open source (famille 2). Un manifeste qui reconnaît ses propres limites argumentatives est plus solide qu’un manifeste qui les masque.
Voir Limites assumées du dispositif pour la liste consolidée des limites argumentatives reconnues, des suppositions du dispositif, et de l’écart entre le manifeste et l’outil.
Allez-vous mettre à jour le manifeste si de nouveaux faits émergent ?#
Oui. Le manifeste est versionné publiquement. Chaque modification substantielle est documentée. Si des faits postérieurs à la publication invalident une thèse ou une analyse, nous le notons et nous corrigeons. Si une analyse alternative documentée change notre lecture d’un cas, nous l’intégrons. Le manifeste est un point de départ pour un débat, pas un texte sacré. Notre engagement n’est pas envers les conclusions actuelles mais envers la rigueur de la démarche.
Acceptez-vous les critiques publiques ?#
Pleinement. Toute personne qui souhaite contester un fait, une analyse ou une thèse peut nous contacter — par email, par publication publique, par contribution sur les outils de discussion ouverts que nous mettrons en place. Les critiques argumentées seront citées et, lorsque c’est justifié, intégrées dans les versions ultérieures. Les critiques qui relèvent de la mauvaise foi ou de l’attaque personnelle ne recevront pas de réponse publique.
IV. Pratique#
Qui porte ce manifeste ?#
À ce stade, le manifeste est porté individuellement par Nicolas Martinez, via NIM-HQ (SAS française) — voir les mentions légales pour les coordonnées effectives. Ce portage est explicitement transitoire : une structuration collective (association, AISBL, fondation, ou collectif éditorial) sera arbitrée quand la dynamique de déclarants la justifiera. La posture est assumée — un porteur unique avant d’étendre, plutôt que prétendre à une légitimité collective qui n’existe pas encore. Voir aussi Limites assumées.
Comment puis-je publier ma déclaration ?#
Le geste central proposé par le manifeste est de publier sa déclaration plutôt que de signer un texte. Vous rédigez votre déclaration via le générateur public à /fr/profil/, qui fonctionne intégralement dans votre navigateur — aucune donnée saisie ne transite par un serveur. Vous obtenez un fichier sovereignty.json que vous hébergez vous-même sur votre propre domaine, à une URL stable. Vous notifiez ensuite le manifeste depuis la même page. Une équipe de modération vérifie que l’URL répond, que le JSON est conforme et que le déclarant est bien le titulaire du domaine (challenge DNS, HTTP ou git), puis inscrit la déclaration dans l’index public à /fr/profil/index.
Qu’est-ce qu’un Profil de souveraineté ?#
C’est la désignation communicationnelle utilisée pour les fournisseurs technologiques (éditeurs, hébergeurs, distributeurs) qui remplissent l’ensemble des sept domaines de la déclaration : composants tiers stratégiques, plans de contournement, dépendances de chaîne d’approvisionnement, hébergement et données, continuité en cas de défaillance, gouvernance et capital, engagements et limites assumés. Le format technique sous-jacent est sovereignty.json. Un Profil de souveraineté permet à un acheteur — DSI, RSSI, responsable des achats — d’évaluer rapidement la posture d’un fournisseur sans passer par un audit lourd.
Qu’est-ce qu’une déclaration d’engagements ?#
C’est la désignation communicationnelle utilisée pour les déclarants qui ne remplissent que le domaine 7 — engagements et limites assumés — sans documenter l’ensemble de la chaîne technique. Cas typiques : une organisation utilisatrice qui assume publiquement les principes du manifeste sans être elle-même fournisseur ; un particulier qui rend publics ses engagements professionnels ; une administration qui formalise sa politique. Le format technique est exactement le même que pour le Profil de souveraineté : un seul fichier sovereignty.json. Seule la couverture des domaines diffère.
Comment ma déclaration est-elle vérifiée ?#
À la notification, le manifeste effectue trois contrôles : l’URL canonique répond, le JSON valide contre le schéma sovereignty-v1, et le déclarant prouve qu’il maîtrise le domaine via un mécanisme de challenge au choix : enregistrement DNS TXT, fichier HTTP à une URL standardisée, ou tag git signé sur un dépôt public. Une fois ces contrôles passés, l’équipe de modération examine la soumission selon des critères publics (pas de duplication, pas d’usurpation, pas de contenu hors-sujet ou illégal) puis valide ou refuse. Une vérification automatique quotidienne contrôle ensuite que l’URL canonique répond toujours et que son contenu reste conforme ; une déclaration devenue inaccessible est marquée comme telle pendant trente jours, puis retirée si elle n’a pas été restaurée.
Que devient mon email ?#
Vous fournissez un email de modération uniquement pour permettre à l’équipe de vous contacter en cas de demande de correction. Cet email est supprimé immédiatement à la validation, de manière non contournable. La date de suppression est tracée par un horodatage emailDeletedAt. Aucun email n’est conservé après la validation. Aucun emailing n’est envoyé. Aucun cookie de tracking, aucun analytics tiers, aucun transfert hors UE. La page RGPD détaille la politique complète.
Comment contribuer au-delà de la déclaration ?#
Plusieurs voies sont possibles. Vous pouvez relayer le manifeste dans votre réseau professionnel et académique. Vous pouvez nous signaler des cas documentés que nous aurions oubliés ou des erreurs factuelles. Vous pouvez proposer une traduction dans votre langue. Vous pouvez contribuer à l’instanciation opérationnelle de la thèse 10 du manifeste — la mesure de la souveraineté est précisément ce que le Profil et l’index public construisent. Pour toutes ces contributions, contactez-nous via la page À propos.
Comment soutenir financièrement le projet ?#
Aucun canal de don n’est ouvert à ce stade, par choix. Le manifeste préfère structurer un cadre collectif (cf. la question précédente sur le portage) avant d’ouvrir un canal financier — ouvrir une cagnotte sans structure pour la recevoir serait incohérent avec la grammaire de transparence du dispositif. Le soutien le plus utile aujourd’hui est de publier votre déclaration de souveraineté, de relayer le manifeste dans votre réseau, et de signaler des cas documentés que nous aurions oubliés.