La question politique centrale
Toute la machinerie technique décrite dans les quinze parties précédentes — les DSLs racines, les méta-générateurs, le bridge inter-cadres, le quality gate, le packaging NuGet, Lex Studio — repose sur une hypothèse silencieuse : quelqu'un va générer les cadres. Un cadre Law.France2026.${Author}.Dsl ne se crée pas tout seul. Quelqu'un écrit les attributs [Article], [Paragraph], [Measure], [DemocraticProcedure]. Quelqu'un décide que l'eau potable est un IAsset de type StatusKind.Commons dans son cadre. Quelqu'un publie le .nupkg signé. Qui est ce quelqu'un ?
La question ne se résout pas par du code. Mais elle change radicalement la forme du repo, la politique de contribution, la structure de confiance, et ultimement le sens politique du projet. Reformulée plus précisément : qui a le droit de générer un cadre Law.${Space}${Time}.${Author} et de le publier comme source de vérité juridique ? Le ${Author} de la signature META(Ex × Ty) n'est pas une décoration dans le namespace — c'est la trace technique de la réponse politique à cette question. C'est la composante de la signature qui porte tout le poids de la gouvernance.
Modèle A — Cadre étatique unique (le modèle Catala)
Le premier modèle est celui que Catala pratique aujourd'hui, et c'est le plus lisible pour les institutions. Les auteurs sont des juristes professionnels, des chercheurs INRIA, des agents de la DGFiP, des fonctionnaires d'Etalab. Le repo est un monorepo public hébergé par un service de l'Etat. Le workflow de contribution est strictement contrôlé : seuls les contributeurs accrédités peuvent merger. L'avantage est évident : l'autorité du cadre est indiscutable, parce qu'elle émane de l'institution qui fait la loi.
La conséquence sur le code est immédiate. Law.France2026.Etalab.Dsl est le cadre canonique. Il est publié en NuGet officiel signé. Son versioning est contrôlé par un comité éditorial. Et surtout : aucun autre ${Author} n'est toléré dans la "vérité juridique" — tout fork est marginal, officieux, non-signé, et les outils institutionnels ne le reconnaissent pas.
// Modèle A — un seul cadre autorisé par (Space, Time)
// Le namespace est unique : Etalab est le seul ${Author} légitime
namespace Law.France2026.Etalab;
[Article("L132-4", Codification = "Code de l'environnement")]
public sealed class ArticleEnvL132_4
{
[Paragraph(1, Text = "L'eau et les milieux aquatiques sont des éléments du patrimoine commun de la nation.")]
[Measure(MeasureKind.Regulation, typeof(DrinkingWater))]
// Pas de concurrent : c'est la vérité Etalab, point final
public void Paragraph1() { }
}La limite est précise : c'est le risque de monoculture des cadres identifié en C.4 de la Partie 17 — Méta-critique. Si un seul cadre existe par (Espace × Temps), le vocabulaire de ce cadre-là préempte le vocabulaire politique disponible pour penser le droit. Quand Etalab décide que DrinkingWater est un actif de type StatusKind.Public plutôt que StatusKind.Commons, cette décision de typage est une décision politique — et dans le modèle A, personne ne peut la contester dans le même système formel. Le citoyen peut écrire un courrier, mais il ne peut pas forker le cadre et montrer dans le compilateur même ce que sa version alternative impliquerait. C'est l'asymétrie expert/citoyen reproduite dans un outil qui prétendait la réduire.
C'est le diagnostic exact d'Alain Supiot dans La Gouvernance par les nombres (2015) : la substitution d'un cadre algorithmique unique à la délibération politique qui devrait précisément générer et choisir ses cadres. Le modèle A fait courir au projet le risque de devenir ce qu'il dénonce. Il faut le dire clairement : le modèle A est excellent pour ce que Catala fait déjà (le calcul fiscal, les prestations sociales — des domaines où l'autorité étatique est légitime et souhaitable), mais il ne suffit pas pour le projet métacratique dans son ensemble.
Le modèle A a aussi un avantage pragmatique qu'il ne faut pas sous-estimer : il est le seul à proposer un chemin d'adoption institutionnel immédiat. Un directeur de la DINUM peut signer un arrêté validant Law.France2026.Etalab.Dsl comme référence officielle. Aucun responsable institutionnel ne signera un arrêté validant "la multiplicité fédérée des cadres concurrents". L'adoption institutionnelle du modèle A ouvre la porte aux modèles B et C par la suite — il est plus facile de passer de A à B que de B à A, parce que l'infrastructure B est un surensemble technique de A.
Modèle B — Multiplicité fédérée des cadres (le modèle Wikipédia)
Le deuxième modèle est celui qui fait du ${Author} un namespace ouvert. Pour un même (Espace × Temps), plusieurs auteurs génèrent leurs cadres concurrents, et le débat public porte explicitement sur les divergences entre cadres. Les auteurs sont des associations (La Quadrature du Net, France Nature Environnement), des universités, des juristes indépendants, des fédérations citoyennes, des syndicats, et l'Etat aussi — mais l'Etat est un auteur parmi d'autres, pas l'auteur canonique.
Le repo n'est pas un monorepo centralisé mais une forge ouverte — Codeberg, GitLab.fr, SourceHut — avec des maintainers élus par la communauté des contributeurs. L'avantage est la pluralité native des cadres assumée comme valeur positive, pas comme défaut regrettable. La limite est l'absence d'autorité finale tranchée : quand deux cadres divergent sur le statut d'un actif, le système exhibe la divergence mais ne la résout pas. Et c'est précisément le point : la résolution des divergences est l'affaire de la délibération politique, pas du compilateur.
C'est ici que le ConsensusScorer prend tout son sens. Dans le modèle A, le ConsensusScorer est inutile — il n'y a qu'un seul cadre, donc le consensus est trivial (unanimité par absence d'alternative). Dans le modèle B, le ConsensusScorer devient l'outil politique central : il calcule pour chaque article du droit un score de consensus entre les cadres concurrents, et il exhibe les zones de divergence comme données politiques adressables. Un parlementaire qui prépare un projet de loi peut consulter le ConsensusScorer pour savoir sur quels articles les différents cadres s'accordent (et donc où la réforme est consensuelle) et sur quels articles ils divergent (et donc où la réforme doit être débattue). C'est un outil de cartographie des désaccords, pas un outil de résolution des désaccords.
// Modèle B — plusieurs cadres coexistent pour le même (Space, Time)
// Chaque ${Author} est un namespace autonome
namespace Law.France2026.Etalab;
[Article("L132-4", Codification = "Code de l'environnement")]
public sealed class ArticleEnvL132_4
{
[Paragraph(1, Text = "L'eau et les milieux aquatiques [...]")]
[Measure(MeasureKind.Regulation, typeof(DrinkingWater))]
[Status(StatusKind.Public)] // Etalab : l'eau est un bien public
public void Paragraph1() { }
}
namespace Law.France2026.LaQuadrature;
[Article("L132-4", Codification = "Code de l'environnement")]
public sealed class ArticleEnvL132_4
{
[Paragraph(1, Text = "L'eau et les milieux aquatiques [...]")]
[Measure(MeasureKind.Regulation, typeof(DrinkingWater))]
[Status(StatusKind.Commons)] // LaQuadrature : l'eau est un commun
public void Paragraph1() { }
}La conséquence architecturale est profonde. Le bridge Source Generator doit accepter plusieurs cadres simultanément et émettre des diagnostics comparatifs. Le Law.QualityGate produit un rapport par cadre plus un rapport de divergence inter-cadres. Et le ConsensusScorer — le cinquième régime d'usage décrit en Partie 12 — Les six régimes — calcule pour chaque article son score de consensus à travers les cadres concurrents et exhibe les zones où les cadres divergent.
// Le ConsensusScorer compare les cadres pour un même article
// et exhibe les divergences comme données politiques adressables
public sealed class ConsensusResult
{
public ArticleFqn Article { get; init; }
public IReadOnlyDictionary<string, StatusKind> StatusByAuthor { get; init; }
public decimal ConsensusScore { get; init; } // 0.0 = divergence totale, 1.0 = unanimité
// La divergence n'est pas un bug — c'est de l'information politique précieuse
public bool HasDivergence => ConsensusScore < 1.0m;
// Les zones de divergence sont les zones où le débat politique est le plus nécessaire
public IReadOnlyList<DivergenceDetail> Divergences { get; init; }
}Ce qui est politiquement précieux dans le modèle B, c'est que le désaccord devient typé. Quand Law.France2026.Etalab et Law.France2026.LaQuadrature divergent sur le statut de l'eau, le ConsensusScorer ne dit pas "il y a un problème" — il dit "sur l'article L132-4 du Code de l'environnement, Etalab attribue StatusKind.Public et LaQuadrature attribue StatusKind.Commons, et cette divergence concerne l'actif DrinkingWater". Le désaccord est adressable parce qu'il a un type, un lieu, une portée. C'est la première fois qu'un débat politique peut porter clairement sur les cadres mentaux et pas seulement sur leurs conséquences observables.
Modèle C — Génération radicalement ouverte (commons numérique)
Le troisième modèle pousse la logique du modèle B jusqu'à son terme. Pas d'accréditation. Pas de forge centralisée. Pas de maintainers élus. Chaque cadre Law.${Space}${Time}.${Author} peut être généré par n'importe quel auteur, et chaque article à l'intérieur d'un cadre est lui-même un commun gouverné par les règles d'Ostrom à l'échelle de son groupe d'usagers. C'est le modèle "lex commons" — le droit typé comme un bien commun numérique radical, sans intermédiaire institutionnel entre le contributeur et le corpus.
Le repo est fédéré — possiblement via un protocole de type ActivityPub adapté au code — et aucun point central ne filtre les publications. L'avantage est vertigineux : aucune barrière à l'entrée, quiconque peut générer son propre cadre, et c'est l'usage et la réputation qui décident lesquels survivent. Un collectif de juristes climatiques de Montpellier peut publier Law.France2026.JuristesClimatMontpellier.Dsl le même jour qu'Etalab publie sa version, et les deux cadres coexistent dans l'écosystème sans que l'un ait besoin de la permission de l'autre. Le système est alors une véritable grammaire de grammaires : chaque auteur produit sa grammaire juridique, et l'infrastructure produit les conditions de leur coexistence.
La limite est sérieuse : le risque d'inflation des cadres, où mille Law.France2026.${random} coexistent sans que personne ne puisse les trier. Pire : des acteurs malveillants pourraient publier des cadres intentionnellement erronés, et sans registre de confiance, l'utilisateur final ne saurait pas lesquels sont fiables. Ce modèle suppose un protocole de réputation que personne n'a encore construit pour le droit — un problème ouvert dont la résolution est elle-même un projet de recherche.
// Modèle C — chaque cadre porte une signature cryptographique
// et une référence à son auteur décentralisé
[assembly: SignedBy("did:peer:z6MkrXs...", "2026-04-10T08:00:00Z", "base64sig...")]
namespace Law.France2026.CollectifJuristesClimat;
[Article("L132-4", Codification = "Code de l'environnement")]
public sealed class ArticleEnvL132_4
{
[Paragraph(1, Text = "L'eau et les milieux aquatiques [...]")]
[Measure(MeasureKind.Regulation, typeof(DrinkingWater))]
[Status(StatusKind.Commons)]
// Qui fait confiance à ce cadre ? La communauté qui a choisi ce DID comme auteur
public void Paragraph1() { }
}La métacratie devient alors une fonction (loi, cadre, communauté) → bool — la même loi peut être valide dans un cadre et invalide dans un autre, et la communauté décide quel cadre fait foi pour elle. C'est le principe d'Elinor Ostrom poussé jusqu'au droit lui-même : pas de solution universelle aux problèmes de gouvernance des communs, mais des règles spécifiques à chaque communauté, validées empiriquement par l'usage.
Les trois modèles ne sont pas exclusifs
Il faut résister à la tentation de voir les trois modèles comme une progression linéaire vers un idéal. Ce ne sont pas des stades de développement mais des modes de fonctionnement qui peuvent coexister dans le même écosystème. Le modèle A est le plus adapté pour les domaines où l'autorité de l'Etat est indiscutable et souhaitable — le calcul de l'impôt, les prestations sociales, la comptabilité publique. Le modèle B est le plus adapté pour les domaines où la pluralité des interprétations est constitutive du droit — le droit constitutionnel, le droit du travail, le droit de l'environnement. Le modèle C est un horizon de recherche qui pourrait devenir praticable quand les protocoles de réputation décentralisés auront mûri.
Concrètement, on peut imaginer un écosystème où Law.France2026.Etalab fait autorité pour le calcul fiscal (modèle A via Catala.Bridge), où Law.France2026.LaQuadrature et Law.France2026.CGT et Law.France2026.InstitutMontaigne coexistent sur le droit du travail (modèle B avec ConsensusScorer), et où des expérimentations locales de type Law.France2026.CollectifVillefranche émergent pour le droit municipal (modèle C naissant). L'architecture ne force aucun modèle — elle les accueille tous, parce que le ${Author} dans le namespace est le seul composant qui distingue les trois. Le même bridge, le même quality gate, le même ConsensusScorer fonctionnent indifféremment dans les trois modèles.
Le ${Author} comme trace politique
Il faut mesurer ce que le composant ${Author} de la signature META(Ex × Ty) porte réellement. Ce n'est pas un champ technique de métadonnées. C'est la réponse encodée dans le code à la question "qui a le droit de typer le droit ?". Quand le namespace dit Law.France2026.Etalab, il dit : "ce cadre a été produit par Etalab, et c'est Etalab qui en porte la responsabilité politique". Quand le namespace dit Law.France2026.CGT, il dit : "ce cadre est l'interprétation du droit français 2026 telle que la CGT l'a formalisée, avec ses propres priorités, ses propres choix de typage, et sa propre philosophie du droit du travail". Les deux cadres compilent. Les deux cadres passent le quality gate. Mais ils ne disent pas la même chose — et c'est exactement le point.
La pluralité des ${Author} pour un même (Space, Time) est donc constitutive du projet. Si on la supprimait — si on fixait ${Author} = Etalab pour toujours — on aurait un projet d'informatisation du droit parfaitement utile (c'est Catala), mais on n'aurait pas un projet de métacratie. La métacratie commence quand le citoyen peut choisir son cadre, quand le juriste peut en générer un concurrent, quand le syndicat peut montrer que son cadre diverge de celui de l'Etat sur le droit du travail, et quand le ConsensusScorer rend toutes ces divergences navigables.
Posture de design pour le ship initial
Sans réponse définitive à la question méta-sociale — et il serait malhonnête de prétendre la trancher dans un blog technique — le repo doit être structuré pour permettre les trois modèles. Concrètement, quatre décisions de design :
Premièrement, le cadre Common.France1995.Erard.Dsl du smoke test (cf. Partie 10 — Trace Dumas) n'est pas canonique. C'est un exemple historique signé par Stéphane. Le ${Author} = Erard est délibéré : il refuse d'être confondu avec une autorité. Le cadre dit : "voici comment je type la décision Dumas 1995, en connaissance de cause que d'autres pourraient typer différemment". Ce n'est pas une faiblesse — c'est l'exemple incarné du modèle B.
Deuxièmement, le bridge Source Generator accepte un Common.${Space}${Time} multiple via [assembly: SymbolSource("...", Author = "...")]. Le code est écrit pour que plusieurs cadres concurrents soient techniquement supportés dès le Ship 1, même si le ship initial n'en contient qu'un seul.
Troisièmement, aucun cadre Common.${Space}${Time} n'est publié sur NuGet officiel dans le premier ship. Le repo héberge seulement des exemples, jamais une autorité. La publication officielle est l'affaire du Ship 7 — et c'est un acte politique, pas technique.
Quatrièmement, cette partie de la série accompagne la première publication en posant la question ouvertement et en présentant les trois modèles sans trancher. Poser la question est la contribution initiale au débat. La question "qui a le droit de typer le droit ?" est une question politique qui mérite un débat politique — pas une réponse technique enfouie dans un fichier de configuration.
Pourquoi cette posture : si on tranchait pour le modèle A, on reproduirait l'asymétrie experte que le projet cherche à dépasser. Si on tranchait pour le modèle C, on construirait une infrastructure que personne n'utilise faute de protocole de signature et de réputation. Le modèle B est le seul praticable à court terme, et le code doit être écrit pour qu'il soit le chemin par défaut sans fermer la porte au modèle C quand les conditions seront réunies.
En termes de code, la posture se traduit par une règle simple : partout où le système manipule un cadre, il manipule un (Space, Time, Author) et jamais un (Space, Time) seul. La présence du composant ${Author} dans chaque chemin de données est la garantie architecturale que le système ne peut pas structurellement réduire la pluralité à l'unicité. Supprimer le ${Author} du namespace exigerait un refactoring massif — et c'est exactement le point : la pluralité est encodée dans la structure, pas dans une option configurable qu'on pourrait désactiver.
Le test décisif : l'eau potable
Pour rendre la distinction entre les trois modèles concrète, prenons un seul actif : l'eau potable. L'article L132-4 du Code de l'environnement dit que "l'eau et les milieux aquatiques sont des éléments du patrimoine commun de la nation". La question est : quel StatusKind attribuer à DrinkingWater ?
Dans le modèle A, Etalab tranche : StatusKind.Public. Le citoyen qui pense que l'eau devrait être un commun au sens d'Ostrom n'a aucun recours dans le système — il peut écrire au député mais il ne peut pas montrer dans le compilateur ce que son choix impliquerait.
Dans le modèle B, LaQuadrature publie StatusKind.Commons dans son cadre et Etalab publie StatusKind.Public dans le sien. Le ConsensusScorer exhibe la divergence. Un journaliste peut écrire : "sur l'eau potable, le cadre Etalab et le cadre LaQuadrature divergent — voici les conséquences typées de chaque choix". Le débat public gagne en précision.
Dans le modèle C, n'importe quel collectif citoyen peut publier son cadre avec son choix de StatusKind pour l'eau, et c'est la réputation du cadre dans la communauté qui détermine son poids. C'est le modèle le plus démocratique en théorie, mais aussi le plus exigeant en infrastructure de confiance.
Ce seul exemple montre pourquoi le ${Author} n'est pas une décoration : c'est la composante de la signature qui détermine si le débat sur le statut de l'eau est possible dans le système ou s'il est pré-tranché par un choix d'infrastructure.
Filiation
La question "qui a le droit de générer un cadre ?" n'est pas neuve. Elle a été posée — et partiellement résolue — dans d'autres domaines :
Elinor Ostrom (Nobel d'économie 2009) a montré empiriquement, à travers des décennies de recherche de terrain, que les communautés locales peuvent gouverner des ressources partagées sans les privatiser ni les étatiser, à condition de respecter huit principes institutionnels : limites clairement définies, adéquation entre règles et conditions locales, participation des usagers aux choix collectifs, surveillance effective, sanctions graduées, mécanismes de résolution des conflits, reconnaissance minimale par les autorités, et organisation en couches imbriquées pour les systèmes de grande échelle. Le modèle B transpose ces huit principes aux cadres juridiques typés — chaque cadre est un commun gouverné par sa communauté de contributeurs, et le ConsensusScorer joue le rôle du mécanisme de surveillance en rendant les divergences visibles sans les arbitrer autoritairement. Le huitième principe d'Ostrom (organisation en couches imbriquées) est réalisé par la hiérarchie M3 → M2 → M0 elle-même.
Yochai Benkler (The Wealth of Networks, 2006) a théorisé la peer production — la production entre pairs, décentralisée, sans hiérarchie de commande, financée par la motivation intrinsèque et la valeur d'usage. Wikipédia, Linux, les Creative Commons en sont les exemples paradigmatiques. La clé de Benkler est que le coût marginal de la coordination a chuté avec Internet, rendant viables des modes de production auparavant impossibles. Le modèle B applique le pattern de peer production à la formalisation du droit : le coût marginal de la création d'un cadre juridique concurrent est faible (le LawDslGenerator produit le squelette, l'auteur n'écrit que les spécifications), et la valeur d'usage est immense (un cadre concurrent rend un débat politique visible).
Wikipédia elle-même est le modèle B en pratique pour le savoir encyclopédique depuis 2001. Plusieurs éditeurs peuvent modifier le même article, les divergences sont tracées dans l'historique, et la communauté converge (la plupart du temps) par discussion et par preuves. L'asymétrie contributeur/lecteur (1% écrit, 99% lit) est structurelle mais n'invalide pas le modèle — elle montre simplement que la plupart des gens préfèrent lire plutôt qu'écrire, ce qui est vrai aussi pour le droit. La différence avec le droit typé est que le "lecteur" du droit est aussi son destinataire : Mathilde ne contribue pas au cadre, mais elle le consomme en compilant son cas.
Etalab et le mouvement open data 2.0 français ont démontré que l'Etat peut publier ses données de manière ouverte sans perdre en autorité — au contraire, l'ouverture renforce la confiance. Le passage des données ouvertes (modèle A pour la donnée) aux cadres ouverts (modèle B pour le droit) est un saut qualitatif considérable, mais c'est le même mouvement politique.
Catala (Merigoux et al., INRIA Prosecco) est le modèle A pur appliqué au calcul juridique. Il fonctionne remarquablement pour la DGFiP, et sa rigueur est une inspiration directe. Catala a prouvé que le droit calculable est possible en France — le projet Métacratie prolonge cette preuve en demandant : "et si le droit calculable était aussi pluriel ?". Le pont Catala.Bridge (Ship 6-bis, cf. Partie 18 — Roadmap) est le geste technique de collaboration, pas de concurrence.
Lawrence Lessig (Code: Version 2.0, 2006) a formulé l'idée que le code informatique est une forme de régulation aussi puissante que la loi — "code is law". Le projet inverse la formule : "law as code", mais sans le corollaire autoritaire que Lessig redoutait lui-même. Le ${Author} est la réponse à Lessig : si le code est loi, alors la pluralité des codeurs est la garantie démocratique. Un seul codeur du droit produit une technocratie ; mille codeurs concurrents produisent une démocratie outillée.
Christian Laval et Pierre Dardot (Commun, 2014) ont radicalisé Ostrom en montrant que le commun n'est pas seulement un type de bien économique, mais un principe politique : le principe de l'activité collective qui institue ses propres règles. Les cadres juridiques typés ne sont pas des biens au sens classique (on ne les consomme pas, on ne les épuise pas, on les forke) ; mais la pratique de les générer ensemble est un commun au sens de Laval/Dardot — une activité politique collective qui crée les règles de sa propre gouvernance. Chaque fork est un acte d'institution ; chaque merge est un acte de consensus ; chaque divergence exhibée par le ConsensusScorer est un acte de démocratie.
Pour aller plus loin
- Partie 15 — Lex Studio (précédente)
- Partie 17 — Méta-critique : manques, beautés, limites (suivante)
- Hub de la série
- Partie 12 — Les six régimes d'usage pour le
ConsensusScorer - Partie 4 — META(Ex × Ty) pour la signature formelle dont
${Author}est un composant