Salut à tous, ici Chris Wade, de retour sur agntlog.com. Nous sommes en mars 2026, et honnêtement, si vous pensez encore à surveiller vos agents comme nous le faisions il y a cinq ans, vous laissez de l’argent, de la santé mentale, et peut-être même votre emploi sur la table. Le monde a évolué, et votre stratégie devrait aussi. Aujourd’hui, je veux parler de quelque chose de spécifique, quelque chose qui me tracasse (et qui m’a sauvé la mise) beaucoup ces derniers temps : l’observabilité pour les états des agents, pas seulement pour les métriques.
Je sais, « observabilité » est un mot à la mode qui est lancé comme un frisbee lors d’un pique-nique technologique. Mais écoutez-moi. Pour nous, dans le domaine de la surveillance des agents, ce n’est pas qu’un terme à la mode ; c’est un changement fondamental dans notre compréhension de nos systèmes. Nous ne regardons plus uniquement l’utilisation du CPU ou la consommation de mémoire. Nous essayons de comprendre l’*état interne* de nos agents, leur parcours à travers un flux de travail et les signaux subtils qui nous indiquent que quelque chose est sur le point de mal tourner – ou l’est déjà.
Mon chemin vers cela a commencé il y a environ un an et demi. Nous avions un nouveau client, un immense centre d’appels avec des milliers d’agents utilisant notre intégration CRM personnalisée. L’ancienne approche de surveillance échouait de manière spectaculaire. Nous avions des tableaux de bord qui s’illuminent en rouge pour « haute utilisation CPU » ou « espace disque faible » sur les stations de travail des agents, mais le véritable problème, celui qui causait des plaintes des clients et des SLA manqués, était plus profond. Les agents se retrouvaient bloqués dans un état de « post-appel » indéfiniment, ou leur CTI (Intégration Téléphonique Informatique) ne registrait pas correctement les appels sortants. Les métriques traditionnelles nous disaient que les machines allaient bien, mais les *agents* (et par extension, l’entreprise) ne l’étaient clairement pas.
C’est alors que j’ai réalisé que nous devions cesser de simplement surveiller l’infrastructure et commencer à observer le comportement des agents et les transitions d’état. Il ne suffit pas de savoir si l’application d’un agent fonctionne ; nous devons savoir *ce que* cette application pense que l’agent fait, et si cela correspond à la réalité.
Le Problème de la Surveillance Uniquement des Métriques
Pensez à votre voiture. Si le témoin moteur s’allume, c’est une métrique. Cela vous dit que *quelque chose* ne va pas. Mais cela ne vous dit pas *quoi*. Est-ce un bouchon de gaz mal enlevé ? Un capteur d’oxygène défaillant ? Une défaillance catastrophique du moteur ? Vous avez besoin de plus de contexte, de plus de visibilité interne, pour vraiment comprendre le problème.
La surveillance traditionnelle est comme ce témoin moteur. Elle vous dit *si* une ressource est contrainte ou *si* un service est hors ligne. Mais pour des agents complexes et avec état, en particulier ceux interagissant avec plusieurs systèmes (CRM, téléphonie, base de connaissances, scripts personnalisés), une simple métrique ne vous donne souvent pas la vue d’ensemble. Un agent peut être « connecté » (selon votre surveillance de présence de base) mais effectivement figé, incapable d’effectuer des actions, à cause d’un blocage subtil dans la machine d’état de son application.
Nous avons vu cela de manière éclatante avec notre client de centre d’appels. Notre surveillance de base montrait que les agents étaient connectés au CRM. Leur connectivité réseau était correcte. Le CPU était normal. Pourtant, les appels n’étaient pas traités. En approfondissant, nous avons découvert qu’une séquence spécifique d’actions (transférer un appel, puis essayer immédiatement d’accéder à l’historique des paiements d’un client) faisait que l’état interne du CRM pour cet agent restait bloqué dans une boucle de « attente de réponse d’un service externe », même après que le service externe avait répondu. L’application ne plantait pas ; elle était simplement gelée dans un état non réactif du point de vue de l’agent. Aucune métrique n’aurait pu repérer cela.
Observabilité pour les États des Agents : Ce que Cela Signifie
Pour moi, l’observabilité dans ce contexte signifie équiper vos applications et flux de travail d’agents pour émettre des données détaillées et structurées sur leurs changements d’état internes, événements et contexte. Il s’agit de demander :
- Que fait l’agent *actuellement* selon l’application ? (par exemple, « En appel », « En récapitulatif », « Disponible », « Formation », « Pausé »)
- Quel était l’*état précédent* ?
- Quels *événements* ont déclenché le changement d’état ? (par exemple, « Appel entrant », « Appel répondu », « Bouton de pause manuelle cliqué »)
- Quel *contexte* est associé à cet état ? (par exemple, ID d’appel, ID client, raison de la pause, durée dans l’état actuel)
Ce n’est pas juste enregistrer des erreurs ; c’est consigner le *parcours* d’un agent à travers sa journée de travail, étape par étape, avec un contexte riche.
Exemple 1 : Suivi des États de Flux de Travail des Agents
Disons que vous avez une application de bureau d’agent personnalisée. Au lieu de simplement surveiller si le processus fonctionne, vous voulez connaître son état interne. Vous pouvez émettre des journaux structurés ou des traces chaque fois qu’un état clé change.
// Dans votre application de bureau d'agent (pseudo-code)
enum AgentState {
LoggedIn,
Available,
OnCall,
WrapUp,
Paused,
Offline
}
currentAgentState = AgentState.Offline;
function transitionState(newState, eventDetails = {}) {
const timestamp = new Date().toISOString();
const agentId = getAgentId(); // Obtenir depuis le contexte de l'application
const sessionId = getCurrentSessionId(); // Obtenir depuis le contexte de l'application
// Journaliser la transition d'état avec un contexte riche
console.log(JSON.stringify({
timestamp: timestamp,
agentId: agentId,
sessionId: sessionId,
oldState: currentAgentState.toString(),
newState: newState.toString(),
eventType: eventDetails.type || "STATE_CHANGE",
eventData: eventDetails.data || {}
}));
currentAgentState = newState;
}
// Exemple d'utilisation :
// Lorsque un agent répond à un appel :
transitionState(AgentState.OnCall, { type: "CALL_ANSWERED", data: { callId: "12345", customerId: "98765" } });
// Lorsque un agent passe en récapitulatif :
transitionState(AgentState.WrapUp, { type: "CALL_ENDED", data: { callId: "12345", dispositionTime: 30 } });
// Lorsque un agent met manuellement en pause :
transitionState(AgentState.Paused, { type: "MANUAL_PAUSE", data: { reason: "Break", duration: 15 } });
Ce n’est pas de la science roquette, n’est-ce pas ? Mais la puissance réside dans la collecte de ces événements de manière centralisée. Vous pouvez ensuite construire des tableaux de bord qui affichent les états des agents en temps réel, identifier les agents bloqués dans des états inattendus, et même analyser les modèles de transition d’état pour repérer les goulets d’étranglement des flux de travail.
Intégrer l’Observabilité dans Votre Outil de Gestion des Agents
Il ne s’agit pas simplement d’ajouter quelques instructions d’impression. Cela nécessite une approche réfléchie de l’instrumentation. Voici comment nous avons abordé cela :
1. Définir les États et Transitions Clés des Agents
Avant de rédiger du code, asseyez-vous avec vos chefs de produits, vos responsables d’équipe, et même certains agents. Cartographiez les états critiques dans lesquels un agent peut se trouver et les manières légitimes dont il peut passer d’un état à l’autre. Cela devient votre « vérité de base » sur ce à quoi ressemble un flux de travail sain pour un agent. Documentez cela explicitement.
2. Instrumenter Tout ce qui Est Pertinent
Dans vos applications d’agents (bureau, web, services backend soutenant les agents), émettez des journaux structurés ou des traces à chaque changement d’état significatif ou événement. Concentrez-vous sur :
- Changements d’État : Lorsque l’état d’un agent change (par exemple, « Disponible » à « En appel »).
- Actions Clés : Lorsque un agent effectue une action critique (par exemple, « Transférer l’appel », « Mettre à jour le dossier client », « Soumettre le formulaire »).
- Interactions avec des Systèmes Externes : Lorsque l’application de l’agent interagit avec un CRM, un système de téléphonie, ou une base de données. Enregistrez la requête, la réponse, et toute erreur.
3. Utiliser des Journaux Structurés
JSON est votre ami ici. Ne vous contentez pas de déverser du texte brut. Les journaux structurés facilitent infiniment l’analyse, le filtrage et la compréhension de vos données par la suite. Incluez des attributs communs dans chaque entrée de journal (timestamp, ID d’agent, ID de session, version de l’application) et des attributs spécifiques pour chaque type d’événement.
4. Centraliser et Analyser
Envoyez tous ces journaux à un système de journalisation central (Elasticsearch, Splunk, Loki, DataDog, etc.). C’est là que la magie opère. Maintenant, vous pouvez :
- Construire des Tableaux de Bord en Temps Réel : Visualisez l’état actuel de tous les agents, identifiez les valeurs aberrantes (par exemple, agents bloqués en « Récapitulatif » trop longtemps).
- Interroger et Filtrer : Trouvez rapidement tous les événements pour un agent, un client ou un ID d’appel spécifique.
- Alerter sur des Anomalies : Mettez en place des alertes pour des transitions d’état ou des durées inattendues (par exemple, « Alertez si un agent est en état de ‘Pausé’ pendant plus de 30 minutes sans code motif valide »).
- Suivre les Flux de Travail : Suivez le parcours d’un agent à travers un processus complexe en liant les entrées de journaux liées.
Exemple 2 : Détecter les Agents Bloqués avec l’Analyse de Journaux
En utilisant un système de journalisation tel qu’Elasticsearch avec Kibana, vous pourriez configurer une requête pour trouver des agents bloqués dans un état indésirable. Imaginez que vous cherchez des agents qui sont entrés dans l’état « Récapitulatif » mais qui n’en sont pas sortis depuis plus de 5 minutes.
// Requête Elasticsearch (Kibana Discover ou Dev Tools)
{
"query": {
"bool": {
"must": [
{ "match": { "newState.keyword": "WrapUp" } },
{ "range": { "timestamp": { "lte": "now-5m" } } }
],
"must_not": [
{ "exists": { "field": "nextState" } } // En supposant que vous journalee un événement "nextState" ou "transitionedOut"
]
}
},
"aggs": {
"stuck_agents": {
"terms": {
"field": "agentId.keyword",
"size": 100
}
}
}
}
Cette requête vous donnerait une liste d’IDs d’agents qui sont entrés dans l’état « Récapitulatif » il y a plus de 5 minutes et qui n’ont pas eu d’événement de changement d’état consigné par la suite. C’est un moyen très puissant d’identifier et d’adresser proactivement les problèmes avant qu’ils ne s’aggravent.
Mes Retours et Étapes Actionnables
Si vous gérez des agents, qu’ils soient humains ou des bots automatisés, vous devez absolument aller au-delà d’une simple surveillance du temps de fonctionnement. Voici ce que je recommande :
- Cessez de surveiller simplement les ressources, commencez à observer les états : Changez votre focus de « Le CPU est-il élevé ? » à « Que fait exactement l’application de l’agent en ce moment, et est-ce correct ? »
- Cartographiez vos flux de travail d’agent : Documentez chaque état significatif dans lequel un agent peut se trouver et les transitions valides. Ceci est votre plan pour l’observabilité.
- Instrumentez vos applications d’agent : Intégrez une journalisation structurée ou un traçage directement dans vos outils d’agent. Chaque changement d’état critique ou action doit émettre un événement détaillé. Utilisez JSON.
- Centralisez vos données : Envoyez ces événements dans un système où vous pouvez interroger, visualiser et alerter dessus.
- Établissez des alertes proactives : N’attendez pas que les agents se plaignent. Configurez des alertes pour des durées d’état inattendues ou des transitions invalides. Par exemple, si un agent reste en « WrapUp » pendant plus de 180 secondes en moyenne, alertez. Si un agent essaie d’accepter un appel alors qu’il est en état « Paused », alertez.
- Éduquez vos équipes : Montrez à vos équipes de support, d’opérations et de produits comment utiliser ces nouveaux tableaux de bord et requêtes. Plus il y a d’yeux sur les données, plus vite vous repérerez les problèmes.
Ce n’est pas un projet ponctuel. C’est un processus continu d’affinement de votre instrumentation, d’amélioration de vos tableaux de bord et de questionnement approfondi sur l’expérience de vos agents. Mais je vous promets, l’investissement en vaut la peine. Nous sommes passés d’une lutte réactive à une identification et résolution proactives des problèmes ayant un impact sur les agents en quelques minutes, parfois même avant que l’agent lui-même ne remarque un problème. Cela a amélioré le respect des SLA de nos clients, a réduit la frustration des agents et, franchement, a rendu mon travail beaucoup moins stressant. Et ça, en mars 2026, c’est une victoire à mes yeux.
Des pensées sur l’observabilité des agents ? Faites-le moi savoir dans les commentaires ci-dessous !
Articles Connexes
- Développement piloté par les journaux d’agents AI
- Ma stratégie de débogage : Du chaos au calme
- Journalisation des agents AI en production
🕒 Published: