Ce document s'affiche mieux au format PDF — Télécharger le PDF

Gouvernance souveraine de l'IA à l'échelle communautaire

Note d'orientation de l'UE

Comment les organisations communautaires et les petites entreprises peuvent-elles respecter les obligations de la loi sur l'IA sans déléguer le contrôle à leur fournisseur ?

Auteur — John Stroh, directeur, My Digital Sovereignty Limited, Nouvelle-Zélande ORCID — 0009-0005-2933-7170 DOI — 10.5281/zenodo.19635598 Document parent — Équité distributive par la structure : un exemple concret à l'échelle communautaire de la pérennité des valeurs (v1.0, 16/04/2026). DOI : 10.5281/zenodo.19600614. Version — 0.1 (publiée le 18 avril 2026) Licence — Creative Commons Attribution 4.0 International (CC BY 4.0) Auteur correspondant — john.stroh@mysovereignty.digital Également disponible en — allemand (https://agenticgovernance.digital/whitepapers/eu-policy-brief-de)

Résumé

La plupart des organisations communautaires de l’UE se conformeront à la loi sur l’IA en acceptant les paramètres par défaut de leur fournisseur actuel. Le fournisseur détermine le modèle, la politique de traitement des données et l’acheminement juridictionnel de chaque requête. L’organisation communautaire hérite de tout cela en signant un formulaire de passation de marché. Il ne s’agit pas de conformité, mais de délégation.

Une alternative est déjà en cours de développement. La plateforme Village — construite autour d’une architecture constitutionnelle à trois niveaux qui ancre les valeurs communautaires dans le code de la plateforme, et d’une couche linguistique contextualisée entraînée sur le matériel autorisé de la communauté — offre, en tout ou en partie, une solution à de nombreux cas où la délégation au fournisseur échoue. Ce document présente les trois mécanismes, les met en correspondance avec le dispositif réglementaire européen auquel ils se rattachent, et décrit les critères d’audit structurel qu’une communauté ou une entreprise adoptante peut appliquer pour elle-même avant d’intégrer un module.

La boîte à outils The Village s’inscrit dans un contexte autre que celui de l’UE. Elle a été conçue dans le cadre des obligations découlant Te Tiriti o Waitangi (le Traité de Waitangi de 1840) envers les communautés Māori de Nouvelle-Zélande — où la souveraineté des données est un engagement constitutionnel entre la Couronne et iwi (tribus), et non une simple préférence réglementaire. Pour répondre à cette contrainte, il fallait une architecture où les valeurs sont ancrées dans le code, et non dans un texte marketing ; cette même architecture répond aux obligations auxquelles sont soumises les organisations de l’UE en vertu de la loi sur l’IA, du RGPD et de l’EMFA. La boîte à outils comporte trois mécanismes :

  1. La couche linguistique située (SLL). Un modèle linguistique à l'échelle de la communauté, formé sur des données autorisées par la communauté, qui préserve la souveraineté locale du vocabulaire des langues minoritaires et de la gouvernance communautaire plutôt que de l'intégrer dans un corpus mondial.
  2. Agents gardiens. Contrôles de gouvernance en temps réel qui évaluent chaque réponse de l'IA par rapport aux valeurs déclarées par la communauté avant que la réponse n'atteigne un utilisateur. Le respect des valeurs est garanti par le code, et non par des documents de politique.
  3. Fédération. Accords bilatéraux entre des plateformes communautaires souveraines leur permettant de se connecter — pour le covoiturage, les annonces intercommunautaires, les appels vidéo — sans céder ni données, ni identité des utilisateurs, ni autorité de gouvernance à un intermédiaire central.

Chaque mécanisme correspond à un élément réglementaire de l’UE : les articles 2 et 50 de la loi sur l’IA (champ d’application et transparence) ; la loi européenne sur la liberté des médias (pluralisme des médias en langues minoritaires) ; l’article 9 du RGPD (catégories particulières de données, qui s’étend sans doute aux données culturelles en langues minoritaires). Le Tractatus Framework (la couche de gouvernance sur laquelle reposent les mécanismes) est open source sous licence Apache 2.0 et accessible au public sur Codeberg ; le code source de la plateforme Village est actuellement propriétaire, certains modules spécifiques étant à l'étude pour une publication en open source, sous réserve du processus de gouvernance décrit au §7. La production s'effectue sur une infrastructure relevant de la souveraineté de l'UE (OVH France) et sur une infrastructure relevant de la souveraineté de la Nouvelle-Zélande (Catalyst Cloud), sans aucune dépendance vis-à-vis des États-Unis dans le chemin de requête.

