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 :
| Fonction | Règles métier natives | Smart Assign |
|---|---|---|
| Attribuer par catégorie ou groupe | Oui (destination fixe) | Oui, entre les techniciens du groupe responsable de la catégorie |
| Équilibrage de charge (moins de tickets ouverts) | Non | Oui |
| Rotation séquentielle (round-robin) | Non | Oui |
| S'adapte à l'arrivée/au départ de techniciens du groupe | Manuel | Automatique |
| Enregistrement dédié de la décision d'attribution | Historique générique | Onglet Journaux du module, avec le motif quand il ne distribue pas |
Comment l'activer
- Installez le plugin NexTool dans GLPI.
- Accédez à Configuration > NexTool > Modules.
- Activez le module Smart Assign.
- 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.
- 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.
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