Architecture

Le plafond n’est pas technique

Tous les déploiements suivent la même courbe : montée rapide, puis stagnation. Le plafond n’est pas technique.

Tous les déploiements sérieux d’IA juridique connaissent la même courbe. Les premiers mois, l’usage progresse vite : les utilisateurs découvrent, les premières économies de temps sont visibles, les retours sont positifs. Puis, vers le sixième ou huitième mois, la courbe s’aplatit. L’usage ne s’effondre pas, mais il ne progresse plus. Les utilisateurs se servent de l’outil pour ce qu’ils maîtrisent, et reviennent à leurs méthodes pour le reste.

Cette stagnation est un phénomène de marché, pas un échec individuel. Elle se répète dans presque toutes les organisations équipées, avec une régularité qui exclut les explications particulières. Quand un même phénomène se reproduit partout, quels que soient l’outil, l’organisation, le secteur, c’est qu’il a une cause structurelle, et non une cause locale. Il mérite donc qu’on procède par élimination, méthodiquement, parce que la cause qu’on retient détermine la solution qu’on cherche, et qu’une mauvaise cause envoie chercher au mauvais endroit.

Un plateau qui se répète partout, quel que soit l’outil, n’a pas une cause locale. Il a une cause structurelle.

Éliminer les explications techniques, une à une

Commençons par l’explication la plus courante : la stagnation viendrait de la qualité des modèles. Si c’était le cas, elle se résoudrait avec les nouvelles versions, plus puissantes. Or les nouvelles versions arrivent, régulièrement, nettement meilleures, et la courbe reste plate. Le plafond ne bouge pas quand le modèle s’améliore, ce qui suffit à écarter l’hypothèse : si la cause était la performance du modèle, un meilleur modèle relèverait le plafond. Il ne le relève pas.

Deuxième explication : la stagnation viendrait d’un déficit de formation. Si c’était le cas, elle se résoudrait avec des programmes d’accompagnement. Or ces programmes existent dans les organisations sérieuses, souvent ambitieux, et la courbe reste plate. On peut former intensément les équipes et voir le plateau persister, ce qui écarte cette seconde hypothèse. Le problème n’est pas que les gens ne savent pas se servir de l’outil ; ils savent parfaitement, et c’est justement en connaissance de cause qu’ils cessent de l’étendre.

Troisième explication : la stagnation viendrait de l’interface, de l’ergonomie, du produit. Si c’était le cas, elle se résoudrait avec de meilleurs produits. Or les produits s’améliorent, deviennent plus fluides, plus agréables, et la courbe reste plate. Une à une, les explications faciles tombent, et elles tombent toutes pour la même raison : elles visent des causes techniques, alors que le plafond résiste à toutes les améliorations techniques. Quand on a éliminé chaque cause technique et que le plafond demeure, la conclusion s’impose : le plafond n’est pas technique.

Quand toutes les causes techniques sont éliminées et que le plafond demeure, c’est que le plafond n’est pas technique.

Ce que la stagnation traduit vraiment

Ce que la stagnation traduit est plus simple, et plus profond. Les usages faciles ont été absorbés. Dans les premiers mois, les utilisateurs ont porté l’IA sur tout ce qu’elle pouvait tenir sans difficulté : recherches ponctuelles, premiers jets, résumés, tâches périphériques. Ces usages-là sont maintenant acquis, et il ne reste, au-delà du plateau, que les usages difficiles, ceux qui demanderaient à l’IA de tenir ce que les outils actuels ne tiennent pas.

Pour aller plus loin, il faudrait en effet que l’IA s’intègre à des contextes que les outils actuels ne tiennent pas : des dossiers complexes en cours, des matières sensibles, des productions où la traçabilité est critique, des enchaînements où la cohérence entre versions compte. C’est précisément là que les utilisateurs se retirent. Le plateau n’est pas le signe qu’ils ont cessé de progresser ; c’est le signe qu’ils ont atteint la limite au-delà de laquelle l’outil, tel qu’il est, ne peut pas les suivre.

