La réponse courte
Le monitoring d'Agentforce diffère de celui d'un système traditionnel : l'Agentforce ne "tombe" presque jamais. Il continue de répondre, mais de manière moins optimale. Par conséquent, les métriques classiques de disponibilité et d'erreurs sont insuffisantes ; une couche supplémentaire est nécessaire pour mesurer la qualité des décisions plutôt que la simple intégrité technique.
Une structure pratique comprend trois niveaux : la trace (Trace) expliquant une interaction individuelle, les tendances hebdomadaires identifiant les dégradations, et une métrique de résultat commercial justifiant la poursuite de l'activité. Chaque niveau répond à une question différente et s'adresse à un public distinct.
Les trois niveaux de monitoring
| Niveau | Question à laquelle il répond | Public | Fréquence |
|---|---|---|---|
| Trace | Pourquoi cette interaction s'est-elle conclue ainsi ? | Équipe technique et analyste | Sur demande |
| Tendance | Qu'est-ce qui change en bien ou en mal ? | Propriétaire de processus et administrateur de plateforme | Hebdomadaire |
| Résultat | L'Agentforce justifie-t-il son existence ? | Direction et sponsor | Mensuelle et trimestrielle |
Niveau 1 : Que doit contenir la trace (Trace)
Une trace Agentforce utile permet de reconstituer la décision sans interroger qui que ce soit. Elle se compose de sept éléments : la requête telle que formulée, le sujet identifié, les extraits réellement récupérés, les actions déclenchées avec leurs paramètres, le résultat de chaque action, les points de confirmation et leur décision, et la raison de la conclusion.
L'élément le plus souvent oublié est celui des extraits récupérés. Sans cela, il est impossible de distinguer deux échecs totalement différents : l'Agentforce n'a pas trouvé l'information, ou l'a trouvée mais l'a mal utilisée. Le premier cas relève du contenu, le second des instructions – et une mauvaise gestion a fait perdre des semaines à chaque organisation que nous avons rencontrée.
Il est également essentiel de lier la Trace à l'enregistrement métier : Case, Order ou Opportunity. Sans ce lien, il est impossible de vérifier si l'interaction a finalement conduit à un résultat positif ou à un contact répété.
Niveau 2 : Les tendances à surveiller
Cinq métriques sont généralement suffisantes pour la plupart des déploiements : le taux de résolution sans escalade, le taux de nouveau contact dans la semaine, le pourcentage de réponses avec une source valide, le taux d'échec des actions, et la consommation par rapport aux tâches accomplies.
L'analyse se fait par paires. Un taux de confinement élevé avec un taux de nouveau contact élevé n'est pas un succès. Une consommation qui augmente alors que les tâches restent stables signifie que l'Agentforce travaille plus pour le même résultat — un signe précoce de dégradation du contenu.
Les alertes automatiques sont configurées sur les changements relatifs plutôt que sur les valeurs absolues : un pic du taux d'escalade, une baisse du pourcentage de sources valides, une augmentation des échecs d'action avec un système externe spécifique.
Le lien entre ces métriques et les coûts est détaillé dans Coût d'Agentforce et TCO.
Niveau 3 : Résultat commercial
C'est le niveau décisif lors de l'examen trimestriel. Deux chiffres : qu'est-ce qui a changé dans la métrique de processus que nous avons choisie à l'avance – temps de traitement, abandon, volume de requêtes par agent – et quel est le coût de la tâche accomplie par rapport à la référence (Baseline).
Il est crucial de fixer les définitions à l'avance et de ne pas les modifier après avoir constaté un résultat. Changer la définition du "succès" en cours de route est ce qui nuit le plus à la confiance de la direction dans les données, même lorsque le changement est justifié.
De l'analyse à la file d'attente d'amélioration
Le rapport hebdomadaire n'est pas le produit final. Le produit final est une file d'attente de travail. La pratique efficace consiste à : échantillonner vingt interactions ayant échoué ou été escaladées, les classer par cause racine — lacune de contenu, étiquetage incorrect, instruction imprécise, échec d'action ou requête hors du périmètre (Scope) — et ouvrir un élément de travail pour la catégorie la plus représentée uniquement.
La règle qui empêche la dispersion : traiter une cause racine par semaine. Les organisations qui tentent de corriger cinq problèmes simultanément ne savent pas, au final, ce qui a amélioré la métrique et ce qui l'a détériorée.
Les lacunes de contenu identifiées ici sont une entrée directe pour la liste de rédaction – le processus est détaillé dans Knowledge Management pour Agentforce.
Cas d'étude : une dégradation silencieuse détectée à temps
Une entreprise de services financiers avait déployé un Agentforce interne qui est resté stable pendant quatre mois. Au cours de la quinzième semaine, le taux d'escalade a augmenté progressivement sans que personne ne s'en plaigne – les agents complétaient simplement le traitement eux-mêmes.
L'alerte configurée sur une augmentation relative de l'escalade a déclenché une investigation. L'échantillonnage des Traces a montré que, dans la moitié des nouveaux cas, aucun extrait pertinent n'avait été récupéré. La raison : un changement de politique produit avait entraîné l'archivage automatique de onze articles, et aucune alternative n'avait été rédigée.
La correction a pris deux jours et n'a pas nécessité de toucher à l'Agentforce. Sans la couche de monitoring, l'écart n'aurait été découvert que lorsqu'un manager aurait demandé pourquoi le temps de traitement moyen avait augmenté – probablement après un trimestre.
Risques et actions préventives
| Risque | Comment cela se manifeste | Action préventive |
|---|---|---|
| Monitoring technique uniquement | Tout est "vert", mais les réponses sont de moindre qualité | Métriques de qualité et d'escalade en plus des métriques de disponibilité |
| Trace sans extraits de récupération | Des mois de conjectures entre contenu et modèle | Enregistrement obligatoire des extraits récupérés |
| Rapport sans file d'attente de travail | Les données sont présentées mais ne changent rien | Échantillonnage hebdomadaire et élément de travail pour une cause racine |
| Modification des définitions en cours de route | Perte de confiance dans les données | Fixer les définitions de succès à l'avance |
| Aucun lien vers un enregistrement métier | Impossible d'identifier les contacts répétés | Lier la Trace à un Case ou à un Order |
Tableau de bord de métriques recommandé
| Métrique | Définition | Seuil d'alerte |
|---|---|---|
| Taux de résolution | Achèvement sans escalade et sans nouveau contact | Baisse relative significative d'une semaine sur l'autre |
| Taux d'escalade | Pourcentage de transferts à un agent humain | Augmentation relative continue |
| Source valide | Pourcentage de réponses avec citation existante et valide | Baisse en dessous d'un seuil prédéfini |
| Échecs d'action | Pourcentage d'opérations ayant échoué par système cible | Augmentation des échecs envers une cible spécifique |
| Consommation par tâche | Unités de consommation par tâche accomplie | Augmentation sans croissance des tâches |
Pour un accompagnement dans la mise en place d'une couche de monitoring et d'un processus d'amélioration hebdomadaire, le Service Agentforce et IA est la voie pratique à suivre.
Checklist de mise en place de l'observabilité
- ☐ La Trace enregistre la requête, le sujet, les extraits récupérés, les actions et le résultat.
- ☐ Chaque Trace est liée à un enregistrement métier.
- ☐ Une politique de conservation distingue les métadonnées du contenu de l'interaction.
- ☐ Seules cinq à sept métriques de tendance ont été sélectionnées.
- ☐ Des alertes ont été configurées sur les changements relatifs plutôt que sur les valeurs absolues.
- ☐ Une routine d'échantillonnage hebdomadaire des interactions ayant échoué est en place.
- ☐ Une taxonomie des causes racines des échecs a été définie.
- ☐ Le propriétaire du processus métier participe à l'examen hebdomadaire.
- ☐ Les définitions de succès ont été établies avant le début de la mesure.