Hallucinations de l’IA en justice : plus de 2 000 décisions, que construire ?

Plus de 2 000 décisions de justice sur des hallucinations d’IA. Pourquoi le RAG seul n’a pas suffi, et des patterns tirés de mon travail en IA contractuelle.

Au 14 septembre 2026, la base de données AI Hallucination Cases de Damien Charlotin recense 2 041 décisions de cours et de tribunaux portant sur des contenus hallucinés par l’IA. Dans la plupart d’entre elles, une juridiction a constaté ou laissé entendre qu’une partie s’était appuyée sur un tel contenu ; à titre d’exception, la base inclut aussi certaines décisions où le recours à l’IA était allégué sans être confirmé. La recherche documentaire, à elle seule, n’est pas la solution : trois outils de recherche juridique de premier plan, testés en 2024 dans une étude menée par Stanford, ont chacun halluciné dans 17 à 33 % des cas. Ce qu’il faut construire, c’est une structure qui rend les sorties vérifiables, une personne qui décide, et un jeu d’évaluation constitué dès le départ.

J’ai été ingénieur IA sur Kartez Contract ; voici ce que je garderais de ce travail, et ce que je ferais en premier.

Ce que la base des affaires d’hallucinations d’IA apprend aux concepteurs, et ce qu’elle ne dit pas

Le décompte de Charlotin a dépassé les 2 000. Trois points comptent avant de le citer dans une présentation commerciale ou une note sur les risques.

La base compte des décisions, pas des erreurs. Elle « ne recense pas l’univers (nécessairement plus vaste) de toutes les fausses références ou de tout usage de l’IA dans les écritures judiciaires ». C’est un registre des défaillances arrivées jusqu’à un juge, pas un taux d’hallucination.

Elle n’incrimine pas les outils. Sa propre note précise que la mention d’un outil « ne signifie pas nécessairement que cet outil était responsable des hallucinations en question » ; rien ici ne relie donc une décision de la base à un outil. Les outils nommés plus bas proviennent de l’étude de Stanford, pas de la base.

Les catégories comptent plus que le total. Dans la base de Charlotin, 1 690 décisions portent l’étiquette Fabricated (contenu inventé), 854 l’étiquette Misrepresented (contenu déformé) et 548 l’étiquette False Quotes (fausses citations), et une même décision peut porter plusieurs étiquettes. Un contrôle de l’existence de la source citée peut repérer la plupart des cas de la première catégorie, les sources juridiques inventées. Ce contrôle laisse passer les deux autres dès que la source est réelle, mais que la citation est inventée ou que la lecture qui en est faite est erronée. Un outil contractuel peut commettre ces deux erreurs tout en désignant une clause qui existe bel et bien.

Charlotin recense aussi 1 174 décisions où la partie ayant utilisé l’IA se défendait seule, sans avocat (pro se litigant), et 811 où il s’agissait d’un avocat : un outil d’IA juridique ne peut donc tenir pour acquis ni qu’un avocat se trouve dans la boucle, ni qu’il repérera ses erreurs. Avec 449 décisions, le droit des contrats (Contract) est le domaine juridique le plus représenté de sa base. Il s’agit de litiges contractuels dans lesquels un contenu halluciné par l’IA était en cause, et non de contrats rédigés par une IA.

Le RAG empêche-t-il les hallucinations de l’IA juridique ?

Non. L’étude de Stanford présentée ci-dessous conclut que la génération augmentée par récupération (RAG) appliquée au droit « peut réduire les hallucinations par rapport aux systèmes d’IA généralistes (ici, GPT-4), mais les hallucinations restent substantielles, variées et potentiellement insidieuses ». « Insidieuses » est le mot juste : une réponse mal ancrée arrive accompagnée d’une source bien réelle. La conception générale des garde-fous est décrite dans Garde-fous contre les hallucinations en RAG.

L’étude menée par Stanford : 17 à 33 %

