Produit

Le choix de la primitive décide de tout

La primitive d’un produit, l’unité autour de laquelle tout s’organise, détermine ce qu’il pourra faire et ce qu’il ne pourra jamais faire. L’IA juridique a choisi le prompt. MAX a choisi le workflow.

Dans le développement d’un produit, un choix dit plus de choses sur ce qu’il deviendra que toutes les listes de fonctionnalités réunies : le choix de la primitive, c’est-à-dire de l’unité élémentaire autour de laquelle tout le reste s’organise. Cette primitive détermine ce que le produit pourra faire naturellement, et ce qu’il ne pourra jamais faire qu’au prix de contorsions. Et la primitive choisie par la quasi-totalité de l’IA juridique actuelle est le prompt.

Ce qu’est une primitive, et pourquoi elle décide de tout

Le mot primitive mérite qu’on s’y arrête, parce que c’est en comprenant ce qu’il recouvre qu’on saisit l’enjeu. La primitive d’un produit, c’est son unité de pensée, la brique élémentaire en fonction de laquelle tout le reste est conçu. Tout produit en a une, qu’elle soit choisie consciemment ou non, et ce choix est le plus structurant de tous parce qu’il précède et conditionne tous les autres. On peut changer presque tout dans un produit, ses fonctions, son interface, ses performances ; on ne change pas sa primitive sans le reconstruire, parce qu’elle est ce sur quoi tout le reste s’appuie.

C’est pourquoi le choix de la primitive ne se rattrape pas par l’ajout de fonctionnalités. Une fois la primitive posée, elle dessine un horizon : ce qui est dans son prolongement naturel se construit facilement, ce qui lui est étranger ne se construit qu’au prix de détours qui finissent par buter sur une limite. Deux produits qui partent de primitives différentes ne convergeront jamais vraiment, quel que soit le nombre de fonctions qu’on leur ajoute, parce qu’ils n’organisent pas le monde de la même façon. Le choix de la primitive, fait souvent tôt et sans qu’on en mesure la portée, décide donc de ce que le produit pourra devenir des années plus tard.

La primitive trompeuse

Le prompt est une primitive élégante : une question, une réponse, un cycle court qui se prête à l’expérimentation, à la démonstration, à l’itération rapide. C’est cette élégance qui explique son adoption massive : il est facile à comprendre, facile à montrer, facile à itérer. Mais il a une caractéristique structurelle qui en fait, pour le travail juridique, une primitive trompeuse : il suppose que l’utilisateur sait, à chaque interaction, formuler ce dont il a besoin. Le prompt est performant quand on peut bien poser sa question. Il devient inopérant quand la question fait elle-même partie du problème.

Or dans le travail juridique réel, la formulation est rarement le point de départ. Ce qui se présente d’abord, ce n’est pas une question bien posée, c’est un workflow : un ensemble d’étapes à enchaîner pour produire un livrable, avec des dépendances entre elles, des contraintes de temps, des règles de validation, des contributions humaines à différents moments. La question, dans un workflow, n’est qu’un moment local. Le vrai sujet est l’enchaînement, et c’est précisément cet enchaînement que les outils centrés sur le prompt ne prennent pas en charge.

Cette limite du prompt n’est pas un défaut de qualité qu’un meilleur modèle viendrait corriger. Elle tient à ce que le prompt prend en charge, et à ce qu’il laisse dehors. Il prend en charge la traduction d’une intention claire en réponse ; il laisse dehors tout ce qui précède l’intention claire, c’est-à-dire l’essentiel du travail juridique : décider quoi faire, dans quel ordre, sous quelles contraintes, en mobilisant qui et quoi à chaque étape. Un modèle plus puissant répondra mieux à la question posée, mais il ne posera pas la question à votre place, et il n’enchaînera pas les étapes que la question n’a pas nommées.

Un meilleur modèle répond mieux à la question. Il ne décide pas, à votre place, quelle est la prochaine étape.

Il faut bien voir que ce n’est pas une nuance, mais une frontière. Tant que le besoin se laisse formuler en une question, le prompt suffit, et il est même excellent. Dès que le besoin est un processus, dont la formulation se découvre en avançant plutôt qu’elle ne précède l’action, le prompt cesse d’être l’outil adéquat, non parce qu’il répond mal, mais parce que la chose à faire n’est pas de répondre. C’est là que la plupart des outils actuels rencontrent leur plafond, et ce plafond n’est pas dans le modèle, il est dans la primitive.

Le prompt suppose qu’on sait poser sa question. Le travail juridique commence souvent là où on ne le sait pas encore.

Pourquoi le marché a choisi le prompt

Si le prompt est une primitive aussi mal ajustée au travail juridique, on peut se demander pourquoi il s’est imposé si massivement. La réponse n’est pas qu’il a été choisi pour ses mérites sur le travail réel, mais qu’il a été choisi pour ses mérites sur autre chose : la facilité de construction et la force de démonstration. Bâtir un outil autour du prompt est rapide ; le montrer est spectaculaire ; l’itérer est aisé. Pour un éditeur qui doit livrer vite et convaincre en réunion, le prompt est la primitive de moindre résistance.

