Approbation basée sur le risque : quand un changement a-t-il vraiment besoin d'approbation ?

Imaginez deux changements qui arrivent le même jour. L'un modifie la couleur d'un bouton sur un tableau de bord interne. L'autre modifie le schéma de base de données derrière le processus de paiement. Si les deux changements doivent passer par le même processus d'approbation — une réunion CAB, une signature du manager, ou une longue file d'attente — l'équipe perdra rapidement patience. Les petits changements sont retardés, tandis que les changements risqués ne reçoivent pas nécessairement une meilleure attention.

Cela arrive dans de nombreuses organisations d'ingénierie. Un processus d'approbation unique pour chaque changement devient souvent de la bureaucratie plutôt qu'une protection. Les gens attendent, le contexte devient obsolète, et l'effet secondaire le plus dangereux apparaît silencieusement : les équipes cessent de réfléchir clairement au risque de chaque changement.

Le problème d'approuver chaque changement

Quand chaque changement nécessite la même approbation, les équipes peuvent perdre leur sentiment de responsabilité. Un développeur peut penser : "Quelqu'un d'autre vérifiera cela plus tard." Mais la personne la plus proche du changement le comprend généralement le mieux. Si l'approbation devient le seul mécanisme de contrôle qualité, l'équipe devient moins prudente, pas plus prudente.

Trop d'approbation crée l'illusion de la sécurité. Les relecteurs sont obligés d'inspecter trop de changements en trop peu de temps. Les changements à haut risque peuvent recevoir une revue superficielle, tandis que les changements à faible risque attendent dans la même file. Le processus semble contrôlé, mais le risque réel n'est pas bien géré.

Le principe de l'approbation basée sur le risque

L'approbation basée sur le risque repose sur un principe simple : plus le risque est élevé, plus le chemin d'approbation doit être solide. Les changements à faible risque peuvent avancer rapidement. Les changements à haut risque doivent être examinés par des personnes qui comprennent l'impact potentiel.

De nombreuses équipes le font déjà de manière informelle. Le problème est que sans un cadre clair, la frontière entre "nécessite une approbation" et "ne nécessite pas d'approbation" devient floue. Les décisions dépendent de qui a demandé le changement, qui est de service, ou à quel point l'organisation se sent nerveuse cette semaine-là. Un meilleur modèle lie le chemin d'approbation au risque réel du changement.

Définir des seuils d'approbation

Un seuil d'approbation est la ligne qui décide si un changement peut se dérouler automatiquement ou doit attendre une approbation humaine. Cette ligne doit être explicite, cohérente et liée à des caractéristiques observables du changement.

Les critères utiles incluent :

Le diagramme suivant illustre comment un changement peut être évalué selon ces critères et orienté vers le chemin d'approbation approprié.

L'extrait GitLab CI suivant montre comment un pipeline peut détecter automatiquement le risque et exiger conditionnellement une approbation manuelle :

stages:
  - test
  - deploy
  - approval
  - production

risk-check:
  stage: test
  script:
    - if git diff --name-only $CI_MERGE_REQUEST_DIFF_BASE_SHA...$CI_SHA | grep -E "^(migrations/|payment/)"; then
    -   echo "HIGH_RISK=true" >> risk.env
    - else
    -   echo "HIGH_RISK=false" >> risk.env
    - fi
  artifacts:
    reports:
      dotenv: risk.env

approval-job:
  stage: approval
  needs: [risk-check]
  rules:
    - if: $HIGH_RISK == "true"
      when: manual
      allow_failure: false
  script:
    - echo "Le changement nécessite une approbation manuelle avant le déploiement en production"

deploy-production:
  stage: production
  needs: [approval-job]
  script:
    - echo "Déploiement en production"
