Produit

Personne ne veut un onglet de plus

Le premier obstacle à l’adoption de l’IA juridique n’est pas la qualité des modèles. C’est le geste, mille fois répété, de transférer l’information d’un outil à un autre.

Observez un professionnel du droit une journée entière, dans n’importe quel cabinet, et vous verrez la même scène. Une messagerie ouverte en permanence. Un système de gestion documentaire. Un outil de gestion des matières. Un éditeur de texte. Un comparateur de documents. Une plateforme de visioconférence, une autre de signature. Et désormais, sur le côté, dans un onglet à part, un copilote. À la fin de la journée, cette personne a passé une part significative de son temps non pas à exercer le droit, mais à transférer de l’information d’un environnement vers un autre, à la main, en copiant, en collant, en reformulant, en rapatriant.

Cette scène est si banale qu’on ne la voit plus. Elle s’est installée par couches, un outil après l’autre, chacun résolvant un problème réel, et la somme a fini par créer un problème que personne n’avait choisi : l’éclatement du travail entre une dizaine d’environnements qui ne se parlent pas. Le professionnel est devenu, sans l’avoir voulu, le seul lien entre des outils qui s’ignorent. C’est lui qui porte le contexte d’un endroit à l’autre, parce qu’aucun système ne le fait à sa place.

Cette friction est devenue si ordinaire qu’on ne la formule même plus. Elle est pourtant le premier obstacle réel à l’adoption sérieuse de l’IA juridique, bien avant la qualité des modèles ou la pertinence des réponses. On débat de la performance des systèmes alors que le point de blocage est ailleurs, en amont, dans le simple fait d’avoir à se déplacer pour les solliciter.

Le premier frein à l’IA juridique n’est pas ce qu’elle sait faire. C’est l’endroit où il faut aller pour le lui demander.

L’onglet qui s’empile au lieu de remplacer

Quand un outil arrive avec sa propre interface, son propre cadre, son propre vocabulaire, il ajoute une charge sans en retirer aucune. Il ne remplace rien ; il s’empile. L’utilisateur doit quitter le contexte de son travail, entrer dans celui de l’outil, traduire son besoin dans le langage de l’outil, attendre, évaluer la réponse, puis la rapatrier à la main dans son flux réel. Chacune de ces étapes est minuscule ; leur répétition, elle, ne l’est pas.

Il faut bien mesurer la nature de ce coût, parce qu’elle explique pourquoi il est si souvent négligé. Ce n’est pas un coût ponctuel et visible, du genre qu’on évalue avant d’acheter. C’est un coût diffus, fait de quelques secondes perdues à chaque sollicitation, multipliées par le nombre de sollicitations dans une journée, puis par le nombre de jours, puis par le nombre d’utilisateurs. Pris isolément, chaque transfert est négligeable ; c’est précisément pour cela qu’on ne le compte pas. Mais ce qu’on ne compte pas finit par décider.

Le plus pernicieux, c’est que ce coût ne se voit nulle part. Il ne figure sur aucune facture, ne s’inscrit dans aucun indicateur, ne se compare à rien. Il se dissout dans le quotidien, sous la forme de quelques secondes perdues mille fois par jour, et c’est précisément parce qu’il est invisible qu’il finit par décider de l’échec ou du succès d’un déploiement. Un outil dont chaque usage coûte un petit effort de déplacement sera, à l’échelle, déserté, quelle que soit la brillance de ce qu’il produit une fois qu’on y est.

Un petit effort, mille fois par jour, sur des centaines de personnes, ne reste pas petit. Il décide de tout.

On voit alors que le transfert manuel d’un environnement à l’autre n’a rien d’une tâche annexe sans importance. Il occupe un temps réel, il fragmente l’attention, il interrompt le fil du travail au moment précis où il faudrait le tenir. Et surtout, il n’apporte rien : recopier une information d’un outil vers un autre ne crée aucune valeur juridique, c’est une pure perte, une dépense d’énergie que le travail intellectuel n’exige pas et que seule l’architecture des outils impose.

