IA juridique : la gouvernance se joue dans l'architecture, pas les CGU

Un associé gérant qui déploie un outil d'IA générative dans son cabinet sans politique d'usage formalisée prend un risque qu'il ne mesure pas toujours : celui de ne plus pouvoir répondre, le jour d'un contrôle du bâtonnier ou d'un contentieux sur une fuite de données, à la question la plus simple qui soit — qui a interrogé quoi, sur quel dossier, et où est allée la donnée. Ce n'est pas un problème de vitesse d'adoption. C'est un problème d'architecture.

Le diagnostic : une gouvernance qui reste sur le papier

Une tribune récente publiée sur Village Justice pose un constat que beaucoup de directeurs innovation partagent en privé : l'adoption de l'IA générative dans les cabinets d'avocats a largement devancé la construction de cadres de gouvernance solides. Politiques d'usage inexistantes ou génériques, comités IA sans mandat clair, audit des outputs laissé à l'appréciation individuelle de chaque collaborateur. L'auteur parle d'un « exercice d'équilibre difficile » entre gains de productivité et maîtrise des risques — confidentialité, biais, hallucinations.

Ce diagnostic est juste, mais il s'arrête à mi-chemin. Car la gouvernance qu'appelle de ses vœux la tribune — RACI, formation, politique interne — présuppose une chose rarement questionnée : que l'infrastructure sous-jacente permette de faire respecter ces règles. Un comité IA peut rédiger la politique d'usage la plus rigoureuse du marché ; si l'outil sur lequel elle s'applique est un SaaS américain dont les logs de prompts sont partiels, dont la rétention des données dépend des CGU en vigueur ce mois-ci, et dont l'algorithme de retrieval est une boîte noire, cette politique reste déclarative. Elle décrit une intention, pas un contrôle.

C'est là que se situe l'angle mort du débat actuel : on parle de gouvernance comme d'un chantier organisationnel, alors qu'elle est d'abord un chantier d'architecture. Sans maîtrise de la stack technique — index, permissions, logs, cycle de vie des données — un comité IA gouverne dans le vide.

Pourquoi la gouvernance ne se décrète pas : elle se construit dans l'architecture

Prenons un exemple concret : la muraille de Chine, principe déontologique central pour tout cabinet traitant des dossiers concurrents ou des conflits d'intérêts potentiels. Dans un monde pré-IA, elle repose sur des habilitations documentaires classiques — dossiers physiques ou GED cloisonnés, accès nominatifs. Avec un agent IA générique branché sur l'ensemble du corpus documentaire du cabinet, cette muraille devientihypothétique si les permissions ne sont pas gérées au niveau de l'index lui-même.

Concrètement, un avocat associé sur le dossier A ne doit techniquement pas pouvoir interroger l'agent sur des pièces du dossier B, même par une question détournée ou une recherche transversale. Cela suppose que :

• les permissions documentaires soient héritées et appliquées au niveau du moteur de recherche vectorielle, pas seulement de l'interface utilisateur ;
• chaque requête génère un log horodaté, associé à l'identité de l'utilisateur et au périmètre documentaire interrogé ;
• ces logs soient exportables et auditables par une personne du cabinet indépendamment du fournisseur d'IA.

Aucun de ces trois points n'est un enjeu de « politique d'usage ». Ce sont des propriétés de l'infrastructure. Une politique d'usage peut interdire à un collaborateur de contourner la muraille de Chine ; seule l'architecture peut le rendre techniquement impossible et, surtout, prouvable a posteriori.

Ce qui part, ce qui reste : le vrai partage de responsabilité

Il faut ici sortir d'un raccourci trop souvent utilisé dans les argumentaires commerciaux : opposer « le SaaS qui envoie tout à l'étranger » à « le privé qui ne sort jamais rien ». La réalité est plus nuancée, et c'est précisément cette nuance qui doit structurer une politique de gouvernance sérieuse.

