L'IA qui a inventé une affaire judiciaire — et l'architecture que nous avons bâtie pour rendre cela impossible

Je me souviens du moment précis où j'ai cessé de faire confiance à la manière dont la plupart des gens construisent l'IA juridique.

C'était tard un mardi soir, et je lisais la transcription judiciaire de l'affaire Mata v. Avianca. Pas un résumé. Pas un fil de tweets. Le dossier réel. Un avocat avait déposé un mémoire citant Varghese v. China Southern Airlines, Shaboon v. Egyptair, et Petersen v. Iran Air — avec numéros de rôle, dates et attendus cités à l'appui. Suffisamment convaincant pour que l'avocat adverse doive partir à leur recherche. Ces affaires n'existaient pas. ChatGPT les avait inventées. Et lorsque l'avocat est revenu vers ChatGPT pour vérifier, le modèle a joyeusement confirmé ses propres fabrications : « Oui, ces affaires existent bel et bien et peuvent être trouvées dans des bases de données juridiques réputées. »

J'ai reposé la transcription et je me suis dit : ce n'est pas un problème de prompting. C'est un problème d'architecture. Et la plupart du secteur de l'IA juridique fait comme si ce n'était pas le cas.

Cet incident — qui a débouché sur une amende de 5 000 dollars, un blâme judiciaire et un cratère de réputation — est devenu l'étude de cas fondatrice de ce que mon équipe chez Veriprajna construit désormais : des systèmes GraphRAG à citations imposées pour l'IA juridique. Des systèmes où l'IA ne peut physiquement pas produire la citation d'une affaire qui ne correspond pas à une entrée vérifiée dans un Knowledge Graph. Pas « ne le fera probablement pas ». Ne le peut pas.

Je veux expliquer pourquoi cette distinction compte, ce qu'il a fallu pour la construire, et pourquoi je crois que l'ère consistant à plaquer une interface de chatbot sur un modèle de fondation en l'appelant « IA juridique » est révolue.

Pourquoi ChatGPT a-t-il inventé une affaire judiciaire ?

C'est la question que tout le monde pose, et que presque personne ne résout correctement.

L'explication courante est la « hallucination » — un mot devenu tellement galvaudé qu'il a perdu toute valeur diagnostique. Ce qui s'est réellement passé dans l'affaire Mata v. Avianca est plus précis et plus accablant. On a demandé au modèle de trouver des précédents sur la responsabilité des compagnies aériennes en cas de blessures de passagers. Il n'a pas interrogé de base de données. Il n'en a pas. Il a prédit la suite de mots la plus probable statistiquement.

« Varghese » est un nom de plaignant plausible. « China Southern Airlines » est un défendeur plausible. Un numéro de rôle comme « 2017 WL 3245891 » suit la syntaxe des citations réelles. Le modèle a assemblé ces fragments de la même façon qu'il assemble un poème ou un e-mail marketing — en minimisant quelque chose que l'on appelle la perplexité, qui est essentiellement une mesure du degré de « surprise » du modèle face à sa propre production. Une faible surprise équivaut à un texte fluide. Un texte fluide n'est pas la même chose qu'un texte vrai.

Le modèle est entraîné à minimiser la perplexité — le degré de surprise face au mot suivant. Il n'est pas entraîné à optimiser la provenance — le fait que ce mot remonte ou non à quelque chose de réel.

C'est là la tension fondamentale. Les LLM optimisent la cohérence. Le droit exige la provenance. Ce sont des objectifs fondamentalement différents, et aucune dose d'ingénierie de prompt ne comble l'écart. Vous pouvez dire à GPT-4 « Vous êtes un avocat rigoureux, ne citez que des affaires réelles. » Il acquiescera et se conformera — jusqu'au moment où ses données d'entraînement ne contiennent pas l'affaire dont vous avez besoin, moment auquel il en inventera une qui sonne juste, parce que sonner juste est littéralement ce pour quoi il est optimisé.

Des chercheurs de Stanford ont testé cela rigoureusement. Les chatbots généralistes, même ceux disposant d'un accès à Internet ou de capacités de recherche de base, hallucinaient entre 58 % et 82 % du temps sur des requêtes juridiques complexes. Pas des cas limites. Des questions de recherche juridique de routine.

Le piège du wrapper

