Round 4 — Contre-exemples historiques : traditions juridiques comme DSLs📋

Le recadrage📋

ChatGPT (Round 0) pose la question : « Quels exemples historiques contredisent la nécessité de formalisation ? ». La question est légitime. Le common law anglais fonctionne depuis le XIIe siècle sans code civil. Le droit coutumier africain a organisé des sociétés entières sans texte écrit. Le droit romain a régné sur un empire avec des catégories radicalement différentes du droit moderne. Si la formalisation typée était nécessaire, comment ces systèmes ont-ils fonctionné pendant des siècles ?

La réponse est : ces traditions juridiques ne sont pas des réfutations de la formalisation. Ce sont des DSLs spécifiques à leur (Espace × Temps). Chacune a sa grammaire, ses types (explicites ou implicites), ses mécanismes de validation, ses garde-fous, ses failles. L'architecture metacratie ne les rejette pas — elle les accueille comme des instances de la signature META(Ex × Ty).

1 — Le common law anglais comme DSL à types implicites📋

Le système de types du précédent📋

Le common law anglais fonctionne par précédent (stare decisis). Chaque arrêt de la cour supérieure produit une règle typée par ses faits : « dans les circonstances X, le résultat juridique est Y ». Le juge suivant, face à des circonstances similaires, doit appliquer la même règle — sauf s'il peut distinguer les faits de manière suffisante pour échapper au précédent.

C'est un système de types. Les faits sont les paramètres de type. La règle est la valeur de retour. Le raisonnement par analogie est un pattern matching sur les faits. La distinction (distinguishing) est une spécialisation de type — « mon cas est du type X', qui est un sous-type de X mais avec un paramètre supplémentaire qui change le résultat ».

La différence avec un DSL typé explicite est que le système de types du common law est implicite. Les types ne sont jamais déclarés formellement — ils émergent de l'accumulation des arrêts. Westlaw et LexisNexis sont des registres de ce DSL implicite : ils indexent les arrêts par domaine juridique, par faits, par résultat, et permettent au praticien de naviguer dans le système de types.

Le coût de l'implicite📋

Le coût d'accès au droit anglais est le plus élevé d'Europe — précisément parce que le typage est implicite. Pour savoir quel droit s'applique à une situation donnée, il faut lire des centaines d'arrêts, identifier les faits pertinents, tracer les chaînes de précédents, et deviner les distinctions que le juge pourrait faire. C'est un travail d'expert qui prend des heures (facturées). Un CommonLaw.England.Dsl rendrait ce système de types explicite — pas pour remplacer le common law, mais pour le rendre navigable.

Les hooks d'inter-implémentation📋

Un cadre Law.France2026.Etalab.Dsl (droit civil) et un cadre CommonLaw.England2026.Dsl (common law) ont des systèmes de types différents. Le droit civil part de la règle générale et descend au cas particulier (déduction). Le common law part du cas particulier et monte à la règle générale (induction). Les deux sont des DSLs valides — ils diffèrent par leur direction de typage.

