Legora lance 2000 exécutions parallèles d'un agent juridique dans des sandboxes Modal

Tester un assistant conversationnel est simple : on pose une question, on obtient une réponse, on la compare à la référence. Avec un agent qui fouille pendant plusieurs heures des milliers de documents, modifie des fichiers et interroge des bases de données, cela ne fonctionne plus. La plateforme juridique Legora y a été confrontée début 2026. Elle a remplacé son assistant par un agent à part entière et reconstruit son système d'évaluation de zéro.

Pourquoi l'ordinateur portable ne suffit plus

Les anciens evals étaient conçus pour de petites tâches : quelques documents dans l'environnement, le tout tournant en local. Le nouvel agent travaille dans un projet réaliste comptant des milliers de documents et des gigaoctets de données. Une expérience type ressemble désormais à ceci : 100 cas, 4 variantes de harness (l'enveloppe qui entoure le modèle dans l'agent) et 5 exécutions pour chacune. Au total, 2000 lancements, qui doivent tous s'exécuter simultanément. L'ingénieur de Legora Eirik Dräge Steen est catégorique : 10 à 20 exécutions parallèles suffiraient déjà à saturer un ordinateur portable.

Le second problème est plus subtil : la fidélité de l'environnement. L'agent de Legora couvre tout le produit : un éditeur DOCX headless, des instances dédiées de Turbopuffer, la conversion de PDF, Postgres et une base d'autorisation, un stockage de blobs et des sandboxes dynamiques pour l'exécution de code. Pour mesurer l'effet d'une migration de base ou d'une modification de la sandbox de code, chaque exécution a besoin précisément de cette version de toute l'application. Les mocks ne conviennent pas ici.

Fonctionnement : une sandbox, une exécution

Chaque exécution reçoit une Modal Sandbox distincte, avec une image et un système de fichiers personnalisés. À l'intérieur, toute l'application est lancée, figée sur un commit précis. Les ingénieurs lancent les expériences depuis leur portable, mais tout le calcul se fait dans le cloud. Legora a comparé plusieurs fournisseurs de sandboxes cloud et a choisi Modal pour sa capacité de passage à l'échelle, sa faible latence de démarrage et sa prise en charge des environnements complexes : l'application comme l'image sont très volumineuses.

Quelques astuces à retenir :

• L'état du monde dans des Volumes. De grandes collections de documents sont accessibles dans toutes les sandboxes. Le snapshot inclut les documents, la base, les droits et les blobs : les exécutions répétées partent ainsi des mêmes données, et la partie commune est dédupliquée.
• Préchauffage horaire. La construction de l'image géante ralentissait au départ les exécutions. Désormais, une fois par heure, le pipeline construit l'image et préchauffe les sandboxes ; la réinitialisation à un commit se réduit au delta depuis la dernière construction, et non à une build complète de l'application.
• Secrets. Une tâche dédiée synchronise chaque heure les valeurs du coffre de clés vers les Modal Secrets. S'y ajoutent une rotation fréquente, des droits minimaux, des exigences d'ancienneté des dépendances et une liste blanche de domaines.

Un chapitre à part : le passage de gVisor aux VM Sandboxes. L'application de Legora est composée de services Docker, et sous gVisor il fallait multiplier les contournements : un réseau en mode host avec sa propre résolution DNS, et l'exécution des sandboxes de code comme simples processus, car FUSE ne se montait pas. Dans une machine virtuelle dotée d'un vrai noyau Linux, Docker se comporte comme sur un hôte ordinaire, et l'équipe a supprimé toutes ces rustines.

Ce que cela a apporté et où est le piège

La plateforme est devenue l'outil principal d'évaluation de la qualité de l'agent. On y exécute le benchmark interne BAR, un ensemble de longues tâches juridiques réalistes, et on compare les modèles de base en termes de qualité, de coût et de latence. De ces résultats dépendent le choix du modèle en production et la conception du harness.

Ce qui est plus intéressant, c'est autre chose : les evals ont été enveloppés dans une CLI et un skill, et désormais les agents créent eux-mêmes des cas, lancent des expériences et analysent les résultats. La plupart des ingénieurs travaillent avec les evals par l'intermédiaire d'agents. Si l'on donne à un agent une métrique, des outils d'expérimentation et un budget, il ajustera le harness jusqu'à ce que la métrique s'améliore. C'est ainsi que Legora a optimisé la recherche d'outils, la génération de PowerPoint et la reproduction d'articles scientifiques. L'un des résultats : une baisse de 30 % du coût de l'agent grâce à une compaction du contexte (compaction) plus intelligente et à une implémentation maison de la recherche d'outils.

Le piège, c'est qu'il s'agit d'un blog de Modal, donc d'un cas client publié par un fournisseur. Il n'y a pas de chiffres sur la latence de démarrage, sur le prix de 2000 exécutions ou sur la part de lancements instables. Pour les « 30 % », on ne précise ni sur quel benchmark ni s'il y a eu perte de qualité. L'approche elle-même n'est toutefois pas liée à une seule plateforme : on peut la reproduire ailleurs, à condition qu'elle gère les images lourdes et offre un vrai Docker.

Ce qu'il faut retenir :

• Si l'agent touche à des bases de données, des fichiers et des services externes, testez-le sur une copie complète du produit, pas sur des mocks.
• Figez non seulement le code, mais aussi les données : un snapshot des documents, des droits et de l'état de la base rend les exécutions comparables.
• Préchauffez les images selon un calendrier afin que la réinitialisation à un commit n'exige pas une build complète.
• Lancez plusieurs exécutions par cas : l'agent est non déterministe, et chez Legora il y en a 5.
• Enveloppez les evals dans une CLI pour que les agents puissent lancer eux-mêmes des expériences et améliorer le harness dans la limite d'un budget.