Comment un Village humain » gouverne sa propre IA — ce que nous avons construit, pourquoi une nouvelle constitution pour l’évolution de l’IA le valide, et la seule lacune de cette constitution

Résumé. En juin 2026, Vincent Boucher, président de QUEBEC.AI et MONTREAL.AI, a publié une constitution régissant la manière dont l’IA institutionnelle est autorisée à évoluer : GoalOS — La Constitution de la preuve d’évolution. Sa règle est austère et juste — ne mettez pas l’intelligence sur la chaîne ; mettez la preuve de l’intelligence sur la chaîne — et la plupart de ses primitives sont celles que nous avions déjà construites, pour la gouvernance humaine, et mises en œuvre : une frontière entre preuve publique et données privées, des enregistrements signés portant des preuves, des décisions de type « créateur-vérificateur », des pages d’audit qui sont des salles d’évidence plutôt que des pages de marketing. Cette convergence mérite d’être clairement soulignée, car le fait qu’un penseur indépendant sérieux parvienne à la même architecture constitue la validation externe la plus solide qu’une conception puisse obtenir. Cet essai remplit trois fonctions. Il explique ce que le Village met déjà en œuvre et pourquoi. Il adopte la partie de la discipline de Boucher qui nous manquait — une méthode nommée et fondée sur des preuves pour décider quand notre propre IA mérite le droit de remplacer ce qui est en service. Et il s’écarte sur deux points : nous refusons la blockchain sur laquelle repose sa norme, pour des raisons de souveraineté que sa propre clause de neutralité autorise ; et nous ajoutons le seul critère que sa constitution ne prévoit pas. Son sujet est la capacité de l’IA. Le nôtre, ce sont les personnes. Un modèle peut répondre, un agent peut agir, une institution doit prouver — et une communauté doit rester l’auteur.

Une norme a vu le jour en juin dernier qui mérite l’attention d’une petite nation, non pas parce qu’elle est achevée, mais en raison de ceux qui l’ont élaborée et du lieu où elle a vu le jour. Vincent Boucher — président de QUEBEC.AI et MONTREAL.AI — a publié GoalOS : The Proof-of-Evolution Constitution, sous-titré AEP-001 : The Blockchain-Native Standard for Proof-Carrying Intelligence Organizations. Il s’agit, selon la formulation prudente de son auteur, d’une doctrine et d’un programme de recherche falsifiable, et non d’un produit commercialisé : ses références fondamentales sont des ébauches manuscrites, et il revendique une architecture de protocole plutôt qu’une capacité déjà réalisée. Cette honnêteté est la première chose que nous y avons reconnue, car c’est la discipline à laquelle nous nous conformons.

La raison pour laquelle il faut le lire attentivement, c’est la convergence. Nous avons consacré ce programme à la construction d’une plateforme de souveraineté pour les communautés humaines — whānau, paroisses, prestataires de hauora, kāhui — dans laquelle l’IA est un instrument au service de la communauté, et non jamais l’autorité à laquelle elle rend des comptes. Boucher s’est fixé pour objectif de régir la manière dont l’IA d’une institution est autorisée à s’améliorer. Nous sommes partis de pôles opposés — lui de la machine, nous des personnes — et nous nous sommes retrouvés sur le même petit ensemble de principes fondamentaux. Lorsque cela se produit, c’est un signe. Cet essai rend compte de ce point d’accord, du seul domaine où nous refusons de le suivre, et du seul domaine où nous allons plus loin.

Ce que Boucher a construit

La colonne vertébrale de la constitution tient en une seule phrase : ne mettez pas l’intelligence sur la chaîne ; mettez la preuve de l’intelligence sur la chaîne. Le raisonnement de la machine, les invites privées, les données clients, les traces brutes — tout cela reste privé. Ce qui devient public et vérifiable, c’est la preuve qu’un travail a été effectué, évalué et autorisé à influencer la suite des événements. La doctrine publique de Boucher énonce quatre étapes — Viser → Agir → Prouver → Évoluer — et transforme chacune d’elles en un objet signé et versionné : une institution énonce son objectif ; un agent délimité agit ; l’exécution émet un paquet de preuves vérifiables ; et une amélioration potentielle ne peut évoluer — se propager pour être mise en service — qu’en franchissant un seuil de sélection.

