Close

Prêt pour une solution ITSM à haute vélocité ?

Dix bonnes pratiques en matière de gestion des changements

La gestion des changements est connue pour être procédurale, instable et complexe. Mais la réalité est tout autre. Lorsqu'elle est bien exécutée, la gestion des changements informatiques réduit les incidents, tout en garantissant l'agilité des processus et en limitant les interruptions de travail.

Comment gérer les changements ? Ces dix bonnes pratiques constituent un bon début :

1. Déterminez la tolérance au risque de votre organisation et planifiez en conséquence

Lorsqu'il s'agit de trouver le juste équilibre entre risques et rapidité, n'oubliez pas qu'il n'y a pas d'approche unique de la gestion des changements. Chaque organisation doit gérer sa propre culture, sa tolérance aux risques et ses exigences réglementaires, et chacune devrait prendre en compte ces considérations dans ses pratiques de gestion des changements.

La compréhension des risques implique notamment de comprendre les obligations de votre entreprise en matière de réglementation et de conformité. Lorsque la réglementation entre en jeu, il n'est plus question du nombre de temps d'arrêt que votre système peut se permettre avant d'entraîner une perte de clients ou du coût des ressources auxquelles vous ferez appel pour résoudre un problème. Il s'agit d'un ensemble de règles non négociables. Vous devrez obtenir certaines approbations. Vous devrez aussi répartir les tâches. Plusieurs réglementations, comme les normes SOX et le RGPD, rendent certaines activités non négociables, même si elles ralentissent un peu le processus.

La bonne nouvelle ? Cette planification n'est pas forcément statique. Les entreprises qui choisissent une approche prudente impliquant davantage d'approbations et de workflows rigides peuvent toujours réévaluer au fil du temps, en ajustant le niveau de rigueur de leurs processus en fonction du niveau de risque.

2. Utilisez l'évaluation des risques basée sur les données pour adapter continuellement vos pratiques de gestion des changements

Le suivi des métriques, en particulier des liens entre les changements et les incidents, constitue une base importante pour améliorer vos pratiques en matière de changement. Les données mettront en évidence les tendances, révélant les types de changements, les membres de l'équipe et les services qui sont les moins susceptibles d'être impliqués dans un incident. Ces informations peuvent vous aider à adapter le niveau de rigueur par rapport au risque pour différentes demandes de changement.

Une évaluation intelligente des risques permet souvent de rétrograder davantage de demandes de changement vers des workflows d'approbation moins rigoureux. Comme le suggère le processus de gestion adaptative des changements de Gartner, les organisations peuvent tenter de classer de plus en plus de changements normaux comme standard, puis pré-approuvés et automatisés.

Ci-dessous, nous avons regroupé quelques étapes pratiques pour que les changements standard deviennent la norme.

  1. Passez en revue les changements apportés au cours des derniers mois
    • Quels sont les changements les plus fréquents ?
    • Quels changements sont « standard » ?
    • Sur quels services ont-ils un impact ?
    • Quels changements ont porté leurs fruits ?
    • Quel était le délai moyen pour implémenter ces changements ?
    • Quels changements ont été demandés par les équipes de développement ?
  2. Sélectionnez trois à cinq changements standard qu'il serait possible d'automatiser
  3. Développez des types de demandes en libre-service pour les changements standard dans votre logiciel de gestion de services
    • Ajoutez du texte pour clarifier l'objet et le périmètre de la demande de changement standard
    • Déterminez les champs importants, tels que le système, l'app ou le service faisant l'objet du changement
    • Créez des règles d'automatisation pour approuver automatiquement le changement, transitionner les états et informer les équipes des mises à jour
  4. Prenez le temps de former vos équipes informatiques et de développement à cette nouvelle capacité
  5. Surveillez les performances au cours des prochains mois
    • Obtenez des informations pour améliorer vos offres existantes
    • Identifiez des changements standard supplémentaires à automatiser

3. Assurez-vous que votre gestion des changements soit aussi simple que possible

Personne n'aime alourdir sa charge de travail. C'est pourquoi la gestion des changements est souvent considérée comme une nuisance. Les pratiques en la matière exigent des personnes qu'elles documentent quelque chose, souvent dans un outil avec lequel elles n'aiment pas travailler, et de suivre un processus comportant une ou deux étapes supplémentaires. Les développeurs chargés de publier le code se sentent alors détournés de leur tâche principale.

La réponse à ce défi majeur est la simplicité : votre gestion des changements doit être aussi simple que possible. Là où vous le pouvez, travaillez avec le minimum d'approbations. Choisissez des outils technologiques qui s'intègrent de façon transparente, afin que les développeurs ne doivent pas entrer les mêmes informations dans plusieurs systèmes. Automatisez le plus possible.

Plus vous simplifiez le processus, plus vite vos équipes seront opérationnelles et le resteront.

4. Repensez le modèle CAB traditionnel

Dans la plupart des organisations informatiques traditionnelles, un comité consultatif sur les changements (CAB) est chargé d'évaluer les implications techniques et opérationnelles des demandes de changement. Le processus traditionnel crée certains défis : livraisons lentes, processus instables et, parfois, manque de communication et de collaboration. C'est pourquoi les équipes les plus performantes repensent le modèle CAB.

L'objectif est de conserver la valeur ajoutée que ces comités ajoutent à nos processus informatiques (en encourageant les communications et en équilibrant la nécessité de changements avec les risques liés à ces derniers), tout en rendant le processus CAB type plus agile et plus stratégique. Voici les implications potentielles :

  • Demander uniquement l'approbation du CAB pour les changements les plus risqués (et utiliser des outils éprouvés comme la revue par les pairs, les checklists virtuelles et l'automatisation pour gérer les changements moins risqués)
  • Laisser le CAB se charger de la stratégie et aider les équipes à élaborer des pratiques qui réduisent les risques et la charge de travail liée à la gestion des changements grâce à l'automatisation et à des processus efficaces
  • Organiser des CAB virtuels et en temps réel au lieu d'attendre des réunions en personne pour traiter les changements majeurs ou les questions

