IA et secret professionnel : les 7 vérifications à faire avant de choisir un outil

Le secret professionnel n'est pas une règle de déontologie parmi d'autres. C'est un devoir d'ordre public, général, absolu et illimité dans le temps, protégé à la fois par l'article 226-13 du Code pénal (un an d'emprisonnement et 15 000 € d'amende), l'article 66-5 de la loi n° 71-1130 du 31 décembre 1971 et l'article 2 du Règlement Intérieur National de la profession d'avocat (RIN). Il couvre toutes les confidences reçues, toutes les pièces d'un dossier, toutes les correspondances entre l'avocat et son client.

L'arrivée massive des outils d'IA générative dans les cabinets pose une question que ni le Code pénal ni le RIN n'avaient anticipée : qu'est-ce qu'un avocat partage, exactement, quand il pose une question à une IA ? La réponse technique est loin d'être évidente — et choisir un outil non conforme expose à une sanction disciplinaire, voire pénale, sans que l'avocat s'en rende toujours compte sur le moment. Cet article propose une checklist opérationnelle de sept vérifications à effectuer avant d'adopter un outil.

Le secret professionnel à l'ère de l'IA

Pendant vingt ans, la question de la confidentialité informatique des cabinets s'est résumée à trois sujets : la messagerie, les sauvegardes et le cloud de stockage. Un avocat prudent choisissait un hébergeur européen, chiffrait ses mails sensibles avec son confrère, et estimait avoir fait le tour du problème.

L'IA générative change la nature du risque. Un outil d'IA ne se contente pas de stocker des documents — il en ingère le contenu, le transmet à un modèle de langage, parfois à plusieurs sous-traitants en cascade, pour produire une réponse. Chaque requête est potentiellement une communication vers un tiers technique au sens du secret.

La jurisprudence française en matière de secret professionnel est particulièrement protectrice : elle sanctionne la divulgation, peu important que l'information soit arrivée à une personne qui ne l'a pas exploitée ou qui est elle-même tenue à une forme de confidentialité. Un fournisseur d'IA qui logge, même temporairement, le contenu d'un prompt n'est pas un confident légitime — c'est un tiers au regard de l'article 226-13 du Code pénal.

D'où l'impératif de vérifier en amont les propriétés techniques de l'outil. La sanction disciplinaire ne se demande pas si vous saviez : elle s'applique dès que la divulgation est établie. Sept vérifications permettent de filtrer 90 % des outils non conformes avant même de leur confier une requête test.

Les 7 vérifications essentielles

Vérification 1 — Hébergement européen

Ce qu'il faut exiger : que les données (prompts, réponses, métadonnées, logs) soient traitées et stockées sur des serveurs physiquement situés dans l'Union européenne. Pas de transit hors UE, même ponctuel, pour le traitement IA lui-même.

Pourquoi : le RGPD encadre strictement les transferts de données personnelles hors Espace économique européen (articles 44 et suivants). Un outil qui fait transiter vos prompts par des serveurs américains pour le traitement expose vos données à un cadre juridique tiers — et vous oblige à documenter un transfert encadré (Clauses Contractuelles Types, Data Privacy Framework) qui ne compense pas, en pratique, le risque d'exposition.

Comment vérifier : demander la liste nominative des sous-traitants, avec leur localisation serveur et leurs certifications (ISO 27001, SOC 2 Type II). Un éditeur sérieux fournit cette liste publiquement, généralement dans un document d'Avenant Traitement des Données (DPA).

Côté Consia : le traitement IA est réalisé exclusivement à Paris, sur une infrastructure certifiée ISO 27001 et SOC 2 Type II. Les détails d'architecture, la localisation précise de chaque type de donnée et la liste des sous-traitants figurent sur la page Sécurité.

Vérification 2 — Architecture sans upload de documents

Ce qu'il faut exiger : idéalement, que l'outil ne demande jamais d'uploader de pièces de dossier. Une interface conçue pour des questions en langage naturel, qui interroge des bases publiques (Légifrance, Judilibre, Journal Officiel), est structurellement plus protectrice qu'une interface qui absorbe des PDF de conclusions ou des correspondances avec adversaires.

Pourquoi : chaque upload est une occasion supplémentaire de divulguer du contenu couvert — y compris involontairement, par glisser-déposer d'un mauvais fichier ou par habitude. L'architecture la plus sûre est celle qui rend l'erreur impossible plutôt que celle qui la sanctionne.

Comment vérifier : lire les conditions d'utilisation de l'outil. S'il accepte les uploads, vérifier (a) la destination technique des fichiers, (b) leur durée de conservation, (c) leur traitement par l'IA, (d) la ségrégation par utilisateur.

Côté Consia : par choix d'architecture, Consia n'accepte aucun upload de document. Le service est structurellement limité à l'interrogation de bases juridiques publiques en langage naturel, ce qui est rappelé expressément à l'article 5 des CGU. Une fonctionnalité d'analyse de fichiers est à l'étude — elle ne sera mise en ligne que lorsqu'un niveau de sécurité compatible avec le secret professionnel aura été validé.

