Legora a fait passer la précision des citations juridiques de 70 % à 99 % sans accès aux données

L’équipe de Legora fait face à un problème délicat, mais de plus en plus courant : son agent juridique travaille sur des documents confidentiels, tandis que les développeurs ne peuvent pas simplement ouvrir une trace pour voir où le modèle a pris la mauvaise direction. Les données appartiennent aux clients des cabinets d’avocats. Le cycle habituel — « repérer une mauvaise réponse, lire la requête, corriger le prompt » — ne fonctionne donc pas ici.

Legora organise ses évaluations autrement. Ingénieurs et juristes créent des environnements de test proches du travail réel : des espaces contenant des milliers de fichiers, des tâches consistant à rechercher des clauses dans des contrats, à préparer des brouillons et à vérifier des citations. Il ne s’agit pas de copies parfaites des dossiers clients, mais de bancs d’essai suffisamment proches pour détecter les erreurs récurrentes avant la mise en production.

Comment évaluer ce que l’on ne peut pas voir

Imaginons un agent chargé d’examiner 10 000 contrats et de produire un tableau indiquant la durée de validité, le droit de résiliation, les pénalités et un lien vers le passage source. Dans un projet réel, le développeur n’a le droit de lire ni les contrats ni les réponses de l’agent. Il peut toutefois constituer un jeu artificiel présentant la même structure : documents longs, annexes contradictoires, champs manquants et plusieurs formulations d’une même clause.

L’équipe définit ensuite à l’avance les bonnes réponses et mesure chaque étape séparément : le bon document a-t-il été trouvé, la clause a-t-elle été extraite, la conclusion correspond-elle à la source et la citation renvoie-t-elle au bon endroit ? Dans un entretien, le CTO de Legora, Jacob Lauritzen, décrit une équipe dédiée réunissant ingénieurs et juristes pour construire ces environnements. Ils rappellent les « mondes » utilisés dans les jeux pour entraîner des agents : le système reçoit une tâche réaliste sans jamais entrer en contact avec le dossier confidentiel du client.

Lorsqu’une défaillance apparaît malgré tout sur des données réelles, Legora s’efforce de ne pas sortir le texte source de l’environnement protégé. L’équipe utilise des exemples anonymisés ou reformulés et ramène les problèmes à 10–20 catégories. Par exemple : l’agent a choisi la mauvaise version du contrat, a perdu une exception à une règle ou a fourni une citation convaincante en apparence, mais qui n’étaye pas la conclusion. Une telle catégorie peut ensuite être reproduite sur un jeu de données sûr.

Les métriques comptent davantage qu’une belle démonstration

L’exemple des citations est particulièrement révélateur. Selon Lauritzen, lors d’un test, le modèle indiquait correctement ses sources dans environ 70 % des cas. Après une mise à jour ultérieure du modèle de base, ce taux est passé à 99 %, alors même que Legora n’avait pas modifié son propre système. C’est une bonne nouvelle pour le produit, mais aussi un avertissement : la qualité d’un agent ne dépend pas uniquement de votre code. Le fournisseur du modèle peut soudainement corriger un point faible — ou casser ce qui fonctionnait la veille.

Un score global unique ne suffit donc pas. Il faut évaluer séparément la recherche, l’extraction des faits, les citations, le traitement des documents longs et le remplissage des tableaux. Un nouveau modèle ne doit pas être déployé simplement parce qu’il répond mieux à quelques questions manuelles. Il faut l’exécuter sur un ensemble fixe de tâches et le comparer à la version précédente pour chaque scénario critique.

Ce que les produits ordinaires peuvent en retenir

L’approche de Legora n’est pas utile qu’aux juristes. Un assistant bancaire, un agent médical ou un moteur de recherche interne se heurtent à la même limite : le produit doit progresser, mais les données brutes ne peuvent pas être remises aux développeurs. La recette pratique comporte quatre éléments : décrire les scénarios professionnels réels, construire leurs équivalents sûrs, annoter les résultats attendus et tenir un catalogue des défaillances récurrentes.

La limite est évidente : une simulation est toujours moins riche que la réalité. Elle ne révélera pas une formulation rare, une structure d’archive inhabituelle ou une erreur qui n’apparaît que dans une combinaison précise de documents. Les tests synthétiques ne remplacent donc ni les retours utilisateurs protégés ni les métriques produit agrégées. Ils apportent autre chose : un environnement reproductible dans lequel le modèle, la recherche et l’interface peuvent évoluer sans donner accès aux secrets d’autrui.

La principale leçon pour les développeurs est simple : lorsque les traces sont fermées, l’observabilité ne disparaît pas — elle doit être conçue. Ne commencez pas par tout journaliser, mais par dresser la liste des décisions dont l’agent est responsable et des signaux mesurables indiquant un résultat correct. La confidentialité cesse alors de servir d’excuse à l’absence d’évaluations et devient une contrainte autour de laquelle bâtir le système d’ingénierie.