La définition de l’ITIL (Information Technology Infrastructure Library) que je préfère est sans aucun doute celle de Don Page, véritable gourou de l’ITIL, qui le décrit simplement comme le « sens commun documenté ». Si l’on en croit Voltaire, « le sens commun n’est pas si commun » ; d’où l’importance de bien le documenter quand on a la chance de le trouver !
L’ITIL est un ensemble de bonnes pratiques d’ITSM, permettant notamment d’adresser des questions telles que : Quels types de service fournir, et à qui ? Comment créer de la valeur ajoutée pour ses clients ? Comment définir la qualité de services ? Comment continuer à améliorer ses services dans un monde digital en perpétuelle transformation ? Comment mieux intégrer la stratégie IT à la stratégie business de l’entreprise ?
Pour résumer, il s’agit d’un ensemble de guidelines permettant à l’IT de fournir un service de meilleure qualité, à moindre coût.
A l’instar de nombreuses philosophies et autres frameworks, l’ITIL n’a toutefois pas échappé à quelques dérives. La démarche ITIL repose sur la concordance entre individus, processus et outils. Or, au fil des années, des fournisseurs, quoique bien intentionnés, ont pris le train en marche en se contentant d’en traiter uniquement l’aspect technique : bases de données et systèmes de gestion de configuration (CMDB et CMS), outils de certifications ITIL... ont ainsi été légion, vendus comme des solutions miracles d’ITSM. Et ce au détriment d’un véritable accompagnement méthodologique. Si bien que l’ITIL est peu à peu devenu un outil de « service desk », qui, sous couvert de « management », consistait surtout à traiter et suivre les incidents.
La question de la pertinence de l’ITIL se pose d’autant plus aujourd’hui que d’autres démarches, en particulier celle du DevOps, ont émergé.
Selon Gartner, « le DevOps n’est pas un marché, mais une philosophie centrée sur les outils, permettant de favoriser une chaîne de continuous delivery. » Je me permettrais toutefois d’ajouter à la notion d’ « outils » celles d’ « individus » et de « culture »...
Pour Gene Kim, l’auteur de « The Phoenix Project », le DevOps prône une collaboration entre le Développement et l’IT, qui permettrait une exécution plus rapide des tâches planifiées (par exemple, des taux de déploiement plus élevés), tout en augmentant la fiabilité, la stabilité, la résistance et la sécurité des environnements de production.
L’un des principaux points de discorde, dans le débat opposant ITIL et DevOps, réside dans le manque de flexibilité souvent reproché aux guidelines ITIL en matière de change management.. Mais il faut rappeler que le premier objectif de ces guidelines consiste à encadrer les risques liés à la fiabilité, la stabilité, la résistance et la sécurité, grâce à une meilleure collaboration entre les équipes. Tandis que le DevOps préconise l’automatisation pour adresser les mêmes risques. Ce qui fait qu’en substance, le débat entre les deux philosophies n’a pas vraiment lieu d’être. Mieux, elles s’avèrent complémentaires.
Commencez par vous poser la question du « Pourquoi ». Viendront ensuite le « Quoi » et le « Comment ». N’oubliez pas que les frameworks et les processus ne sont pas une fin en soi, mais un moyen d’atteindre vos objectifs.
Votre succès dans l’économie digitale tient à trois points clés :
un focus permanent sur le client et l’expérience client, et sur la façon dont vous pouvez tirer parti des données récoltées pour améliorer sans cesse votre qualité de service ;
le continuous delivery et le continuous improvement (amélioration continue), notamment via des releases régulières de nouvelles fonctionnalités, pour répondre à l’évolution rapide et permanente des attentes de vos clients ;
l’excellence opérationnelle, qui passe notamment par une culture de la collaboration, du feedback et de l’amélioration, partagée par l’ensemble de l’entreprise, tous départements confondus. Ce n’est qu’à cette condition que vous serez en mesure de garantir la fiabilité, la stabilité, la résistance et la sécurité de vos environnements et de vos services.