Sanction CNIL 300 000 € : le droit à l'effacement face à l'IA/RAG

Un client résilie son mandat, exige la destruction de son dossier, puis change d'avis six mois plus tard et attaque le cabinet pour violation du secret professionnel — parce que son ex-associé retrouve, dans une réponse générée par l'assistant IA du cabinet adverse, un fragment de correspondance qui aurait dû être effacé. Ce scénario n'est pas de la science-fiction : c'est exactement le type de faille que la CNIL vient de sanctionner, à un niveau générique, chez un acteur numérique classique. Le sujet dépasse largement EXTIA. Il touche directement les cabinets d'avocats qui ont déployé un assistant IA générative ou un système RAG (Retrieval-Augmented Generation) sur leurs dossiers clients.

L'affaire EXTIA : une sanction qui parle d'effacement, pas de fuite

Le 21 juillet 2026, la CNIL a prononcé une sanction de 300 000 euros à l'encontre de la société EXTIA pour non-respect du droit à l'effacement et, plus largement, des droits des personnes concernées (communiqué CNIL). Ce dossier se distingue des sanctions habituelles liées aux violations de données (fuites, piratages, défauts de sécurité) : il ne s'agit pas d'un incident ponctuel mais d'une défaillance structurelle dans la capacité de l'entreprise à traduire une demande d'effacement en suppression technique réelle, complète et vérifiable.

C'est précisément ce point qui rend l'affaire pertinente pour le secteur juridique. La CNIL ne sanctionne pas le fait d'avoir collecté des données — elle sanctionne l'incapacité à les faire disparaître effectivement lorsque la loi l'exige. Or cette difficulté, déjà réelle pour des bases de données relationnelles classiques, devient nettement plus aiguë dès qu'on introduit un système d'IA générative indexant des documents : bases vectorielles, caches de modèles, logs de conversation, éventuels pipelines de fine-tuning. Le droit ne change pas ; la technique, elle, se complexifie.

Le droit à l'effacement, une obligation simple sur le papier

L'article 17 du RGPD est limpide dans son principe : toute personne peut demander l'effacement de ses données personnelles, sous réserve d'exceptions précises (obligation légale de conservation, exercice ou défense de droits en justice, intérêt public). Pour un cabinet d'avocats, cette obligation se double d'un enjeu déontologique spécifique : les documents concernés sont souvent couverts par le secret professionnel (article 66-5 de la loi du 31 décembre 1971), et leur mauvaise gestion expose non seulement à une sanction CNIL mais à une procédure disciplinaire devant l'Ordre, voire à une mise en cause pénale au titre de la violation du secret (article 226-13 du Code pénal).

Dans un environnement documentaire classique — dossiers papier, GED, messagerie — effacer un document est une opération relativement traçable : on identifie le fichier, on le supprime, on purge la sauvegarde, on documente l'opération. Dans un système d'IA générative de type RAG, cette même opération se décompose en plusieurs couches techniques distinctes, dont certaines échappent souvent au contrôle direct du cabinet.

Pourquoi un système RAG rend l'effacement structurellement plus difficile

Un système RAG ne stocke pas un document comme un fichier unique et localisé. Il le transforme en plusieurs objets techniques distincts :

• Le document source, conservé dans une GED ou un espace de stockage.
• Des chunks, fragments du document découpés pour l'indexation.
• Des embeddings, représentations vectorielles de ces chunks stockées dans une base vectorielle séparée.
• Des logs d'agent, traces des requêtes et réponses générées, parfois conservées pour l'audit ou l'amélioration du modèle.
• Dans certaines architectures SaaS, des caches d'inférence ou des données de fine-tuning, potentiellement répliquées sur plusieurs data centers.

Supprimer le document source ne supprime pas automatiquement les embeddings correspondants dans l'index vectoriel : ce sont deux systèmes distincts, souvent gérés par des composants logiciels différents (une GED d'un côté, une base vectorielle type FAISS, Pinecone ou Weaviate de l'autre). Sans procédure explicite de purge, l'index continue d'être interrogeable et peut restituer des fragments du document supposément effacé lors d'une requête ultérieure — un « vecteur orphelin » qui n'a plus de lien direct avec le document original mais reste sémantiquement exploitable.

