Exemples de Profils.

Cet exemple cible une équipe qui publie pour la première fois : poser la pierre, sans surinvestir au premier passage.

Trois choses sont remplies, le reste est honnêtement laissé pour la révision suivante :

• les métadonnées de publication (URL canonique, dates, langue, version du schéma) — sans elles, le Profil n’est pas indexable ;
• deux composants stratégiques au domaine 1 (PostgreSQL, Debian) — pas tous les composants utilisés, ceux qui structurent vraiment l’activité ;
• deux engagements concrets au domaine 7 (publier annuellement, préférer les briques européennes à équivalence technique) — un engagement tenable vaut mieux que dix engagements rhétoriques.

Une limite assumée est ajoutée pour signaler que l’hébergement n’a pas encore été documenté. Mieux vaut nommer ce qui manque que masquer.

Le format n’oblige pas à tout remplir. Un Profil court mais honnête vaut mieux qu’un Profil exhaustif mais flou.

Cet exemple n’est pas un standard — c’est une borne haute qui montre ce que le format peut porter quand l’organisation a fait le travail interne pour le remplir.

Verdana Software est une mid-cap allemande / française fictive. Elle est à la fois éditeur (75 % du chiffre d’affaires) et hébergeur de son propre SaaS (25 %), ce qui lui impose de remplir le domaine 4 sous deux angles : les fournisseurs qu’elle consomme (hosting_providers) et l’infrastructure qu’elle opère en propre (own_infrastructure).

Trois éléments structurent ce Profil :

1. Une chaîne explicite jusqu’aux composants — PostgreSQL, OpenSearch (avec mention de la migration depuis Elasticsearch après le re-licensing AWS / Elastic), Keycloak avec qualification de la gouvernance effective. La grammaire « licence ≠ garantie » du manifeste est tenue : Keycloak est sous fondation neutre mais reconnu comme single-vendor-dominant en pratique.
2. Des mécanismes de continuité contractuels (domaine 5) : séquestre tripartite chez NCC Group France, libération sous AGPL-3.0 en cas de déclenchement, clause de réversibilité, statuts protégeant contre acquisition extra-EU. Cette section incarne les sept mécanismes d’équivalence pour le propriétaire détaillés dans la page équivalence.
3. Des limites assumées plutôt que masquées (domaine 7) : la dépendance Let’s Encrypt n’est pas niée, et l’absence d’évaluation systématique des assistants IA est nommée. Une faiblesse documentée vaut mieux qu’une faiblesse cachée.

Aucun déclarant n’est tenu d’aller à ce niveau de détail dès la première publication. C’est une trajectoire, pas un seuil d’entrée.

Cet exemple illustre l’apport de la version 1.3 du schéma : la racine optionnelle products[] qui permet à un déclarant multi-offres de différencier la lisibilité de chaque produit.

Eurocloud se déclare en tant qu’hébergeur cloud français. Au niveau organisation, les domaines 4, 6, 7 sont remplis pour décrire l’infrastructure et la gouvernance globales. Mais trois produits coexistent et n’ont pas la même chaîne :

• iaas-souverain : surcharge le domaine 4 pour préciser que c’est une stack 100 % opérée en propre, sans dépendance hyperscaler. Une qualification SecNumCloud y est attachée. C’est le produit qui incarne la posture souveraine au sens fort.
• kaas-managed : surcharge le domaine 4 pour assumer un point honnête — l’infrastructure est souveraine, mais l’écosystème Kubernetes lui-même reste sous gouvernance CNCF. Le commentaire reformule cette nuance pour le lecteur. La portabilité applicative est revisitée au domaine 5 pour ce produit.
• dbaas-postgres : surcharge le domaine 5 pour formaliser l’export en dump SQL natif. PostgreSQL comme brique multi-vendor neutre permet de proposer une sortie réelle, pas seulement contractuelle.

Règle de lecture importante : quand un produit redéclare un domaine, ce domaine remplace entièrement celui de l’orga pour ce produit. Pas de fusion fine champ-par-champ — pas de zone d’ambiguïté dans le fichier publié. Si un domaine n’est pas redéclaré au niveau produit, le domaine orga s’applique tel quel.

Cette structure permet à un acheteur DSI de lire le Profil par produit, pas seulement par éditeur, et donc de mesurer l’écart entre une offre IaaS souveraine et une offre KaaS à portabilité conditionnée par l’écosystème Kubernetes.

