Deuxième volet de notre série sur la sécurité et la confidentialité des outils d'IA juridique. Le premier article traitait du risque d'entraînement des modèles sur les données des utilisateurs. Celui-ci porte sur la rétention des données, et plus précisément sur la différence entre qui contrôle ce qui est conservé. Le troisième article traitera du chiffrement des données qui sont bel et bien conservées.
Partie I : le problème
La question qui compte : qui décide que les données sont conservées ?
Quand on parle de rétention des données dans les outils d'IA, la conversation porte souvent sur la durée de conservation des conversations. Ce n'est pas le bon critère.
La bonne question n'est pas « combien de temps », mais « qui décide qu'elles sont conservées ».
Il existe deux modèles de rétention fondamentalement différents :
Rétention contrôlée par le fournisseur. Le fournisseur conserve les conversations dans ses systèmes pour afficher l'historique à l'utilisateur, générer des logs système, analyser l'usage ou poursuivre d'autres finalités qui lui sont propres. L'utilisateur peut ou non pouvoir supprimer l'historique visible, mais les données que le fournisseur retient dans ses systèmes backend existent indépendamment de ce que l'utilisateur fait dans l'interface. Tant que ces données existent dans les systèmes du fournisseur, elles relèvent du droit du fournisseur, et sont exposées aux ordonnances judiciaires, aux demandes des autorités et aux incidents de sécurité hors du contrôle de l'utilisateur.
Rétention contrôlée par l'utilisateur. L'utilisateur décide activement ce qu'il conserve et ce qu'il supprime. Le fournisseur ne tient pas de logs du contenu des conversations dans ses propres systèmes. Ce qui existe dans le système est ce que l'utilisateur a choisi de faire exister, et lorsqu'il le supprime, c'est vraiment supprimé.
La différence entre les deux modèles peut sembler peu technique en apparence, mais elle a des conséquences juridiques et de sécurité radicalement différentes.
L'affaire qui illustre le risque de la rétention par le fournisseur
Le 17 février 2026, le juge Jed Rakoff du district sud de New York a publié son opinion dans United States v. Heppner, le premier arrêt fédéral sur la confidentialité et les conversations avec une IA.
Bradley Heppner avait utilisé un outil d'IA public pour préparer l'analyse de sa stratégie de défense dans une affaire de fraude. Il n'avait pas décidé activement de conserver ces conversations comme un enregistrement permanent. Il avait simplement utilisé l'outil.
L'outil, comme la plupart des outils d'IA du marché, avait conservé par défaut l'historique des conversations sur ses serveurs. Lorsque le FBI a saisi les appareils de Heppner et enquêté sur son activité numérique, ces conversations existaient dans les systèmes du fournisseur, soumises à la même juridiction que toute autre donnée détenue par un tiers.
Le juge a ordonné qu'elles soient remises au parquet. Parmi les motifs de la décision, l'un était directement lié à la rétention : la politique de confidentialité de l'outil autorisait le partage de données avec les autorités gouvernementales. L'existence de données retenues par le fournisseur a été le vecteur qui a rendu la divulgation possible.
Si l'outil n'avait pas retenu ces conversations dans ses systèmes, si le contenu n'avait pas existé sur les serveurs du fournisseur, il n'y aurait eu aucune donnée à ordonner de divulguer.
Ce que « logs » signifie en pratique
Le concept de « logs système » est technique, mais ses implications sont directes. Les systèmes logiciels conservent des enregistrements des opérations qu'ils exécutent. Ces enregistrements peuvent aller de métadonnées pures (horodatages, usage des ressources, erreurs) jusqu'au contenu intégral des conversations.
Sur la plupart des plateformes d'IA, les logs système enregistrent au moins des fragments du contenu des conversations, pour le débogage, la modération de contenu ou l'audit de sécurité. Ces logs ont leurs propres durées de rétention, souvent plus longues que l'historique visible de l'utilisateur, et sont régis par des politiques d'ingénierie internes que l'utilisateur ne contrôle pas et, dans la plupart des cas, ne connaît même pas.
La distinction pertinente pour la confidentialité juridique est celle-ci : les logs qui enregistrent le contenu des conversations sont des données en possession du fournisseur. Ce sont des données que le fournisseur peut être contraint de produire. Ce sont des données qui peuvent être exposées lors d'une faille de sécurité. Et ce sont des données qui existent indépendamment de ce que l'utilisateur fait dans l'interface.
Le second problème : supprimer l'historique visible ne supprime pas les données backend
Une incompréhension fréquente chez les utilisateurs d'outils d'IA consiste à croire que supprimer l'historique visible dans l'interface équivaut à supprimer les données du système.
Sur la plupart des plateformes, ce n'est pas le cas.
L'historique affiché dans l'interface est la couche de présentation, ce que le système a choisi de montrer à l'utilisateur. Les données backend sont la couche de stockage : les enregistrements réels dans les bases de données, les logs, les systèmes de sauvegarde et les caches. Supprimer l'historique visible désassocie souvent la conversation de l'interface utilisateur sans la retirer des systèmes de stockage sous-jacents.
Cela a une implication directe : un utilisateur qui a « supprimé » ses conversations de l'interface d'un outil d'IA peut n'avoir rien supprimé de ce qui existe sur les serveurs du fournisseur. Et si ces serveurs font l'objet d'une ordonnance judiciaire ou d'un incident de sécurité, les données peuvent encore être disponibles alors que l'utilisateur pensait les avoir effacées.
Pourquoi la rétention par le fournisseur est particulièrement problématique pour les données juridiques
Chaque type de données a un profil de risque spécifique. Les données juridiques ont des caractéristiques qui rendent une rétention non contrôlée par l'utilisateur particulièrement problématique :
Elles sont stratégiquement sensibles pour les parties adverses. Les conversations de stratégie juridique, les analyses de position contractuelle et les évaluations de risque ont une valeur économique concrète pour la contrepartie dans un litige ou une négociation. La motivation d'un attaquant à accéder à ces données est proportionnelle à cette valeur.
Elles peuvent faire l'objet de procédures de discovery dirigées contre le fournisseur. Comme l'a montré Heppner, les ordonnances de discovery peuvent viser le fournisseur directement, et non l'avocat. Si le fournisseur retient des données, ces données sont potentiellement accessibles par cette voie, même si l'avocat n'avait jamais imaginé que c'était possible.
Leur confidentialité a des conséquences professionnelles spécifiques. La règle 1.6 du Model Rules of Professional Conduct de l'ABA impose à l'avocat le devoir de faire des « efforts raisonnables pour prévenir la divulgation involontaire » d'informations de clients. Utiliser un outil qui retient des données de conversation dans les systèmes du fournisseur sans contrôle de l'utilisateur satisfait difficilement cette norme.
Partie II : la solution
Le modèle mis en œuvre par LexBuddy : sans logs, avec contrôle de l'utilisateur
LexBuddy n'applique pas un modèle de rétention zéro au sens où les conversations disparaîtraient immédiatement. Les conversations dans LexBuddy peuvent être enregistrées, car un avocat qui travaille sur un dossier pendant des semaines doit pouvoir reprendre le fil.
Ce que LexBuddy met en œuvre est un modèle différent, avec deux éléments qui, ensemble, changent l'architecture du risque :
Élément 1 : aucun log du contenu des conversations
LexBuddy ne tient pas de logs système qui enregistrent le contenu de ce que les utilisateurs écrivent. Les logs techniques de la plateforme enregistrent des métadonnées opérationnelles (horodatages, états système, erreurs techniques), mais pas le texte des conversations.
Cela a une implication concrète : LexBuddy ne détient pas dans ses systèmes une copie du contenu des conversations qui existerait indépendamment de la volonté de l'utilisateur. Si LexBuddy recevait une ordonnance judiciaire portant sur le contenu des conversations d'un utilisateur, il n'y aurait aucun log à produire, car ces logs n'existent pas.
C'est fondamentalement différent de la situation dans Heppner, où l'outil détenait dans ses systèmes des données de l'utilisateur susceptibles de faire l'objet d'une ordonnance de divulgation.
Élément 2 : l'utilisateur décide ce qui est enregistré et quand cela est supprimé
Les conversations dans LexBuddy peuvent être enregistrées dans l'espace de travail de l'utilisateur, car cela est utile pour le travail juridique. La différence tient à qui contrôle cette décision.
Dans LexBuddy, l'utilisateur décide quelles conversations conserver et lesquelles supprimer. Lorsqu'un utilisateur supprime une conversation, cette conversation est supprimée des systèmes de LexBuddy. Il n'existe pas de copies backend qui persistent après une suppression par l'utilisateur. Il n'existe pas de cache de conversations qui survive à la décision de supprimer.
Ce qui existe dans les systèmes de LexBuddy est ce que l'utilisateur a choisi de faire exister. Rien de plus.
La différence avec le modèle de Heppner
Dans l'affaire Heppner, le problème n'était pas que l'accusé ait choisi d'enregistrer ses conversations. Le problème était que le fournisseur les avait enregistrées par défaut, indépendamment de l'intention de l'utilisateur, et que ces conversations étaient restées dans les systèmes du fournisseur, soumises aux lois qui régissent les données détenues par des tiers.
Chez LexBuddy, la logique est inversée : ce qui existe dans les systèmes de LexBuddy existe parce que l'utilisateur l'a choisi. Et lorsqu'il le supprime, c'est vraiment supprimé.
Cela ne crée pas automatiquement le privilege attorney-client. Ce privilege dépend d'autres facteurs juridiques hors de portée de tout outil technologique. Mais cela élimine le vecteur spécifique qui a rendu la divulgation possible dans Heppner : l'existence de données dans les systèmes du fournisseur susceptibles de faire l'objet d'une ordonnance de divulgation sans que l'utilisateur le sache ni puisse l'éviter.
Ce dont les conversations enregistrées ont besoin : le rôle du chiffrement
La rétention contrôlée par l'utilisateur répond à la question de savoir qui décide de ce qui existe. Mais elle soulève une seconde question : lorsque l'utilisateur décide bel et bien d'enregistrer une conversation, comment est-elle protégée ?
Cette question trouve sa réponse dans l'architecture de chiffrement de LexBuddy, qui est le sujet du troisième article de cette série. Les conversations que l'utilisateur choisit de conserver dans son espace de travail sont chiffrées avec la clé de chiffrement de l'organisation, de sorte que même l'équipe LexBuddy ne peut accéder à leur contenu. La rétention sous contrôle de l'utilisateur et le chiffrement au niveau de l'organisation sont deux couches de protection complémentaires : la première définit qui décide de ce qui existe, la seconde protège ce qui existe.
Deux questions en séquence : d'abord, l'outil a-t-il des logs système qui enregistrent le contenu de mes conversations ? Ensuite, si je supprime une conversation depuis l'interface, disparaît-elle de tous les systèmes backend ? Si la réponse à la première est « oui » ou « je ne sais pas », ou si la réponse à la seconde est « non » ou « nous ne sommes pas sûrs », le fournisseur retient des données sur lesquelles l'utilisateur n'a pas de contrôle réel.
Prochain volet : chiffrement au niveau de l'organisation et MFA, comment est protégé ce que l'utilisateur décide de conserver.
Cet article est fourni à titre informatif et ne constitue pas un conseil juridique. Pour toute application spécifique à votre pratique, consultez un spécialiste de la déontologie professionnelle dans votre juridiction.
Sources
| Source | Lien |
|---|---|
| Harvard Law Review Blog : United States v. Heppner | harvardlawreview.org |
| Gibson Dunn : AI privilege waivers, SDNY rules against privilege for consumer AI outputs | gibsondunn.com |
| Akin Gump : SDNY rules that a public AI platform is not protected by privilege | akingump.com |
| Perkins Coie : Heppner and Gilbarco, courts apply privilege and work product to AI | perkinscoie.com |
| ABA : 2024 Legal Technology Survey Report | americanbar.org |
| ABA Formal Opinion 512 (PDF, 29 juillet 2024) | americanbar.org |
| RGPD : article 5, principes relatifs au traitement des données à caractère personnel | gdpr-info.eu |
| RGPD : article 17, droit à l'effacement | gdpr-info.eu |