Ce filtre est au cœur du système, et c’est la partie qui vaut la peine d’être reprise. Boucher l’appelle le « gradient de preuve », et il insiste sur le fait qu’il s’agit d’« une loi de sélection, pas une impression, pas un concours de popularité, et pas un score marketing ». Le score est indicatif ; les filtres sont obligatoires. Une mise à jour candidate n’est promue que si sa preuve est valide, si elle surpasse la référence en place sur les évaluations enregistrées à budget égal, si son risque mesuré est inférieur au seuil, si elle comporte un objectif de retour en arrière qui a été testé, si elle dispose d’un « canari » bien délimité, si sa promotion est autorisée dans un périmètre spécifique plutôt que diffusée globalement, et si une fenêtre de contestation s’est écoulée. Pas de preuve, pas d’évolution. Pas d’évaluation, pas de propagation. Pas de retour en arrière, pas de déploiement.

Deux autres éléments sont importants. Le « Evidence Docket » est le nom qu’il donne à la page de preuve publique, et la phrase qu’il en dit est celle que nous aurions aimé écrire : « Une page de preuve n’est pas une page marketing. C’est une salle des preuves liée à une allégation. » Le lecteur d’une telle page peut voir ce qui a été testé, ce qui a réussi, ce qui a échoué, quelles bases de référence ont été comparées, quelles barrières ont été appliquées, et comment réexécuter l’allégation. Et le modèle de menace est antagoniste par conception — fausses preuves, collusion des évaluateurs, piratage des récompenses, fuites de données personnelles, captation de la gouvernance, échec de la restauration, allégations excessives — car, comme il le dit, un système qui cache ses échecs ne peut pas être un système de preuve.

Ce que nous avions déjà mis en place

Lisez cette liste avec l’œil de quelqu’un qui a passé deux ans à mettre en place une gouvernance pour des communautés humaines, et presque chaque ligne vous sera familière — car nous l’avions déjà mise en œuvre, pour un sujet différent.

La frontière entre preuve publique et données privées constitue notre architecture. Le Village publie des identités did:web et des chaînes de preuves en ajout seul ; le contenu du locataire et les raisons d’une décision sont chiffrés et n’atteignent jamais la surface publique. L’artefact porteur de preuve de Boucher — signé, versionné, immuable, avec une cible de retour en arrière — est notre enregistrement souverain signé, avec son hachage de provenance, son hachage de contenu et sa chaîne de preuves inviolable, exportable sous forme de dossier. Son SelectionCertificate, l’objet signé qui admet ou rejette une modification dans le cadre de la séparation créateur-vérificateur, est notre registre de décision DirectorEngagement : positions des membres signées, proposant différent de l’approbateur, le tout consigné dans un procès-verbal. Son Evidence Docket — la salle des preuves liée aux allégations, et non une page marketing — est la discipline que nous nous sommes imposée tout au long de l’année : vérifier avant d’affirmer, pas de sections de couverture défensive, des « Decision Records » qui se lisent comme des procès-verbaux inviolables plutôt que comme des communiqués de presse. Et sa discipline en matière d’allégations — pas d’allégations sur l’AGI ou l’ASI, uniquement empiriques par le biais de preuves — est notre règle permanente contre la fabrication et les fausses équivalences juridiques.

Nous le disons avec prudence, car la discipline en matière d’affirmations est à double tranchant. Ce qui est livré, c’est la machinerie de gouvernance humaine décrite ci-dessus : les identités, les chaînes de preuves, les comptes rendus signés, le système « créateur-vérificateur », les comptes rendus de décision. Ce qui nous manquait jusqu’à présent, c’était d’appliquer la même rigueur à l’évolution de notre propre IA. C’est cette lacune que le travail de Boucher nous a permis de combler, et nous ne prétendrons pas qu’elle était déjà comblée.

La lacune qu’il comble pour nous

