Gestion des problèmes ITSM : pourquoi les mêmes pannes reviennent

Luigi F. de PeopleCert l'a dit sans détour dans la communauté des professionnels ITSM : la gestion des problèmes est toujours brisée en 2026. Les incidents majeurs se répètent. L'analyse des causes racines est absente. Les équipes restent en mode réactif. Ce diagnostic circule depuis des années dans les cercles ITSM, et pourtant la situation ne s'améliore pas dans la majorité des organisations. Cet article part de ce constat pour identifier les trois raisons structurelles qui empêchent la gestion des problèmes de fonctionner, et propose un cadre d'autodiagnostic en cinq questions pour savoir où vous en êtes.

‍

Les incidents se répètent parce que les données ne sont pas liées entre elles

‍

La cause la plus fréquente que nous observons sur le terrain est aussi la plus simple : les incidents sont gérés dans un outil, les problèmes dans un autre, et la base de connaissances existe quelque part ailleurs. Dans ce contexte, l'analyste qui ouvre un dossier de problème repart pratiquement de zéro. Il n'a pas accès à l'historique des incidents reliés, aux éléments de configuration touchés ni aux solutions temporaires déjà appliquées. Il reconstruit à la main ce qui devrait déjà être là.

Un logiciel ITSM configuré correctement crée des liens natifs entre l'incident, le problème qui en découle, les éléments de la CMDB concernés et la base de connaissances mise à jour à la résolution. Quand cette chaîne est brisée, les équipes résolvent les symptômes plutôt que les causes, et le cycle recommence.

‍

La solution de contournement et la résolution permanente sont traitées de la même façon

‍

Dans de nombreux centres de services, un ticket fermé est un ticket fermé, peu importe qu'il ait été résolu définitivement ou simplement contourné. Cette absence de distinction entre solution temporaire et résolution permanente est l'un des angles morts les plus coûteux de la gestion des problèmes.

Lors d'une rencontre récente avec une équipe TI d'un cégep québécois, nous avons observé exactement cette situation : des tickets fermés avec la note « redémarrage du service, surveillance en cours ». Aucun lien vers un dossier de problème. Aucune investigation déclenchée. Trois semaines plus tard, le même incident revenait. L'équipe l'avait pourtant résolu. Un processus clair doit distinguer explicitement les deux cas et déclencher automatiquement une investigation lorsque le même incident se répète au-delà d'un seuil défini. Sans cette règle dans le processus, la solution de contournement devient la norme par défaut.

‍

Les métriques suivies mesurent la vitesse de fermeture, pas la récurrence

‍

C'est ce qui est souvent répété dans la communauté ITIL : les KPI actuels mesurent la fermeture, pas la résolution. Le temps moyen de résolution, le volume de tickets fermés, le taux de respect des SLA. Ces indicateurs disent si l'équipe a été rapide. Ils ne disent pas si le problème est réglé.

Une organisation qui ferme cent tickets en quarante-huit heures et qui les rouvre pour les mêmes raisons deux semaines plus tard n'a pas une bonne performance ITSM. Elle a une bonne performance de fermeture de tickets. Le taux de récurrence des incidents, le MTBF (temps moyen entre pannes) et le nombre de problèmes connus avec solution permanente documentée sont des indicateurs beaucoup plus honnêtes de la maturité d'un département. Si vous ne suivez pas ces métriques, vous ne pilotez pas votre gestion de problèmes: vous la subissez.

La conformité ITIL ne consiste pas à cocher des processus sur papier. Elle consiste à configurer des règles qui rendent ces distinctions obligatoires dans l'outil, pas facultatives selon la charge du moment.

‍

Ce que « faible maturité en gestion de groblème » signifie concrètement

‍

Nous avons accompagné de nombreuses organisations publiques et privées dans la structuration de leurs processus ITSM. Dans la plupart des cas, le point de départ ressemblait à ceci : des incidents bien documentés à l'ouverture, une résolution rapide quand l'équipe connaît la procédure, mais aucun mécanisme systématique pour capitaliser sur ces résolutions. Chaque technicien résout selon son expérience personnelle. La base de connaissances est vide ou périmée. Les nouveaux arrivants recommencent de zéro.

La faible maturité en gestion de problèmes ne se manifeste pas par une absence totale de processus mais plutôt par des processus incomplets qui s'arrêtent à la fermeture du ticket plutôt que de se prolonger jusqu'à l'élimination de la cause. La CMDB joue un rôle central ici : elle permet de voir quels éléments de configuration sont impliqués dans les incidents récurrents et d'identifier les zones de fragilité dans l'environnement avant qu'elles ne deviennent des pannes.

‍

Cinq questions pour diagnostiquer où vous en êtes

Avant de changer d'outil ou de refondre vos processus, posez-vous ces cinq questions :

1. Vos incidents sont-ils liés à des dossiers de problèmes dans le même outil?

Si vos analystes ouvrent manuellement un courriel pour signaler un problème récurrent, la réponse est non.

2. Avez-vous une règle explicite pour distinguer solution de contournement et résolution permanente?

Si tous vos tickets se ferment de la même façon, vous n'avez pas cette distinction.

3. Suivez-vous le taux de récurrence de vos incidents?

Si votre tableau de bord montre le volume et le délai mais pas la répétition, vous mesurez la vitesse, pas la solidité.

4. Votre base de connaissances est-elle alimentée à chaque résolution?

Si la réponse est « ça dépend du technicien », elle ne l'est pas systématiquement.

5. Vos dossiers de problèmes aboutissent-ils à des solutions permanentes documentées?

Si vous ne pouvez pas répondre avec un chiffre, c'est un signal.

La gestion de problèmes n'est pas une fonctionnalité à activer. C'est une discipline qui nécessite des liens natifs entre les données, des règles explicites dans les flux de travail et des métriques honnêtes. Si vos mêmes incidents reviennent mois après mois, le problème n'est probablement pas votre équipe : c'est la structure dans laquelle elle travaille.

‍

Vous voulez voir ce que ça donne avec une plateforme configurée pour sortir du mode réactif ? Demandez une démonstration : nous partons de votre réalité, pas d'un scénario générique.

‍