Quatre pratiques essentielles. Quatre à déployer au cas par cas. Trois à laisser de côté. Voici notre lecture pragmatique d'ITIL 4.
ITIL 4 est devenu un mot-valise. Pour certains, c'est un référentiel sérieux et adaptable. Pour d'autres, c'est un théâtre de processus déconnectés du terrain. Les deux existent. Et c'est rarement le référentiel qui est en cause, c'est la façon dont on l'applique.
Voici notre lecture pragmatique de ce qui mérite vraiment d'être déployé, et de ce qu'on peut laisser de côté sans dommage.
ITIL 4 est un outil, pas une religion. On retient ce qui crée de la valeur dans votre contexte, on laisse de côté le formalisme qui pèse sans servir.
Ce qu'on garde toujours
Quatre pratiques ITIL 4 produisent de la valeur dans à peu près tous les contextes. Ce sont celles à instrumenter en priorité.
Incident Management
C'est la base. Une organisation qui ne sait pas piloter ses incidents (qualification, escalade, communication, clôture, post-mortem si nécessaire) ne peut pas piloter sa qualité de service. Toutes les autres pratiques s'effondrent si celle-ci n'est pas solide.
Ce qu'on garde concrètement : un workflow simple, des niveaux de priorité clairs, des règles d'escalade explicites, une post-mortem systématique sur les incidents majeurs. Pas besoin de plus.
Service Request Management
Distinguer un incident d'une demande est un premier pas qui change beaucoup. Un incident, c'est un dysfonctionnement. Une demande, c'est une sollicitation normale (un accès, un compte, une installation). Les deux ne mobilisent pas les mêmes compétences et n'ont pas les mêmes urgences.
Un catalogue de services bien structuré, avec des demandes standardisées et des SLA réalistes, libère immédiatement de la capacité sur le front line.
Change Enablement
Anciennement Change Management. La nouvelle version est plus pragmatique : on distingue les changements standards (pré-approuvés, sans risque), les changements normaux (qui passent par une évaluation), et les changements d'urgence (avec un circuit dédié).
C'est cette catégorisation qui crée la valeur. Elle évite de soumettre une demande d'ajout d'un membre dans un groupe Active Directory à un comité hebdomadaire, tout en sécurisant les changements vraiment risqués.
Service Catalog Management
Avoir un catalogue à jour, accessible aux utilisateurs, avec des engagements de service clairs, c'est ce qui transforme la relation entre l'IT et les métiers. Sans catalogue, l'IT est perçu comme une boîte noire dont on attend l'aide sans savoir quoi attendre. Avec un catalogue, l'IT devient un fournisseur de services lisible.
Ce qu'on déploie au cas par cas
Quatre pratiques sont importantes, mais leur déploiement dépend du contexte et de la maturité de l'organisation.
Problem Management
Indispensable si vos incidents se répètent. Inutile à formaliser tant que vous n'avez pas atteint un niveau de stabilité minimal sur les incidents.
Une problem management déployée trop tôt produit des analyses qui ne sont jamais exploitées, parce que l'équipe est encore occupée à éteindre les feux du jour.
Knowledge Management
Précieux quand votre équipe est suffisamment large pour qu'une base de connaissance partagée fasse une différence. Sur une équipe de 3 personnes, c'est trop d'effort pour trop peu de valeur. Sur une équipe de 20, c'est essentiel.
Service Level Management
Utile dès que vos métiers ont des attentes formalisées (en interne ou via des contrats). Optionnel tant que la relation est purement informelle.
Un SLA mal défini est pire que pas de SLA du tout. Il crée une fausse sécurité chez les métiers et une mauvaise allocation des priorités côté IT.
Configuration Management (CMDB)
À ne déployer que quand vous avez un usage clair en tête. Sur ce sujet précis, nous avons écrit un article dédié sur les conditions de réussite. La règle générale : pas de CMDB sans usage cible défini.
Ce qu'on laisse souvent de côté
Plusieurs pratiques ITIL 4 sont précieuses dans certains contextes mais coûtent plus qu'elles ne rapportent dans la majorité des cas pour des PME et ETI.
Le déploiement formel de Continual Improvement comme pratique séparée est l'archétype. L'amélioration continue doit être présente partout, pas instanciée comme un processus à part. Sinon on crée une équipe d'amélioration qui regarde travailler les autres, sans levier réel.
Risk Management au sens ITIL est très utile dans les organisations soumises à de la réglementation forte (banque, santé, énergie). Pour la majorité des PME et ETI, la gestion des risques est mieux portée au niveau de la direction générale, pas formalisée par la DSI.
Strategy Management for IT Services suppose une organisation IT déjà très structurée. Pour une équipe de 10 à 30 personnes, c'est probablement trop lourd à mettre en place comme pratique formalisée.
Un référentiel n'est pas une obligation. C'est une boîte à outils. On prend ce qui sert, on laisse le reste.
La règle générale
Une pratique ITIL ne mérite d'être déployée formellement que si elle remplit deux conditions. Elle répond à un besoin réel et identifié. Elle peut être instrumentée sans détruire la productivité des équipes.
Si vous travaillez avec un prestataire qui vous propose de déployer ITIL 4 dans son ensemble, posez-lui une question simple : quelles pratiques produisent quels résultats mesurables chez vous, et sur quel horizon ? Si la réponse n'est pas claire, c'est probablement que la démarche est cérémonielle, pas opérationnelle.