ITSM sans religion : comment appliquer ITIL sans fabriquer une usine à gaz

Le malentendu : ITIL n’est pas un logiciel, ni une cathédrale

À chaque fois qu’une DSI prononce “ITIL”, un réflexe pavlovien s’active : certains voient un gage de sérieux, d’autres sentent venir la paperasse, les comités, les formulaires et les ateliers de trois heures pour décider de la couleur d’un statut. Résultat : ITIL devient un symbole, soit de maturité, soit d’oppression. Or ITIL n’est ni une application, ni une doctrine. C’est un corpus de bonnes pratiques. À prendre, adapterif, la plupart du temps. À adapter, toujours.

L’ITSM (IT Service Management) n’a pas pour vocation de “mettre l’IT en conformité”, mais de rendre le service fiable, prévisible, mesurable, et compréhensible par les métiers. Si ton ITIL produit plus de friction que de valeur, tu n’as pas “raté le déploiement”, tu t’es trompé d’objectif.

Le vrai objectif : remettre la promesse de service au centre

Le pragmatisme commence par une phrase simple : “Qu’est-ce qu’on promet, et à qui ?” L’ITSM sert à formaliser cette promesse et à la tenir dans la durée. Cela veut dire : clarifier ce qui est supporté, comment on le supporte, ce qui est prioritaire, et comment on arbitre quand ça brûle partout. Le reste est secondaire.

La plupart des usines à gaz naissent d’une erreur de départ : on veut “couvrir ITIL”, alors qu’on devrait vouloir “sécuriser le run” et “fluidifier le delivery”. Dans la vraie vie, personne ne te félicitera parce que tu as un catalogue de services parfait, si les incidents critiques ne sont pas traités, si les changements cassent la prod, et si les métiers ne savent pas à qui parler.

La règle d’or : minimum viable process, maximum de discipline

Un bon ITSM ne se voit pas, il se ressent : moins d’aléas, moins de pertes d’informations, moins de rework, moins de “c’est pas moi”. Pour y arriver, tu n’as pas besoin de 18 processus. Tu as besoin de 4 ou 5 processus “socle”, ultra clairs, tenus avec une discipline stable.

Le “process minimum viable” n’est pas un ITSM au rabais. C’est un ITSM qui choisit ses batailles. Ton objectif n’est pas de modéliser l’entreprise, mais de réduire les points de rupture. Si tu dois expliquer un processus en plus de deux minutes à un opérationnel, il est trop compliqué. Si un manager ne peut pas vérifier en 30 secondes si le processus est respecté, il est trop fragile.

Incident : un circuit court, un pilotage réel, une priorité qui a du sens

Le processus incident est la colonne vertébrale. Et pourtant, c’est souvent là qu’on fait de la littérature : catégories infinies, statuts inutiles, matrices d’escalade incompréhensibles. La version utile tient en quelques éléments.

Un incident, c’est un événement qui dégrade un service. Point. La priorité doit traduire l’impact business et l’urgence, pas l’humeur de celui qui ouvre le ticket. Une matrice simple fait mieux que cinquante exceptions : impact (combien de personnes / quel service / quel chiffre d’affaires) croisé avec urgence (est-ce bloquant maintenant). Ensuite, un pilotage : un Incident Manager ou un Service Desk lead qui annonce le rythme, maintient le lien, et impose des updates.

Ce que les métiers jugent, ce n’est pas ta taxonomie, c’est ta capacité à dire : “On a compris, on a la main, voici l’heure du prochain point, voici le contournement, voici le délai probable.” L’ITIL utile, c’est d’abord une mise en musique de la communication.

Demande : standardiser pour libérer, pas pour contrôler

Les demandes (service requests) sont l’endroit où l’ITSM crée du confort : accès, matériels, comptes, logiciels, droits, interventions. Quand les demandes sont traitées comme des incidents, tout devient urgent et personne ne respire.

Le minimum viable ici : un catalogue simple, limité aux demandes fréquentes, avec un formulaire court, des règles de validation évidentes, et surtout un circuit d’exécution. L’usine à gaz, c’est le catalogue “exhaustif” que personne ne lit et que tout le monde contourne par mail. Le bon catalogue, c’est celui qui remplace le mail parce qu’il est plus rapide, pas parce qu’il est obligatoire.

Change : réduire le risque sans tuer la vitesse

Le change management est l’autre grand déclencheur de religion. Certains veulent tout valider, tout documenter, tout soumettre à un CAB. D’autres détestent toute contrainte et livrent en production comme on traverse une rue les yeux fermés. Les deux approches échouent.

Le pragmatisme, c’est la segmentation : changements standards (pré-approuvés), changements normaux (évalués), changements urgents (encadrés après coup). La clé : une check-list simple qui protège le service. Qu’est-ce que ça change ? Quel risque ? Quel rollback ? Quelle fenêtre ? Qui est informé ? Et surtout : a-t-on une supervision qui permettra de détecter rapidement une régression ?