Le Village exploite de petites IA souveraines pour chaque type de communauté — des modèles modestes par communauté et les couches plus légères qui les entourent. Décider quand une nouvelle version mérite de remplacer celle en service a été un processus empirique mais ad hoc, et le bilan empirique est une leçon d’humilité. Un re-entraînement que nous avions évalué n’ a délibérément pas été déployé. Une série d’ expériences sur les poids a dégradé les performances. Nous avons appris, à nos dépens, à ne pas entraîner en visant trop haut — que les améliorations systématiquement fiables proviennent d’une adaptation plus légère, et non d’un réentraînement héroïque. Nous avions l’habitude de rechercher les preuves. Nous n’avions pas de règle formelle qui stipulait, à l’avance, ce qu’un changement devait prouver avant d’être autorisé à se propager.

Nous en avons donc adopté une, en tant que norme de gouvernance interne. Elle reprend le « Proof Gradient » de Boucher presque mot pour mot et en fait la règle de notre propre évolution en matière d’IA : un modèle candidat est d’abord une ébauche, puis un candidat, puis un « canari », puis actif, et l’état « actif » est toujours révocable vers « rolled_back ». Il n’est promu qu’après avoir franchi les mêmes étapes obligatoires : preuve valide, évaluation supérieure à la référence, risque inférieur au seuil, retour en arrière testé, portée du « canari » définie, portée autorisée, fenêtre de test validée. Le score consultatif évalue la valeur et la qualité vérifiées par rapport au coût, au risque et à la dette de retour en arrière, exactement comme il le précise, et n’admet jamais un candidat qui échoue à une étape. C’est la discipline qui nous manquait, et nous sommes clairs sur le fait qu’il s’agit d’une discipline nouvellement adoptée, et non d’un système déjà en production.

La seule chose que nous refusons : la chaîne

C’est là que nos chemins se séparent, et cette séparation n’est pas purement cosmétique. L’AEP-001 est, de par son sous-titre, natif de la blockchain. Son « Evolution Ledger » est une colonne vertébrale de preuves basée sur Ethereum. Sa suite de contrats est entièrement basée sur Ethereum — un coffre-fort de récompenses, une cour de sanctions, le staking des évaluateurs, des normes d’abstraction des comptes et de comptes liés à des jetons, un service d’attestation. Dans sa conception, les capacités sont régies en partie par des incitations crypto-économiques : les évaluateurs effectuent du staking, les mauvais acteurs sont sanctionnés, le bon travail est récompensé, et les droits de propagation sont réglés sur la chaîne.

Nous n’adoptons rien de tout cela. Une chaîne publique, une infrastructure crypto ancrée aux États-Unis et un règlement crypto-économique constituent une violation directe de la raison d’être Village: une infrastructure souveraine et auto-hébergée relevant du droit de l’Union européenne et de la Nouvelle-Zélande, sans chaîne publique, sans substrat étranger, sans que la continuité de la communauté soit prise en otage par une économie de jetons. Pour un whānau ou une paroisse, l’idée qu’un changement lié à l’IA soit subordonné au staking et aux sanctions est non seulement une infrastructure erronée, mais aussi une erreur de catégorie quant à la nature même de l’ institution.

La bonne nouvelle, c’est que nous sommes en droit d’adopter la doctrine sans le substrat, selon les propres termes de Boucher. Ses principes de conception incluent une clause de neutralité commerciale : « tout fournisseur de modèle, runtime, couche de stockage, évaluateur, chaîne, entreprise ou institution souveraine peut mettre en œuvre l’AEP s’il respecte les interfaces de preuve. » Nous respectons les interfaces de preuve. Nous les mettons simplement en œuvre sur un terrain souverain : une chaîne de preuves en ajout seul sur un stockage auto-hébergé au lieu d’un registre Ethereum ; des identités did:web et des enregistrements souverains signés au lieu d’ attestations sur la chaîne ; un enregistrement de décision « maker-checker » au lieu d’un contrat de certificat de sélection. Là où sa conception comporte un coffre-fort de récompenses et un tribunal de slashing, la nôtre prévoit une responsabilité humaine clairement désignée, et rien d’autre. Le Village est la preuve vivante qu’il est possible de disposer de l’intégralité de la discipline de preuve de l’AEP-001 sans aucune blockchain.