Le propos de cette note n’est pas de prétendre que les communautés linguistiques minoritaires de l’UE devraient adopter en bloc la boîte à outils néo-zélandaise. L’argument est plus restreint : une communauté ou une entreprise spécifique — galloise, sami, basque, sorabe, frisonne, catalane, bretonne, ou d’ailleurs tout organe de gouvernance, organisation nationale affiliée disposant de sections locales, association professionnelle, fédération sportive, groupe communautaire ou club, petite entreprise, coopérative, réseau de conservation ou d’anciens élèves, réseau paroissial ou diaspora transfrontalière — pourrait adopter un module spécifique, dans un cadre juridique adapté à sa propre juridiction. La souveraineté linguistique des minorités est le cas de figure principal car elle implique les obligations de responsabilité les plus strictes ; la même boîte à outils répond aux cas plus simples. La discussion que cette note vise à ouvrir porte sur le choix du module, de la communauté et du cadre juridique.

1 — Ce qui a été mis en place, et pourquoi

My Digital Sovereignty Ltd (Nouvelle-Zélande) exploite Village: une plateforme basée sur des modèles pour la gouvernance à l'échelle communautaire. Une base de code unique s’adapte — via le vocabulaire, les fonctionnalités et les paramètres de gouvernance par défaut — au mode de vie spécifique de toute communauté ou organisation dans des limites raisonnables : les organes de gouvernance et leurs comités ; les organisations affiliées au niveau national avec des sections locales (associations professionnelles, organismes professionnels, fédérations sportives, confessions religieuses, syndicats, organisations caritatives nationales) ; les groupes communautaires et les clubs (les Vereine qui forment une couche si dense de la vie civique allemande s’y intègrent naturellement) ; petites entreprises ; coopératives ; réseaux de conservation et d’anciens élèves ; réseaux paroissiaux ; services de covoiturage ; sites communautaires whānau (famille élargieMāori ) — entre autres. Lorsqu’une même communauté comprend des groupes de travail fonctionnellement différents, la fédération (§2.3) gère la séparation : chaque groupe exploite sa propre instance souveraine et s’accorde bilatéralement sur ce qu’il convient de partager entre les instances. La bibliothèque de modèles s’enrichit à mesure que de nouveaux types de communautés s’engagent ; il ne s’agit pas d’un catalogue figé.

La plateforme existe parce que deux pressions ont convergé. La première est une pression en matière de souveraineté : les communautés Māori, faisant valoir leurs droits en vertu Te Tiriti o Waitangi et des principes énoncés dans le rapport WAI 262 du Tribunal de Waitangi et les Principes CARE pour la gouvernance des données autochtones, exigent que leurs données restent sous leur propre autorité, régies selon leurs propres tikanga (protocoles coutumiers), sur une infrastructure sur laquelle elles peuvent exercer un véritable contrôle. La seconde est une pression technique : la pile d’IA standard achemine chaque requête via une infrastructure détenue par un petit nombre de sociétés américaines, transforme les données de chaque communauté en données d’entraînement pour ces sociétés, et importe la juridiction américaine (en particulier le CLOUD Act) dans chaque communauté de l’UE ou de Nouvelle-Zélande qui signe le formulaire de passation de marché.

Village répond à la première pression par sa conception et à la seconde par son déploiement. La plateforme est fédérée par défaut (chaque communauté est sa propre entité juridictionnelle), isolée par locataire (aucun accès aux données entre communautés n’est possible, y compris par l’opérateur de la plateforme), et effectue des inférences sur une couche linguistique située (Situated Language Layer) entraînée sur des données ancrées en Nouvelle-Zélande. Aucune entreprise américaine n’intervient dans le chemin de la requête.

Des instances de locataires de production sont aujourd’hui en service à la fois sur OVH France et Catalyst Cloud New Zealand, couvrant des organes de gouvernance, des organismes d’adhésion, des réseaux paroissiaux, des comités, des sites communautaires whānau (famille élargieMāori ) et d’autres configurations issues de la bibliothèque de modèles. Une collection distincte d’instances de démonstration, clairement identifiées comme telles, est également hébergée sur la même infrastructure afin que tout lecteur puisse consulter un exemple concret de chaque configuration. Le premier covoiturage fédéré entre plusieurs villes néo-zélandaises est décrit comme un exemple concret au §2.3. Le reste de cette note décrit chaque mécanisme, la réglementation européenne à laquelle il répond et les critères d’audit qu’un adoptant peut vérifier par lui-même.

2 — Les trois mécanismes

