Votre agent IA commence à se comporter de façon imprévisible

Pourquoi l’IA en production exige des tests continus, de l’observabilité, des boucles de rétroaction et une gouvernance sur l’ensemble de son cycle de vie

Le scénario est bien connu.

Un développeur conçoit un outil pour répondre à un cas d’usage précis. L’équipe qualité le soumet à toutes sortes de tests, y compris dans des conditions qu’aucun utilisateur raisonnable ne devrait rencontrer. L’outil passe chaque épreuve avec succès.

Puis un utilisateur s’en empare. 

Il l’intègre à un processus inattendu, l’applique à un problème que personne n’avait anticipé et lui demande d’accomplir une tâche qui n’a jamais figuré dans le cahier des charges. Pensez, par exemple, à ce chatbot de service client de McDonald’s qui s’est retrouvé, à générer du code d’urgence pour un utilisateur qui avait épuisé ses tokens sur une autre plateforme. 

Les agents IA ne font pas exception. La difficulté est qu’ils peuvent produire une réponse inexacte, inadaptée ou incohérente tout en la présentant de manière parfaitement structurée. La forme paraît crédible, même lorsque le fond est erroné. L’utilisateur ne dispose donc pas toujours des signaux habituels qui lui permettraient de repérer immédiatement le problème.

Vous avez peut-être déjà échangé avec un agent qui donnait une mauvaise réponse avec une assurance déconcertante. Le genre de réponse qui vous oblige à vous arrêter un instant et à vous demander : « Comment cela a-t-il pu passer les tests ? »

La réponse est simple : votre agent IA est désormais en production.

Malheureusement, la production a des utilisateurs.

L’agent qui brillait lors d’une démonstration contrôlée peut continuer à répondre rapidement, à communiquer correctement avec les API et à afficher des indicateurs techniques au vert, tout en produisant discrètement des résultats incohérents.

D’un point de vue technique, rien n’est « en panne ».

Pourtant, les utilisateurs constatent que quelque chose ne fonctionne pas comme prévu.

Bienvenue dans la réalité de l’IA en production.

Le monde a changé. Pas votre agent.

Les agents IA évoluent dans des organisations où tout se transforme en permanence : les données, les API, les droits d’accès, les modèles, les processus internes et les comportements des utilisateurs.

Ces changements peuvent provoquer plusieurs formes de dérive.

1. Dérive des connaissances : l’agent récupère une information qui était exacte lors de son déploiement, mais qui ne l’est plus.
2. Dérive des outils : l’API existe toujours, mais son fonctionnement ne correspond plus à ce que l’agent attend.
3. Dérive des autorisations : l’agent perd l’accès à une ressource nécessaire ou, à l’inverse, obtient un niveau d’accès qu’il ne devrait pas avoir.
4. Dérive du modèle ou du prompt : une modification apparemment mineure entraîne un changement important de comportement.
5. Dérive des processus : l’agent continue d’appliquer rigoureusement une procédure que l’entreprise a modifiée depuis plusieurs mois – sans penser à informer le système.
6. Dérive des usages : les utilisateurs emploient le système d’une manière que ses concepteurs n’avaient jamais envisagée.

Cette dernière forme mérite une attention particulière.

Puis les utilisateurs entrent en scène

Les utilisateurs regroupent plusieurs intentions dans une même demande. Ils inventent des méthodes de travail que vous n’avez jamais conçues, explorent les cas limites et utilisent le système pour accomplir des tâches auxquelles il n’était pas destiné.

Ils vont également corriger l’agent, le contourner et parfois lui transmettre des habitudes que vous n’auriez pas souhaité lui voir adopter.

Cette créativité humaine n’est pas nécessairement un problème. L’utilisation réelle constitue même l’une des sources d’information les plus précieuses pour une équipe d’ingénierie IA. En pratique, vos utilisateurs deviennent votre plus vaste dispositif de test.

Malheureusement, ils ne créent pas de tickets Jira lorsqu’ils rencontrent un comportement inhabituel.

