Quand l'approbation manuelle reste pertinente dans votre pipeline de déploiement

Votre pipeline est vert. Tous les contrôles automatisés sont passés. La compilation s'est déroulée sans erreur, les tests unitaires ont réussi, les scans de sécurité n'ont trouvé aucune vulnérabilité critique, et les tests d'intégration ont confirmé que l'API répond toujours correctement. Le pipeline est prêt à déployer en production.

Mais quelque chose cloche. Cette modification réécrit le module de paiement. Les tests automatisés vérifient que le code fonctionne, mais ils ne peuvent pas vous dire si le nouveau flux de paiement correspond à ce que l'équipe métier a convenu avec la banque. Le pipeline sait que la syntaxe est correcte. Il ne sait pas si la logique est juste.

C'est le moment où l'automatisation atteint ses limites.

Ce que les portes automatisées ne peuvent pas voir

Les portes automatisées excellent pour détecter les problèmes mécaniques. Elles détectent les erreurs de compilation, les échecs de tests, les mauvaises configurations de sécurité et les erreurs de syntaxe. Elles exécutent les mêmes vérifications à chaque fois, de manière cohérente et sans fatigue.

Mais les machines ne peuvent pas évaluer l'impact métier. Un pipeline peut détecter qu'un code a changé, mais il ne peut pas juger si ce changement altère un flux métier critique. Un pipeline peut valider qu'un script de migration de base de données a une syntaxe correcte, mais il ne peut pas prédire si cette migration va verrouiller une grande table en production et provoquer une indisponibilité. Un pipeline peut confirmer qu'un fichier de configuration serveur est un JSON valide, mais il ne peut pas savoir si cette configuration casse une dépendance pour un autre service.

Ce sont des situations où le jugement humain devient nécessaire. La question n'est pas de savoir s'il faut tout automatiser. La question est de savoir quels changements nécessitent qu'un humain les examine avant qu'ils n'atteignent les utilisateurs.

Quatre situations qui nécessitent une approbation manuelle

Modifications importantes du code applicatif

La taille d'un changement ne se mesure pas en lignes de code. Un changement d'une ligne qui active un feature flag peut être à faible risque. Un changement qui réécrit un module central peut être à haut risque même s'il ne touche que quelques fichiers.

L'approbation manuelle est importante lorsque le changement affecte un flux métier critique. Réécrire le module de paiement, modifier la façon dont l'application gère les sessions utilisateur, ou remplacer une bibliothèque centrale dont dépendent de nombreuses parties de l'application — ces changements comportent un risque que les tests automatisés ne peuvent pas évaluer complètement. Les tests peuvent vérifier que le nouveau code ne plante pas, mais ils ne peuvent pas confirmer que la nouvelle logique métier correspond à ce que l'équipe a convenu avec les parties prenantes.

Quelqu'un qui comprend le contexte métier doit examiner le changement et dire : "Cela correspond à ce que nous avions prévu."

Modifications de base de données

Les modifications de base de données sont l'une des sources les plus courantes d'incidents de production. Les changements de schéma, les nouveaux index et les migrations de données ont tous des effets secondaires difficiles à détecter automatiquement.

L'extrait de workflow GitHub Actions suivant montre comment exiger une approbation manuelle pour les modifications de migration de base de données :

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    # Exiger une approbation manuelle pour les modifications sous migrations/
    if: contains(github.event.head_commit.modified, 'migrations/')
    steps:
      - uses: actions/checkout@v4
      - name: Run database migration
        run: |
          echo "Applying migration..."
          # Le script de migration va ici

Dans cet exemple, le paramètre environment: production déclenche une étape d'approbation manuelle dans GitHub Actions. Le pipeline se met en pause jusqu'à ce qu'un réviseur désigné approuve le déploiement, garantissant qu'un humain évalue la migration avant qu'elle n'atteigne la production.

Une migration qui ajoute une colonne à une grande table peut verrouiller cette table pendant plusieurs minutes, ce qui empêche l'application de répondre. Un pipeline peut vérifier si la syntaxe de la migration est valide, mais il ne peut pas évaluer si la migration peut être exécutée en toute sécurité sur le volume de données en production. Une requête qui fonctionne parfaitement sur une base de développement avec mille lignes peut avoir des performances désastreuses sur une base de production avec des millions de lignes.

Les équipes de base de données ou les développeurs seniors doivent examiner le plan de migration, estimer son impact et approuver qu'il peut être exécuté en toute sécurité. Il ne s'agit pas de faire du gatekeeping. Il s'agit d'éviter un verrouillage de table de cinq minutes qui mettrait toute l'application hors service.

