Comment les équipes se partagent les rôles et les responsabilités en matière de gestion des changements

Gestionnaire/Coordinateur des changements

Les gestionnaires des changements (parfois appelés coordinateurs) doivent généralement gérer tous les aspects des changements informatiques. Ils établissent les priorités des demandes de changement, évaluent leur impact, et acceptent ou rejettent les changements. Ils documentent également les processus de gestion des changements et les plans correspondants. Plus important encore, ils préparent, organisent et animent les réunions du comité consultatif sur les changements (CAB). La réussite d'un gestionnaire des changements se mesure généralement en fonction de l'atteinte des objectifs temporels et budgétaires.

Approbateur/autorité de changement

Une autorité de changement est une personne qui prend la décision d'autoriser ou non un changement. Parfois, il s'agit d'une seule personne, comme un gestionnaire ou un cadre. Parfois, il s'agit d'un groupe de personnes qui font partie d'un CAB, ou encore d'un pair en charge de l'évaluation. Selon ITIL 4 : « Dans les organisations à haute vélocité, il est courant de décentraliser l'approbation des changements, ce qui rend la revue par les pairs l'un des meilleurs indicateurs de haute performance. »

Les gestionnaires des changements travaillent généralement en étroite collaboration avec l'approbateur afin d'approuver les changements et de les diffuser au sein d'une organisation. Dans certains cas, en particulier dans les petites organisations, le gestionnaire des changements fait office d'approbateur. Il peut donc prendre les décisions sans impliquer des personnes ou des équipes supplémentaires.

Parties prenantes métier

Les parties prenantes métier participent souvent à la gestion des changements et peuvent être impliquées dans le processus d'autorisation. Cette approche est de plus en plus courante, compte tenu de l'importance cruciale des services logiciels pour la plupart des entreprises.

Par exemple, si un changement influe sur la connexion entre le logiciel de suivi des paiements de l'équipe financière et le système CRM de l'équipe commerciale, les parties prenantes des deux équipes devront peut-être participer aux réunions du CAB et aux décisions finales concernant un changement.

Ingénieurs/Développeurs

Les équipes de développement soumettent généralement les changements à des fins d'approbation et expliquent leur bien fondé. Dans les entreprises qui adoptent une approche « Vous le développez, vous l'exécutez », ces équipes déploient le changement approuvé, le surveillent et réagissent souvent à tout incident ou problème connexe. Dans d'autres cas, l'équipe de gestion des incidents responsable de tout incident provoqué par le changement peut être distincte des développeurs qui l'implémentent.

Agents du centre de services

Les agents du centre de services peuvent apporter une perspective unique et de première ligne sur les incidents et les problèmes de service courants qu'un changement peut entraîner.

Gestionnaires des opérations

Étant donné qu'ils sont responsables du fonctionnement quotidien des systèmes, les gestionnaires des opérations ont le dernier mot sur les risques et les dépendances.

Gestionnaires de la relation client

Pour représenter le client, ces gestionnaires peuvent fournir des informations sur l'état d'esprit, les frustrations et l'évolution des besoins des clients.

Responsables de la sécurité des systèmes d'information et ingénieurs réseau

Les experts en sécurité réseau et en infrastructure cloud fournissent des informations importantes sur les menaces et les vulnérabilités.

Qu'est-ce qu'un CAB ?

Regroupant les personnes assumant les responsabilités décrites ci-dessus, les CAB sont des groupes chargés d'évaluer les risques liés aux demandes de changement et d'approuver (ou non) ces dernières. En règle générale, un CAB organise régulièrement des réunions pour examiner tous les changements proposés et, si nécessaire, fait appel à des experts pour expliquer, défendre ou évaluer ces changements. Les CAB traditionnels agissent en tant que contrôleurs chargés de contrôler la livraison des changements.

C'est pourquoi, outre les réunions fastidieuses, les backlogs de demandes de changement interminables et la distance par rapport au travail lui-même, les CAB sont souvent très mal perçus. Heureusement, nombre d'entre eux évoluent pour favoriser la livraison de logiciels Agile, assumant ainsi un rôle de conseil plus stratégique. Les CAB se transforment en conseillers chargés de surveiller les tendances du changement, de recommander des pratiques qui peuvent y répondre, et de trouver des solutions pour aider les équipes à offrir de la valeur aux clients et à réduire les risques.