flowchart TD A[Changement soumis] --> B{Évaluation du risque} B -->|Faible risque| C[Changement standard] C --> D[Aucune approbation formelle] D --> E[Déployer] B -->|Risque moyen| F[Changement normal] F --> G[Revue par les pairs] G --> H{Approuvé ?} H -->|Oui| E H -->|Non| I[Réviser et soumettre à nouveau] I --> A B -->|Haut risque| J[Changement d'urgence] J --> K[Approbation rapide] K --> L{Approuvé ?} L -->|Oui| E L -->|Non| I
  • Le changement touche-t-il des données utilisateur ?
  • Modifie-t-il un schéma de base de données ou un chemin de migration ?
  • Pourrait-il affecter la disponibilité du service ?
  • Implique-t-il des flux de paiement, d'authentification, de sécurité ou d'autres flux critiques ?
  • Modifie-t-il une infrastructure dont dépendent de nombreux systèmes ?
  • Affecte-t-il un composant ayant un historique de comportement fragile ?

Les meilleurs seuils peuvent être détectés automatiquement. Un pipeline peut voir qu'une pull request contient des fichiers de migration de base de données, des modifications Terraform, une configuration de signature mobile ou des changements de politique de secrets de production. Il peut alors orienter le déploiement vers le bon chemin d'approbation sans se fier à des suppositions.

Trois catégories pratiques de changements

De nombreuses équipes peuvent commencer avec trois catégories.

Les changements standard sont à faible risque et répétables. Les exemples incluent les mises à jour de contenu, les modifications de configuration bien testées, ou les déploiements qui suivent un modèle sûr connu. Ces changements doivent avancer sans approbation formelle. L'équipe reste responsable de la qualité.

Les changements normaux comportent un risque modéré. Ils peuvent nécessiter une revue par une ou deux personnes qui comprennent le domaine concerné. Cela peut généralement se faire de manière asynchrone. Une réunion formelle est rarement nécessaire.

Les changements d'urgence sont effectués pour résoudre un incident ou prévenir des dommages immédiats. Ils nécessitent un chemin rapide avec un minimum de friction, suivi d'une documentation après coup. L'objectif n'est pas de ralentir la récupération. L'objectif est de s'assurer que l'organisation sait ce qui a été changé, pourquoi cela a été changé, et ce qui doit être amélioré après l'incident.

Ce que cela change dans le comportement de l'équipe

Lorsque l'approbation est réservée aux risques significatifs, les équipes deviennent plus attentives. Elles savent que les petits changements sont de leur responsabilité. Elles savent aussi que les grands changements recevront une attention supplémentaire de la part de personnes qui peuvent aider à repérer les angles morts.

Cela favorise une culture de responsabilité plutôt qu'une culture de délégation. Les développeurs ne peuvent pas se cacher derrière l'approbation. Les relecteurs ne sont pas submergés par des demandes triviales. L'organisation consacre son attention là où l'attention compte vraiment.

Une liste de contrôle pratique

  • Identifiez les composants critiques tels que les bases de données, les flux de paiement, l'authentification, l'état de l'infrastructure et les services partagés.
  • Définissez des seuils objectifs pour chaque catégorie de risque.
  • Documentez le chemin d'approbation qui s'applique aux changements standard, normaux et d'urgence.
  • Faites en sorte que le pipeline détecte les indicateurs de risque lorsque c'est possible.
  • Enregistrez les approbations et les preuves dans le cadre de l'enregistrement de déploiement.
  • Révisez les seuils périodiquement, car le risque change à mesure que le système et l'équipe évoluent.

Une gouvernance qui aide la livraison à avancer

Avec l'approbation basée sur le risque, la gouvernance devient une aide à la livraison plutôt qu'un blocage. Elle offre aux changements à faible risque un chemin rapide et aux changements à haut risque l'attention qu'ils méritent.

Le but n'est pas d'approuver tout. Le but est d'approuver les bonnes choses. Un système CI/CD sain doit distinguer le mouvement de routine du véritable danger. Lorsque cette distinction est claire, les équipes peuvent avancer plus vite sans faire semblant que chaque changement est également sûr.

Point clé à retenir : Commencez par identifier les changements qui sont vraiment à haut risque dans votre environnement. Donnez aux changements de routine un chemin rapide. Donnez aux changements risqués une revue plus solide. Une approbation efficace ne consiste pas à contrôler chaque mouvement. Il s'agit de s'assurer que les changements qui peuvent causer des dégâts réels reçoivent l'attention appropriée avant d'atteindre la production.