complexity-esn-lille-ssii-grenoble-paris-lyon-nantes-bordeaux-hardis-group

Ce n’est pas nouveau, lorsqu’une nouvelle approche apparaît, il est tentant de faire table rase du passé. Pourtant, la bonne approche à moyen terme, est plutôt de prendre le meilleur de chaque méthodologie. En effet, DevOps et ITIL ont tout pour favoriser une gestion efficace des développements et de l’exploitation, sans sacrifier ni la rigueur et ni la créativité.

DevOps vs ITIL : une question complexe

Tel un clivage politique, les avis sont souvent assez tranchés quant à la compatibilité – ou l’incompatibilité – entre les méthodes agiles, et notamment DevOps et ITIL. La question est pertinente, d’autant plus que chaque méthodologie ne tire pas sa source des mêmes enjeux, et donc des mêmes équipes : ITIL est ainsi issue du monde de l’exploitation, tandis que agilité et DevOps puisent leur inspiration du côté du développement. Et les arguments, pas toujours inspirés de la bonne foi, ne manquent pas pour les opposer : agile vs statique ou encore rapidité vs lenteur (au profit de la stabilité). Mais la réalité est, dans les faits, beaucoup plus complexe.Inutile de ménager le suspense : oui, DevOps et ITIL sont compatibles. Car bien que leurs approches respectives soient clairement différentes, ces méthodologies ont toutes deux pour objectif la mise en œuvre de bonnes pratiques. Différentes certes, contradictoires, certainement pas. Inutile donc de choisir entre les deux. Pour autant, et afin de concilier les deux dans le cadre d’un processus global de gestion efficace des développements et de l’exploitation, rigueur et créativité ne seront pas de trop. Et seront même les conditions de base pour surmonter les écarts en termes de vision et de pratiques.Le décalage temporel n’est, lui-aussi, pas à sous-estimer : ITIL, imaginé pour combler l’absence de processus formels de gestion du cycle de vie des applications, a largement été diffusé dans la dernière décennie. À l’opposé, beaucoup considèrent DevOps comme une “simple” extension de l’agilité aux tâches d’exploitation, qu’il suffit d’imposer aux équipes qui en ont la charge. Mais dans les faits, ITIL étant déjà largement diffusée, la mise en place de DevOps devra prendre en compte cette base, qui est loin de ne comporter que des inconvénients.Dès lors, concilier DevOps et ITIL consistera donc à injecter l’agilité proposée par DevOps dans l’exploitation, tout en capitalisant sur les processus et la traçabilité imposés par ITIL. Dans sa version 3, ITIL introduit d’ailleurs la notion d’amélioration continue et une approche globale du cycle de vie d’un système pour répondre aux besoins métiers. Ce qui renvoie à la notion d’itération des méthodes agiles. Le défi repose donc sur la fréquence des changements et la communication transverse. En bref, DevOps doit challenger ITIL, tandis qu’ITIL permet d’encadrer DevOps.

Transition des services : DevOps, complémentaire à la gestion des changements

En termes d’exploitation, la gestion des changements vise à répondre aux besoins d’évolutions, tout en minimisant le risque de nuisance pour l’utilisateur : régression, indisponibilité, etc. Les changements doivent être évalués, autorisés, enregistrés puis planifiés pour répondre à des objectifs de stabilité, de traçabilité (versions, configurations) et de prédictibilité. La valeur ajoutée immédiate est d’imposer un cadre aux changements dans une organisation peu mature, et permettre de donner une image précise à un instant T du système.Si la perception initiale peut être négative (lourdeur et lenteur du processus), elle est indispensable à la chasse aux changements sauvages. Et si le travail de modélisation a été correctement réalisé en amont, le processus ne sera pas plus lent ou lourd : il sera encadré et la réactivité sera au rendez-vous. Concrètement, cela signifie qu’il est essentiel de définir des processus d’approbation en fonction du type de changement, du risque associé et de sa criticité : ce qui favorise la réactivité en cas d’urgence, et le formalisme dans tous les cas. Ces processus formels permettent en outre d’imposer un feedback systématique sur les changements effectués, dans une logique d’amélioration continue.Bien sûr, les tâches aboutissant à la création d’une demande de changement, de même que leur mise en œuvre, peuvent être automatisées sans remettre en cause le fait que les changements doivent passer par un comité d’approbation. En d’autres termes, les tâches évoluent, mais la méthode d’évaluation ne change pas. Et pour être tout à fait en phase avec DevOps, le comité d’approbation doit privilégier la communication transverse et les décisions collégiales.

Exploitation des services : la gestion des incidents, complémentaire à DevOps

Les organisations agiles et DevOps sont généralement définies pour répondre aux impératifs de livraison de nouvelles fonctionnalités. On peut parler de cas de travail “nominal”. Mais, en dehors du support, on y trouve très rarement d’équipe dédiée à la gestion des problèmes en production. Et lorsque le cas de figure se présente, il est souvent difficile de suivre une méthode pré-établie d’analyse, d’escalade et de résolution. Les itérations courtes ne sont en effet pas conçues pour la prise en compte et la gestion de nouveaux problèmes à diagnostiquer.C’est, a contrario, le cas d’ITIL, qui sait répondre à ce cas de figure, en définissant une organisation et des processus capables de gérer au mieux les aléas liés à la gestion des problèmes et des incidents. Les rôles y sont définis, des règles de priorisation aussi. Ce qui n’est en rien incompatible avec une organisation agile. Ainsi, dans une logique d’amélioration continue, les processus ITIL vont nourrir les tâches DevOps. En premier lieu par l’enrichissement du monitoring sur un périmètre complet, de l’infrastructure aux cas métiers. Par l’automatisation des opérations de contournement sur incident ensuite, ainsi que par l’adjonction des cas de tests automatisés.Pour mettre en place cette mécanique, la création d’un processus de remontée d’informations entre l’exploitation et la R&D est essentielle. Ce qui se traduit concrètement par des processus d’escalade, une méthode de gestion de crise et un back log partagé intégrant l’occurrence des incidents, afin de pouvoir adapter la priorisation de leur correction. Un dispositif qui ne sera efficace qu’à la condition de pouvoir mobiliser les équipes R&D quand cela est nécessaire : développeurs, testeurs et DevOps doivent ainsi pouvoir disposer de temps dédiés à ces sujets, en fonction des événements survenant en production. Dès lors, ITIL et DevOps pourront non seulement cohabiter, mais aussi et surtout se compléter l’un l’autre.

Maxime Orand

Consultant

SUR LE MÊME THÈME

photo d'un magasin de jouet

Projet d’accélération du commerce digital chez King-Jouet

5 décembre 2022

time_agile_scrum_ssii_hardis_group_grenoble_lille_lyon_nantes_paris_bordeaux

Méthode AGILE : du mythe à la réalité

Méthode AGILE : du mythe à la réalité

agilité-esn-lille-ssii-grenoble-paris-lyon-nantes-bordeaux-hardis-group

DevOps : les pièges sont humains, pas techniques

DevOps : les pièges sont humains, pas techniques

Leave a Reply