Savoir où vous en êtes est la première étape pour savoir où aller. Ce guide montre comment évaluer le niveau de maturité ITSM de votre exploitation à partir de signaux objectifs extraits de GLPI lui-même - sans dépendre de la perception - et comment prioriser les prochaines étapes de votre évolution.
La maturité ne se mesure pas à l'opinion
La question "à quel niveau sommes-nous ?" reçoit presque toujours une réponse émotionnelle : celui qui éteint des incendies tous les jours jure être au niveau 1, et le responsable qui a approuvé l'achat de l'outil jure être au niveau 4. Les deux ont tort, car les deux mesurent un ressenti, pas un processus. La maturité ITSM est le degré de formalisation, d'automatisation et d'optimisation de la gestion des services, et elle laisse des traces mesurables dans la base de données de l'outil. Avant d'engager un conseil ou d'acheter d'autres modules, il vaut la peine d'extraire ces traces.
Diagnostic objectif : interrogez GLPI lui-même
Trois signaux séparent nettement une exploitation mature d'une exploitation immature : combien de tickets sont réellement catégorisés, combien ont un SLA associé, et combien de temps ils mettent à être résolus. Exécutez la requête ci-dessous directement sur la base de données (lecture seule) sur les 90 derniers jours :
-- Signaux de maturite sur les 90 derniers jours (GLPI 10/11)
SELECT
COUNT(*) AS total_tickets,
ROUND(100 * SUM(itilcategories_id > 0) / COUNT(*), 1) AS pct_categorises,
ROUND(100 * SUM(slas_id_ttr > 0) / COUNT(*), 1) AS pct_avec_sla_resolution,
ROUND(AVG(TIMESTAMPDIFF(HOUR, date, solvedate)), 1) AS heures_moyennes_pour_resoudre
FROM glpi_tickets
WHERE date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND is_deleted = 0
AND solvedate IS NOT NULL;Lecture de terrain : en dessous de 70% de tickets catégorisés, oubliez la gestion des problèmes - vous n'avez aucune base pour regrouper les récurrences. En dessous de 50% avec un SLA associé, vos rapports de conformité ne mesurent que la fraction qui a une échéance, pas toute l'exploitation. Et si la moyenne d'heures pour résoudre varie beaucoup d'un mois à l'autre, le processus reste ad-hoc même si un outil existe.
Matrice : niveau x signal dans GLPI x action
Utilisez la matrice pour situer votre niveau d'après ce que GLPI montre aujourd'hui, pas d'après ce que vous aimeriez qu'il montre :
| Niveau | Signal observable dans GLPI | Prochaine action technique | Métrique cible |
|---|---|---|---|
| 1 - Ad-hoc | Aucun outil, ou tickets sans catégorie/SLA | Déployer GLPI, créer l'entité et les profils | 100% des tickets dans l'outil |
| 2 - Reproductible | Tickets ouverts, mais la catégorie "Autre" domine | Arbre de catégories allégé + SLA initial | >70% catégorisés |
| 3 - Défini | Catégories et SLA en usage ; affectation manuelle | Règles métier (affectation), base de connaissances | SLA associé >90% |
| 4 - Géré | Métriques collectées ; cron en CLI | Gestion des problèmes et des changements, tableaux de bord | SLA respecté >90% |
| 5 - Optimisé | Décision par la donnée ; automatisation mature | Analyse de récurrence, intégration au métier | Baisse d'année en année de la récurrence |
Le détail d'exploitation qui fausse toute métrique
Dans le maintien en condition opérationnelle des environnements clients, l'indicateur le plus trompeur est le "SLA respecté" lorsque les actions automatiques de GLPI s'exécutent en mode GLPI (déclenchées par le navigateur) au lieu de CLI. Dans ce mode, le recalcul des échéances, les escalades et les notifications ne se produisent que lorsque quelqu'un ouvre une page du système. Résultat : à 3 h du matin, sans personne connecté, aucun ticket n'est escaladé, et le rapport du lendemain affiche un SLA vert qui ne correspond pas à la réalité. L'erreur courante est de faire confiance au tableau de bord sans vérifier, dans Configuration > Actions automatiques, quel est le mode d'exécution. La correction consiste à tout standardiser en CLI et à planifier le cron du système :
# /etc/cron.d/glpi - execute les actions automatiques chaque minute
# Valable pour GLPI 10 et 11 (front/cron.php est portable ; sur le 11 evitez de dependre de la console)
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/nullAprès le passage en CLI, dans Actions automatiques, basculez le mode d'exécution de chaque tâche critique (queuednotification, slaticket, closeticket) en CLI. Sans cela, vous pouvez être au niveau 4 sur le papier et au niveau 2 dans la pratique.
Le piège de l'arbre de catégories hérité
Autre faux pas récurrent : monter d'un niveau en croyant qu'"avoir beaucoup de catégories" est un signe de maturité. C'est l'inverse. Nous avons repris un environnement qui comptait environ 400 catégories importées d'un système hérité, imbriquées sur cinq niveaux. En pratique, les agents ne trouvaient pas la bonne catégorie, choisissaient la première venue et le champ devenait du bruit. Nous avons recatégorisé l'historique des derniers mois, réduit l'arbre à un peu plus de deux douzaines de catégories reflétant ce que l'équipe traite réellement, et ce n'est qu'alors que les rapports par cause ont commencé à avoir du sens. La règle pratique que nous appliquons : si une catégorie n'a reçu aucun ticket depuis 90 jours, elle est candidate à disparaître. Trop de catégories ne mesurent pas la maturité ; elles gênent le tri et faussent toute analyse de récurrence.
Checklist d'évaluation rapide
- Existe-t-il un outil ITSM avec tous les tickets à l'intérieur ? (oui = niveau 2+)
- Plus de 70% des tickets sont-ils dans une catégorie précise, pas "Autre" ? (oui = niveau 3+)
- Le SLA est-il associé et le cron tourne-t-il en CLI validé ? (oui = niveau 3+)
- Les métriques sont-elles collectées et revues dans une réunion fixe ? (oui = niveau 4+)
- Les décisions viennent-elles de la donnée, pas de la perception ? (oui = niveau 4+)
- Y a-t-il une gestion des problèmes active qui réduit la récurrence ? (oui = niveau 5)
Plan d'évolution : un niveau à la fois
N'essayez pas de sauter des étapes - chaque niveau s'appuie sur le précédent. Si le diagnostic a montré une catégorisation faible, la prochaine étape n'est pas d'acheter de l'IA ; c'est de réduire l'arbre des catégories à ce que l'équipe utilise réellement (en pratique, 15 à 25 catégories couvrent la plupart des exploitations de taille moyenne) et de former le tri. Ce n'est qu'une fois la catégorisation stabilisée que la gestion des problèmes prend du sens, car vous pouvez enfin regrouper les incidents par cause. Si vous êtes au niveau 1-2, commencez par le déploiement de GLPI et la configuration de base avant toute automatisation.
D'après notre expérience d'exploitation, le gain de maturité le plus rapide ne vient pas d'une nouvelle fonctionnalité, mais du nettoyage de ce qui existe déjà : cron en CLI, catégories allégées et SLA associé à 100% des types de tickets. Ces trois ajustements font passer une exploitation du niveau 2 au niveau 3 en quelques semaines, sans coût de licence supplémentaire.
Si vous souhaitez un diagnostic de maturité avec ces indicateurs extraits de votre propre environnement, NexTool évalue et maintient GLPI pour les exploitations B2B - de la configuration de base au niveau optimisé.
Révisé par l'équipe NexTool Solutions.
