Pourquoi votre agent IA ne passe pas en production

Pourquoi une démo réussie ne prouve rien

Une démonstration se construit sur des données choisies, un chemin unique et un opérateur bienveillant. La production, c'est l'inverse : des données réelles avec leurs trous, tous les chemins à la fois, et des utilisateurs qui posent la question autrement. L'écart entre les deux n'est pas un écart de qualité du modèle, c'est un écart d'ingénierie.

Les chiffres de McKinsey le disent sans détour : 62 % des entreprises expérimentent, 11 % ont quelque chose en production. Le taux de déchet n'est pas dû à des modèles insuffisants, ceux de 2026 dépassent largement ce que demandent la plupart des cas d'usage d'entreprise. Il est dû à cinq causes que je retrouve dans presque tous les projets qui s'arrêtent, et qui ont toutes en commun d'être décidées avant la première ligne de code.

Ce guide les prend dans l'ordre où elles se manifestent, avec ce qu'il faut trancher pour chacune. Il se termine par une checklist de douze points : si vous ne pouvez pas cocher les douze, votre agent n'est pas prêt, quel que soit le résultat de la démonstration.

Raison 1, Les données ne sont pas accessibles autrement qu'à la main

C'est la cause la plus fréquente et la plus banale. L'agent de démonstration lisait un export CSV posé sur un disque, ou trois PDF chargés à la main. Personne n'a demandé comment ces fichiers arriveraient chaque jour, à quelle heure, avec quelle garantie de format. Le jour de la mise en production, la réponse est : quelqu'un les dépose. Ce quelqu'un part en congés, et l'agent s'arrête.

La question à poser avant tout : vos données métier sont-elles accessibles par API, par requête, ou par un export automatisable ? Si la réponse est non, et c'est le cas de la majorité des entreprises que je rencontre, le projet n'est pas encore un projet d'agent : c'est d'abord un diagnostic et un plan de structuration de données, et il faut le nommer ainsi. Il coûte entre 6 000 et 14 000 €, dure une à trois semaines, et conditionne tout ce qui vient après. L'escamoter revient à construire sur du sable.

Le bon signal : quand vous demandez « d'où viennent ces données », la réponse tient en une phrase technique, un endpoint, une vue, une base. Le mauvais signal : la réponse commence par un prénom.

Raison 2, Personne n'a défini ce que « ça marche » veut dire

Un agent n'est ni juste ni faux : il est acceptable ou inacceptable sur un ensemble de cas. Sans définition écrite de cet ensemble, la recette devient une conversation d'impressions. Le prestataire trouve que ça marche, le client trouve que non, et le projet meurt d'épuisement plutôt que d'échec technique.

La pratique qui règle ce problème s'appelle les critères de recette. Avant de commencer, on écrit une vingtaine de cas de test : une entrée réelle, le résultat attendu, et la tolérance acceptée. Dix cas normaux, cinq cas limites, cinq cas que l'agent doit refuser de traiter. Ce document tient en deux pages et se relit en dix minutes.

Il produit trois effets. Il rend la recette factuelle : l'agent passe dix-huit cas sur vingt, on sait exactement lesquels échouent. Il force le métier à expliciter ses règles, ce qui révèle souvent des désaccords internes qui n'avaient rien à voir avec l'IA. Et il permet d'adosser le paiement à un fait vérifiable plutôt qu'à un ressenti, c'est pourquoi je fais dépendre 40 % du prix de ces cas.

Raison 3, Aucune gestion d'erreurs

Un traitement qui fonctionne sur dix éléments et casse sur deux mille n'a aucune valeur. C'est la leçon la plus coûteuse de mon projet le plus lourd : sur 2 800 biens et sept traitements chacun, il y a chaque nuit des appels qui échouent, des réponses hors format, des limites de débit atteintes, des champs vides là où le format en promettait un. L'agent doit prévoir cela, sinon le premier cas limite arrête toute la chaîne.

Trois mécanismes suffisent dans la plupart des cas. Premièrement, la reprise idempotente : chaque élément traité est marqué, et un redémarrage ne retraite pas ce qui est fait. Deuxièmement, la validation de sortie : on vérifie le format et les contraintes, longueur, champs obligatoires, cohérence, et on relance la génération quand ça sort des bornes, au lieu d'écrire une donnée fausse. Troisièmement, le routage des erreurs : les échecs partent vers un canal surveillé, avec le contexte suffisant pour comprendre sans rejouer.

Ce travail représente environ un tiers du coût d'un agent sérieux. C'est aussi le premier poste que l'on coupe quand on veut faire baisser un devis, et la raison la plus fréquente pour laquelle un agent moins cher finit par coûter plus.

Raison 4, L'agent dépend d'un prestataire que l'équipe ne peut pas remplacer

Un agent hébergé sur le compte du prestataire, avec des prompts que personne n'a lus et une logique que personne ne sait modifier, n'est pas un actif : c'est une dette. La direction technique le sait, et c'est souvent elle qui bloque la mise en production, pas par mauvaise volonté, mais parce qu'elle refuse d'exploiter ce qu'elle ne peut pas réparer.

Les conditions d'un transfert réel sont concrètes : l'agent tourne sur votre infrastructure ou sur un compte à votre nom ; le code et les prompts sont dans votre dépôt ; l'architecture est documentée avec le journal des décisions ; et au moins une personne chez vous a modifié un comportement de l'agent avant la fin de la mission, en séance. Ce dernier point est le seul qui prouve les trois autres.

Chez Villanovo, le serveur MCP a été construit par leur équipe IT à partir de ma spécification, et huit mois plus tard ils font évoluer l'infrastructure sans moi. Que ce soit vos équipes ou moi qui tenions le clavier, la condition est la même : la documentation et le transfert de compétence doivent être réels, pas un vernis.

Raison 5, On a automatisé un processus que personne n'avait simplifié avant

La plus fréquente des cinq, et la moins traitée, parce qu'elle ne relève pas de la technique. Un processus qui a accumulé quinze ans d'exceptions, de validations redondantes et de contournements ne devient pas efficace parce qu'un agent l'exécute : il devient rapide et illisible. Le coût de l'automatisation suit la complexité du processus, souvent de façon non linéaire.

La séquence utile est toujours la même : décrire le processus tel qu'il est réellement exécuté, pas tel qu'il est documenté ; supprimer les étapes que personne ne sait justifier ; puis automatiser ce qui reste. Sur les projets que j'ai vus, cette étape retire entre un quart et la moitié des étapes. Et cette moitié coûtait plus cher à automatiser que le reste, parce que c'est là que se cachent les exceptions.

Le test est simple : demandez à trois personnes qui exécutent le processus de le décrire. Si vous obtenez trois descriptions différentes, vous n'avez pas un problème d'IA, vous avez un problème de processus. L'automatiser en l'état, c'est graver le désaccord dans du code.

Checklist de mise en production, 12 points

Douze points à cocher avant d'ouvrir l'agent à des utilisateurs réels. Si un seul manque, la date de mise en production est optimiste.

Si votre projet bute sur l'un de ces points, c'est exactement le genre de sujet qu'on peut trancher en vingt minutes. Prendre rendez-vous →