Produit

Gouvernable avant d’être puissante

Dans un cabinet, l’accès à l’information n’est jamais uniforme. C’est le premier obstacle à l’adoption sérieuse de l’IA, et le plus rarement nommé.

Dans toute organisation juridique sérieuse, l’accès à l’information obéit à une structure stricte. Un dossier sensible n’est ouvert qu’à l’équipe qui le traite. Une note interne demeure interne. Certains clients ne peuvent être évoqués devant certaines équipes, pour cause de conflit d’intérêts. Certains documents sont protégés par le secret professionnel, d’autres par des engagements contractuels de confidentialité. Cette structure de permissions n’est pas un détail d’administration que l’on pourrait régler après coup ; elle est une dimension constitutive du métier, au même titre que la compétence juridique elle-même.

Les outils d’IA grand public, et même la plupart des outils dédiés, ignorent presque entièrement cette structure. Ils opèrent sur un accès indifférencié : si le document est dans le système, il est dans le système. Le modèle ne distingue pas un dossier placé sous muraille de Chine d’un dossier ordinaire ; il ne sait pas qu’un collaborateur n’a aucune raison légitime de voir les pièces d’une équipe voisine. La couche d’IA est posée sur l’organisation comme une nappe uniforme, et ce faisant, elle écrase les règles d’accès qui la structurent comme si elles n’existaient pas.

Il faut nommer cet obstacle, parce qu’il est le plus rarement formulé et pourtant le plus décisif. On parle sans cesse de la puissance des modèles, de la qualité de leurs réponses, de leur vitesse. On ne parle presque jamais de leur gouvernabilité, c’est-à-dire de la capacité d’une organisation à contrôler, à travers eux, qui accède à quoi. Or c’est exactement là que se joue l’adoption dans un cabinet : non pas sur ce que l’outil sait faire, mais sur ce qu’il permet de garantir.

La question n’est pas de savoir si l’IA est puissante. La question est de savoir si elle est gouvernable.

Le vrai frein à l’adoption n’est pas l’utilisateur

On explique volontiers la lenteur de l’adoption de l’IA par la résistance supposée des utilisateurs, leur prudence, leur attachement aux habitudes. Sur le terrain, c’est rarement la réalité. Les utilisateurs veulent ces outils ; ils les réclament même, souvent avec impatience. Ceux qui bloquent ne sont pas les utilisateurs, ce sont les responsables : associés, directions juridiques, responsables KM, directions informatiques. Et ils ne bloquent pas par conservatisme, mais parce qu’ils ne peuvent pas, en conscience, valider un déploiement qui rend leur structure de permissions invisible à la couche qui produit.

Leur refus n’exprime aucune défiance envers leurs propres équipes. Il exprime une impossibilité de principe : engager la responsabilité d’un cabinet sur un système incapable de dire, à tout instant, qui a accès à quoi à travers lui, est tout simplement intenable. Le blocage n’est donc pas culturel, il est architectural. Et un blocage architectural ne se lève pas à coups de conduite du changement ou de sessions de formation ; il se lève en changeant l’architecture. C’est pourquoi tant de programmes d’adoption échouent après avoir tout misé sur la formation : ils traitent un problème d’architecture comme un problème de culture.

L’adoption ne bute pas sur la volonté des utilisateurs. Elle bute sur l’impossibilité, pour les responsables, de valider l’ingouvernable.

Un exemple concret rend la chose tangible, parce qu’il se rejoue à l’identique dans beaucoup de cabinets. Un projet de déploiement d’un assistant d’IA à l’échelle est lancé. Il est porté par la direction, financé, attendu par les équipes qui l’ont testé et l’ont aimé. Tout est prêt. Et le projet s’arrête net au comité de sécurité, sur une seule question, posée calmement par le responsable de la conformité : peux-tu me garantir qu’un collaborateur affecté au dossier A ne pourra jamais, en interrogeant l’assistant, faire remonter une pièce du dossier B, placé sous muraille de Chine ?

Si la réponse est non, ou même un oui hésitant, le déploiement ne se fera pas, quelle que soit l’élégance de l’outil ou l’enthousiasme des équipes. Et ce refus est parfaitement rationnel. Un seul franchissement de muraille suffit à engager la responsabilité du cabinet, à compromettre un mandat, parfois à le faire écarter d’une opération entière. Face à ce risque, la puissance de l’outil ne pèse rien. On n’échange pas une garantie déontologique contre un gain de productivité, aussi réel soit-il. Le responsable qui bloque ne se trompe pas : il fait son travail.

Un seul franchissement de muraille coûte plus qu’un outil ne fera jamais gagner.

Ce que la puissance ne peut pas racheter

Il y a, dans le refus des responsables, une logique que les concepteurs d’outils saisissent mal, parce qu’ils raisonnent en capacités quand le responsable raisonne en risques. Pour un concepteur, un outil plus puissant est un meilleur outil ; pour un responsable, un outil plus puissant mais ingouvernable est un risque plus grand, parce qu’il fait plus de choses sans qu’on puisse garantir qu’il ne fera pas la seule chose interdite. La puissance et la gouvernabilité ne sont pas sur la même échelle : l’une mesure ce que l’outil peut faire, l’autre ce qu’on peut l’empêcher de faire.

