Une confusion revient souvent dans les discussions sur l’intelligence artificielle juridique : nous traitons comme équivalentes des choses qui ne le sont pas. Avoir le texte n’est pas avoir la règle. Avoir la bonne source n’est pas encore savoir quelle conséquence en tirer.
Cette distinction n’est pas théorique. Elle explique pourquoi une réponse peut être parfaitement documentée et juridiquement fragile.
Le juriste ne lit pas seulement des phrases
Une disposition peut poser une règle générale, renvoyer à une définition, prévoir une exception, ne s’appliquer qu’à compter d’une certaine date et dépendre de faits qui ne sont pas établis.
Le juriste reconstruit une architecture. Il identifie les conditions, détermine si elles sont cumulatives ou alternatives, vérifie les exceptions, choisit la version applicable et qualifie les faits. Il accepte parfois de ne pas conclure tant qu’un élément manque.
Le document est la source de cette opération. Il n’en est pas l’exécution.
Une convention fiscale l’illustre bien. Donner au modèle l’article complet sur l’établissement stable est indispensable. Cela ne suffit pas à savoir si l’entreprise possède effectivement un établissement stable. Il faut encore déterminer ce qu’elle fait, où, pendant combien de temps, avec quels moyens, et parfois si plusieurs activités doivent être considérées ensemble.
Plusieurs niveaux existent déjà dans les standards juridiques
L’informatique juridique travaille depuis longtemps sur cette distinction.
Le European Legislation Identifier, ELI, fournit un cadre commun d’identification par URI et de métadonnées pour la législation, afin de la rendre accessible aux humains comme aux machines.[1]
Akoma Ntoso structure le contenu et les métadonnées des documents parlementaires, législatifs et judiciaires dans un vocabulaire XML commun. Le standard permet notamment de représenter des versions et des consolidations à un instant donné.[2]
LegalRuleML se place à un autre niveau. Il vise la représentation des particularités des normes juridiques, de leur relation avec les sources, de leur temporalité et de leur caractère révisable ou défaisable.[3]
Identifier le document, structurer son texte et représenter la norme ne sont donc pas trois formulations du même problème. Ce sont trois opérations distinctes.
Le RAG demande souvent au modèle de franchir ces niveaux en une fois
Dans un système RAG classique, des passages sont retrouvés puis placés dans le contexte. Le modèle doit ensuite reconstruire la règle pendant qu’il rédige : comprendre qu’un alinéa constitue une exception, interpréter un renvoi, repérer une modification temporelle, identifier le fait manquant.
Cette souplesse est précieuse. Elle évite d’avoir à formaliser au préalable chaque fragment du droit. Mais elle rend également le contrôle plus difficile, car source, règle, faits et conclusion se retrouvent fondus dans une même prose.
Ajouter davantage de documents améliore la probabilité de retrouver la bonne matière. Cela ne change pas la nature de l’opération. Une bibliothèque contenant cent mille décisions n’est pas, par ce seul fait, un système qui représente cent mille raisonnements.
Séparer pour pouvoir contrôler
Dans un système juridique sérieux, il faut pouvoir distinguer au moins quatre éléments : la source qui établit la norme, la représentation de cette norme, les faits utilisés pour l’appliquer et le chemin qui conduit à la conclusion.
Cette séparation permet de localiser l’erreur. La source est-elle mauvaise ? La règle a-t-elle été mal représentée ? Un fait a-t-il été supposé ? Une exception a-t-elle été oubliée ?
Elle permet aussi de maintenir le lien essentiel entre la formalisation et le texte qui fait autorité. Une règle exécutable sans source vérifiable serait aussi dangereuse qu’une source exacte appliquée sans logique contrôlable.
Rendre le droit lisible par machine est une étape importante. Le rendre juridiquement manipulable sans perdre sa provenance, sa temporalité et ses zones d’interprétation en est une autre.
C’est entre ces deux étapes que se situe une grande partie du travail encore à accomplir.
Sources et références
- Office des publications de l’Union européenne, « European Legislation Identifier, ELI », documentation consultée le 29 août 2026. Source ↗ (documentation officielle).
- OASIS, « Akoma Ntoso Version 1.0, Part 1: XML Vocabulary », OASIS Standard, 29 août 2018. Source ↗ (standard officiel).
- OASIS, « LegalRuleML Core Specification Version 1.0 », OASIS Standard, 30 août 2021. Source ↗ (standard officiel).