Le maillon manquant de la constitution

C’est la partie qui importe le plus, et c’est là que nous allons au-delà de Boucher plutôt que de simplement nous écarter de lui.

Le sujet de sa constitution est la capacité de l’IA. Il l’affirme clairement dans sa conclusion : la prochaine frontière réside dans « des institutions dont les agents peuvent agir, mais dont les améliorations doivent faire leurs preuves avant de se propager ». L’ institution qu’il imagine est, en effet, un réseau d’agents, et la question à laquelle répond sa porte est de savoir quelle amélioration de l’IA a gagné le droit de se propager. C’est une bonne question, à laquelle il apporte une réponse rigoureuse. Mais ce n’est pas toute la question pour une communauté humaine, et son propre modèle de menaces en révèle la faille : parmi les menaces qu’il énumère figure la capture de la gouvernance — « des votes symboliques ou des initiés contournant les preuves » — qu’il atténue par une séparation des fonctions de gouvernance. Le problème plus profond est qu’une barrière de capacité, aussi stricte soit-elle, peut favoriser une mise à niveau techniquement supérieure qui, discrètement, retire la paternité de la décision aux personnes à qui appartient la communauté, et la fait passer par toutes les barrières dont elle dispose.

Nous ajoutons donc un filtre que sa constitution ne prévoit pas. Appelons-le « ServeAuthorized »; il pose deux questions auxquelles aucune mesure de capacité ne peut répondre. Premièrement : le changement permet-il à la communauté de rester l’auteur de ses propres décisions ? Un changement est refusé s’il réduit le rôle des membres en tant qu’auteurs — même s’il obtient un meilleur score, coûte moins cher et franchit tous les autres filtres. La preuve d’évolution est nécessaire ; elle n’est pas suffisante. La paternité n’est pas un indicateur. Deuxièmement : lorsqu’un changement touche les données ou le cadre de référence d’une communauté — notamment la gouvernance des données te ao Māori —, dispose-t-il du consentement des personnes concernées ? La conception de Boucher limite la promotion par locataire et par classe de risque ; nous élargissons le champ d’application au consentement et à l’ adéquation culturelle. Un changement sans preuve ne se propage pas ; il en va de même pour un changement sans consentement.

Remarquez ce que cela implique également pour la menace de « capture de la gouvernance » qu’il évoque. Il doit atténuer la capture des votes par jetons, car son substrat comporte des votes par jetons. Nous supprimons le substrat: il n’y a pas de participation à pondérer ni de jeton à capturer, car le pouvoir de promotion appartient à des gardiens humains désignés dans le cadre d’un système « maker-checker », responsables en tant que personnes et non en tant que portefeuilles. Le vecteur de captation contre lequel il se prémunit n’existe pas dans notre conception. Ce n’est pas une coïncidence ; c’est ce qui se produit lorsque le sujet de l’institution est constitué de personnes plutôt que d’agents.

Garder l’IA au service de l’humain

Il existe un risque permanent à mettre tout cela par écrit, et il vaut la peine de le mentionner car il ne disparaît pas. Le discours sur « l’évolution institutionnelle de l’IA » est séduisant. Si on l’adopte suffisamment, le Village commence à dériver — d’une plateforme de souveraineté pour les communautés humaines vers un produit d’opérations d’IA auquel les communautés sont rattachées. Le cadre de Boucher, brillant pour ce à quoi il sert, tend vers cette direction, car pour lui, l’IA est le sujet. Chaque fois que nous invoquons cette discipline, nous devons défendre la position inverse : l’IA est le serviteur, pas le sujet. Le gradient de preuve existe pour qu’une communauté puisse faire confiance à l’ instrument dont elle dispose — et non pour que cet instrument devienne la raison d’être de la communauté. Si l’application de cette discipline commence à faire de l’ IA le centre d’intérêt, c’est qu’elle est détournée de son usage, et la bonne réaction est d’y mettre un terme.

