Une démo d'agent IA a un avantage injuste : elle se joue sur les questions que son auteur a choisies. La production n'a pas cette politesse. Elle pose les questions des utilisateurs, dans le désordre, avec des données sales, à deux heures du matin.

Selon l'étude du MIT publiée en 2025, 95 % des pilotes d'IA générative en entreprise ne produisent aucun retour mesurable. Dans les projets que nous avons vus passer, la cause est rarement le modèle. C'est presque toujours l'absence de trois disciplines.

1. Sans évaluation, personne ne sait si ça marche

Le jour de la démo, quelqu'un a testé dix prompts et tout allait bien. Trois mois plus tard, un prompt système a été retouché, un modèle a changé de version, une source de documents a bougé. Personne n'a de chiffre pour dire si le système est meilleur ou pire qu'avant.

Ce qu'il faut, et ce que nous construisons en premier dans un diagnostic : un jeu de cas représentatifs, tirés des vraies conversations, avec un critère de réussite explicite pour chacun. Cinquante cas bien choisis valent mieux que mille cas synthétiques. Ensuite, ce jeu tourne à chaque changement, et une mise en production peut échouer dessus. C'est la seule façon de faire évoluer un agent sans le casser à l'aveugle.

2. Sans observabilité, vous découvrez les problèmes sur la facture

Un agent qui boucle coûte cent fois un appel simple. Une chaîne de récupération qui ramène vingt documents inutiles double la latence. Sans traces, ces dérives sont invisibles jusqu'à la fin du mois, quand la facture arrive et que personne ne peut désigner le responsable.

L'observabilité n'est pas un tableau de bord de plus. C'est la capacité, pour un appel donné, de répondre à trois questions : qu'est-ce qui a été envoyé au modèle, combien cela a coûté, et pourquoi la réponse est celle-là. Traces, latence par étape, coût par requête : quand ces trois mesures existent, un incident se lit en minutes. Quand elles n'existent pas, il se devine en jours.

3. Sans transfert, le système part avec son auteur

Le troisième mode d'échec est le plus silencieux. L'agent fonctionne, il est même observé. Mais il vit dans le notebook, ou dans la tête, d'une seule personne. Elle change d'équipe, et le système devient une boîte que plus personne n'ose ouvrir.

Un système en production doit pouvoir être repris : code dans le dépôt de l'équipe, avec ses conventions et ses revues ; documentation qui dit ce qui est fragile et pourquoi ; sessions de passation où l'équipe modifie le système elle-même, pas où elle regarde quelqu'un le faire. Nous considérons une mission terminée quand nos interlocuteurs n'ont plus besoin de nous.

Ce que cela change dans l'ordre des choses

La tentation naturelle est de commencer par construire. C'est l'ordre qui gaspille le plus.

  1. Comprendre ce que l'IA sait faire, ce qu'elle coûte et là où elle échoue, pour que les décisions se prennent sur des faits.
  2. Mesurer l'existant : lire le code qui tourne, construire le jeu d'évaluation, chiffrer ce que la production exigera.
  3. Livrer un cas d'usage jusqu'au bout, avec ses évaluations, ses traces et son transfert.

Une démo prouve qu'une idée est possible. Une évaluation prouve qu'elle est vraie. Une trace prouve ce qu'elle coûte. Un transfert prouve qu'elle durera. Les quatre sont nécessaires, et seule la première est facile.