Dans un article mis en ligne sur arXiv le 30 mai 2024, des chercheurs de Stanford et de Yale ont présenté « la première évaluation empirique préenregistrée d’outils de recherche juridique fondés sur l’IA ». Préenregistrée signifie que l’étude et son jeu de plus de 200 requêtes juridiques ont été enregistrés avant que l’évaluation ne soit menée : un garde-fou contre le choix des requêtes en fonction des résultats. Dans leur communication commerciale, certains fournisseurs avaient présenté la recherche documentaire comme un moyen d’« éliminer » ou d’« éviter » les hallucinations. L’étude a établi que Lexis+ AI, Westlaw AI-Assisted Research et Ask Practical Law AI hallucinaient chacun dans 17 à 33 % des cas, et que « les affirmations des fournisseurs sont exagérées ».

La définition compte plus que la fourchette. Une réponse est considérée comme hallucinée « si elle est soit incorrecte, soit mal ancrée » (misgrounded), et mal ancrée signifie que des propositions clés sont « citées, mais interprètent mal la source ou renvoient à une source inapplicable ». Les outils ont été testés en 2024, sur de la recherche juridique et non sur des contrats : cette fourchette ne vaut donc pas pour l’IA juridique d’aujourd’hui. La catégorie, elle, se transpose : dans un contrat, une réponse mal ancrée sonne juste et désigne la mauvaise clause.

Le constat de Google sur le contexte suffisant : plus de contexte, moins d’abstentions

L’article « Sufficient Context » distingue les erreurs où le modèle exploite mal un bon contexte de celles où le contexte n’a jamais suffi pour répondre. Les modèles les plus grands qu’il a testés, de Google, OpenAI et Anthropic, « produisent souvent des réponses incorrectes au lieu de s’abstenir lorsque le contexte n’est pas » suffisant.

Le billet de Google Research consacré à ces travaux (14 mai 2025) indique que si le RAG « améliore généralement les performances globales, il réduit paradoxalement la capacité du modèle à s’abstenir de répondre lorsque cela s’impose ». Dans l’exemple de Google, Gemma donnait des réponses incorrectes à 10,2 % des questions sans aucun contexte, et à 66,1 % avec un contexte insuffisant.

La recherche documentaire change ce que voit le modèle, pas sa capacité à savoir s’il en a assez. Une question sur la résiliation peut dépendre d’une définition ou d’une clause de préavis qui n’a jamais été retrouvée. La conception doit faire de « j’ai besoin d’une autre section » une sortie normale, et l’évaluation doit le tester.

Analyse de contrats par IA : les défaillances qui comptent

Une clause inventée devient un risque juridique pour quiconque signe : un modèle qui en invente une est donc pire que pas de modèle du tout. Voici les défaillances que je chercherais à prévenir en priorité dès la conception. Aucun des patterns ci-dessous ne prouve qu’une réponse est juste ; la plupart permettent de repérer une réponse fausse.

Défaillance

Dans un contrat

Pattern qui la rend vérifiable

Contenu inventé

Une clause ou une échéance que le document ne contient pas

Réponses tirées des clauses sélectionnées ; l’utilisateur accepte chaque modification

Formulation mal citée

Une correction qui modifie un texte absent du document

Chaque correction cite la formulation actuelle à l’identique

Réponse mal ancrée

Une réponse tirée de la mauvaise clause, ou d’une section jamais montrée

Sélection des clauses ; consigne de demander les sections manquantes

Sortie défectueuse

Une liste de risques tronquée présentée comme complète

Schémas fixes, jamais affichés bruts ; contrôle de complétude des réponses réparées (recommandé)

Modifications partielles

Une partie renommée dans une seule section

Modifications de l’ensemble du contrat planifiées, appliquées partout, surlignées

Valeurs modifiées

Un montant, une date ou un nom altéré lors d’une réécriture