La clé ? La stratégie. Au lieu d'agir comme contrôleur, le nouveau CAB favorise le changement. Au lieu de devenir un goulot d'étranglement, il constitue une ressource stratégique. La revue de code et les détails techniques sont réservés aux revues par les pairs et aux personnes les plus à même de détecter les erreurs dans le code. Le CAB peut ainsi se concentrer sur le processus et la stratégie, et soutenir la livraison continue.

5. Utilisez des outils pour automatiser et perfectionner vos processus

L'automatisation de vos outils est l'un des meilleurs moyens de limiter la charge des processus de gestion des changements pour vos équipes. De simples contrôles au niveau de nos outils peuvent garantir notre conformité et réduire considérablement les risques, sans obliger personne à consacrer inutilement du temps à de nouveaux processus.

Comme l'expliquait Guy Herbert, notre futurologue spécialiste des risques, dans un récent article consacré à la conformité et aux risques : « En vérité, peu sont ceux qui ont besoin d'un processus d'approbation à six niveaux et de subir des mois de va-et-vient entre les comités d'approbation de la conformité… Ce dont nous avons réellement besoin, c'est de quelques contrôles simples qui garantissent qu'aucun changement non conforme ne passe entre les mailles du filet. Nos outils jouent ici un rôle essentiel. Bitbucket, par exemple, ne laissera pas nos développeurs pusher le code sur lequel ils ont travaillé dans la base de code tant qu'il n'a pas été revu par un autre développeur compétent. Bamboo ne lancera pas un nouveau code s'il n'a pas été soumis à nos processus de conformité dans Bitbucket. »

6. Déployez progressivement des livraisons plus petites pour vous assurer que vos changements se passent bien

L'approche héritée des livraisons consistait à les regrouper et à les lancer toutes en même temps. Aujourd'hui, nous savons que cette approche favorise les incidents majeurs et complique la recherche de la source d'un problème, le cas échéant. Des mises en production plus petites et plus fréquentes peuvent limiter le périmètre d'un incident potentiel. Les déploiements progressifs de type « canary » ou le feature flag avec un petit sous-ensemble d'utilisateurs permettent de tester et de démontrer la stabilité avant un déploiement complet.

7. Considérez ITIL comme un ensemble de directives, et non de règles strictes et rapides

ITIL a parfois mauvaise réputation. Il est considéré comme restrictif et obsolète. Mais la vérité est tout autre : il a beaucoup à offrir aux équipes informatiques, y compris à celles qui ont adopté une culture DevOps. Le problème n'est pas qu'ITIL est trop rigide, mais réside dans notre approche de ses directives.

Considérez ITIL comme une série de règles strictes et rapides, et il paraîtra bien évidemment restrictif. Considérez-le comme un ensemble de directives fondamentales sur lesquelles votre entreprise peut s'appuyer et il apparaîtra comme un auxiliaire qui vous accompagnera au fur et à mesure que vous développez vos pratiques de gestion des changements.

Ce conseil s'applique à chaque framework et approche culturelle. ITIL, Lean, DevOps, Agile, CD… aucun framework, aussi apprécié soit-il, ne résoudra tous vos problèmes en un coup de baguette magique. Trop souvent, nous nous tournons vers un framework ou un outil pour résoudre des problèmes internes, alors que nous devrions nous appuyer sur la culture d'équipe.

8. Donnez la priorité à la collaboration

Des CAB aux groupes DevOps, les équipes performantes adoptent la collaboration, l'ouverture et les mises à jour en temps réel. La gestion des changements permet de coordonner l'ensemble des équipes. Les changements, les incidents et les problèmes se répercutent sur plusieurs équipes. Cet état de fait devient plus évident à mesure que votre organisation se complexifie.

Une bonne gestion des changements ne peut tout simplement pas être cloisonnée. Les organisations qui s'efforcent d'encourager une collaboration plus ouverte sont susceptibles d'améliorer leurs pratiques de changement.

9. Tirez parti de l'ingénierie du chaos et de la résilience

L'ingénierie du chaos est une pratique récente qui vise à tester la résilience en retirant ou en désactivant les composants d'un produit ou d'un service. De même, l'ingénierie de la résilience aborde délibérément tous les facteurs de stress possibles sur un système (par exemple, en pushant un système présentant un nombre élevé d'utilisateurs ou un trafic important).

Les deux pratiques permettent de cerner les problèmes et les changements nécessaires pour éviter les incidents futurs. Cette approche préventive apporte une grande valeur ajoutée aux équipes de gestion des changements et permet aux équipes de gestion des incidents de gagner du temps, d'économiser du budget et d'éviter la fatigue d'alerte.

10. Choisissez des outils connus et appréciés de vos équipes de développement

De bons processus de gestion des changements doivent être intégrés aux différents outils utilisés par vos développeurs. Demander aux équipes de se familiariser avec un nouvel outil, de saisir des informations dans plusieurs outils ou de gérer un outil qu'elles connaissent et maîtrisent mal a tendance à ralentir l'adoption, ce qui affectera votre capacité à fournir des mises à jour précieuses aux clients.

Chez Atlassian, nous suivons les changements à l'aide de Jira Service Management. La plateforme Jira facilite le rapprochement des équipes de développement et opérationnelles, garantissant une transparence et un contexte traçable avant même que les développeurs ne commencent à coder, jusqu'au moment où les changements sont déployés en production.