Produit

Répondre n’est pas exécuter

Le marché propose des outils qui répondent. Les organisations, en mûrissant, demandent des outils qui exécutent. Entre les deux, il y a un fossé que la performance du modèle ne comble pas.

Une bonne part de la frustration que les organisations juridiques expriment face à l’IA tient à un malentendu sur la nature de l’aide qu’elles attendent. Le marché propose massivement des outils qui répondent ; les organisations, à mesure qu’elles mûrissent dans leur usage, demandent de plus en plus des outils qui exécutent. La frustration ne vient pas de réponses de mauvaise qualité, qui sont souvent excellentes, mais d’un décalage entre ce qui est livré, une réponse, et ce qui est attendu, un travail conduit à son terme.

Répondre, c’est traiter une demande ponctuelle et la rendre. Exécuter, c’est prendre en charge une fonction dans un processus et la conduire à son terme. Cet article ne porte pas sur ce qui distingue, en théorie, ces deux régimes ; il porte sur ce que veut dire, très concrètement, exécuter, c’est-à-dire sur tout ce qui se passe une fois la réponse obtenue, et que la plupart des outils laissent entièrement à la charge de l’humain.

Ce qui commence après la bonne réponse

Pour comprendre l’écart, le mieux est de partir du moment où un outil qui répond a fait tout son travail : il a rendu une bonne réponse. L’analyse est juste, le raisonnement est solide, la formulation est correcte. Et c’est précisément là, au moment où l’outil considère sa tâche accomplie, que le travail réel commence pour le professionnel. Car une réponse, si bonne soit-elle, n’est pas un livrable. Elle est une matière première qu’il faut encore transformer.

Déroulons ce qui reste à faire, parce que c’est dans ce déroulé que se loge tout le sujet. La réponse doit être replacée dans le bon document, au bon endroit, dans le bon format. Elle doit être confrontée aux positions antérieures du cabinet, pour vérifier qu’elle ne les contredit pas. Elle doit être adaptée au client précis, à son histoire, à ses préférences. Elle doit passer par une relecture, intégrer les retours, être validée par un senior. Elle doit être archivée, tracée, reliée au dossier dont elle fait désormais partie. Et chacune de ces étapes peut, à son tour, déclencher une question nouvelle, donc une nouvelle réponse, donc un nouveau cycle de transformation.

Ce travail d’après-réponse n’est ni accessoire ni secondaire : il est l’essentiel de l’effort réel. La réponse elle-même, le moment où le modèle produit son analyse, représente une fraction du temps total ; tout le reste est dans la transformation de cette analyse en quelque chose d’utilisable, de validé, d’intégré. Un outil qui s’arrête à la réponse a donc fait la part la plus visible et la plus petite du travail, et il a laissé la part la plus lourde, et la moins visible en démonstration, à l’humain.

La réponse, c’est cinq pour cent du travail. Les quatre-vingt-quinze pour cent qui suivent, c’est ce que l’exécution prend en charge.

Le travail invisible que porte l’utilisateur

Tant que l’outil s’arrête à la réponse, ce travail d’après-réponse ne disparaît pas : il est simplement reporté sur l’utilisateur, qui devient l’exécutant que l’outil n’est pas. C’est lui qui copie la réponse dans le document, qui vérifie la cohérence avec les dossiers voisins, qui se souvient qu’une position contraire avait été prise il y a six mois, qui pense à faire valider, qui n’oublie pas d’archiver. Chacun de ces gestes lui incombe parce que l’outil les ignore, et leur accumulation finit par peser plus lourd que le gain apporté par la réponse elle-même.

Ce report a un coût qui ne se voit nulle part, et c’est ce qui le rend si facile à ignorer au moment de l’achat. En démonstration, on ne voit que la réponse, brillante, immédiate ; on ne voit pas l’heure que l’utilisateur passera ensuite à la transformer en livrable, parce que cette heure se déroule après la démonstration, dans le travail réel. L’outil paraît donc faire l’essentiel alors qu’il fait le plus facile, et le coût de tout ce qu’il ne fait pas reste invisible jusqu’au déploiement, où il réapparaît sous la forme d’une déception : l’IA fait gagner moins de temps qu’espéré, parce qu’elle ne prend en charge que la pointe émergée du travail.

Il faut bien voir que ce travail reporté n’est pas du travail juridique au sens noble : ce n’est pas du raisonnement, ce n’est pas du jugement, c’est de la manutention. Replacer une réponse au bon endroit, vérifier une cohérence, penser à archiver, ce sont des gestes nécessaires mais sans valeur ajoutée intellectuelle, exactement le genre de tâches qu’une infrastructure devrait absorber pour rendre le praticien à son métier. Laisser ces gestes à l’humain, c’est lui faire payer en attention ce qu’une exécution bien conçue lui épargnerait.

