Secret professionnel et IA : où vont vraiment les pièces du dossier ?

Un associé copie-colle trois pages d'un protocole de médiation confidentiel dans une fenêtre de chat pour en obtenir un résumé en trente secondes. Le gain de temps est réel. Mais une question technique, rarement posée avant de cliquer sur « envoyer », devrait l'être systématiquement : où partent physiquement ces trois pages, sur quels serveurs sont-elles traitées, combien de temps y restent-elles, et qui d'autre que le cabinet peut légalement y accéder ? C'est exactement l'angle qu'adopte Adrien Palomba, ingénieur en informatique, dans sa tribune publiée sur Village Justice. Son constat est limpide : le débat sur l'IA générative en cabinet d'avocats s'est trop longtemps focalisé sur la performance des modèles, alors que le nœud du problème est ailleurs — dans le trajet physique et juridique des pièces du dossier.

Cette tribune mérite d'être prolongée techniquement, car elle touche directement les DSI et responsables innovation qui doivent arbitrer entre rapidité de déploiement, coût et conformité. Entre un LLM SaaS classique et une architecture RAG installée au cabinet, la différence n'est pas une nuance contractuelle. C'est une différence d'architecture vérifiable.

Ce que pose vraiment la tribune d'Adrien Palomba

L'auteur, qui n'est pas avocat mais ingénieur, aborde le sujet sous l'angle qu'il maîtrise : l'infrastructure. Son argument central est que la conformité au secret professionnel ne se négocie pas dans les conditions générales d'un éditeur, elle se vérifie dans la topologie du système. Autrement dit : peu importe la qualité des clauses de confidentialité d'un fournisseur SaaS si, techniquement, les pièces du dossier transitent et séjournent sur des serveurs hors du contrôle direct du cabinet.

Ce recentrage est stratégique pour les décideurs. Il déplace la question de « quel modèle choisir » vers « quelle architecture d'hébergement et de traitement adopter ». Et cette seconde question a des réponses techniques précises, pas seulement juridiques.

Anatomie d'un prompt envoyé à un LLM SaaS

Quand un collaborateur utilise un assistant IA généraliste ou un SaaS juridique facturé par siège, le cycle de vie d'une requête suit généralement ce chemin :

