Constitution.Dsl — typer la séparation des pouvoirs, la hiérarchie des normes et la révision
La Partie 7 a posé Law.Dsl comme le noyau abstrait du compilateur croisé : une notion minimale de container juridique, d'acteur, de cadre interprétatif. La Partie 8 a ajouté Commons.Dsl et Citizen.Dsl pour politiser les biens et attacher une figure de destinataire aux actes. La Partie 8.5 a complété le triangle par State.Economy.Dsl — la comptabilité nationale et le budget comme type system. Il manque une racine centrale pour refermer l'acte III : la Constitution elle-même. Pas la Constitution d'un pays particulier, mais les concepts qui font qu'on peut parler de « constitution » dans la même phrase pour la France, les États-Unis, l'Allemagne ou l'Italie. Constitution.Dsl est ce vocabulaire.
Il faut justifier l'existence de cette racine séparée. Pourquoi ne pas absorber les concepts constitutionnels dans Law.Dsl ? Parce que la Constitution n'est pas une loi comme une autre : elle a une méta-position par rapport aux autres normes. Elle définit qui peut produire quelles normes, selon quelle procédure, sous quel contrôle. Dans l'architecture Kelsen, elle est au sommet de la pyramide — au-dessus d'elle, seuls les traités internationaux ratifiés occupent parfois une place discutée. La mélanger avec les lois ordinaires dans un même DSL reviendrait à confondre le métalangage avec la langue-objet. Techniquement, C# supporterait les deux — l'interface ILegalContainer de Law.Dsl peut très bien accueillir une sous-interface IConstitutionalBlock. Mais on perd alors la capacité d'outiller différemment chaque rang : les analyzers qui vérifient la cohérence d'une loi ordinaire (navette bicamérale, publication au JORF) ne sont pas ceux qui vérifient la cohérence d'une révision constitutionnelle (procédure art. 89, respect du bloc supra-législatif). Deux racines, deux jeux d'analyzers, deux rythmes de maintenance.
Cette partie fait le même geste que la Partie 8.5 : elle pose une racine indépendante, elle décrit ses concepts clés, elle énumère six analyzers Roslyn qui refusent à la compilation les violations structurelles les plus graves, elle démontre le fonctionnement sur un cas historique explosif — le référendum De Gaulle du 28 octobre 1962, qui a modifié l'article 6 de la Constitution par la voie de l'article 11 au lieu de l'article 89. Le Conseil constitutionnel s'est déclaré incompétent pour contrôler ce vice. Le compilateur, lui, ne peut pas se déclarer incompétent.
L'argument technique : Kelsen sépare les rangs, le DSL les sépare aussi
Hans Kelsen, dans la Reine Rechtslehre (1934, réécrite en 1960), pose que l'ordre juridique est une pyramide dont chaque étage tient son autorité de l'étage supérieur. La Constitution est au sommet parce qu'elle établit les règles de production des lois — elle est la norme qui dit comment faire les normes. Les lois organiques sont au-dessous parce qu'elles mettent en œuvre des dispositions constitutionnelles spécifiques (art. 34 al. 3 ou art. 46 FR). Les lois ordinaires encore en dessous. Les règlements, décrets, arrêtés, circulaires s'empilent ensuite. Cette pyramide n'est pas une fantaisie pédagogique : le Conseil constitutionnel peut annuler une loi pour violation d'une norme de rang supérieur, une cour administrative peut annuler un décret pour violation d'une loi. La hiérarchie opère.
Un DSL qui sérieuse cette hiérarchie ne peut pas mettre sur le même plan la Constitution et les textes dérivés. Les outils de vérification diffèrent : pour une loi ordinaire, on vérifie l'adoption par le Parlement, la navette bicamérale, la promulgation par le Président, la publication au JORF. Pour une révision constitutionnelle, on vérifie la procédure formelle (art. 89 ou Article V US), l'adoption par les deux chambres séparément, le vote du Congrès réuni à Versailles ou le référendum en aval. Faire un seul DSL monolithique, ce serait accumuler des attributs et des analyzers dans une classe de base gigantesque — plus simple de séparer les racines.
Le parallèle avec la comptabilité nationale posé en Partie 8.5 tient ici aussi. SEC 2010 est au droit ce que le bloc constitutionnel est aux lois dérivées : un système de règles méta qui contraint un système de règles dérivées. State.Economy.Dsl a été séparée de Law.Dsl pour la même raison — les outils ne sont pas les mêmes. Constitution.Dsl répond à la même logique.
L'argument politique : la séparation rend les prises de position plus lisibles
Il y a un deuxième argument, politique celui-là. Quand Law.France2026.CGT.Dsl et Law.France2026.Medef.Dsl s'affrontent sur le Code du travail, leurs désaccords portent sur des articles de loi ordinaire. Ils peuvent parfaitement partager le même Law.Dsl core et diverger uniquement dans les instances. Quand Constitution.France2026.Gauche.Dsl et Constitution.France2026.Droite.Dsl s'affronteront sur la VIe République, leurs désaccords porteront sur la structure même de l'édifice : proportionnelle intégrale ou majoritaire, suppression ou maintien du Sénat, référendum d'initiative citoyenne, mandat unique, etc. Les divergences ne sont plus portées par des articles — elles sont portées par des interfaces et des enums au niveau du DSL lui-même.
Séparer Constitution.Dsl comme racine permet à chaque cadre constitutionnel publié (officiel ou alternatif) de redéfinir sa propre structure sans avoir à recompiler Law.Dsl. Un think tank qui publierait Constitution.France2030.VIeRepublique.Dsl pourrait déplacer le pouvoir exécutif vers le Parlement (régime d'assemblée), ajouter un quatrième pouvoir (pouvoir citoyen direct, par contrepoint aux thèses épistocratiques que Lagasnerie critique dans L'âme noire de la démocratie, Flammarion 2026), ou retyper le Conseil constitutionnel comme organe à compétence élargie. Tout cela sans toucher à la racine Law.Dsl qui reste stable. C'est le principe open/closed du MDE Partie 6 appliqué au droit constitutionnel : les types ouverts sont au niveau du cadre, les types fermés sont au niveau de la racine technique neutre.
Concepts nucléaires de Constitution.Dsl
La racine porte sept familles de concepts, chacune réifiée par une ou deux interfaces et quelques phantoms. J'énumère ici les concepts, en donnant à chaque fois le code C# minimal qui les introduit et la justification doctrinale qui les autorise.
Les pouvoirs : IPower et ses quatre phantoms
Montesquieu, De l'esprit des lois (1748), livre XI chapitre VI, établit les trois pouvoirs fondamentaux : législatif, exécutif, judiciaire. James Madison, dans le Federalist n° 51 (1788), reprend et systématise : If men were angels, no government would be necessary. If angels were to govern men, neither external nor internal controls on government would be necessary. In framing a government which is to be administered by men over men, the great difficulty lies in this: you must first enable the government to control the governed; and in the next place, oblige it to control itself. Le principe est sédimenté. Toute constitution démocratique pose cette tripartition, quoique sous des formes variables.
Une quatrième catégorie mérite discussion : le pouvoir constitutionnel au sens strict — celui du Conseil constitutionnel en France, de la Cour suprême aux États-Unis, du Bundesverfassungsgericht en Allemagne. Carré de Malberg (1920, Contribution à la théorie générale de l'État) le distingue comme pouvoir de contrôle de la régularité des normes, qui n'est ni législatif (il n'édicte pas de règles générales), ni exécutif (il n'applique pas les lois), ni strictement judiciaire (il ne tranche pas de litiges particuliers entre parties privées). La doctrine française contemporaine (Rousseau, Duhamel, Carcassonne) oscille : certains intègrent le Conseil constitutionnel dans le pouvoir judiciaire élargi, d'autres le laissent à part. Le DSL tranche pour l'option séparée, en ajoutant un quatrième phantom Constitutional. Ce choix est contestable doctrinalement — mais il est explicite, il apparaît dans le code, il peut être retypé par un cadre alternatif.
public interface IPower { }
public sealed class Legislative : IPower { public static readonly Legislative Instance = new(); }
public sealed class Executive : IPower { public static readonly Executive Instance = new(); }
public sealed class Judicial : IPower { public static readonly Judicial Instance = new(); }
public sealed class Constitutional : IPower { public static readonly Constitutional Instance = new(); }La hiérarchie des normes : IConstitutionalBlock, NormRankFr, NormRankUs
Chaque tradition juridique a sa propre pyramide. En France : bloc constitutionnel > lois organiques > traités ratifiés > lois ordinaires > ordonnances > décrets > arrêtés > circulaires. Aux États-Unis : bloc constitutionnel > federal statutes > treaties > federal regulations > executive orders > agency rules. Les rangs ne se transposent pas directement : les lois organiques françaises n'ont pas d'équivalent américain ; les Executive Orders américains occupent une position que les décrets du Président français ne recouvrent qu'incomplètement (un décret français peut être un décret d'application de loi, un décret autonome art. 37, un décret en Conseil d'État, un décret en Conseil des ministres — quatre choses distinctes).
Le DSL encode donc deux enums distincts, NormRankFr et NormRankUs, au lieu d'un seul unifié. La tentation d'un enum universel serait une faute — elle supposerait une hiérarchie transnationale qui n'existe pas. Les attributs [NormFr(rank)] et [NormUs(rank)] marquent une classe comme portant un rang de norme particulier. L'attribut [Supersedes(typeof(AutreNorm))] déclare que cette norme en abroge une autre — l'analyzer CST001 vérifiera que le rang supersedé n'est pas supérieur au rang supersédant.
public enum NormRankFr {
ConstitutionalBloc = 0,
OrganicLaw = 1,
TreatyRatified = 2,
OrdinaryLaw = 3,
Ordonnance = 4,
Decree = 5,
Arrete = 6,
Circulaire = 7,
}
public enum NormRankUs {
ConstitutionalBloc = 0,
FederalStatute = 1,
TreatyRatified = 2,
FederalRegulation = 3,
ExecutiveOrder = 4,
AgencyRule = 5,
}On notera que les traités ratifiés ont rang 2 en France (art. 55 de la Constitution : supérieurs aux lois) et également 2 aux États-Unis (Article VI clause 2 : supreme Law of the Land). C'est une coïncidence heureuse, pas une universalité — un cadre qui porterait sur la Constitution allemande devrait introduire un rang spécifique pour le droit de l'Union européenne au-dessus des lois fédérales, après Solange II (1986) et Maastricht-Urteil (1993).
Les organes : IConstitutionalOrgan et IConstitutionalAct<TOrgan, TPower>
Un organe est une entité de droit public qui opère dans un scope de pouvoir déterminé. Le Parlement opère dans Legislative, le Gouvernement dans Executive, les juridictions ordinaires dans Judicial, le Conseil constitutionnel dans Constitutional. Chaque acte qu'un organe émet est typé IConstitutionalAct<TOrgan, TPower> — on y trouve à la fois le type de l'organe émetteur et le type du pouvoir exercé. Normalement, les deux correspondent : un acte de Parlement est IConstitutionalAct<Parlement, Legislative>, un décret du Président est IConstitutionalAct<Presidence, Executive>.
La subtilité arrive quand un organe déborde de son scope. Cas français : l'article 38 autorise le Gouvernement à prendre des ordonnances, c'est-à-dire à légiférer. L'ordonnance est donc IConstitutionalAct<Gouvernement, Legislative> — mais avec une habilitation explicite. Cas américain : la non-delegation doctrine (clarifiée récemment par West Virginia v. EPA 2022 sur la Major Questions Doctrine) limite ce que le Congrès peut déléguer à l'exécutif, mais certaines lois l'autorisent ponctuellement — Section 232 du Trade Expansion Act 1962 (tarifs), IEEPA 1977 (sanctions économiques), etc. L'Executive Order qui impose un tarif doit porter [CongressionalAuthorization(typeof(Section232TradeExpansionAct1962))]. L'analyzer CST002 rejette sinon.
public interface IConstitutionalOrgan {
string Designation { get; }
Type Scope { get; } // : IPower
Type ConstitutionalBasis { get; } // : IConstitutionalBlock
}
public interface IConstitutionalAct<TOrgan, TPower>
where TOrgan : IConstitutionalOrgan
where TPower : IPower
{
Type IssuingOrgan { get; }
}La composition par paramètres génériques remplace l'héritage : on n'a pas IExecutiveAct, ILegislativeAct, IJudicialAct comme interfaces distinctes, mais un seul IConstitutionalAct<,> paramétré. Cela permet une inspection uniforme par les analyzers et évite la prolifération d'interfaces quasi-identiques.
La procédure de révision : IConstitutionalRevision et ses procédures typées
Modifier la Constitution n'est pas comme modifier une loi ordinaire. Chaque système a sa procédure spécifique. En France, l'article 89 prévoit deux voies : le Congrès (Parlement réuni à Versailles, 3/5e des suffrages exprimés) ou le référendum. Aux États-Unis, l'Article V prévoit aussi deux voies pour la proposition (2/3 du Congrès, ou convention demandée par 2/3 des États) suivie d'une ratification par 3/4 des États.
Le DSL fixe l'ensemble des procédures valides comme un ensemble fermé d'interfaces. Une classe marquée IConstitutionalRevision doit implémenter exactement une procédure parmi cet ensemble. L'analyzer CST003 rejette toute combinaison qui n'en ferait pas partie. Le cas nucléaire : le référendum De Gaulle de 1962, qui a utilisé l'article 11 (référendum législatif) au lieu de l'article 89 (procédure de révision) pour modifier l'article 6 de la Constitution. Le Conseil constitutionnel s'est déclaré incompétent pour contrôler cette irrégularité (décision n° 62-20 DC du 6 novembre 1962). Le compilateur ne peut pas.
public interface IConstitutionalRevision {
Type Modifies { get; }
}
public interface IAmendmentProcedure<TFramework> { string Designation { get; } }
public sealed class Article89Congress { }
public sealed class Article89Referendum { }
public interface IArticle89Congress : IAmendmentProcedure<Article89Congress> { }
public interface IArticle89Referendum : IAmendmentProcedure<Article89Referendum> { }
public sealed class ArticleVCongressProposal { }
public sealed class ArticleVConventionProposal { }
public interface IArticleVCongressProposal : IAmendmentProcedure<ArticleVCongressProposal> { }
public interface IArticleVConventionProposal : IAmendmentProcedure<ArticleVConventionProposal> { }
// Volontairement distinct : art. 11 n'est PAS une procédure de révision.
public sealed class Article11 { }
public interface IReferendum<TBasis> { string Designation { get; } }La séparation entre IAmendmentProcedure<> et IReferendum<> est sémantique, pas technique. Elles pourraient partager la même structure en C#. Mais on les garde distinctes parce que le typage doit correspondre à la distinction doctrinale : un référendum législatif (art. 11) n'est pas une procédure de révision, et le compilateur doit refuser de les confondre.
Le contrôle de constitutionnalité : IConstitutionalReview et IPractices<>
Trois modalités doctrinalement distinctes. En France, contrôle a priori (art. 61 : saisine par 60 parlementaires, 60 sénateurs, Président, Premier ministre, Président de l'Assemblée, Président du Sénat — avant promulgation). Depuis 2008, contrôle a posteriori via la Question Prioritaire de Constitutionnalité (art. 61-1 : soulevée par une partie à l'occasion d'une instance, transmise par le Conseil d'État ou la Cour de cassation au Conseil constitutionnel). Aux États-Unis, judicial review (Marbury v. Madison 1803) : contrôle concret, incident, exercé par toute cour fédérale et in fine par la Cour suprême sur recours.
public interface IConstitutionalReview { }
public sealed class PriorReview : IConstitutionalReview { }
public sealed class PosteriorReview : IConstitutionalReview { }
public sealed class JudicialReview : IConstitutionalReview { }
public interface IPractices<TReview> where TReview : IConstitutionalReview { }Un organe peut pratiquer plusieurs modalités. Le Conseil constitutionnel français pratique PriorReview et PosteriorReview. La Cour suprême américaine pratique JudicialReview. Un cadre constitutionnel alternatif pourrait ajouter ConcreteReview, AbstractReview, CollectiveReview, etc. — la liste est ouverte à l'extension.
Les droits fondamentaux : IFundamentalRight et le triple test
La CEDH, dans l'arrêt Handyside c. Royaume-Uni (1976), systématise le triple test : une restriction à un droit fondamental n'est autorisée que si elle est légitime (but défini par la loi), nécessaire (proportionnée au but) et proportionnée (la moins intrusive possible). La jurisprudence constitutionnelle française a intégré ce triple test depuis la décision n° 2015-713 DC. Le DSL encode cette contrainte comme quatre attributs : [Infringes(typeof(IFundamentalRight))] déclare l'atteinte, [Legitimate] + [Necessary] + [Proportionate] la justifient. L'analyzer CST004 rejette (en warning opt-in error) les actes qui portent [Infringes] sans les trois compagnons.
Le bicaméralisme : BicameralPassageAttribute et PromulgatedAttribute
Une loi promulguée doit avoir traversé une navette bicamérale complète. En France, art. 45 : Assemblée et Sénat doivent adopter le même texte, à défaut Commission Mixte Paritaire puis dernier mot de l'Assemblée. Aux États-Unis, Article I Section 7 : House + Senate doivent adopter le identical text avant que le Président promulgue. Le DSL encode les deux voies valides dans BicameralPassageAttribute, l'analyzer CST006 rejette toute promulgation qui n'en suivrait pas une.
Paire 1 : séparation des pouvoirs
La séparation des pouvoirs est le principe le plus ancien et le plus cité de tout le corpus constitutionnel occidental. Elle est pourtant, dans sa forme pédagogique ordinaire, présentée par un schéma textuel flou : trois boîtes (Législatif / Exécutif / Judiciaire), trois flèches qui se croisent, des légendes vagues (« contrôle », « nomme », « sanctionne »). Ce schéma-type a une qualité — il est mémorisable — mais il rend invisible la mécanique juridique réelle : qui peut émettre quel acte, dans quelle situation, et surtout qui vérifie que l'émetteur était bien dans son scope.
Le type system fait le travail inverse. Il réifie chaque pouvoir comme phantom (Legislative, Executive, Judicial, Constitutional), chaque organe comme interface à scope typé, et chaque acte comme IConstitutionalAct<TOrgan, TPower>. La vérification devient compile-time : si un organe exécutif prétend émettre un acte législatif, soit il exhibe une habilitation typée (art. 38 FR ou Congressional Authorization US), soit le compilateur rejette. Le contrôle a posteriori par le Conseil constitutionnel ou la Cour suprême ne disparaît pas, mais il est doublé par un contrôle a priori mécanique — qui attrape les erreurs les plus structurelles avant même qu'elles n'arrivent à la saisine.
Paire 2 : pyramide des normes
La pyramide kelsénienne est le deuxième invariant du corpus constitutionnel. Dans sa forme pédagogique, c'est un empilement de rectangles : Constitution au sommet, lois organiques, lois ordinaires, règlements, etc. Le défaut de cette représentation est qu'elle ne contrôle rien : elle décrit une structure sans indiquer ce qui se passe quand un rang inférieur prétend contredire un rang supérieur. Dans la pratique, la sanction est toujours a posteriori — annulation par le Conseil constitutionnel ou les juridictions administratives — et elle est contentieuse, lente, incomplète.
Le type system rend cette hiérarchie exécutable. L'enum fermé NormRankFr / NormRankUs donne à chaque norme un rang numérique compile-time. L'attribut [Supersedes(typeof(...))] déclare explicitement qu'une norme en remplace une autre. L'analyzer CST001 vérifie la cohérence : si le rang supersédant est numériquement inférieur (rang supérieur dans la pyramide) au supersédé, tout va bien. Si c'est l'inverse — un décret qui prétend abroger une loi, une circulaire qui prétend modifier un décret — l'erreur est compile-time.
Paire 3 : procédure de révision — le cas De Gaulle 1962
La troisième paire met en scène le smoke test de la Partie. En 1962, De Gaulle utilise l'art. 11 (référendum législatif) pour modifier l'art. 6 de la Constitution (suffrage universel direct pour l'élection du Président). L'art. 89 aurait imposé un vote préalable par chacune des deux chambres avant référendum ou Congrès. Le Conseil constitutionnel saisi par Gaston Monnerville, président du Sénat, se déclare incompétent par la décision n° 62-20 DC du 6 novembre 1962 : il ne contrôle pas les lois référendaires qui sont « l'expression directe de la souveraineté nationale ». La révision est promulguée, le suffrage universel direct entre en vigueur, tout le monde s'y habitue. Seule la doctrine juridique (Avril, Carcassonne, Duhamel) continue à considérer la procédure comme viciée.
C'est un cas où la légitimité politique (le peuple a voté, la participation fut massive) a primé sur la légalité juridique (la procédure de l'art. 89 n'a pas été suivie). Le Conseil constitutionnel, dans sa position d'incompétence, a de fait validé ce primat. Le type system ne peut pas adopter cette posture — parce qu'il n'est pas une juridiction, il est un vérificateur mécanique. Il doit trancher entre deux typages possibles : soit l'acte est une révision constitutionnelle, et alors il porte obligatoirement une procédure valide parmi l'ensemble fermé {IArticle89Congress, IArticle89Referendum, ...} — position orthodoxe, qui relit 1962 comme un passage art. 89 raté. Soit l'acte n'est pas une révision, et alors il abandonne le marqueur IConstitutionalRevision pour ne garder que IReferendum<Article11> — position gaulliste, qui relit 1962 comme une expression directe de souveraineté non-réductible aux catégories constitutionnelles classiques.
Les deux typages compilent. L'un ou l'autre est choisi par qui écrit le code, c'est-à-dire par celui qui publie le cadre Constitution.France1958.Official.Dsl (Partie 9-ter) ou un cadre alternatif Constitution.France1958.Avril.Dsl. La politique se relit dans le choix de typage — elle ne se dissout pas dans une ambiguïté narrative.
Les six analyzers Roslyn
Six diagnostics, tous implémentés comme DiagnosticAnalyzer Roslyn dans le projet Constitution.Dsl.Analyzers. Chacun est un outil de vérification structurelle indépendant — ils peuvent tourner en parallèle, ils ne partagent pas d'état, ils s'alignent tous sur les conventions de AnalyzerReleases.Shipped.md / AnalyzerReleases.Unshipped.md imposées par EnforceExtendedAnalyzerRules=true.
CST001 — NormHierarchyViolation (Error)
Scanne chaque classe portant [NormFr(rank)] ou [NormUs(rank)]. Pour chaque attribut [Supersedes(typeof(N))], compare le rang de la classe au rang de N. Si la classe prétend abroger une norme de rang supérieur (valeur enum inférieure — convention Kelsen : 0 = sommet), émet une erreur compile-time. La règle est stricte et n'admet pas d'exception automatique : une loi qui veut déplacer une autre loi de rang supérieur doit d'abord justifier un reclassement explicite, ce qui casse la chaîne d'abrogation.
CST002 — OrganOutOfPowerScope (Error)
Scanne chaque classe implémentant IConstitutionalAct<TOrgan, TPower>. Lit le scope de TOrgan (via l'attribut [OrganScope(typeof(...))]). Si le scope de l'organe diffère de TPower, vérifie la présence d'une habilitation ([Habilitation(typeof(...))] côté FR ou [CongressionalAuthorization(typeof(...))] côté US). Sinon, émet une erreur : {ClassName} émet IConstitutionalAct<{OrganName}, {PowerName}> alors que l'organe opère dans le scope {OrganScope}. Aucune habilitation n'est attachée.
L'analyzer est conçu pour le cas canonique de la Partie 9-ter : Executive Order qui tarife les importations (pouvoir réservé au Congrès par Article I Section 8). Il fonctionnera aussi, par symétrie, pour toute ordonnance française art. 38 sans loi d'habilitation explicite.
CST003 — AmendmentProcedureViolation (Error)
C'est l'analyzer central de cette Partie, celui qui porte le smoke test. Scanne chaque classe implémentant IConstitutionalRevision. Vérifie que la classe implémente aussi au moins une procédure parmi l'ensemble fermé {IArticle89Congress, IArticle89Referendum, IArticleVCongressProposal, IArticleVConventionProposal}. Sinon, émet une erreur compile-time. Le cas 1962 (IConstitutionalRevision + IReferendum<Article11>) est rejeté parce que IReferendum<> n'appartient pas à cet ensemble.
Le diagnostic de l'analyzer est volontairement verbeux — il énumère l'ensemble des procédures acceptables et précise que IReferendum<Article11> n'en fait pas partie. Le but est d'aider le développeur à comprendre pourquoi son code est rejeté et quelles sont les deux voies de correction (accepter le vice art. 89, ou renoncer au statut de révision).
CST004 — FundamentalRightInfringement (Warning, opt-in Error)
Scanne chaque classe portant [Infringes(typeof(IFundamentalRight))]. Vérifie la présence des trois attributs compagnons : [Legitimate], [Necessary], [Proportionate]. Émet un warning pour chaque attribut manquant. Le choix du niveau Warning (et non Error) tient à la phase : au stade projet de texte, il est normal que la justification soit incomplète. Un cadre strict (Constitution.France2026.Gauche.Dsl) peut remonter le diagnostic en Error via <WarningsAsErrors>CST004</WarningsAsErrors> dans son .csproj.
CST005 — UnpublishedNormExecution (Error)
Scanne chaque méthode portant [Enforce]. Vérifie que la classe déclarante porte [PublishedInOfficialJournal(Date)]. Sinon, émet une erreur : la méthode prétend appliquer une norme qui n'a pas été publiée au JORF (FR) / Federal Register (US), donc qui n'est pas exécutoire (art. 1 Code civil français / Federal Register Act 1935 pour les États-Unis).
CST006 — BicameralityViolation (Error)
Scanne chaque classe portant [Promulgated]. Vérifie la présence et la validité de l'attribut [BicameralPassage(...)]. Deux configurations valides : lowerHouseAdopted=true + upperHouseAdopted=true (navette classique FR / identical text US), ou commissionMixteParitaire=true + lastWordLowerHouse=true (voie CMP + dernier mot AN, art. 45 al. 4 FR). Toute autre configuration déclenche une erreur.
Infrastructure technique réutilisée
Comme pour State.Economy.Dsl en Partie 8.5, on ne réinvente rien. Les patterns viennent directement du monorepo FrenchExDev_i2 et des parties précédentes :
- Composition par paramètres génériques plutôt qu'héritage —
IConstitutionalAct<TOrgan, TPower>avec deux paramètres,IAmendmentProcedure<TFramework>avec un paramètre. Même geste queIAction<TProgram>de la Partie 8.5 pour la hiérarchie LOLF. - Phantom types à singleton Instance —
Legislative.Instance,Executive.Instance,Judicial.Instance,Constitutional.Instance. Même pattern que les secteurs SEC 2010 (S11.Instance,S13.Instance) ou les opérations économiques (P1.Instance,B1g.Instance) en Partie 8.5. - Attributs + analyzers Roslyn —
[NormFr(rank)]+[Supersedes(typeof(...))]+Cst001NormHierarchyViolationAnalyzer. Même structure que[Expenditure]+Eco002UnattachedBudgetExpenditureAnalyzeren Partie 8.5. - Analyzer release tracking —
AnalyzerReleases.Shipped.md+AnalyzerReleases.Unshipped.mdavec format strict (headerRule ID | Category | Severity | Notes), exigé parEnforceExtendedAnalyzerRules=truedans le.csproj. Contrainte déjà rencontrée et résolue en Partie 8.5. - Solution C# unifiée — tous les projets référencés dans
ConstitutionEconomy.slnavec une organisation en solution folders (demos,analyzers,instances) viaNestedProjects. Extension incrémentale de la solution de la Partie 8.5.
Kelsen, Reine Rechtslehre (1934, 1960) — la pyramide des normes
Hans Kelsen publie la première version de la Reine Rechtslehre (Théorie pure du droit) en 1934, en exil à Genève après avoir été chassé d'Autriche par les lois anti-juives. Il y propose une théorie formelle du droit qui cherche à se dégager de toute fondation morale, sociologique ou politique — d'où le qualificatif pure. Le droit est, pour Kelsen, un système de normes hiérarchisées dont chacune tient son autorité de la norme immédiatement supérieure, jusqu'à une norme fondamentale (Grundnorm) postulée à la racine. La pyramide kelsénienne n'est pas une image : c'est une structure formelle qui rend compte de la cohérence interne d'un ordre juridique.
La seconde édition de 1960 raffine et complète le dispositif. Kelsen y répond aux critiques sociologiques (Max Weber, Eugen Ehrlich) qui reprochent à la théorie pure de faire abstraction de l'effectivité sociale du droit. Il maintient la pureté méthodologique tout en concédant que l'effectivité est une condition de validité de l'ordre juridique pris globalement — une nuance qui n'affaiblit pas la pyramide mais la replace dans un contexte d'efficacité empirique.
Ce qui fait travailler Kelsen pour nous, c'est moins la Grundnorm — concept controversé, parfois métaphysiquement embarrassant — que la mécanique de subordination qu'il explicite. Chaque norme dérivée est mesurable en termes de conformité à la norme supérieure. Cette mesurabilité, abstraite chez Kelsen, devient concrète dans notre DSL : l'attribut [NormFr(rank)] et l'enum NormRankFr encodent directement la pyramide, l'analyzer CST001 mécanise la vérification de conformité. Kelsen avait pensé un type system implicite qui attendait un compilateur pour devenir opérationnel — c'est ce que nous faisons.
On notera, pour être complet, que la pyramide stricte est contestée par plusieurs courants contemporains. Hart (The Concept of Law, 1961) propose une règle de reconnaissance plutôt qu'une Grundnorm. Dworkin (Law's Empire, 1986) substitue à la pyramide une pluralité de principes en tension permanente, arbitrés par le juge-Hercule. MacCormick (Rhetoric and the Rule of Law, 2005) parle de systems of institutional normative order. Le DSL que je pose ne prétend pas trancher ces débats — il adopte la version kelsénienne par commodité technique (elle se code bien en enum fermé et en attributs), et laisse ouvert le pluralisme des cadres alternatifs.
Montesquieu, De l'esprit des lois (1748) — la séparation des pouvoirs
Montesquieu publie De l'esprit des lois en 1748, après vingt années de travail. Le livre XI, chapitre VI (De la constitution d'Angleterre), pose le principe désormais canonique : Il y a dans chaque État trois sortes de pouvoirs : la puissance législative, la puissance exécutrice des choses qui dépendent du droit des gens, et la puissance exécutrice de celles qui dépendent du droit civil. Cette tripartition n'est pas de Montesquieu seul — Locke l'avait esquissée dans le Second traité du gouvernement civil (1689) avec une partition légèrement différente (législatif / exécutif / fédératif) — mais c'est Montesquieu qui en fait un principe de technique politique diffusable.
La thèse centrale de Montesquieu est mécaniste : Pour qu'on ne puisse abuser du pouvoir, il faut que, par la disposition des choses, le pouvoir arrête le pouvoir. Ce n'est pas la bonne volonté des gouvernants qui garantit la liberté — c'est la structure institutionnelle qui rend l'abus difficile. La séparation des pouvoirs est donc une architecture, pas une morale. Le parallèle avec le type system est exact : la rigueur des types n'est pas la bonne volonté des développeurs — c'est une structure qui rend certaines erreurs mécaniquement impossibles.
Les Federalist Papers, rédigés en 1787-1788 par Madison, Hamilton et Jay pour défendre la ratification de la Constitution américaine, reprennent explicitement Montesquieu. Le n° 47 de Madison cite Montesquieu textuellement : The accumulation of all powers, legislative, executive, and judiciary, in the same hands, whether of one, a few, or many, and whether hereditary, self-appointed, or elective, may justly be pronounced the very definition of tyranny. Le n° 51 va plus loin et ajoute le principe des checks and balances : non seulement les pouvoirs sont séparés, mais chacun a des moyens de contrôle sur les autres (véto présidentiel, ratification des traités par le Sénat, impeachment, nomination des juges par le Président avec confirmation du Sénat). C'est un raffinement majeur par rapport à la formulation montesquienne pure, que le type system doit pouvoir accueillir — d'où l'attribut [Habilitation] côté FR (art. 38) et [CongressionalAuthorization] côté US (Section 232, IEEPA), qui permettent explicitement à un organe de sortir de son scope sous condition d'autorisation typée.
La critique marxiste classique — de la séparation des pouvoirs comme mystification bourgeoise qui masque l'unité réelle du pouvoir de classe — a sa force propre (Lordon la rejoue régulièrement dans les années 2010-2020), mais elle ne disqualifie pas le dispositif technique de Montesquieu. Elle change l'échelle d'analyse : le type system peut parfaitement modéliser la séparation des pouvoirs formelle et laisser à un autre DSL (Economy.Marx.Dsl, par exemple, qui n'existe pas encore) le soin de mesurer la concentration économique réelle. Les deux lectures ne s'excluent pas — elles opèrent à des niveaux différents du compilateur croisé.
Carré de Malberg, Contribution à la théorie générale de l'État (1920-1922) — le pouvoir constitutionnel
Raymond Carré de Malberg publie sa Contribution à la théorie générale de l'État en deux tomes (1920, 1922). C'est l'œuvre de référence de la doctrine constitutionnelle française classique, qui reste enseignée dans toutes les facultés de droit public un siècle plus tard. Sa position centrale est que la souveraineté appartient à la Nation — entité abstraite distincte du peuple actuel — et qu'elle s'exprime par le représentant (Parlement) plutôt que directement (référendum). Carré de Malberg est donc un « légaliste » dans la typologie classique, par opposition aux gaullistes qui feront primer l'expression directe de la souveraineté dans le référendum de 1962.
Ce qui nous intéresse dans Carré de Malberg, c'est la distinction catégorielle qu'il opère entre les différents pouvoirs juridiques. Là où Montesquieu distinguait trois pouvoirs (législatif, exécutif, judiciaire), Carré de Malberg propose d'ajouter un pouvoir constitutionnel distinct — le pouvoir de contrôler la régularité des normes. À l'époque (1920), ce pouvoir est quasi-inexistant en France : pas de cour constitutionnelle, pas de contrôle de constitutionnalité des lois. La proposition de Carré de Malberg est donc prospective. Elle sera réalisée seulement en 1958 avec la création du Conseil constitutionnel par la Constitution de la Ve République.
Le DSL adopte cette distinction catégorielle en introduisant le phantom Constitutional comme quatrième pouvoir, distinct de Judicial. Ce choix n'est pas innocent : un cadre alternatif peut parfaitement fusionner les deux en ne gardant que Judicial (position hartienne ou dworkinienne, où le contrôle constitutionnel est une activité judiciaire spécialisée) ou en subdiviser Constitutional en plusieurs sous-catégories (contrôle abstrait, contrôle concret, interprétation conforme, déclaration d'inconstitutionnalité). La flexibilité est dans le DSL.
Bertrand Meyer, Object-Oriented Software Construction (1988, 1997) — le contrat comme infrastructure
Bertrand Meyer, dans la première édition d'Object-Oriented Software Construction (1988) et de manière systématisée dans la deuxième édition (1997), pose le principe du design by contract : chaque composant logiciel doit spécifier ses pré-conditions, ses post-conditions et ses invariants, qui deviennent des obligations contractuelles vérifiables au runtime (et, dans certains cas, au compile-time). La formalisation repose sur le langage Eiffel, dont Meyer est l'auteur, mais le principe se transpose à tout langage statiquement typé qui supporte des attributs et des analyzers.
Le parallèle avec le DSL constitutionnel est direct. [Infringes(typeof(IFundamentalRight))] est une pré-condition structurelle : l'acte déclare qu'il va porter atteinte à un droit. [Legitimate] + [Necessary] + [Proportionate] sont les post-conditions qui doivent accompagner toute pré-condition [Infringes] — l'analyzer CST004 vérifie le respect du contrat. De même, [Promulgated] est une post-condition de tout parcours législatif, qui ne peut être satisfaite sans que la pré-condition [BicameralPassage] soit elle-même satisfaite — l'analyzer CST006 vérifie la chaîne.
Meyer, qui est l'un des interlocuteurs constants de la communauté Éiffel depuis 1985, insiste dans sa deuxième édition sur le caractère épistémique du contrat : il n'est pas là pour attraper des bugs au moment de l'exécution, mais pour expliciter ce que le code affirme. Le contrat est, avant tout, une communication entre développeurs et entre équipes. Le transport à Constitution.Dsl est évident : les attributs ne sont pas là seulement pour déclencher des analyzers, mais pour rendre lisible ce que l'acte constitutionnel affirme. La séparation IConstitutionalAct<TOrgan, TPower> + [Habilitation] est un contrat qui rend lisible, au premier regard sur le type, que l'acte exige une habilitation pour être valide hors scope.
Catala (Merigoux, Huttner, Protzenko, 2022, POPL) — les cadres nationaux vivants
Le projet Catala, présenté à POPL 2022 par Denis Merigoux, Nicolas Chataing, Jonathan Protzenko et al., est la démonstration vivante qu'on peut traduire fidèlement un corpus juridique dense en un langage formellement vérifiable. L'équipe a travaillé avec la DGFiP française pour traduire des pans entiers du Code général des impôts (impôt sur le revenu, CSG, prélèvement à la source) en Catala, avec résultats testés contre les simulateurs officiels de Bercy. La précision obtenue — au centime près sur des millions de cas de test — démontre que le législateur peut, en principe, produire un texte formellement vérifiable, et que ce n'est pas une utopie académique.
Le projet est particulièrement éclairant par ce qu'il évite : Catala ne cherche pas à remplacer le droit, il cherche à offrir une représentation vérifiable du droit existant. Il ne propose pas de nouveaux textes, il propose une machine à vérifier la cohérence des textes en vigueur. Le parallèle avec Constitution.Dsl est direct et prudent : nous ne proposons pas une nouvelle Constitution, nous proposons un vocabulaire qui permette à plusieurs cadres constitutionnels (officiels, syndicaux, alternatifs) de se décrire dans un espace partagé où la cohérence structurelle est vérifiable mécaniquement.
Catala, en 2026, a essaimé dans plusieurs juridictions (projet pilote aux Pays-Bas sur la fiscalité des non-résidents, discussion ouverte avec HMRC britannique, proof of concept sur le Code de la sécurité sociale suisse). L'infrastructure est reproductible. La politique ne l'est pas — chaque adoption nationale de Catala est une négociation politique entre l'équipe formaliste et l'administration concernée. La leçon pour Constitution.Dsl est que le compilateur politique ne s'imposera pas par supériorité technique — il s'imposera (ou pas) par la qualité des jonctions politiques qu'il permettra. La décision de publier un cadre Constitution.France2026.Officiel.Dsl sera politique avant d'être technique.
Critique et limites
Le type system constitutionnel a des limites structurelles qu'il faut exposer plutôt que masquer. La première est la question du texte : le DSL encode la structure de la Constitution (pouvoirs, organes, procédures, droits) mais pas le texte littéral des articles. Un cadre constitutionnel alternatif qui voudrait proposer la VIe République ne peut pas se contenter de changer quelques phantom types — il faut rédiger les articles eux-mêmes, dans la langue humaine, et les soumettre au débat. Le type system est un squelette, pas une Constitution.
La deuxième limite est la question du contrôle politique. Le type system attrape les erreurs structurelles (violation de hiérarchie, organe hors scope, révision sans procédure) mais il n'attrape pas les erreurs politiques : une loi parfaitement régulière sur le plan procédural peut être profondément injuste, oppressive, discriminatoire. Le DSL encode le triple test CEDH ([Legitimate] + [Necessary] + [Proportionate]) mais chacun de ces trois attributs reste qualitatif — un simple libellé textuel que l'analyzer ne lit pas sémantiquement. La vérification de la proportionnalité réelle reste un acte humain, juridique, politique.
La troisième limite est la question du Conseil constitutionnel comme institution vivante. Le cas De Gaulle 1962 illustre une tension irréductible : une institution constitutionnelle peut se déclarer compétente ou incompétente selon des considérations qui ne sont pas purement juridiques. Le CC de 1962 a fait le choix politique de l'incompétence face au référendum, probablement pour éviter l'affrontement frontal avec un président de la République au sommet de sa popularité. Le type system ne connaît pas cette marge de manœuvre — il vérifie la cohérence structurelle, point. Un cadre qui voudrait modéliser la variabilité discrétionnaire du contrôle constitutionnel devrait ajouter une couche supplémentaire — DiscretionaryReview comme quatrième modalité, avec attribut [SelfDeclaredIncompetent(case: "...", reason: "...")]. Je laisse cette extension à un futur cadre.
La quatrième limite — la plus grave pour un projet de compilateur politique — est le public. Le DSL est écrit en C#, parse par Roslyn, compilé par MSBuild. Les juristes ne lisent pas C#. Les politologues encore moins. Les citoyens, encore moins. La diffusion suppose soit une couche de présentation qui traduit les types en prose vérifiable (Catala le fait pour le CGI français), soit une adoption professionnelle partielle dans les rédactions de cabinets ministériels et d'assemblées. La Partie 15 — Lex Studio aborde cette question de diffusion ; je ne la résous pas ici.
Vers la Partie 9-ter — instances FR / US
Cette Partie a posé la racine Constitution.Dsl. Elle reste abstraite : aucun article particulier de la Constitution française ou américaine n'est encodé. Le DSL fournit le vocabulaire (pouvoirs, organes, procédures), les analyzers fournissent la vérification structurelle, la démo 1962 fournit le smoke test.
La Partie 9-ter, à venir, instancie ce vocabulaire dans deux cadres officiels : Constitution.France1958.Official.Dsl (89 articles + révisions jusqu'à 2026) et Constitution.Usa2026.Official.Dsl (7 articles + 27 amendements + projection d'éventuelles évolutions). Elle montre comment les mêmes types abstraits se remplissent différemment selon la tradition (codifiée vs common law, contrôle a priori vs judicial review, révision par Congrès vs ratification par États). Elle ajoute le deuxième smoke test de ce triptyque : un Executive Order hypothétique qui tarife des importations sans habilitation statutaire — violation de Article I Section 8 Clause 1, error CST002 compile-time.
Le cas Dumas de la Partie 10 gagne alors rétroactivement une lecture plus riche. En 1995, la suppression du financement public des campagnes par la loi organique aurait pu (si elle avait suivi cette voie) violer simultanément LOI003 (procédure démocratique) et — si le plafonnement électoral avait été dans le bloc constitutionnel — un futur CST001 (violation de hiérarchie des normes). Le type system multiplie les niveaux de vérification. Il attrape les erreurs à chaque rang de la pyramide, pas seulement au rang de la loi ordinaire.
Les parties ultérieures (11 à 18) viendront reprendre l'ensemble du dispositif sous l'angle de sa diffusion politique, de sa critique interne, et de sa capacité à servir d'infrastructure à un renouveau démocratique qui ne soit ni autoritaire ni libéral, mais proprement métacratique — où l'écriture constitutionnelle devient un terrain commun, typé, vérifiable, et donc démocratiquement appropriable.