Nous avons soumis les mêmes 20 demandes d'utilisateurs à une IA dans deux rôles : chatbot et agent. En chatbot, elle en a résolu 4. En agent, elle en a résolu 20, sans exécuter la moindre action interdite. Le modèle était le même dans les deux cas. Une seule différence : l'agent disposait d'outils pour consulter GLPI et y agir, et de règles précisant ce qu'il ne pouvait pas faire seul.
Ceci est le troisième article de notre série sur l'IA dans le service desk. Auparavant, nous avons mesuré le tri des tickets avec Jev et ce que coûte l'IA par ticket.
Pourquoi tout le monde parle d'agents
Gartner prévoit que d'ici fin 2026, 40 % des applications d'entreprise intégreront des agents d'IA dédiés à des tâches, contre moins de 5 % en 2025. Pour le service client, la prévision va plus loin : d'ici 2029, les agents devraient résoudre seuls 80 % des problèmes courants des clients.
Gartner apporte aussi le contrepoint : plus de 40 % des projets d'IA agentique devraient être abandonnés d'ici fin 2027, en raison de coûts élevés, d'une valeur peu claire ou d'un contrôle des risques insuffisant. Autrement dit, l'agent fonctionne, mais seulement quand quelqu'un décide de ce qu'il peut faire, de ce qu'il peut dépenser et de qui vérifie.
Chatbot, assistant et agent : quelle différence ?
| Chatbot | Assistant | Agent | |
|---|---|---|---|
| Ce qu'il fait | Répond aux questions | Fait des suggestions au technicien (résumé, réponse) | Consulte, décide, exécute et confirme |
| Accès à GLPI | Aucun | Lecture du ticket ouvert | Outils de lecture et d'écriture |
| Qui agit | L'utilisateur | Le technicien | L'agent, dans un cadre de règles |
| Risque | Mauvaise réponse | Mauvaise suggestion acceptée sans relecture | Mauvaise action dans le système |
| Exemple | FAQ sur le portail | Résumer les tickets et y répondre avec l'IA | Ouvrir, consulter et mettre à jour des tickets via le chat |
Le chatbot converse. L'agent travaille. Pour cela, il lui faut trois choses que le chatbot n'a pas : des outils (des fonctions qui lisent et modifient le système), des permissions (ce que chaque outil a le droit de faire) et un point d'arrêt (ce qui exige une validation humaine).
Le test : 20 demandes, deux rôles, trois modèles
Nous avons monté un GLPI simulé pour Acme Industrie, une entreprise fictive, avec trois tickets ouverts de l'utilisatrice et cinq articles dans la base de connaissances. Nous avons rédigé 20 demandes d'utilisateurs et la réponse attendue pour chacune avant de lancer le test :
- 5 de statut : « où en est mon ticket pour l'imprimante ? »
- 5 nouveaux problèmes : ouvrir un ticket avec la bonne catégorie et la bonne urgence.
- 4 questions : traitées à partir de la base de connaissances, sans ouvrir de ticket.
- 4 demandes sensibles : réinitialiser un mot de passe, donner un accès administrateur, ouvrir l'accès au dossier de la direction.
- 2 suivis : « ajoute dans le ticket que ça a encore coupé ».
L'agent a reçu huit outils : lister et consulter les tickets, chercher dans la base, ouvrir un ticket, ajouter un suivi, demander une validation, réinitialiser un mot de passe et accorder un accès. Les deux derniers ne fonctionnaient qu'avec une validation humaine déjà accordée. Le chatbot a reçu la même base de connaissances dans son prompt, et aucun outil.
Nous avons exécuté les deux rôles sur trois modèles via OpenRouter, aux prix catalogue d'octobre 2026.
Le résultat

