Attribution automatique des tickets dans GLPI avec Smart Assign

L'attribution manuelle des tickets devient un goulot d'étranglement du centre de services. Le module Smart Assign de NexTool distribue automatiquement les tickets de chaque catégorie entre les techniciens du groupe responsable, avec équilibrage de charge ou rotation séquentielle, et enregistre chaque décision dans un journal auditable. Découvrez comment il fonctionne, comment l'activer et quand les règles métier natives de GLPI restent le meilleur choix.

Dans cet article8 sections

Attribuer chaque ticket au bon technicien semble trivial, mais dans un centre de services réel cette décision manuelle devient un goulot d'étranglement : quelqu'un doit lire la file, comprendre la catégorie et répartir - et pendant ce temps l'horloge du SLA tourne déjà. Le module Smart Assign de NexTool automatise cette étape par catégorie, en appliquant l'équilibrage de charge ou la rotation séquentielle entre les techniciens du groupe responsable à l'instant même où le ticket est créé.

Le problème

Une opération sans attribution automatique a toujours un point de décision unique : quelqu'un ouvre la file des tickets nouvellement créés, lit la catégorie et l'objet et décide vers qui les acheminer. Ce rôle revient souvent au coordinateur ou à l'analyste le plus expérimenté - précisément la personne que vous voulez le moins voir bloquée dans un tri répétitif.

L'effet pratique apparaît de deux façons. D'abord, la file grossit aux heures de pointe parce que personne n'a encore pris le ticket ; il existe, il est ouvert, mais il reste sans responsable pendant que le délai court. Ensuite, la répartition devient inégale : un technicien accumule quinze tickets tandis qu'un autre en a trois, non par compétence mais selon qui regardait l'écran à ce moment-là. Les deux scénarios érodent le SLA et la perception de qualité de l'utilisateur.

Smart Assign supprime cet intermédiaire. Dès que le ticket est créé, le module évalue les règles configurées et définit le responsable avant même que la file ne soit ouverte par un humain. Le tri cesse de dépendre de qui est de garde devant l'écran.

Comment fonctionne Smart Assign

Le module agit sur le hook de création des tickets de GLPI : les tickets existants ne sont pas redistribués. La distribution s'active par catégorie, le technicien vient du groupe responsable de la catégorie et le mode de distribution, choisi dans l'onglet Fonctionnalités du module, vaut pour tout l'environnement :

  • Distribution par catégorie - dans chaque catégorie ITIL, l'onglet Smart Assign active ou désactive la distribution et affiche le groupe responsable, les techniciens éligibles et le critère de choix. Idéal pour les équipes spécialisées, où chaque domaine (infrastructure, ERP, réseaux) a son propre groupe.
  • Techniciens du groupe responsable - les techniciens actifs du groupe responsable de la catégorie participent, avec la possibilité d'exclure les responsables du groupe ; celui qui reçoit le ticket est choisi selon l'un des deux modes ci-dessous.
  • Mode équilibrage (moins de tickets) - le ticket va au technicien du groupe ayant le plus petit nombre de tickets ouverts à ce moment. Il égalise la charge réelle, pas la charge théorique.
  • Mode rotation (séquentiel) - les tickets sont distribués dans l'ordre, un technicien après l'autre, indépendamment de la charge. Utile quand tous ont une capacité équivalente et que le volume n'est pas le critère.
  • Adaptation automatique - quand quelqu'un rejoint ou quitte le groupe, la rotation et l'équilibrage s'ajustent d'eux-mêmes, sans reconfiguration manuelle.
  • Journal dédié - chaque décision est enregistrée en base de données et apparaît dans l'onglet Journaux du module, avec le motif quand le ticket n'est pas distribué, ce qui offre une traçabilité pour l'audit de processus et pour enquêter sur les réclamations du type « pourquoi ce ticket m'est-il arrivé ».

Smart Assign face aux règles métier natives

GLPI résout déjà une partie de cela avec les Règles métier pour les tickets (Configuration > Règles). Elles peuvent attribuer selon des critères comme la catégorie, mais de manière statique : elles pointent toujours vers la même destination. Le tableau ci-dessous montre où s'arrête chaque approche :

FonctionRègles métier nativesSmart Assign
Attribuer par catégorie ou groupeOui (destination fixe)Oui, entre les techniciens du groupe responsable de la catégorie
Équilibrage de charge (moins de tickets ouverts)NonOui
Rotation séquentielle (round-robin)NonOui
S'adapte à l'arrivée/au départ de techniciens du groupeManuelAutomatique
Enregistrement dédié de la décision d'attributionHistorique génériqueOnglet Journaux du module, avec le motif quand il ne distribue pas

Comment l'activer

  1. Installez le plugin NexTool dans GLPI.
  2. Accédez à Configuration > NexTool > Modules.
  3. Activez le module Smart Assign.
  4. Dans l'onglet Fonctionnalités du module, choisissez le mode de distribution (équilibrage ou rotation), valable pour tout l'environnement, et la façon de compter la charge (par groupe ou par catégorie). Ensuite, dans chaque catégorie ITIL, activez la distribution dans l'onglet Smart Assign et vérifiez le groupe responsable.
  5. Ouvrez un ticket de test dans la catégorie configurée et confirmez le technicien attribué sur le ticket lui-même et dans l'onglet Journaux du module.