Et ils s’en retirent non par méfiance, mais par lucidité opérationnelle. Ils savent que l’outil ne tiendra pas ce contexte-là, alors ils ne l’y emmènent pas. Ce point mérite d’être souligné, car il inverse le discours habituel sur l’adoption. On présente souvent l’utilisateur qui se retire comme un frein, un retardataire à convaincre. C’est l’inverse : il a correctement évalué que l’outil ne tiendrait pas son dossier complexe, et il agit en professionnel prudent. Le plateau est fait de milliers de ces retraits lucides, non d’un manque d’enthousiasme.

Les utilisateurs n’abandonnent pas l’IA sur les sujets sérieux par peur. Ils l’abandonnent parce qu’ils ont raison.

Traiter un problème d’architecture comme tel

Cette relecture change la nature du problème, et donc la solution. Tant qu’on traite la stagnation comme un problème d’adhésion, on s’acharne sur la formation, la communication, la conduite du changement, c’est-à-dire sur des remèdes qui visent la volonté des utilisateurs. Mais la volonté n’est pas en cause : les utilisateurs voudraient étendre l’usage, ils ne le peuvent pas, parce que l’outil ne tient pas le contexte. Dès qu’on traite la stagnation comme un problème d’architecture, on cesse de vouloir convaincre les gens et on construit ce qui leur manque.

Ce qui manque n’est pas un meilleur outil, mais une couche au-dessus des outils qui rende possible ce qu’ils ne rendent pas possible séparément : continuité, mémoire, méthodologie, traçabilité, gouvernance. C’est cette couche qui permettrait à l’utilisateur d’emmener enfin l’IA sur son dossier complexe, parce qu’elle tiendrait, à sa place, le contexte que l’outil seul ne tient pas. Le déblocage ne viendra donc pas d’en bas, d’un modèle plus performant, mais d’au-dessus, d’une couche qui rend le contexte tenable.

Cette lecture a une conséquence pratique immédiate, et discriminante. Les organisations qui attendent que les modèles s’améliorent pour relancer l’adoption attendront longtemps, car ce n’est pas de là que viendra le déblocage : on l’a vu, le plafond ne bouge pas quand le modèle progresse. Celles qui construisent la couche d’orchestration ouvriront la suite sans attendre la prochaine version de quoi que ce soit. Face au même plateau, les unes patientent en vain, les autres agissent au bon endroit.

Attendre un meilleur modèle pour relever le plafond, c’est attendre à l’endroit où le déblocage ne viendra jamais.

Pourquoi le retrait est un signal, pas un frein

Il faut s’arrêter sur la nature de ce retrait, parce que la manière dont on l’interprète décide de tout ce qu’on va faire ensuite. Un utilisateur qui retire l’IA de ses dossiers sérieux émet un signal précieux : il indique exactement la frontière où l’outil cesse de tenir. Ce signal, correctement lu, est une carte du problème ; mal lu, il devient un prétexte à blâmer les équipes. La différence entre les deux lectures sépare les organisations qui progresseront de celles qui s’enliseront.

Lu comme un signal, le retrait dit où construire. Il désigne, dossier après dossier, les contextes que l’outil ne tient pas, et donc ce que la couche manquante devra tenir. Une organisation attentive à ce signal dispose d’une feuille de route gratuite, dessinée par les choix lucides de ses propres praticiens : là où ils n’emmènent pas l’IA, il y a exactement le travail que la couche devra rendre possible. Le retrait n’est pas un problème à corriger, c’est une information à exploiter.

Lu comme un frein, au contraire, le retrait envoie l’organisation dans la mauvaise direction. On le prend pour de la résistance, on répond par de la persuasion, on relance des formations, on multiplie les incitations, et rien ne bouge, parce qu’on traite un symptôme lucide comme s’il était une réticence. Pendant ce temps, la vraie cause, l’absence de couche, reste intacte, et le plateau avec elle. Confondre le signal avec un frein, c’est se condamner à s’acharner sur les personnes quand le problème est dans l’architecture.