Ce choix par défaut a une conséquence que peu mesurent au moment où ils le font : il enferme le produit dans une catégorie avant même qu’on ait réfléchi à ce qu’il devrait faire. On adopte le prompt parce que c’est le standard, parce que c’est ce que font les autres, parce que c’est ce que les démonstrations attendent, et l’on hérite, sans l’avoir voulu, de toutes les limites que cette primitive impose. Le marché n’a pas tant choisi le prompt qu’il s’y est laissé glisser, et c’est pourquoi il bute aujourd’hui, collectivement, sur le même plafond.

Faire un autre choix demande donc d’aller à contre-courant, et d’en accepter le coût. Choisir le workflow comme primitive, c’est renoncer à la facilité de construction du prompt, accepter des démonstrations moins immédiates, investir dans une ingénierie de coordination que le prompt n’exige pas. C’est un choix plus lent et plus coûteux à l’amorçage, qui ne se justifie que si l’on vise le travail réel plutôt que l’effet de démonstration. Mais c’est précisément parce qu’il est plus coûteux qu’il est défendable : ce que l’on construit sur la bonne primitive, les autres ne l’obtiendront pas en améliorant la mauvaise.

Changer de primitive change le produit

C’est ce constat qui a déterminé l’un des choix de conception les plus structurants de MAX : la primitive autour de laquelle tout s’organise n’est pas le prompt, c’est le workflow. Une matière déclenche un workflow. Un workflow contient des étapes, qui peuvent appeler des modèles, des sources, des collaborateurs humains, des règles de validation, des permissions différentes. La couche sémantique sait coordonner cet enchaînement, tenir le contexte d’une étape à l’autre, appliquer les règles entre les étapes, produire les traces correspondantes. Le prompt existe encore, il reste utile à certains moments, mais comme composant local, jamais comme primitive structurante.

Ce choix change profondément ce que l’outil peut faire, et il faut bien voir qu’il ne s’agit pas d’une amélioration mais d’un changement de catégorie. Une IA centrée sur le prompt restera toujours, structurellement, un outil d’aide à des tâches ponctuelles : on peut l’améliorer indéfiniment, elle ne deviendra pas, par accumulation, capable de porter un processus. Une IA centrée sur le workflow peut, sans changement d’architecture, prendre en charge des processus complexes, longs, multi-étapes, multi-acteurs, avec une cohérence opérationnelle préservée d’un bout à l’autre. Ce sont deux familles d’objets, pas deux niveaux de qualité.

On n’améliore pas un outil de prompt jusqu’à en faire un outil de workflow. On change de primitive, donc de catégorie.

On peut illustrer la portée de ce choix par un exemple. Préparer un avis sur une opération n’est pas une question, c’est une suite : cadrer la demande, identifier les sources pertinentes, vérifier leur actualité, confronter les positions, rédiger une première version, la soumettre à une relecture, intégrer les retours, faire valider par un senior, archiver avec la trace. Un outil de prompt peut aider sur chacune de ces étapes prise isolément, à condition qu’on la lui formule. Un outil de workflow connaît la suite, sait où l’on en est, prépare l’étape suivante, applique les règles entre les étapes, et n’oblige pas l’utilisateur à rejouer le chef d’orchestre à chaque transition.

Le workflow organise le jugement humain au lieu de l’écarter

Il faut ajouter que ce choix n’oppose pas le workflow au jugement humain, il l’organise. Dans une couche centrée workflow, les points où une décision humaine est requise ne sont pas des interruptions subies, ce sont des étapes prévues, situées, tracées. Le workflow ne retire pas la main à l’avocat ; il lui rend la main au bon moment, en ayant préparé tout ce qui pouvait l’être avant. C’est l’inverse d’une automatisation aveugle : une orchestration qui réserve à l’humain ce qui lui revient et prend en charge le reste.

Cette distinction est importante, parce qu’on objecte souvent que structurer le travail en workflow reviendrait à le rigidifier, à enlever à l’avocat la souplesse de son jugement. C’est l’inverse qui se produit. Un travail non structuré ne laisse pas plus de place au jugement ; il le noie sous la charge de tout tenir soi-même, de se rappeler chaque étape, de ne rien oublier. En portant la coordination, le workflow libère l’attention du praticien pour ce qui requiert vraiment son jugement, au lieu de la disperser sur la mécanique de l’enchaînement. La structure ne s’oppose pas à la liberté de juger ; elle en crée les conditions.

Le workflow ne retire pas la main à l’avocat. Il la lui rend au bon moment, le reste étant déjà prêt.

Construire MAX autour des workflows plutôt que des prompts n’a pas été un choix de marketing, mais le reflet d’une lecture du métier : le travail juridique se fait en enchaînements, pas en interactions isolées. Un produit qui ne respecte pas cette réalité ne peut pas servir durablement le métier, quelle que soit la performance de ses composants pris séparément. On peut avoir le meilleur modèle du monde et rester inutile sur un dossier réel, faute de savoir enchaîner les étapes qui mènent au livrable.

C’est sur cette primitive, et non sur une fonctionnalité visible, que se construit la différence entre une IA juridique de surface et une IA juridique structurelle. La première brille sur la question isolée ; la seconde tient le processus entier. Et c’est le processus, pas la question, qui définit le travail juridique.

Une IA de surface répond à la question. Une IA structurelle conduit le processus jusqu’au livrable.