Vérification 3 — Anonymisation automatique des prompts

Ce qu'il faut exiger : un mécanisme technique de détection et de remplacement automatique des données identifiantes (noms propres, dates, numéros de dossier, adresses) dans le prompt, avant son envoi au modèle de langage. Le modèle ne doit voir que des tokens anonymisés ; la ré-hydratation des données réelles se fait côté serveur, sans que les données originales n'atteignent jamais le LLM.

Pourquoi : même avec un outil sans upload, le prompt lui-même peut contenir des éléments couverts par le secret (cf. exemple M. Durand plus haut). L'anonymisation déplace la ligne de confidentialité en amont du traitement IA.

Comment vérifier : demander à l'éditeur s'il implémente une couche d'anonymisation PII (Personally Identifiable Information) avant l'envoi au LLM, et sur quels types de données elle opère.

Côté Consia : l'anonymisation automatique des prompts fait partie de la roadmap sécurité publiée sur /securite. L'architecture repose d'abord sur une discipline d'usage — les CGU invitent l'utilisateur à ne pas soumettre d'informations identifiantes — et sur le principe général de non-acceptation d'upload, qui limite mécaniquement la surface d'exposition.

Vérification 4 — Chiffrement bout-en-bout

Ce qu'il faut exiger :

• En transit : TLS 1.2 au minimum, idéalement TLS 1.3, avec HSTS pour empêcher tout fallback non chiffré.
• Au repos : chiffrement symétrique AES-256 (ou équivalent) sur toutes les données stockées — conversations, historiques, métadonnées.
• Gestion des clés : idéalement un KMS (Key Management Service) physiquement séparé de la base de données, pour qu'une compromission d'un composant ne suffise pas à lire le contenu.

Pourquoi : le chiffrement au repos protège contre (a) une intrusion dans la base, (b) une réquisition judiciaire d'un sous-traitant d'infrastructure, (c) une faille d'un prestataire. Sans chiffrement au repos, une panne de configuration, un backup mal protégé ou une fuite accidentelle rend les conversations lisibles en clair.

Comment vérifier : demander les algorithmes exacts utilisés, la localisation du KMS, la séparation physique clés / données.

Côté Consia : chiffrement AES-256-GCM côté application avant stockage en base, TLS 1.3 + HSTS en transit, KMS séparé physiquement de la base chiffrée. Détails techniques sur la section Chiffrement de /securite.

Vérification 5 — CLOUD Act et souveraineté

Ce qu'il faut exiger : une chaîne complète de sous-traitants, avec leur droit d'incorporation (français, européen, américain) et leur localisation serveur. Un fournisseur français qui s'appuie sur un cloud américain en dessous (AWS US, Azure US, Google Cloud US) reste potentiellement soumis au CLOUD Act par ricochet.

Pourquoi : le CLOUD Act (Clarifying Lawful Overseas Use of Data Act, adopté en 2018) permet au gouvernement américain d'exiger d'une société de droit américain les données qu'elle stocke, y compris sur des serveurs situés hors des États-Unis. Il coexiste avec le RGPD, et la CNIL comme le Comité européen de la protection des données (CEPD) ont publiquement pointé le conflit de normes qu'il crée. Pour un avocat, cela signifie qu'un prompt envoyé à un service américain, même hébergé techniquement à Paris, reste théoriquement saisissable par une autorité étrangère.

Comment vérifier : demander la nationalité juridique de chaque sous-traitant et la chaîne d'infrastructure sous-jacente. Si elle est américaine, vérifier la neutralisation technique du risque : zero data retention, chiffrement au repos avec clé non détenue par le sous-traitant US, absence de stockage persistant.

Côté Consia : certains sous-traitants d'infrastructure sont des sociétés de droit américain, mais ils hébergent les services en UE et sont neutralisés techniquement : zero data retention chez le fournisseur IA, blocs chiffrés AES-256-GCM chez l'hébergeur de base, clé de chiffrement séparée physiquement chez un autre prestataire. La section CLOUD Act de /securite détaille, composant par composant, ce qu'une réquisition américaine pourrait obtenir — spoiler : rien d'exploitable.

Vérification 6 — RGPD et DPA

Ce qu'il faut exiger :

• Un Avenant Traitement des Données (DPA) signé entre l'éditeur et le cabinet, décrivant précisément les finalités, durées de conservation, et sous-traitants.
• Un registre de sous-traitance à jour, accessible sur demande.
• L'implémentation effective et automatisée des droits des personnes : accès, rectification, effacement, portabilité, opposition (articles 15 à 21 du RGPD).
• Une procédure de notification de violation de données conforme à l'article 33 RGPD (72 heures).

Pourquoi : en tant que responsable de traitement pour les données de ses clients, l'avocat doit encadrer chaque sous-traitance technique par un DPA conforme à l'article 28 du RGPD. Un outil qui ne propose pas de DPA, ou qui propose un DPA minimaliste sans liste de sous-traitants, ne respecte pas les obligations que le RGPD fait peser sur vous.