Le défi des CAB

Les clichés entourant les « mauvaises réunions » s'appliquent également aux CAB. Ils sont souvent critiqués : ils constituent une perte de temps, ils ne font pas grand-chose, ils impliquent trop de personnes au hasard et ils pourraient être remplacés par « un simple mail ». Cela s'explique en partie par le fait que les CAB traditionnels assument beaucoup trop de responsabilités.

Recourons à une métaphore de l'aviation pour illustrer le défi. On peut imaginer le CAB comme la tour de contrôle d'un aéroport. Cette tour de contrôle doit accomplir la tâche suivante : annoncer aux pilotes qu'ils peuvent atterrir. Elle ne devra jamais déterminer la sûreté des avions ou la compétence des pilotes, car ces aspects sont déjà évalués par l'Administration fédérale de l'Aviation (FAA) et d'autres organismes compétents en la matière.

En attendant, beaucoup trop de CAB rassemblent un large éventail d'intervenants et sont chargés de prendre des décisions générales en matière de sécurité concernant toutes sortes de changements différents. En outre, ces décisions sont souvent prises à la fin de la semaine, alors que tout le monde n'a qu'une seule envie : partir en week-end. Un CAB est tout simplement voué à l'échec.

De plus, les CAB sont souvent avant tout préoccupés par le risque que des changements provoquent des incidents. Cette préoccupation est bien sûr importante, mais ils doivent également envisager le risque de retarder des changements précieux. Avancer trop lentement peut nuire aux clients et, dans un univers ultra-compétitif de SaaS, causer la perte d'une organisation.

Il est possible de magnifier et de cibler le rôle du CAB. Adopter de bonnes pratiques permet d'automatiser de nombreux changements. De cette façon, le CAB peut devenir un conseiller important, suivre les tendances et collaborer avec les équipes pour accélérer les changements qui profitent aux clients.

Positionnez votre CAB en tant que conseiller stratégique

La première étape pour repositionner le CAB consiste à dissiper l'idée qu'une gestion complexe des changements produit des résultats positifs. Les données du rapport « State of DevOps » 2019 ont révélé que les processus qui nécessitent l'approbation d'un CAB ont eu un impact négatif sur les performances de livraison de logiciels. D'ailleurs, les personnes interrogées qui suivaient ces processus étaient 2,6 fois plus susceptibles d'être peu performantes. De plus, rien n'indique qu'un processus formel d'approbation pouvait être associé à une diminution des taux d'échec des changements !

C'est pourquoi les équipes modernes prennent les mesures suivantes pour améliorer leurs CAB.

Cessez de suivre une approche « unique » de la gestion des demandes de changement

Chaque demande de changement est l'occasion de suivre et de recueillir des informations. Nous pouvons en apprendre davantage sur les taux de réussite, les incidents connexes et les facteurs qui y sont corrélés. Au fil du temps, grâce aux données, il devrait être possible d'approuver et d'automatiser de plus en plus de changements. Seuls les changements fondamentaux les plus risqués devraient nécessiter une approbation manuelle.

Rapprochez la gestion des changements et des livraisons

L'approche héritée des livraisons consistait à les regrouper et à les lancer toutes en même temps. Les CAB ont ensuite la lourde tâche d'examiner minutieusement et d'approuver d'interminables séries de changements. Cette approche favorise les incidents majeurs et complique la recherche de la source d'un problème, le cas échéant. Elle ralentit également le rythme auquel les équipes apportent de la valeur à leurs clients. En outre, les gestionnaires des changements et des livraisons peuvent consacrer moins de temps aux tâches de gestion de projets.

Optez pour des livraisons progressives pour tester et itérer

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. Ces approches limitent le périmètre d'un incident potentiel et démontrent la réussite d'un déploiement avant de le lancer dans tous les environnements.

Utilisez l'automatisation et les outils pour simplifier la gestion des changements

