Pourquoi l’expérience d’ITIL compte désormais plus que sa connaissance

ITIL n’a jamais été conçu pour être suivi sans réfléchir. Il donne une direction, pas des instructions.

La plupart des professionnels de l’IT savent réciter la différence entre un incident et un problème. Bien moins nombreux sont ceux qui peuvent vous dire, à 2 heures du matin avec un parc de magasins hors ligne, sur lequel des deux ils devraient travailler à cet instant. C’est dans cet écart entre connaître le référentiel et l’appliquer que la qualité de service se gagne ou se perd.

Pourquoi « désormais » ?

Les anciennes versions d’ITIL étaient construites autour de processus définis. On pouvait, en principe, les suivre étape par étape.

ITIL 4 a remplacé les processus par des pratiques, des principes directeurs et des flux de valeur. ITIL (Version 5) va plus loin : Transformation figure désormais dans chaque désignation, et l’accent s’est déplacé de la bonne exécution des pratiques à la conduite du changement à travers elles.

Un référentiel fondé sur des principes ne s’exécute pas comme une liste de contrôle. Quelqu’un doit décider comment chaque principe s’applique à cette organisation, à ce service et à ce risque. Cette décision relève du jugement, et le jugement vient de l’expérience.

Des recommandations, pas une liste de contrôle

ITIL aide les organisations à comprendre comment les services créent de la valeur, à prendre de meilleures décisions et à s’améliorer sans cesse. Il n’attend pas d’un hôpital, d’un distributeur et d’une flotte maritime qu’ils gèrent les changements ou les incidents de la même manière.

Le certificat prouve que vous connaissez les recommandations. L’expérience, c’est savoir quelles parties comptent le plus un mardi donné.

Chaque service a besoin d’un seul propriétaire de service

« Le service appartient à l’IT » signifie que personne n’en est propriétaire.

Chaque service a besoin d’un seul propriétaire de service : une personne nommée, responsable de ses performances de bout en bout, y compris des parties fournies par d’autres équipes et par des fournisseurs. Le propriétaire de service ne corrige pas lui-même chaque défaut. Il s’assure que les défauts sont corrigés, que les améliorations sont financées et que quelqu’un répond du résultat.

Voici le test. La paie manque son SLA parce qu’un changement de pare-feu de l’équipe réseau a échoué. Qui l’explique au directeur financier ? Si trois équipes se renvoient la balle, le service n’a pas de propriétaire. Le propriétaire de service est celui qui reçoit l’appel, puis qui s’assure que le prochain changement de pare-feu ne pénalisera plus la paie.

Rétablir d’abord, puis éliminer la cause

Quand un service tombe en panne, la première tâche est de le rétablir. C’est la gestion des incidents, et la rapidité est tout l’enjeu.

L’erreur est de s’arrêter là. Si la messagerie tombe trois fois en une semaine, ce ne sont pas trois incidents sans lien. Ce sont trois incidents qui pointent vers un seul problème, et tant que personne n’a trouvé et éliminé la cause sous-jacente, la quatrième panne est déjà programmée.

Connaître les définitions est facile. L’expérience, c’est repérer le schéma tôt, avoir la discipline d’ouvrir un enregistrement de problème quand tout le monde veut passer à autre chose, et transformer l’analyse des causes racines en actions avec des responsables et des dates. C’est par une gestion des problèmes structurée que mes équipes ont réduit de 40% les incidents récurrents : non pas en corrigeant plus vite, mais en s’assurant que la même défaillance ne puisse pas se produire deux fois.

Changer avec le juste niveau de contrôle

Le changement est normal. Tout l’art consiste à adapter le contrôle au risque.

• Les changements standard sont à faible risque, répétables et pré-autorisés. Un correctif courant poussé par un pipeline testé ne devrait pas attendre un comité.
• Les changements normaux comportent un risque réel et exigent une évaluation et une autorisation proportionnées à ce risque.
• Les changements d’urgence doivent avancer vite, mais sont tout de même enregistrés et revus.

Traitez chaque changement comme à haut risque et la livraison s’enlise. Traitez chaque changement comme anodin et l’un d’eux finira par mettre l’activité à l’arrêt. ITIL 4 a renommé la pratique de gestion des changements en habilitation des changements précisément pour cette raison : l’objectif est d’aider le changement à se faire en toute sécurité, pas de l’empêcher.

Décider de la catégorie d’un changement relève du jugement. Une règle peut dire « les changements de base de données sont Normaux ». Seule l’expérience vous dit que ce changement de base de données, un week-end de clôture trimestrielle, mérite un second regard.

L’amélioration se fait chaque jour

L’amélioration continue n’est pas un projet avec une date de fin. Elle se produit lorsque les équipes :

• Repèrent tôt les petits problèmes, avant qu’ils ne deviennent des incidents
• Apportent des corrections pratiques au lieu d’attendre un programme de transformation
• Examinent les résultats et s’ajustent

Une base de connaissances bien entretenue en est un bon exemple. Elle n’apparaîtra pas sur une diapositive stratégique, mais dans un environnement de support télécom très chargé, elle a été l’une des principales raisons de la baisse de 35% des délais de résolution.

Ce que l’expérience apporte vraiment

Connaître les concepts ITIL est le point de départ. Les praticiens expérimentés savent aussi :

• Quand suivre les recommandations de près, parce que le risque est élevé et que le processus existe pour une raison
• Quand les adapter, parce que les suivre à la lettre ralentirait l’activité sans rien rendre plus sûr
• Comment mesurer les résultats, pas l’activité : des services disponibles quand le métier en avait besoin, pas des tickets clos

Cet équilibre ne s’apprend pas par cœur pour un examen. Il se construit en gérant de vrais services, en prenant de vraies décisions et en assumant les résultats.

Conclusion

ITIL a été conçu pour soutenir les bonnes décisions, pas pour les remplacer. Ceux qui comprennent l’intention derrière les recommandations gèrent mieux les services, abordent le changement avec assurance et continuent d’améliorer la qualité.

Au bout du compte, ITIL est une affaire de personnes et de valeur réelle apportée.

Vous voulez savoir où en sont vos propres pratiques de gestion des services ? Faites l’évaluation de maturité ITSM gratuite.