Gestion des changements : approuver selon le niveau de risque

Opérations IT · 4 min

Traiter tous les changements de la même manière crée des files d'attente et des lots plus volumineux. Découvrez comment classer les changements par risque, préautoriser les changements répétitifs et produire des preuves sans dépendre d'une réunion hebdomadaire.

Gestion des changements : approuver selon le niveau de risque

TL;DR

Un circuit d'approbation unique peut créer des retards inutiles en traitant de la même manière des changements présentant des risques différents.
La recherche DORA sur le DevOps associe des processus d'approbation plus légers, la revue par les pairs et l'automatisation à de meilleurs résultats en matière de livraison logicielle.
Distinguer les changements standard, normaux et d'urgence permet de concentrer l'analyse humaine là où le risque est le plus élevé.
Les enregistrements d'approbation, de tests et de déploiement peuvent être générés par le flux de travail lui-même, dans le respect des exigences de contrôle et de séparation des tâches.
La transition exige un inventaire fiable, des tests, des mécanismes de retour arrière et une revue continue des résultats.

Le comité des changements est devenu un point d'attente

Dans de nombreuses organisations, toute modification de l'infrastructure ou des applications suit le même circuit : demande formelle, réunion hebdomadaire d'un comité d'approbation (CAB, Change Advisory Board) et fenêtre de déploiement définie. Ce modèle vise à protéger les systèmes en production, mais tous les changements ne présentent pas le même niveau de risque. Le renouvellement d'un certificat, une modification de configuration préalablement testée et la migration d'une base de données critique peuvent exiger des procédures d'évaluation et d'approbation différentes. Lorsque tous suivent le même circuit, les demandes s'accumulent, le temps d'attente augmente et des déploiements peuvent être regroupés en lots plus volumineux. Pour ceux qui gèrent les opérations IT, l'enjeu est d'adapter les contrôles à la criticité et à l'impact de chaque changement, sans compromettre la traçabilité.

Plus d'approbation formelle ne signifie pas moins d'échecs

Le programme de recherche DORA (DevOps Research and Assessment), à ne pas confondre avec le règlement européen sur la résilience opérationnelle numérique, a analysé cette relation dans le rapport State of DevOps de 2019. La recherche a identifié des effets négatifs des processus d'approbation externe lourds sur la performance de la livraison logicielle, sans démontrer qu'ils se traduisaient par un taux d'échec des changements plus faible. Comme alternative, elle recommande de rapprocher la revue des équipes qui exécutent le travail, en recourant à la revue par les pairs et à l'automatisation des tests, des vérifications et de la supervision. Ces conclusions ne signifient pas que les comités des changements soient superflus : ils restent utiles pour la coordination entre équipes, la communication et les décisions exigeant une évaluation de l'impact sur le métier. L'application de ces pratiques aux changements d'infrastructure doit tenir compte du risque et des exigences de contrôle de chaque organisation.

Classer les changements par risque avant de les approuver

Une approche courante consiste à distinguer trois types de changement. Les changements standard sont répétitifs, à faible risque et bien documentés, comme certaines configurations préalablement testées ; ils peuvent être préautorisés dès lors qu'ils suivent une procédure approuvée et sont enregistrés. Les changements normaux exigent une évaluation et une autorisation proportionnées au risque, idéalement par des personnes connaissant les systèmes et leurs dépendances. Les changements d'urgence suivent un circuit accéléré, avec les autorisations et la revue a posteriori prévues par la procédure applicable. Les critères de classification doivent être explicites et prendre en compte les services affectés, la facilité de retour arrière, l'exposition de données sensibles et l'historique des échecs. Une CMDB à jour aide à identifier les autres systèmes susceptibles d'être affectés par un changement apparemment isolé.

La preuve peut être générée par le processus lui-même

L'une des raisons de maintenir des processus d'approbation formels est la nécessité de démontrer le contrôle auprès des auditeurs, des clients ou des autorités de régulation. La recherche DORA indique que la revue par les pairs, appuyée par l'automatisation, peut contribuer à un processus de livraison fiable, sans dépendre exclusivement d'approbations externes. En pratique, chaque changement doit être associé à une demande, à l'identification du responsable, aux autorisations applicables, aux résultats des tests et à l'enregistrement du déploiement. Les plateformes de gestion des services, les outils d'automatisation et les mécanismes d'infrastructure as code peuvent produire une partie de ces preuves automatiquement, à condition que les enregistrements soient fiables et que les accès soient correctement contrôlés. Lorsqu'une partie de l'exploitation est confiée à des tiers, par exemple dans un contrat de gestion d'infrastructure, les changements exécutés par le prestataire doivent s'intégrer au processus de gestion des changements convenu avec le client. Les exigences concrètes en matière de preuve et de séparation des tâches doivent être validées au regard des obligations applicables.

Mesurer l'attente et le résultat de chaque changement

La recherche DORA recommande d'analyser la proportion de changements nécessitant une approbation manuelle avant la mise en production, en les distinguant par profil de risque, ainsi que le temps d'attente associé aux approbations externes. Ces indicateurs doivent être analysés conjointement avec la fréquence des changements à l'origine d'incidents, le besoin de retours arrière et le temps de rétablissement. Si les changements à faible risque attendent plusieurs jours pour être approuvés, sans que le processus n'apporte une valeur proportionnelle, il peut exister une marge de simplification. À l'inverse, si une catégorie présente des échecs fréquents, la réponse peut consister à renforcer les tests, à améliorer les procédures de déploiement ou à revoir les mécanismes de retour arrière, plutôt qu'à ajouter automatiquement un niveau d'approbation supplémentaire. Une bonne observabilité des services permet de détecter rapidement les dégradations après un changement et d'appuyer les décisions de retour arrière sur des données.

Un processus proportionné exige discipline et revue continue

Approuver les changements selon le niveau de risque peut contribuer à réduire les temps d'attente, à éviter les déploiements regroupés en lots plus volumineux et à concentrer l'attention humaine sur les décisions à plus fort impact. La transition dépend toutefois de conditions que toutes les organisations ne réunissent pas d'emblée : inventaire fiable, procédures documentées, tests adéquats, mécanismes de retour arrière et enregistrements cohérents. Sans ces fondations, la préautorisation des changements peut simplement transférer le risque vers l'exploitation. Une évolution progressive, en commençant par les changements les plus répétitifs et en revoyant périodiquement leur classification sur la base des résultats, tend à être plus prudente qu'une refonte complète du processus en une seule fois. L'équilibre entre agilité, sécurité et contrôle doit être évalué au cas par cas, en fonction de la criticité des services, des responsabilités contractuelles et des obligations applicables.