Quand votre pipeline doit-il attendre un humain ?

Imaginez la scène : votre pipeline CI/CD vient de builder et tester une nouvelle fonctionnalité. Tous les tests sont verts. L'analyse de sécurité n'a rien trouvé de suspect. L'environnement de staging exécute la nouvelle version sans le moindre problème. Le pipeline veut maintenant pousser cette même version en production. Doit-il y aller directement, ou doit-il s'arrêter et attendre qu'un humain donne son feu vert ?

Cette question se pose dans toutes les équipes qui construisent un pipeline de déploiement avec plusieurs environnements. La réponse n'est pas un simple oui ou non. Elle dépend de votre niveau de confiance dans chaque environnement et du risque que vous êtes prêt à accepter.

Pourquoi laisser le pipeline s'exécuter automatiquement

Dans les environnements précoces comme le développement, la plupart des équipes laissent le pipeline promouvoir les changements automatiquement. Le build réussit, les tests passent, les scans de sécurité sont propres — et le pipeline déploie immédiatement cette version dans l'environnement suivant. Personne n'a besoin de cliquer sur un bouton. C'est ce qu'on appelle la promotion automatique.

La promotion automatique est rapide. Les développeurs n'ont pas à attendre qu'un responsable approuve un déploiement en staging à chaque fois qu'ils poussent une petite correction. Le pipeline peut traiter des dizaines de changements par jour sans que l'équipe ne devienne un goulot d'étranglement. Pour les environnements de début de cycle où les erreurs sont peu coûteuses, cette rapidité est précieuse.

Mais la promotion automatique n'est pas adaptée à toutes les situations. Plus un changement se rapproche de la production, plus l'impact est grand en cas de problème. À un moment donné, l'équipe peut vouloir marquer une pause, examiner les résultats des tests en staging, puis décider si le changement doit continuer.

Quand faire intervenir un humain

La promotion manuelle signifie que le pipeline s'arrête à une frontière d'environnement spécifique et attend qu'une personne autorise la poursuite. Cela se produit généralement avant la production, ou avant un environnement auquel des utilisateurs réels accèdent. Le pipeline a déjà fait toute la préparation — la nouvelle version est buildée, testée en staging, et vérifiée par la sécurité — mais elle n'ira pas en production tant que quelqu'un ne l'aura pas approuvée.

Les équipes décident généralement d'utiliser la promotion manuelle en fonction de deux facteurs : le caractère critique de l'environnement cible et l'ampleur du changement.

Pour les environnements de production, de nombreuses équipes utilisent la promotion manuelle comme filet de sécurité final. Toutes les barrières automatisées ont été franchies. Le staging fonctionne normalement. Mais l'équipe veut quand même qu'une personne vérifie consciemment avant que le changement n'atteigne les utilisateurs. La personne qui donne l'approbation est généralement un ingénieur senior, un lead technique, ou quelqu'un qui comprend l'impact complet du changement sur le système.

Pour les changements importants — migrations de base de données, modifications d'architecture, ou mises à jour majeures de bibliothèques — la promotion manuelle est souvent utilisée même pour les environnements de staging. L'équipe veut s'assurer que quelqu'un est attentif avant que le changement ne passe à l'étape suivante.

Le schéma courant : automatique tôt, manuel tard

L'approche la plus courante est une combinaison : promotion automatique pour les environnements précoces, promotion manuelle pour le dernier. Le pipeline se promeut tout seul du développement au staging, puis s'arrête à la porte de la production en attendant une approbation. Ou bien le pipeline promeut automatiquement en staging, l'équipe QA vérifie manuellement, puis donne son feu vert pour la production.

Le diagramme suivant illustre ce schéma courant avec un point de décision pour les changements à haut risque :

Certaines équipes appliquent une promotion manuelle à plusieurs niveaux. Par exemple, le passage en staging nécessite l'approbation d'un développeur senior, tandis que le passage en production nécessite l'approbation à la fois du lead technique et de l'équipe QA. Plus l'environnement est élevé, plus le nombre de personnes devant donner leur accord est important.

Ce que la promotion manuelle n'est pas

La promotion manuelle ne remplace pas les barrières automatisées. Les barrières automatisées s'exécutent toujours dans chaque environnement. Le pipeline vérifie toujours les builds, les tests et la sécurité avant de s'arrêter pour attendre une approbation. La promotion manuelle ajoute une couche de décision humaine par-dessus les vérifications automatisées. Elle ne les remplace pas.

Si votre pipeline ignore les vérifications automatisées et repose entièrement sur l'approbation manuelle, vous ne faites pas de la promotion manuelle. Vous faites du déploiement manuel avec des étapes supplémentaires. La valeur de la promotion manuelle vient de la combinaison des deux : une vérification automatisée rigoureuse et un jugement humain éclairé.

Une checklist pratique pour décider

Lorsque vous définissez les règles de promotion pour votre pipeline, posez-vous ces questions :

• Cet environnement est-il utilisé par des utilisateurs réels ? Si oui, envisagez la promotion manuelle.
• Une erreur ici peut-elle affecter l'intégrité des données ou provoquer une indisponibilité ? Si oui, la promotion manuelle est plus sûre.
• L'équipe a-t-elle suffisamment confiance dans les tests automatisés pour cet environnement ? Sinon, ajoutez une revue manuelle.
• S'agit-il d'un changement de routine (mise à jour de configuration, fonctionnalité mineure) ou d'un changement à haut risque (migration de schéma, mise à jour de bibliothèque) ? Les changements à haut risque bénéficient d'une approbation manuelle, même en staging.
• Combien de temps prend l'approbation manuelle ? Si elle prend des heures, l'équipe pourrait éviter de déployer fréquemment. Trouvez un équilibre entre sécurité et rapidité.

En résumé

La promotion manuelle est une pause délibérée, pas un garde-barrière qui ralentit tout. Utilisez-la là où le coût d'une erreur est plus élevé que le coût d'attendre qu'un humain examine. Pour les environnements précoces, laissez le pipeline s'exécuter. Pour la production et les changements à haut risque, laissez une personne décider. Les meilleurs pipelines combinent une rigueur automatisée et un jugement humain aux bons moments.