Le format se décline aussi en déclaration personnelle. Une personne physique — développeuse, mainteneur, chercheuse, dirigeant agissant à titre privé — peut publier un Profil qui engage elle seule, pas son employeur, pas son client, pas la communauté à laquelle elle contribue.

Trois choix structurels distinguent ce cas de figure :

1. declarant.type à individual et individual_details rempli (given_name, family_name, pays, rôle). Le champ affiliated_organization est laissé vide — toute mention contextuelle d’un employeur ne lui transfère aucun engagement.
2. Seul le domaine 7 est rempli. Les domaines 1 à 6 décrivent une infrastructure et un capital qui n’existent pas pour un individu. Le schéma admet explicitement ce cas : un Profil individu prend la forme d’une déclaration d’engagements.
3. Une limite assumée explicite : l’engagement personnel ne lie pas l’employeur. Ce rappel n’a pas d’effet juridique en soi, mais il rend l’asymétrie lisible.

Cette forme est la plus sobre du dispositif. Elle convient à quiconque veut signer publiquement un engagement de souveraineté sans avoir à répondre pour une structure.

Un fonds n’est pas un fournisseur de souveraineté technologique. Il finance des fournisseurs. Le geste-pivot d’un fonds, dans la grammaire du manifeste, n’est donc pas un Profil JSON décrivant son catalogue d’investissements — c’est une thèse publique : critères de sélection, lignes rouges, raisons de refuser un dossier (cf. la fiche d’engagement fund-003).

Ce Profil illustre malgré tout comment un fonds peut publier le sien, à un usage spécifique : documenter que le fonds-organisation lui-même consomme de la technologie, et engager publiquement ses pratiques.

Trois éléments structurent cet exemple :

1. Catégorie unique user. Le fonds ne se déclare pas editor ni host_or_cloud — il n’édite ni n’héberge. Il consomme. Cette honnêteté de catégorisation évite la fausse impression d’un acteur producteur de technologie.
2. Domaines 1 à 5 absents. Pas de chaîne de composants à documenter, pas d’hébergement, pas de mécanisme de continuité au sens du dispositif. Un fonds qui se forçait à les remplir nourrirait la confusion plus qu’il n’éclairerait.
3. Domaine 7 minimal mais ciblé. Trois engagements : publier la thèse, exiger contractuellement la démarche Profil chez les portefeuilles, privilégier les dossiers documentés. Une general_note rappelle que le geste-pivot du fonds est ailleurs — la thèse publique, pas le Profil.

La cohérence du dispositif est respectée : le fonds joue sa partition (la thèse), et ce Profil documente la partie qu’il peut documenter sans confusion de rôle.

Une fondation est structurellement différente d’une société commerciale. Pas de capital cessible, pas d’actionnaires de référence, pas de mécanisme de séquestre nécessaire (le code est déjà publié sous licence libre). Le format Profil reflète cette singularité.

Atlas Foundation e.V. est une fondation allemande fictive qui gouverne un middleware OSS de fédération identitaire. Quatre éléments distinguent ce Profil :

1. organization_type à foundation et categories à ["editor"]. La fondation édite (au sens du manifeste) le projet qu’elle gouverne. Elle n’opère pas de SaaS payant, donc pas de catégorie host_or_cloud.
2. Domaine 5 réécrit en logique fondation : pas de séquestre — le code est déjà sous Apache-2.0. Le mécanisme de continuité est dans les statuts d’e.V. (non-cessibilité, clause d’attribution dévolutive en cas de dissolution) et dans la gouvernance des marques.
3. Domaine 6 sans capital : la chaîne de propriété s’arrête à la fondation elle-même. Aucun bénéficiaire effectif ultime au sens d’une société commerciale. Le conseil est élu par l’assemblée des contributeurs actifs.
4. Domaine 7 cible la gouvernance multi-vendor neutre : un seuil de 40 % de contributions par employeur unique est documenté comme garde-fou. Une limite assumée sur le bus factor (mainteneurs réguliers) est ajoutée — assumer la fragilité plutôt que la masquer.

Cette forme illustre pourquoi le manifeste considère que la fondation est une garantie structurelle, distincte des garanties contractuelles que peut offrir un éditeur propriétaire (cf. la page équivalence). Les deux voies coexistent — le dispositif n’en privilégie aucune.

Le débat public assimile parfois « stack open source » à « stack souveraine ». Cet exemple rappelle, par les faits déclarés, que les deux dimensions sont indépendantes.