Après Mata, j'ai commencé à répertorier les outils d'IA juridique sur le marché. La plupart d'entre eux étaient ce que le secteur appelle poliment des « wrappers » — de fines interfaces utilisateur superposées à l'API d'OpenAI ou d'Anthropic. Un prompt système disant « Vous êtes un assistant juridique serviable. » Peut-être une fonction de téléversement de PDF. Peut-être une police de caractères plus jolie.

J'ai eu un appel avec un client potentiel — la directrice juridique d'un cabinet de taille moyenne — qui m'a dit qu'elle évaluait l'un de ces outils. « Il est rapide », a-t-elle dit. « Mais la semaine dernière, il a cité une opinion dissidente comme s'il s'agissait de l'attendu majoritaire. Mon collaborateur a failli le déposer. » Elle a marqué une pause. « Le plus effrayant, c'est que l'affaire était réelle. C'était juste l'attendu qui était... faux. »

C'est cela, avec les hallucinations juridiques, qui m'empêche de dormir. Mata était spectaculaire parce que les affaires étaient entièrement fabriquées. Mais les erreurs plus subtiles — affaire réelle, mauvais attendu ; loi valide, mais abrogée depuis ; précédent contraignant de la mauvaise juridiction — sont plus difficiles à détecter et sans doute plus dangereuses. Une fausse affaire est repérée dès la première étape de vérification. Une affaire réelle citée pour une proposition qu'elle n'étaye pas ? Cela peut survivre à plusieurs cycles de relecture.

L'approche wrapper ne peut résoudre ce problème parce qu'elle ne possède pas la couche de données. Elle ne sait pas quelles affaires existent. Elle ne sait pas lesquelles ont été infirmées. Elle ne comprend pas qu'une décision du Second Circuit ne lie pas une cour du Ninth Circuit. C'est une zone de texte élégante branchée sur un moteur de probabilités.

Et l'économie est brutale. L'analyse du marché des wrappers montre que si certains atteignent rapidement des revenus, la grande majorité échoue faute de toute technologie défendable. À mesure que les modèles de fondation s'améliorent, chaque fonctionnalité qui rendait le wrapper utile — synthèse, rédaction, questions-réponses — est absorbée par le modèle de base. Vous construisez sur un terrain loué, et le propriétaire est OpenAI.

Que se passe-t-il quand on donne à l'IA une carte du droit ?

C'est là que commence l'obsession de mon équipe.

La solution standard contre l'hallucination est la génération augmentée par récupération — le RAG. Au lieu de s'appuyer sur la mémoire du modèle, on récupère des documents pertinents dans une base de données et on les fournit comme contexte. C'est une réelle amélioration. Mais pour le droit, ce n'est pas suffisant, et je veux expliquer pourquoi avec un exemple précis qui nous a rendus fous pendant des semaines.

Nous testions un pipeline de vector RAG standard sur la question de savoir si une réglementation environnementale précise de 1990 était encore applicable après une décision de la Cour suprême de 2023. Le vector RAG a fait ce qu'il fait : il a trouvé des fragments de texte sémantiquement similaires à la requête. Il a renvoyé la réglementation. Il a renvoyé l'opinion de la Cour suprême. Il a renvoyé un article de revue juridique traitant des deux.

Le LLM les a assemblés en une réponse assurée et bien rédigée qui était complètement fausse. Il a traité l'article de revue juridique — un commentaire universitaire persuasif mais non contraignant — comme s'il avait le même poids que l'attendu de la Cour suprême. Pire, il a manqué le fait que la réglementation avait été effectivement invalidée, parce que la chaîne d'autorité reliant la réglementation à la décision invalidante passait par une affaire d'appel intermédiaire que la recherche vectorielle n'avait pas récupérée. Le lien n'était pas sémantique. Il était structurel.

Je me souviens de mon ingénieur en chef qui, en plein débogage de ce problème, s'est tournée vers moi et m'a dit : « Le problème n'est pas la récupération. Le problème, c'est que les vecteurs ne comprennent pas les relations. »

Elle avait raison. Et c'est là l'intuition derrière le GraphRAG — la génération augmentée par récupération fondée sur les graphes.

Au lieu de stocker les documents juridiques comme des points isolés dans un espace vectoriel, nous les cartographions dans un Knowledge Graph : un réseau où chaque loi, affaire, réglementation et doctrine juridique est un nœud, et où les relations entre eux — cite, infirme, distingue, interprète, confirme — sont des arêtes explicites et étiquetées. J'ai décrit l'architecture complète dans la version interactive de nos travaux.