Un contrôle des valeurs à l’identique (recommandé plus bas)

Patterns de conception d’IA contractuelle tirés de Kartez Contract

De novembre 2025 à juillet 2026, j’ai travaillé comme ingénieur IA sur Kartez Contract, un espace de travail contractuel trilingue, conçu pour l’écriture de droite à gauche, doté d’un assistant de rédaction pas à pas, d’un parcours d’analyse et d’un studio de contrats. J’ai refondu et étendu le moteur d’IA qui sous-tend ces parcours, en partant des premières chaînes d’IA élémentaires du client, et j’ai construit le copilote qui classe chaque demande, retrouve les clauses pertinentes et planifie les modifications sur l’ensemble du contrat.

Les problèmes les plus difficiles ont été la recherche documentaire et l’ancrage, et l’ancrage a reposé sur la structure plutôt que sur la confiance. Aucun des six patterns ci-dessous n’est une garantie mesurée ; les quatre premiers sont les contraintes d’ancrage elles-mêmes.

Des réponses tirées uniquement des clauses sélectionnées par le copilote

Le contrat de l’utilisateur était découpé selon sa propre structure, y compris les articles, clauses et notes (ماده، بند، تبصره) que les contrats persans numérotent à leur manière. Seules les sections pertinentes pour une question servaient à y répondre, et le copilote avait pour consigne de signaler lorsqu’il avait besoin de sections qui ne lui avaient pas été montrées.

La clause est une unité avec laquelle un juriste travaille déjà : un évaluateur peut donc étiqueter et vérifier des résultats de recherche composés de clauses. La consigne offre au modèle une autre issue que de deviner, mais ce n’est pas un contrôle imposé ; le jeu d’évaluation doit donc contenir des questions auxquelles les clauses sélectionnées ne permettent pas de répondre. La recherche documentaire en persan a ses propres pièges, traités pour un autre système dans Recherche hybride pour le RAG en persan.

Des corrections qui citent le contrat à l’identique

Chaque correction suggérée devait citer mot pour mot la formulation actuelle, afin de pouvoir la retrouver et la remplacer, et s’accompagnait d’un texte de remplacement prêt à l’emploi. C’est cette exigence qui rend possible la validation par citation exacte : un programme peut confirmer que le texte cité existe avant que la correction ne soit appliquée.

Savoir si une réécriture est judicieuse relève du jugement juridique. Savoir si la phrase qu’elle remplace existe relève d’une comparaison de chaînes. Les recommandations de l’OWASP sur les informations erronées produites par les LLM défendent le principe général : « valider automatiquement les sorties clés, en particulier celles issues d’environnements à fort enjeu ». Si je devais reconstruire ce système, j’écarterais toute correction dont la citation est introuvable, je ne l’appliquerais jamais de manière approximative, et je suivrais le nombre de ces rejets comme un signal d’alerte précoce.

Ces corrections se situent dans le parcours d’analyse, qui n’avait pas été entièrement testé à l’arrêt des travaux : le pattern repose donc sur sa logique, pas sur une mesure.

Des schémas de sortie fixes, jamais affichés bruts

Chaque analyse renvoyait une structure fixe, de sorte que chronologies, registres des risques et corrections étaient présentés de la même manière à chaque fois. Une réponse mal formée passait par une étape d’analyse syntaxique et de réparation en plusieurs temps, y compris la réparation des réponses tronquées, et était relancée avec davantage de marge si nécessaire. Elle n’était jamais montrée brute à l’utilisateur.

Cela vise une défaillance silencieuse : une liste de risques tronquée paraît complète au lecteur. La réparation seule ne règle pas le problème, car une liste coupée puis refermée reste syntaxiquement valide ; je relancerais donc la requête, ou je signalerais la troncature réparée, plutôt que d’afficher la liste comme si elle était entière. Un schéma donne aussi aux autres contrôles un endroit connu où chercher.