Liberopay est une PME française fictive de paiement, agréée ACPR, capital 100 % FR détenu par ses fondateurs et un fonds Bpifrance Participations. Sa stack applicative est entièrement open source — Linux, PostgreSQL, Kubernetes, Redis, Kafka. Tout y est OSS. Et pourtant, la fiche expose explicitement quatre limites de souveraineté technique :

1. Domaine 1 — Composants stratégiques tiers : Kubernetes (CNCF, sous-projet de la Linux Foundation, mutual benefit corp Oregon, 501(c)(6) US) et PostgreSQL (gouvernance distribuée, Core Team auto-coopté, marques détenues par la PostgreSQL Community Association of Canada) sont déclarés comme composants essentiels. Le commentaire précise : « la licence libre garantit le droit de lire et redistribuer le code, pas la gouvernance de la roadmap, l’infrastructure de distribution, ni l’applicabilité du droit extra-territorial ». C’est exactement ce que le précédent du retrait de mainteneurs russes du noyau Linux en octobre 2024 a démontré.

2. Domaine 4 — Hébergement : AWS Frankfurt (eu-central-1) est le seul fournisseur. La fiche déclare honnêtement extraterritorial_law_exposure: yes et précise « CLOUD Act et FISA 702 — applicables même sur les données dans des datacenters européens, par contrainte du droit US imposable à Amazon Web Services Inc. ». Le siège juridique français de Liberopay ne neutralise pas cette exposition.

3. Domaine 5 — Continuité : la fiche ne masque pas la dépendance — software_escrow: no, data_export_in_case_of_termination documenté en SQL natif Postgres + S3 dump, reversibility_clause_in_contracts: yes, mais avec un commentaire honnête : « la portabilité des données est garantie ; la portabilité opérationnelle vers un autre cloud demande 12 à 18 mois compte tenu des intégrations EKS, RDS, S3, IAM ».

4. Domaine 7 — Limites assumées : trois limites sont publiées explicitement, dont la principale : « exposition CLOUD Act non éliminable tant que le cloud est AWS — engagement à publier annuellement le delta de portabilité et à étudier une migration progressive vers un cloud SecNumCloud à horizon 24-36 mois ». La position est défendable parce qu’elle est documentée, pas cachée.

Cette fiche illustre la valeur pédagogique du dispositif : un acheteur qui lit ce profil sait exactement où se situe la souveraineté de Liberopay. Il peut juger, contester, comparer. Liberopay ne prétend pas être ce qu’elle n’est pas. Le manifeste appelle ça assumer la zone grise plutôt que la masquer — et c’est ce que cette fiche fait.

L’inverse de cette posture est documenté dans la fiche secnumcloud-vmware-broadcom : un acteur dont le label SecNumCloud est techniquement valide mais dont la stack sous-jacente expose à une roadmap décidée hors UE. La conclusion est symétrique : les deux profils sont valides, à condition de documenter les écarts.

Le visa SecNumCloud, délivré par l’ANSSI, garantit qu’un fournisseur de cloud opère sous droit français/européen, isole ses opérations critiques, et résiste aux demandes de droit extra-territorial (CLOUD Act, FISA, etc.). C’est un visa juridique et opérationnel. Il ne se prononce pas sur la maîtrise des composants techniques sous-jacents.

Trustcloud Souverain est un opérateur français fictif, qualifié SecNumCloud 3.2 sur ses datacenters de Gravelines et Strasbourg. Sa stack technique repose intégralement sur VMware vSphere/vSAN/NSX — l’offre IaaS historique de la maison VMware, désormais acquise par Broadcom (Inc., Delaware, USA) en novembre 2023. Trois faits documentés depuis l’acquisition :

• Fin des licences perpétuelles depuis janvier 2024 — passage forcé au modèle d’abonnement ;
• Plus de 160 produits annulés et regroupés en quatre bundles d’abonnement ;
• Réduction massive du programme partenaires : les VMware Cloud Service Providers (VCSP) autorisés sont passés de 4 500+ à environ 13 Pinnacle en juillet 2025 (source Redress Compliance).

Ce contexte n’est pas un risque hypothétique — c’est l’état du marché au moment de la publication de cette fiche. Trustcloud Souverain documente cette dépendance honnêtement :

1. Domaine 1 — Composants stratégiques tiers : VMware vSphere/vSAN/NSX déclaré comme essential. Juridiction de gouvernance : USA (Broadcom Inc., Delaware). Le commentaire précise « roadmap et politique de licence dictées par Broadcom — voir limites assumées au domaine 7 ».