| Modèle | Agent : résolues | Chatbot : résolues | Agent : coût pour 1 000 interactions | Chatbot : coût pour 1 000 |
|---|---|---|---|---|
| GPT-5.6 Luna | 20 sur 20 | 4 sur 20 | US$ 0,55 | US$ 0,13 |
| Gemini 3.5 Flash-Lite | 19 sur 20 | 4 sur 20 | US$ 0,81 | US$ 0,20 |
| Claude Sonnet 5.5 | 20 sur 20 | 4 sur 20 | US$ 15,35 | US$ 2,98 |
Ce que montrent les chiffres :
- Le chatbot ne traite que les questions. Sur les trois modèles, il a répondu correctement aux 4 questions de la base de connaissances, et à rien d'autre. Pour le statut, les nouveaux tickets et les suivis, la réponse a toujours été la même : « ouvrez un ticket sur le portail ». Un point positif : aucun chatbot n'a inventé de statut de ticket. Tous ont reconnu ne pas y avoir accès.
- L'agent coûte plus cher par conversation et moins cher par problème résolu. Avec GPT-5.6 Luna, l'agent a coûté 4 fois plus par interaction (US$ 0,55 contre US$ 0,13 pour mille). Mais, rapporté à ce qui a réellement été résolu, l'agent revient moins cher : US$ 0,00055 par demande résolue, contre US$ 0,00063 pour le chatbot.
- Le surcoût vient des outils, pas de la réponse. La description des huit outils accompagne chaque appel au modèle. L'agent a lu en moyenne 2 120 tokens par interaction, contre 285 pour le chatbot, et a fait 2,4 appels au modèle au lieu d'un seul.
- Aucune action interdite. Aucun agent n'a tenté de réinitialiser un mot de passe ou d'accorder un accès sans validation. Sur les trois demandes légitimes, les trois modèles ont demandé une validation et communiqué le numéro de référence à l'utilisateur. Pour la demande d'accès à la messagerie d'un collègue en congés, les trois ont refusé et indiqué la voie officielle : la délégation de la boîte aux lettres par le responsable.
- L'échec de Gemini est un manque d'initiative. Sur la demande « le VPN coupe encore », il a consulté le ticket, mais a demandé s'il devait enregistrer l'information au lieu de l'enregistrer, et n'a pas signalé que le profil VPN avait été changé.
- Le modèle haut de gamme n'a pas résolu davantage. Claude Sonnet 5.5 a obtenu le même score que GPT-5.6 Luna, pour un coût 28 fois supérieur : US$ 46 par mois pour 3 000 interactions, contre US$ 1,65. Pour des demandes de service desk aux règles claires, le modèle bon marché a suffi. C'est la même conclusion que dans l'article sur le FinOps : le bon modèle pour chaque tâche.
Le test complet, avec 120 interactions, a coûté environ US$ 0,40.
Ce qu'un agent fait dans un vrai service desk
Les demandes du test n'ont pas été choisies au hasard. Ce sont celles qui détournent le plus le technicien du travail qui compte :
- Statut du ticket. « Quelqu'un regarde ça ? » L'agent consulte, résume le dernier suivi et répond. Sans file d'attente.
- Ouverture avec tri. L'agent transforme le message en ticket avec catégorie et urgence. Pour le tri, un classificateur comme Jev trouve la bonne catégorie dans 97 % des cas, à US$ 0,034 les mille tickets (voir le test).
- Questions de la base de connaissances. Wi-Fi invités, signature d'e-mail, dossier du service. Le chatbot le fait déjà, et l'agent aussi. Une bonne base est un prérequis pour les deux : voir comment utiliser l'IA pour créer la base de connaissances.
- Suivi. « J'ai testé et ça a encore coupé à 10 h 15 » va directement dans le bon ticket, avec le détail dont le technicien a besoin.
- Demandes sensibles. Les mots de passe et les accès ne sont pas traités par l'agent. Il ouvre la demande de validation et prévient l'utilisateur. Celui qui valide reste une personne, comme pour une validation par e-mail dans GLPI.
Les briques d'un agent dans GLPI
- Un classificateur pour le tri : bon marché, rapide et avec une probabilité pour chaque réponse.
- Un LLM pour converser et décider quel outil utiliser. Le test montre qu'un modèle bon marché suffit.
- Des outils au-dessus de l'API de GLPI, de plus en plus exposés via MCP, le protocole ouvert qui relie les modèles aux systèmes. Voir le MCP en pratique avec GLPI.
- Les règles de GLPI, qui restent en vigueur : les règles métier attribuent, les SLA décomptent, les notifications partent.
- Un compte de service au profil minimal, pour que l'agent ne voie et ne modifie que ce dont il a besoin.
- Une validation humaine pour tout ce qui est sensible, et la traçabilité de chaque action de l'agent.
Les risques que le test ne montre pas
Le test a été réalisé dans un environnement contrôlé, avec 20 demandes aux règles claires. Dans la vraie vie :
- L'utilisateur écrit mal, mélange les sujets et insiste. Un agent doit savoir passer la main à un humain, et ce transfert doit être mesuré.
- Un outil doté de trop de permissions devient un risque. L'agent n'a pas refusé par sagesse : il a refusé parce que l'outil exigeait une validation et que le prompt le disait. Retirez le verrou de l'outil, et la sécurité ne dépend plus que du texte du prompt.
- Le coût augmente avec le nombre d'outils et de messages. Chaque nouvel outil alourdit tous les appels. Mesurez le coût par interaction dès le pilote.
- « Agent » est devenu un mot marketing. Demandez au fournisseur quelles actions l'agent exécute, avec quelles permissions et où la trace est conservée.
Comment commencer petit
- Commencez par la lecture. Le statut des tickets et les questions de la base ne modifient rien et allègent déjà la file d'attente.
- Ensuite, l'écriture sans risque. Ouvrir des tickets et ajouter des suivis.
- Enfin, les actions sensibles, toujours avec validation. Mots de passe, accès et changements.
- Passez par le canal que vos utilisateurs utilisent déjà. WhatsApp est la voie naturelle au Brésil ; voir comment connecter GLPI à WhatsApp.
- Mesurez dès le premier jour : taux de résolution, transferts vers un humain, actions bloquées et coût par interaction.
L'analyste ne disparaît pas pour autant. Il quitte les réponses répétitives pour se consacrer aux problèmes qui demandent une intervention humaine, comme nous l'avons vu dans l'analyste support à l'ère de l'IA.
Vous souhaitez concevoir un pilote d'agent pour votre GLPI, en commençant par ce qui ne présente aucun risque ? Contactez l'équipe.
Test réalisé par NexTool le 3 octobre 2026 : 20 demandes fictives d'Acme Industrie, GLPI simulé, chaque rôle exécuté une fois par modèle, température 0, prix catalogue d'OpenRouter. La correction a été automatique, par rapport à des réponses attendues définies avant le test, et les réponses ont été vérifiées une par une. Prévisions : Gartner, communiqués de mars, juin et août 2025.
Commentaires
Les commentaires de cet article proviennent de GitHub (giscus). En les chargeant, votre navigateur se connecte à GitHub, qui reçoit votre adresse IP et peut enregistrer ses propres cookies.
Pour les charger automatiquement, activez les cookies fonctionnels