L'architecture metacratie gère cette coexistence via des hooks : un IPrecedentResolver expose l'interface entre un cadre civil et un cadre common law. Le bridge Law.International.Bridge (Partie 17, A.6) orchestre les deux cadres quand une situation juridique les implique tous les deux (droit international privé, reconnaissance d'un jugement étranger). Les hooks ne convertissent pas un système dans l'autre — ils exposent les points de contact.

2 — Le droit coutumier comme DSL oral📋

La coutume est un DSL sans persistance textuelle📋

Le droit coutumier — en Afrique subsaharienne, en Asie du Sud-Est, dans les communautés autochtones des Amériques — est un DSL oral. Les règles sont transmises par les anciens, interprétées par les chefs coutumiers, adaptées par la pratique communautaire. Il n'y a pas de texte — il y a une mémoire collective qui fonctionne comme un registre de types implicites.

C'est un DSL fonctionnel : il a ses propres catégories (terres collectives, obligations familiales, justice restauratrice), ses propres mécanismes de validation (conseil des anciens, consensus communautaire), et ses propres garde-fous (honte sociale, ostracisme). La signature serait CustomaryLaw.${Space}${Time}.Community.Dsl — un DSL spécifique à une communauté, un territoire, une époque.

Les failles de l'oralité📋

L'oralité a des failles structurelles que le typage explicite résout :

• Pas de diff : comment savoir si la coutume a changé ? Sans texte, pas de comparaison entre « avant » et « après ». Le chef coutumier qui modifie une règle peut prétendre qu'elle a toujours été ainsi.
• Pas de versioning : quelle version de la coutume s'applique ? Celle du grand-père ou celle du père ? Sans horodatage, pas de réponse vérifiable.
• Vulnérable à la manipulation : le détenteur de la mémoire collective détient le pouvoir d'interprétation. L'asymétrie est structurelle et irréductible.

Un CustomaryLaw.${Space}.Dsl ne fige pas la coutume — il la versionne. Les coutumes évoluent, le DSL enregistre les évolutions. Le diff entre deux versions montre ce qui a changé et quand. Le [VagueByDesign] est natif dans le droit coutumier — la coutume est par définition interprétative, et les zones d'interprétation doivent être marquées comme telles.

La collision avec le droit étatique📋

La question la plus douloureuse est la collision entre le droit coutumier et le droit étatique post-colonial. En Afrique de l'Ouest, le droit foncier coutumier (terres collectives, héritage matrilinéaire) coexiste avec le droit foncier étatique (cadastre, propriété individuelle). Les deux DSLs sont incompatibles sur les mêmes objets. Le bridge CustomaryLaw.Senegal.Bridge devrait exhiber ces incompatibilités au lieu de les résoudre — parce que la résolution est un acte politique (choix de société entre propriété collective et individuelle), pas un acte technique.

3 — Le droit européen comme migration📋

La formalisation textuelle sans typage📋

Le RGPD fait 88 pages. L'AI Act en fait 144. La directive MiFID II en fait plus de 700. Ce n'est pas de la « sur-formalisation » — c'est de la formalisation textuelle sans typage. Le texte est long parce qu'il doit tout dire en prose ce qu'un système de types dirait en une ligne. L'article 6 du RGPD (bases légales du traitement) est un enum à 6 valeurs (Consent | Contract | LegalObligation | VitalInterests | PublicInterest | LegitimateInterest) noyé dans 3 pages de prose.

L'opacité de la réglementation européenne ne vient pas de l'excès de formalisation — elle vient de l'absence de typage. Le même contenu, typé, serait à la fois plus court et plus lisible. Un Law.EU2024.AIAct.Dsl qui déclare [RiskLevel(RiskLevel.HighRisk, typeof(BiometricIdentification))] dit en une ligne ce que l'AI Act dit en quatre paragraphes.

La transposition comme implémentation d'interface📋

Le vrai enjeu architectural est que le DSL France doit accueillir le DSL Europe. C'est une migration au sens technique du terme. Quand l'Union européenne publie une directive, chaque État membre doit la transposer dans son droit national. En termes de DSL, la directive est une interface que le cadre national implémente :

// La directive est une interface
public interface IEuropeanDirective<TDirective>
    where TDirective : IDirective
{
    bool IsTransposed { get; }
    TranspositionReport Validate();
}

// Le cadre national implémente l'interface
public class LawFrance2026Etalab
    : IEuropeanDirective<AIAct>,
      IEuropeanDirective<GDPR>,
      IEuropeanDirective<MiFID2>
{
    // Le bridge vérifie la transposition au compile-time
}

L'inter-implémentation (interface d'interface) est le marqueur de compatibilité entre DSLs. Une IEuropeanDirective<T> est elle-même paramétrée par un type T qui décrit la directive spécifique. Le bridge vérifie au compile-time que la transposition est complète — et signale les articles non transposés comme des diagnostics. La France a été condamnée plusieurs fois par la CJUE pour transposition incomplète de directives. Avec un bridge typé, la transposition incomplète serait un compile error.

Le pattern général📋

Les directives européennes deviennent des interfaces. Les cadres nationaux deviennent des implémentations. Le bridge vérifie la cohérence. C'est le même pattern que l'héritage d'interface en C# — et ce n'est pas une analogie : c'est littéralement le mécanisme technique que Law.Dsl utilise.

4 — Le pattern général : chaque tradition est un DSL📋

Chaque tradition juridique dans l'histoire humaine est un DSL spécifique à son (Espace × Temps) :

Les DSLs offrent trois mécanismes d'interopérabilité :

• Hooks (points d'extension) : un DSL peut être étendu sans modifier son noyau. Le IPrecedentResolver est un hook qui permet au common law de coopérer avec le droit civil.
• Interfaces (contrats entre systèmes) : un DSL peut exiger qu'un autre DSL satisfasse certaines contraintes. IEuropeanDirective<T> est une interface que les DSLs nationaux doivent implémenter.
• Inter-implémentations (interface d'interface) : un marqueur de compatibilité entre DSLs. Quand un DSL implémente l'interface d'un autre DSL, le bridge vérifie la cohérence au compile-time.

La question n'est pas « faut-il formaliser ? » — le droit est toujours déjà formalisé, dans un DSL ou un autre. La question est : « quel DSL pour quel (Espace × Temps), et comment les faire coopérer ? ».

Pour aller plus loin📋

• Partie 17 — Méta-critique — A.6 (droit comparé), A.10 (logique non-monotone)
• Partie 5 — Architecture en couches — la pile qui accueille les DSLs
• Partie 9 — Law.Commons.Bridge — le mécanisme de bridge inter-DSL
• Round 6 — Statut ontologique — la DLL comme carte, pas territoire
• Hub de la série