Industrialiser un agent IA : ce qui change par rapport à un pipeline

Construire une démonstration d'IA générative convaincante prend quelques jours. Cette facilité crée une attente que la mise en service met des mois à satisfaire, et l'écart surprend souvent les équipes qui financent le projet.

La bonne nouvelle, c'est que les difficultés ne sont pas nouvelles. Ce sont celles d'un pipeline de données : qualité des sources, fraîcheur, contrôles, traçabilité, supervision. Le modèle est la partie la plus visible, et rarement celle qui pose problème.

Ce qu'on fait par défaut : un agent qui fait tout

La tentation est de confier l'ensemble à un appel unique : classification, analyse, décision, rédaction de la réponse. Ça fonctionne, et la démonstration est impressionnante.

Le problème apparaît à la première sortie médiocre. Impossible de savoir quelle partie a échoué. On modifie un prompt de deux pages en espérant que ça aille mieux, sans rien pouvoir mesurer.

Un agent qui fait sept choses est impossible à déboguer. Sept agents qui font une chose chacun se corrigent un par un.

Sur le système multi-agents que j'ai conçu pour le traitement de la voix du client, c'est la décision qui a tout structuré : chaque étape a son agent, avec un périmètre étroit et une sortie définie. Un agent qui ne fait qu'une chose peut être évalué sur cette chose, corrigé sans effet de bord, et remplacé si un meilleur modèle arrive.

Traiter les sorties du modèle comme des données douteuses

C'est le réflexe à importer directement du data engineering. Une sortie de modèle n'est pas plus fiable qu'un fichier déposé par un système tiers : elle se contrôle avant d'être intégrée.

• Le format est-il celui attendu ?
• Les valeurs appartiennent-elles à un référentiel connu ?
• Les sorties sont-elles cohérentes entre elles ?

Une sortie qui échoue est isolée, pas silencieusement absorbée par la suite du pipeline.

Parce que le risque n'est pas l'erreur visible : un système qui répond manifestement n'importe quoi cesse vite d'être utilisé. Le risque, c'est la réponse plausible, bien formulée, et fausse.

« Ça marche bien » n'est pas une évaluation

Sans jeu de questions de référence, toute modification devient un pari : on change une instruction, le résultat semble meilleur sur les deux exemples qu'on regarde, et on ignore ce qu'on a dégradé ailleurs.

Le minimum utile est une liste de cas représentatifs avec, pour chacun, ce qu'une bonne réponse doit contenir. Cela permet aussi de séparer deux causes très différentes, qui appellent des corrections opposées.

Sans mesure séparée, on optimise le prompt alors que le problème est dans le découpage, ou l'inverse.

La base documentaire vit

Une démonstration travaille sur un corpus figé. En service réel, des documents arrivent, sont modifiés, sont retirés. Chaque changement doit se répercuter, sinon le système répond à partir de versions périmées, avec la même assurance.

On retrouve exactement les problématiques d'un pipeline : détecter les nouveautés, mettre à jour sans tout reconstruire, supprimer réellement ce qui a été retiré, et surveiller que tout cela s'est bien passé. Un index non rafraîchi depuis trois jours est l'équivalent d'un traitement qui n'a pas démarré.

Décider ce qui se passe quand le système ne sait pas

Par défaut, un modèle répond quand même, à partir de ses connaissances générales. Dans un contexte documentaire, c'est le pire comportement possible : l'utilisateur croit lire une réponse fondée sur ses documents.

Il faut donc trancher explicitement : un seuil de pertinence en dessous duquel le système répond qu'il n'a pas trouvé, et une formulation claire de ce message. « Je n'ai pas d'élément sur ce point dans les documents » vaut infiniment mieux qu'une réponse inventée.

Ce que Dataiku 14 apporte sur ce terrain

La plateforme a rattrapé ces besoins. Agent Testing et Agent Evaluation permettent de mesurer avant de modifier. Agent Review et la validation humaine encadrent ce qui part en action. Les traces et le monitoring d'usage donnent la visibilité qu'on attend de n'importe quel traitement de production. Les guardrails filtrent en amont et en aval.

Autrement dit, les outils existent désormais pour appliquer aux agents ce qu'on applique depuis longtemps aux pipelines. Ce qui manque le plus souvent, ce n'est plus l'outillage, c'est le réflexe.