NexTool Solutions

La gestion des problèmes, c'est ce qui sépare une exploitation qui éteint le même incendie chaque semaine de celle qui l'élimine pour de bon. En infogérance d'environnements GLPI de clients, le schéma que nous voyons le plus n'est pas un manque de processus, c'est le problème ouvert, contourné et marqué Résolu le jour même - clôturant le cycle avant même que la cause racine soit documentée. Ce guide montre où vit chaque donnée d'un problème dans GLPI, comment classer sans inventer un champ qui n'existe pas, et les pièges qui font qu'une investigation se perd.

Incident vs problème : la différence est dans la donnée, pas seulement dans le discours

La confusion classique de l'ITSM est de croire que "l'incident devient un problème". Dans GLPI ils ne partagent même pas de table : l'incident vit dans glpi_tickets, le problème dans glpi_problems, chacun avec sa propre machine à états. Ce sont des objets distincts aux objectifs opposés :

• Incident : rétablir le service le plus vite possible. C'est curatif et cela a un SLA de résolution.
• Problème : trouver et éliminer la cause racine pour que l'incident ne revienne pas. C'est préventif et cela avance à un autre rythme.

Exemple de terrain : le serveur de messagerie tombe chaque lundi. Chaque panne est un incident résolu en redémarrant le service. L'investigation qui découvre que la sauvegarde hebdomadaire épuise la mémoire et fait tomber le service, c'est le problème. Clôturer les incidents sans ouvrir le problème garantit que le lundi suivant apportera le même ticket.

La section Analyse : où vit réellement la cause racine

Ce qui distingue le formulaire du problème de celui d'un ticket ordinaire, c'est la section Analyse, qui écrit dans trois colonnes de texte dédiées de glpi_problems (exposées comme options de recherche 60, 61 et 62) :

• impactcontent - Impacts : ce que le problème affecte tant qu'il n'est pas résolu.
• causecontent - Causes : c'est là que vit la cause racine. C'est le champ le plus important de tout le processus.
• symptomcontent - Symptômes : comment le problème se manifeste pour celui qui ouvre un incident.

Le piège de terrain le plus courant que nous rencontrons : la section Analyse est repliée par défaut dans le formulaire. Le technicien remplit le titre et la description, consigne le contournement dans la chronologie et n'ouvre jamais la section - donc causecontent reste vide. Résultat : six mois plus tard, personne ne sait pourquoi ce problème a été ouvert ni ce qui a été découvert. Une cause racine qui n'atteint jamais causecontent ne devient pas de la connaissance, elle devient une rumeur.

Incident, problème ou changement : matrice de décision

Avant d'ouvrir le moindre enregistrement, l'équipe doit savoir ce qu'elle ouvre. Voici la matrice que nous utilisons au tri :

Notez que problème et changement ne s'opposent pas : le flux mature, c'est problème (trouve la cause) - changement (implémente le correctif) - base de connaissances (documente), le tout enchaîné.

Lier les incidents : l'onglet Tickets et le type de lien

Ce qui donne corps à un problème, ce sont les incidents qui lui sont rattachés. Sur le formulaire du problème, l'onglet Tickets associe les tickets liés, en écrivant dans la table glpi_problems_tickets. Le détail que presque tout le monde ignore : le lien a un type. Lier en "Lié à" n'est pas la même chose que lier en "Doublon", et cela change la lecture des rapports de récurrence. Standardisez le type de lien dans l'équipe, sinon le décompte d'incidents par problème n'a plus de sens - ce fut l'un des premiers ajustements que nous avons faits dans des environnements hérités sans gouvernance.

Le cycle de vie et le piège du "Résolu" trop tôt

Le problème a sa propre machine à états dans la colonne status de glpi_problems, et elle n'est pas identique à celle du changement. Les états que le problème utilise réellement sont :

1. Nouveau (1) - enregistré, pas encore investigué.
2. Accepté (7) - trié et pris en charge par l'équipe.
3. En cours / attribué (2) et planifié (3) - investigation en cours.
4. En attente (4) - en attente d'un tiers, d'un fournisseur ou d'une fenêtre.
5. Sous observation (8) - contournement appliqué, on surveille si la cause a vraiment été éliminée.
6. Résolu (5) et Clos (6) - cause éliminée et cycle terminé.