Le vector RAG demande : « Trouve du texte qui ressemble à cette requête. » Le GraphRAG demande : « Trouve la loi, parcours l'arête “interprète” pour trouver la jurisprudence, puis parcours l'arête “infirme” pour t'assurer qu'elle est toujours valide. »

Ce n'est pas une différence subtile. C'est la différence entre fouiller une bibliothèque à l'intuition et la fouiller à l'aide du catalogue de fiches, de l'index des citations et du rapport Shepard's simultanément.

Comment empêcher une IA d'inventer une citation ?

C'est la partie qui nous a pris le plus de temps à réussir, et celle dont je suis le plus fier.

Disposer d'un Knowledge Graph est nécessaire mais pas suffisant. Le graphe vous donne la structure. Mais le LLM génère toujours du texte token par token, et à tout moment il pourrait s'écarter du graphe et se mettre à inventer. Il nous fallait un mécanisme qui ne se contente pas d'encourager le modèle à citer des affaires réelles — il l'empêche physiquement de citer des affaires fausses.

Nous appelons cela le décodage contraint par graphe, et le mécanisme central est ce que l'on appelle un KG-Trie.

Voici comment cela fonctionne en clair. Nous prenons chaque entité valide de notre Knowledge Graph — chaque nom d'affaire, chaque citation de recueil, chaque numéro de rôle — et nous construisons un arbre préfixe (un Trie) à partir de ces identifiants. Lorsque le LLM génère du texte et atteint un point où il s'apprête à produire une citation, le mécanisme de contrainte s'active. Il vérifie : quels sont les tokens suivants valides selon le Trie ?

Si le modèle a généré « Mata v. A » — le Trie autorise les tokens qui complètent des noms d'affaires valides commençant par cette chaîne. « Avianca » est valide. Tout le reste voit sa probabilité fixée à moins l'infini. Bloqué.

Si le modèle tente de générer « Varghese v. Chi » — le Trie ne trouve aucune continuation valide. La génération est arrêtée. Le modèle est forcé de revenir en arrière et soit de trouver une citation réelle, soit de produire quelque chose comme « Aucun précédent trouvé. »

L'IA ne peut pas rêver une affaire parce qu'elle ne peut physiquement pas produire la séquence de tokens d'une affaire qui n'est pas dans la base de données vérifiée.

Il s'agit d'une garantie structurelle, et non probabiliste. Nous ne disons pas « le modèle a 95 % de risques en moins d'halluciner. » Nous disons que la voie de la fabrication est fermée. La séquence de tokens d'une fausse citation ne peut littéralement pas être produite.

Maintenant, je veux être précis sur ce que cela fait et ne fait pas. Cela empêche la fabrication — inventer une affaire qui n'existe pas. Cela n'empêche pas la mauvaise interprétation — citer une affaire réelle en en tirant la mauvaise conclusion. C'est une erreur de raisonnement, et elle exige toujours une relecture humaine. Mais éliminer la fabrication est énorme. Cela écarte complètement le mode de défaillance le plus catastrophique — le scénario Mata.

Il y a eu une nuit, au début du développement, où nous avons lancé notre premier test de bout en bout. Nous avons soumis au système la requête exacte qui avait produit les fausses citations dans Mata. Le système contraint a tenté de générer « Varghese », a heurté le mur du Trie, est revenu en arrière et a renvoyé une affaire réelle avec une chaîne de citation valide. Mon ingénieure a envoyé une capture d'écran dans notre groupe de discussion à 1 h 47 du matin. Personne n'a répondu par des mots. Juste une rangée d'émojis de flammes.

Pourquoi les wrappers ne peuvent-ils pas faire cela ?

On me pose cette question constamment, et la réponse est architecturale, pas commerciale.

Le décodage contraint par graphe nécessite de manipuler les probabilités de tokens du modèle — ses logits — en temps réel pendant la génération. Il faut accéder au moteur d'inférence au niveau du décodage. Les API commerciales standard comme GPT-4 n'exposent pas cela. Vous pouvez envoyer un prompt et obtenir une réponse. Vous ne pouvez pas intercepter le processus de génération en plein token pour injecter des contraintes.

C'est pourquoi nous construisons sur des modèles à poids ouverts — Llama, Mistral — ou déployons via des points de terminaison d'entreprise qui autorisent des boucles de décodage personnalisées. Nous hébergeons le modèle. Nous contrôlons le pipeline d'inférence. Nous injectons les contraintes du KG-Trie directement dans la distribution de probabilité de chaque token au fur et à mesure de sa génération.