Exécuter, geste par geste

Que signifie alors, concrètement, prendre en charge ces quatre-vingt-quinze pour cent ? Cela ne signifie pas produire une meilleure réponse, ni en produire plusieurs ; cela signifie conduire le travail à travers ses étapes successives. Un outil qui exécute ne rend pas une réponse puis attend la question suivante : il avance. Il sait quelle est l’étape en cours et quelle est la suivante, il prépare ce qui peut l’être, il applique les règles qui valent entre les étapes, il déclenche les contributions humaines au bon moment, il conserve la trace de ce qui a été fait. Là où l’outil qui répond rend la main après chaque échange, l’outil qui exécute garde le fil et le poursuit.

Il faut lever ici un malentendu, car il revient toujours : exécuter ne signifie pas se passer de l’humain. L’exécution dont il s’agit n’est jamais autonome, elle est gouvernée. Entre les étapes qu’elle prend en charge, elle réserve des points précis où une décision humaine est requise, demandée, tracée. Exécuter, ce n’est donc pas remplacer le jugement par de l’automatisme ; c’est avancer entre les moments où le jugement est nécessaire, en préparant chacun de ces moments pour que l’humain y arrive avec tout ce qu’il lui faut, et seulement ce qu’il lui faut.

Exécuter n’est pas se passer de l’humain. C’est avancer entre les points où l’humain décide.

Cette manière de placer l’humain change la qualité de son intervention. Quand il n’y a pas d’exécution, l’humain est sollicité de partout, tout le temps, pour des décisions grandes et petites mêlées, et son attention se disperse sur la mécanique autant que sur le fond. Quand l’exécution porte l’enchaînement, l’humain n’est plus sollicité qu’aux points qui requièrent vraiment son jugement, et il y arrive avec un contexte préparé plutôt qu’avec une page blanche. Il décide mieux parce qu’il décide moins souvent et sur des choses qui en valent la peine. L’exécution ne dévalue pas le jugement humain ; elle le concentre là où il a le plus de valeur.

On peut donner à cette idée la précision d’un exemple. Préparer un avis sur une opération suppose de cadrer la demande, de réunir les sources, de vérifier leur actualité, de confronter les positions, de rédiger, de faire relire, d’intégrer les retours, de faire valider, d’archiver. Un outil qui répond peut produire une bonne analyse à n’importe laquelle de ces étapes, à condition qu’on la lui demande. Un outil qui exécute fait passer le travail d’une étape à la suivante : il sait que la rédaction vient après la confrontation des positions, que la validation vient après la relecture, et il prépare chaque transition au lieu de la laisser à la charge de l’utilisateur. Le professionnel n’a plus à rejouer le chef d’orchestre à chaque mesure ; il intervient là où son jugement compte, le reste étant déjà tenu.

Pourquoi l’exécution coûte si cher à construire

Cette différence se traduit dans des choix d’ingénierie très concrets, et coûteux. Un outil qui répond peut se contenter d’une interface où l’on pose des questions. Un outil qui exécute doit suivre des états, savoir où en est chaque travail ; gérer des permissions, savoir qui peut faire quoi à quelle étape ; déclencher des étapes, enchaîner sans intervention quand l’intervention n’est pas requise ; intégrer des contributions humaines, les situer, les tracer ; produire des artefacts qui persistent. Les deux outils s’appuient peut-être sur les mêmes modèles, mais ce qu’ils construisent au-dessus n’a ni la même ambition ni le même coût.

C’est précisément ce coût qui explique pourquoi si peu d’éditeurs ont pris ce chemin. Construire un assistant qui répond est rapide et démontrable ; construire une couche qui exécute suppose une infrastructure d’orchestration et de gouvernance qu’un assistant n’a jamais besoin de porter. L’investissement est sans commune mesure, et il ne se voit pas en démonstration, où un assistant brillant fait illusion. Mais c’est cet investissement, et lui seul, qui sépare un outil d’usage individuel d’une infrastructure capable de porter le travail d’une organisation.

Le marché va découvrir que l’IA qui répond bien a un plafond. La prochaine vague viendra de l’IA qui exécute.

C’est cette ambition d’exécution, et non la recherche de la réponse parfaite, qui structure la Legal Semantic Layer de MAX. Parce que le travail juridique réel ne consiste pas à obtenir de bonnes réponses, mais à conduire des dossiers jusqu’à des livrables, à travers des dizaines d’étapes dont la réponse n’est que la première. Une réponse de plus ne change pas la nature d’un métier ; une exécution gouvernée, conduite d’un bout à l’autre, si.

C’est dans cette direction que se construit le travail juridique réellement assisté par l’IA, et nulle part ailleurs.