Les bonnes pratiques en matière de Change Management dans l’IT
Assurer la stabilité d’un système tout en contribuant à son évolution : telle est la promesse du Change Management, un concept hérité du management et des RH qui s’applique désormais à l’informatique. Un certain nombre de bonnes pratiques contribue à une gestion efficace des changements, et peut être appliqué par les développeurs eux-mêmes. Revue de détail.
Change Management, des techniques de management appliquées à l’IT
Gérer une organisation humaine, la transformer en interne par un processus souple, progressif et sécurisé : tels sont les moteurs du Change Management, également appelé « conduite du changement », utilisé depuis de nombreuses années par les services RH et les managers.
Ses grands principes ont depuis lors été transposés dans l’IT. Il est ainsi défini comme un principe moteur pour réaliser des mises à jour et intégrer des nouveautés à un système existant en assurant sa continuité, le tout de manière maîtrisée, réversible et documentée, sans risque d’interruption de service.
Une boîte à outils et bonnes pratiques comme l’ITIL (Information Technology Infrastructure Library) intègre la question du Change Management appliqué à l’IT. Il s’agissait d’un pilier de la version 3 d’ITIL, qui a été renommé en Change Enablement dans la V4. Mais son principe reste le même : la gestion du changement vise à assurer l’ajout, la modification ou la suppression de tout ce qui peut affecter un service, de l’appli aux processus en passant par les éléments critiques. Mis à jour en 2019, l’ITIL intègre aujourd’hui le Change Management appliqué à des organisations flexibles de travail, type DevOps et Lean/Agile, ce qui explique que l’on retrouve des bonnes pratiques historiques et de nouveaux ajustements dans les pratiques actuelles.
Les méthodes historiques du Change Management
Avant les années 2010, le Change Management dans les environnements IT s’appuyait sur l’anticipation des risques, la mise en place de déploiements intelligents et la réversibilité des opérations. Autant d’aspects qui sont toujours utilisés dans de nombreuses organisations où les changements sont appliqués sur des systèmes critiques.
Parmi les bonnes pratiques que l’on retrouve notamment dans des secteurs comme la banque ou l’assurance, où l’ITSM (IT Service Management) et l’ITIL sont implantés, le « Change Advisory Board » figure en bonne place. Il s’agit d’un conseil consultatif auquel les développeurs proposent les changements. L’organe, composé de différents représentants du service IT et des pôles métiers, étudie de manière concertée les effets des changements proposés et pointe les risques éventuels. C’est une instance nécessaire pour prioriser les modifications apportées au système et les approuver.
Les préconisations de Change Management touchent aussi aux phases de déploiement. En effet, les mises à jour, quelles qu’elles soient, sont susceptibles d’affecter la continuité d’un service. Aussi, l’une des bonnes pratiques héritées de l’ITIL consiste à planifier les fenêtres de déploiement, par exemple en les mettant en place de nuit, ou le dimanche, afin qu’elles n’affectent pas les opérateurs. Dans le même ordre d’idée, le Release Management, qui établit des mises en production cycliques, permet de préparer l’ajout d’une fonctionnalité ou un update en l’intégrant à des versions planifiées.
Enfin, le Rollback Plan encadre la sécurité des systèmes : il s’agit de concevoir des mises à jour qui puissent être annulées facilement en faisant appel à une version antérieure du système. De cette façon, si l’on constate un bug ou une faille, le système peut être redémarré à sa dernière itération fonctionnelle.
DevOps et CI/CD : des bonnes pratiques en continu
La philosophie DevOps et les chaînes d’intégration et de développement continus CI/CD ont transformé la manière dont les développeurs intègrent leurs mises à jour à un système. Et c’est notamment par l’automatisation que ce type d’approche révolutionne le Change Management.
Dans les systèmes complexes, on demande aujourd’hui à un chef de projet ou à un développeur de connaître des outils comme Jenkins, GitLab ou ArgoCD, et de suivre les protocoles CI/CD lors du déploiement. Des outils de tests automatisés s’exécutent directement sur un dépôt, où le développeur aura ajouté sa mise à jour, et le déploiement s’ensuit si aucune erreur n’est remontée.
Pour s’assurer de la fluidité des changements et de leur lisibilité par l’ensemble d’une équipe IT, le Change Management appuie également les démarches de documentations et de suivis poussés. Jira ou GitHub Projets sont ainsi à connaître, puisqu’ils permettent de lister l’ensemble des évolutions d’une appli ou d’un réseau, afin que développeurs et opérateurs aient toujours la trace des changements appliqués. Les plateformes de documentation collaborative (type Notion ou Confluence) aident aussi à ce que la transmission d’informations s’effectue en continu. Dans le même ordre d’idée, ITIL préconise d’inventorier les dépendances, les machines, les serveurs, les applis au sein d’une CMDB (Configuration Management Database), sur lesquels les mises à jour peuvent être simulées en listant l’intégralité des services/API qui seraient amenés à être modifiés.
Enfin le Feature Flagging, qui peut réserver le déploiement d’une nouvelle fonctionnalité à un nombre limité d’opérateurs, ou restreint telle ou telle partie du code en fonction d’un temps donné, peut aussi être utile à l’adoption progressive d’une mise à jour ou à un usage ponctuel d’un changement. Les feature flags font aujourd’hui partie du bagage technique commun des chefs de projets et développeurs DevOps qui veulent une approche du Change Management souple et versatile.
Comme on le voit, le Change Management, défini au départ comme un ensemble de processus susceptibles d’améliorer la continuité des systèmes, s’est largement imposé parmi les développeurs et les project managers, et s’intègre aujourd’hui à la philosophie DevOps.
