Formaliser le droit n’est jamais une simple opération de copie. Entre le texte et la règle exécutable, il faut identifier des concepts, choisir des conditions, ordonner des exceptions et décider ce que le système fera lorsqu’un terme demeure ambigu.
Ces choix peuvent être justifiés, documentés et contrôlés. Ils restent des choix juridiques. Le code ne fait pas disparaître l’interprétation. Il lui donne une forme plus précise, parfois plus visible, mais aussi plus facile à confondre avec une vérité objective.
La règle n’est pas contenue dans une seule phrase
Une disposition paraît parfois se prêter immédiatement à une structure condition-conséquence. En pratique, la condition peut dépendre d’une définition située dans un autre article, d’une exception introduite plus loin, d’une date d’effet particulière ou d’une qualification que le texte ne résout pas seul.
Danièle Bourcier montrait dès 1979 que l’unité lexicale indexable ne restitue pas nécessairement le concept juridique. Son analyse oppose déjà la disponibilité informatique des mots à la construction de leur signification dans le discours juridique.[1]
La formalisation commence donc avant le code. Il faut déterminer quelles propositions appartiennent à la règle, comment elles s’articulent et quels éléments du contexte leur donnent sens.
Traduire en code oblige à lever des ambiguïtés
Catala a été conçu pour représenter des textes qui décrivent des calculs et s’organisent autour de règles générales et d’exceptions. Le langage conserve une relation étroite avec le texte juridique et fournit une sémantique formelle permettant de produire une spécification exécutable.[2]
Sa documentation explique toutefois que coder la loi ne consiste pas à traduire littéralement les phrases. L’opération peut exiger de résoudre une ambiguïté, d’intégrer un règlement, une pratique administrative ou un autre matériau extérieur au texte principal. Elle suppose une collaboration entre expertise juridique et expertise informatique, ainsi qu’une trace des décisions prises pendant la formalisation.[3]
Prenons une règle fiscale qui prévoit un avantage sous plusieurs conditions. Il faut décider si ces conditions sont cumulatives, définir la date à laquelle chacune s’apprécie, représenter les exceptions et déterminer la conséquence d’un fait manquant. Deux programmes peuvent partir du même article et produire des résultats différents sans contenir la moindre erreur de syntaxe.
Le désaccord se trouve alors dans la représentation juridique. Le code l’exécute avec précision, mais ne le tranche pas.
Toutes les normes ne gagnent pas à être exécutées
Une partie du droit décrit des opérations presque algorithmiques : calcul d’un montant, délai, seuil, ordre de priorité ou enchaînement d’exceptions. Le British Nationality Act a ainsi pu être partiellement représenté sous la forme d’un programme logique dès 1986.[4]
D’autres normes mobilisent des notions comme le caractère raisonnable, l’abus, la proportionnalité, l’intention ou l’intérêt supérieur. Elles peuvent être structurées, mais cette structuration ne les transforme pas nécessairement en décisions déterminées à l’avance.
La documentation de Catala le dit clairement : toute loi peut peut-être être formalisée dans un sens abstrait, mais toute loi n’est pas utilement formalisée. L’effort produit surtout de la valeur lorsque le texte est dense en règles, complexe, computationnel et organisé autour d’exceptions.[3]
La bonne question n’est donc pas de savoir si le droit peut être mis en code en général. Elle est de déterminer quelle partie doit l’être, dans quel but et avec quelles limites explicites.
La traçabilité empêche le code de devenir une seconde loi
Une représentation exécutable devient dangereuse lorsqu’elle se détache du texte dont elle procède. Une modification législative peut alors ne pas être répercutée. Une hypothèse d’interprétation peut se transformer silencieusement en règle générale. Une exception peut disparaître parce qu’elle n’entrait pas dans le modèle initial.
LegalRuleML traite précisément plusieurs dimensions que les suites de conditions ordinaires représentent mal : provenance, temporalité, juridiction, exceptions, défaisabilité et relations entre normes.[5] Son intérêt n’est pas de supprimer l’interprétation, mais d’offrir une structure dans laquelle les choix et les relations peuvent être décrits.
La formalisation devrait donc rester reliée à la disposition source, à sa version, à la date pertinente et à la justification de chaque transformation importante. Le lecteur doit pouvoir remonter du résultat au code, puis du code au texte et au choix juridique qui les relie.
Les LLM peuvent accélérer la formalisation, pas en assumer seuls la responsabilité
Un modèle de langage peut extraire des conditions, proposer une structure, repérer des renvois et générer un premier programme. Cette capacité réduit fortement le coût d’un travail qui exigeait auparavant une intervention spécialisée sur chaque texte.
Elle introduit aussi un risque particulier. Une formalisation produite automatiquement peut être cohérente, complète en apparence et néanmoins reposer sur une lecture discutable. Le caractère exécutable du résultat renforce alors l’illusion de certitude.
La documentation de Catala considère encore la traduction de la loi par les LLM comme une question de recherche ouverte et souligne les tensions avec les exigences de précision, d’exactitude et de responsabilité.[3] Le contrôle juridique ne peut donc pas être ajouté seulement à la fin, après la génération du code. Il doit accompagner l’identification des concepts, la résolution des ambiguïtés et la construction de chaque règle.
Formaliser le droit peut rendre certaines opérations plus transparentes, testables et reproductibles. À condition de reconnaître ce que l’opération contient : non pas une transcription neutre, mais une interprétation devenue exécutable.
Sources et références
- Danièle Bourcier, « Information et signification en droit. Expérience d’une explicitation automatique de concepts », Langages, no 53, 1979, p. 9-32. Source ↗ (article académique en accès ouvert).
- Denis Merigoux, Nicolas Chataing et Jonathan Protzenko, « Catala: A Programming Language for the Law », 2021, arXiv 2103.03198. Source ↗ (article scientifique et implémentation documentée).
- Catala, « General questions », documentation officielle, consultée le 30 août 2026. Source ↗ (documentation officielle).
- Marek J. Sergot et al., « The British Nationality Act as a Logic Program », Communications of the ACM, vol. 29, no 5, mai 1986. Source ↗ (article évalué par les pairs).
- OASIS, « LegalRuleML Core Specification Version 1.0 », OASIS Standard, 30 août 2021. Source ↗ (standard officiel).