Ce que serait la deuxième vague

Il vaut la peine de décrire ce que serait concrètement la suite, car elle ne ressemble pas à ce qu’on a connu. La première vague d’adoption était horizontale : beaucoup d’utilisateurs, des tâches simples, un usage large mais superficiel. La suivante sera verticale : les mêmes utilisateurs, mais sur leurs dossiers les plus complexes, les plus longs, les plus sensibles, ceux qu’aujourd’hui ils traitent encore entièrement à la main. Le gain unitaire y est bien supérieur, parce que c’est là que se concentre la valeur du travail juridique, et c’est précisément là que les outils actuels ne vont pas.

On comprend alors pourquoi la stagnation actuelle est trompeuse. Vue de loin, elle ressemble à un essoufflement, à une déception, au signe que l’IA juridique aurait atteint ses limites. Vue de près, c’est l’inverse : elle marque la fin de la phase facile et le seuil de la phase qui compte. Les organisations qui interprètent le plateau comme un plafond vont réduire leurs ambitions au mauvais moment ; celles qui l’interprètent comme un seuil architectural vont construire ce qui ouvre la suite. La même courbe plate mène à deux décisions opposées, selon qu’on la lit comme une fin ou comme un seuil.

C’est aussi pourquoi les indicateurs habituels d’adoption induisent en erreur. Mesurer le nombre d’utilisateurs actifs ou de requêtes par jour décrit la première vague, pas la seconde. Le bon indicateur n’est pas combien de personnes utilisent l’IA, mais sur quels dossiers elles acceptent de l’emmener. Tant que l’IA reste cantonnée aux tâches périphériques, l’adoption peut sembler large tout en restant superficielle. La profondeur d’usage, et non sa largeur, est le vrai signe que la couche manquante a été construite.

Le bon indicateur d’adoption n’est pas combien de personnes utilisent l’IA. C’est sur quels dossiers elles acceptent de l’emmener.

Un plafond qui ne se relève pas en attendant

Le plafond actuel n’est donc pas un plafond de capacité, mais un plafond d’architecture. Et un plafond d’architecture ne se relève pas en attendant le prochain modèle ; il se relève en construisant la couche qui manque. C’est une différence décisive, parce qu’elle sépare deux attitudes face au même plateau : l’attente d’un progrès qui ne viendra pas de là, et la construction de ce qui débloque réellement. Les organisations qui l’auront compris n’attendront pas ; elles bâtiront.

C’est exactement la couche que MAX a été conçu pour porter : une Legal Semantic Layer qui permet à l’IA d’opérer là où, aujourd’hui, les utilisateurs sérieux ne l’emmènent pas. Non pour ajouter une capacité aux outils, mais pour tenir, au-dessus d’eux, le contexte qui rend leurs capacités enfin utilisables sur le cœur du travail. C’est ce passage qui ouvre la deuxième vague d’adoption, celle où l’IA cesse d’être un accessoire des tâches faciles pour devenir un instrument du travail qui compte.

Il faut, pour finir, remettre la stagnation à sa vraie place. Elle n’est pas la preuve que l’IA juridique a échoué ; elle est la preuve qu’elle a épuisé ce que la première génération d’outils pouvait donner. Le plateau n’est pas un mur, c’est une marche : celle qui sépare l’usage superficiel de l’usage profond, et qu’on ne franchit pas en poussant les outils, mais en posant la couche au-dessus d’eux. Les organisations qui verront le plateau pour ce qu’il est, un seuil et non une fin, seront celles qui ouvriront la suite.

Le plateau n’est pas un mur, c’est une marche. On ne la franchit pas en poussant les outils, mais en posant la couche au-dessus d’eux.