Normaliser les tickets GLPI sans dépendre de la discipline de qui les ouvre

Une catégorie ITIL qui définit déjà priorité, SLA, groupe et technicien ; et des champs obligatoires validés côté serveur pour que le ticket ne se ferme pas à moitié vide. Le module Règles de Ticket traite les deux extrémités par configuration.

La normalisation ne se demande pas, elle se configure. Tout service desk tente de normaliser par la formation et la bonne volonté — et tout service desk découvre qu'à grande échelle, cela ne tient pas.

Le problème

Normaliser les tickets dans GLPI coûte généralement des deux côtés. À l'entrée, priorité, SLA, groupe et technicien dépendent du bon choix de celui qui ouvre — et chacun choisit à sa façon. À la sortie, le ticket se ferme avec une solution de trois mots, sans lieu renseigné et sans responsable clair.

L'alternative habituelle consiste à bâtir un enchevêtrement de règles métier dans GLPI. Cela fonctionne au début et devient une dette technique ensuite : des dizaines de règles aux ordres d'exécution interdépendants que personne n'ose modifier.

Comment fonctionnent les Règles de Ticket

Le module traite les deux extrémités par configuration déclarative, plutôt que par des règles chaînées.

  • Catégorisation automatique par catégorie ITIL — chaque catégorie porte priorité, SLA, groupe, techniciens et observateurs. Choisir la bonne catégorie renseigne le reste.
  • Champs obligatoires à la résolution ou à la clôture — validation côté serveur, pas seulement dans le formulaire : impossible à contourner via l'API ou un champ masqué.
  • Nombre minimal de caractères — dans les suivis, tâches et solutions — fini le "ok" comme solution enregistrée.
  • Un seul technicien ou groupe par ticket — évite l'affectation cumulée, où la moitié de l'équipe est formellement responsable et personne ne l'est vraiment.
  • Des règles à la carte — chaque obligation est un interrupteur indépendant : n'activez que ce qui correspond à votre exploitation.

Comment l'activer

  1. Installez NexTool sur votre GLPI 11.
  2. Rendez-vous dans NexTool > Modules et activez Règles de Ticket.
  3. Dans Paramètres par catégorie, définissez priorité, SLA, groupe et techniciens de chaque catégorie ITIL.
  4. Dans Règles de traitement, activez les obligations souhaitées et le nombre minimal de caractères.

À qui cela s'adresse

Aux exploitations qui ont besoin d'indicateurs fiables — et qui ont constaté qu'un indicateur ne vaut que ce que valent les données saisies. Également à celles soumises à un audit ou à un contrat exigeant un enregistrement minimal par intervention, et qui dépendent aujourd'hui d'une relecture manuelle.

Une réserve honnête : les champs obligatoires créent des frictions avec l'équipe. Commencez par les deux ou trois qui règlent votre vraie difficulté, pas par la totalité d'un coup.

Compatibilité

  • GLPI : 11.0+
  • Offre : Sous licence
  • Plugin : NexTool 6.x+

Prochaine étape

Les Règles de Ticket font partie de NexTool, un écosystème de modules qui étend GLPI sans personnalisation de code. Découvrez la page du module ou réservez un échange pour le voir fonctionner dans votre environnement.


Relu par l'équipe NexTool Solutions.

Questions fréquentes

Pour chaque catégorie ITIL, le module peut définir le type, l'urgence, l'impact, la priorité, les SLA de prise en charge et de résolution, le lieu, les techniciens, les groupes, les observateurs, les actifs et les modèles. La priorité peut aussi être laissée au recalcul de GLPI.

Chaque catégorie peut appliquer ses paramètres à l'ouverture du ticket, lors d'un changement de catégorie ou aux deux moments. À la création, vous pouvez aussi choisir si la catégorisation s'exécute avant ou après les règles métier ; lors d'un changement de catégorie, elle s'exécute avant en raison des points d'extension disponibles dans GLPI.

La validation s'effectue côté serveur, donc une intégration API ne contourne pas les règles applicables. Pour préserver l'expérience du demandeur, les règles de champs et de catégorie obligatoires ne bloquent jamais l'interface simplifiée ; la catégorisation automatique par catégorie continue d'y fonctionner.

Non. La fonction de catégorisation démarre activée, mais chaque catégorie doit être configurée et activée séparément. Les règles de traitement sont également indépendantes, ce qui permet de commencer uniquement par les validations nécessaires.

Oui, mais il faut éviter les fonctions qui se chevauchent. N'activez pas aussi le technicien ou le groupe unique dans Behaviors ; l'option d'Escalade qui retire les techniciens lors de l'ajout d'un groupe peut changer le résultat attendu. Smart Assign remplace les affectations avant d'ajouter le technicien et coexiste normalement avec les règles d'unicité.

Besoin d'aide ?