Pour les éditeurs propriétaires européens#

Vous éditez du logiciel propriétaire en Europe. Vous opérez un SaaS, ou vous démarrez un projet ambitieux qui ne sera pas open source. La question vous a peut-être été posée — par un client, un partenaire, un journaliste, ou par vous-même : votre modèle est-il compatible avec l’exigence de souveraineté technologique européenne portée par le manifeste ? Cette page répond. Le manifeste ne vous demande pas d’ouvrir votre code. Il vous demande, comme à tout fournisseur, de rendre lisible votre chaîne — et, sur les dimensions où la licence propriétaire est intrinsèquement faible, de démontrer contractuellement ce que l’open source offre structurellement.

La position du dispositif#

Le manifeste ne pousse pas vers le libre. Il ne pousse pas non plus vers le propriétaire. Il pousse vers la lisibilité de la chaîne, quel que soit le modèle.

C’est une distinction qui change tout. Le mot « souverain » a longtemps servi de marqueur de positionnement : un produit était présenté comme tel au seul titre que son éditeur était européen, ou que son code était libre. Le dispositif refuse ce raccourci. Comme le pose la thèse 3 du manifeste, « la licence, ouverte ou fermée, est un attribut juridique du logiciel — pas une garantie de souveraineté ». La souveraineté est un attribut de la chaîne entière — capital, juridiction, hébergement, continuité, dépendances, gouvernance —, pas du seul logiciel.

L’axe 4 du manifeste l’écrit explicitement : « le Profil ne distingue pas l’open source du propriétaire : il distingue les fournisseurs qui rendent leur chaîne lisible de ceux qui la masquent ». Vous êtes donc invité à publier un Profil de souveraineté au même titre qu’un éditeur open source. Ni au-dessus, ni en-dessous. À une condition : que ce que l’open source offre par défaut, vous le formuliez par contrat.

Pourquoi la nuance structurel / contractuel change tout#

Quand un client achète une solution open source publiée sous une licence permissive ou copyleft, plusieurs garanties lui viennent par construction :

• Le code source est public — il peut l’auditer, l’archiver, ou le faire auditer.
• Si l’éditeur disparaît, le code reste exploitable — il peut être forké, maintenu par une communauté, ou auto-hébergé.
• L’usage du logiciel ne dépend pas, à long terme, de la survie d’une entité commerciale unique.

Ces garanties sont structurelles : elles découlent du modèle, pas d’un effort contractuel. L’éditeur open source les obtient sans rien faire de spécial — sa licence les porte.

Quand un client achète une solution propriétaire, ces garanties n’existent pas par défaut. Si l’éditeur ferme, le code disparaît. S’il bascule unilatéralement de licence, de tarification, ou de stratégie, le client n’a souvent aucun recours opérationnel rapide. La protection doit être fabriquée, ajoutée, négociée — par contrat. C’est cela, le travail propre de l’éditeur propriétaire qui veut exister dans l’écosystème souverain : produire contractuellement ce que la licence libre produit structurellement.

Ce n’est pas une infériorité. C’est un coût d’entrée plus élevé, qui se paye une fois, et qui à terme distingue les éditeurs sérieux des autres.

Quand la transparence devient un risque — le caveat sectoriel#

Le manifeste pose la lisibilité de la chaîne comme principe — pas la publication universelle du code source. La distinction est essentielle pour certains secteurs : défense, infrastructures critiques, énergie, santé, finance, administrations sensibles. Dans ces contextes, la publication open source du code peut elle-même constituer un risque actif — pas par sécurité par l’obscurité (chimère), mais par asymétrie de capacité défensive et offensive à l’ère de l’IA.

L’IA agentique permet désormais à un attaquant équipé de scanner silencieusement des millions de lignes de code source, d’identifier des failles non triviales, et de les exploiter — sans alerter, sans contribuer de patch, sans responsible disclosure. C’est l’opposé du cas Copy Fail (CVE-2026-31431) où Theori/Xint a divulgué responsablement une faille kernel découverte par IA défensive ; ce qui rend Copy Fail instructif est précisément qu’il aurait pu rester silencieux.