C'est exactement le type de défaillance que sanctionne la CNIL dans l'affaire EXTIA : une architecture technique où la suppression déclarée ne correspond pas à une suppression réelle sur l'ensemble des systèmes concernés.

Le cas particulier des outils SaaS mutualisés

Pour un cabinet utilisant un assistant IA en mode SaaS, la difficulté est double. D'abord, il ne maîtrise pas l'architecture interne du fournisseur : impossible de vérifier soi-même si la purge a été effectuée jusque dans l'index vectoriel et les caches. Ensuite, certains contrats prévoient une conservation des logs de conversation à des fins d'amélioration du service ou de sécurité, avec des durées de rétention qui ne coïncident pas nécessairement avec le calendrier d'une demande d'effacement client.

Ce n'est pas propre à un fournisseur en particulier — Harvey (valorisé 8 milliards de dollars fin 2025, environ 100 000 avocats utilisateurs, 144 millions de dollars d'ARR), CoCounsel de Thomson Reuters, Lexis+ Protégé ou des assistants généralistes déployés en environnement professionnel comme Claude Cowork reposent tous, à des degrés divers, sur une infrastructure cloud mutualisée où le cabinet client n'a pas un accès direct et vérifiable à la couche d'indexation. La question n'est pas de savoir si ces fournisseurs sont négligents — leurs conditions contractuelles prévoient généralement des engagements de suppression — mais de savoir si le cabinet peut, en pratique, produire une preuve d'exécution opposable à la CNIL ou à l'Ordre en cas de contrôle.

Ce que « purger » veut vraiment dire, techniquement

Une suppression conforme à l'article 17 dans un système d'IA générative suppose, au minimum, les étapes suivantes :

