Nous avons demandé à Claude, en portugais courant, de regarder la file d'attente de GLPI, d'ouvrir un ticket et de nous dire ce qui avait la mauvaise urgence. Il a lu 18 tickets, ouvert le nouveau ticket, suggéré trois changements d'urgence avec la raison de chacun et n'a modifié que ce que le technicien a approuvé. Cela a représenté 8 appels au modèle, pour 0,10 $. Ce qui a relié Claude à GLPI, c'est un serveur MCP d'environ 140 lignes de Python, que vous pouvez télécharger à la fin de cet article.
Cet article poursuit la série sur l'IA au service desk, après le tri avec Jev et FinOps de l'IA : combien coûte chaque ticket.
Ce qu'est MCP, en trois paragraphes
Le MCP (Model Context Protocol) est un standard ouvert, créé par Anthropic fin 2024, pour relier des assistants d'IA à des systèmes. Au lieu que chaque outil invente sa propre intégration, le système publie un serveur MCP avec une liste d'outils (« lister la file », « ouvrir un ticket »), et n'importe quel client compatible peut alors les utiliser : Claude Desktop, Claude Code, VS Code et d'autres.
Le standard s'est vite imposé. Des études de marché indiquent que les kits de développement de MCP ont dépassé 97 millions de téléchargements par mois en mars 2026.
Pour le service desk, la conséquence est simple : l'IA sort de la fenêtre de conversation et commence à consulter et agir dans GLPI. Et cela exige de décider ce qu'elle peut faire seule et ce qui nécessite une approbation.
Les options pour relier GLPI à une IA par MCP
| Option | Fonctionnement | Pour qui |
|---|---|---|
| Plugin GLPI AI de Teclib | Plugin officiel avec un assistant dans GLPI et un serveur MCP pour les clients externes. Nécessite GLPI 11.0.7 ou supérieur et l'abonnement GLPI Network | Ceux qui ont déjà GLPI Network |
| Plugins tiers | Il existe des plugins de serveur MCP pour GLPI publiés par des partenaires | Ceux qui veulent une solution prête à l'emploi et évaluent le fournisseur |
| Serveur MCP maison sur l'API de GLPI | Un petit programme qui traduit les outils en appels à l'API | Ceux qui veulent un contrôle total sur ce que l'IA peut faire |
Nous n'avons pas testé les deux premières ; les informations proviennent de la documentation publique. Dans cet article, nous présentons la troisième, car c'est celle qui rend explicite chaque décision de sécurité.
La démo
Le scénario : le GLPI de support de NexTool, dans une entité de test avec l'entreprise fictive Acme et 25 tickets fictifs. L'assistant est Claude Sonnet 5.5, relié à notre serveur MCP.
Les outils que nous lui avons donnés :
| Outil | Type | Ce qu'il fait |
|---|---|---|
listar_fila |
lecture | Tickets ouverts, avec statut, urgence et date |
detalhe_chamado |
lecture | Description et derniers suivis d'un ticket |
abrir_chamado |
écriture | Ouvre un ticket |
definir_urgencia |
écriture | Modifie l'urgence et enregistre la raison dans un suivi privé |
adicionar_acompanhamento |
écriture | Ajoute un suivi |
La règle d'or : les outils d'écriture ont un paramètre confirmado. Les appels sans ce paramètre ne renvoient qu'un aperçu, et l'assistant doit le montrer au technicien et attendre son « vas-y ». Ainsi, l'approbation humaine ne dépend pas de la bonne volonté du modèle : elle est dans le code.
Ce qui s'est passé, demande par demande :
- « Où en est la file ? Et ouvre un ticket pour l'imprimante multifonction qui n'a plus de toner. » L'assistant a listé la file (18 tickets ouverts), signalé ceux qui étaient bloqués depuis le plus longtemps et ceux d'urgence haute, et montré l'aperçu du nouveau ticket. Il n'a rien ouvert.
- « Vas-y, ouvre-le. Et dis-moi ce qui devrait être plus urgent, avant de changer quoi que ce soit. » Il a ouvert le ticket, lu quatre tickets en détail et suggéré d'en remonter trois, avec la raison de chacun : ERP lent pour l'émission des factures (tout le service financier touché et la clôture de caisse bloquée), pas d'accès à la pointeuse (deux utilisateurs avec le même problème) et sauvegarde nocturne en échec. Il n'a rien changé.
- « Je suis d'accord pour le principal, vas-y, change seulement celui-là. » Il a montré l'aperçu de la modification : urgence de moyenne à haute, avec la raison qui irait dans le suivi.
- « Je confirme. » Il a modifié l'urgence, enregistré la raison dans un suivi privé et rappelé que les deux autres restaient tels quels.
Lors d'une première exécution du même scénario, il a aussi remarqué qu'un ticket marqué en urgence haute avait déjà été résolu par l'utilisateur lui-même, d'après le dernier suivi, et a suggéré de baisser l'urgence et de le clore. C'est le genre de lecture que personne ne fait dans une file de 18 tickets à 8 heures du matin.
Coût : 8 appels au modèle, environ 38 mille tokens en entrée et 2,7 mille en sortie, 0,10 $ avec Claude Sonnet 5.5 au prix catalogue. L'essentiel correspond à la file et aux tickets lus, qui sont renvoyés au modèle à chaque étape. Un modèle moins cher réduirait ce montant ; voir la comparaison du coût par tâche dans FinOps de l'IA.
Sécurité : les quatre verrous que nous avons utilisés
- Utilisateur de service dédié. L'assistant utilise un compte qui lui est propre, avec un jeton d'accès distant, jamais l'identifiant d'une personne. Dans GLPI, tout ce qu'il a fait apparaît dans l'historique sous le nom de ce compte.
- Profil minimal et une seule entité. À l'ouverture de la session, le serveur bascule sur un profil de technicien et restreint la session à une entité. L'assistant ne voit ni ne modifie le reste de GLPI, même s'il le demande.
- Approbation humaine dans le code. Écriture uniquement avec
confirmado=true, après le « vas-y » du technicien. Dans la démo, l'assistant a suggéré avant d'agir et montré l'aperçu avant d'enregistrer ; la modification n'a eu lieu qu'au « Je confirme ». - Journalisation de chaque action. Le serveur enregistre chaque appel d'outil dans un fichier d'audit, et GLPI conserve l'historique de chaque ticket modifié.
Et ce qu'il ne faut pas exposer : les outils d'administration (utilisateurs, profils, règles), la suppression de tickets et toute donnée personnelle que l'assistant n'a pas besoin de lire. Le jeton reste hors du code, dans une variable d'environnement ou dans le coffre-fort de mots de passe du système.
Où cela vaut la peine, et où non
Cela vaut la peine : - Résumer la file du jour et signaler ce qui est bloqué. - Ouvrir un ticket à partir d'une conversation, avec catégorie et urgence suggérées. - Revoir les urgences et proposer des modifications avec la raison. - Répondre à « quel est le statut du ticket X » sans ouvrir GLPI.
Cela ne vaut pas la peine (pour l'instant) : - Action irréversible sans approbation : suppression, changement de droits, clôture en masse. - Décision qui exige un contexte absent de GLPI, comme une conversation de couloir ou une priorité politique. - Remplacer le tri à fort volume : pour classer des milliers de tickets, un classificateur comme Jev est moins cher et plus rapide (voir le test).
Téléchargez le serveur d'exemple
Le serveur MCP d'exemple contient les cinq outils de la démo, l'approbation par confirmado, le journal d'audit et les instructions pour le relier à Claude Desktop ou à Claude Code. Il utilise l'API REST v1, qui existe dans GLPI 10 (apirest.php) et dans GLPI 11 (api.php/v1) ; nous l'avons testé sur la 11. Testez-le dans une entité ou dans un GLPI de test avant la production.
Vous préférez une solution prête à l'emploi ? NexTool MCP for GLPI fait cela avec plus de 160 outils — open source à exécuter en local, ou hébergé, avec connexion et connecteur pour Claude et ChatGPT. Découvrez NexTool MCP for GLPI ou consultez le dépôt sur GitHub.
Besoin d'aide pour mettre cela en place en toute sécurité dans votre GLPI ? Parlez à l'équipe.
Démo de NexTool le 4 octobre 2026, sur le GLPI 11.0.7 de notre support, avec une entité de test et des données fictives. Le ticket créé et l'urgence modifiée ont été rétablis à la fin. Le modèle a été utilisé via OpenRouter au prix catalogue. Concernant le plugin GLPI AI et les plugins tiers, les informations proviennent de la documentation publique.