Pour les secteurs cités, le calcul classique de la « loi de Linus » — given enough eyeballs, all bugs are shallow — est partiellement inversé : les « yeux » incluent désormais des agents d’IA en mode offensif silencieux, dont la diligence excède celle des défenseurs humains équipés d’outils équivalents mais moins motivés économiquement. 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, dans ces contextes, offrir un meilleur profil souverain qu’une publication open source qui exposerait la surface d’attaque sans contrepartie défensive proportionnée.

Cette nuance ne disqualifie pas l’open source dans ces secteurs ; elle exige que la posture défensive associée — financement de mainteneurs équipés en IA défensive, programme de bug bounties à la hauteur des nouvelles capacités offensives, audit IA mobilisé en mode défensif — soit à la mesure de l’asymétrie. Le dispositif Profil ne tranche pas pour le déclarant : il rend visible le choix et les conditions de son équivalence souveraine.

Les sept mécanismes contractuels — la réversibilité d’abord#

Le dispositif retient sept mécanismes établis qui, cumulés, démontrent l’équivalence à laquelle l’open source accède par défaut. Aucun seul ne suffit ; les éditeurs propriétaires sérieux en combinent 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 vous donne accès à un code que vous ne pouvez 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 vous ne pouvez pas reprendre vous-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 ;
• 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.

1. Clause de réversibilité standard — la condition incontournable#

Selon le modèle de service, la réversibilité prend deux formes opérationnelles distinctes.

SaaS — clause d’export complet des données dans des formats ouverts documentés, avec scripts de migration testés en conditions réelles et délai d’export contractuel plafonné. L’enjeu est la portabilité des données.

PaaS — 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émonstration publique périodique d’une migration réussie. La cible privilégiée est le self-hosted via Docker Compose — accessible et soutenable sans cluster lourd à maintenir. L’enjeu est la portabilité du workload applicatif, plus profonde 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.

→ pub-009 — Clause de réversibilité (SaaS) · pub-014 — Portabilité applicative (PaaS)

2. Séquestre logiciel chez un tiers de confiance européen#

Le code source actualisé est déposé chez un notaire spécialisé, un séquestre légal ou une fondation européenne. 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 dépôt — typiquement trimestrielle — est ce qui fait sa valeur protectrice.

→ pub-005 — Établir un séquestre logiciel

3. Engagement public de release#

À défaut ou en complément du séquestre, l’éditeur publie un engagement explicite (release-on-trigger) à libérer son code sous licence libre dans des circonstances déclenchantes nommées : faillite, liquidation, arrêt définitif du produit, rachat hors UE. L’engagement précise la licence applicable (par exemple AGPL v3) et le dépôt public où le code sera publié, ainsi qu’un délai documenté (typiquement 30 à 90 jours après l’événement).

→ pub-005 — Établir un séquestre logiciel (engagements de release inclus)

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. Un préavis contractuel court ou absent vide en pratique tous les autres engagements.

→ pub-010 — Préavis contractuel minimum

5. Engagement de continuité opérationnelle#

En cas de cessation, un dispositif est prévu avant qu’elle ne survienne : transfert organisé de la relation client à un repreneur identifié, 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 pour le client, qui ne dépend pas de la bonne volonté du jour de la liquidation.

→ pub-011 — Continuité opérationnelle

6. Clauses statutaires anti-rachat hors UE#

Pour les fournisseurs d’intérêt stratégique : pacte d’actionnaires interdisant la cession à une entité extra-européenne sans approbation, 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. Ce mécanisme est ce qui distingue, sur le long terme, un éditeur souverain d’un éditeur souverain en attente d’offre de rachat.

→ pub-012 — Statuts anti-rachat

7. Droit d’audit du code source sous accord de confidentialité#

