CNB et IA juridique : qui fixera les règles en cabinet ?

Demandez à un associé gérant de citer le président du Conseil national des barreaux ou d'expliquer en une phrase ce que prévoit l'article 6.2 du Règlement intérieur national. Puis demandez-lui le prix par siège de Harvey ou de CoCounsel. La réponse à la seconde question viendra sans hésiter. La première restera souvent sans réponse — y compris dans des cabinets qui ont déjà signé un contrat d'IA générative. Cette asymétrie n'est pas anecdotique : elle signale que la profession investit dans des outils avant d'avoir intégré qui, structurellement, en fixera les règles d'usage.

Un article récent d'actu-juridique.fr, consacré à une présentation en 23 questions du Conseil national des barreaux, pointe précisément ce déficit de connaissance institutionnelle, y compris chez les avocats eux-mêmes (actu-juridique.fr, 1ère partie). Ce constat, apparemment éloigné des enjeux d'intelligence artificielle, est en réalité au cœur du sujet : ce n'est pas un éditeur SaaS californien qui déterminera demain ce qu'un avocat français a le droit de faire transiter par une IA, mais bien le CNB — via le RIN, ses recommandations et l'appréciation disciplinaire des bâtonniers.

Le CNB, institution normative méconnue mais déjà compétente sur le numérique

Créé par la loi du 31 décembre 1990, le Conseil national des barreaux est l'institution représentative de l'ensemble de la profession d'avocat en France. Ses deux missions structurantes sont connues des juristes institutionnels mais rarement des équipes innovation ou des DSI de cabinet : unifier les règles et usages de la profession via le Règlement intérieur national, et représenter les avocats auprès des pouvoirs publics, notamment sur les textes touchant à l'exercice professionnel.

