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 avec des règles par catégorie ou groupe, en appliquant l'équilibrage de charge ou la rotation séquentielle à 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 les hooks de création et de mise à jour des tickets de GLPI. La configuration se fait par catégorie ou par groupe, avec deux modes de distribution qui peuvent coexister dans la même opération :
- Attribution par catégorie - définit quel technicien ou groupe reçoit les tickets d'une catégorie spécifique. Idéal pour les équipes spécialisées, où chaque domaine (infrastructure, ERP, réseaux) a un responsable fixe.
- Attribution par groupe - distribue les tickets entre les membres d'un groupe 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 dans
plugin_nextool_smartassign.log, 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 |
| É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 | Fichier propre auditable |
Comment l'activer
- Installez le plugin NexTool dans GLPI.
- Accédez à Configuration > NexTool > Modules.
- Activez le module Smart Assign.
- Ouvrez la configuration du module et enregistrez les règles : choisissez l'attribution par catégorie et/ou par groupe et, pour chaque groupe, le mode de distribution (équilibrage ou rotation).
- Ouvrez un ticket de test dans la catégorie configurée et confirmez le technicien attribué sur le ticket lui-même et sur la ligne correspondante du journal.
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 est en congé ne reçoit tout simplement rien. 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 :
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 écrite en texte clair dans le journal du module, ce qui raccourcit beaucoup l'enquête « pourquoi ce ticket m'est-il arrivé » :
[2026-03-12 09:41:22] smartassign: ticket #10482 categorie "Infra/Reseau" -> groupe "N2 Reseaux" mode=equilibrage technicien=marina.souza (ouverts=3)
[2026-03-12 09:43:05] smartassign: ticket #10483 groupe "Support N1" mode=rotation technicien=paulo.lima (suivant dans la file)
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 3.x+
- PHP : 8.1+
É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.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.