Un wrapper, par définition, ne peut pas faire cela. Il appelle l'API de quelqu'un d'autre. C'est un passager, pas le pilote.

La partie la plus difficile dont personne ne parle

Construire le mécanisme de contrainte a été intellectuellement satisfaisant. Construire le Knowledge Graph qui le sous-tend a été un calvaire.

Le texte juridique est désordonné d'une manière qui ferait pleurer un ingénieur de données. Une même affaire peut être désignée par « Mata v. Avianca », « Mata », « 678 F. Supp. 3d 443 », « l'affaire Avianca », ou simplement « Id. » — une abréviation de deux lettres signifiant « l'affaire que je viens de mentionner ». Toutes ces désignations doivent se résoudre en un unique nœud canonique dans le graphe. Manquez-en une, et vous avez un trou dans le réseau de citations.

Nous avons passé des mois à construire des pipelines de résolution d'entités qui gèrent la déduplication (« Smith v. Jones, 123 F.3d 456 » et « Smith, 123 F.3d at 456 » sont la même affaire), la désambiguïsation (« Smith v. Jones (1995) » contre « Smith v. Jones (2002) » — affaires différentes, même nom), et l'enfer particulier de la résolution des références « Id. » à l'aide d'une analyse contextuelle par fenêtre glissante.

Et puis il y a le traitement négatif — le système du « drapeau rouge ». Un Knowledge Graph juridique qui traite les affaires infirmées comme une autorité valide est pire qu'inutile. Nous ingérons les signaux de citator — des formulations telles que « infirmée », « abrogée », « remplacée » — et les encodons comme des arêtes bloquantes dans le graphe. Lorsque le système parcourt un chemin et rencontre une arête OVERRULES (« infirme »), ce chemin est invalidé en tant qu'autorité contraignante. Si quelqu'un interroge sur Roe v. Wade au sujet des droits reproductifs, le graphe fait immédiatement remonter l'arête OVERRULES issue de Dobbs v. Jackson. Une recherche vectorielle pourrait encore citer Roe avec enthousiasme parce que le pur volume de texte historique qui l'appuie domine les scores de similarité.

Pour la ventilation technique complète du schéma du graphe, du pipeline de résolution d'entités et de l'architecture de contrainte, voir notre article de recherche.

Qu'est-ce que cela signifie concrètement pour un cabinet d'avocats ?

J'ai eu une conversation avec un associé gérant qui l'a dit sans détour : « Je me fiche des Knowledge Graphs. Ce qui m'importe, c'est de savoir si mes collaborateurs vont me couvrir de honte devant un juge. »

Juste. Alors laissez-moi traduire.

Le coût de l'affaire Mata v. Avianca n'était pas de 5 000 dollars. C'était l'humiliation publique, l'obligation de notifier le client, l'exposition à une faute professionnelle, et le signal envoyé à chaque client potentiel que ce cabinet ne vérifie pas son travail. Pour un grand cabinet, un seul mémoire halluciné est un événement de réputation existentiel.

Le GraphRAG à citations imposées fonctionne comme une police d'assurance contre la fabrication. L'approche wrapper offre un faible coût initial et une responsabilité illimitée. Notre approche exige un investissement réel dans la couche de données et l'architecture de contrainte, mais elle réduit à zéro le risque de fabrication de citations.

Il y a aussi un argument d'efficacité moins évident. À l'heure actuelle, si un cabinet utilise l'IA pour la recherche, un collaborateur doit vérifier chaque citation, une par une. Cette étape de vérification prend souvent plus de temps que la recherche elle-même, ce qui va à l'encontre du but recherché. Les benchmarks du GraphRAG montrent une amélioration de 30 à 35 % par rapport au RAG standard sur les tâches de raisonnement multi-sauts — le type de recherche complexe et connectée qui compte vraiment en contentieux. Plus important encore, parce que les citations sont structurellement garanties valides, le rôle humain passe de « vérificateur de faits » à « relecteur de stratégie ». Vous ne passez pas trois heures à confirmer que des affaires existent. Vous passez ce temps à évaluer si l'argument est persuasif.

Lorsque chaque citation est structurellement vérifiée, le travail de l'avocat passe de la vérification des faits de l'IA à la réflexion stratégique. C'est là que se trouve le véritable levier.

