CEPD juillet 2026 : ce que les cabinets doivent faire avant le 2 août

Le 7 juillet 2026, le Comité Européen de la Protection des Données a adopté simultanément deux séries de lignes directrices : l'une sur l'anonymisation dans le contexte de l'IA générative, l'autre sur le moissonnage de données web à des fins d'entraînement et d'inférence. Pour les cabinets d'avocats français, ce n'est pas une évolution abstraite du droit des données. C'est une injonction à documenter, maintenant, comment leur IA traite les dossiers clients — avant que l'AI Act entre en application totale le 2 août 2026, soit moins de quatre semaines plus tard.

La fenêtre de mise en conformité n'est pas un délai théorique. C'est une contrainte opérationnelle concrète, avec deux textes qui se superposent en l'espace d'un mois.

Ce que les lignes directrices CEPD du 7 juillet imposent réellement

Les deux textes adoptés le 7 juillet ne sont pas des recommandations de principe. Ils traduisent une position du régulateur européen sur des pratiques qui sont déjà largement répandues dans les outils IA actuels — et qui posent problème.

Sur l'anonymisation

La ligne directrice sur l'anonymisation dans le contexte génératif clarifie un point que beaucoup d'éditeurs legaltech avaient laissé dans le flou : une pseudonymisation n'est pas une anonymisation. Remplacer le nom d'un client par un identifiant dans un document uploadé dans un système IA ne suffit pas à neutraliser le risque de réidentification, notamment lorsque le modèle peut croiser ce document avec d'autres données de contexte.

Pour un cabinet d'avocats, cela signifie que tout outil IA traitant des actes, des contrats, des pièces de procédure ou des correspondances doit désormais répondre à une question précise : à quel stade du traitement les données personnelles sont-elles effectivement anonymisées, et par quel mécanisme documenté ?

Si la réponse se trouve dans les conditions générales d'un éditeur SaaS américain, elle est par définition difficile à auditer et encore plus difficile à opposer à la CNIL en cas de contrôle.

Sur le moissonnage

La seconde ligne directrice concerne le web scraping à des fins d'IA — c'est-à-dire la collecte automatisée de données publiques utilisée pour entraîner ou alimenter des modèles. Pour les cabinets, le sujet est moins évident mais tout aussi réel : nombre d'outils legaltech enrichissent leur base de connaissances en indexant des décisions de justice, des commentaires doctrinaux ou des bases réglementaires issues de sources publiques.

Le CEPD pose désormais des conditions explicites : les données moissonnées contenant des données personnelles doivent être traitées avec une base légale identifiée, et leur utilisation dans un contexte d'IA générative ne peut pas s'appuyer par défaut sur l'intérêt légitime sans analyse d'impact documentée.

Pour les cabinets qui utilisent des outils intégrant de la jurisprudence enrichie ou des bases documentaires construites par scraping, cela crée une obligation de questionnement sur la chaîne de traitement en amont de leur outil — pas seulement sur leur propre usage.

L'AI Act du 2 août : la couche de risque supplémentaire

L'entrée en application totale de l'AI Act le 2 août 2026 ajoute une dimension structurante. Les systèmes IA utilisés dans l'administration de la justice — qualification retenue pour tout outil assistant à l'analyse de pièces, à la rédaction de conclusions ou à l'évaluation de risques juridiques dans un contexte de litige ou de conseil — passent en catégorie haut risque au sens de l'annexe III du règlement.

Les obligations concrètes pour cette catégorie :

Aucun de ces points n'est insurmontable. Mais ils supposent que le cabinet contrôle réellement l'architecture de son outil IA — et pas seulement qu'il a signé des conditions générales.

La question architecturale que les lignes directrices CEPD rendent inévitable

Dans le débat public sur la souveraineté des données juridiques, l'argument dominant est souvent formulé ainsi : « les outils américains envoient vos données aux États-Unis. » C'est partiellement vrai, mais c'est une simplification qui obscurcit ce qui importe vraiment au regard des nouvelles exigences.

La vraie question n'est pas de savoir si un fournisseur LLM reçoit des données. C'est de savoir quoi exactement transite, sous quelle forme, sous quel contrôle, et avec quelle traçabilité.

