NexTool Solutions

L'IA ne remplacera pas l'analyste de support, mais l'analyste qui l'utilise bien remplacera celui qui l'ignore. Dans GLPI, ce n'est pas un slogan : c'est un flux que l'on configure, mesure et ajuste. En maintenance de service desks GLPI de clients, nous avons vu l'IA échouer de deux façons - greffée sans mesure (personne ne sait si elle a aidé) et utilisée en pilote automatique (une suggestion erronée collée directement dans la solution). Ce guide montre comment opérationnaliser l'IA au quotidien du ticket, avec les requêtes et la configuration que nous exécutons sur le terrain.

Commencez par mesurer où l'IA rapporte, pas où elle impressionne

L'erreur courante est de pointer l'IA vers le ticket complexe et rare - celui qui brille en démonstration - au lieu du répétitif à fort volume, là où elle redonne vraiment du temps. Avant de brancher quoi que ce soit, trouvez où est le volume et ce qu'il coûte. Cette requête liste les catégories avec le plus de tickets sur les 90 derniers jours et le temps moyen jusqu'à la résolution, les candidats au meilleur retour pour une réponse assistée par IA, un article de base de connaissances et un tri automatique :

-- Categories a plus fort volume et temps moyen de resolution (90 jours).
-- solve_delay_stat est en secondes ; /3600 convertit en heures.
SELECT c.completename            AS categorie,
       COUNT(t.id)               AS tickets,
       ROUND(AVG(t.solve_delay_stat)/3600, 1) AS heures_pour_resoudre
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
  AND t.is_deleted = 0
  AND t.solvedate IS NOT NULL
GROUP BY t.itilcategories_id, c.completename
HAVING tickets >= 10
ORDER BY tickets DESC
LIMIT 15;

Le haut de cette liste est votre carte : ce sont les sujets où un résumé automatique, un brouillon de réponse ou un article de la base rapportent le plus. Une catégorie à fort volume et temps de résolution élevé est là où l'IA comme assistante soulage le plus la file ; une catégorie à faible volume et forte complexité reste du travail humain - et tenter de l'automatiser est du gâchis.

Tri déterministe d'abord, IA ensuite

La confusion la plus coûteuse que nous voyons est de demander à l'IA ce que les règles métier de GLPI font déjà mieux. Classer la catégorie, définir la priorité et affecter le groupe par motif sur le sujet, le demandeur ou l'entité est le travail des règles métier de tickets (RuleTicket) : déterministe, auditable et reproductible. L'IA générative relève de ce qui est flou et n'a pas besoin d'être reproductible : résumer un fil de 50 échanges, rédiger un brouillon à partir de l'historique, évaluer le ton du demandeur. Mélanger les deux rôles est à l'origine de rapports de SLA que personne ne sait expliquer. La matrice que nous utilisons pour décider qui fait quoi :

N'appelez jamais l'IA de façon synchrone dans le cycle du ticket

C'est le piège qui nous a coûté le plus d'heures en maintenance. Quand l'intégration IA - ou n'importe quel webhook externe - déclenche un appel HTTP à l'intérieur du hook de création ou de mise à jour du ticket de façon synchrone, l'enregistrement de l'analyste reste bloqué à attendre la réponse de l'API externe. Nous avons vu le bouton d'enregistrement se figer 30 à 60 secondes parce qu'un hook faisait la requête sur le moment, et l'analyste jurait que « GLPI est lent ». L'enrichissement par IA doit être asynchrone : on le met en file et on le traite hors du request, par le cron externe de GLPI. Et ce cron doit être réel (mode CLI/externe), pas le déclenchement par visite de page :

# Cron externe de GLPI (MODE_EXTERNAL) - execute les taches en file,
# y compris notifications et enrichissement asynchrone.
# A executer comme l'utilisateur du serveur web (www-data / apache), chaque minute :
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

L'erreur courante est de laisser les tâches automatiques en mode interne, déclenché par celui qui charge une page. Sans visite, rien ne tourne ; sous charge, une tâche longue bloque l'état et les autres ne s'exécutent pas. Réglez les tâches de GLPI en mode CLI et assurez le crontab ci-dessus - sinon l'automatisation « marche parfois », ce qui revient à ne pas marcher.

Ce qui reste du travail humain

L'IA rédige ; l'humain décide et signe. Diagnostiquer un problème aux variables non documentées, négocier avec un utilisateur frustré, le jugement d'escalader ou de contourner, le contexte politique qui fixe la priorité réelle - rien de tout cela n'est du ressort de l'IA. Et il y a un détail que seul celui qui opère perçoit : le champ solution du ticket alimente la base de connaissances, qui à son tour alimente la suggestion suivante de l'IA. Coller une réponse générée sans la relire n'est pas juste une erreur ponctuelle - elle entre dans le fonds et revient amplifiée dans la suggestion suivante. L'analyste de l'ère de l'IA est le relecteur qui empêche cette boucle de dégrader la qualité du service.

Les compétences techniques qui prennent de la valeur

1. Prompt avec le contexte du ticket : citer l'objet, l'historique et l'erreur exacte donne une réponse utile ; un prompt générique donne du texte générique.
2. Lire et ajuster RuleTicket : comprendre le tri déterministe qui soutient le SLA vaut plus que n'importe quelle astuce d'IA.
3. Mesurer avec SQL : les requêtes ci-dessus prouvent, avec des chiffres, où l'IA a rapporté et où elle n'a fait qu'ajouter du travail.
4. Entretenir la base de connaissances : la suggestion de l'IA vaut ce que vaut la base qui l'alimente ; un article obsolète devient une suggestion fausse.
5. Relire avant de coller : c'est vous qui signez la solution, pas l'IA. C'est la frontière qui définit l'analyste qui apporte de la valeur.

Vous voulez mettre l'IA au travail dans GLPI de façon mesurable, avec le module AI Assist intégrant OpenAI GPT et Google Gemini directement dans le ticket ? Découvrez le service de maintenance GLPI de NexTool et faites rendre l'IA sans casser ce qui fonctionne déjà.

Révisé par l'équipe NexTool Solutions.