Avantages, inconvénients et coûts

Les avantages réels

• Contrôle du blast radius : une règle de protection empêche un déploiement accidentel ou prématuré d'atteindre un environnement sensible — le module 3 l'a montré concrètement, pas en théorie.
• Isolation des secrets : un secret de production n'est exposé qu'aux jobs qui référencent explicitement environment: production — un job de build/test n'y a jamais accès, même par erreur de copier-coller dans le workflow.
• Auditabilité : la page Deployments (module 2) et l'historique d'approbation donnent une trace de qui a approuvé quoi et quand — utile en cas d'incident ou d'audit de conformité.
• Gouvernance sans changer le code du workflow : comme observé au module 3, on peut durcir ou assouplir la gouvernance d'un déploiement en modifiant uniquement la configuration de l'Environment, sans toucher au fichier YAML.

Les inconvénients réels

• Friction disproportionnée si mal calibrée : imposer des reviewers requis sur un environnement de développement ralentit chaque itération sans bénéfice correspondant — la protection doit être proportionnelle à l'enjeu réel de l'environnement, pas appliquée uniformément par réflexe.
• Dérive entre environnements : rien n'empêche que staging et production divergent progressivement (une variable oubliée, une version différente d'une dépendance) si la configuration de chaque Environment est modifiée manuellement sans processus commun.
• Complexité de configuration : plus il y a d'Environments, de règles et de secrets scopés, plus il y a de surface à maintenir et à comprendre pour une nouvelle personne qui rejoint le projet.
• Ce n'est pas une solution d'infrastructure : un Environment GitHub gouverne qui peut déclencher un déploiement et avec quels secrets — il ne provisionne, ne surveille, ni ne fait de rollback de quoi que ce soit lui-même. C'est un point de contrôle, pas une plateforme de déploiement.

Le coût de plan à connaître

Fait vérifié sur la documentation officielle GitHub (à revérifier si vous lisez ceci longtemps après la rédaction — les plans évoluent) :

« Users with GitHub Free plans can only configure environments for public repositories. If you convert a repository from public to private, any configured protection rules or environment secrets will be ignored. »

« Organizations with GitHub Team and users with GitHub Pro can configure environments for private repositories. »

Concrètement : si votre repo est privé et que vous (ou votre organisation) êtes sur un plan Free, vous pouvez créer un Environment et lui ajouter des secrets, mais les règles de protection et les secrets scopés seront silencieusement ignorés — ce qui peut donner une fausse impression de sécurité si vous ne le savez pas. C'est la raison pour laquelle le module 1 recommandait un repo public pour suivre ce parcours.

Décision, pas réflexe

Le point à retenir n'est pas « les Environments sont bons » ou « les Environments sont une contrainte inutile » — c'est que leur bénéfice dépend entièrement du contexte : un environnement de production avec des enjeux réels justifie largement la friction des reviewers requis ; un environnement de développement jetable, non. Le module 6 formalise cette décision avec une grille de critères, une fois que le module 5 aura élargi la perspective au-delà de la seule fonctionnalité GitHub.

Ce que vous venez de faire

Vous savez maintenant peser objectivement les Environments — bénéfices concrets, inconvénients réels, et une contrainte de plan qui peut silencieusement neutraliser la protection que vous croyez avoir configurée. Le module suivant sort du cadre strict de la fonctionnalité GitHub pour parler de stratégie d'environnements en général.