Thomas a 47 ans et préside le Change Advisory Board depuis six ans. Chaque mercredi à 14h, il ouvre le même fichier Excel, et la réunion commence. Le fichier fait parfois 80 lignes, parfois 120. Pendant ce temps, l’équipe DevOps attend. Les déploiements aussi. Parfois jusqu’au jeudi. Thomas sait que le processus est lent. Tout le monde le sait. Et pourtant, le CAB résiste. Semaine après semaine, avec la régularité d’un rituel.

Le CAB : bien plus qu’un processus technique

Dans un monde où les équipes déploient plusieurs fois par jour, le CAB traditionnel, cette réunion hebdomadaire où l’on valide ligne par ligne un tableau de changements, est devenu un goulot d’étranglement. Il ralentit l’innovation sans garantir proportionnellement la sécurité des systèmes.

Tout le monde le sait. Alors pourquoi persiste-t-il ?

La sociologie des organisations offre une réponse qui dérange : le CAB n’est pas qu’un processus. C’est un rituel de contrôle qui remplit des fonctions bien réelles et souvent invisibles. Il donne une légitimité formelle à la gouvernance IT : « nous avons un processus rigoureux » qui rassure les auditeurs, les directions, les clients. Il offre aussi une déresponsabilisation douce : si le changement a été approuvé en CAB, la responsabilité se dilue dans le collectif. Et surtout, c’est là que le contexte devient politique, participer au CAB, c’est avoir un droit de regard sur les décisions techniques. Une zone de pouvoir que l’automatisation, par définition, menace de faire disparaître.

La résistance à l’automatisation du Change Management n’est donc pas qu’une question d’habitude organisationnelle. C’est, très souvent, une résistance à la perte de contrôle.

L’angoisse sous-jacente : qui décide quand la machine décide ?

Il y a une question que les équipes n’osent pas toujours formuler clairement : si l’automatisation approuve un changement qui provoque une panne majeure, qui est responsable ?

Quand un humain (le CAB, un architecte) prend cette décision et qu’elle échoue, on nomme l’erreur. On l’analyse. On l’attribue. La chaîne de responsabilité reste lisible. Quand un algorithme prend cette décision, la zone grise s’installe : est-ce le développeur qui a configuré les règles ? L’architecte qui a défini les critères de risque ? Le responsable IT qui a validé l’outil ?

Cette incertitude génère une anxiété décisionnelle bien réelle, un mécanisme qui est central dans les résistances organisationnelles. Elle explique pourquoi, même face à l’évidence de l’inefficacité du CAB, des organisations continuent de s’y accrocher. Le rituel, aussi imparfait soit-il, offre ce que l’automatisation ne donne pas spontanément : une lisibilité des responsabilités.

Ce que ITIL 4 et JSM changent concrètement

ITIL 4 a introduit une distinction structurante : le Standard Change préapprouvé. Un changement est qualifié de « standard » lorsqu’il est suffisamment bien connu, documenté et maîtrisé pour ne pas nécessiter d’approbation individuelle à chaque occurrence. Les conditions de son exécution sont définies à l’avance, et c’est leur respect qui déclenche l’approbation, pas une réunion.

Concrètement, dans l’écosystème Atlassian, cela se traduit par une intégration entre le pipeline CI/CD (GitLab, Jenkins, Bitbucket) et Jira Service Management. Le workflow devient : déploiement demandé → tests automatisés verts ✅ → niveau de risque calculé comme faible ✅ → JSM approuve, crée le ticket de changement, le ferme. L’audit reste complet. C’est la nature de la décision humaine qui change. On passe d’un contrôle a priori, valider chaque occurrence, à une confiance dans le processus, avec vérification continue.

C’est ce glissement qui est réellement impactant. Et c’est aussi ce glissement qui demande un travail culturel que l’outil seul ne fait pas.

Ce que l’automatisation ne résout pas

Soyons précis sur les limites. L’automatisation ne résout pas la définition des critères de risque, cette décision reste profondément humaine et politique. Elle ne résout pas les erreurs de configuration : si les règles sont mal conçues, on automatise de mauvaises décisions, plus vite. Et elle ne résout pas le besoin de sens des équipes : une règle opaque (« l’algorithme a refusé » sans explication) génère de la frustration et, à terme, des contournements silencieux.

L’ergonomie du travail formule cela avec précision : une automatisation réussie ne remplace pas l’intelligence humaine, elle la libère pour se concentrer là où elle est irremplaçable : les cas complexes, les changements d’architecture, les situations inédites.

Vers un Change Management proportionné

La recommandation n’est pas de supprimer le CAB. C’est de le réserver aux situations qui le méritent vraiment. Un modèle proportionné distingue trois niveaux :

• les Standard Changes (80 % des cas, déploiements applicatifs maîtrisés), entièrement automatisés via JSM ;
• les Normal Changes (15 % — modifications d’infrastructure à impact moyen), avec une approbation allégée impliquant une à deux personnes ;
• les Major ou Emergency Changes (5 %), qui nécessitent une délibération collective réelle, pas une revue de tableur.

Pour que ce modèle fonctionne, trois conditions sont non négociables.

• La transparence des critères d’abord : les règles qui qualifient un Standard Change doivent être explicites, documentées, accessibles. Pas une boîte noire ;
• La traçabilité complète ensuite : chaque changement automatisé crée un ticket JSM avec son contexte, ses résultats, son auteur;
• Et enfin, la boucle d’amélioration continue : chaque incident lié à un Standard Change doit déclencher une révision des critères, c’est ainsi que l’automatisation gagne en maturité et en légitimité.

Thomas, lui, continue de présider son CAB. Mais depuis quelques mois, la réunion du mercredi ne dure plus qu’une demi-heure. Les lignes Excel ont fondu de 80 à 7. Les sept changements restants méritent vraiment d’être discutés. Le reste tourne seul, et tout le monde sait pourquoi.

La vraie question n’est pas technique. Elle est culturelle : votre organisation est-elle prête à faire confiance à ses processus pour décider, et à réserver l’intelligence humaine là où elle compte vraiment ? 🤔