ITIL : UTILE ?

26 janvier 2016

ITIL a maintenant presque 15 ans. Une éternité dans l’informatique. Et durant tout ce temps, il a fait son chemin dans les entreprises : on le voit partout, tous les services informatiques sont « ITIL », et tous les informaticiens sont certifiés. C’est un véritable standard, quelque chose qui va de soi, un peu comme l’utilisation de la suite Office. De la même façon qu’on ne demande plus « savez-vous utiliser Office ? », on ne demande plus : « êtes-vous certifié ITIL ? ». Cela va de va de soi : vous êtes informaticien, vous êtes donc certifié ITIL.

Mais voilà, malgré son omniprésence, j’ai l’impression qu’ITIL n’est toujours pas compris et que les entreprises n’arrivent toujours pas à en tirer la valeur attendue.

En effet, ITIL ne semble pas être compris par les entreprises qui continuent à prendre l’informatique par son côté technique.Comme celle-ci qui recrutait récemment son Responsable IT en mettant en avant les tâches d’architecture, de veille technologique, puis un peu au milieu de l’annonce : les besoins des utilisateurs et des managers, coincés entre « organiser les formations et concevoir des supports » et « prendre la responsabilité de l’exploitation des applications et des bases de données », pour aborder ensuite la gestion des coûts et tout en bas de l’annonce, comme une arrière-pensée, presque un oubli, « maîtrise ITIL appréciée ».

ITIL n’est pas non plus compris par les ingénieurs IT eux-mêmes, qui suivent la formation (la subissent ?) et qui pourtant ne savent pas répondre à mes deux questions préférées en entretien d’embauche : "quel est selon vous le processus le plus important d’ITIL dans le contexte des opérations ?" et : "quelle est la différence entre un incident et un problème ? ». En général, je n’ai qu’un silence gêné pour réponse à ma première question et un triomphant « ben un incident, c’est un problème quand il se produit » en réponse à la deuxième...

Et que dire de ce fournisseur de services Cloud qui affiche fièrement que ses ingénieurs sont tous « certifiés ITIL » mais qui n’est pas en mesure de me communiquer ses procédures de gestion des incidents et de gestion des changements lorsque je les lui demande ?

Triste tableau après une l’équivalent d’une ère glacière informatique à tenter de structurer les services IT. La question se pose donc : ITIL est-il utile ?
Lorsque je pose cette question à des responsables IT, on me répond qu’ITIL est carcan lourd à mettre en place, qu’il fait perdre de la souplesse et de la vitesse dans l’exécution des prestations des services IT : "en cas de problème, il faut aller vite, ce n’est pas le moment de brasser du papier », ou encore « on a les procédures, mais on ne les suit pas, elles sont trop longues ». Dans les petites structures, on me répond : « c’est pour les grosses boîtes qui ont du personnel, c’est pas pour nous ».ITIL est aussi perçu comme un substitut au talent du manager : « je n’ai pas besoin de ça pour gérer mon service / mon équipe ». En clair, ITIL est perçu comme un encombrement.
Or, c’est tout le contraire : c’est ITIL qui va permettre de maîtriser enfin les services IT, de dominer les problèmes puis de les éliminer.

Le "Service Management" c’est la gestion du « service » que rend l’IT, pas la gestion du Service IT au sens de "département IT". Tout le problème vient d’inculquer la notion de service rendu par l'IT et de bien calibrer le besoin en procédure, de bien mettre le curseur pour ne pas créer des procédures lourdes, inutiles que personne ne suivra. Il faut commencer léger, puis améliorer dans le temps, par petites touches, lorsque tout le monde aura perçu l’amélioration que les procédures apportent. Deming est là pour ça. Il ne sert à rien de vouloir déployer « tout ITIL » d’un coup, chaque processus, chaque partie du référentiel. Cela irait à l’échec par overdose de procédure et provoquerait un rejet massif et durable. Je compare souvent les apprentissages à du sable qu’on jette dans l’eau : il faut du temps pour ce sable se dépose au fond du bassin, et ce n’est qu’à ce moment qu’il se stabilise et se sédimente. Il en va de même pour les apprentissages : il faut du temps pour que les nouvelles notions soient intégrées et deviennent une culture.

Il faut aussi cesser de voir l’informatique comme un métier technique, un empilement de solutions. L’informatique est un métier de service, au même titre que la restauration : nous, informaticiens de tout poil, sommes au service d’une entreprise, de ses utilisateurs, de ses clients. Les informaticiens doivent cesser de se concentrer sur leurs serveurs, leurs logiciels, leurs routeurs ou que sais-je encore pour réaliser que ce ne sont que des outils au service d’une activité elle-même au service de clients. J’ai terriblement l’impression d’enfoncer des portes ouvertes en écrivant cela, mais combien d’informaticiens se considèrent comme des experts techniques au service de leur machine, combien de services informatiques sont des tours d’ivoire hermétiques aux besoins du business, allant parfois jusqu’à lui dicter leurs conditions, à lui imposer leurs solutions ou à lui refuser l’expression de ses besoins ?

ITIL permet de se hisser au-dessus de cette vision technique et de voir l’informatique comme ce qu’elle est : un service rendu au business. Les processus proposés n’ont d’autre objectif que la stabilité pour le business, la qualité pour le business, l’anticipation pour le business. La maîtrise pour le business. Et au final, pour le client. On en revient à la raison d’être d’une entreprise et la boucle est bouclée.

ITIL se débarrasse de la technique et fait entrer le client dans le service informatique. Cette entrée est vécue comme une intrusion par les informaticiens qui ne sont pas habitués à s'y confronter. Pire, cette focalisation sur le client semble s’opposer à leur activité technique. D’ou le rejet de processus jugés intrusifs et inutiles dans une fonction perçue comme purement technique. Et d’où le succès et la qualité des services IT qui ont su mettre le client au centre de leur activité. La malédiction d’ITIL est donc avant tout un problème de culture. Et la culture, cela dépend, au final, de l’humain plus que de procédures. Dans un prochain article, je vous donnerai quelques idées pour changer la culture de votre service IT et lui permettre de mettre le client au centre de ces activités.

D’ici-là, je suis votre serviteur en cas de questions.