LLM juridiques et cabinets : la pseudonymisation ne suffit pas au RGPD

Depuis le lancement de Claude for Legal, la communauté droit et technologie s’interroge sur les mêmes questions : quels éditeurs vont survivre, lesquels vont être absorbés, et à quelle vitesse l’écosystème va se recomposer. C’est un débat légitime mais ce n’est pas le plus urgent.

Le vrai sujet, pour les cabinets d’avocats, n’est pas seulement de savoir quel outil est le plus performant, mais à quelles conditions il peut être utilisé sans fragiliser la conformité, le secret professionnel et la chaîne contractuelle qui les soutient.

Ce que le débat sur la disruption des legaltechs occulte

Pendant que la conversation porte sur les parts de marché, les cabinets prennent des décisions d’adoption. Ils évaluent des outils présentés par des fondateurs qui maîtrisent le vocabulaire juridique, connaissent les contraintes métier et savent rassurer. L’argument de conformité est souvent intégré au pitch : pseudonymisation des données, secret professionnel préservé, architecture pensée pour les professionnels du droit.

Ces arguments ne sont pas nécessairement faux, ils sont surtout incomplets. Et en matière de protection des données, l’incomplet produit souvent le même effet que l’erreur.

Les architectures LLM proposées aux cabinets reposent fréquemment sur un schéma simple : une couche technique interposée entre les données clients et le modèle de langage. Ainsi les données sont pseudonymisées avant d’atteindre le LLM, le cabinet serait protégé et le secret professionnel préservé.

C’est précisément cette déduction qu’il faut discuter. La pseudonymisation a une définition juridique précise, des effets juridiques précis, et des limites que le RGPD ne laisse pas à la libre appréciation des éditeurs.

Ces questions se posent avec une acuité particulière dans les configurations cloud, aujourd’hui largement majoritaires sur le marché. Les architectures on-premise ou les instances dédiées sans entraînement sur les données clients réduisent certains de ces risques, mais elles supposent des moyens techniques et des garanties contractuelles que peu de cabinets vérifient avant signature.

Ce que la pseudonymisation ne fait pas

La pseudonymisation consiste à remplacer des identifiants directs par des substituts : un nom devient un identifiant aléatoire, un numéro de dossier devient un code. L’argument commercial qui en découle est simple : le LLM ne voit jamais les vraies données et le cabinet est protégé.

Le RGPD ne raisonne pas ainsi.

L’article 4 définit la donnée personnelle comme toute information permettant d’identifier une personne physique, directement ou indirectement. Le considérant 26 est explicite : une donnée pseudonymisée reste une donnée personnelle dès lors que la réidentification est possible, y compris par recoupement avec d’autres éléments disponibles. La pseudonymisation réduit un risque, mais elle ne fait pas sortir la donnée du champ du règlement.

Le Groupe de travail « Article 29 » l’a formulé sans ambiguïté dans son avis 05/2014 sur les techniques d’anonymisation : la pseudonymisation ne transforme pas des données personnelles en données anonymes. La CNIL maintient la même position dans ses lignes directrices. La Cour de Justice de l’Union européenne a confirmé cette logique dans l’arrêt Breyer en 2016 : une donnée indirectement identifiante, croisée avec d’autres éléments accessibles, reste une donnée personnelle.

Ce que cela signifie concrètement pour un cabinet : les obligations du RGPD ne disparaissent pas parce que le prestataire a intercalé une couche technique entre les données et le LLM. Elles se déplacent et se complexifient. Le droit d’accès, le droit à l’effacement, l’obligation de notification en cas de violation, l’analyse d’impact si le traitement présente un risque élevé : tout cela continue de s’appliquer.

Ce glissement change l’objet de l’évaluation : non plus la solidité technique de la pseudonymisation, mais la capacité de chaque maillon de l’architecture à honorer ces obligations, et le contrat qui le formalise.

Voici un exemple concret : un cabinet alimente un assistant LLM avec des pièces de dossier pour produire une première synthèse. Les noms sont remplacés par des identifiants. Cependant le prestataire de cloud conserve des logs, le fournisseur du modèle traite les prompts hors EEE, et le contrat ne précise ni la région d’hébergement ni le sort des données en cas de demande de suppression. Techniquement le flux est pseudonymisé, mais juridiquement le cabinet n’a pas encore posé les bonnes questions.

La chaîne de responsabilité que personne ne cartographie

Une architecture LLM juridique type met en jeu au minimum trois acteurs : le fournisseur du modèle, l’éditeur du SaaS qui orchestre les flux, et le cabinet qui utilise l’ensemble. À cela s’ajoutent souvent des sous-traitants de second rang : hébergeurs, fournisseurs de connecteurs, prestataires de signature électronique.

Le RGPD impose de qualifier chaque acteur. Responsable de traitement, sous-traitant, responsables conjoints : cette qualification n’est pas optionnelle et elle n’est pas laissée à l’appréciation commerciale des parties. Elle découle de la réalité des flux et des pouvoirs de décision sur les données.

Dans la plupart des configurations actuelles, le cabinet reste responsable de traitement. C’est lui qui détermine les finalités : gérer des dossiers clients, produire des actes, archiver des échanges. Le fait de déléguer l’exécution technique à un SaaS ne transfère pas cette qualité. Elle emporte des obligations que le cabinet ne peut pas sous-traiter : information des personnes concernées, gestion des droits d’accès et d’effacement, tenue du registre des activités de traitement, notification à la CNIL en cas de violation.

