IA juridique augmentée : ce que cache l'architecture cloud mutualisée

Quand un éditeur juridique promet une IA « augmentée » capable de mobiliser des « compétences métier adaptées au type de dossier et au risque », il décrit sans le dire une architecture multi-agents. Ce n'est plus un simple chatbot qui répond dans une fenêtre de chat : c'est un système d'orchestration qui route une requête vers un agent spécialisé, active des outils, interroge des bases documentaires, puis restitue une synthèse consolidée. Techniquement, c'est une avancée réelle. Commercialement, c'est aussi une manière élégante de ne jamais répondre à la question qui intéresse un associé gérant, un DSI ou un responsable innovation : où transitent les documents du dossier pendant que les agents se parlent entre eux, sur quels serveurs, dans quel pays, et avec quel modèle de langage sous-jacent ?

Dans sa tribune « Lexis Poly avec Protégé : notre IA juridique augmentée, au service de vos missions à forte valeur ajoutée », publiée sur Village Justice, LexisNexis répond à la première partie de la question — la promesse fonctionnelle — sans jamais aborder la seconde : l'architecture technique et le trajet des données pendant l'exécution (source : village-justice.com). C'est une tribune commerciale, ce qui est légitime, mais c'est justement pour cela qu'elle mérite d'être décryptée avec les outils de l'analyse technique plutôt qu'avec ceux du marketing.

Ce que cache la formule « compétences métier adaptées au type de dossier et au risque »

Dans le vocabulaire des architectes IA, « mobiliser des compétences adaptées au type de dossier et au niveau de risque » désigne un pattern précis : l'orchestration d'agents spécialisés, chacun doté d'un prompt système, d'un accès à des outils ou bases documentaires spécifiques, et d'une politique de comportement calibrée sur un type de mission. Un dossier de fusion-acquisition ne mobilise pas le même agent qu'un contentieux prud'homal ou qu'une revue de conformité RGPD. Un agent « haut risque » doit vérifier davantage de sources, citer ses fondements juridiques, et parfois refuser de trancher seul. C'est exactement ce que promettent aussi, sous des formulations différentes, Harvey, CoCounsel ou Claude Cowork : une couche de raisonnement au-dessus du LLM brut, capable de découper une tâche complexe en sous-tâches confiées à des agents spécialisés.

Cette architecture repose sur des briques précises, qu'un DSI de cabinet doit savoir identifier avant de signer :

• Un routeur ou orchestrateur qui analyse la requête entrante et décide quel(s) agent(s) activer
• Un registre d'agents avec leurs prompts, permissions et outils associés
• Un ou plusieurs index documentaires (vector stores) que chaque agent interroge pour récupérer du contexte
• Des connecteurs vers les sources internes du cabinet (DMS, CRM, messagerie)
• Un système de logs traçant qui a demandé quoi, à quel agent, avec quel résultat
• Un ou plusieurs LLM sous-jacents, appelés à chaque étape du raisonnement

La sophistication fonctionnelle vient de l'orchestration. Mais chaque étape d'orchestration est aussi une étape où des données quittent potentiellement le pipeline local pour aller vers un modèle hébergé ailleurs. Plus il y a d'agents, plus il y a d'appels, et plus il y a d'appels, plus il y a de points de sortie des données du dossier.

L'angle mort : le trajet des données pendant l'orchestration

C'est précisément ce que la tribune de LexisNexis ne détaille pas. LexisNexis a publiquement annoncé des partenariats technologiques avec plusieurs fournisseurs de modèles de langage pour alimenter sa gamme Lexis+ AI et Protégé, dont des accords avec des acteurs américains du secteur. Concrètement, cela signifie que lorsqu'un agent « type de dossier » interroge un agent « niveau de risque », l'un des deux, voire les deux, transmettent des extraits du dossier à un LLM tiers hébergé sur une infrastructure cloud américaine, dans le cadre d'un contrat API que le cabinet client n'a ni négocié ni auditée directement — c'est l'éditeur qui a négocié ces conditions en amont, pour l'ensemble de ses clients.

Ce n'est pas une accusation, c'est une description d'architecture SaaS standard, partagée par la quasi-totalité des éditeurs de ce segment. Le problème n'est pas que ces éditeurs utilisent des LLM tiers — RAGbase Legal le fait aussi, selon le choix du cabinet. Le problème est que dans un modèle SaaS mutualisé, le cabinet ne contrôle ni le pipeline d'orchestration, ni la liste exacte des sous-traitants techniques, ni le rythme auquel le modèle sous-jacent change de version — un changement de version de LLM peut modifier le comportement d'un agent du jour au lendemain, sans que le cabinet en soit informé à l'avance ni puisse le tester avant bascule en production.

Pourquoi cette distinction est juridiquement structurante

Un avocat français est soumis à une obligation de secret professionnel définie par l'article 66-5 de la loi n° 71-1130 du 31 décembre 1971, renforcée par les sanctions pénales de l'article 226-13 du code pénal. Cette obligation ne s'éteint pas parce qu'un traitement est confié à un outil d'IA : elle se transpose en obligation de maîtriser la chaîne de sous-traitance. Or, l'arrêt Schrems II de la Cour de justice de l'Union européenne (CJUE, 16 juillet 2020, aff. C-311/18) a invalidé le Privacy Shield et imposé une évaluation renforcée de tout transfert de données personnelles vers les États-Unis, au motif que la législation américaine de surveillance ne garantit pas un niveau de protection équivalent au RGPD. Un cabinet qui déploie une IA orchestrée par un éditeur américain, avec des sous-traitants LLM américains, hérite mécaniquement de cette obligation d'évaluation — et ne peut généralement pas l'assumer seul, faute de visibilité sur l'architecture interne de l'éditeur.