Tu peux être très “ITIL” avec un processus léger, si tu as une vraie discipline de préparation et de communication. L’usine à gaz commence quand le change devient un théâtre administratif au lieu d’un mécanisme de réduction de risque.

Problème : ne pas en faire un cimetière de tickets

Le problème management est souvent mal compris. Ce n’est pas “l’étape suivante” automatique après un incident. C’est un investissement ciblé pour éliminer une cause racine qui coûte cher en récurrence, en image ou en fatigue d’équipe.

Le minimum viable : ouvrir un problème quand un incident majeur survient, ou quand une récurrence est démontrée. L’objectif : une cause racine probable, une action corrective priorisée, un responsable, une date, et un suivi. Pas besoin d’un roman. Ce qui tue le problème management, c’est la bureaucratie et l’absence de décision.

CMDB : si elle n’aide pas le support, elle est inutile

La CMDB est le grand fantasme. On veut “la CMDB”, comme on veut “la data”. Mais une CMDB parfaite n’existe pas, surtout dans des environnements hybrides, multi-fournisseurs, et historiques. Si tu la construis pour l’audit, tu vas te ruiner. Si tu la construis pour le run, tu vas réussir.

Le pragmatisme : commencer par ce qui aide immédiatement le support et l’exploitation. Les services critiques, leurs composants principaux, les dépendances majeures, et les contacts. Ensuite, automatiser la découverte autant que possible, et accepter une part d’imperfection. Une CMDB doit être “assez vraie pour être utile”, pas “parfaite pour être admirée”.

Les métriques qui comptent : quelques chiffres, toujours les mêmes

L’ITSM devient toxique quand il se transforme en reporting pour le reporting. Les métriques utiles sont peu nombreuses, stables, et reliées à une décision.

Pour le run : volume d’incidents, % respect SLA, MTTR (temps moyen de résolution), nombre d’incidents majeurs, récurrence. Pour le change : taux d’échec, incidents post-change, lead time, % changes standards. Pour le service desk : taux de résolution au premier contact, délai moyen de prise en charge, satisfaction.

Le piège, c’est de mesurer ce qui est facile à mesurer, au lieu de mesurer ce qui améliore le service.

Adoption métiers : la vérité, c’est l’expérience utilisateur

Tu peux avoir une documentation impeccable et un outil ITSM dernier cri, si les métiers trouvent que “ça n’avance pas”, tu as perdu. L’adoption se gagne par le design de l’expérience : simplicité, rapidité, transparence.

Un portail doit être plus pratique qu’un mail. Un ticket doit donner de la visibilité, pas de l’angoisse. Un SLA doit être compréhensible, et tenu sur les sujets qui comptent. Et surtout, il faut un langage commun : “service”, “impact”, “priorité”, “urgence” doivent vouloir dire la même chose pour tout le monde.

Là encore, le pragmatisme consiste à co-construire : pas des processus, mais des parcours. “Je veux un accès.” “Je suis bloqué.” “Je lance un nouveau site.” “Je change un applicatif.” Si ton ITSM n’épouse pas ces parcours, il restera un outil d’IT pour l’IT.

Gouvernance légère : décider vite, apprendre vite

Les comités ne sont pas le problème. L’absence de décisions rapides est le problème. Une gouvernance ITSM efficace tient en rituels courts : un point run hebdo, un point incidents majeurs, un point changements à risque, un point backlog et récurrences. Et des décisions visibles : on standardise telle demande, on automatise tel flux, on stoppe tel changement risqué, on finance telle correction.

ITIL sans usine à gaz, c’est une gouvernance qui tranche. Une DSI qui ne tranche pas compense par des processus. Une DSI qui tranche peut garder des processus simples.

La méthode de déploiement : petit, rapide, irréversible

Le meilleur antidote au dogme, c’est la mise en production rapide. On choisit un périmètre (un service critique, une région, un domaine), on met en place le socle (incidents, demandes, changes), on mesure, on corrige, puis on étend.

Le secret est là : rendre le nouveau fonctionnement plus pratique que l’ancien. Si tes équipes doivent faire plus d’effort pour produire le même résultat, elles contourneront. Si elles gagnent du temps et de la clarté, elles adopteront.

Conclusion : ITIL est une boîte à outils, pas une religion

Appliquer ITIL sans fabriquer une usine à gaz, c’est accepter une réalité : la valeur vient de la discipline sur quelques pratiques, pas de la couverture exhaustive du référentiel. L’ITSM pragmatique vise la réduction du chaos, la tenue de la promesse de service, et l’amélioration continue tangible.

Quand ton ITSM marche, les métiers ne disent pas “vous êtes ITIL”. Ils disent : “On vous comprend. On vous fait confiance. Et ça tient.”