Pourquoi il est temps d'abandonner votre Change Advisory Board

Le Change Advisory Board (CAB) est une composante significative du Change Management dans les départements IT. Sa promesse ? Minimiser les risques, accélérer la résolution des incidents et améliorer la communication et la collaboration. Mais dans la pratique, le CAB ralentit significativement le Time-to-Market et est coûteux en termes de mobilisation d’équipes et de ressources financières. Il peut également générer un faux sentiment de sécurité et faire baisser la qualité de la Delivery. 15 ans d’expérience en Devops m’ont enseigné une chose : il est temps d’abandonner votre CAB en faveur de l'automatisation.

‍

Ces dernières décennies ont été le témoin de profonds changements dans la manière de concevoir et de gérer des applications. Les deux plus significatifs étant probablement la généralisation des approches Agile et Devops. Au carrefour de ces deux transformations majeures se trouve la Gestion des changements (Change Management), où comment s’assurer que les évolutions attendues par le métier se retrouvent effectivement en production, de façon sécurisée et sans impact pour les utilisateurs.

Un des aspects les plus visibles de la gestion des changements est le CAB, pour Change Advisory Board. Chez Alenia nous travaillons avec de nombreux acteurs, dont les principales banques d’investissement. Dans ces structures, les DSI sont constituées de milliers de personnes, réparties sur les principales places financières (NY,Londres, Paris, Hong-Kong…) et ont la charge de centaines d’applications critiques. Comme dans de nombreuses grandes entreprises, la culture du CAB y est encore très présente. Il m’est arrivé d’observer jusqu’à 4 instances de CAB pour une même demande de changement avant que celle-ci ne soit autorisée à un passage en production :

• Le CAB de la tribu situé à Paris, car le responsable de la production de celle-ci veut s’assurer que tout est bien réalisé afin de « gagner du temps »
• Le CAB de la région, par exemple pour une livraison par les équipes de New-York dans une banque dans le siège est à Paris
• Un CAB ad-hoc, car l’application fait partie d’un business process sensible qui a connu plusieurs incidents majeurs dans le passé
• Le CAB global de la DSI

Chacun de ces meetings ayant lieu souvent de façon hebdomadaire, pour une durée minimum d’une heure et pouvant réunir un nombre conséquent de participants (le métier et leurs représentants, développeurs, business analysts, chefs de projets, testeurs, intégrateurs, supports applicatifs, métiers de l’infrastructure, change managers, release managers, managers…)

Rappelons que les instances du CAB ne sont que la partie émergée de l’iceberg, et que cela peut représenter une heure de travail en amont, parfois plus, pour la rédaction et le workflow de validation pour chaque demande de changement. A cela s’ajoute la préparation du CAB et la validation de chacune de ces demandes, souvent plusieurs centaines par semaine.

‍

Pourquoi les CAB sont-ils aussi répandus ?

On comprend assez vite que le processus pour mettre à disposition des utilisateurs une nouvelle fonctionnalité ne va pas être des plus simples, mais surtout que cela va prendre du temps ! Alors pourquoi la plupart des entreprises ont choisi de mettre en place un CAB ?

Une fois passé les biais comportementaux humains, à ne surtout pas sous-estimer, comme « on a toujours fait comme cela » ou« si on n’a pas un CAB on n’a pas une gestion sérieuse des changements » ou encore une culture d’entreprise qui génère plus de défiance que de confiance, on retrouve principalement les raisons suivantes :

1.    Minimiser les risques liés aux changements entraînant des perturbations ou des pannes

2.    Accélérer la résolution des incidents avec une traçabilité claire afin d’identifier rapidement les changements à l’origine de la perturbation

3.    S’assurer que les changements sont revus correctement et approuvés afin de se conformer avec les demandes des régulateurs ou de l’audit interne

4.    Améliorer la communication et la collaboration entre les différentes équipes de l’organisation

‍

En réalité, qu’observe-t-on ?

Le CAB va surtout permettre de vérifier que chaque acteur a correctement rempli la demande de changement. Vu le volume, la diversité et la complexité des changements à traiter, personne ne pourra s’assurer que les actions ont été réellement et correctement effectuées ou même s’assurer que tel changement aura un impact sur tel autre. Pire, l’instance de CAB de par son positionnement, manque souvent d’autorité pour réellement empêcher un changement. Tout cela confère un faux sentiment de sécurité, de dilution de la responsabilité, où chacun se dit que ce qu’il fait est validé par un autre ce qui contribue à une moindre qualité.

Sur l’aspect de la traçabilité c’est souvent très perfectible. La lenteur du processus fait que les équipes à qui on demande de mettre en production, généralement sous la pression du métier ou du management, préfèreront ne pas tracker ou passer abusivement par des changements en urgence.

