Un changement bien géré dans GLPI n'est pas celui qui a le plus de champs remplis, c'est celui que vous pouvez annuler à 2 h du matin quand il échoue. Ce guide parcourt le cycle de vie complet des changements dans GLPI : de quelle section et colonne vient chaque information, comment modéliser des types de changement que GLPI natif n'a pas, et les pièges que nous avons vus faire échouer des fenêtres de maintenance dans les environnements que nous exploitons pour des clients.
Le modèle de données derrière un changement
Tout changement vit dans la table glpi_changes. Au-delà des champs évidents (nom, contenu, urgence, impact, priorité), ce qui distingue un changement d'un ticket ordinaire, ce sont les colonnes de texte que GLPI expose dans la section analyse et plans du formulaire :
impactcontent- analyse d'impact : ce qui casse si cela tourne mal.controlistcontent- liste de contrôle : points de vérification.rolloutplancontent- plan de déploiement (le cœur l'étiquette « Deployment plan ») : le pas à pas du déploiement.backoutplancontent- plan de retour arrière/rollback (le cœur l'étiquette « Backup plan ») : comment revenir en arrière.checklistcontent- liste de contrôle de validation après implémentation.
Savoir que ces informations sont des colonnes distinctes, et non du texte libre dans la description, c'est ce qui permet d'auditer la gouvernance directement en base, comme nous le montrons plus bas.
« Type de changement » dans GLPI : le champ qui n'existe pas
L'erreur la plus courante de ceux qui viennent d'outils comme ServiceNow est de chercher un sélecteur « Type : Normal / Urgence / Standard ». Il n'existe pas dans GLPI natif. Le changement a une catégorie (itilcategories_id), une urgence, un impact et une priorité, mais pas de champ de type ITIL. Vous modélisez la classification avec des catégories ITIL dédiées, ce qui alimente aussi les rapports et les règles métier.
| Classe ITIL | Comment la modéliser dans GLPI | Approbation | Exemple |
|---|---|---|---|
| Normal | Catégorie « Changement > Normal » + validation obligatoire | Formelle, avant implémentation | Montée de version de GLPI, migration de serveur |
| Urgence | Catégorie « Changement > Urgence » + priorité Très haute | Simplifiée, possible a posteriori | Correction d'une CVE critique en production |
| Standard (pré-approuvé) | Modèle de changement récurrent + validation dispensée | Pré-approuvé, sans nouveau tour | Redémarrage de service, règle de pare-feu déjà homologuée |
Le cycle de vie, statut par statut
GLPI fait passer le changement par sa propre machine à états, plus riche que celle du ticket. L'état courant se trouve dans la colonne status de glpi_changes :
- Nouveau (1) - enregistré sous Assistance > Changements, avec description, justification, impact et risque.
- Évaluation (4) - analyse d'impact et de risque ; remplissage des sections analyse et plans.
- Approbation (11) - tour de validation avec les approbateurs.
- Accepté (12), Test (13), Qualification (14) - planification et exécution des tâches (
glpi_changetasks), chacune consignée dans la chronologie. - Résolu (5) - revue après implémentation ; confirme le succès et consigne les leçons apprises.
- Clos (6) - documentation finale et clôture.
Chaque tâche de changement porte actiontime (temps réel) et state (à faire/fait), ce qui permet de comparer l'effort planifié à l'effort dépensé - une donnée que nous utilisons pour calibrer les estimations des fenêtres suivantes.
Approbation : validation native versus multiniveau
L'approbation native s'écrit dans glpi_changevalidations (statut 2 = en attente, 3 = approuvé, 4 = refusé). Le détail qui piège presque tout le monde : la validation de GLPI est informative, ce n'est pas une barrière. Rien n'empêche de faire passer le changement d'Approbation à Test alors que la validation est encore en attente ; GLPI ne bloque pas la transition. Si votre gouvernance exige que personne n'implémente sans approbation enregistrée, la validation native seule n'y suffit pas. C'est là qu'intervient Approval Flow, avec une approbation multiniveau et des routes conditionnelles qui bloquent réellement l'avancement.
Modèle de notification de la demande d'approbation
Sous Configuration > Notifications, le modèle de l'événement de validation de changement utilise les balises de GLPI. Un corps concis réduit les allers-retours :
Objet : [Changement ##change.id##] Approbation demandée - ##change.title##
Bonjour,
Un changement attend votre approbation.
Titre : ##change.title##
Catégorie : ##change.category##
Urgence : ##change.urgency##
Impact : ##change.impact##
Priorité : ##change.priority##
Description :
##change.content##
Approuver ou refuser sur :
##change.url##
Garder urgence, impact et priorité dans le corps évite à l'approbateur d'ouvrir le changement juste pour décider. Cela réduit le temps passé au statut Approbation, là où la plupart des fenêtres prennent du retard.
Diagnostic : changements sans plan de retour arrière
En exploitation, le champ que nous trouvons le plus souvent vide est précisément le plus critique : backoutplancontent. La section plans arrive repliée dans l'interface, donc le technicien remplit la description et les tâches mais jamais le plan de retour arrière, et la panne n'apparaît que lorsque le changement tourne mal et que personne ne sait revenir en arrière. Nous exécutons ce SELECT tous les vendredis, avant la fenêtre du week-end :
SELECT c.id,
c.name AS changement,
c.status,
IF(c.backoutplancontent = '' OR c.backoutplancontent IS NULL,
'SANS ROLLBACK', 'ok') AS plan_retour
FROM glpi_changes c
WHERE c.is_deleted = 0
AND c.status NOT IN (5, 6) -- exclut Résolu et Clos
ORDER BY c.date DESC;
Toute ligne avec SANS ROLLBACK est un changement qui ne devrait pas entrer en fenêtre. Nous en faisons une règle métier : sans plan de retour arrière renseigné, l'approbation ne passe pas.
Bonnes pratiques d'exploitation
- Documentez
backoutplancontentavant de demander l'approbation, pas après avoir implémenté. - Reliez le changement au problème d'origine (
glpi_changes_problems) pour conserver la traçabilité cause racine vers action corrective. - Créez des modèles de changement pour les récurrents (standard) et dispensez-les de validation.
- Planifiez hors des heures de pointe et enregistrez le
actiontimeréel pour calibrer les estimations. - Bouclez le cycle par la revue après implémentation, même quand tout s'est bien passé ; c'est ce qui devient base de connaissances.
Si l'exploitation a besoin d'une barrière d'approbation qui bloque réellement l'avancement et d'une gouvernance des changements auditable, le support NexTool configure ce flux avec le module Approval Flow sur le GLPI que vous utilisez déjà.
Révisé par l'équipe NexTool Solutions.