Cette asymétrie explique pourquoi aucun gain de performance ne rachète un défaut de gouvernabilité. Un outil qui ferait gagner deux heures par jour mais ne pourrait pas garantir l’étanchéité d’une muraille de Chine ne sera pas adopté, parce que les deux heures gagnées ne compensent en rien le risque d’un franchissement. Ce n’est pas un calcul de rentabilité ordinaire, où l’on pèserait le pour et le contre ; c’est un seuil, en deçà duquel rien n’est négociable. Sous ce seuil, la puissance de l’outil ne pèse tout simplement pas dans la balance, parce qu’elle est du mauvais côté d’une ligne que le responsable ne peut pas franchir.

On comprend alors pourquoi la course à la performance, qui occupe tout le marché, passe à côté de ce qui décide réellement de l’adoption en cabinet. Optimiser la puissance, c’est améliorer ce qui n’était déjà pas le point de blocage. Le point de blocage est ailleurs, dans une case que les démonstrations n’abordent jamais parce qu’elle n’a rien de spectaculaire : la capacité à garantir, froidement, qui voit quoi. C’est cette case, et non la brillance des réponses, qui décide si un outil franchit ou non le comité de sécurité.

Pourquoi cloisonner en amont ne suffit pas

On objecte parfois qu’il suffirait de cloisonner les données en amont, de ne donner à l’outil accès qu’à ce que chacun peut voir. L’idée paraît simple et rassurante, mais elle est ingérable à l’échelle d’un cabinet vivant. Car un cabinet n’est pas une structure figée où chacun aurait, une fois pour toutes, un périmètre d’accès stable. Les équipes se recomposent à chaque dossier, les murailles se montent et se démontent au gré des mandats, une même personne a des droits différents selon l’affaire, parfois selon la semaine.

Cette mobilité permanente est la règle, pas l’exception. Un associé peut être barré d’un dossier lundi pour cause de conflit, puis y être admis jeudi parce que le conflit s’est dénoué. Un collaborateur peut travailler le matin sur une opération et se voir, l’après-midi, interdit d’accès à une affaire concurrente. Les permissions ne sont pas un état que l’on configure une fois ; elles sont un flux, qui épouse les mouvements du cabinet en temps réel. Un cloisonnement statique, configuré en amont, est périmé le jour même où on l’a posé.

C’est pourquoi la seule réponse tenable n’est pas de figer des accès, mais de porter les règles dynamiquement, à chaque requête. Il faut que la couche sache, au moment précis où un utilisateur l’interroge, ce que cet utilisateur a le droit de voir ce jour-là, sur ce dossier-là, compte tenu de l’état courant des murailles. Cette évaluation ne peut pas être déléguée à une configuration préalable, parce que la configuration ne suit pas le rythme du cabinet. Elle doit être faite à la volée, à chaque interaction, par une couche qui connaît l’état des permissions à l’instant où elle répond.

Les permissions ne sont pas un état qu’on configure. Elles sont un flux qu’il faut suivre à chaque requête.

Les permissions vivent dans la couche, pas dans le prompt

La leçon est qu’on ne gère pas les permissions, la confidentialité, les régimes d’accès et les cloisonnements internes dans un prompt. Un prompt est un événement ponctuel ; les permissions sont une structure permanente. On les gère dans l’architecture, dans une couche conçue pour les porter et les appliquer à chaque interaction, sans exception et sans dépendre de la vigilance de l’utilisateur. C’est pour cela que MAX a été pensé, dès l’origine, comme une couche au-dessus des modèles et non comme un assistant à leur niveau : une couche qui connaît les règles d’accès de l’organisation et les fait respecter par construction.

Il faut mesurer ce que « par construction » veut dire ici, car c’est le cœur de l’affaire. Une couche qui applique les permissions par construction ne peut pas les enfreindre, même si l’utilisateur formule une requête qui, sans elle, y conduirait. Le respect des murailles n’y dépend ni de la prudence de celui qui interroge, ni d’un paramétrage qu’on aurait pu oublier de mettre à jour ; il est inscrit dans le fonctionnement même de la couche, qui évalue les droits avant de répondre et ne remonte jamais ce que l’utilisateur n’a pas le droit de voir. C’est cette garantie structurelle, et non une promesse de bonne conduite, que réclament les responsables avant d’autoriser un déploiement.

L’IA juridique réellement adoptable n’est donc pas la plus rapide ni la plus impressionnante en démonstration. C’est celle dont une organisation peut dire, à tout instant et sans hésiter, qui a accès à quoi à travers elle. La gouvernabilité n’est pas une contrainte que l’on ajoute à la puissance après coup ; c’est la condition pour que la puissance soit, un jour, autorisée à servir. Un outil ingouvernable, si puissant soit-il, reste à la porte du cabinet ; un outil gouvernable, même moins spectaculaire, y entre et y reste.

Une couche qui ne porte pas les règles d’accès n’est pas une infrastructure. C’est un démonstrateur qui restera à la porte.