Ce que « souverain » signifie réellement en architecture RAG

Dans un outil SaaS legaltech standard — qu'il s'agisse de Harvey (~100 000 avocats utilisateurs, 144 M$ d'ARR, valorisation de 8 Md$ fin 2025), de CoCounsel ou de Lexis+ Protégé — le flux de traitement fonctionne typiquement ainsi :

1. Le document client complet est uploadé sur l'infrastructure du fournisseur
2. Il est découpé, vectorisé et indexé dans la base de données du fournisseur
3. Les requêtes de l'avocat interrogent cet index, hébergé hors du cabinet
4. Les chunks pertinents sont envoyés au modèle LLM, potentiellement hébergé dans un autre cloud
5. La réponse est renvoyée à l'utilisateur

Dans ce schéma, le document complet, l'index, les embeddings et les logs de requêtes sont tous sur des infrastructures que le cabinet ne contrôle pas directement. C'est ce que les lignes directrices CEPD rendent problématique : impossibilité d'auditer l'anonymisation réelle, opacité sur la rétention des embeddings, dépendance aux certifications du fournisseur pour démontrer la conformité.

Une architecture IA privée pour cabinet d'avocats construite sur le modèle RAGbase Legal fonctionne différemment :

1. Les documents clients restent sur l'infrastructure du cabinet (on-premise ou cloud privé France)
2. L'orchestration agentique, les connecteurs, les index vectoriels, les permissions et les logs restent sous contrôle client
3. Seuls des extraits minimaux — les chunks pertinents récupérés par le moteur RAG pour répondre à la requête — peuvent transiter vers un fournisseur LLM, selon les conditions API que le cabinet a lui-même sélectionnées et documentées
4. Le cabinet peut choisir un modèle hébergé en France ou en UE pour ces appels, ou un modèle local sans aucun transit externe

C'est cet écart entre le document complet sous contrôle client et le chunk minimal envoyé au modèle qui est décisif pour répondre aux exigences CEPD sur l'anonymisation et la minimisation des données. Et c'est cet écart que la plupart des comparaisons simplistes entre « solutions souveraines » et « outils américains » ne parviennent pas à expliquer clairement.

Ce que les solutions françaises ont déjà intégré

Les acteurs legaltech français qui se sont positionnés sur l'hébergement souverain — Ordalie, Jimini, Doctrine, GenIA-L — ont structuré leurs offres autour de deux garanties contractuelles : hébergement France + absence de rétention des données à des fins d'entraînement. Ces engagements répondent directement à la ligne directrice CEPD sur l'anonymisation, mais ils restent des engagements de niveau SaaS : le cabinet délègue la conformité au fournisseur sans en contrôler l'architecture.

La différence avec une approche on-premise est que le cabinet devient lui-même le responsable de traitement de bout en bout, avec la capacité de le démontrer — ce que l'AI Act exige pour les systèmes haut risque.

Ce que cela change concrètement pour un cabinet de 50 à 500 avocats

La tentation est de traiter ces nouvelles lignes directrices comme un sujet de conformité abstraite, à déléguer au DSI ou au DPO. C'est une erreur de gouvernance. Les associés gérants sont exposés directement, pour deux raisons :

Premièrement, en droit français, le cabinet d'avocats est responsable de traitement pour les données de ses clients. Si un outil IA traite ces données de manière non conforme, la responsabilité ne remonte pas automatiquement à l'éditeur — elle reste au cabinet.

Deuxièmement, les clients institutionnels — grandes entreprises, établissements financiers, acteurs publics — commencent à intégrer des clauses d'audit sur les outils IA dans leurs conventions d'honoraires. Un cabinet incapable de documenter où transitent les données d'un dossier M&A ou d'une procédure de contentieux perd un argument de différenciation, et parfois le mandat.

Trois questions à poser immédiatement à votre fournisseur IA

1. Où sont hébergés les embeddings et l'index vectoriel de mes documents ? (Pas seulement le modèle LLM — l'index.)
2. Quelle est la politique de rétention des données après la fin du contrat, et est-elle vérifiable par audit ?
3. Êtes-vous en mesure de fournir une documentation technique conforme aux exigences AI Act haut risque, incluant la version du modèle, les données d'entraînement et les logs de traitement ?