2.1 La couche linguistique située (SLL)

Une couche linguistique située est un modèle linguistique à l'échelle d'une communauté. Son corpus d'entraînement est déterminé par la communauté ; son inférence s'effectue sur une infrastructure que la communauté peut auditer ; ses résultats servent les définitions de la communauté en matière d'usage linguistique acceptable plutôt que la moyenne statistique d'un corpus mondial.

Dans le déploiement Village, la SLL de base est entraînée sur des données ancrées en Nouvelle-Zélande : le vocabulaire te reo Māori (la langue Māori ), l’anglais néo-zélandais, les travaux universitaires Te Tiriti o Waitangi et des documents relatifs à la gouvernance communautaire dont l’utilisation à des fins d’entraînement a été autorisée par les communautés qui en sont propriétaires. Des spécialisations propres à chaque communauté viennent s’ajouter : un SLL épiscopal a des paramètres par défaut différents en matière de textes sacrés et de gouvernance d’un SLL Whānau, qui a lui-même des paramètres différents d’un SLL d’organisation associative.

Le lien avec les langues minoritaires de l’UE est direct. Un SLL en gallois, formé sur du matériel en gallois sous l’autorité d’une communauté galloise, répondrait aux requêtes en gallois provenant de sources en gallois. Un SLL sami ferait de même pour le sami. Un SLL basque pour le basque. La chaîne d’outils ne présuppose pas spécifiquement le te reo Māori — elle présuppose que la communauté détient la souveraineté sur ce qui forme le modèle et sur ce que le modèle est autorisé à faire. Remplacer les communautés galloises, samies ou basques par des communautés Māori revient à réentraîner le modèle sur un corpus différent, et non à reconstruire l’architecture. Le même principe s’applique à toute organisation communautaire — paroisse, coopérative, groupe de conservation — dont la langue se trouve être la langue nationale dominante : moins de contraintes linguistiques, la même posture de souveraineté.

La réalité technique est plus précise que l’argument marketing. Les SLL sont des modèles linguistiques de base affinés à partir de données communautaires ; ils ne sont pas reconstruits à partir de zéro. L'argument de la souveraineté repose sur le fait que l'affinage, le pilotage au moment de l'inférence et l'hébergement relèvent tous de l'autorité de la communauté — ce qui constitue le sens opérationnel du terme « souverain » dans ce contexte. L'origine du modèle de base importe moins que ne le supposent la plupart des débats, à condition que la communauté contrôle ce qui lui est fait et où il est exécuté.

2.2 Agents gardiens

Les « Guardian Agents » sont des contrôles d'exécution, implémentés dans le code, qui évaluent chaque réponse générée par l'IA avant qu'elle ne parvienne à l'utilisateur. Chaque contrôle analyse la réponse, l'évalue par rapport à une ou plusieurs valeurs déclarées, puis la valide, la signale ou la rejette. Les valeurs déclarées sont définies par la communauté ; les contrôles sont open source.

Cela revêt une importance particulière pour une raison bien précise. La « persistance des valeurs » désigne la question de savoir si les valeurs déclarées d’une plateforme restent fidèles à leur forme initiale à mesure que celle-ci se développe. La réponse habituelle est négative : les plateformes rédigent des déclarations de valeurs lors de leur création, puis les modifient au fil du temps sous la pression du marché, des investisseurs ou des régulateurs. La « dérive des valeurs » est le terme technique désignant ce phénomène. Les agents Guardian constituent une tentative visant à rendre cette dérive détectable en temps réel, et non plus uniquement lors des conférences de presse. Une réponse générée par l’IA qui a été soumise à un Guardian Agent en fonction des valeurs déclarées par la communauté a passé un contrôle réel, et non une simple assurance de conformité à une déclaration de politique générale.

L'équivalent réglementaire européen est simple : l'article 50 de la loi sur l'IA, relatif aux obligations de transparence, exige que le contenu généré par l'IA soit identifiable. Les Guardian Agents vont plus loin : ils enregistrent, pour chaque réponse, quelles valeurs ont été vérifiées et quel a été le résultat de cette vérification. Il s'agit d'un artefact prêt pour l'audit qu'un régulateur, un conseil communautaire ou un chercheur peut inspecter directement. C'est le type de preuve qui distingue une plateforme prétendant défendre des valeurs d'une plateforme démontrant qu'elle les défend réellement.

2.3 Fédération