Dans les systèmes qui combinent mémoire persistante, gestion d’état, recherche d’information et orchestration, ces interactions ont une importance particulière. Une expérience passée peut influencer les réponses et les décisions futures de l’agent.

Mais accumuler de l’expérience ne signifie pas apprendre.

Sans boucle de rétroaction, la mémoire ne fait qu’accumuler

L’une des idées les plus dangereuses concernant l’IA en production consiste à croire qu’un agent doté d’une mémoire va naturellement s’améliorer avec le temps.

La mémoire, à elle seule, produit uniquement une accumulation d’informations.

Pour progresser, le système a besoin d’une véritable boucle de rétroaction.

Un bouton « utile » ou « inutile » ne constitue pas une boucle de rétroaction. Les journaux techniques et les données de télémétrie non plus. Tous ces mécanismes génèrent des signaux. L’essentiel est de savoir ce que l’organisation fait ensuite de ces signaux.

Une boucle de rétroaction efficace doit déclencher une action concrète :

Observer → Évaluer → Corriger → Valider → Améliorer

Si les utilisateurs reçoivent régulièrement des informations peu pertinentes, il faut peut-être revoir la stratégie de recherche et de récupération. Si l’agent sélectionne systématiquement le mauvais outil, le problème peut venir de la définition de cet outil ou de la logique de routage. Si les utilisateurs font apparaître un nouveau cas limite, cette interaction doit rejoindre le jeu de scénarios utilisé pour évaluer le système.

Et s’ils contournent constamment l’agent, il ne s’agit pas seulement d’une source de frustration. C’est une donnée opérationnelle précieuse.

Un bouton « pouce baissé » que personne ne consulte n’est rien de plus qu’une petite boîte à réclamations numérique. 

Votre tableau de bord ne vous dit peut-être pas toute la vérité

Les outils de supervision traditionnels indiquent si le service est disponible, si l’API fonctionne correctement, si le temps de réponse reste acceptable et si des erreurs techniques se sont produites.

Un agent IA peut réussir tous ces contrôles tout en remplissant mal sa mission.

L’observabilité de l’IA doit donc aller au-delà de l’état de l’infrastructure. Elle doit également couvrir le comportement de l’agent, la qualité de ses réponses et les résultats obtenus pour l’activité.

Lorsqu’un utilisateur signale que « l’agent a répondu quelque chose d’étrange hier », l’équipe doit pouvoir reconstituer l’ensemble du parcours : la demande initiale de l’utilisateur ; la mémoire et le contexte disponibles ; les informations récupérées ; la décision de routage ; l’outil sélectionné ; l’exécution de cet outil ; la réponse produite ; le résultat final. Autrement dit, l’équipe doit pouvoir reconstituer la scène du crime.

« L’agent a répondu quelque chose d’étrange » n’est pas une stratégie d’observabilité.

Le traçage permet d’identifier l’étape à laquelle le comportement a changé, plutôt que de simplement constater que la réponse finale était mauvaise.

Transformez chaque comportement inhabituel en test

Les situations observées en production doivent continuellement enrichir le dispositif d’évaluation.

Les scénarios définis avant le lancement ne peuvent pas rester figés. Les utilisateurs feront apparaître des cas que vous n’aviez pas anticipés. L’évolution de l’activité créera également des situations impossibles à prévoir lors de la conception initiale.

Toute interaction suffisamment inhabituelle devrait donc devenir un test potentiel de non-régression.

Inhabituel une fois ? C’est un incident.

Inhabituel deux fois ? C’est une tendance.

Inhabituel trois fois ? Félicitations, vous tenez peut-être une nouvelle fonctionnalité.

La formule prête à sourire, mais le principe est essentiel : l’utilisation en production doit continuellement approfondir votre compréhension des conditions dans lesquelles le système réussit ou échoue.

Les utilisateurs qui révèlent les dysfonctionnements les plus inattendus mettent souvent en lumière des exigences dont vous ignoriez l’existence.

Versionnez tout ce qui peut modifier le comportement

Un système agentique peut changer de comportement alors même que le code de l’application reste identique.