1. Le texte saisi (souvent accompagné d'un document joint) quitte le poste de travail du cabinet.
2. Il transite vers l'infrastructure cloud de l'éditeur — fréquemment hébergée aux États-Unis ou chez un sous-traitant dont l'entité mère y est domiciliée.
3. Il peut être temporairement journalisé, mis en cache, ou utilisé pour l'amélioration du service selon les conditions contractuelles en vigueur à la date de l'usage.
4. La réponse redescend vers le cabinet, mais la trace de la pièce originale a déjà circulé hors de son périmètre.

Le risque identifié par la tribune, et bien documenté par ailleurs, est celui du Cloud Act (Clarifying Lawful Overseas Use of Data Act, 2018) : toute entreprise américaine, y compris via ses filiales européennes, peut être contrainte de communiquer des données qu'elle héberge, sans que le client final — ici le cabinet d'avocats — en soit nécessairement informé. Ce n'est pas une hypothèse d'école. Le Conseil d'État l'a reconnu explicitement dans l'affaire Health Data Hub (ordonnance de référé du 19 juin 2020), où il a validé le recours à Microsoft Azure tout en pointant le risque théorique d'accès extraterritorial lié au statut de société américaine de l'hébergeur — déclenchant depuis une politique active de « cloud de confiance » côté administrations françaises. Transposé au secteur juridique, le raisonnement est identique : un éditeur SaaS, aussi vertueux soit-il contractuellement, reste soumis à son droit national.

L'article 226-13 du Code pénal, du principe déontologique à l'exigence technique

Le secret professionnel de l'avocat n'est pas une politesse de profession, c'est une infraction pénale en cas de violation. L'article 226-13 du Code pénal punit d'un an d'emprisonnement et de 15 000 euros d'amende la révélation d'une information à caractère secret par une personne qui en est dépositaire par état, profession ou fonction. La Cour de cassation retient de façon constante un secret général et absolu, qui ne souffre pas d'exception liée au support technique utilisé pour traiter l'information.

Le Règlement Intérieur National de la profession d'avocat (RIN) prolonge cette exigence : l'avocat doit garantir la confidentialité des correspondances et des pièces du dossier, y compris lorsqu'il recourt à des outils numériques tiers. Autrement dit, le choix d'un prestataire technique n'exonère jamais l'avocat de sa responsabilité déontologique — il la déplace simplement vers un exercice de diligence technique : avant d'adopter un outil, il faut pouvoir démontrer où vont les données, pas seulement le lire dans une FAQ.

C'est précisément ce que la tribune d'Adrien Palomba transforme en question opérationnelle pour les DSI : le secret professionnel cesse d'être un argument marketing d'éditeur pour devenir un critère de spécification technique, au même titre que la disponibilité ou le temps de réponse d'un système.

Ce que change une architecture RAG on-premise, techniquement

Une architecture RAG (Retrieval-Augmented Generation) installée au sein du cabinet, comme celle de IA privée pour cabinet d'avocats, repose sur une séparation nette entre ce qui reste local et ce qui peut, le cas échéant, être envoyé à un modèle de langage externe.

Restent sur l'infrastructure du cabinet :

• Les documents complets du dossier (conclusions, pièces, correspondances, contrats).
• L'index vectoriel qui permet de retrouver les passages pertinents sans relire l'intégralité du corpus à chaque requête.
• Le moteur d'orchestration (l'agent) qui décide quelles pièces interroger, dans quel ordre, et comment assembler la réponse.
• Les permissions par dossier, par équipe, par niveau de confidentialité — essentielles dans un cabinet où une muraille de Chine sépare certains départements.
• Les journaux d'accès (logs), qui permettent de reconstituer a posteriori qui a consulté quoi, quand, et pour quel dossier — un élément de preuve en cas de contrôle ou de contentieux disciplinaire.

Ce qui peut quitter l'infrastructure, et uniquement cela : des extraits minimisés (chunks), c'est-à-dire quelques paragraphes identifiés comme pertinents par l'agent pour répondre à une question précise, envoyés au fournisseur de LLM choisi par le cabinet selon ses propres conditions contractuelles et API.

Cette nuance est volontairement honnête : RAGbase Legal n'élimine pas l'usage de modèles de langage tiers, et il serait trompeur de prétendre qu'« aucune donnée ne sort jamais ». La différence structurelle est ailleurs — dans l'écart entre transmettre un dossier entier à un service tiers qui en conserve potentiellement une copie, et transmettre un fragment contextuel et révocable à un modèle qui ne reçoit jamais le dossier dans son intégralité ni l'historique complet du client.

Tableau comparatif : trois architectures, trois trajets de données

Un marché qui n'ignore pas la question, mais la traite différemment

Les acteurs du marché n'ont pas le même positionnement sur cette question, et il serait réducteur de les mettre dans le même panier. Harvey, qui revendique environ 100 000 avocats utilisateurs et un ARR de 144 millions de dollars pour une valorisation de 8 milliards de dollars fin 2025, opère un modèle SaaS mutualisé facturé entre 1 000 et 1 200 USD par utilisateur et par mois — un prix qui reflète en partie l'infrastructure cloud dédiée et les investissements en fine-tuning sectoriel. Une étude de Stanford a par ailleurs mesuré un taux d'hallucination d'environ 1 sur 6 sur certains cas d'usage juridiques testés, rappelant que la fiabilité du modèle reste un enjeu distinct de celui de la localisation des données.

CoCounsel (Thomson Reuters), positionné entre 250 et 500 USD par utilisateur et par mois, et Lexis+ Protégé, entre 500 et 1 000+ USD, s'appuient sur l'infrastructure cloud de leurs groupes respectifs, avec des engagements contractuels de confidentialité propres à chaque éditeur. Claude Cowork (Anthropic), dans sa version entreprise, se situe dans un ordre de grandeur comparable aux offres SaaS juridiques premium — sans qu'un chiffrage précis et public permette de le fixer avec certitude à ce stade.

