Les agents IA du support technique agissent seuls et font éclater la logique du ticket

Depuis la fin des années 1980, avec l'apparition des premiers systèmes de suivi des demandes et de la première version d'ITIL, le support compte son travail en tickets. Une demande arrive, elle est assignée à un intervenant, puis clôturée, et le temps est chronométré. Près de quatre décennies plus tard, ce schéma se fissure : des agents IA exécutent déjà des actions dans plusieurs systèmes à la fois, débloquent des comptes, accordent des accès et redémarrent des services. Si personne ne prend la demande en charge, une question demeure : comment mesurer le support ? C'est celle que traite Habr AI. Voici l'essentiel de son analyse, ainsi que nos conclusions.

Pourquoi le ticket a si longtemps été l'unité de référence

Le ticket cumulait trois rôles : file de tâches, journal d'événements et base de reporting. Les SLA, la charge des employés, le temps de réaction et le temps de résolution sont rattachés à la fiche et à une personne précise. Toute la construction repose sur une hypothèse : entre la demande et l'action se trouve un intervenant qui dépense du temps et de l'attention. Le temps était d'ailleurs considéré comme la ressource principale.

Avec un agent, cette hypothèse ne tient plus. Il n'attend pas dans une file, ne passe pas d'une tâche à l'autre et ne part pas déjeuner. Le déblocage d'un compte prend quelques secondes, et l'action peut toucher en même temps l'annuaire des utilisateurs, le système de gestion des accès et la supervision.

Ce qu'il reste de la demande

Ce qui casse en premier, ce sont les métriques de vitesse. Le temps de réaction tend vers zéro, le temps moyen de résolution chute brutalement. Ces chiffres ne permettent pas de savoir si le problème est réellement résolu ou si l'utilisateur a simplement cessé d'écrire. Dans un rapport, un bon résultat et une défaillance silencieuse se ressemblent.

Le deuxième changement concerne la fiche elle-même. Lorsque l'agent agit de façon autonome, le ticket est souvent créé et clôturé automatiquement, ou n'est pas créé du tout. Il cesse d'être un outil de travail pour devenir une trace : un enregistrement de qui a fait quoi, sur quel fondement et avec quels droits. La valeur se déplace de la file d'attente vers le journal des actions.

Le troisième changement touche à la responsabilité. Un accès accordé crée une surface d'attaque bien réelle, et un service redémarré peut interrompre le travail de quelqu'un d'autre. Dans ce cas, un commentaire « fait » dans la fiche est une source trop pauvre.

Comment mesurer le support

L'annonce ne contient pas de liste directe, mais le problème décrit appelle un ensemble d'indicateurs qu'il est raisonnable de placer à côté des indicateurs classiques :

• la part des demandes clôturées par l'agent sans intervention humaine, et la part des demandes répétées les concernant ;
• la part des actions de l'agent qu'un humain a annulées ou corrigées ;
• le temps jusqu'à la résolution du point de vue de l'utilisateur, et non d'après le statut de la fiche ;
• le nombre d'escalades vers des humains et leurs motifs ;
• le coût de traitement d'une demande, en tenant compte des appels au modèle et du temps de vérification ;
• l'exhaustivité de l'audit : pour chaque action, l'initiateur, le fondement, les droits utilisés et le résultat sont consignés.

Les demandes répétées sont ici l'indicateur le plus honnête. Si l'utilisateur revient avec le même problème, la clôture rapide ne valait rien.

Par où commencer en pratique

Commencez par les droits. L'agent a besoin du niveau d'accès minimal nécessaire, et non d'un compte administrateur « pour plus de commodité ». Il convient de répartir les actions selon leur niveau de risque : une réinitialisation de mot de passe ou un déblocage n'est pas comparable à l'attribution de droits privilégiés, et ce second cas exige la validation d'un humain.

Revoyez ensuite le reporting. Pour les demandes automatisées, mieux vaut remplacer les SLA de temps de réaction par des indicateurs de qualité : demandes répétées, annulations, satisfaction. Il n'est pas nécessaire de jeter le ticket. Il vaut mieux le conserver comme enregistrement unique pour l'audit, même si aucun humain n'y est jamais intervenu.

Enfin, laissez aux humains les cas d'exception et l'analyse des erreurs. Le travail du spécialiste du support se déplace du traitement de la file vers le paramétrage et la vérification des agents, et il faudra l'évaluer autrement qu'au nombre de demandes clôturées.