Cabinets d'avocats · Pourquoi votre modèle se trompe d'une manière que vous ne verrez pas

Un collaborateur junior dans un cabinet de taille moyenne demande à un assistant juridique IA de résumer les clauses d'indemnisation de 40 contrats fournisseurs. L'outil renvoie un résumé propre et sûr de lui. Aucune référence jurisprudentielle inventée, aucun texte de loi halluciné, rien qui déclencherait un contrôle d'hallucinationhallucinationUne hallucination, c'est lorsqu'un modèle d'IA produit une réponse fluide et assurée mais factuellement fausse, inventée, ou non étayée par ses données sources.Voir la définition complète →. C'est simplement faux : l'outil classe systématiquement les clauses d'« indemnisation mutuelle » comme « unilatérales », parce que le modèle sous-jacent du fournisseur a été fine-tuné principalement sur des modèles de clauses d'indemnisation unilatérales, majoritaires dans son jeu d'entraînement. Personne ne s'en aperçoit avant qu'un associé repère le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → trois mois plus tard, sur des dizaines de notes clients.

Ce n'est pas de l'hallucination. C'est du biais, du drift et de l'excès de confiance : trois modes de défaillance distincts qui se cachent derrière un output fluide et bien formaté. Ils méritent leur propre vocabulaire et leurs propres contrôles.

Hallucination et les défaillances que vous ne voyez pas

L'hallucination fait les gros titres : un modèle invente une référence jurisprudentielle ou un texte de loi qui n'existe pas. C'est bruyant et vérifiable. Vous passez la référence dans Westlaw ou une base de données judiciaire, et soit elle existe, soit elle n'existe pas.

Les trois risques de cette leçon sont plus discrets :

• Biais : distorsion systématique due à des données d'entraînement non représentatives ou historiquement déséquilibrées.
• Drift : dégradation silencieuse ou changement de comportement après la mise à jour du modèle sous-jacent par le fournisseur.
• Erreur assurée : une réponse factuellement ou analytiquement incorrecte, mais livrée avec la même certitude fluide qu'une réponse juste, sans aucun signal de prudence pour le lecteur.

Aucun de ces cas ne déclenche chez le lecteur le réflexe « ça a l'air inventé », parce que l'output est plausible, bien formaté et cohérent en interne. C'est précisément ce qui les rend dangereux dans un cabinet d'avocats, où le produit fini (une note, un redline de contrat, un résumé de due diligence) est souvent crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édité de confiance sur la seule force du ton.

Le biais inscrit dans les données d'entraînement

Les grands modèles de langage (LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète →, systèmes d'IA entraînés sur d'énormes corpus de texte pour prédire et générer du langage) apprennent des schémas à partir du texte sur lequel ils ont été entraînés : documents publics, jurisprudence, contrats, texte web. Les données d'entraînement juridiques présentent des déséquilibres connus.

Exemples concrets pertinents pour les cabinets :

• Déséquilibre juridictionnel : l'essentiel des données d'entraînement publiques surreprésente la jurisprudence fédérale américaine et les systèmes de common law anglophones. Un modèle interrogé sur le droit des sociétés du Delaware sera probablement plus performant que le même modèle interrogé sur le droit des sociétés luxembourgeois ou brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ésilien, sans signaler cet écart de fiabilité.
• Déséquilibre d'époque des précédents : la jurisprudence ancienne et fortement citée est surreprésentée par rapport aux décisions récentes, de sorte qu'un modèle peut sous-pondérer un revirement d'appel de 2024 qui a renversé des décennies de précédent.
• Déséquilibre des modèles de contrats : les jeux de données de fine-tuningfine-tuningLe fine-tuning adapte un modèle pré-entraîné à une tâche ou un domaine précis en poursuivant son entraînement sur un jeu de données plus petit et ciblé, ce qui améliore la précision et le style pour ce cas d'usage.Voir la définition complète → des outils de revue contractuelle s'appuient souvent sur des modèles issus d'une poignée de grands cabinets ou de types d'opérations (par exemple les M&A tech américains), ce qui façonne discrètement ce que le modèle considère comme une rédaction de clause « standard ».

Cela compte pour la gouvernance, car le biais n'est pas un bug que l'on corrige une fois. C'est une propriété de la distribution d'entraînement, et il réapparaît dès que l'outil est poussé hors du domaine pour lequel il a été implicitement optimisé.

Angle réglementaire : l'AI Act européen (Règlement (UE) 2024/1689, en vigueur depuis août 2024) classe certains usages de l'IA dans l'administration de la justice comme « à haut risque », ce qui déclenche des exigences en matière de gouvernance des données, de documentation et de supervision humaine (voir la présentation de l'AI Act par la Commission européenne). Les outils de recherche juridique et de prédiction d'issue de contentieux sont proches de cette ligne, et les cabinets qui les utilisent devraient demander aux fournisseurs une documentation sur la composition des données d'entraînement, et pas seulement des allégations de précision.

Le drift silencieux après les mises à jour des fournisseurs

La plupart des cabinets n'entraînent pas leurs propres modèles. Ils achètent un accès à GPT, Claude, Gemini ou à une surcouche spécialisée en droit (Harvey, CoCounsel, Lexis+ AI, etc.). Le cabinet n'a donc aucun contrôle, et souvent aucune visibilité, sur le moment où le modèle sous-jacent change.

Le model drift signifie ici : le fournisseur déploie une nouvelle version du modèle ou un nouveau fine-tune, et le comportement change, parfois en mieux sur les benchmarks, parfois en pire sur votre cas d'usage précis, sans notification adaptée aux workflows juridiques.