Un faible degré d’aléa pour la rédaction

Pour la rédaction, le modèle fonctionnait avec un faible degré d’aléa. On y gagne en reproductibilité, pas en exactitude : une même entrée tend à produire le même texte, si bien que les défaillances peuvent être reproduites et les exécutions d’évaluation comparées.

Des parcours guidés, pas une seule fenêtre de discussion pour tout

Rédiger, analyser et modifier sont des tâches différentes, et chacune appelle son propre parcours guidé, pas une fenêtre de discussion unique. L’analyse, par exemple, est rédigée du point de vue de l’utilisateur : sa première étape lui demande donc son rôle dans l’opération.

L’article « Building effective agents » d’Anthropic emploie le terme workflow au sens de l’orchestration : « des systèmes où les LLM et les outils sont orchestrés selon des chemins de code prédéfinis ». Selon lui, les workflows « offrent prévisibilité et cohérence pour des tâches bien définies ». Chaque étape fixe a une forme d’entrée et de sortie connue, que l’on peut vérifier. Une fenêtre de discussion vierge accepte n’importe quoi et renvoie n’importe quoi.

Des modifications surlignées, que l’utilisateur accepte ou rejette

Dans les trois parcours, la règle était la même : l’IA propose, l’utilisateur décide. Les modifications du copilote étaient surlignées dans l’éditeur pour que l’utilisateur les accepte ou les rejette. Une instruction portant sur l’ensemble du contrat, comme renommer une partie, était d’abord planifiée, puis appliquée à chaque section concernée et surlignée.

L’utilisateur juge les changements signalés au lieu de relire le document, et un changement de nom est surligné partout où il a été appliqué, au lieu d’être découvert plus tard sous la forme d’une incohérence.

Un autre système : les sas de validation de l’assistant de ce site

Rien de ce qui est décrit dans cette section ne faisait partie de Kartez Contract. L’assistant de ce site, que j’ai construit et que je maintiens, ne répond qu’à partir du contenu du site lui-même, derrière des sas de validation déterministes.

Certaines questions sont refusées par détection de motifs avant toute recherche : tarifs et disponibilité, informations privées, spéculations, tentatives visant le prompt système et demandes de tâches, comme écrire du code ou traduire un texte. Si une question ne me concerne pas et qu’aucun résultat de la recherche n’atteint un seuil minimal de score, l’assistant refuse de répondre et le modèle n’est jamais appelé. Les questions qui me concernent sont elles aussi reconnues par détection de motifs, à des indices comme mon nom ou un pronom de la troisième personne, et ne sont pas refusées du seul fait qu’aucun passage n’atteint le seuil. Le modèle reçoit à la place les fiches du site lui-même, tirées de son CV, de ses études de cas, de ses articles et de ses services, avec la consigne de répondre par un jeton fixe si elles ne couvrent pas la question ; le lecteur voit alors le même refus. Pendant la diffusion d’une réponse, un sas phrase par phrase vérifie chaque phrase complète avant qu’elle ne soit affichée :

  • Plage des références. Chaque marqueur de référence renvoie à une source fournie au modèle.

  • Référence obligatoire. Chaque phrase substantielle porte un marqueur.

  • Valeurs étayées. Chaque nombre, URL et adresse e-mail figure dans une source que la phrase cite.

  • Voix. Aucune phrase n’emploie de pronom de première personne comme « je », « me » ou « nous ».

Une seule phrase en échec interrompt la réponse, et cette phrase n’est jamais affichée. Les marqueurs de référence sont vérifiés, puis retirés : les lecteurs ne les voient jamais.

Le mécanisme est détaillé dans Garde-fous LLM en streaming. La démo RAG et sans RAG diffuse une vraie réponse ancrée à côté d’une colonne brute qui reste vide par conception ; posez une question qui ne me concerne pas et que le site ne couvre pas, et l’exécution s’arrête avant d’atteindre le moindre modèle. Si je construisais un outil contractuel, j’ajouterais le même type de contrôle pour les montants, les dates et les noms des parties, chaque valeur devant correspondre mot pour mot à la source.