La fédération, au sens Village, est un arrangement technique restreint qui permet à deux plateformes communautaires souveraines de se connecter à des fins spécifiques — appels vidéo intercommunautaires, covoiturage partagé, événements conjoints, annonces inter-villages — sans que l’une ou l’autre ne soit tenue de céder des données, son identité ou son autorité de gouvernance à un tiers. Chaque fédération est un accord bilatéral : les deux communautés conviennent, selon les termes qu’elles spécifient, de permettre l’interaction spécifique. Aucun réseau central ne coordonne le processus. Chaque partie peut se retirer à tout moment. Une fédération à laquelle une communauté n’a pas adhéré est une fédération qui n’existe pas pour cette communauté.

C'est là tout le contraste avec le modèle de plateforme. Les groupes Facebook, les serveurs Discord, les communautés WhatsApp et leurs équivalents ne sont pas fédérés ; ce sont des instances au sein du réseau d'un seul opérateur. L'opérateur fixe les règles, a accès aux données et peut modifier les deux. La fédération Villageest d'une architecture opposée : deux opérateurs souverains s'accordent, selon leurs propres conditions, sur une interaction délimitée. Lorsque l'un des deux se retire, rien ne se brise de l'autre côté.

Un exemple concret — en cours de développement. Le premier covoiturage fédéré multi-instances, reliant plusieurs villes néo-zélandaises, est en cours de développement et devrait être opérationnel début mai 2026. Chaque ville gérera sa propre instance souveraine — ses propres membres, sa propre modération, ses propres données. Les villes s’engagent bilatéralement à partager la mise en relation des covoiturages au-delà de leurs frontières communes, et uniquement cela : aucune donnée relative à l’adhésion, au paiement ou à l’historique des trajets n’est échangée entre les instances ; chaque ville conserve le droit de quitter la fédération à tout moment, sans que cela n’affecte les services des autres villes. L'infrastructure de la fédération sur laquelle cela fonctionnera — le modèle FederationAgreement, les routes et les services — est déjà déployée dans le code source de la plateforme ; le déploiement du covoiturage est la première fédération multi-instances sous ce modèle. Le modèle est le modèle ; le fait qu'il s'agisse de covoiturage plutôt que, par exemple, d'un organisme d'adhésion affilié au niveau national reliant le siège à ses sections, est accessoire.

Cela a une pertinence réglementaire directe au regard de la loi européenne sur la liberté des médias, qui exige que les communautés de langues minoritaires conservent leur souveraineté éditoriale et de gouvernance sur les médias et les services d’information par lesquels elles agissent. Un modèle de fédération préserve cette souveraineté en tant que propriété architecturale, et non en tant qu’engagement politique.

3 — Leviers réglementaires de l'UE

La section 2 a abordé chaque réglementation comme le résultat d’un mécanisme ; cette section aborde chaque mécanisme comme une réponse à une réglementation.

Les trois mécanismes ci-dessus recoupent spécifiquement quatre instruments réglementaires de l’UE. Chaque recoupement est présenté de manière restrictive ; rien dans cette note ne constitue un avis de conformité réglementaire (l’auteur n’est pas juriste et n’agit pas en tant que tel).

3.1 Loi sur l'IA — Articles 2 et 50