Dans une architecture comme celle de RAGbase Legal, l'agent d'orchestration, l'index vectoriel, les documents complets, les permissions et les logs sont hébergés sur l'infrastructure du cabinet — on-premise ou cloud privé dédié. Seuls des extraits minimaux (chunks) — quelques centaines de mots pertinents, retrouvés par l'index pour répondre à une requête précise — sont transmis au fournisseur de modèle de langage choisi par le cabinet, via une API respectant les conditions contractuelles négociées par ce dernier. Le cabinet garde la main sur quel LLM il utilise, avec quelles garanties contractuelles, et peut en changer sans migrer ses données.

Cette distinction change tout du point de vue de la gouvernance :

• Le document complet — souvent le vecteur de risque le plus élevé en matière de secret professionnel — ne quitte jamais l'infrastructure du cabinet.
• Le cycle de vie de la donnée (création, indexation, requête, suppression) est intégralement traçable, car il se déroule sur des systèmes contrôlés par le cabinet.
• La dépendance contractuelle au fournisseur de LLM se limite au traitement d'un chunk isolé, ce qui réduit considérablement la surface d'exposition en cas de modification unilatérale des CGU d'un tiers.

À l'inverse, dans une architecture SaaS pure — qu'il s'agisse de Harvey, CoCounsel, Lexis+ Protégé ou d'un assistant généraliste type Claude Cowork déployé en mode entreprise — l'ensemble du pipeline (ingestion, indexation, retrieval, génération) est opéré par le fournisseur. Le cabinet peut négocier des clauses de traitement des données, mais il ne peut pas auditer indépendamment l'infrastructure : il dépend de la documentation, des certifications et de la bonne foi contractuelle du prestataire.

Tableau comparatif : où se situe réellement le contrôle

Ce tableau ne dit pas que le SaaS est disqualifié — il reste pertinent pour des usages non sensibles à volume élevé. Il dit que la gouvernance formalisée qu'appelle la tribune de Village Justice n'a de valeur opérationnelle que si l'architecture sous-jacente permet de la vérifier, pas seulement de la déclarer.

Le comité IA a besoin de preuves, pas de bonnes intentions

Un comité de gouvernance IA digne de ce nom — celui que recommande la tribune — doit pouvoir répondre à trois questions à tout moment, sur demande d'un client, d'un régulateur ou d'un bâtonnier :

1. Quels documents ont été utilisés pour générer telle réponse ?
2. Qui a interrogé l'agent, sur quel dossier, à quel moment ?
3. Quelle donnée a quitté l'infrastructure du cabinet, et vers qui ?

Sans logs vérifiables et sans maîtrise de l'index, ces réponses reposent sur la documentation fournie par un tiers — documentation qui peut être incomplète, ou dont la granularité ne correspond pas aux besoins d'audit du cabinet. Avec une architecture où l'agent, l'index et les logs sont sous contrôle du cabinet, le comité IA dispose de données primaires, pas de rapports d'un tiers sur ses propres données.

Cette capacité change également la formation. Un cabinet peut former ses collaborateurs sur des cas réels tirés de ses propres logs — quelles requêtes ont produit des réponses incorrectes, quels dossiers ont généré des tentatives d'accès hors périmètre — plutôt que sur des scénarios génériques fournis par l'éditeur. C'est un gisement direct pour améliorer la qualité de la recherche de jurisprudence IA interne, en identifiant les patterns de requêtes mal formulées ou les zones du corpus documentaire mal indexées.

Jurisprudence et cadre réglementaire : le risque n'est plus théorique

Le risque juridique attaché à une gouvernance défaillante n'est plus hypothétique. L'étude de Stanford sur les taux d'hallucination des outils de recherche juridique IA a mesuré, chez Harvey, un taux d'une hallucination pour six requêtes — un chiffre qui, appliqué à un cabinet traitant plusieurs centaines de recherches par semaine, représente un volume d'erreurs potentielles significatif si aucun processus de vérification n'est en place. Aux États-Unis, l'affaire Mata v. Avianca (2023) a montré les conséquences disciplinaires d'un usage non vérifié de l'IA générative devant un tribunal — un précédent que les juridictions françaises et les conseils de discipline observent avec attention.

