Construction 2 — Étiqueter les régimes de preuve📋

Rectification préalable📋

Ma première version de cette construction accusait le projet de ne pas publier son code. C'était faux : le dépôt github.com/FrenchExDev/FrenchExDev est public. Je le mentionne d'emblée parce que l'erreur est typique du biais que le ping-pong avec un LLM reproduit : un critique extérieur conclut trop vite quand il ne voit pas l'artefact cité, alors que l'artefact est à un clic si on cherche correctement. C'est aussi une illustration concrète de la critique 5 du même round : un adversaire humain qui connaît l'écosystème aurait suivi le lien avant d'accuser.

La critique corrigée, plus fine, porte sur un défaut d'étiquetage : la Construction 2 du Round 1 mélange des éléments qui relèvent de régimes de preuve différents, sans les signaler. Cette construction-ci propose une discipline pour sortir de ce mélange.

Le bon cadre : design-in-public📋

Il faut d'abord nommer le genre dans lequel le corpus métacratie travaille. Ce n'est pas un papier académique (format Catala), ce n'est pas une documentation de produit (format impots.gouv.fr), ce n'est pas une startup pitch. C'est un blog de conception ouverte — ce que la littérature anglophone appelle design-in-public ou building-in-public. On publie la pensée architecturale avant, pendant et après l'écriture du code. On décrit comment le logiciel doit fonctionner en parallèle de sa construction. On rend visible l'itération, y compris ses maladresses.

Ce genre a sa valeur propre. Il n'est pas un sous-produit d'un projet « sérieux » qu'on publierait en retard — c'est une pratique à part entière, qui sert à clarifier l'intention de l'auteur, à inviter des lecteurs à critiquer tôt, et à créer une trace historique du raisonnement. Des projets importants ont été construits de cette façon : la documentation publique de Rust, les RFC Python, les posts de blog d'architectes logiciels qui publient leurs réflexions avant implémentation. Le genre est légitime. Il n'a simplement pas les mêmes règles de preuve qu'un papier de conférence.

Le corpus métacratie assume en grande partie ce genre : le Round 0-1 (Confrontations), le Round 0-5 (Théories), le Round 0-6 (Ontologie) sont du raisonnement pur — de la conception publique d'un dispositif politico-logiciel. Leur valeur ne dépend pas de l'existence d'un produit. Ils sont évalués comme on évalue un essai architectural : par la cohérence interne, la puissance de l'analogie, la portée des distinctions.

Le problème est ailleurs : certaines parties du corpus font comme si elles étaient dans un autre régime. La Construction 2 du Round 1 et le Round 0-7 (Implémentation) revendiquent du concret et de la vérifiabilité compile-time, ce qui est une promesse d'un autre registre. Le défaut n'est pas la prospective — c'est le mélange silencieux entre prospective et vérifiabilité, dans des textes qui prétendent à la seconde alors qu'ils relèvent de la première.

Les quatre régimes à distinguer📋

Une discipline minimale d'étiquetage reconnaîtrait quatre régimes dans les textes du corpus. Chacun a ses règles de preuve, chacun a sa valeur, aucun n'est disqualifiant — à condition d'être nommé.

Régime 1 — Projet tiers peer-reviewed. Catala. Le lecteur peut vérifier l'existence d'un papier publié, d'un dépôt GitHub, d'un partenariat institutionnel documenté. L'argument tire sa force de la vérifiabilité distante — quelqu'un d'autre a déjà fait le travail, il faut juste y pointer. C'est le régime le plus solide, mais il n'appartient pas à metacratie : il est emprunté. L'étiquette serait : « Tiers vérifiable. Catala, POPL 2022, INRIA. » Une phrase.

Régime 2 — Code public du projet. Ce qui est dans FrenchExDev/FrenchExDev. Ici le lecteur peut aller voir et vérifier ce qui existe effectivement. L'étiquette serait : « Public. Voir [fichier] dans [branche] du dépôt. » Une phrase et un lien. Quand un texte décrit un comportement, il devrait pouvoir pointer vers le commit qui l'implémente ou signaler explicitement que le code correspondant n'est pas encore dans le dépôt. Il y a une différence entre « voici comment le pub/sub fonctionne » quand le code existe et la même phrase quand le code est en cours d'écriture. Actuellement cette différence est indiscernable à la lecture.

Régime 3 — Design-in-public, prospective architecturale. La partie la plus volumineuse du corpus. Les rounds 0-1, 0-5, 0-6, les parties 1-18 de la série compilateur. C'est du raisonnement sur ce qui doit être construit, avec des analogies, des distinctions, des contraintes. L'étiquette serait : « Prospective. Aucun code à ce jour ne vérifie ce paragraphe. Évalué par cohérence interne et pouvoir heuristique. » C'est moins glorieux, mais c'est exact — et c'est suffisant pour que le texte garde sa valeur. Un lecteur habitué au genre design-in-public sait comment lire ce registre.