Comment évaluer une IA juridique : constituer d’abord le jeu d’évaluation

L’ordre habituel consiste à construire, puis à mesurer. Pour l’IA juridique, je l’inverserais.

  1. Une contrainte de conception est une hypothèse. « Les corrections doivent citer le contrat à l’identique » est une règle. La fréquence à laquelle le modèle l’enfreint est un nombre, et seul un jeu d’évaluation permet de l’obtenir.

  2. Chaque changement exige un test de non-régression. Sans jeu fixe, chaque changement de modèle, de prompt ou de recherche documentaire est jugé à l’intuition.

  3. Le jeu survit au projet. Un jeu étiqueté et sa dernière exécution sont des éléments de preuve dont d’autres peuvent se servir. Une liste de principes de conception, non.

Ce qui s’est passé sur Kartez Contract

Le client a interrompu la mission un mois avant son achèvement, lorsque des difficultés financières liées à la guerre ont mis fin au financement. Il s’agissait d’un échec de financement côté client, et non d’un échec de livraison. À ce stade, l’assistant de rédaction pas à pas, le studio de contrats avec son copilote et l’interface trilingue étaient construits et raccordés de bout en bout. Le parcours d’analyse était construit sur l’ensemble de ses cinq étapes, mais il n’avait pas été entièrement testé et faisait encore l’objet d’ajustements à l’arrêt des travaux.

Il n’existe aucun taux d’exactitude, car la mission s’est arrêtée avant qu’un jeu d’évaluation formel ne soit constitué. Les contraintes de conception étaient réelles ; le chiffre qui les aurait transformées en affirmation n’a jamais été produit.

Un jeu d’évaluation dès la première semaine pour l’IA contractuelle

Ce qui suit est un conseil, pas la description de quoi que ce soit dont disposait Kartez Contract. Chaque élément donne un résultat binaire : réussite ou échec.

  • Des questions auxquelles le contrat répond, étiquetées avec leur clause. La réponse doit être juste et s’appuyer sur cette clause.

  • Des questions auxquelles le contrat ne répond pas. Le résultat attendu est « j’ai besoin de la section X » ou « le contrat ne le précise pas », pas une réponse.

  • Des demandes de modification. Chaque passage cité dans une correction proposée doit se retrouver tel quel, par comparaison de chaînes, dans le document source.

  • Des modifications de l’ensemble du contrat. Renommer une partie doit modifier chaque occurrence, et rien d’autre.

  • Des valeurs qui ne doivent pas bouger. Montants, dates, délais de préavis et noms des parties, comparés à l’identique avant et après chaque réécriture.

  • Des sorties défectueuses. Les réponses tronquées ou mal formées ne doivent jamais arriver brutes à l’écran, et une troncature réparée ne doit jamais être présentée comme complète.

  • La structure persane. Numérotation par ماده, بند et تبصره, lignes mêlant les deux sens d’écriture et chiffres persans.

  • Les deux côtés de l’opération. Le même contrat analysé depuis la position de chaque partie.

Échéances de l’AI Act européen après l’omnibus numérique : un regard d’ingénieur

  • Le Parlement européen a adopté le texte final le 16 juin 2026, et le Conseil le 29 juin 2026.

  • Le marquage des contenus générés par l’IA doit être en place au plus tard le 2 décembre 2026 pour les systèmes mis sur le marché avant le 2 août 2026.

  • Les autres obligations de transparence de l’article 50, comme celle d’informer les utilisateurs qu’ils ont affaire à un système d’IA, s’appliquent à partir du 2 août 2026.

  • Les obligations relatives aux systèmes à haut risque autonomes de l’annexe III sont reportées au 2 décembre 2027. Pour l’IA intégrée à des produits couverts par la législation sur la sécurité visée à l’annexe I, l’échéance est le 2 août 2028.