Voici l'erreur courante qui coûte le plus cher : appliquer le contournement et marquer le problème Résolu le jour même. Résolu signifie "la cause racine a disparu", mais un contournement n'élimine aucune cause - il masque seulement le symptôme. En infogérance nous avons commencé à utiliser le statut Sous observation (8) précisément pour cela : le contournement tient, le problème reste vivant sur le tableau, et nous ne le passons à Résolu qu'après l'arrivée du correctif définitif et une période sans récidive. Clôturer trop tôt, c'est crier victoire alors que l'incendie couve encore derrière le mur.

Contournement, solution définitive et le pont vers le changement

Un problème porte deux issues qu'il ne faut pas confondre :

• Contournement (workaround) : rétablit le service sans toucher à la cause. Documentez-le dans la chronologie ou comme tâche du problème (glpi_problemtasks) pour un usage immédiat par la première ligne.
• Solution définitive : élimine la cause racine. Elle est enregistrée dans l'onglet Solution, en écrivant dans glpi_itilsolutions (avec itemtype = 'Problem'), et exige souvent un changement pour être implémentée.

Quand le correctif touche à l'infrastructure, ouvrez le changement directement depuis le problème : le lien s'écrit dans glpi_changes_problems et maintient la traçabilité cause racine - action corrective. C'est cette ligne qui permet ensuite de prouver que le problème a réellement été résolu, et pas seulement clôturé.

Modèle de notification de clôture de problème

Dans Configuration > Notifications, le modèle de l'évènement problème utilise les balises de GLPI. Un corps de clôture qui force l'enregistrement de la cause racine réduit les problèmes clos sans leçon apprise :

Objet : [Problème ##problem.id##] Clôturé - ##problem.title##

Bonjour,

Le problème ci-dessous a été clôturé.

Titre :      ##problem.title##
Catégorie :  ##problem.category##
Statut :     ##problem.status##
Incidents :  ##problem.numberoftickets##

Symptômes :
##problem.symptoms##

Cause racine :
##problem.causes##

Détails : ##problem.url##

Les balises ##problem.causes## et ##problem.symptoms## tirent directement de causecontent et symptomcontent. Si la notification de clôture arrive avec ces blocs vides, c'est un signe clair que le problème a été clos sans cause racine documentée - et l'e-mail lui-même devient l'auditeur du processus.

Diagnostic : des problèmes avec trop d'incidents et trop peu de cause

En infogérance, nous exécutons périodiquement un SELECT qui croise l'essentiel : les problèmes encore ouverts avec beaucoup d'incidents liés mais sans cause racine renseignée. C'est la file du retravail imminent :

SELECT p.id,
       p.name AS probleme,
       p.status,
       COUNT(pt.tickets_id) AS incidents,
       IF(p.causecontent = '' OR p.causecontent IS NULL,
          'SANS CAUSE RACINE', 'ok') AS cause
FROM glpi_problems p
LEFT JOIN glpi_problems_tickets pt ON pt.problems_id = p.id
WHERE p.is_deleted = 0
  AND p.status NOT IN (5, 6)          -- exclut Résolu et Clos
GROUP BY p.id
HAVING cause = 'SANS CAUSE RACINE'
    OR incidents >= 3
ORDER BY incidents DESC;

Chaque ligne avec SANS CAUSE RACINE et plusieurs incidents est un problème qui consomme de l'effort de contournement sans avancer vers la solution. Transformer cette requête en tableau hebdomadaire change la conversation en réunion d'exploitation : au lieu de "combien de tickets avons-nous clôturés", cela devient "quelles causes avons-nous éliminées".

Bonnes pratiques d'infogérance

• N'attendez pas des dizaines d'incidents : 3 occurrences avec le même symptôme justifient déjà un problème.
• Renseignez causecontent avant de clôturer, même si la cause semble évidente ; c'est ce qui devient de la connaissance.
• Utilisez Sous observation pendant que le contournement tourne ; ne marquez Résolu qu'une fois la cause éliminée.
• Standardisez le type de lien des incidents pour que le décompte de récurrence signifie quelque chose.
• Liez le problème au changement (glpi_changes_problems) dès que le correctif touche à l'infrastructure.
• Passez en revue les problèmes ouverts chaque semaine ; un problème oublié est un incident garanti plus tard.

Si l'exploitation a besoin que les problèmes récurrents soient détectés d'eux-mêmes - au lieu de dépendre de quelqu'un qui repère le schéma - le module Problem Flow identifie les incidents répétés par catégorie et fréquence et ouvre le problème avec les tickets déjà liés. Le support NexTool configure ce flux sur le GLPI que vous utilisez déjà, du déclencheur de détection au tableau des causes éliminées.

Révisé par l'équipe NexTool Solutions.