Probablement pas !
Avec l'émergence d'Agile et de DevOps, certains disent qu'ITIL est mort ! Est-ce vrai ? La réponse courte est "NON !
Cependant, nous devons comprendre le raisonnement qui sous-tend l'affirmation selon laquelle ITIL n'est pas pertinent et que la gestion des services informatiques (ITSM) est obsolète. Il est certainement vrai que de nombreuses organisations qui ont "mis en œuvre ITIL" ou qui sont "conformes à ITIL" ou "alignées sur ITIL" sont actuellement confrontées à de nombreux problèmes. Ces problèmes comprennent une bureaucratie inutile, des processus rigides et complexes, des outils et des technologies obsolètes, des départements informatiques cloisonnés et antagonistes, ainsi que d'autres problèmes et dysfonctionnements importants.
Il est fréquent que les gens considèrent ITIL et la gestion des services informatiques (ITSM) comme étant dogmatiques et fixés sur des processus rigides. Une autre perception populaire est qu'ITIL a un fort penchant pour les opérations plutôt que pour le développement de logiciels et qu'il n'est donc pas pertinent pour les "app guys".
Une question de mauvaise interprétation
De nombreuses organisations interprètent mal les meilleures pratiques ITIL et/ou mettent mal en œuvre les principes ITSM. De même, beaucoup d'organisations font un mauvais usage d'Agile, surtout si leur interprétation d'Agile est synonyme de "tirer à la hanche". Dans les années à venir, il est fort probable que nous verrons de nombreuses organisations tenter de mettre en œuvre DevOps, puis échouer. Cependant, ce n'est pas parce que certaines d'entre elles mettent mal en œuvre Agile et DevOps que ces concepts incroyablement puissants doivent être condamnés. Il y a plus d'"erreurs de l'utilisateur" que de déficiences dans n'importe lequel de ces cadres, y compris l'ITIL.
ITIL n'était pas censé être un une taille pour tous pour être mis en œuvre de la même manière par chaque organisation. L'une des devises d'ITIL est "adopter et adapter". L'objectif de cette admonition est d'encourager une mise en œuvre flexible du cadre ITIL.
ITIL n'est pas censé être bureaucratique ou entraver l'agilité et l'innovation. C'est plutôt le contraire qui est vrai. ITIL encourage l'adoption de nouvelles technologies et l'innovation afin de répondre aux besoins de l'entreprise et de créer de la valeur pour les clients. Les concepts ITIL doivent être mis en œuvre de manière à optimiser les résultats du point de vue des personnes, des processus et des technologies.
Supposition de l'inexistence d'un conflit
Contrairement à la croyance populaire, ITIL n'est pas en conflit avec la pensée Agile ou DevOps. ITIL ne se limite pas non plus à l'infrastructure ou aux opérations. Les versions les plus récentes d'ITIL sont axées sur les services de bout en bout. Ceux-ci comprennent normalement la gestion des applications, le développement, l'infrastructure, les opérations et l'alignement sur la stratégie commerciale et la valeur client.
En outre, ITIL a un cycle de développement basé sur des principes qui sont presque identiques au cycle de développement logiciel utilisé par Agile et DevOps. Une grande partie du cycle de vie d'ITIL est la "conception des services" et ITIL est assez agnostique sur le sujet de la façon de conduire le développement d'applications. ITIL n'a pas de parti pris inhérent pour l'approche Waterfall de la gestion de projet et s'adapte à Agile ainsi qu'à toute autre approche possible de la conception de services ou de la gestion de projets. ITIL n'est pas prescriptif en ce qui concerne les outils, la structure organisationnelle et la conception des politiques et procédures.
Aucune incompatibilité
De nombreuses bonnes pratiques et concepts décrits dans ITIL sont similaires, sinon identiques, à ceux préconisés dans Agile et DevOps - ou du moins ne sont pas incompatibles avec ITIL. Par exemple, ITIL ne dit pas qu'il faut faire des versions trimestrielles "big bang" ou avoir un processus de gestion des changements lent et compliqué. ITIL permet des mises à jour fréquentes et un processus de changement rapide.
Le livre récemment publié, Ingénierie de la fiabilité des sites : Comment Google fait fonctionner ses systèmes de production, décrit en détail la mise en œuvre de DevOps chez Google. Chez Google, DevOps est un mélange de méthodologies Agile, de meilleures pratiques ITIL, de résolution de problèmes et de prise de décision systématiques, et d'une culture mature d'amélioration continue sans reproche. Bien entendu, tout cela fonctionne sur la technologie propriétaire très avancée de Google pour les applications, l'infrastructure virtualisée, les outils de surveillance et d'alerte, etc. Google utilise les meilleures pratiques d'un point de vue intégré et holistique (personnes, processus et technologie), à l'instar de ce que préconise l'ITIL depuis les années 1980.
Google et de nombreuses autres organisations utilisent deux concepts DevOps importants - l'intégration continue et la livraison continue - pour encourager les mises à jour fréquentes, parfois des centaines par jour. Ces concepts ne sont pas incompatibles avec ITIL, qui suggère que cela soit fait de manière contrôlée avec un ensemble de processus, d'outils et de compétences alignés sur les besoins de l'entreprise. DevOps, Agile et Google sont tous d'accord.
DevOps et Agile ne sont pas le "Far West" de l'informatique
Une analyse systématique, une planification solide et une gestion minutieuse sont nécessaires pour mettre en place un système de gestion des versions efficace et efficient. C'est important si le résultat final souhaité est une approche traditionnelle consistant à effectuer des mises à jour selon un calendrier trimestriel, et c'est encore plus important dans le cadre d'un modèle DevOps avec un objectif de livraison continue. DevOps et Agile ne sont pas synonymes de laisser-aller ou de "Far West". La discipline et la structure sont essentielles à ITIL, Agile et DevOps. Google ne fait pas exception à la règle à cet égard.
Intégration des meilleures pratiques ITIL avec DevOps et Agile
Comment l'intégration et la livraison continues s'intègrent-elles à ITIL et aux autres meilleures pratiques ITSM ?
L'intégration et la livraison continues peuvent être réalisées en partie en poussant autant de changements que possible dans la catégorie des changements standard (c'est-à-dire pré-approuvés). Par exemple, votre politique de changement alignée sur ITIL pourrait être la suivante : "Si la demande de changement proposée passe tous les tests requis, elle est pré-approuvée et peut être mise en œuvre sans qu'il soit nécessaire d'obtenir des autorisations supplémentaires ou d'exercer une surveillance de la part de la direction" (ce qui permet de contourner le comité consultatif hebdomadaire sur les changements, etc.) Une autre approche complémentaire consisterait à automatiser autant de points d'approbation que possible dans le processus de gestion des changements.
L'automatisation est la clé
Les tests et la surveillance automatisés existent depuis longtemps et sont pleinement soutenus par les meilleures pratiques ITIL. DevOps va encore plus loin. Avec DevOps, l'objectif est de mettre en œuvre des capacités de test et de surveillance automatisés le plus tôt possible dans le cycle de vie du développement. Les tests automatisés intégrés basés sur le code encouragent le programmeur à développer des applications capables de détecter presque tout ce qui pourrait potentiellement mal tourner dans le système. Si le programmeur est vraiment malin, il essaiera même d'intégrer une solution permettant de résoudre automatiquement tous les problèmes détectés, sans intervention humaine (et sans qu'il soit nécessaire de créer un nouveau ticket d'incident - bien que le système puisse créer une alerte informative dans le système de gestion des événements).
DevOps n'est généralement pas adapté aux systèmes existants.
Cela dit, n'oublions pas que, dans de nombreuses organisations, il n'est pas toujours réaliste ou préférable d'utiliser Agile ou DevOps dans toutes les situations. Qu'en est-il des systèmes existants ? Qu'en est-il des systèmes qui ne sont ni virtualisés ni basés sur le cloud ? Et si votre organisation n'est pas prête à utiliser Agile ou DevOps parce qu'elle ne dispose pas des compétences, des outils, de la maturité culturelle, de la structure organisationnelle nécessaires, etc. L'ITIL traditionnel et/ou d'autres cadres de gestion des services connexes constituent toujours l'un des meilleurs moyens de gérer les systèmes et services informatiques existants.
En conclusion : Dans de nombreuses organisations, il serait judicieux d'utiliser une combinaison d'approches : ITIL pour certaines choses, Agile pour certains développements, Waterfall pour d'autres projets, et DevOps dans certaines circonstances où les conditions le permettent (peut-être en menant un pilote ou en utilisant DevOps uniquement pour les nouveaux produits et services numériques).
ITIL est-il donc mort ? Non ! Il est toujours pertinent et, dans certains cas, plus nécessaire que jamais.
