Rendez le processus observable avant d'ajouter un LLM

Le pire projet IA que j'ai vu de près n'a pas échoué à cause du modèle. Le modèle allait très bien. Il a échoué parce que personne ne pouvait dire, précisément, ce que faisaient les humains qu'il remplaçait. L'équipe a automatisé sa meilleure supposition du processus. Cette supposition était fausse sur une douzaine de petits points, et chacun de ces points est devenu un bug silencieux à la voix assurée.

Depuis, j'applique une règle avant de mettre un LLM à proximité d'un processus métier : rendre d'abord le processus observable.

Ce que "observable" veut dire ici

Pas des dashboards. Pas des OKR. Observable au sens de l'ingénierie : pour n'importe quelle exécution du processus, vous pouvez répondre à trois questions après coup.

1. Qu'est-ce qui est entré ? Les inputs exacts : le document, l'email, le formulaire, la donnée telle qu'elle est réellement arrivée, pas telle que la spec dit qu'elle devrait arriver.
2. Qu'est-ce qui est sorti ? La décision, la classification, le brouillon, le routing, capturé sous une forme structurée.
3. Que s'est-il passé entre les deux ? Les étapes, les recherches, les exceptions, les cas où un humain a dit "celui-là est bizarre, je vais le traiter autrement."

La plupart des processus métier échouent spectaculairement à ce test. Le savoir vit dans la tête de trois personnes, les inputs arrivent par email et disparaissent dans des dossiers, et les exceptions (là où réside toute la vraie complexité) sont invisibles par définition, parce que traiter les exceptions discrètement, c'est précisément ce que les gens expérimentés savent faire.

Si vous ne pouvez pas répondre à ces trois questions pour le processus manuel, vous n'avez aucune baseline. Et sans baseline, votre projet LLM n'a aucune définition de ce que signifie "ça marche".

Le piège de la demo impressionnante

Voici comment ça se passe en général. Quelqu'un construit un prototype : on colle un contrat, le LLM extrait les clauses clés, tout le monde est ébloui, le projet est validé. L'input de la demo était un PDF propre choisi par la personne qui construisait la demo.

Les inputs de production sont des fax scannés, des contrats en deux langues, des documents où la page 3 manque, et un type de clause que l'équipe voit deux fois par an mais qui porte tout le risque juridique. La demo n'a jamais rencontré ces cas parce que personne n'avait jamais écrit noir sur blanc qu'ils existaient.

J'ai travaillé sur un produit d'IA juridique où l'artefact le plus précieux au départ n'était ni un prompt ni un pipeline. C'était un corpus : de vrais inputs, collectés sur plusieurs semaines, avec les outputs que des humains expérimentés produisaient pour eux et des notes sur le pourquoi. Fastidieux à assembler. C'est aussi ce qui a transformé "l'IA a l'air bonne" en "l'IA correspond à l'output des experts sur 87% de ce type de clause précis, et voici les 13% qu'elle rate."

Vous ne pouvez pas construire ce corpus rétroactivement si le processus n'a jamais été instrumenté. La donnée a disparu.

Instrumenter d'abord, automatiser ensuite

Le playbook pratique que j'utilise désormais avec les équipes, dans l'ordre :

Etape 1 : capturer les inputs et les outputs, ne rien changer d'autre. Ajoutez la plomberie minimale pour que chaque exécution du processus manuel laisse une trace : artefact d'entrée stocké, décision de sortie enregistrée, horodatage, qui l'a traité. Pas encore d'IA. Cette étape est peu coûteuse et politiquement facile, parce que le workflow de personne ne change.

Etape 2 : laisser les traces s'accumuler, puis les lire. Quelques semaines de trafic réel vous apprennent plus que n'importe quel atelier. Vous découvrez la distribution réelle des cas : 60% triviaux, 30% standards, 10% bizarres. Vous découvrez que deux experts traitent le même cas différemment, ce qui veut dire que le "processus" est en réalité deux processus, et personne ne le savait.

Etape 3 : automatiser d'abord les 60% ennuyeux, avec les traces comme test set. Le LLM a maintenant un vrai benchmark : produit-il ce que les humains produisaient, sur de vrais cas historiques ? Vous pouvez mesurer avant de livrer. Et comme le pipeline enregistre déjà tout, chaque run de production étend le dataset.

Etape 4 : router, ne pas remplacer. Les 10% de cas bizarres restent aux humains, et le système doit connaître ses propres limites suffisamment bien pour les router. Cette logique de routing n'est possible que parce que vous avez observé le processus assez longtemps pour caractériser ce à quoi ressemble "bizarre".

L'objection : "c'est lent"

C'est plus lent à démarrer. C'est radicalement plus rapide à terminer. Le chemin instrumenté prend quelques semaines supplémentaires au départ et vous donne un système mesurable, avec un test set de régression construit à partir du réel. Le chemin demo-en-premier livre en deux semaines, puis passe six mois dans une boucle de rapports de bugs anecdotiques ("ça a échoué sur ce contrat, tu peux corriger ?") sans aucun moyen de savoir si une correction en a cassé une autre.

J'ai fait les deux. Le second ne fait que donner l'impression d'être rapide.

Il y a aussi un bénéfice que personne n'attend : parfois la phase d'observation tue le projet IA, et de la meilleure des façons. Vous instrumentez le processus, vous regardez les traces, et vous découvrez que le goulot d'étranglement n'est pas du tout l'étape cognitive. C'est que les inputs restent dans une file pendant trois jours. Une règle de routing règle le problème. Aucun LLM nécessaire. C'est une réussite, même si ça fait une moins bonne conférence.

Ce que je dirais à moi-même au départ

Un LLM amplifie la clarté ou la confusion que vous lui donnez. Un processus que vous pouvez voir est un processus que vous pouvez automatiser, mesurer et améliorer. Un processus que vous ne pouvez pas voir est une machine à sous avec des étapes en plus.

Alors avant le modèle, le prompt, le débat sur le framework : stockez les inputs, enregistrez les outputs, observez pendant quelques semaines. C'est un travail sans gloire. C'est aussi ce qui fait la différence entre une fonctionnalité IA et un passif IA.