Le transfert manuel d’un outil à l’autre n’est pas du travail juridique. C’est du coût d’usage déguisé en productivité.

Venir là où le travail a déjà lieu

Si le coût naît du déplacement, alors la seule manière de le supprimer n’est pas de rendre le déplacement plus agréable, mais de le supprimer tout court. Un outil qui ne demande pas qu’on aille à lui n’a pas besoin d’être plus rapide à ouvrir ou plus simple à apprendre : il n’a pas à être ouvert, ni appris comme un lieu séparé, parce qu’il n’est pas un lieu. Il agit là où le travail se fait déjà, dans la messagerie, dans l’éditeur, dans le système de matières, sans réclamer qu’on en sorte.

Ce renversement change la question d’adoption du tout au tout. Tant qu’un outil est une destination, la question est : comment convaincre les gens d’y aller, et d’y retourner, jour après jour ? Dès qu’un outil cesse d’être une destination, cette question disparaît, parce qu’il n’y a plus nulle part où aller. L’utilisateur n’a pas à décider d’utiliser l’IA ; elle est présente dans l’environnement qu’il utilise de toute façon. On ne lui demande pas d’ajouter un geste à sa journée, on retire de sa journée un geste qui n’aurait jamais dû s’y trouver.

Cette manière de procéder ne relève pas du confort, mais de la viabilité à l’échelle. Une infrastructure qui s’incarne dans les outils existants ne se heurte pas au plafond d’adoption qui guette toute destination, parce qu’elle ne demande à personne de changer ses habitudes. Elle se loge dans les flux déjà installés, et c’est précisément parce qu’elle n’exige aucun geste nouveau qu’elle peut transformer la manière de travailler sans en faire payer le coût d’entrée. La transformation se fait par-dessous, sans demander d’effort à ceux qu’elle transforme.

Une infrastructure ne demande pas à l’organisation de s’adapter à elle. Elle se loge dans ce que l’organisation fait déjà.

Pourquoi la discipline ne sauvera pas l’adoption

Face à ce constat, la réponse spontanée consiste à minimiser. On objectera que l’utilisateur s’habitue, qu’un onglet de plus n’est pas un drame, qu’il suffit d’un peu de discipline pour intégrer le nouvel outil dans ses gestes. Cet argument a l’air raisonnable, et il l’est, dans un certain périmètre : pour un utilisateur motivé, sur quelques semaines, la discipline suffit en effet à surmonter la friction.

Mais ce périmètre n’est pas celui d’un déploiement réel. Ce qui est vrai pour un utilisateur motivé sur quelques semaines cesse de l’être pour deux cents personnes sur deux ans, sous la pression du quotidien, dans les jours chargés où chaque seconde compte et où le réflexe l’emporte sur la bonne résolution. La discipline est une ressource rare, inégalement distribuée, et surtout fluctuante : elle est haute le premier mois, elle s’érode ensuite. Fonder l’adoption d’un outil sur la discipline de ses utilisateurs, c’est la fonder sur ce qui cède en premier.

L’architecture, à l’inverse, est constante. Un outil qui ne demande aucun geste nouveau ne dépend pas de la motivation de celui qui l’utilise : il fonctionne aussi bien le premier jour que le centième, pour l’enthousiaste comme pour le réticent, dans la journée calme comme dans la journée surchargée. C’est cette constance qui sépare un outil adopté durablement d’un outil abandonné après l’enthousiasme initial. La différence ne tient pas à la qualité de ce que l’outil produit, mais à ce qu’il exige pour qu’on y accède.

C’est pourquoi la question de l’onglet n’est pas une question d’ergonomie de surface, mais une question de catégorie. Un outil qui demande à l’organisation de venir à lui et un outil qui vient là où l’organisation travaille déjà ne sont pas deux variantes d’un même produit : ce sont deux espèces différentes, avec deux destins différents. L’un a un plafond d’adoption fixé par la patience de ses utilisateurs ; l’autre n’en a pas, parce qu’il ne demande aucune patience.

Ce ne sont pas deux variantes du même produit. Ce sont deux catégories différentes, et une seule passe l’échelle d’une organisation entière.