ITSM : quand le processus finit par étouffer le service

Un soir, dans une salle de crise, j'ai assisté à une scène qui résume tout. Un service applicatif critique était à terre. Le métier perdait de l'argent à la minute. L'équipe technique savait quoi faire : redémarrer. Mais pour redémarrer, il fallait un changement. Et pour ce changement : sept validations. Le CAB n'était que le lendemain. Tout le monde regardait le processus comme on regarde un mur.

Ce soir-là, l'ITSM n'était plus là pour protéger le service. Il était devenu son principal obstacle. Et c'est, à mes yeux, la maladie la plus répandue des DSI matures : elles ont tellement bien outillé leurs processus qu'elles ont oublié à quoi ils servaient.

Le culte du processus

L'ITSM est né d'une excellente idée : arrêter d'improviser, structurer la gestion des incidents, des problèmes, des changements, pour livrer un service fiable. Le problème survient quand le moyen devient la fin. Quand on mesure le nombre de réunions de CAB plutôt que la rapidité de rétablissement. Quand on exige le même circuit de validation pour redémarrer un service que pour migrer un datacenter. Quand « respecter le processus » l'emporte sur « rendre le service ».

Un processus qui ralentit la résolution n'est pas un processus. C'est un obstacle déguisé en bonne pratique.

J'ai un test très simple pour repérer une DSI malade de ses processus : je demande à un technicien de me décrire ce qu'il fait vraiment en cas d'incident grave. S'il commence par « officiellement… », c'est gagné. Il y a le processus affiché, et le processus réel — celui qui consiste à contourner le premier pour que le métier reparte. Quand les meilleurs éléments passent leur énergie à contourner l'outil, l'outil a échoué.

Calibrer le process sur le risque

La solution n'est pas de supprimer les processus — c'est de les calibrer. Tout ne mérite pas le même cérémonial :

• Les changements standards, à risque connu et maîtrisé, doivent être préautorisés. Redémarrer un service selon une procédure éprouvée ne devrait jamais attendre un comité.
• Les urgences ont besoin d'un circuit d'urgence. Un emergency change avec validation a posteriori, ce n'est pas un contournement : c'est une partie du processus, pensée à froid pour les moments chauds.
• Le gros du contrôle doit porter là où est le vrai risque. Concentrez la rigueur sur les changements complexes et irréversibles, pas sur les gestes quotidiens.

Sortir de l'escalade en silos

L'autre poison, c'est l'escalade rigide en niveaux : le N1 qui « passe au N2 » qui « passe au N3 », chaque palier rajoutant du délai et de la perte d'information. Sur les incidents qui comptent, je préfère le swarming : on réunit immédiatement les bonnes compétences autour du problème, sans le faire transiter de file en file. Le ticket ne voyage plus ; ce sont les compétences qui convergent. C'est plus rapide, et infiniment moins frustrant pour les équipes comme pour l'utilisateur.

Le bon ticket est celui qu'on n'a pas eu à créer

Enfin, le meilleur incident est celui qui n'arrive pas jusqu'à un agent. Un portail de self-service réellement utile, un catalogue de demandes clair, de l'automatisation sur les gestes répétitifs (réinitialisation, provisioning, accès), et aujourd'hui un assistant intelligent qui répond aux questions courantes : tout cela désengorge la file et rend du temps aux équipes pour les vrais sujets. L'ITSM le plus élégant est souvent le plus discret.

Ce que ça donne avec une bonne plateforme

Un ITSM qui sert le service, c'est précisément ce que vise BMC Helix ITSM : des processus ITIL solides mais souples, un routage intelligent des tickets, de l'automatisation native, un portail et un assistant pilotés par l'IA pour désengorger la file, et surtout une intégration directe avec la CMDB et la supervision de la même plateforme. Le changement « sait » sur quoi il impacte ; l'incident « sait » quel service il menace. Le processus redevient ce qu'il aurait toujours dû rester : un serviteur du service, pas son geôlier.