Le Conseil National des Barreaux a d'ailleurs publié des recommandations invitant les cabinets à documenter précisément les traitements de données confiés à des outils d'IA générative avant tout déploiement, dans une logique proche des exigences de l'article 28 du RGPD sur la sous-traitance. La CNIL, dans ses recommandations sur l'IA générative, insiste également sur la nécessité de connaître la finalité exacte du traitement et la localisation des données à chaque étape — une exigence difficile à satisfaire quand l'architecture repose sur plusieurs agents en cascade appelant plusieurs modèles.

Tableau comparatif : où vont réellement les données selon l'architecture

Ce tableau ne dit pas que les solutions cloud sont mauvaises — Harvey revendique environ 100 000 avocats utilisateurs, 144 millions de dollars d'ARR et une valorisation de 8 milliards de dollars fin 2025, ce qui traduit une adoption réelle et une valeur perçue forte sur des cas d'usage à fort volume. Une étude de Stanford a néanmoins mesuré un taux d'hallucination de 1 réponse sur 6 sur ce type d'outil, rappelant qu'orchestration sophistiquée ne signifie pas fiabilité absolue, quelle que soit l'architecture retenue.

Ce qui reste chez vous dans une architecture on-premise

La proposition de RAGbase Legal n'est pas de refuser tout appel à un LLM externe — c'est une option que le cabinet garde, pas une contrainte imposée. La différence tient à ce qui reste physiquement sur l'infrastructure du cabinet, et à ce qui en sort :

• L'agent et l'orchestrateur tournent sur les serveurs du cabinet, pas sur le cloud de l'éditeur
• L'index documentaire complet (vector store, métadonnées, documents sources) reste local
• Les permissions par matière et par utilisateur sont gérées et auditables sur l'infrastructure du cabinet, pas dans un tableau de bord SaaS tiers
• Les logs d'exécution — qui a interrogé quel agent, sur quel dossier — restent internes, exploitables pour un audit ou une revue déontologique
• Seuls des extraits minimaux, sélectionnés par le pipeline local selon la pertinence, sont transmis au LLM choisi par le cabinet, dans les conditions API que ce dernier a lui-même négociées

Cette granularité fonctionnelle — agents spécialisés par type de dossier (contentieux, M&A, conformité, social), calibrés par niveau de risque — est la même promesse que celle de Lexis Poly avec Protégé. Ce qui change, c'est l'endroit où vit le pipeline. Un cabinet peut construire un agent « due diligence » qui interroge uniquement l'index local des contrats du dossier, un agent « veille contentieuse » relié à sa base de recherche de jurisprudence IA, et un agent « conformité » avec des permissions restreintes aux associés référents — le tout orchestré localement, avec un choix de LLM révisable à tout moment sans dépendre de la feuille de route produit de l'éditeur.

L'exemple d'El Murshid illustre ce que permet une indexation locale à l'échelle : 26 000 dossiers indexés, avec un gain de temps de rédaction mesuré entre 5 et 70 % selon la complexité des actes. Ce niveau de performance ne repose pas sur la puissance du LLM seul, mais sur la qualité de l'index et du pipeline de récupération documentaire — exactement la couche qu'une architecture on-premise permet de garder sous contrôle total, indépendamment des évolutions futures des modèles.

Le vrai coût total sur trois ans

Sur un cabinet de taille intermédiaire (50 à 150 avocats), le différentiel de coût cumulé sur trois ans dépasse rapidement plusieurs centaines de milliers de dollars, avant même de comptabiliser le coût de gouvernance nécessaire pour documenter les flux de données vers un éditeur SaaS mutualisé au sens de l'article 28 du RGPD.

Ce qu'il faut évaluer avant de signer

La sophistication d'une IA juridique « augmentée » ne se juge pas à la richesse du vocabulaire marketing — « compétences métier », « valeur ajoutée », « orchestration » — mais à la capacité du cabinet à répondre, documents à l'appui, à quatre questions : où sont hébergés l'index et les documents sources, quelle est la liste exacte des sous-traitants LLM impliqués dans l'orchestration, qui contrôle le rythme de mise à jour des modèles, et que reste-t-il localement en cas de rupture de contrat avec l'éditeur. Ces questions ne sont pas anti-cloud ; elles sont la version 2025 de la diligence raisonnable que tout DSI de cabinet applique déjà à ses autres fournisseurs critiques.

Les éditeurs américains ont raison sur un point : l'avenir de l'IA juridique passe par l'orchestration multi-agents et la spécialisation par type de dossier, pas par le chatbot générique. La question qui reste ouverte pour chaque cabinet n'est donc pas « faut-il de l'IA agentique », mais « sur quelle infrastructure voulons-nous la faire tourner, et qui en garde le contrôle dans cinq ans ». Pour approfondir les arbitrages architecture-coût-conformité, notre guide IA pour cabinets détaille les critères de sélection technique, et notre présentation de l'IA privée pour cabinet d'avocats décrit précisément ce qui reste on-premise dans un déploiement multi-agents.

Avant de signer un abonnement par siège ou de lancer un projet on-premise, la bonne pratique consiste à demander à chaque éditeur, y compris RAGbase Legal, une cartographie écrite de son architecture : liste des sous-traitants, localisation des serveurs, nature exacte des données transmises à chaque appel de modèle, et conditions de portabilité en fin de contrat. C'est cette cartographie, pas la formulation marketing, qui doit guider la décision d'un associé gérant ou d'un DSI de cabinet.