Si les réponses renvoient à des pages de politique de confidentialité génériques, le risque de non-conformité est réel.

Les coûts de la mise en conformité : construire vs. déléguer

La question financière mérite d'être posée sans détour. Les outils SaaS legaltech haut de gamme ont des coûts d'abonnement significatifs : Harvey se positionne autour de 1 000 à 1 200 USD par utilisateur et par mois pour les grands cabinets. CoCounsel (Thomson Reuters) se situe entre 250 et 500 USD/utilisateur/mois, Lexis+ Protégé entre 500 et 1 000+ USD/utilisateur/mois.

Ces tarifs n'incluent pas le coût de mise en conformité CEPD/AI Act, qui repose entièrement sur les certifications du fournisseur — certifications que le cabinet ne peut pas auditer lui-même.

Une infrastructure RAGbase Legal représente un investissement one-time de l'ordre de 20 à 50 k$ pour le déploiement, avec des coûts d'inférence qui dépendent ensuite du fournisseur LLM choisi par le cabinet — et que le cabinet contrôle. Sur un horizon de trois ans, pour un cabinet de 30 avocats utilisant intensivement un outil IA, la comparaison économique n'est pas défavorable à l'option on-premise. Et la conformité CEPD/AI Act est documentable de bout en bout, sans dépendre d'un tiers.

Pour les charges de travail qui ne nécessitent pas ce niveau de contrôle — recherche de jurisprudence IA sur des bases publiques, veille réglementaire, synthèse de textes non confidentiels — les outils SaaS restent pertinents et compétitifs. L'erreur serait d'imposer une architecture on-premise à l'ensemble des usages, comme l'erreur inverse serait de traiter un dossier d'arbitrage international ou une transaction sensible avec un outil dont on ne contrôle pas l'infrastructure.

Ce que le marché va faire dans les prochaines semaines

Les lignes directrices CEPD du 7 juillet ne créent pas d'obligation de migration immédiate. Elles créent une obligation de documentation et de vérification qui, pour nombre de cabinets, révélera des angles morts dans leur gouvernance IA actuelle.

La dynamique prévisible du marché suit trois axes :

• Les grands éditeurs SaaS (Harvey, Thomson Reuters, LexisNexis) vont accélérer leurs certifications EU et leurs engagements contractuels sur la rétention. Certains déploieront des instances dédiées hébergées dans des datacenters européens — ce qui répond partiellement aux exigences géographiques mais ne résout pas la question du contrôle de l'index et des logs.

• Les acteurs français souverains (Ordalie, Jimini, GenIA-L) vont capitaliser sur leur positionnement existant et probablement adapter leur documentation contractuelle aux exigences CEPD pour les rendre opposables.

• Les cabinets les plus exposés — ceux qui traitent des données de personnes physiques dans des contextes de litige, de droit de la famille, de droit social ou de procédures pénales — vont devoir arbitrer rapidement entre une mise en conformité par le contrat (délégation au fournisseur) et une mise en conformité par l'architecture (contrôle interne).

Le guide IA pour cabinets que nous maintenons à jour intègre ces évolutions réglementaires au fil des adoptions — c'est le bon point de départ pour structurer cet arbitrage.

Les lignes directrices CEPD du 7 juillet et l'AI Act du 2 août 2026 ne demandent pas aux cabinets d'arrêter d'utiliser l'IA. Ils leur demandent de savoir ce que leur IA fait avec les données de leurs clients — et d'être capables de le démontrer. C'est une exigence d'architecture autant que de droit.

Avant d'évaluer une nouvelle solution ou de renouveler un contrat existant, trois points méritent une vérification concrète : où réside l'index vectoriel de vos documents, quelle est la base légale du traitement des données moissonnées par votre fournisseur, et votre outil peut-il produire la documentation technique exigée par l'AI Act pour un système haut risque. Les réponses à ces trois questions déterminent votre exposition réelle — indépendamment de ce qu'indique la page marketing de votre fournisseur.