Les équipes haute vélocité commencent à repenser les anciens modèles d'approbation. Plutôt que de traiter un long backlog de demandes de changement lors d'une réunion hebdomadaire en personne, il est possible de recourir à la collaboration virtuelle. Ce n'est pas plus compliqué que d'envoyer un e-mail détaillant les demandes de changement pour les examiner avant une réunion du CAB. Dans d'autres cas, des éléments comme les tickets Jira et les pages Confluence peuvent fournir aux réviseurs de changements le contexte dont ils ont besoin pour collaborer de manière asynchrone et approuver les changements. Grâce à Jira Service Management, les équipes peuvent collaborer de cette manière, voire participer à une visioconférence ou créer un canal Slack dédié. Quel que soit le moyen de communication préféré de votre équipe, tout est toujours hébergé au même endroit, de sorte que tout le monde reste en phase.

En raison des outils ITSM hérités, les équipes chargées des infrastructures, des opérations et du développement ont plus de mal à soumettre des demandes de changement. Adoptez l'automatisation et les logiciels modernes pour réduire la charge imposée par la saisie manuelle des informations sur les changements. Un développeur voudra éviter à tout prix de renseigner des tickets dans un système complexe et distinct si cette tâche peut être automatisée. Dans Jira Service Management, les équipes peuvent tirer parti de l'automatisation pour simplifier le processus de changement, atténuer les risques et réduire les temps d'arrêt.

Appliquez les principes de la validation anticipée (ou « Shift Left ») et rapprochez la gestion des changements des experts

La revue par les pairs est l'une des stratégies les plus courantes. Elle remplace ou limite le besoin d'approbations par le CAB. Les personnes qui comprennent le mieux le code sont alors chargées d'identifier les problèmes qui s'y cachent. Selon ITIL 4 : « Dans les organisations à haute vélocité, il est courant de décentraliser l'approbation des changements, ce qui rend la revue par les pairs l'un des meilleurs indicateurs de haute performance. » De même, le rapport « State of DevOps » 2019 recommandait que « les organisations appliquent le principe du "shift left" (validation anticipée) pour garantir une approbation fondée sur la revue par les pairs pendant le processus de développement ».

Pour assurer la conformité à la réglementation, cette approche doit être méticuleusement documentée. C'est là que des systèmes tels que Bitbucket entrent en jeu, puisqu'ils garantissent un suivi automatique des auteurs et des revues par les pairs, et empêchent que les changements soient publiés sans respecter le processus requis.

Chez Atlassian, la revue par les pairs est un élément central de notre processus d'approbation. Comme l'explique l'un de nos experts en matière de risques informatiques et de conformité : « Tout le code Atlassian est stocké dans Bitbucket. Lorsqu'un développeur souhaite apporter un changement, il fait un check-out du code dans Bitbucket et sur son ordinateur portable. Lorsqu'il fait le check-in du code modifié dans le dépôt Bitbucket, au lieu de mettre à jour le code, le système est configuré pour exiger une revue par les pairs. Le code est uniquement ajouté au dépôt après la revue et l'approbation du changement. Et si le code n'est pas approuvé ? Il est renvoyé au développeur initial avec les notes du réviseur. Il corrige le problème et soumet le code qui fera l'objet d'une autre revue par les pairs. »

Réunissez les experts pour favoriser les bonnes pratiques

À mesure que les organisations se complexifient, il est de plus en plus essentiel de faciliter la circulation des informations et la coordination entre les équipes. Plutôt que d'approuver des demandes de changement individuelles, les CAB peuvent se concentrer sur l'amélioration de la pratique. Dans ce paradigme, ils peuvent chercher à fournir des recommandations d'amélioration de la pratique, à implémenter de meilleures capacités, et à fournir des ressources et des outils qui se traduisent par de meilleures performances. Le champ de compétence du CAB s'en voit élargi afin d'éviter que les changements ne soient trop lents et de s'assurer qu'ils procurent de la valeur aux clients.

Même au sein d'organisations informatiques plus traditionnelles, le CAB peut devenir un espace où sont mises au point des solutions créatives. Par exemple, une université prudente qui adhère aux pratiques et aux outils ITSM hérités se demandait comment informer les étudiants de l'indisponibilité d'un service important. Le CAB est devenu un forum pour réfléchir à de nouvelles tactiques de communication. Le résultat ? L'université a commencé à distribuer des bonbons et des affiches dans le cadre d'une campagne qui s'est avérée efficace pour rediriger les demandes entrantes concernant une mise à niveau planifiée du système.