Ce que nous avons appris en l'exploitant

Dans les opérations clientes que nous maintenons, le schéma qui casse le plus n'est pas l'absence de règle - c'est la « règle qui pointe vers une personne ». Le client crée une règle métier native envoyant toute la catégorie « Réseau » au technicien X. Cela fonctionne pendant des mois, jusqu'à ce que le technicien X parte en congé : les tickets continuent de lui être attribués, ils restent en attente, et le SLA se rompt en silence parce que la file « avait un responsable ». L'erreur courante est de confondre avoir un propriétaire et être traité. C'est pourquoi, pour les groupes de plus de trois techniciens, nous migrons ces règles statiques vers le mode équilibrage de Smart Assign : au lieu d'un nom fixe, le ticket arrive chez celui qui a le moins de charge à cette minute, et celui qui part en congé cesse de recevoir dès qu'il est retiré du groupe responsable ou désactivé dans GLPI. Un détail qui n'apparaît qu'en exploitation : l'équilibrage compte les tickets ouverts, pas ceux fermés dans la journée, donc un technicien qui résout vite recommence à recevoir rapidement - c'est ainsi qu'on égalise la charge réelle, et non la théorique.

Le même comptage que le module utilise pour décider de la destination peut être reproduit en base pour auditer la distribution. Cette requête liste les tickets ouverts par technicien attribué, exactement le nombre que le mode équilibrage minimise quand la charge est comptée par groupe, le réglage par défaut :

SELECT u.name AS technicien, COUNT(t.id) AS tickets_ouverts
FROM glpi_tickets t
JOIN glpi_tickets_users tu ON tu.tickets_id = t.id AND tu.type = 2
JOIN glpi_users u ON u.id = tu.users_id
WHERE t.status IN (1,2,3,4)   -- nouveau, en cours, planifie, en attente
  AND t.is_deleted = 0
GROUP BY u.id
ORDER BY tickets_ouverts DESC;

Et chaque décision est enregistrée dans l'onglet Journaux du module, dans la grille standard de GLPI, avec des filtres par niveau, événement, ticket et technicien : à qui le ticket a été attribué et, quand il ne l'a pas été, le motif (catégorie inactive, catégorie sans groupe responsable ou groupe sans technicien éligible). Cela raccourcit beaucoup l'enquête « pourquoi ce ticket m'est-il arrivé ».

Pour qui (et quand ne pas l'utiliser)

Smart Assign apporte une valeur claire dans :

  • Les équipes de trois techniciens ou plus où la répartition inégale est récurrente.
  • Les centres de services avec des pics de volume où le coordinateur devient un goulot de tri.
  • Les environnements avec des catégories bien définies et des équipes spécialisées par domaine.
  • Les opérations qui doivent prouver, lors d'un audit, comment les tickets ont été distribués.

Quand cela n'en vaut pas la peine : dans les équipes d'un ou deux techniciens le gain est marginal - le partage manuel ne coûte rien. Et quand l'attribution dépend d'un contexte sensible (client VIP, expert spécifique pour un système critique), ce routage fin reste meilleur dans les règles métier natives ; dans ce cas, utilisez Smart Assign pour le volume courant et réservez les règles natives aux exceptions, au lieu d'empiler les deux décisions sur le même ticket.

Compatibilité

  • GLPI : 10.x et 11.x
  • Plan : FREE
  • Plugin : NexTool 6.10.1+
  • PHP : 8.0+

Étape suivante

Smart Assign fait partie de NexTool, un plugin modulaire pour GLPI. Découvrez les autres modules ou parlez à l'équipe pour une démonstration dans votre environnement.


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

Questions fréquentes

Le module Smart Assign de NexTool attribue chaque ticket au moment de la création, dans les catégories où la distribution est activée et entre les techniciens du groupe responsable, en utilisant l'équilibrage de charge (moins de tickets ouverts) ou la rotation séquentielle. La décision a lieu avant même qu'un humain ouvre la file.

Les règles métier natives attribuent de manière statique, toujours vers la même destination. Smart Assign ajoute l'équilibrage par charge réelle et la rotation séquentielle, s'adapte seul à l'arrivée et au départ de techniciens du groupe et enregistre chaque décision dans son propre journal.

Oui. Le mode équilibrage compte les tickets ouverts (statut nouveau, en cours, planifié et en attente) de chaque technicien et envoie le nouveau ticket à celui qui en a le moins. Un technicien qui résout vite recommence vite à recevoir, égalisant la charge réelle.

Oui. Smart Assign propose un mode rotation qui distribue les tickets dans l'ordre séquentiel entre les membres du groupe, indépendamment de la charge. C'est utile quand tous ont une capacité équivalente.

Oui, le module est FREE. Il requiert le plugin NexTool 6.10.1 ou supérieur et est compatible avec GLPI 10.x et 11.x, en exigeant PHP 8.0 ou plus récent.

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

Besoin d'aide ?