Le champ d’application est une question à soumettre à un juriste. Aucun des patterns ci-dessus n’est une mesure de conformité.

Checklist pour construire ou acheter une IA juridique

  • Sur quoi chaque réponse s’appuie-t-elle ? Sur une clause ou une section, pas sur « le document ».

  • Chaque modification peut-elle être localisée ? Chaque changement cite le texte qu’il remplace, et cette citation est vérifiée dans le document.

  • L’outil sait-il dire que la réponse n’y figure pas ? Demandez une démonstration.

  • La sortie est-elle validée avant affichage ? Les réponses défectueuses sont réparées ou ne sont pas affichées.

  • Quelque chose change-t-il sans acceptation ? Rien ne devrait changer.

  • Y a-t-il un parcours par tâche ? Rédaction, analyse et modification ne devraient pas partager une même fenêtre de discussion.

  • Les valeurs sont-elles vérifiées à l’identique ? Montants, dates et noms des parties, par rapport à la source.

  • Puis-je voir le jeu d’évaluation ? Ce qu’il contient, quels éléments testent l’abstention et quand il a été exécuté pour la dernière fois.

Si vous cadrez un système d’IA contractuelle ou juridique, le Diagnostic de projet transforme cinq questions en une première architecture.

Questions fréquentes

Combien d’affaires d’hallucinations d’IA sont arrivées devant les tribunaux ?

Au 14 septembre 2026, la base de données AI Hallucination Cases de Damien Charlotin recense 2 041 décisions de cours et de tribunaux portant sur des contenus hallucinés par l’IA. Dans la plupart d’entre elles, une juridiction a constaté ou laissé entendre qu’une partie s’était appuyée sur un tel contenu ; à titre d’exception, certaines décisions où le recours à l’IA était allégué sans être confirmé y figurent aussi. La base recense des décisions, pas chaque fausse référence ni chaque usage de l’IA dans les écritures judiciaires.

Le RAG réduit-il les hallucinations de l’IA juridique ?

Il les réduit, sans les faire disparaître. Dans une étude préenregistrée menée par Stanford, trois outils de recherche juridique à base de RAG hallucinaient moins que GPT-4, mais chacun hallucinait encore dans 17 à 33 % des cas lors des tests de 2024. Les travaux de Google sur le contexte suffisant ont montré que les modèles les plus grands répondent souvent de manière incorrecte au lieu de s’abstenir lorsque le contexte retrouvé ne suffit pas.

L’IA peut-elle analyser des contrats de manière fiable ?

Pas si on la croit sur parole. Ce que l’on peut construire, c’est une analyse qui rend les erreurs vérifiables : des réponses tirées des clauses sélectionnées, des corrections qui citent le contrat à l’identique, des schémas de sortie fixes et une personne qui accepte ou rejette chaque changement. Savoir si un outil détecte réellement les erreurs relève de la mesure : demandez donc à voir son jeu d’évaluation.

Qu’est-ce que la validation par citation exacte ?

C’est un contrôle qui vérifie, avant qu’une correction proposée ne soit appliquée, que le texte qu’elle cite existe mot pour mot dans le document actuel. Il suppose une règle imposant à chaque correction de citer la formulation qu’elle remplace, et il ramène une partie d’une modification juridique à une comparaison de chaînes.

Pourquoi n’y a-t-il aucun taux d’exactitude pour Kartez Contract ?

Le client a interrompu la mission un mois avant son achèvement, pour des raisons de financement liées à la guerre, avant qu’un jeu d’évaluation formel ne soit constitué. Ce site n’avance pas de chiffres qu’il n’a pas mesurés. C’est ce manque qui conduit cet article à plaider pour constituer le jeu d’évaluation en premier.

Sources