Les modèles, les prompts, les index de recherche, les définitions d’outils, les règles d’orchestration, les politiques de mémoire, les garde-fous et les données d’évaluation peuvent tous modifier ses performances.

La traçabilité devient donc indispensable.

Si vous ne pouvez pas identifier ce qui a changé, vous ne pouvez pas déterminer avec fiabilité ce qui s’est dégradé.

Le retour à une version antérieure est également plus complexe que pour une application traditionnelle. Il peut être nécessaire de rétablir un ancien modèle, de restaurer un prompt précédent, d’annuler une configuration de recherche, de modifier la définition d’un outil ou de revenir sur une règle d’orchestration.

Il faut parfois aussi intervenir sur la mémoire persistante ou sur l’état du système.

L’exploitation d’une IA en production exige donc une discipline opérationnelle appliquée à chaque composant susceptible d’influencer son comportement, et pas uniquement au code applicatif.

Qui en est responsable après le lancement ?

Les organisations consacrent beaucoup d’énergie à déterminer qui construira l’agent. Elles en consacrent souvent moins à définir qui en sera responsable une fois celui-ci déployé.

Pourtant, quelqu’un doit examiner les retours des utilisateurs et les résultats des évaluations. Quelqu’un doit vérifier que les sources de connaissances restent à jour et que les intégrations fonctionnent toujours comme prévu. Quelqu’un doit avoir l’autorité nécessaire pour valider les modifications apportées aux prompts, aux outils, aux modèles et aux règles d’orchestration. Quelqu’un doit également décider quand l’agent doit interrompre une action, transmettre la demande à une personne ou être définitivement retiré.

Sans responsabilité clairement attribuée, l’IA en production devient rapidement l’affaire de tout le monde et, par conséquent, celle de personne.

Déployer un agent sans désigner de responsable revient à introduire dans l’entreprise un système capable d’agir, sans établir clairement qui doit superviser ses décisions.

Le système peut être performant. Il peut automatiser des tâches complexes et produire des résultats impressionnants.

Mais quelqu’un doit rester responsable de son fonctionnement et de ses conséquences.

Le déploiement ne marque pas la fin d’un projet d’IA.

Il marque le début de son exploitation.

L’IA en production s’inscrit dans un cycle de vie

Les systèmes agentiques ont besoin de mécanismes permanents pour repérer les comportements inhabituels, en comprendre les causes, les corriger et éviter qu’ils ne se reproduisent. Il faut également savoir retirer les systèmes qui ne répondent plus aux besoins de l’activité.

Les tests, les évaluations, l’observabilité, le traçage, la supervision humaine, le versionnage, les procédures de retour en arrière, la gouvernance et la responsabilité opérationnelle appartiennent donc à un même cycle de vie.

Certains agents devront finir par disparaître.

Un processus peut devenir obsolète. Une fonctionnalité peut faire doublon avec un autre outil. Les coûts de maintenance peuvent dépasser la valeur créée. Une nouvelle solution peut remplacer entièrement l’agent initial.

Maintenir un agent simplement parce qu’il a été construit un jour ne constitue pas une stratégie d’exploitation.

Un retrait planifié sera toujours préférable à une dégradation progressive de la qualité, de la sécurité et de la confiance des utilisateurs.

Ne déployons plus l’IA pour ensuite l’oublier

La prochaine étape de la maturité de l’IA en entreprise ne se mesurera pas uniquement à la capacité de construire des agents.

Elle dépendra surtout de la capacité à les exploiter dans la durée.

Cela demande bien plus que de savoir rédiger des prompts ou sélectionner un modèle. Les architectes, les ingénieurs, les équipes de sécurité, les responsables métier et les utilisateurs doivent comprendre comment ces systèmes se comportent une fois intégrés à une organisation vivante.

L’objectif ne devrait pas être de multiplier les agents.

Il devrait être de construire des organisations capables de les maintenir utiles, sûrs, observables et alignés sur les besoins de l’entreprise dans la durée.

Votre agent IA n'est pas hors de contrôle.

Il est surtout livré à lui-même.