1. Identification du document et de tous les objets dérivés (chunks, embeddings, entrées de cache).
2. Suppression du document source dans la GED ou l'espace de stockage.
3. Purge des embeddings correspondants dans la base vectorielle — opération qui nécessite souvent une ré-indexation partielle ou complète selon la granularité de l'index.
4. Purge des logs de conversation contenant des extraits du document, avec gestion des conflits entre effacement et obligations de traçabilité professionnelle (secret professionnel, obligations de l'avocat en matière de preuve de conseil).
5. Vérification de l'absence de copie chez un tiers (sous-traitant cloud, fournisseur de LLM, prestataire de fine-tuning).
6. Production d'un certificat de suppression daté et traçable, opposable en cas de contrôle.

Cette liste n'a rien de théorique : c'est précisément ce niveau de granularité que la CNIL semble attendre des responsables de traitement, et c'est l'absence de maîtrise de cette chaîne complète qui a été sanctionnée dans l'affaire EXTIA.

Comparaison des architectures : qui contrôle réellement la purge ?

Ce tableau ne dit pas que les outils SaaS sont non conformes — leurs fournisseurs disposent en général de procédures de suppression contractuelles sérieuses. Il dit que le niveau de preuve et de contrôle direct diffère structurellement selon que l'infrastructure d'indexation appartient au fournisseur ou au cabinet lui-même.

L'approche RAGbase Legal : agent, index et logs sur l'infrastructure du cabinet

La réponse de RAGbase Legal à ce problème n'est pas de refuser tout usage de LLM externes — un cabinet peut tout à fait s'appuyer sur le modèle de langage de son choix pour la génération finale. La différence tient à l'architecture : l'agent d'orchestration, l'index vectoriel, les connecteurs aux sources documentaires, les permissions et les logs d'usage restent hébergés sur l'infrastructure privée du cabinet. Seuls des extraits minimaux — les chunks strictement nécessaires à la réponse — quittent cette infrastructure pour être transmis au fournisseur de LLM choisi, selon les conditions API négociées par le cabinet lui-même.

Concrètement, cela change trois choses au moment d'une demande d'effacement :

• Le cabinet identifie et supprime lui-même le document source et ses embeddings dans son propre index vectoriel, sans dépendre d'un ticket de support auprès d'un fournisseur tiers.
• La ré-indexation post-suppression est un processus interne, documenté et auditable, pas une boîte noire externalisée.
• Les logs de conversation liés au document effacé résident sur l'infrastructure du cabinet et peuvent être purgés selon la politique de rétention définie par le cabinet lui-même — un point particulièrement structurant pour les workflows de recherche de jurisprudence IA où des extraits de dossiers sensibles peuvent être interrogés à répétition.

Cette maîtrise a un coût d'entrée plus élevé qu'un abonnement SaaS par siège (20-50 k$ d'investissement initial contre des licences mensuelles), mais elle déplace la charge de la preuve : au lieu de se reposer sur les engagements contractuels d'un tiers, le cabinet peut produire lui-même, en quelques minutes, la traçabilité complète d'une opération d'effacement — un document précieux en cas de contrôle CNIL ou de procédure disciplinaire ordinale.

Le risque déontologique, distinct mais cumulatif

Pour un cabinet d'avocats, l'affaire EXTIA doit se lire à double titre. Sur le plan RGPD, une sanction de 300 000 euros illustre le niveau de vigilance attendu sur l'exécution effective du droit à l'effacement. Sur le plan déontologique, un document couvert par le secret professionnel qui subsiste dans un index vectoriel après une demande de suppression n'est pas seulement une non-conformité RGPD : c'est potentiellement une violation du secret professionnel opposable devant le Conseil de l'Ordre, avec des conséquences disciplinaires qui s'ajoutent — et non se substituent — à la sanction administrative.

Cette double exposition change le calcul de risque pour un DSI de cabinet ou un associé en charge de l'innovation : la question n'est plus seulement « notre fournisseur IA est-il conforme RGPD ? » mais « pouvons-nous démontrer, à la fois à la CNIL et à l'Ordre, que la suppression a été techniquement complète ? ».

Ce qu'il faut vérifier avant de choisir ou d'auditer un outil IA juridique

Quelques questions concrètes à poser à tout fournisseur, SaaS ou on-premise, avant déploiement :

• Où sont stockés les embeddings, et sur quelle infrastructure (pays, sous-traitant, cloud act) ?
• Quel est le délai contractuel d'exécution d'une demande de purge complète (document + embeddings + logs) ?
• Le fournisseur peut-il produire un certificat de suppression daté et vérifiable ?
• Les logs de conversation sont-ils utilisés pour du fine-tuning, et pendant combien de temps sont-ils conservés ?
• En cas de résiliation du contrat, existe-t-il une garantie de suppression totale, y compris dans les sauvegardes ?

Ce niveau de questionnement devrait figurer systématiquement dans les grilles d'audit fournisseur des cabinets, au même titre que les clauses de sécurité classiques. Notre guide IA pour cabinets détaille l'ensemble des critères à intégrer dans un cahier des charges IA juridique, effacement compris.

Ce qui va probablement se durcir

L'affaire EXTIA n'est probablement pas isolée dans le temps : à mesure que les systèmes d'IA générative se généralisent dans les organisations, la CNIL devrait affiner sa doctrine sur ce que signifie une « suppression effective » dans un contexte d'index vectoriel et de modèles de langage. Pour les cabinets d'avocats, l'anticipation est plus rentable que la remédiation a posteriori : documenter dès maintenant sa capacité technique à exécuter une demande d'effacement de bout en bout — document, embeddings, logs — évite à la fois le risque de sanction et le risque disciplinaire.

Avant de généraliser un assistant IA sur des dossiers couverts par le secret professionnel, il vaut la peine de cartographier précisément où vivent vos documents, vos embeddings et vos logs — et qui, en interne ou chez un tiers, est réellement capable d'exécuter une purge complète et auditable en cas de demande d'effacement.