C’est aussi pourquoi nous nous réjouissons de cette convergence. Elle nous indique que la structure que nous avons mise en place — portant la preuve, avec des preuves publiques et des données privées, et liée à des affirmations — est la bonne, ce qui a été confirmé de manière indépendante par un chercheur sérieux issu du domaine des machines. Nous apprécions grandement sa rigueur. Nous apprécions également la lignée qui la sous-tend : l’idée qu’un artefact doive porter la preuve de sa propre correctitude est plus ancienne que nous deux, remontant au« Proof-Carrying Code » de Necula en 1997. Et nous conservons la seule chose que sa constitution omet, car c’est la raison d’être du Village.

Un modèle peut répondre. Un agent peut agir. Une institution doit prouver. Et une communauté doit rester l’auteur.

Post-scriptum — de la constitution au produit

Depuis la rédaction de cet essai, Boucher a publié la couche produit du même programme : GoalOS Mission OS : The Proof OS for Autonomous AI Work (juin 2026). Elle transforme la constitution en quelque chose qu’une institution peut commander pour une exécution unique — « définir l’ objectif ; GoalOS s’exécute jusqu’à ce que la preuve soit établie » — et son résultat phare n’est pas un rapport mais un état décisionnel régulé: selon ses propres termes, « le résultat n’est pas un document. Le résultat est un état décisionnel régulé ». Trois éléments de cet article ont un lien direct avec l’ argumentation ci-dessus, et c’est un article d’autant plus convaincant qu’il mérite d’être lu attentivement.

Premièrement, il règle discrètement la question sur laquelle nous avions le plus insisté. Le produit Mission OS est en grande partie neutre vis-à-vis du substrat : la machinerie Ethereum si présente dans l’AEP-001 — le coffre à récompenses, la cour de sanction, le staking — a disparu de la couche produit, ne subsistant que sous la forme d’une mise en garde en arrière-plan indiquant que le flux de travail « ne doit pas diffuser de transactions sur le réseau principal ». La commercialisation proposée par Boucher se passe de la chaîne. La doctrine et le substrat ont toujours été séparables ; son produit en est la démonstration, et une démonstration plus convaincante que notre argumentation seule.

Deuxièmement, elle désigne une discipline que Village applique déjà. Mission OS énonce une « loi de publication autonome » : le site public « n’est pas édité manuellement [mais] généré à partir d’une source alignée sur les preuves, vérifié par un système automatisé, relu par un humain, puis publié », et le pipeline « ne doit pas fusionner automatiquement… publier des affirmations non étayées, ni supprimer les limites des affirmations ». C’est, presque étape par étape, la manière dont ces pages sont créées. Cela donne également un nom clair au danger contre lequel notre propre discipline en matière d’affirmations nous protège : la dette de preuve, « le risque que les résultats non vérifiés de l’IA deviennent la norme institutionnelle ».

Troisièmement, et surtout, cela accentue plutôt qu’il n’atténue le seul point sur lequel nos opinions divergent — et nous le disons en reconnaissant la qualité du produit. Mission OS est, comme son nom l’indique, un système d’exploitation destinéau travail autonome de l’IA: il fonctionne « jusqu’à ce que ce soit TERMINÉ », puis publie. C’est exactement le danger contre lequel cet essai mettait en garde — le glissement du sujet des personnes vers l’autonomie de la machine. Mission OS conserve un contrôle humain, une révision avant publication ; The Village conserve l’humain en tant qu’ auteur, et non en tant que réviseur de dernier recours. Nous acceptons cette rigueur avec gratitude et maintenons notre position d’autant plus fermement : l’IA est le serviteur, pas le sujet.

Le Village est un système opérationnel, pas une brochure — découvrez-le sur mysovereignty.digital et comparez-le aux affirmations présentées ici. Le Village applique la discipline décrite ici en tant que norme de gouvernance interne — le « Proof Gradient », adapté. Sources : Vincent Boucher, GoalOS : The Proof-of-Evolution — AEP-001, v12.1, juin 2026 (QUEBEC.AI & MONTREAL.AI) ; et GoalOS Mission OS : The Proof OS for Autonomous AI Work, v23, juin 2026. Les citations sont tirées mot pour mot de ces documents. Références intellectuelles : G. C. Necula, « Proof-Carrying Code », POPL 1997. — John G. Stroh, My Digital Sovereignty Ltd., juin 2026.