Architecture

Le test qui sépare la démo de l’infrastructure

Il y a un test simple pour savoir si un outil d’IA est une infrastructure ou un démonstrateur. Il n’est pas dans la démo. Il est dans ce qui se passe quand on en sort.

Il existe un test simple, et étonnamment fiable, pour évaluer si un outil d’IA est une infrastructure ou un démonstrateur. Le test n’est pas dans la qualité de la démonstration, qui ne prouve presque rien, car une démonstration est par nature un cadre choisi, conçu pour mettre l’outil en valeur, avec les bonnes questions, le bon corpus, les bons exemples. Tout outil, même fragile, impressionne dans le cadre qu’il a lui-même dessiné. C’est une scène, et sur une scène, tout est réglé pour que rien ne tombe. Le test commence là où la démonstration s’arrête : dans ce qui se passe quand on sort du cadre choisi, c’est-à-dire dans les conditions où le travail réel a lieu.

Il faut prendre la mesure de ce qu’est, vraiment, une démonstration. Elle n’est pas une tromperie ; elle est une sélection. On y montre l’outil dans les conditions où il réussit, sur les cas qu’il traite bien, avec un corpus dont on connaît la forme. Rien de tout cela n’est malhonnête, mais rien de tout cela ne ressemble à la réalité d’un déploiement, où les cas arrivent dans le désordre, où le corpus est vaste et hétérogène, où les utilisateurs sont pressés et les questions mal posées. Juger un outil sur sa démonstration, c’est juger un acteur sur une réplique apprise : on n’apprend rien de sa capacité à improviser quand le texte lui échappe.

On peut formuler le test d’une phrase. Ne demandez pas à un outil ce qu’il sait faire ; demandez-lui ce qui se passe quand son meilleur modèle est retiré, quand la session précédente est oubliée, quand le dossier reprend trois semaines plus tard, quand un autre praticien continue le travail, quand les permissions changent en cours de route. Les réponses à ces questions, et non la brillance de la démo, disent de quelle nature est l’outil. Car ce sont ces situations, et non les questions bien posées d’une présentation, qui composent la journée ordinaire d’une organisation.

Un démonstrateur impressionne dans le cadre choisi. Une infrastructure tient hors de ce cadre.

On peut même renverser le test pour le rendre plus tranchant encore. Plutôt que d’éprouver l’outil sur ses points forts, éprouvez-le sur ses points de rupture. Que devient le contexte quand la conversation se ferme ? Où va la mémoire quand le fournisseur de modèle change ? Qui se souvient de la décision prise le mois dernier quand c’est un collègue qui rouvre le dossier ? Un démonstrateur répond à ces questions par un silence gêné, ou par un « il faudrait reconfigurer ». Une infrastructure y répond par son fonctionnement normal, parce qu’elle a été conçue pour ces situations, et non contre elles. La différence n’est pas que l’une gère mieux ces cas : c’est que l’une les a prévus comme le cœur du problème, et l’autre comme des exceptions.

Cette opposition entre le cœur et l’exception est plus profonde qu’il n’y paraît. Un outil pensé comme démonstrateur traite la continuité, la mémoire, le partage comme des cas particuliers à gérer après coup, une fois la fonction principale assurée. Un outil pensé comme infrastructure les place au centre dès la conception, parce qu’il sait que c’est là que se joue la valeur réelle. Le premier ajoute la continuité comme une option ; le second est bâti autour d’elle. Et cette différence d’ordre des priorités, invisible dans une démonstration, détermine tout le comportement de l’outil une fois déployé.

Cette distinction n’est pas une nuance de produit, c’est une frontière de catégorie. Et la majorité des outils d’IA juridique d’aujourd’hui se trouvent, malgré la qualité réelle de leurs réponses, du côté du démonstrateur. Non par défaut de sérieux, mais par défaut de conception : ils ont été pensés pour bien répondre, pas pour tenir l’opérationnel. Or tenir l’opérationnel n’est pas une version améliorée de bien répondre. C’est autre chose, et cette autre chose ne s’obtient pas en perfectionnant la réponse, mais en construisant ce qui l’entoure et la fait durer.

Car tenir l’opérationnel, c’est tenir plusieurs choses à la fois. Tenir un contexte qui ne disparaît pas entre deux sessions. Tenir une mémoire qui ne dépend pas du modèle interrogé. Tenir des permissions qui restent valides quand les personnes changent. Tenir une cohérence entre des décisions prises à des semaines d’intervalle. Tenir une traçabilité qui survit aux changements d’outils. Chacune de ces exigences, prise isolément, est à la portée d’un bon produit. C’est leur conjonction, dans la durée, qui fait la difficulté, et c’est cette conjonction qu’aucune démo ne met jamais à l’épreuve.

Une fonctionnalité marche dans le cadre prévu par le concepteur. Une infrastructure tient même quand on en sort.

