Début des années 2000, de nombreuses entreprises ont du mal à s’organiser pour opérer des systèmes d’information qu’elles ne maîtrisent pas complètement. ITIL est une bénédiction: il fournit un ensemble de processus et de bonnes pratiques compréhensibles de tous, profils techniques ou non.
20 ans plus tard, ITIL n’est plus adapté au monde du cloud natif, au déploiement continu ou aux niveaux de service les plus exigeants. Si certains concepts sont encore plus ou moins d’actualité, d’autres sont devenus des freins.
Ce premier article propose une analyse des limites des approches inspirées d’ITIL dans un contexte business et technologique contemporain. Un second article explorera les impacts de ces changements sur les métiers associés et proposera des pistes d’évolutions.
Stabilité Vs Vitesse d’adaptation
ITIL date d’une époque ou l’on devait faire face à deux grandes difficultés. La première était la maîtrise des infrastructures techniques, supportées par des moyens physiques. Les « administrateurs systèmes » étaient alors des gourous de l’informatique. On leur prêtait le pouvoir un peu mystique. Ils comprendrenaient les conséquences des nombreuses actions manuelles à effectuer pour construire et maintenir un système. La seconde difficulté résidait dans la gestion des évolutions de larges solutions logicielles peu modulaires, où le moindre changement de code pouvait engendrer des chaines de dépendances aussi effrayantes qu’imprévisibles.
ITIL a apporté un cadre et de la stabilité, nécessaires pour maîtriser les risques, gérer les impondérables au mieux des intérêts des utilisateurs. Il a aussi permis de structurer le support, ou encore améliorer la qualité dans la durée et structurer la diffusion de la connaissance. ITIL a contribué à la maitrise, apportant ainsi la stabilité recherchée.
20 ans plus tard, les enjeux business ont changé. Le nombre d’acteurs dans l’industrie IT a explosé. Les services ne se sont pas uniquement digitalisés, ils se sont aussi interconnectés. Les produits logiciels ne se vendent plus en tant que tel, mais comme des services managés permettant de générer des revenus récurrents. Les opportunités doivent être concrétisées très rapidement, les organisations, pour survivre, doivent faire preuve d’agilité et adapter leur contenu en permanence. La vitesse est devenue le maître-mot.
En 20 ans, on est passé d’un enjeu de maîtrise de la stabilité à une exigence de vitesse. Le paradigme a changé.
L’impact du Cloud et des méthodes DevOps
L’offre technologique a naturellement accompagné les besoins business de vitesse et de flexibilité. Cette évolution s’est appuyée sur trois piliers. Le premier est la démocratisation du Cloud, offrant le bénéfice d’infrastructures physiques de manière immatérielle et flexible. Le second est l’essor des méthodes modernes type DevOps, l’avènement de l’IaC (Infrastructure as Code), l’automatisation de l’ensemble du cycle d’ingénierie logicielle, du code au test jusqu’à la production. Le troisième pilier de cette évolution est l’avènement de nouvelles architectures modulaires (telles que les micro services) ou les systèmes complexes sont découpés en un large ensemble de sous-systèmes plus simples, et relativement indépendants les uns des autres.
Ces trois innovations ont changé la donne et les impacts ont été nombreux. L’ensemble des actions techniques – y compris celles touchant le monde physique – sont maintenant traduites par du code, testable, auditable, et traçable. Fini les mythes, fini les dépendances vers des gourous. Si la complexité des systèmes continue d’augmenter, on sait désormais la gérer.
Certes, la version 4 d’ITIL met l’accent sur la valeur et le lien avec les clients (héritage de l’ère Agile), et encourage à la collaboration et à l’utilisation d’approches itératives. Mais ce n’est qu’un vernis sur une poutre oxydée, les anciens préceptes deviennent obsolètes.
Coûts de structure et bureaucratie
Beaucoup d’entreprises ayant adopté ITIL ont fait le choix de personnifier certains rôles. C’est ainsi que sont apparus des Change Manager, des Incident Manager, ou encore des Problem Managers. Profils souvent dupliqués pour couvrir différentes time-zones (indispensable pour l’incident management par exemple). Toutes ces personnes étant généralement elles-mêmes rattachées à un manager. C’est beaucoup de structure.
Cette structure doit s’occuper et se montrer utile et active. Comme ces processus nécessitent rarement quelqu’un à plein temps, on confie à leurs incombants la mission de définir et implémenter les processus, les mettre en œuvre et en rendre compte. C’est comme ça que progressivement, avec les meilleures intentions qui soient, la bureaucratie apparaît : meetings récurrents avec nombreux participants, fichiers Excel à remplir, KPIs à mettre à jour, etc… Non seulement la structure coûte, mais elle génère des overheads pour les autres. La conséquence classique est le ghosting des équipes techniques. Une déconnexion se met progressivement en place. Non seulement le ratio contributeur direct par contributeur indirect se dégrade, mais l’impact des contributeurs indirects diminue et se dilue.
La technologie au service de la productivité
Le phénomène inverse a émergé avec l’avènement des méthodes et outils d’ingénierie contemporains. Elles peuvent s’appuyer sur des plateformes communes et déterministes et des environnements d’intégration et de déploiement continu (CI/CD) performants. Un développeur peut se concentrer sur l’implémentation de ses requirements business, un QA sur ses tests, un CloudOps sur le run. Toutes les autres tâches sont standardisées, intégrées et automatisées. Il n’y a plus besoin de coordinateurs pour garantir des bonnes pratiques que l’on a pu coder et automatiser.
La mise en place de ce type d’approche apporte deux avantages essentiels. Le premier est l’existence d’un cadre qui permet l’implémentation de processus robustes et adaptés à l’amélioration continue, apportant qualité et vitesse d’exécution. Le second avantage réside dans la factorisation des efforts de coordination. En d’autres termes, ces méthodes permettent d’augmenter le ratio de contributeur direct (sous-entendu « technique ») dans les équipes. C’est efficace, la base même du lean. Sans parler des bénéfices de l’IA qui permettront bientôt d’aller au-delà.
En conclusion
Si les approches ITIL perdureront encore un peu pour des cas d’usages spécifiques tels que l’IT Enterprise, elles ont déjà disparu de nombreuses entreprises de la tech dont les enjeux d’adaptation et de vitesse d’exécution exigent des approches plus modernes. Ces anciennes méthodes, qui avaient leur valeur dans leur contexte d’origine, vont progressivement s’effacer. Certaines bonnes pratiques resteront, mais la majorité vont évoluer. Pour de nombreuses entreprises, ce changement représente une réelle transformation, avec ses opportunités et aussi ses risques : vu de l’intérieur, il fait peur. Et pourtant il est un véritable vecteur de performance et d’agilité.
Nous verrons dans les prochains articles comment une telle transformation peut être mise en œuvre de manière pratique.
Cet article vous a plu ? Partagez sous Linked’In !
Photo: Udaipur City Palace, Radjasthan, Inde.
Laisser un commentaire