ITIL vs DevOps

Nous étions à table. C’était un espace de co-working que je souhaitais tester, dans ma région, regroupant des co-workers d’horizons divers prêts à partager leur savoir et leur savoir-faire avec d’autres personnes d’autres entreprises. Une expérience neuve pour moi. Nous étions en 2014 et je venais de recevoir ma certification ITIL V3.
Je préparais la formation de mes 60 collègues.

Un jeune homme, très fraîchement sorti des études monopolise non pas l’attention mais du moins la conversation, convaincu d’avoir quelque chose à vendre à toute cette joviale assemblée… Son discours est assez péremptoire, il semble assez sur de lui et a une forte envie d’en découdre avec tout supporter d’ITIL…

Je l’entends dire : « il faut absolument se séparer de la bureaucratie inhérente à l’implémentation d’ITIL dans les entreprises ». Je défends une conception de la gestion des services qui est beaucoup plus flexible et efficace.
Mon référentiel est facile à mettre en place, remplacera rapidement ITIL qui coûte cher et enferme les entreprises dans des processus lourds et inutiles.

Tous ceux qui ont implémenté ITIL s’en mordent les doigts parce qu’aujourd’hui ils souhaiteraient en sortir et n’en ont plus la possibilité.

Je venais d’investir une semaine de mon temps, et m’apprêtais à signer un bon de commande de 40000 € pour former tout un service aux bonnes pratiques, vous imaginez donc mon inquiétude. En même temps, il me fallait en savoir plus.

 

Je posai donc quelques questions rapides :

• Comment résout-on les incidents avec ce framework ?
• Il n’y en a presque plus, donc un retour au tableau Excel est largement suffisant.
• Wow… Donc il y a une gestion de l’imprévu en amont, une résolution proactive d’incidents potentiels sur base d’événements constatés ?
• Même pas, les systèmes sont stables par nature…
• Eh bien, et ce grâce à un ensemble de choix technologiques particuliers ?
• Oui bien sûr, mais surtout grâce à une méthode de développement qui supprime tout bug à la source…
• Une méthode Agile ?
• Quoi, il y a d’autres méthodes de développement ?

 

Là, j’ai pensé « On avance » !

• Dis-moi, as-tu des exemples concrets d’organisations qui sont enfermées dans ITIL et voudraient en sortir ? Cela m’intéresserait de partager leur expérience pour éviter cela à mon Service.
• Toutes !

 

J’ai compris à ce moment que j’avais en face de moi une brillante jeune pousse formée à l’argumentation et au bagout, mais en aucun cas à la gestion des services.
Laissant la discussion se terminer de cette façon, je remis à plus tard la suite de mon interrogatoire.

De retour à nos postes de travail, je retournais près de lui pour connaître le nom de ce référentiel magique.
Du bout des lèvres, il me dit : ça s’appelle ‘DevOps’. Ce fut mon premier contact avec DevOps, et j’avais déjà l’intuition qu’il avait bien retenu les leçons de son gourou, mais qu’il n’en avait pas capté l’essence.

J’ai donc cherché par moi-même… trouvé de bonnes pistes et suis finalement entré dans ce monde, sans jamais quitter ITIL. Il n’y avait à cette époque que très peu de documentation vraiment structurée sur le sujet. Des bonnes idées qui ensemble formaient un magma plein de bonnes intentions dont on ne pouvait que ressentir l’énorme potentiel.

C’est durant cette année cependant qu’une première mise en mots vit le jour. Un roman sur l’IT et  DevOps appelé « The Phoenix Project ». Une immersion dans un effort de transformation d’une entreprise à travers la modification profonde de son service IT.
Lire ce livre, c’est un peu comme prendre de l’expérience sans rien faire : une immersion pleine d’enseignements.

Il est vrai qu’au début du livre, certains processus ITIL sont attaqués pour leur lourdeur, mais en aucun cas il n’est recommandé de s’en défaire complètement. Mieux au fil du livre, on se rend compte de l’influence essentielle des bonnes pratiques ITIL sur la réussite de la transformation DevOps, et de l’égale importance pour celles-ci d’être élaguées de ce qui ne produit pas de valeur. On peut donc avancer vers un concept de Lean-ITIL, et une partie du chemin vers DevOps est parcouru.

Avec le temps, DevOps ayant gagné en maturité, de même que ses adeptes et praticiens, il est clairement indiqué, dans les premières pages des formations ‘Foundations’ que les 3 sources d’inspiration de DevOps sont ITIL, Lean et l’Agilité. Pour insister un peu plus, l’obsolescence d’ITIL est considérée comme l’un des mythes accompagnant systématiquement le seul nom DevOps.

Je crois fermement que ITSM et le mouvement DevOps ne sont pas opposés. Au contraire, ils offrent un mariage Culturel parfait (Selon Gene Kim, auteur – entre autres-  du Phoenix Project et du DevOps Handbook, traduction libre de l’auteur de cet article) .

Cette citation a été lancée avant même la sortie d’ITIL 4… qui s’est agilisé.
DevOps n’effaçait pas l’intérêt d’ITIL V3, inutile de dire ce qu’il advient d’ITIL 4 dans ces conditions.

Il reste donc critique pour les services IT de prendre connaissance et de mettre en place les pratiques ITIL , DevOps en utilisera le fruit avec succès.

J’ai souvent repensé à ce jeune homme. Je ne peux que le remercier d’avoir déclenché cette remise en question.
En aucun cas je ne lui reprocherai sa légèreté insouciante… Au contraire, je lui souhaite aujourd’hui d’avoir gagné en maturité au même rythme que le mouvement qu’aujourd’hui nous représentons ensemble.

 

Xavier Heusdens

Xavier a plus de 20 ans d’expérience dans la gestion de projets, programmes au sein des organisations. En plus de son activité de consultant, Xavier est formateur multilingue pour PMP, PRINCE2 et DevOps. Il est également formé aux méthodes AgilePM, ITIL, COBIT, MOP et change management.

Suivez Xavier sur Linkedin