Pour les clients dont le contrat le justifie — administrations 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. C’est l’équivalent contractuel ciblé de ce que l’open source offre par défaut à tous.

→ pub-013 — Droit d’audit du code source

Une forme spécifique pour les startups#

Si vous démarrez un projet logiciel qui sera commercialisé en propriétaire, vous n’avez probablement pas encore de séquestre, pas de clause statutaire d’anti-rachat, pas de fonds de continuité sectoriel — et c’est normal. La question pour vous n’est pas « avez-vous tout, dès maintenant ? », mais « quels engagements assumez-vous publiquement aujourd’hui, et lesquels prendrez-vous quand l’échelle le permettra ? »

Voici ce qu’une startup peut crédiblement assumer dès l’amorçage, et qui peut figurer dans une première déclaration honnête :

• Réversibilité by design. Concevoir vos formats et votre architecture pour que l’export soit possible dès le premier client. Cela coûte moins à 5 clients qu’à 5 000.
• Choix des dépendances. Tracer dès le départ la juridiction de vos composants tiers stratégiques. Privilégier, à équivalence fonctionnelle, les briques sous gouvernance européenne. Domaine 1 du Profil.
• Hébergement européen documenté. Quel datacenter, quelle juridiction effective, quel statut vis-à-vis du CLOUD Act. Domaine 4.
• Intentions statutaires. Vous n’avez peut-être pas encore négocié votre première levée. Posez par écrit — dans des domaines 6 et 7 honnêtes — ce que vous accepterez et ce que vous refuserez : préemption européenne au pacte d’actionnaires, golden share publique éventuelle, refus du board control par un investisseur extra-européen.
• Limites assumées. Le domaine 7 (« engagements et limites assumés ») accueille naturellement les « nous ne pouvons pas encore mais voici la trajectoire ». C’est le contraire d’un point de faiblesse — c’est un signal d’honnêteté.

Le bénéfice est stratégique : prendre date publiquement avant de devoir négocier sous contrainte avec investisseurs étrangers, clients exigeants, ou journalistes méfiants. Une déclaration publique vaut plus, à 18 mois, qu’une intention privée.

Ce que vous publiez#

Le Profil de souveraineté est un fichier sovereignty.json que vous publiez à la racine de votre domaine — https://votre-domaine.eu/sovereignty.json. Le format est public, le schéma est versionné, aucun coût d’adhésion n’est dû.

Le dispositif :

• ne note pas votre déclaration ;
• n’audite pas son contenu ;
• n’attribue pas de label ;
• rend lisible ce que vous assumez et ce que vous laissez en blanc.

Vous remplissez les sept domaines pertinents pour votre cas. Un domaine peut être laissé vide (signifiant : non déclaré à ce stade) ou marqué non applicable avec une raison brève — les deux états sont distincts. Le générateur web vous accompagne ; rien n’est transmis à un serveur tiers, le brouillon est sauvegardé dans votre navigateur.

À la notification, vous passez un challenge léger (DNS TXT, fichier HTTP, ou git public) qui prouve que vous contrôlez bien le domaine. Une fois validée, votre déclaration apparaît dans l’index public, listée par ordre antéchronologique de mise à jour — sans classement, sans note, sans hiérarchie.

Pour aller plus loin#

• Manifeste — la nuance fondamentale entre licence et souveraineté est posée à la thèse 3 et opérationnalisée à l’axe 4. Une version condensée existe : manifeste court (~5 min de lecture) ; la version complète est ici : manifeste.
• Philosophie du dispositif — la formalisation longue des sept mécanismes, dans le contexte des quatre catégories de fournisseurs et de l’auto-déclaration publique : conditions d’équivalence pour le propriétaire.
• À quoi ressemble un Profil — des exemples annotés couvrent différents cas typiques : exemples de Profils.
• Limites assumées — ce que le dispositif ne mesure pas, ne garantit pas, et l’écart entre le manifeste et l’outil : limites assumées du dispositif.
• Questions fréquentes — foire aux questions.