Le code, qu'il soit juridique ou informatiquebrouillon
J’ai une passion pour le code, qu’il soit juridique ou informatique, et c’est elle que je voulais partager ici. Plutôt que d’écrire de longs pavés théoriques ou de lancer des formules sur les réseaux sociaux, j’ai préféré montrer comment je procède. Ce site en est la première pièce : il se construit sous vos yeux, et chaque étape de sa construction est racontée, impasses comprises.
Écrire du code pour qu’il soit relu, comme une thèse
Le droit m’a appris à écrire pour être relu. Une thèse cite ses sources, introduit avant de démontrer, annonce son plan avant de le dérouler. Quand je développe, je garde les mêmes réflexes. Chaque fichier commence par dire ce qu’il fait, ce qui l’appelle et ce qu’il ne doit jamais faire. Chaque dossier a son introduction, le README, qui annonce le plan de ce qu’on va y trouver. Et un commentaire de code bien écrit ressemble à une note de bas de page : il ne répète pas le texte, il dit d’où vient une règle et pourquoi elle est là.
Le chemin inverse m’est tout aussi utile. Les développeurs ont inventé des outils pour qu’un projet survive à ceux qui l’écrivent : le README qui oriente, la feuille de route qui dit où l’on va, le journal des modifications qui dit ce qui a changé et pourquoi, le registre des décisions qui évite de rouvrir chaque débat. Avec l’IA, ces outils changent de statut. Une IA qui reprend un dossier ne sait que ce qui est écrit : une décision prise à l’oral, une hypothèse jamais notée, un « on avait dit que » n’existent pas pour elle. Tenir un dossier juridique comme un dépôt de code, c’est donner à l’IA, et d’ailleurs au collègue qui reprendra le dossier, de quoi travailler sans tout redemander.
Une virgule peut changer l’exécution d’un contrat comme celle d’un programme
Un article de code et une clause de contrat ont plus en commun qu’il n’y paraît. Tous deux traduisent une intention, tous deux remplissent une fonction, et dans les deux cas la mise en forme peut tout changer au moment de l’exécution.
La devise de ce site en a fait les frais. Sa première version oubliait un signe :
while [ friction = true ] ; do think_otherwise ; done # oublie le $
while [ "$friction" = true ] ; do think_otherwise ; done # lit la variable
Sans le $, la boucle ne compare pas la valeur de la variable mais le mot « friction »
lui-même, qui ne sera jamais égal à « true ». La condition est toujours fausse, et
think_otherwise ne s’exécute jamais : la devise affirmait exactement le contraire de ce
qu’elle voulait dire. Un caractère, et l’intention s’inverse. (La version actuelle, en
pied de page, a changé de boucle depuis, mais pas de leçon.)
Rendre lisibles des arrêtés scannés empilés dans des PDF de 300 pages
Les préfectures publient leurs arrêtés dans des recueils des actes administratifs : des PDF de plusieurs centaines de pages, souvent scannés, où se suivent nominations, tarifs, autorisations, et, perdues au milieu, des interdictions temporaires de vente ou de transport (artifices, carburant au détail) le temps d’une fête nationale ou d’un événement. Attrap, un outil libre, collecte ces recueils. Restait à en tirer ce qu’un juriste cherche : ce qui est interdit, où, et du combien au combien.
J’ai écrit pour cela une chaîne qui découpe chaque recueil en actes, repère les articles pertinents et en extrait les dates. Son cœur n’a rien de savant : ce sont des conditions écrites en dur, une par forme réellement rencontrée. « jusqu’au » coupé en « jus qu’au » par la mise en page ; « O6h00 », où la reconnaissance de texte a lu la lettre O à la place du zéro ; l’heure placée avant la date dans une préfecture, après dans toutes les autres. Chaque règle porte en commentaire l’acte qui l’a motivée, comme une note d’arrêt renvoie à sa décision. Sans ce commentaire, la règle paraît arbitraire, et le prochain qui « simplifie » le code la supprime. Avec lui, une matière chaotique redevient un ensemble de cas identifiés, chacun avec sa source.
Le « 111 juillet », ou comment corriger un cas en cassant tous les autres
Un arrêté interdisait une vente « du samedi 111 juillet 2026 » : la reconnaissance de texte avait doublé le premier chiffre du jour. Première correction, logique en apparence : un chiffre suivi du même chiffre est un doublon, on l’ignore.
// Première version : ignorer un chiffre suivi du même chiffre
const JOUR = /(?:(\d)(?=\1))?(\d{1,2})\s*(juin|juillet|août)/;
'111 juillet'.match(JOUR)[2]; // '11' : corrigé
'22 juin'.match(JOUR)[2]; // '2' : faux, sans la moindre erreur
// Correction : n'ignorer le chiffre que s'il en reste encore deux après
const JOUR = /(?:(\d)(?=\1\d))?(\d{1,2})\s*(juin|juillet|août)/;
'22 juin'.match(JOUR)[2]; // '22'
Le 111 juillet redevenait bien le 11. Mais le 22 juin devenait le 2, et le 11 août le 1 : aucun plantage, aucun message, seulement des dates d’interdiction fausses, sur toutes les dates dont le jour s’écrit avec deux chiffres identiques. La régression n’a pas été trouvée sur le cas qui avait motivé la règle, puisque lui marchait parfaitement, mais en rejouant la règle sur tout le corpus. C’est exactement le réflexe du juriste qui modifie une définition : avant de signer, on relit chaque article qui l’emploie.
C’est de cela que parlera ce blog : des textes qui s’exécutent, qu’ils tournent sur une machine ou entre deux parties, et de la façon de les écrire pour qu’ils fassent ce qu’on voulait qu’ils fassent.
