Scénario illustratif. Un distributeur lance un agent qui trie les incidents de commande et propose la réponse au client. Le jour du lancement, il y a un gâteau. À la troisième semaine, trois personnes ont un avis sur la marche de l'agent, et chacune regarde autre chose : l'une compte les cas qu'il résout, l'autre ceux qui lui reviennent, la troisième ne se souvient que de celui qui a mal tourné. Personne n'a de date pour décider si l'agent reste, s'ajuste ou s'éteint.
La thèse en une ligne : le lancement n'est pas l'arrivée, c'est le début de la fenêtre la moins chère pour corriger un agent, et cette fenêtre se gaspille sans calendrier. Chaque semaine des trente premiers jours doit répondre à une question différente, et à la fin quelqu'un, avec un nom, doit signer une décision.
Que se passe-t-il pendant les premières semaines d'un agent IA en production ?
Pendant les premières semaines d'un agent IA en production, il se passe ce que la démo ne pouvait pas montrer : les cas réels arrivent, avec leurs formats bizarres, leurs exceptions et leurs clients impatients. C'est aussi le moment où corriger coûte le moins. Le volume est encore faible, les changements se déploient sans demander la permission à la moitié de l'entreprise, et les gens se rappellent encore comment le travail se faisait avant : ils voient vite quand l'agent dévie.
Ensuite, chaque correction coûte plus cher : plus de volume, plus de personnes qui dépendent de l'agent, plus d'historique qu'on ne veut pas casser. Voilà pourquoi le premier mois mérite ses propres règles, plutôt que « l'agent est en route ». Quatre signaux se regardent toujours : les exceptions (ce que l'agent ne sait pas résoudre), les corrections humaines (ce que les gens réparent après lui), la dérive (l'écart avec ce qui a été testé) et le coût réel par cas.
Semaine 1 : fait-il ce que nous avons validé ?
La première semaine ne se mesure pas, elle se lit. Une personne passe chaque jour en revue à la main un large échantillon de cas, idéalement quelqu'un qui a monté l'agent et quelqu'un qui connaissait l'ancien processus. Quinze minutes par jour suffisent si l'échantillon est bien choisi : les cas faciles, les cas douteux et tous ceux que l'agent a escaladés.
La question de la semaine : l'agent fait-il exactement ce qui a été convenu, et rien d'autre ? Trois vérifications : il ne touche à rien hors de son périmètre (les permissions que vous lui avez données, pas celles qu'il pourrait avoir ; les niveaux d'autonomie d'un agent servent de liste de contrôle), chaque cas laisse assez de traces pour reconstituer ce qui s'est passé, et il existe une liste des « cas que personne n'avait prévus » avec une date et un responsable. Cette liste est l'actif le plus précieux de la semaine : c'est le vrai travail que la démo a sauté.
Semaine 2 : que corrigent les gens après l'agent ?
La deuxième semaine, on regarde ce que les humains rectifient. Chaque correction est une information gratuite sur les failles de l'agent, à condition d'enregistrer ce qui a été corrigé et pourquoi. La règle pratique est simple : une correction isolée est une erreur ; la même correction trois fois est une règle qui manque.
On classe les corrections par type : donnée mal extraite, mauvaise décision, ton ou format, et cas qui aurait dû être escaladé et ne l'a pas été. Le dernier est le plus coûteux, car il signifie que l'agent ne sait pas quand il ne sait pas ; les critères sont dans ce que fait un agent quand il ne sait pas. Et on calcule une mesure de performance avec la même règle que celle utilisée ensuite, comme l'explique le guide sur mesurer la performance de vos automatisations : si l'on change de mesure en cours de mois, on ne peut plus rien comparer.
Semaine 3 : les exceptions s'accumulent-elles, le terrain bouge-t-il ?
La troisième semaine est celle des exceptions et de la dérive. Les exceptions sont le travail que l'agent renvoie aux personnes ; ce qui compte n'est pas leur nombre, mais si quelqu'un les traite, avec quel retard, et si la file grossit ou se stabilise. Une file que personne n'a priorisée est l'endroit où l'économie meurt, comme le raconte la file d'exceptions, où meurt l'économie.
La dérive se mesure contre quelque chose de concret : un jeu de cas dont la bonne réponse est connue, le même que celui qui a servi à valider le lancement. On le repasse maintenant pour vérifier que l'agent répond toujours pareil. Si le fournisseur du modèle, un format d'entrée ou un outil connecté a changé, on le voit ici avant le client. Que le comportement se dégrade avec le temps n'est pas de la malchance, c'est la norme, et nous l'expliquons dans pourquoi votre pilote marchait en janvier et plus en juin.
Semaine 4 : combien coûte vraiment chaque cas, et que décide-t-on ?
La quatrième semaine, on met un prix. Le coût par cas n'est pas la facture du modèle : il additionne les heures de celui qui relit, de celui qui traite les exceptions et de celui qui réajuste, plus le temps de préparation du rapport. Si le seul coût affiché à l'écran est celui des tokens, vous regardez la partie bon marché. Pour avoir ces chiffres en direct sans construire le tableau de bord à la main, il y a la fonction de supervision de l'IA en production.
Avec les quatre semaines devant soi, on prend une décision par écrit. Il n'y a pas de quatrième option « on verra » :
| Décision | Quand elle s'impose | Ce que cela implique |
|---|---|---|
| Déclarer stable | Les corrections répétées baissent, la file d'exceptions ne grossit pas et le coût par cas reste dans l'enveloppe convenue | Passage à la relecture par échantillonnage et à la routine de maintenance |
| Prolonger avec des changements | Une cause est identifiée et réparable, mais les chiffres ne soutiennent pas encore le dossier | On fixe un délai et un changement précis, pas « quelques jours de plus » |
| Arrêter ou réduire l'autonomie | Les mêmes corrections reviennent chaque semaine ou personne ne sait expliquer le coût | Retour en mode assistant ou arrêt ; un résultat valable, pas un échec |
Quand NE PAS déclarer un agent stable à la fin du mois ?
Quatre situations rendent la mention « stable » risquée, même quand les chiffres sont bons. Un : le volume des quatre semaines était si faible qu'aucun cas rare n'est apparu ; un mois calme ne prouve rien. Deux : le mois a compris un changement de fournisseur ou de processus, et le jeu de cas n'a pas été repassé ensuite. Trois : la décision a été prise par celui qui a monté l'agent, sans la signature du responsable du processus ; c'est le sujet de critères d'acceptation d'un agent IA : qui signe le feu vert. Et quatre : personne n'a de nom ni de créneau pour surveiller l'agent la semaine suivante.
Déclarer stable ne veut pas dire cesser de regarder. C'est passer d'une revue intensive à une routine plus légère, avec le calendrier de maintenance des automatisations IA et l'agent déjà inventorié. Si le passage du pilote à l'exploitation est précisément ce qui vous bloque, la fonction du pilote IA à la production couvre ce tronçon.
Ce que vous en retenez
Ce calendrier ne change pas la technique, il change l'habitude : une question par semaine, une personne nommée et une décision à la fin. Semaine un, fait-il ce qui a été validé ? Semaine deux, que corrigent les gens ? Semaine trois, les exceptions s'accumulent-elles ou le terrain bouge-t-il ? Semaine quatre, combien ça coûte et que décide-t-on ? Un agent qui survit à ces quatre questions a gagné le droit à une vie ennuyeuse, ce qui est exactement ce qu'on attend de lui.
Note : cet article n'utilise pas de chiffres de tiers. Le scénario est illustratif, et les délais et seuils de chaque décision dépendent du processus, du volume et du risque de chaque entreprise ; fixez-les avant le lancement, pas après.