Modifications d'infrastructure

Les modifications d'infrastructure ont souvent des répercussions difficiles à prévoir. Changer les règles de pare-feu réseau, changer de type d'instance, mettre à jour des versions Kubernetes ou modifier des configurations d'équilibreur de charge peut affecter des services dont vous ignoriez qu'ils dépendaient de cette infrastructure.

Un exemple classique : modifier une règle de pare-feu qui bloque accidentellement le trafic d'un service d'une autre équipe. Ou modifier une configuration d'équilibreur de charge qui fait que les requêtes sont routées vers le mauvais backend. Le pipeline peut valider que le fichier de configuration est syntaxiquement correct, mais il ne peut pas savoir si cette configuration correspond à l'architecture réelle en production.

Les équipes d'infrastructure doivent examiner le changement, vérifier les dépendances et confirmer qu'il peut être appliqué en toute sécurité.

Tout changement en production

La production est l'endroit où les utilisateurs réels interagissent avec votre application. Chaque changement y comporte un risque direct. Même les changements qui semblent mineurs — mettre à jour un message d'erreur, ajuster une taille de police ou changer un niveau de log — peuvent avoir des effets secondaires inattendus.

De nombreuses équipes adoptent une règle simple : aucun changement ne va en production sans approbation manuelle, quel que soit le type de changement. Cette règle supprime toute ambiguïté. Elle oblige quelqu'un à examiner chaque changement en production et à en assumer la responsabilité.

Comment décider ce qui nécessite une approbation

Tous les changements n'ont pas besoin d'être examinés par un humain. Corriger une faute de frappe dans une page de documentation ou ajouter une nouvelle instruction de log est généralement sûr à laisser passer via les portes automatisées. Mais les changements qui modifient les schémas de base de données, altèrent les configurations de production ou affectent les flux métier principaux doivent nécessiter une approbation manuelle.

Le modèle courant consiste à classer les changements par niveau de risque :

Le diagramme suivant résume le processus de décision :

• Changements à faible risque : Corrections de bugs pour des fonctionnalités non critiques, mises à jour de documentation, ajout de monitoring, ou modification de valeurs de configuration non fonctionnelles. Ceux-ci peuvent passer par les portes automatisées sans examen manuel.

• Changements à haut risque : Modifications de schéma de base de données, modifications de configuration de production, changements dans la logique métier critique, mises à jour de bibliothèque avec des changements cassants, ou tout changement affectant le comportement utilisateur dans un flux critique. Ceux-ci nécessitent une approbation manuelle.

Votre équipe peut définir la limite en fonction du contexte de votre application et de l'expérience passée. L'important est d'avoir une classification claire pour que tout le monde sache ce qui nécessite une approbation et ce qui n'en nécessite pas.

Une checklist pratique pour mettre en place l'approbation manuelle

• Définissez ce qui est considéré comme à haut risque dans le contexte de votre application. Commencez par les changements qui ont déjà causé des incidents.
• Classez automatiquement les changements lorsque c'est possible. Utilisez les messages de commit, les chemins de fichiers ou les noms de branches pour signaler les changements à haut risque pour un examen manuel.
• Assignez les approbateurs en fonction de l'expertise. Les changements de base de données vont à l'équipe DBA. Les changements d'infrastructure vont à l'équipe plateforme. Les changements de logique métier vont à un développeur senior qui maîtrise le domaine.
• Fixez un délai raisonnable. L'approbation manuelle ne devrait pas prendre des jours. Définissez un temps de réponse maximal pour les approbateurs, et ayez un chemin d'escalade si personne ne répond.
• Enregistrez chaque décision d'approbation. Notez qui a approuvé quoi, quand et pourquoi. Cela devient précieux lorsque vous devez retracer une décision après un incident.

Le véritable objectif de l'approbation manuelle

L'approbation manuelle ne vise pas à ralentir la livraison. Il s'agit de s'assurer que les changements à haut risque reçoivent l'attention qu'ils méritent avant d'atteindre les utilisateurs. L'automatisation gère les vérifications de routine. Les humains gèrent les décisions de jugement que les machines ne peuvent pas prendre.

L'objectif n'est pas d'éliminer l'approbation manuelle. L'objectif est de la réserver aux changements qui en ont vraiment besoin, afin que votre équipe puisse avancer rapidement sur tout le reste tout en restant en sécurité sur ce qui compte le plus.