Sur le plan réglementaire européen, deux éléments structurent directement l'architecture à privilégier :

• Le RGPD, notamment son chapitre V sur les transferts de données hors UE, rendu plus contraignant depuis l'arrêt Schrems II de la CJUE (16 juillet 2020, C-311/18), qui a invalidé le Privacy Shield et durci les exigences de garanties pour tout transfert vers les États-Unis. Une architecture qui limite ce qui transite vers un fournisseur étranger à des extraits minimaux réduit mécaniquement la surface d'exposition à ce risque.
• Le secret professionnel de l'avocat, protégé par l'article 66-5 de la loi du 31 décembre 1971, dont la portée s'étend aux traitements automatisés. Le Conseil National des Barreaux a publié des recommandations appelant les cabinets à documenter précisément le traitement de leurs données par les outils d'IA générative — une exigence qui suppose, en amont, une architecture permettant cette documentation.

Ces deux cadres convergent vers la même conclusion opérationnelle : la gouvernance documentée n'a de valeur probante que si l'architecture technique permet de démontrer, pièce à l'appui, que les garanties annoncées sont effectivement appliquées.

Ce que cela change pour le choix d'architecture

Les chiffres de marché illustrent l'ampleur du choix économique et structurel auquel font face les cabinets. Harvey revendique environ 100 000 avocats utilisateurs et 144 millions de dollars d'ARR, avec une valorisation atteignant 8 milliards de dollars fin 2025 — à un tarif de 1 000 à 1 200 dollars par utilisateur et par mois. CoCounsel (Thomson Reuters) se positionne entre 250 et 500 dollars par utilisateur et par mois, Lexis+ Protégé entre 500 et plus de 1 000 dollars. Claude Cowork, dans ses déploiements entreprise, se situe selon les estimations publiques dans une fourchette de 200 à 400 dollars par utilisateur et par mois. Une architecture privée comme RAGbase Legal repose sur un modèle différent : un investissement d'infrastructure de l'ordre de 20 000 à 50 000 dollars, sans facturation récurrente par siège, avec un coût marginal lié uniquement à l'usage des API de LLM choisies.

Ce différentiel économique n'est pas neutre pour la gouvernance : un modèle par abonnement crée une dépendance renouvelée chaque année aux conditions du fournisseur, y compris ses conditions de traitement des données. Un modèle d'infrastructure, une fois l'architecture déployée, place le cabinet en position de négociateur vis-à-vis de n'importe quel fournisseur de LLM, sans avoir à migrer son corpus documentaire ni ses habilitations.

L'exemple d'El Murshid, avec 26 000 dossiers indexés et des gains de temps de rédaction mesurés entre 5 et 70 % selon les typologies de documents, illustre ce que permet une indexation privée bien construite : un contrôle documentaire fin, associé à des gains de productivité réels, sans que l'intégralité du corpus transite par un tiers.

La tribune de Village Justice a raison de pointer l'urgence d'une gouvernance formalisée. Mais un comité IA, une politique d'usage et une matrice RACI ne valent que ce que vaut l'infrastructure sur laquelle ils s'appliquent. Avant de rédiger la prochaine politique d'usage de l'IA générative, un cabinet devrait d'abord cartographier ce qui, techniquement, peut être audité, tracé et cloisonné dans son outil actuel — et ce qui, par construction, ne le peut pas. C'est cette cartographie, plus qu'une nouvelle charte, qui détermine si la gouvernance annoncée résistera au premier contrôle sérieux. Notre guide IA pour cabinets détaille les critères à vérifier avant tout déploiement, qu'il soit SaaS ou privé.