Le contrat avec le SaaS doit donc prévoir, au sens de l’article 28 du RGPD, un accord de traitement de données précis : objet et durée du traitement, nature et finalité, types de données, obligations et droits du responsable. Trop peu de contrats adressent ce point de manière satisfaisante. Un DPA générique, non adapté au contexte d’un cabinet, vaut peu mieux qu’une absence de cadrage.

La question du sous-traitant de second rang est rarement abordée dans les argumentaires commerciaux. Si le SaaS s’appuie sur un fournisseur de cloud américain par exemple, les données peuvent relever du Cloud Act indépendamment de toute pseudonymisation. Si le fournisseur du LLM conserve des logs de requêtes pour améliorer son modèle, même sous forme agrégée, la question du transfert et de la finalité se pose. Ces éléments figurent rarement dans les plaquettes de présentation et ils devraient figurer dans les contrats.

Le fait qu’un outil soit conçu par d’anciens juristes ne modifie pas cet état du droit. La maîtrise du domaine métier et la conformité RGPD sont deux référentiels distincts. L’un ne garantit pas l’autre, et la confusion entre les deux est précisément ce qui crée un angle mort dans l’évaluation de ces solutions.

En cas d’incident, la question de la responsabilité devient immédiatement opérationnelle.
L’article 33 du RGPD impose une notification à la CNIL dans les 72 heures suivant la découverte d’une violation de données. L’article 34 impose dans certains cas d’en informer les personnes concernées. Dans une architecture à trois couches, où le cabinet, l’éditeur du SaaS et le fournisseur du modèle opèrent chacun de leur côté, la question de qui détecte l’incident, qui le qualifie, et qui notifie dans les délais n’est pas résolue par la technique. Elle doit l’être par le contrat. Si le DPA ne prévoit pas de procédure d’escalade claire entre les acteurs, le délai de 72 heures court pendant que chacun attend que l’autre prenne la main.​​​​​​​​​​​​​​​​

Trois questions à poser avant de signer

Ces questions ne supposent aucune compétence technique. Elles supposent de lire ce qu’on vous remet avant de l’accepter.

1. Qui est qualifié responsable de traitement dans le DPA, et sur quelle base ?

Demandez le Data Processing Agreement avant la signature du contrat principal et lisez la clause de qualification. Si l’éditeur du SaaS se qualifie lui-même de responsable de traitement conjoint sans justification, ou si la clause est absente, c’est un signal. Si le document est un modèle générique non adapté à une activité juridique, c’est un autre signal. Un DPA sérieux identifie précisément les catégories de données traitées, les finalités, la durée de conservation, et les sous-traitants de second rang avec leurs localisations.

2. Où transitent vos données, et sous quelle juridiction ?

La pseudonymisation ne neutralise pas un transfert hors Union européenne. Si le fournisseur du LLM est américain, si l’hébergement est assuré par AWS, Azure ou Google Cloud sans précision de région, vos données peuvent relever d’un cadre juridique qui peut autoriser des accès gouvernementaux aux données stockées, indépendamment du droit européen. Demandez la liste des sous-traitants et leur localisation. C’est une obligation du DPA au sens de l’article 28 du RGPD. Si cette liste n’existe pas ou n’est pas communicable, la conformité RGPD revendiquée n’est pas vérifiable.

3. Comment exercez-vous les droits des personnes concernées dans cette architecture ?

Vos clients sont des personnes concernées au sens du RGPD. Ils peuvent demander l’accès à leurs données, leur rectification, leur effacement. En tant que responsable de traitement probable, c’est vous qui devez honorer ces demandes dans les délais légaux. Posez la question concrète : si un client demande la suppression de toutes ses données, quel est le processus exact dans votre système, y compris chez vos sous-traitants ? Si votre interlocuteur commercial ne sait pas répondre, ce n’est pas un problème technique. C’est un problème de conformité qui est déjà le vôtre.

Conclusion

Adopter un LLM juridique n’est pas une décision technique, c’est une décision de conformité. Elle engage le cabinet en tant que responsable de traitement, elle crée des obligations contractuelles envers des sous-traitants qu’on n’a pas toujours identifiés, et elle s’inscrit dans un cadre réglementaire qui ne s’adapte pas au rythme des lancements produits.

Les outils vont continuer à évoluer. Les obligations du RGPD, par contre, sont stables. Trois questions posées avant signature valent mieux qu’un audit de conformité commandé après incident.

L’analyse, le cadrage juridique et les choix éditoriaux de cet article relèvent d’un travail humain. La rédaction a bénéficié d’une assistance par IA, intégralement relue, corrigée et validée par l’auteure.

Rédigé par Anne-Sophie, Juriste en droit des affaires et droit du numérique | 15 ans d’expérience
Diplômée en droit international des affaires et certifiée CIPP/E, Anne-Sophie a construit son expertise en entreprise, au contact des enjeux contractuels et réglementaires liés à l’innovation technologique et au numérique.
Elle accompagne depuis 3 ans les entrepreneurs et startups dans la sécurisation de leurs usages de l’IA : rédaction et négociation de contrats, mise en conformité RGPD et AI Act et gouvernance opérationnelle avec une approche concrète, adaptée aux réalités du terrain