Enfin à propos de la communication entre les équipes, de tels problèmes sont tellement profonds que généralement le CAB va devenir un champ de bataille, ce qui avouons-le n’est pas le lieu idéal pour la collaboration.

Les objectifs du CAB sont donc au mieux très partiellement atteints, et sont en réalité très coûteux :

• Un ralentissement énorme du Time to Market, de quelques jours à plusieurs semaines, qui entraîne des conséquences sur le métier, mais également sur la motivation des employés.
• Le nombre de personnes mobilisé avant et pendant le CAB représente un coût financier important‍
• Même si les études scientifiques sérieuses sur le sujet sont trop peu nombreuses, les recherches qui ont conduit à la rédaction de Accelerate, rédigé par des auteurs de références dans le domaine, démontrent une corrélation négative entre la qualité des livraisons et l’existence d’un CAB. Cette corrélation subsiste même quand le CAB n’a lieu que pour les changements à hauts risques. Pire encore, les équipes sans CAB ont une qualité de livraison supérieure.

Enfin, la première réaction à un incident majeur va être généralement d’alourdir les critères de contrôle du CAB, voire de rajouter une instance, ce qui va accentuer ce cercle vicieux.

‍

Dans ce cas, pourquoi continuer?

Ce constat est souvent partagé par les différents acteurs de la Gestion des changements, mais il est encore trop rare de voir des CAB disparaitre. Je pense que la raison principale est qu’abandonner le CAB peut être perçu comme une prise de risque inconsidérée et un signal envoyé comme quoi chacun peut faire ce qu’il veut car la police ne sera plus là.

En réalité, la meilleure des réponses pour allier rapidité et qualité ne peut être que l’automatisation :

• Tout d’abord investir sur la qualité logicielle plutôt que sur les procédures. Répandre l’usage du BDD ,TDD, pair programming, pilotage de la couverture de code, rédaction de tests d’acceptances…
• Construire un pipeline CI/CD robuste, intégralement automatisé, qui s’assure que les tests sont joués systématiquement au plus tôt dans le cycle de développement (shift left) et qui ne permet la livraison qu’avec un haut niveau de confiance.
• Ce même pipeline a la charge de la création des demandes de changements dans l’outil ITSM et de la génération des documents obligatoires afin de satisfaire les demandes des régulateurs et de l’audit. Cette automatisation aura aussi pour conséquence directe d’améliorer la data quality et donc la résolution des incidents liés aux livraisons.
• Quant à la collaboration entre les équipes, la mise en place de concepts liés à l’Agilité ou du Lean management est souvent le plus efficace. La construction du pipeline et son amélioration continue par les équipes de développements et de production sont souvent de parfaits exercices pour se parler et se comprendre.

Peut-on vraiment se passer de CAB ?

Après plus de 15 ans dans le milieu professionnel autour des problématiques de livraison, je pense que la seule bonne raison de conserver unCAB est de le faire uniquement quand on a une stratégie claire pour en sortir. Voici 3 exemples parmi les plus courants :

1. ‍J’ai un CAB principalement« infra ». Dans ce cas je travaille avec mes équipes IT pour faire en sorte que mes applications soient résilientes à la panne, à l’extrême cela peut mener à la mise en place de Chaos Monkey. Ainsi l’adhérence entre infra et applicatif se réduit au minimum, voir disparait complètement ce qui rend le CAB inutile.
2. J’ai un CAB pour quelques applications problématiques, très transverses, monolithiques et souvent vendor. Dans ce cas la solution sera plutôt de mettre en place une procédure de go/no go propre à ces applications, le temps de travailler sur la mise en place de déploiement sans interruption de service et de rendre l’application plus modulaire.
3. Mes équipes ne sont pas matures, cela va être la catastrophe si j’arrête le CAB. Il est préférable de mettre en place des indicateurs pour définir précisément la maturité suffisante que j’attends pour autoriser des livraisons hors CAB. Cela peut passer par la mise en place d’Error Budget Policy basé sur des business SLA, ou encore repasser en mode CAB lorsque l’application a eu plus de X incidents de mise en production au cours du mois écoulé.

Au final, que retenir ? La gestion des changements et une structure pour la piloter sont indispensables aujourd’hui. Mais penser que le CAB est nécessaire au bon fonctionnement de l’entreprise est clairement une erreur au regard de son efficacité très relative et de son coût. La qualité du processus de mise en production vient avant tout de l’automatisation. Automatisation qui doit être appuyée sur une usine de tests qui assure avec un haut niveau de fiabilité que ce qui part en production ne provoquera pas de régression ou de comportement inattendu. A cela s’ajoutent tous les leviers de la résilience, afin de limiter la panne, ou de s’assurer de pouvoir relivrer rapidement si nécessaire.

Si ce sujet vous intéresse et que vous souhaitez prolonger la discussion, n’hésitez pas à me contacter !