Un agent IA n’est pas un livrable qu’on installe et qu’on oublie. C’est un système vivant qui dépend de données, de modèles et d’usages qui évoluent. Ce qui doit être suivi — et comment — se décide avant la mise en service, pas après.
Pourquoi un agent IA peut dériver
Un agent IA répond à partir de deux choses : un modèle de langage et des données (corpus, connexions, contexte). Les deux évoluent indépendamment de votre volonté.
Le modèle évolue : les fournisseurs (OpenAI, Anthropic, Mistral) publient régulièrement de nouvelles versions. Certaines évolutions améliorent la qualité des réponses. D’autres modifient subtilement les comportements — une formulation qui marchait bien peut produire des résultats différents sur une nouvelle version.
Les données évoluent : vos produits changent, vos procédures aussi. Si le corpus n’est pas mis à jour, l’agent continue de répondre à partir d’informations obsolètes. Il ne sait pas qu’elles sont obsolètes — il répond avec ce qu’il a.
La dérive des réponses
La dérive est rarement spectaculaire. L’agent ne « tombe pas en panne » au sens traditionnel. Il produit des réponses qui semblent correctes mais qui s’éloignent progressivement du périmètre attendu.
Exemples courants : l’agent commence à répondre sur des sujets qu’il ne devrait pas traiter. Ses réponses deviennent plus longues ou plus vagues. Il confond deux produits similaires dont les noms ont changé. Il propose des tarifs anciens.
Ces dérives passent souvent inaperçues si personne ne surveille. C’est pourquoi la supervision n’est pas optionnelle.
Ce qui doit être surveillé
- Taux de questions hors périmètre : l’agent reçoit-il des questions qu’il n’est pas censé traiter ? Si oui, est-ce qu’il les refuse correctement, ou est-ce qu’il tente de répondre quand même ?
- Qualité des réponses sur les cas représentatifs : un ensemble de questions de référence, testées régulièrement, permet de détecter les dérives avant qu’elles atteignent les utilisateurs finaux.
- Feedback utilisateurs : les signaux négatifs (mauvaises notes, reformulations répétées, abandons) indiquent des problèmes que les tests automatiques ne voient pas toujours.
- Cohérence avec les données sources : les informations utilisées dans les réponses correspondent-elles encore à ce qui est dans le corpus ?
Mettre à jour le corpus
La mise à jour du corpus est une opération régulière, pas exceptionnelle. Selon le rythme d’évolution de votre activité, elle peut être mensuelle ou trimestrielle.
Elle comprend : ajout des nouveaux documents, modification des documents existants, suppression des informations obsolètes. Et — étape souvent oubliée — vérification que les nouvelles informations ne contredisent pas les anciennes sans que ce soit intentionnel.
Prévoir qui fait ce travail, avec quel outil, et comment les modifications sont validées avant d’être publiées dans le corpus. Un corpus mal géré est pire qu’un corpus incomplet : l’agent peut servir des informations contradictoires avec une égale confiance.
Gérer les mises à jour de modèle
Les fournisseurs de modèles n’annoncent pas toujours les changements de comportement lors des mises à jour. Certaines sont annoncées, d’autres non. La bonne pratique est de tester le comportement de l’agent sur une batterie de cas de référence avant de passer à une nouvelle version de modèle — et de ne pas mettre à jour en production sans ce test.
Pour les projets sensibles (aide à la décision, informations réglementées, interactions clients), garder la version précédente accessible pendant une période de transition est une précaution raisonnable.
Supervision des cas limites
Tout agent IA bien conçu a un périmètre explicite et un comportement défini hors périmètre. Mais les utilisateurs testent toujours les limites — parfois involontairement, parfois délibérément.
Surveiller les cas limites permet d’identifier deux choses : des usages légitimes que le périmètre initial n’avait pas anticipés (et qu’il faudrait intégrer), et des tentatives de contournement qui révèlent des failles dans les guardrails.
Ces observations alimentent les évolutions du périmètre et de la configuration — pas seulement les corrections de bugs.
Organiser la supervision dès la conception
La supervision n’est pas une couche qu’on ajoute après. Elle se conçoit avec le projet : quelles métriques, quels outils de log, quelle fréquence de revue, qui est responsable, quel processus pour décider d’une intervention.
Un agent IA livré sans plan de supervision est un agent livré à moitié. La mise en service est l’étape qui précède la maintenance — pas celle qui la remplace.
Vous avez un agent IA en production sans supervision structurée, ou vous préparez une mise en service ? Discutons de la façon de l’organiser.
Poser une question