Et il y a une dimension de transparence qui compte pour la conformité. Un wrapper ne peut pas expliquer pourquoi il a choisi une affaire. Un système GraphRAG peut montrer le chemin de parcours exact : « J'ai sélectionné l'affaire A parce qu'elle interprète la loi B et a été confirmée par la cour C, qui fait autorité dans votre juridiction. » Cette piste d'audit n'est pas seulement un plus — elle devient une attente réglementaire.

Où cela nous mène-t-il ensuite ?

Le secteur passe des chatbots aux agents — des systèmes d'IA qui ne se contentent pas de répondre à des questions mais planifient et exécutent des tâches en plusieurs étapes. Un agent juridique chargé de rédiger une requête en irrecevabilité doit rechercher le standard applicable, trouver la jurisprudence à l'appui, vérifier que les affaires font toujours autorité, contrôler les exigences procédurales et assembler l'argument.

Un agent fonctionnant sur une recherche vectorielle n'a pas de carte. Il a une pile de documents et une bonne hypothèse. Un agent fonctionnant sur un Knowledge Graph a une structure explicite qu'il peut parcourir : loi → affaires interprétatives → règles de procédure → exigences propres à la juridiction. Le graphe est la couche de planification de l'agent.

C'est pourquoi je crois que l'investissement dans l'infrastructure de graphe aujourd'hui rapporte des rendements composés plus tard. Les wrappers laissent derrière eux des journaux de conversation. Les Knowledge Graphs laissent derrière eux une carte structurée, croissante et de plus en plus précieuse de l'autorité juridique, qui devient plus utile à chaque affaire ajoutée, à chaque relation encodée, à chaque signal de traitement négatif ingéré.

L'objection honnête

On me rétorque sur deux fronts, et je veux traiter les deux directement.

Premièrement : « N'est-ce pas simplement Westlaw avec des étapes en plus ? » Non. Westlaw est un moteur de recherche pour les humains. Il renvoie des documents qu'un avocat lit et interprète. Ce que nous construisons est une architecture de contrainte pour l'IA — un système qui gouverne ce que l'IA peut et ne peut pas dire. Westlaw aide les avocats à trouver le droit. Le GraphRAG empêche l'IA de l'inventer. Ils sont complémentaires, pas concurrents.

Deuxièmement : « Ne peut-on pas simplement affiner le modèle pour qu'il cesse d'halluciner ? » Nous avons essayé. Au début de nos travaux, nous avons expérimenté l'affinage (fine-tuning) sur des jeux de données juridiques vérifiés. Cela a réduit les taux d'hallucination. Cela ne les a pas éliminés. Un modèle affiné reste un moteur de probabilités. C'est un meilleur moteur de probabilités, mais « meilleur » en matière de citation juridique signifie « se trompe moins souvent », et « se trompe moins souvent » n'est pas un standard qu'un tribunal acceptera. La seule façon de garantir zéro fabrication est de rendre la fabrication structurellement impossible, ce qui signifie contraindre l'espace de sortie, et pas seulement améliorer les données d'entrée.

La fin du « assez bon »

Voici ce à quoi je reviens sans cesse. La profession juridique repose sur une prémisse simple : lorsque vous citez une autorité, cette autorité doit être réelle. Pas probablement réelle. Pas généralement réelle. Réelle.

Pendant les deux années qui ont suivi Mata, les tribunaux n'ont cessé de durcir les sanctions, d'émettre des ordonnances permanentes sur la divulgation de l'IA, et de faire clairement comprendre que « c'est l'IA qui l'a fait » n'est pas une défense. La profession trace une ligne : si vous utilisez l'IA, sa production doit être vérifiée. Et si vérifier la production prend plus de temps que faire le travail manuellement, l'IA n'est pas un outil — c'est un passif.

L'ère du wrapper a résolu le mauvais problème. Elle a rendu la recherche juridique plus rapide. Il fallait rendre la recherche juridique plus digne de confiance. La vitesse sans confiance n'est que de la faute professionnelle efficace.

Ce que nous construisons chez Veriprajna n'est pas un chatbot qui se trouve connaître un peu de droit. C'est un système de raisonnement contraint où chaque citation est un parcours vérifié à travers un Knowledge Graph, où chaque relation est explicite et auditable, et où le modèle génératif est physiquement empêché de basculer dans la fiction.

La profession qui a inventé le concept de précédent contraignant mérite une IA qui le respecte réellement.