Comment vérifier : demander le DPA avant signature de l'abonnement, relire la liste des sous-traitants, vérifier que les durées de conservation sont justifiées (pas un simple « jusqu'à suppression du compte »).

Côté Consia : DPA public accessible depuis la page DPA, avec la liste nominative complète des sous-traitants. Les droits RGPD sont implémentés nativement (export JSON en un clic, suppression du compte en cascade, rectification via paramètres).

Vérification 7 — Auditabilité et logs

Ce qu'il faut exiger : la capacité pour l'outil de fournir, en cas de contestation, un historique horodaté et fiable des échanges — questions posées, sources affichées, réponses générées, utilisateur authentifié.

Pourquoi : en cas de litige (avec un client qui reprocherait un conseil mal fondé, avec un confrère qui contesterait une citation), l'avocat doit pouvoir retracer ce que l'outil a réellement affiché. Une convention de preuve contractuelle avec l'éditeur transforme ces logs en moyen de preuve opposable.

Comment vérifier : lire la clause « convention de preuve » dans les CGU de l'outil. L'éditeur s'engage-t-il à conserver les logs sur un support fiable et durable ? Ces logs font-ils foi entre les parties ? Quelle est leur durée de conservation ?

Côté Consia : l'article 15 des CGU formalise une convention de preuve explicite. Les logs d'usage — acceptation des CGU, questions posées, réponses générées, sources officielles présentées, horodatage — sont conservés sur support fiable et font foi entre les parties jusqu'à preuve contraire.

Votre outil coche-t-il les 7 cases ?

Voici la checklist récapitulative. La colonne Votre checklist est laissée vide pour que vous puissiez, mentalement ou par écrit, la remplir pour chaque outil que vous évaluez.

Critère	Votre checklist	Consia
1. Hébergement européen (traitement + stockage)	—
2. Architecture sans upload de documents	—
3. Anonymisation automatique des prompts	—
4. Chiffrement TLS 1.3 + AES-256 + KMS séparé	—
5. CLOUD Act neutralisé techniquement	—
6. DPA public + droits RGPD automatisés	—
7. Auditabilité + convention de preuve	—

Un outil qui coche les sept cases est compatible, à notre connaissance, avec les exigences du secret professionnel telles qu'elles découlent de l'article 226-13 du Code pénal, de l'article 66-5 de la loi 71-1130 et de l'article 2 du RIN. Un outil qui en coche cinq ou six peut être utilisé sous conditions, avec des précautions d'usage renforcées. En dessous, l'usage sur des sujets couverts par le secret devient difficilement défendable sur le plan déontologique.

Que faire si votre outil actuel ne passe pas toutes les vérifications ?

La réponse raisonnable n'est ni « tout arrêter », ni « continuer comme avant ». Elle tient en trois étapes, à mener dans l'ordre.

1. Cesser immédiatement d'y soumettre des informations couvertes par le secret. Avant toute discussion sur une migration, la mesure conservatoire est de retirer l'outil des workflows sensibles. Les usages génériques (recherche d'article de loi, vérification d'une date, synthèse d'un texte officiel) peuvent continuer ; les prompts contenant des éléments identifiants ou stratégiques, non.

2. Évaluer le risque disciplinaire résiduel. Ce qui a déjà été envoyé ne peut pas être rappelé. Documenter (a) le type d'informations transmises, (b) les garanties techniques effectives de l'outil sur ces données, (c) les durées de conservation. Si le risque est significatif, en informer le Bâtonnier dans le cadre d'une démarche préventive peut être pertinent.

3. Migrer vers un outil conforme. La checklist des sept vérifications permet d'identifier rapidement les alternatives sérieuses. La migration n'est pas seulement un changement d'outil : c'est l'occasion de poser les règles d'usage internes au cabinet (quels prompts autorisés, quelle anonymisation manuelle en attendant l'anonymisation automatique de l'outil, quelle formation des collaborateurs).

Sources citées

1. 01.
   Article 226-13 du Code pénal — Atteinte au secret professionnel— Légifrance · consulté le 2026-04-14
2. 02.
   Loi n° 71-1130 du 31 décembre 1971 — Article 66-5 (secret professionnel de l'avocat)— Légifrance · consulté le 2026-04-14
3. 03.
   Règlement Intérieur National de la profession d'avocat (RIN)— Conseil National des Barreaux · consulté le 2026-04-14
4. 04.
   Règlement (UE) 2016/679 — RGPD— CNIL · consulté le 2026-04-14
5. 05.
   Transferts de données hors UE — dossier souveraineté— CNIL · consulté le 2026-04-14
6. 06.
   Sécurité de Consia — architecture, chiffrement, sous-traitants— Consia · consulté le 2026-04-14
7. 07.
   CGU Consia — Article 5 (Secret professionnel) et Article 15 (Convention de preuve)— Consia · consulté le 2026-04-14