2. Domaine 4 — Hébergement : own_infrastructure avec datacenters Gravelines et Strasbourg, qualifications SecNumCloud 3.2 attachées. extraterritorial_law_exposure : no (l’opérateur est de droit français, pas exposé au CLOUD Act). C’est ici que le label tient sa promesse.

3. Domaine 5 — Continuité : data_export_in_case_of_termination documenté (formats portables OVF/OVA pour les VMs, ESXi disk images), reversibility_clause_in_contracts: yes. Mais le commentaire honnête : « la portabilité des VMs est concrète ; la portabilité de l’orchestration et de la couche réseau (NSX) demande un travail substantiel vers KVM/Proxmox/OpenStack. »

4. Domaine 6 — Capital : 100 % FR/EU, statuts inaliénables, droit de veto Bpifrance.

5. Domaine 7 — Limites assumées : la limite principale est exposée explicitement : « roadmap des composants critiques décidée hors UE par Broadcom — visibilité contractuelle limitée à l’horizon des renouvellements d’abonnement. » L’engagement-pivot est l’évaluation d’une migration progressive vers une stack KVM/OpenStack à horizon 36 mois, motivée moins par un rejet du label que par une volonté de récupérer la maîtrise de la roadmap.

La fiche illustre une nuance que le manifeste défend dans la page /equivalence/ : le label ANSSI est nécessaire mais non suffisant pour la souveraineté technique. Un acheteur OIV peut très légitimement choisir Trustcloud pour la conformité réglementaire ; il devra évaluer séparément l’exposition à la roadmap Broadcom — c’est précisément ce que ce profil rend lisible.

Le pendant inverse est documenté dans la fiche fintech-aws-souveraine-en-papier : un acteur juridiquement français mais opérationnellement exposé. Les deux profils sont valides et instructifs parce qu’ils documentent l’écart.

Le PaaS bien conçu offre une excellente expérience développeur — déploiement instantané, observabilité prête à l’emploi, scaling automatique. Il cache aussi une dette de portabilité massive que la plupart des fiches commerciales ne documentent pas. Cet exemple illustre un troisième mouvement, plus rare et plus utile : publier la dette plutôt que la masquer.

Studento est une startup française fictive de SaaS productivité B2B. Son geste-pivot n’est ni le séquestre, ni la migration, ni la qualification SecNumCloud. C’est la mesure publique du coût de réversibilité :

1. Domaine 4 — Hébergement : deux PaaS américains déclarés.

   • Vercel (Vercel Inc., Delaware) — Next.js ISR, Edge Functions, Image Optimization, Analytics. Le commentaire reversibility_strategy cite explicitement OpenNext comme alternative documentée : reproduire l’expérience Vercel hors Vercel demande sept composants AWS (Lambda + S3 + CloudFront + SQS + DynamoDB + Image Optimizer + Revalidator) et la maintenance d’un projet OSS à part. Le proprietary_components_used énumère honnêtement les fonctionnalités sans pendant générique : ISR, Edge Network, Analytics, Visual Editing.
   • Supabase (Supabase Inc., Delaware) — Postgres managé, Auth, Storage, Edge Functions. Plus favorable côté réversibilité : Supabase publie une stack Docker self-hostable officielle. Le commentaire précise « self-hosting possible mais pas iso-fonctionnel : pas de PITR managé, pas de branching, pas de vector buckets ».

2. Domaine 5 — Continuité chiffrée.

   • reversibility_clause_in_contracts: yes — mais le commentaire est explicite : « Vercel ToS §17.1 : préavis de résiliation 2 à 30 jours selon le motif ; §17.3 : destruction mutuelle des données 14 jours post-termination ». Le risque résiduel est nommé.
   • data_export_in_case_of_termination documente les exports Postgres (dump SQL), Auth (JWT public keys, profil utilisateur JSON), Storage (URLs signées, dump objet).
   • general_comment cite le cas 37signals/HEY (sortie AWS, 6 mois, 700 k$ hardware Dell amorti en 1 an, économies 1,9 M$/an, plus de 10 M$ sur 5 ans) comme borne haute documentée d’une migration cloud-out réussie. C’est de la pédagogie par exemple, pas du marketing.

3. Domaine 7 — Limites assumées. Trois limites chiffrées :

   • Migration Vercel → OpenNext : 30 à 40 h-mois ingénieur, sept composants AWS à reproduire.
   • Migration Supabase → self-hosting : 8 à 12 h-mois, sans pendant pour PITR/branching/vector.
   • Préavis Vercel court (2-30 j) + destruction 14 j post-termination — risque résiduel non éliminable.