Un schéma documenté dans le secteur (largement discuté depuis 2023, y compris dans les model cards d'OpenAI et d'Anthropic) est que les nouvelles versions de modèles peuvent modifier les habitudes de mise en forme, la verbosité, voire le style de raisonnement, de manière à casser les prompts et templates aval calibrés sur l'ancienne version. Le prompt soigneusement réglé d'un cabinet pour extraire les clauses de résiliation peut produire silencieusement une structure d'output différente après une version mineure, sans aucun message d'erreur.

Pourquoi c'est un problème de gouvernance et pas seulement un désagrément IT : si un cabinet a validé un workflow (disons une première passe de revue de NDA) sur la version A d'un modèle, et que le fournisseur bascule sur la version B, la validation est périmée. Personne ne la retestera, sauf si quelqu'un est explicitement chargé du change management des outils d'IA, c'est-à-dire d'un processus de détection, de journalisation et de revalidation après les changements en amont.

Contrôle pratique : maintenir un « golden set » réduit et figé de dossiers passés dont les bonnes réponses sont connues (par exemple 20 contrats avec les types de clauses pré-annotés). Réexécuter ce golden set sur l'outil chaque mois ou après toute mise à jour connue du fournisseur, et comparer les outputs. C'est l'équivalent IA d'un test de régression en génie logiciel.

# simplified drift check logic
golden_set = load_labeled_contracts()  # 20 contrats, réponses vérifiées par un humain
current_outputs = run_model(golden_set, model_version="current")
baseline_outputs = load_saved_outputs(model_version="baseline")

diff_rate = compare(current_outputs, baseline_outputs)
if diff_rate > threshold:
    flag_for_human_review()

Pour la plupart des cabinets, ce n'est pas un projet de développement technique. C'est une discipline : conserver le golden set, conserver les outputs de référence, réexécuter périodiquement.

Des réponses fausses au ton assuré

Les LLM sont entraînés à produire un texte fluide et grammaticalement assuré, indépendamment de leur certitude interne. Il n'existe pas de signal intégré « je ne suis sûr qu'à 55 % » dans une réponse de chat standard, sauf si le fournisseur en a explicitement conçu un.

Cela crée un risque spécifique en cabinet : le ton de la réponse n'est pas corrélé à sa justesse. Un modèle peut se tromper avec autant d'assurance sur une question inédite de conflit de lois qu'il a raison avec assurance sur un point bien établi d'interprétation contractuelle, et le lecteur n'a aucun indice pour faire la différence.

Les méthodes de détection diffèrent des contrôles d'hallucination :

• Test de calibration : poser périodiquement au modèle des questions dont vous connaissez déjà la réponse et d'autres dont la réponse est réellement incertaine ou contestée, puis vérifier si la confiance exprimée (le cas échéant) suit la justesse réelle.
• Recoupement par un second modèle : passer la même requête dans un second modèle entraîné indépendamment et signaler les désaccords pour revue humaine, puisque des modèles indépendants ont peu de chances de partager les mêmes angles morts.
• Divulgation forcée de l'incertitude : prompt engineeringprompt engineeringLe prompt engineering consiste à concevoir et affiner des instructions textuelles pour guider les grands modèles de langage vers des réponses justes, pertinentes et fiables.Voir la définition complète → ou fonctionnalités du fournisseur obligeant le modèle à citer le passage source ou à signaler ses hypothèses juridictionnelles, transformant une réponse assurée et infalsifiable en réponse vérifiable.

Le NIST AI Risk Management Framework (framework américain volontaire, publié pour la première fois en janvier 2023) sépare explicitement « valide et fiable » de « explicable et interprétable » comme caractéristiques distinctes de fiabilité, précisément parce qu'un output fluide peut avoir l'air fiable sans être explicable ni correct.

Intégrer cela dans la gouvernance du cabinet

Aucun de ces trois risques ne se règle avec le même correctif. C'est la leçon centrale pour la conception de la gouvernance :

Un comité de gouvernance de l'IA au niveau du cabinet (de plus en plus courant dans les cabinets de l'AmLaw 100 en 2025-2026, même si les structures varient et qu'aucun organisme unique ne régule cela aux États-Unis) devrait porter ces trois contrôles, et pas seulement une revue générique de « précision de l'IA ». L'avis formel 512 de l'American Bar Association (juillet 2024) sur l'usage de l'IA générative place déjà le devoir de compétence et de supervision directement sur les avocats, ce qui signifie que ces contrôles ne sont pas du théâtre de gestion du risque : ils correspondent aux règles de responsabilité professionnelle existantes (voir le résumé de l'avis de l'ABA).

Points clés

• Le biais, le drift et l'erreur assurée sont distincts de l'hallucination : ils produisent un output plausible, bien formaté et faux, que la vérification classique des citations ne détectera pas.
• Le biais vient de la composition des données d'entraînement (juridiction, époque, source des modèles de contrats) et exige des tests de précision spécifiques au domaine, pas des benchmarks généraux.
• Le drift survient silencieusement quand les fournisseurs mettent à jour les modèles sous-jacents ; maintenez un « golden set » de dossiers annotés et retestez après toute mise à jour connue.
• Un ton assuré n'est pas un signal de fiabilité dans un output de LLM ; utilisez les tests de calibration, les recoupements inter-modèles et la citation obligatoire des sources pour le mettre au jour.
• Ces risques correspondent directement à des devoirs professionnels existants (avis formel 512 de l'ABA) et à la réglementation émergente (catégories à haut risque de l'AI Act européen) : les contrôles de gouvernance relèvent donc de la conformité, pas d'un raffinement technique.