Cette double casquette — normative et représentative — est précisément ce qui rend le CNB incontournable sur l'IA. Il ne s'agit pas d'un régulateur sectoriel au sens de la CNIL ou de l'ARCOM, mais d'une instance qui produit du droit souple opposable à la profession elle-même, et qui négocie en amont avec l'État la manière dont des textes horizontaux (RGPD, AI Act européen, futures lois sur l'IA) s'appliqueront spécifiquement aux avocats. Quand le CNB publie une recommandation sur l'usage du numérique, elle s'articule directement avec l'obligation de formation continue — qui intègre déjà des modules sur les outils numériques — et avec le corpus déontologique du RIN.

L'article d'actu-juridique.fr souligne que cette mécanique reste largement invisible pour la majorité des avocats, qui perçoivent le CNB comme une structure administrative lointaine plutôt que comme l'organe qui, concrètement, validera ou disqualifiera des pratiques d'usage de l'IA. Pour un DSI de cabinet qui négocie un contrat pluriannuel avec un éditeur d'IA générative, ignorer cette dynamique revient à signer un bail sans avoir lu le règlement de copropriété.

Ce que le CNB a déjà posé sur la table concernant l'IA

Le CNB n'aborde pas l'IA générative comme un sujet nouveau ex nihilo. Il l'a déjà rattachée à des obligations préexistantes :

• Le secret professionnel absolu, fondement de l'article 66-5 de la loi du 31 décembre 1971, qui couvre l'ensemble des correspondances, notes et pièces du dossier — une protection jugée par la jurisprudence comme l'une des plus étendues du droit français, au point que la Cour de cassation a refusé à plusieurs reprises d'en assouplir le périmètre même face à des enjeux d'enquête pénale.
• L'article 6.2 du RIN, qui encadre le recours aux outils numériques et technologiques et impose à l'avocat de s'assurer, avant tout usage, de la maîtrise du traitement de données couvertes par le secret professionnel.
• La formation continue obligatoire, désormais intégrée au cursus annuel des avocats, qui a vu l'ajout de modules sur le numérique et, de plus en plus, sur l'usage raisonné de l'intelligence artificielle.

Cette articulation donne au CNB une légitimité que n'a aucun éditeur de logiciel, aussi performant soit-il. Un éditeur peut promettre une architecture conforme au RGPD ; seul le CNB peut qualifier un usage de conforme ou non à la déontologie de la profession, avec des conséquences disciplinaires directes pour l'avocat et, en cabinet, pour la supervision qu'en assure le bâtonnier local.

La responsabilité du bâtonnier : le maillon souvent oublié

La discussion sur l'IA en cabinet se focalise presque toujours sur l'éditeur et le DPO. Elle oublie un acteur clé : le bâtonnier, garant local de la déontologie et des pratiques professionnelles de son barreau. En cas de manquement avéré au secret professionnel via un outil d'IA mal configuré — fuite de données clients vers un sous-traitant tiers non maîtrisé, absence de traçabilité sur ce qui a été transmis à un modèle externe — c'est l'ensemble de la chaîne de contrôle ordinal qui est engagée : le bâtonnier qui n'a pas alerté, le conseil de l'ordre qui a laissé proliférer un usage non encadré, et in fine le CNB dont les recommandations n'auraient pas été suivies.

Cette chaîne de responsabilité descendante change la nature du choix technologique. Il ne s'agit plus seulement d'un arbitrage coût/performance entre deux SaaS juridiques, mais d'un choix d'architecture qui doit pouvoir être défendu devant une instance disciplinaire. Un cabinet qui pourra démontrer, pièces à l'appui, que ses documents clients n'ont jamais quitté son infrastructure et que seuls des extraits minimaux anonymisés ont transité vers un fournisseur de modèle, partira dans une position très différente de celui qui ne pourra produire qu'une clause contractuelle de confidentialité rédigée en anglais par un éditeur basé à San Francisco.

Pourquoi l'architecture, et non la promesse marketing, sera le critère retenu

Les IA cloud mutualisées destinées aux cabinets d'avocats — Harvey, CoCounsel (Thomson Reuters), Lexis+ Protégé, et plus récemment des assistants généralistes positionnés sur le juridique comme Claude Cowork — partagent une caractéristique structurelle : le document complet du dossier transite vers une infrastructure cloud tierce, le plus souvent hébergée hors de France, pour y être indexé, traité et parfois conservé à des fins d'amélioration du modèle ou de cache de performance.

Cette architecture n'est pas illégale en soi, et ces éditeurs investissent réellement dans la conformité RGPD et dans des engagements contractuels de confidentialité. Mais elle pose un problème spécifique au regard de la grille de lecture ordinale : le CNB et les bâtonniers raisonnent en termes de contrôle effectif et d'auditabilité, pas uniquement de promesse contractuelle. Or, par construction, un cabinet qui utilise une IA cloud mutualisée ne peut généralement pas produire une preuve technique indépendante de ce qui a été transmis, conservé, ou utilisé pour améliorer un modèle partagé entre des milliers d'autres utilisateurs, parfois dans d'autres juridictions.

Le précédent Harvey illustre l'ampleur de l'enjeu : l'éditeur revendique aujourd'hui environ 100 000 avocats utilisateurs et une valorisation de 8 milliards de dollars fin 2025, porté par un ARR de 144 millions de dollars. Une étude de Stanford a par ailleurs mesuré un taux d'hallucination d'environ 1 sur 6 sur ce type d'outil — un chiffre qui doit alerter sur la nécessité d'une supervision humaine renforcée, indépendamment même de la question de l'hébergement des données.

Comparatif structurel des architectures

| Auditabilité par le bâtonnier/CNB | Limitée, dépend des clauses contractuelles de l'éditeur | Limitée, dépend du contrat entreprise | Totale : logs et permissions sur l'infrastructure du cabinet | | Tarification indicative | 1 000-1 200 USD/utilisateur/mois (Harvey) ; 250-500 USD (CoCounsel) ; 500-1 000+ USD (Protégé) | Ordre de grandeur estimé 200-400 USD/utilisateur/mois (entreprise) | 20-50 k$ en investissement initial, infrastructure maîtrisée | | Dépendance à une infrastructure étrangère | Forte | Forte | Nulle pour l'agent, l'index et le stockage |

Ce tableau ne vise pas à disqualifier les IA cloud mutualisées — elles répondent à de vrais besoins de rapidité de déploiement et de puissance de modèle. Mais il objective un écart que le CNB ne manquera pas de formaliser tôt ou tard dans ses recommandations : la différence entre un outil qui traite les données du cabinet à distance, et un outil dont l'infrastructure appartient au cabinet, le LLM n'intervenant que ponctuellement sur des fragments choisis.

Ce que change concrètement une architecture type RAGbase Legal

L'argument honnête n'est pas "nous n'envoyons jamais rien à l'extérieur" — toute IA générative performante s'appuie, à un moment donné, sur un modèle de langage, qu'il soit hébergé par Anthropic, OpenAI, ou un autre fournisseur. La différence se joue en amont, sur ce qui reste à l'intérieur du périmètre du cabinet.

Dans une architecture IA privée pour cabinet d'avocats, l'agent d'orchestration, l'index documentaire (vector store), les connecteurs vers la gestion documentaire, les permissions par utilisateur ou par dossier, et les journaux d'audit complets sont déployés sur l'infrastructure du cabinet — serveur on-premise ou cloud privé sous contrôle exclusif du DSI. Les documents clients dans leur intégralité — actes, correspondances couvertes par le secret professionnel, pièces de procédure — ne quittent jamais cette infrastructure.

Seuls des chunks minimaux — des extraits courts et strictement nécessaires à la génération d'une réponse précise — sont envoyés au fournisseur de LLM choisi par le cabinet, selon les conditions contractuelles de l'API retenue (zéro rétention, pas d'entraînement sur les données, juridiction négociée). Ce découpage change la nature du risque : même en cas d'incident côté fournisseur de modèle, l'exposition porte sur des fragments dépourvus de contexte complet, et non sur le dossier entier d'un client.

Pour un usage emblématique comme la recherche de jurisprudence IA, cette architecture permet de croiser des milliers de décisions indexées localement sans jamais faire transiter l'intégralité d'un dossier client vers un tiers — seule la requête de recherche et les extraits pertinents circulent, le reste de la base documentaire restant scellé dans l'infrastructure du cabinet.

Ce que le bâtonnier peut vérifier, concrètement

Une fenêtre d'anticipation encore ouverte

Le CNB n'a pas encore publié de doctrine exhaustive et opposable sur l'architecture technique acceptable pour l'IA en cabinet — il a, à ce stade, posé des jalons via le RIN et la formation continue, dans une logique de principes plutôt que de spécifications techniques. C'est précisément cette fenêtre qu'il faut exploiter. Les cabinets qui attendent une circulaire détaillée avant d'agir prennent le risque de devoir migrer en urgence des outils déjà déployés, avec des coûts de bascule et une perte de confiance interne. Ceux qui choisissent dès maintenant une architecture alignée par construction sur les exigences prévisibles — secret professionnel, contrôle effectif, auditabilité — n'auront pas à justifier a posteriori des choix faits sous la seule pression du marketing d'un éditeur américain.

Le guide IA pour cabinets détaille les critères opérationnels à documenter avant toute signature de contrat IA : localisation des données, nature exacte de ce qui transite vers le LLM, capacité d'audit indépendant, et compatibilité avec l'article 6.2 du RIN tel qu'il est aujourd'hui interprété par les premiers conseils de l'ordre qui s'en sont saisis.

Avant de renouveler ou de signer un contrat d'IA générative, un exercice simple s'impose : demander à l'éditeur de démontrer, documents techniques à l'appui, ce qui quitte réellement l'infrastructure du cabinet et ce qui y reste. Si la réponse se limite à une clause de confidentialité générique, le cabinet s'expose à devoir refaire cet arbitrage dans un an, sous contrainte ordinale cette fois. Mieux vaut le faire maintenant, à froid, avec une architecture conçue dès l'origine pour y répondre.