L’engagement-pivot de Studento est publication trimestrielle de la mesure — un nombre d’h-mois et un nombre de composants à reconstruire, mis à jour avec l’évolution des dépendances. Le format Profil rend cette mesure traçable et comparable d’un trimestre à l’autre.

La fiche illustre la posture défendue par le manifeste : un PaaS US n’est pas illégitime ; le défaut de divulgation l’est. Studento ne prétend pas être souveraine techniquement. Elle publie le diagnostic. Un investisseur impact ou un client B2B peut alors évaluer en connaissance de cause.

Le pendant inverse — un éditeur propriétaire qui produit plus de garanties qu’un OSS hébergé chez un hyperscaler — est documenté dans la fiche editeur-proprio-reversibilite-forte.

Le manifeste défend une équivalence : propriétaire bien engagé et fondation OSS bien gouvernée peuvent toutes deux produire de la souveraineté, par des chemins différents. Cet exemple illustre la première voie — un éditeur sous licence propriétaire qui assemble quatre garanties concrètes qui, ensemble, dépassent le niveau de réversibilité d’un OSS hébergé chez un hyperscaler.

Erpium est un éditeur français fictif d’ERP industriel pour PMI/ETI manufacturières. Capital 100 % FR détenu par les fondateurs et un fonds Bpifrance Participations. Code source non public, licence commerciale annuelle. Et pourtant, quatre éléments structurent un niveau de réversibilité assumé :

1. Séquestre logiciel européen — domaine 5.

   • software_escrow: yes
   • software_escrow_provider: CELOG (acteur français de référence du séquestre logiciel, basé à Paris)
   • software_escrow_jurisdiction: France
   • release_conditions documente cinq déclencheurs publics et auditables : faillite/redressement judiciaire, arrêt de support officiel >12 mois sans alternative communiquée, cession non-EU sans accord client, refus de fournir un correctif de sécurité critique sous 90 jours, abandon du produit annoncé sans plan de migration.
   • Le séquestre est vérifié annuellement — le client peut demander un constat d’huissier.

2. Engagement open-source-on-trigger — domaine 5.

   • open_source_release_commitment: yes
   • target_license: Apache-2.0
   • release_circumstances: les mêmes déclencheurs que le séquestre, garantis contractuellement par une clause d’irrévocabilité dans les CGV B2B (pas une simple lettre d’intention).
   • C’est cette clause qui distingue Erpium d’un éditeur propriétaire classique : si l’un des cinq déclencheurs s’active, le code passe sous Apache-2.0 et la communauté Erpium peut prendre le relais.

3. Formats d’export documentés et portables — domaine 5.

   • export_formats: dump SQL natif PostgreSQL (la base est déjà Postgres en sous-jacent — choix structurant), JSON Schema des API REST, fichiers documentaires en formats ouverts (PDF/A, ODF), export XBRL pour le module financier.
   • data_export_in_case_of_termination documenté : 90 jours d’accès gratuit, 24 mois de conservation des sauvegardes, accompagnement migration documenté.

4. Clauses contractuelles de réversibilité — domaine 5 et 7.

   • reversibility_clause_in_contracts: yes — clause CGV B2B standard, 6 mois d’accompagnement gratuit post-résiliation, accès aux backups pendant 24 mois.
   • support_termination_notice_months: 36 — préavis de fin de support garanti à 36 mois (pas 30 jours comme certains PaaS).

Au domaine 6, la gouvernance capital est verrouillée FR/EU : statuts inaliénables sur cinq ans, droit de veto Bpifrance, clause statutaire de préemption. Au domaine 7, le geste-pivot est l’engagement de publier annuellement le constat d’huissier de vérification du séquestre — preuve continue, pas promesse.

L’argument du dispositif : la licence libre garantit le droit de lire le code ; elle ne garantit pas la pérennité du runtime, ni l’export des données, ni la portabilité contractuelle. Un éditeur propriétaire bien engagé peut produire ces trois garanties, vérifiables en pratique, là où un OSS hébergé chez un hyperscaler les présume sans les contracter. Les deux voies coexistent — le manifeste n’en privilégie aucune. Cette fiche documente la voie propriétaire bien faite, en contrepoint nécessaire de la fiche fondation-oss.

Pour aller plus loin sur cette équivalence, voir la page /equivalence/ du dispositif.