Article 2 (champ d'application). La loi sur l'IA s'applique aux fournisseurs et aux déployeurs de systèmes d'IA au sein de l'Union, ainsi qu'aux fournisseurs situés en dehors de l'Union dont les résultats des systèmes d'IA sont utilisés dans l'Union. Une communauté de l’UE utilisant un service d’IA commercial hébergé aux États-Unis est un déployeur au sens de l’article 2 ; l’opérateur de ce service est un fournisseur. La question de la gouvernance — qui décide de la configuration du système d’IA, de ce qu’il peut et ne peut pas faire, et qui est responsable en cas d’erreur — est déterminée par le choix du fournisseur effectué par le déployeur. Accepter les paramètres par défaut du fournisseur revient à déléguer la décision de gouvernance ; l’article 2 ne dégage pas le déployeur de sa responsabilité.

Article 50 (obligations de transparence). Les déployeurs doivent informer les utilisateurs concernés par les résultats d’un système d’IA que ces résultats ont été générés par l’IA et leur indiquer la nature du système. Cela crée une exigence d’audit permanente : une organisation communautaire qui ne peut pas produire un enregistrement de ce que son système d’IA a été chargé de faire, des valeurs par rapport auxquelles il a été vérifié et de ses résultats, ne peut pas satisfaire de manière significative à l’obligation de transparence. Les Guardian Agents produisent exactement cet enregistrement, automatiquement, pour chaque réponse.

3.2 Loi européenne sur la liberté des médias

L'EMFA (règlement 2024/1083, applicable à partir du 8 août 2025) protège l'indépendance éditoriale et le pluralisme des médias dans toute l'Union. Ses considérants reconnaissent la position particulière des médias en langues minoritaires et des médias à l'échelle communautaire — des services dont l'audience est restreinte mais dont la fonction culturelle ne peut être remplacée par des médias à plus grande échelle.

Le modèle de fédérationVillageest un modèle de conception que l’EMFA présuppose mais ne décrit pas. Deux plateformes communautaires en langues minoritaires, fédérées selon des conditions convenues, préservent la pluralité que protège l’EMFA. Ce n’est pas le cas d’une plateforme communautaire dépendante d’un réseau social détenu par des intérêts américains : ses décisions éditoriales sont soumises aux règles de modération du réseau et au pouvoir de ce dernier de modifier les contrats. L’EMFA n’interdit pas le second arrangement ; elle fait valoir que le premier arrangement est celui que les objectifs politiques de la loi impliquent.

3.3 RGPD — Article 9

L'article 9 du RGPD considère que certaines catégories de données à caractère personnel (santé, orientation sexuelle, opinions politiques, origine raciale ou ethnique, convictions religieuses, appartenance syndicale, données génétiques et biométriques) nécessitent une protection renforcée. La portée de la notion d’« origine raciale ou ethnique » inclut vraisemblablement l’identité communautaire liée à une langue minoritaire — les données d’un locuteur sami concernant son utilisation de la communauté linguistique sami peuvent être considérées comme des données relatives à son origine ethnique au sens de l’article 9. Cette interprétation n’est pas encore tranchée par la justice, mais elle constitue un point de départ défendable pour une communauté cherchant à ancrer sa revendication de souveraineté sur les données.

L’isolation des locataires, la gouvernance contrôlée par la communauté et l’hébergement souverain de la boîte à outils Village concrétisent l’article 9 sous une forme technique spécifique. Les données ne quittent jamais l’infrastructure autorisée de la communauté ; le registre de traitement est vérifiable par la communauté ; le consentement est donné au niveau communautaire, et non seulement au niveau individuel. La conformité à l’article 9 n’est pas la finalité de cette architecture, mais c’est ce qu’elle produit comme effet secondaire.

3.4 Loi sur les services numériques et CLOUD Act

Deux recoupements moins médiatisés méritent d’être mentionnés. La loi sur les services numériques (DSA) impose des obligations de transparence et de modération des contenus aux très grandes plateformes en ligne. Une plateforme communautaire fonctionnant à l’échelle d’une communauté se situe en dessous des seuils fixés par la DSA ; mais une plateforme soumise à la DSA qui souhaiterait héberger des communautés de langues minoritaires sans les intégrer dans son régime de modération trouverait dans le modèle de fédération l’un des rares dispositifs techniques lui permettant de le faire. La DSA présuppose elle aussi un modèle de conception qu’elle ne décrit pas.

Et le CLOUD Act américain — la loi qui confère aux autorités américaines un accès extraterritorial aux données détenues par des entreprises dont le siège social est aux États-Unis, partout dans le monde — est la force opposée non nommée dans tous les débats sur la souveraineté numérique de l’UE. Une communauté utilisant un fournisseur d’IA américain intègre le CLOUD Act dans sa posture vis-à-vis du RGPD en tant que condition non reconnue. Une communauté utilisant un déploiement d’IA souverain ne le fait pas. Il ne s’agit pas ici d’une affirmation sur ce que le CLOUD Act accomplit ou non ; il s’agit d’une affirmation sur la posture contractuelle et juridictionnelle qu’une communauté a choisie, intentionnellement ou par défaut.

4 — Critères d'audit structurels

Une note d'orientation qui se contenterait d'affirmer que la plateforme de son auteur « défend des valeurs » serait sans valeur. Ce qui suit sont des critères d'audit spécifiques, vérifiables à partir d'éléments publics, qui distinguent une plateforme ayant pris des engagements architecturaux d'une plateforme ayant formulé des promesses marketing.

  1. Isolation des locataires. Un opérateur ou un administrateur au niveau de la plateforme peut-il lire le contenu des locataires ? Village propose trois niveaux de sécurité progressivement plus élevés :

    • Niveau 1 (base de données partagée, périmètre par locataire) — chaque requête est filtrée sur le tenantId; les comptes d'administrateur de la plateforme sont explicitement exclus de l'accès au contenu dans la couche d'autorisation. Vérifiable dans le code source ouvert. Il s'agit du niveau par défaut, suffisant pour la plupart des locataires à l'échelle communautaire.
    • Niveau 2 (base de données dédiée par locataire) — les données du locataire résident dans sa propre base de données MongoDB avec ses propres identifiants de connexion ; l'isolation est appliquée au niveau de la base de données plutôt qu'au niveau de la couche de filtrage des requêtes. Actuellement implémenté via le service TenantConnectionManager. Vérifiable en inspectant l'hôte de la base de données contrôlé par l'administrateur du locataire.
    • Niveau 3 (auto-hébergé sur l'infrastructure propre au locataire) — le locataire exécute Village sur ses propres serveurs ; l'opérateur de la plateforme n'a aucun accès aux données ni à la configuration. L'architecture prend en charge ce niveau aujourd'hui ; les outils de déploiement et le modèle de support sont prévus dans la feuille de route (voir §7). Vérifiable par la possession par le locataire de l'instance en cours d'exécution.

  2. Compétence en matière d'infrastructure. Où passe le chemin de la requête ? Quelles entreprises possèdent l'infrastructure sous-jacente ? Y a-t-il une dépendance vis-à-vis des États-Unis dans le chemin de la requête, explicite ou indirecte (y compris CDN, DNS, analyse, systèmes de retour d'information) ? L'infrastructure de production Villageest hébergée chez OVH France et Catalyst Cloud New Zealand, sans aucune dépendance vis-à-vis des États-Unis dans le chemin de la requête. Ces faits sont vérifiables à partir des enregistrements DNS, de la configuration nginx et des scripts de déploiement open source du projet.

  3. Rédaction des valeurs. Qui a rédigé les valeurs de la plateforme ? Qui peut les modifier ? L'historique des modifications est-il public ? Existe-t-il un mécanisme permettant à la communauté de contester, de modifier ou d'opposer son veto à une valeur que la plateforme revendique au nom de la communauté ? Les valeurs et la constitution Villagesont publiées sur mysovereignty.digital — la constitution à l’adresse /constitution.html et /village-constitution.html, les valeurs à l’adresse /values.html et /platform-values.html, avec des versions traduites en allemand, français, néerlandais et te reo Māori. Tout lecteur peut les consulter directement avant de prendre une décision d’adoption.

  4. Application en temps réel. Les valeurs de la plateforme sont-elles appliquées en temps réel, ou simplement mises en avant dans le marketing ? Pour une plateforme d’IA, cela signifie : chaque réponse de l’IA passe-t-elle par un contrôle des valeurs avant d’atteindre un utilisateur ? Les Guardian Agents constituent le mécanisme d’application en temps réel ; leur code source et leur configuration sont ouverts.

  5. Licence open source. Sous quelle licence le code de la plateforme est-il publié ? Cette licence est-elle approuvée par l'OSI, et une communauté ou une entreprise qui adopte la plateforme peut-elle redéployer, modifier et auditer le code de manière indépendante ? Deux réponses différentes s'appliquent :

    • Le Tractatus Framework — le mécanisme de la couche de gouvernance qui sous-tend les mécanismes de pérennisation des valeurs décrits au §2 — est publié sous licence Apache 2.0 et est accessible au public sur Codeberg à l'adresse https://codeberg.org/mysovereignty/tractatus-framework. Approuvé par l'OSI. Tout lecteur peut l'inspecter, le forker et l'auditer.
    • Le code source de la plateformeVillage est actuellement propriétaire. L'engagement pris consiste à publier certains modules — le protocole de fédération, le système de vocabulaire, l'automatisation du déploiement et la documentation destinée aux opérateurs — sous forme de composants open source autonomes, sous réserve du processus de gouvernance décrit au §7. La mise en open source intégrale de l'ensemble du code source de la plateforme n'est pas prévue. Cette réserve s'explique par le risque d'exposition de la surface d'attaque, décrit au §7.

Le public visé par cette note de synthèse n’a pas besoin de refaire tous ces audits. Mais ces critères constituent une liste de contrôle qu’un chercheur, un régulateur ou un conseil communautaire peut appliquer à toute plateforme revendiquant la souveraineté numérique. Une plateforme qui ne satisfait pas à cette liste de contrôle n’est pas encore souveraine ; une plateforme qui y satisfait a au moins franchi le seuil technique requis pour mériter ce terme.

5 — Ce qui est transférable, et ce qui ne l'est pas

Il convient de mentionner trois niveaux de transférabilité, afin qu’une communauté ou une entreprise qui adopte le système sache clairement ce qu’elle hérite, ce qui nécessite une adaptation contextuelle et à quoi ressemble le risque de se tromper.

Transférable. Les trois mécanismes — SLL, Guardian Agents, Fédération — sont directement transférables. Chacun est un modèle technique ; chacun dispose d’une implémentation open source ; chacun peut être redéployé avec le matériel, la gouvernance et les partenaires de fédération d’une communauté différente. Un déploiement en langue galloise serait structurellement similaire à un déploiement en te reo Māori, avec des données d'entraînement différentes, des paramètres de gouvernance par défaut différents et des accords de fédération différents. Il en va de même pour une paroisse, un covoiturage de quartier, une coopérative ou un groupe de conservation opérant dans une seule langue nationale — le modèle de souveraineté communautaire s'étend au-delà du cas de la souveraineté linguistique. La chaîne d'outils ne se limite pas à la Nouvelle-Zélande.

Nécessite une adaptation contextuelle. L’idée que les données culturelles impliquent des obligations de garde — que les données d’une communauté de langue minoritaire ne sont pas simplement des informations à traiter selon le cadre choisi par l’opérateur, mais un taonga (trésor) à gérer selon les propres tikanga de la communauté — trouve des analogies dans les contextes des langues minoritaires de l’UE (le concept gallois de cynefin, le concept sami d’árbediehtu, le concept basque d’auzolan). Ces analogies ne sont pas identiques, et la présente note ne les assimile pas. Elle observe simplement que la boîte à outils néo-zélandaise a été conçue selon un principe de souveraineté qui a des équivalents européens, et que les communautés de l’UE procéderaient à leurs propres adaptations contextuelles.

Risque. Tout transfert de technologie d’un contexte du Sud / autochtone vers un contexte du Nord / de l’UE comporte le risque d’en extraire la forme technique tout en laissant de côté le cadre de responsabilité. L’auteur de cette note ne prétend pas résoudre ce risque. La responsabilité de maintenir la responsabilité dans toute adoption au sein de l’UE incombe à la communauté qui l’adopte et aux chercheurs, praticiens et conseillers juridiques qu’elle a choisis.

6 — Trois questions auxquelles cette note ne répond pas

Une note aussi succincte ne peut résoudre les questions les plus difficiles ; elle ne peut que les soulever.

  1. Qui choisit quel module s'applique à quelle communauté ? Une communauté sami adoptant la SLL, mais pas les Guardian Agents, ferait un choix. Sur quelle base ? Qui est habilité à le faire ?

  2. Le modèle de fédération Village est-il suffisant, ou un protocole inter-fédérations (Matrix, ActivityPub, autre) est-il nécessaire pour permettre à plusieurs communautés souveraines d’interopérer à grande échelle ? La fédération Village actuelle est bilatérale de par sa conception ; un réseau de fédération des langues minoritaires à l’échelle européenne mettrait cette conception à l’épreuve d’une manière qui n’a pas encore été testée.

  3. Quel est le sponsor fiscal européen approprié pour une plateforme communautaire souveraine ? Une fondation commerciale, une coopérative, un organisme public octroyant des subventions, ou un programme d'infrastructure européen existant (NGI0, NLnet, Horizon Europe) ? La réponse varie probablement selon la juridiction et la communauté.

7 — État actuel, position en matière de licences et feuille de route

État actuel de la plateforme. Village est en production sur une infrastructure souveraine de l’UE (OVH France) et une infrastructure souveraine de Nouvelle-Zélande (Catalyst Cloud), hébergeant des instances de locataires à travers la bibliothèque de modèles et traitant du trafic réel. La constitution et les valeurs sont publiées sur mysovereignty.digital avec des traductions en allemand, français, néerlandais et te reo Māori. L’architecture, la plateforme et le livre blanc de référence existent aujourd’hui ; ce ne sont pas des promesses.

Politique en matière de licences. Deux instruments différents s'appliquent à deux composants différents :

Covoiturage — calendrier illustré par un exemple concret. Le premier réseau de covoiturage fédéré multi-instances couvrant plusieurs villes néo-zélandaises est en cours de développement et devrait être opérationnel début mai 2026. L'infrastructure de fédération sur laquelle il fonctionnera — le modèle FederationAgreement, les itinéraires et les services — est déjà déployée dans le code source de la plateforme.

Situation en matière de financement. Deux demandes sont en cours d'examen par la Fondation NLnet : la demande relative au NGI Zero Commons Fund et celle concernant le NGI Fediversity. La seconde vise spécifiquement à fournir l'extraction de modules open source (protocole de fédération, système de vocabulaire), la boîte à outils d'automatisation du déploiement et la documentation destinée aux opérateurs, qui permettent des déploiements indépendants par les opérateurs. Les décisions de la Fondation sont en attente.

Déploiements auto-hébergés (isolation des locataires de niveau 3). Pour les locataires dont les exigences en matière de souveraineté dépassent même l'hébergement sur une base de données dédiée — agences nationales, grandes confessions religieuses, organismes professionnels réglementés, entités proches du gouvernement —, l'architecture technique prend aujourd'hui en charge le fonctionnement auto-hébergé, le locataire exécutant la plateforme sur une infrastructure qu'il contrôle. L'ensemble opérationnel — automatisation du déploiement, documentation de l'opérateur, modèle de support — est ce que la demande de subvention Fediversity est destinée à financer. Tant que ces éléments ne sont pas en place, le déploiement auto-hébergé pratique relève d'un engagement sur mesure plutôt que d'un produit pris en charge.

Ce qui est certain et ce qui ne l'est pas. L'architecture actuelle de la plateforme, la licence de Tractatus sous Apache 2.0, la mise à disposition publique de la constitution et des valeurs, ainsi que le statut de production sur une infrastructure souveraine — tout cela est certain. Les calendriers de publication des modules, les résultats des subventions et le rythme des approbations du Conseil d'administration et du Comité consultatif qui les régissent — tout cela est incertain. Ce document décrit ce qui existe aujourd'hui et ce qui a été engagé par écrit. Les résultats relevant de tiers — les décisions de subvention de la Fondation NLnet, les approbations du Conseil d'administration et du Comité consultatif en cours de formation — sont décrits comme des incertitudes, et non comme des livrables promis.

8 — Comment s'impliquer

Le livre blanc principal — Distributive Equity Through Structure: A Community-Scale Worked Example of Values Stickiness (v1.0, 16/04/2026, DOI 10.5281/zenodo.19600614) — fournit la base théorique complète des arguments présentés dans ce document, ainsi que les critères d'audit structurel sous une forme détaillée, les questions de recherche ouvertes avec plus de précisions et un appareil de référence complet.

Le code source Tractatus Framework est accessible au public à l'adresse https://codeberg.org/mysovereignty/tractatus-framework (licence Apache 2.0). Le code source de la plateformeVillage est actuellement privé ; il sera publié progressivement conformément à la feuille de route de publication des modules décrite au §7. Dans l'intervalle, l'examen technique de composants spécifiques est accessible aux chercheurs institutionnels et aux praticiens des politiques sur demande adressée à l'auteur. La plateforme est en ligne à l'adresse mysovereignty.digital, avec des exemples de constitution, de valeurs et de bibliothèque de modèles accessibles au public sur les sous-domaines des locataires liés depuis sa page de fédération.

Correspondance directe avec l'auteur : john.stroh@mysovereignty.digital. Les demandes émanant d'institutions ou de praticiens des politiques, les invitations à contribuer à l'analyse formelle des politiques et les manifestations d'intérêt pour des déploiements opérationnels sont les bienvenues.

Cette note est publiée sous licence CC BY 4.0. Elle peut être republiée, traduite et citée par toute organisation communautaire de l'UE, tout chercheur, journaliste ou analyste politique, à condition d'en mentionner la source.

Remerciements et mentions

Cette note est dérivée de « Distributive Equity Through Structure » (v1.0, 16/04/2026). L'appareil de citation du document source — qui inclut les travaux universitaires sur la souveraineté des données autochtones (Te Mana Raraunga, la Global Indigenous Data Alliance, les principes CARE pour la gouvernance des données autochtones et les chercheurs individuels qu'il cite) qui sous-tendent les engagements architecturaux décrits dans cette note — s'applique également ici et constitue la source correcte à mentionner.

L'auteur est le dirigeant d'une entreprise unipersonnelle ; il n'est ni juriste, ni universitaire, ni responsable politique. Le travail technique a été réalisé avec l'aide d'une IA, comme indiqué. Aucune personne ou organisation mentionnée dans cette note n'a relu ou approuvé celle-ci. La responsabilité de chaque affirmation incombe uniquement à l'auteur.

Citation suggérée

Stroh, J. (2026). Gouvernance souveraine de l'IA à l'échelle communautaire : note d'orientation de l'UE. Version 0.1. My Digital Sovereignty Limited, Nouvelle-Zélande. DOI 10.5281/zenodo.19635598. Article source DOI 10.5281/zenodo.19600614. Publié sur https://agenticgovernance.digital/whitepapers/eu-policy-brief. ORCID 0009-0005-2933-7170. Sous licence CC BY 4.0.