Top 10 des bonnes pratiques en matière de gestion des changements

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.

Grâce à Jira Service Management, vous pouvez personnaliser les approbations et les workflows en fonction des spécifications d'une organisation. Gérez la flexibilité ou l'automatisation des processus comme vous le souhaitez. Par exemple, vous pouvez automatiser certains processus à faible risque et protéger les processus plus complexes grâce aux approbations.

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 gestion des 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

Après avoir évalué les pratiques de gestion des changements précédentes de votre équipe et les risques liés aux changements, il peut être utile de centraliser la documentation d'évaluation des risques. Grâce à l'intégration Confluence de Jira Service Management, les équipes peuvent consulter une source de référence contenue dans un document de plan de changement. Sur cette page, les collaborateurs peuvent ajouter un modèle de plan de changement aux informations d'évaluation des risques.

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. C'est là qu'une source de référence centrale, comme une page Confluence de plan de changement, peut faciliter la documentation en impliquant toute l'équipe.

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. Ces fonctionnalités de Jira Service Management offrent aux équipes la flexibilité nécessaire pour travailler à leur propre rythme et selon leurs propres règles.

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

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.

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.

Il est plus facile d'organiser des livraisons contrôlées plus petites lorsque les équipes peuvent coordonner ces livraisons sur un calendrier des changements. Ce dernier permet aux développeurs d'éviter les zones de conflit ou d'identifier les dates d'interdiction. Les fonctionnalités de gestion des changements de Jira Service Management permettent aux équipes d'accéder à un calendrier centralisé contenant les informations dont elles ont besoin pour réaliser ces livraisons fragmentées.

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.

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.

Tout dans Jira Service Management vise à unifier les équipes afin d'atteindre les objectifs plus rapidement, le cas échéant : implémenter des changements plus vite, sans incident. Les équipes haute vélocité et soudées ont un point commun : la collaboration. Une plateforme transparente proposant des outils comme Confluence, des solutions de chat et de visioconférence intégrées et des workflows personnalisables permet à chacun de se lancer et d'avancer dans son travail, à sa manière, avec un contexte complet.

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.

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.