Régime 4 — Attestation d'expérience professionnelle. Le CMF. Ici l'auteur mobilise sa pratique dans un cadre privé pour étayer un argument technique. L'étiquette serait : « Expérience. L'auteur a pratiqué ce pattern en production dans un projet commercial. Non-vérifiable par le lecteur. » Ce régime est rhétoriquement faible par rapport aux trois autres, mais il n'est pas illégitime — il est utilisé couramment par tout expert qui parle depuis sa pratique. Le défaut est de ne pas le nommer, ce qui laisse croire qu'il appartient au Régime 2.

Quatre étiquettes possibles : [Tiers], [Code], [Prospective], [Expérience]. Appliquées de façon systématique, ligne à ligne ou paragraphe à paragraphe, elles rendraient visible ce que le lecteur est en train de lire, dans quel sens il peut le critiquer, et quelles preuves il peut réclamer.

Pourquoi cette discipline sert le projet, pas seulement le lecteur📋

On pourrait objecter que l'étiquetage alourdit le texte et casse la fluidité argumentative. C'est vrai. C'est aussi indispensable pour un projet dont l'argument central est la vérifiabilité compile-time du droit. Le parallèle est strict : dans un texte de loi typé, chaque assertion doit être étiquetée par son niveau de contrainte (vague par design, strict, transitoire). Dans un texte de blog qui défend ce principe, chaque assertion devrait être étiquetée par son niveau de preuve.

Mieux : la discipline d'étiquetage fait émerger les zones où le texte dépend trop du Régime 3 pour ce qu'il prétend faire. Un paragraphe qui se retrouve étiqueté [Prospective] alors qu'il était écrit pour convaincre un lecteur sceptique est un signal : soit il faut écrire le code qui le transporte en [Code], soit il faut baisser la prétention de l'argument. Les deux sont productifs. La situation actuelle, où rien n'est étiqueté, est la seule qui empêche ce diagnostic.

Inversement, un paragraphe qui peut passer en [Code] avec un simple lien vers un fichier du dépôt gagne immédiatement en solidité sans aucun travail sur le raisonnement. C'est gratuit. Le Round 2 découvre en cours d'écriture que beaucoup de la Construction 2 du Round 1 aurait pu passer en [Code] pour un coût d'une phrase — et qu'il ne l'a pas fait.

Ce qu'un dépôt public devrait exposer, à terme📋

Au-delà de l'étiquetage, il y a une question plus profonde : le dépôt FrenchExDev/FrenchExDev est public, mais un lecteur qui y arrive sans contexte trouve-t-il le démonstrateur Round 7 ? Trouve-t-il un README qui explique quel texte du blog correspond à quel dossier du code ? Un mapping entre les promesses du blog et les preuves du code ?

Cette construction ne peut pas le vérifier — je ne lis pas le dépôt ici. Mais elle peut poser les questions qu'un lecteur critique poserait :

• Existe-t-il un README.md à la racine qui oriente un lecteur venu depuis le blog ?
• Existe-t-il un dossier law-dsl-demo/ ou équivalent qui contient spécifiquement le démonstrateur du Round 7 ?
• Existe-t-il un CI.yml actif qui tourne les tests à chaque commit et rend visible le compilation status ?
• Existe-t-il un LICENSE ? Lequel ?
• Un lecteur peut-il, depuis un post de blog, cliquer sur un lien qui l'amène au fichier exact implémentant la chose décrite ?

Si la réponse à la plupart de ces questions est oui, alors le défaut est purement un défaut de lien depuis les constructions — ce qui se répare en une édition. Si la réponse est non, alors la priorité de développement du projet devrait être d'installer cette traçabilité avant de produire plus de texte. Dans les deux cas, la marche à suivre est claire.

Questions ouvertes📋

• Les étiquettes [Tiers], [Code], [Prospective], [Expérience] sont-elles les bonnes quatre ? En faut-il plus (par exemple un régime pour l'analogie purement rhétorique) ? Moins ?
• L'étiquetage doit-il être au paragraphe, au bloc, ou à la section ?
• Un post de blog peut-il mélanger plusieurs régimes dans une même phrase (« X est le cas pour Catala [Tiers] et deviendra le cas pour metacratie [Prospective] ») sans devenir illisible ?
• Le design-in-public est-il assez valorisé par le corpus lui-même ? Le projet aurait-il intérêt à rendre le genre explicite — un post de méthodologie qui explique comment lire un blog de conception architecturale ?

Le Round 2 bascule ici d'un débat sur l'existence du code à un débat sur la discipline de l'écriture. C'est une bascule utile : elle déplace l'exigence de transparence du code (qui est là) vers le texte (qui doit apprendre à se nommer).