Dans tous ces cas, le modèle économique repose sur la mutualisation de l'infrastructure entre clients, ce qui peut être parfaitement conforme contractuellement, mais déplace la vérification de la confidentialité vers la lecture fine des conditions de traitement des données — plutôt que vers une architecture techniquement observable par le cabinet lui-même.

À l'inverse, une solution comme El Murshid, qui indexe 26 000 dossiers et revendique un gain de temps de rédaction de 5 à 70 % selon les tâches, illustre qu'un déploiement spécialisé et documenté sur un corpus propre peut produire des gains mesurables sans nécessiter une architecture SaaS mutualisée.

Ce qu'un DSI devrait vérifier avant tout déploiement

La tribune d'Adrien Palomba a le mérite de proposer une grille de lecture technique plutôt que purement déontologique. On peut la décliner en questions opérationnelles concrètes, à poser à tout éditeur avant signature :

• Où sont physiquement hébergés les documents indexés — datacenter européen, souverain, ou infrastructure du cabinet lui-même ?
• L'éditeur peut-il démontrer, pas seulement affirmer, que les documents complets ne transitent jamais vers un tiers externe ?
• Quelles données exactement sont envoyées au LLM final : le document entier, un résumé, ou un chunk de quelques lignes ?
• Les logs d'accès sont-ils consultables par le cabinet, ou uniquement par l'éditeur ?
• Les permissions par dossier et par équipe (muraille de Chine) sont-elles configurables nativement, ou dépendent-elles d'un paramétrage tiers ?
• Que prévoit le contrat en cas de réquisition judiciaire étrangère visant l'hébergeur ?

Ces questions, posées systématiquement, transforment le secret professionnel d'argument de vente en critère d'audit technique — exactement le glissement que propose la tribune source. Elles sont aussi la base d'une évaluation sérieuse dans tout guide IA pour cabinets destiné aux comités de direction.

Recherche de jurisprudence : un cas d'usage qui illustre bien l'enjeu

La recherche de jurisprudence IA est un bon terrain d'observation de cette différence architecturale. Rechercher un arrêt ou un principe jurisprudentiel ne pose en général pas de problème de confidentialité — ce sont des données publiques. Le risque apparaît dès que la recherche est contextualisée avec les pièces du dossier client pour affiner la pertinence : c'est à ce moment précis que le trajet des données change de nature, passant d'une requête générique à une requête nourrie d'informations confidentielles. Une architecture on-premise permet de faire cette contextualisation localement, en ne transmettant au modèle que les éléments strictement nécessaires à la formulation de la requête de recherche, sans jamais exposer le dossier complet.

Ce qu'il faut en retenir pour l'arbitrage interne

Le débat posé par Adrien Palomba ne doit pas se lire comme un procès du SaaS juridique dans son ensemble — plusieurs éditeurs opèrent avec des garanties contractuelles sérieuses et des clients satisfaits. Il doit se lire comme un rappel : la conformité au secret professionnel se prouve par l'architecture, pas par la réputation de l'éditeur. Un cabinet peut très bien combiner les deux approches selon la sensibilité des dossiers — SaaS mutualisé pour des tâches de recherche générale à faible enjeu de confidentialité, architecture on-premise pour les dossiers contentieux sensibles, le M&A stratégique ou les données couvertes par un secret renforcé (santé, défense, affaires pénales).

La question n'est donc pas binaire. Elle appelle une cartographie des usages par niveau de sensibilité, et un choix d'architecture adossé à cette cartographie plutôt qu'à une préférence générale pour le cloud ou le local.

Avant de généraliser un outil d'IA générative à l'ensemble des dossiers du cabinet, il vaut mieux cartographier précisément quels types de pièces transitent aujourd'hui vers des services tiers, et confronter cette cartographie aux exigences réelles de l'article 226-13 et du RIN. C'est cet exercice, plus que la comparaison des performances de modèles, qui détermine si l'architecture choisie tiendra face à un contrôle déontologique ou à un audit de sécurité.