Stratégie d'environnements au sens large
Au-delà de la fonctionnalité GitHub
Les modules 2 à 4 ont couvert la fonctionnalité Environment de GitHub Actions — un objet technique précis, avec ses secrets et ses règles de protection. Mais « avoir des environnements » est une décision de stratégie de déploiement qui existe indépendamment de cet outil précis. Trois patterns reviennent dans la plupart des projets :
Dev / staging / production
Le pattern le plus classique : un environnement pour développer et itérer vite (tolérance élevée aux erreurs), un environnement staging qui doit ressembler le plus possible à la production (pour détecter les problèmes avant qu'ils n'atteignent de vrais utilisateurs), et la production elle-même. Le mapping le plus courant fait correspondre une branche à chaque environnement (develop → staging, main → production), mais ce mapping ne garantit pas que les environnements restent identiques — voir la dérive, déjà introduite au module 4.
Environnements éphémères par pull request
Plutôt que 2-3 environnements fixes, certaines équipes déploient une instance temporaire par pull request, détruite à la fermeture de la PR. Ce site même en est un exemple concret et vérifiable : chaque pull request sur ce repo génère automatiquement une URL de preview Netlify dédiée (visible dans les checks de CI de la PR), sans qu'aucune fonctionnalité Environment GitHub ne soit impliquée — c'est la plateforme d'hébergement qui gère ce cycle de vie, pas GitHub Actions.
Avantage : chaque changement est testable en isolation, sans attendre son tour sur un staging partagé. Inconvénient : coordination plus complexe si plusieurs previews doivent interagir (base de données partagée, par exemple), et coût potentiellement plus élevé si chaque preview consomme des ressources réelles.
Gestion des secrets à travers les environnements
Que les environnements soient gérés via la fonctionnalité GitHub ou via une plateforme tierce, le même risque revient : le secret sprawl. Chaque environnement supplémentaire est un endroit de plus où une clé d'API, un mot de passe de base de données ou un token doit exister — et un endroit de plus à ne pas oublier lors d'une rotation après une fuite. Deux pratiques limitent ce risque, indépendamment de l'outil utilisé :
- Scoper au minimum nécessaire : un environnement de développement ne devrait jamais avoir accès aux vraies clés de production, même « au cas où ».
- Documenter où chaque secret vit : sans inventaire, personne ne sait avec certitude, lors d'une rotation, s'il reste une copie oubliée dans un environnement de test.
Où s'arrête la fonctionnalité GitHub
La fonctionnalité Environment de GitHub (modules 2-4) répond bien au besoin de gouvernance (qui peut déclencher quoi, avec quels secrets) quand le déploiement lui-même est piloté par un workflow GitHub Actions. Elle ne remplace pas une stratégie de déploiement complète : elle n'a pas d'opinion sur le fait d'avoir 2 ou 5 environnements, sur l'endroit où ils tournent (infrastructure propre, plateforme managée), ni sur la façon de détecter une dérive entre eux. Ces décisions restent à prendre indépendamment — c'est l'objet du module suivant.
Ce que vous venez de faire
Vous avez pris du recul sur la fonctionnalité technique des modules précédents pour voir les patterns de stratégie d'environnements qui existent avec ou sans elle, et le risque transversal du secret sprawl. Le dernier module transforme tout ce qui précède en grille de décision actionnable.
Vérifiez votre compréhension
Un environnement de preview/éphémère créé automatiquement pour chaque pull request (par exemple par une plateforme d'hébergement) est-il forcément un Environment GitHub au sens du module 2 ?
Pourquoi la « dérive de configuration » (déjà vue au module 4) est-elle un risque particulier dans un mapping branche → environnement rigide (ex. toujours `develop` → staging, toujours `main` → production) ?
Quel est un risque spécifique de la gestion des secrets à travers plusieurs environnements (dev, staging, prod, et éventuellement des previews éphémères) ?
Envie d'être prévenu des prochains modules ?
L'Académie reste gratuite et en accès libre, sans inscription. Si vous voulez juste être averti par email à la sortie d'un nouveau module, c'est ici — aucune obligation, désinscription en un clic.