Cette exigence de tenir plusieurs choses ensemble n’est pas une difficulté technique de plus, à ranger parmi d’autres. Elle est la difficulté propre de l’opérationnel, celle qui le définit. Un assistant n’a jamais à la rencontrer, parce qu’il vit dans l’instant : il répond, puis l’instant se referme, et rien ne lui survit qu’il faudrait articuler avec autre chose. Une infrastructure, elle, ne connaît que des instants reliés : chaque réponse s’inscrit dans une suite, chaque décision dans un historique, chaque accès dans un cadre de permissions. C’est cette mise en relation permanente, et non la réponse elle-même, qui constitue son travail réel et qui la rend coûteuse à construire.

Il faut insister sur ce mot, simultanément, car c’est lui qui fait toute la difficulté, et c’est lui que les démonstrations escamotent. Tenir le contexte, ou la mémoire, ou les permissions, pris un à un, est un problème soluble, et beaucoup d’outils en résolvent un brillamment. Les tenir tous ensemble, en même temps, sur la durée d’un dossier réel, est un problème d’une autre échelle, parce que chaque exigence interagit avec les autres et qu’aucune ne peut être traitée dans son coin. La mémoire dépend des permissions, les permissions dépendent du contexte, le contexte dépend de la trace : on ne peut pas en isoler une sans rompre les autres. C’est précisément cette simultanéité que démontre rarement une démo, et que révèle toujours un déploiement.

On peut donner à cette idée une forme presque expérimentale. Prenez un outil qui réussit chacune de ces épreuves séparément, en démonstration : il tient le contexte quand on le lui demande, il retrouve une décision quand on l’interroge, il respecte une permission quand on la teste. Mettez-le maintenant en situation réelle, où il faut tenir les trois en même temps, sur un dossier qui dure, entre plusieurs mains. C’est là, et seulement là, qu’on voit si les capacités étaient des fonctions juxtaposées ou les facettes d’un même système. Un assemblage de bonnes fonctions se disloque sous la simultanéité ; une infrastructure la traverse sans y penser, parce qu’elle a été conçue d’un seul tenant.

Les outils qui présentent telle ou telle de ces capacités isolément ne tiennent pas l’opérationnel : ils tiennent une fonctionnalité. Et la différence, invisible en pilote, devient flagrante à l’usage. En pilote, le corpus est petit, les utilisateurs sont attentifs, les cas sont choisis, et la fonctionnalité suffit à faire illusion. Au déploiement, le corpus enfle, les utilisateurs sont pressés, les cas sont quelconques, et l’outil qui ne tenait qu’une fonctionnalité cède sur tout le reste. Ce qui brillait dans la démo devient le point précis où le système lâche, et la promesse qui avait emporté la décision se retourne en déception.

Tenir une de ces choses, c’est une fonctionnalité. Les tenir toutes ensemble, dans la durée, c’est une infrastructure.

Il y a, dans cette ligne de partage, quelque chose de rassurant pour qui doit choisir. Elle ne demande pas d’expertise technique pour être appliquée ; elle demande seulement de poser les bonnes questions et d’écouter la nature des réponses. On n’a pas besoin de comprendre comment un système est construit pour lui demander ce qu’il advient d’un dossier laissé trois semaines, repris par quelqu’un d’autre, sous un modèle différent. La réponse, ou l’embarras qu’elle suscite, en dit plus long que n’importe quelle fiche technique. Le test est à la portée de l’acheteur, précisément parce qu’il porte sur des situations qu’il connaît mieux que personne : les siennes.

Ce constat a une conséquence pratique pour qui doit choisir un outil, et elle inverse la manière habituelle d’évaluer. La bonne évaluation ne consiste pas à organiser une belle démonstration et à juger de la qualité des réponses, parce que c’est précisément ce que tout outil réussit. Elle consiste à fabriquer, délibérément, les conditions du déploiement réel : un corpus large et désordonné, des reprises à distance, des passages de relais entre plusieurs personnes, des changements de contexte en cours de route. Un outil qui tient dans ces conditions inconfortables est une infrastructure ; un outil qui n’y tient que dans le cadre soigné de la démonstration est un démonstrateur, quelle que soit la qualité de ce qu’il montre.

Le marché va se trier sur ce test, et le tri a déjà commencé. Les outils qui restent dans le régime du démonstrateur continueront de séduire en pilote et de décevoir au déploiement, et l’on attribuera leur échec à l’adoption, ou à la maturité de l’IA, alors qu’il tient à leur conception. Les architectures pensées dès l’origine pour tenir l’opérationnel, elles, franchiront la barre du déploiement parce qu’elles ont été bâties pour ce qui se passe quand on sort du cadre. Et ce tri, une fois engagé, ne se renversera pas, parce qu’on ne transforme pas un démonstrateur en infrastructure par une mise à jour : il faudrait le reconstruire.

C’est sur ce test, et non sur la qualité d’une démonstration, que MAX a été conçu pour être évalué. La Legal Semantic Layer ne cherche pas à mieux répondre dans un cadre choisi ; elle cherche à tenir, simultanément et dans la durée, le contexte, la mémoire, les permissions et la cohérence d’un dossier réel. Parce que la seule question qui sépare un produit d’une infrastructure n’est pas ce qu’il montre dans sa démo. C’est ce qui reste quand la démo est finie.