Déployer avec GitHub Actions : de la CI à la CD

Une CI verte ne donne aucun droit de déployer en production. Ce module montre comment GitHub Actions matérialise cette frontière : un environnement porte ses propres secrets, exige une approbation humaine, restreint les branches autorisées, et journalise chaque déploiement. Vous y construirez une chaîne build une fois, promouvoir ensuite, de la pull request à la production, avec un retour arrière qui ne dépend pas d'un rebuild.

Ce que vous allez apprendre

Distinguer ce que couvre la CI de ce que couvre la CD, et ce que GitHub appelle un déploiement
Créer un environnement et y rattacher un job avec l'URL de déploiement
Poser des règles de protection : approbations, délai d'attente, branches autorisées
Promouvoir un artefact unique de staging vers la production, sans le reconstruire
Revenir en arrière sans rejouer le pipeline complet

CI et CD ne posent pas la même question

L'intégration continue répond à une question de qualité : ce commit casse-t-il quelque chose ? Elle s'exécute sur chaque branche, chaque pull request, et son verdict est binaire. Le déploiement continu répond à une question de confiance : cet artefact a-t-il le droit d'atteindre les utilisateurs ? La réponse ne dépend plus seulement des tests, mais de qui approuve, depuis quelle branche, avec quels secrets, et vers quelle cible.

Confondre les deux produit l'erreur la plus répandue : un workflow unique qui teste, construit et déploie dans le même job, avec tous les secrets de production chargés dès la première ligne. Un test compromis, une dépendance piégée, et l'attaquant hérite de l'accès à la production.

Question	Traitée par	Mécanisme GitHub
Le code compile-t-il et passe-t-il les tests ?	CI	Jobs, matrices, cache
L'artefact est-il celui qu'on croit ?	Supply chain	Épinglage SHA, attestations
Qui autorise la mise en production ?	CD	Environnements, règles de protection
Comment revenir en arrière ?	CD	Artefact conservé, redéploiement

Ce que GitHub appelle un déploiement

Un déploiement n'est pas un simple job qui lance un script. C'est un objet que GitHub enregistre : il apparaît dans l'onglet Deployments du dépôt, il porte un environnement cible, un état (en attente, en cours, réussi, échoué), et éventuellement une URL consultable. Cette traçabilité est ce qui distingue un ssh serveur "./deploy.sh" d'une chaîne de livraison auditable.

Le déclencheur de cette mécanique tient en une clé de workflow :

jobs:
  deploy:
    runs-on: ubuntu-24.04
    environment: production
    steps:
      - run: ./deploy.sh

À partir de cette ligne, le job n'est plus un job ordinaire. Il est soumis aux règles de l'environnement production : s'il faut une approbation, GitHub met le job en pause et attend ; si la branche courante n'est pas autorisée, le job échoue avant d'avoir démarré ; et les secrets d'environnement ne lui sont délivrés qu'une fois ces conditions remplies.

La chaîne de promotion

Le schéma mental à installer est une ligne de promotion, pas une série de déploiements indépendants. On construit un seul artefact, et c'est ce même artefact qui traverse les étapes :

Pull request
     |
     v
   CI (tests, lint, scanners)
     |
     v
   Build  ->  artefact unique + attestation
     |
     v
  Staging  (environnement, secrets de staging)
     |
     v
 Approbation humaine
     |
     v
Production (environnement protégé, secrets de production)

La propriété qui compte est celle-ci : ce qui est testé en staging est exactement ce qui part en production. Reconstruire entre les deux étapes casse la garantie, parce que le second build peut résoudre des dépendances différentes, embarquer un correctif non testé, ou simplement échouer alors que la validation est déjà donnée.

C'est aussi ce qui rend le retour arrière trivial : l'artefact précédent est toujours là, il suffit de le redéployer. Un rollback qui exige de rejouer le pipeline complet n'est pas un rollback, c'est un nouveau déploiement avec les risques d'un nouveau déploiement.

Le découpage de ce module

Les pages suivantes construisent cette chaîne dans l'ordre où on la met en place sur un dépôt réel. La progression va du contenant (l'environnement) vers le contenu (l'artefact promu), puis vers ce qui se passe quand ça se passe mal.

Étape	Ce qu'elle installe
Environnements	La cible nommée, ses secrets et ses variables propres
Règles de protection	Approbations, délai d'attente, branches autorisées
Promotion d'artefact	Un build unique qui traverse staging puis production
Releases et packages	La distribution publique : release GitHub, image GHCR
Rollback et concurrence	Le retour arrière, et l'interdiction des déploiements simultanés

Le piège de facturation à connaître d'emblée

Les environnements avec règles de protection et les secrets d'environnement ne sont pas disponibles partout. Sur un plan Free, ils ne fonctionnent que sur les dépôts publics : un dépôt privé exige au minimum GitHub Pro, ou un plan Team ou Enterprise pour une organisation.

Cette limite a une conséquence pédagogique directe : si vous suivez ce module sur un dépôt privé en plan gratuit, l'environnement sera bien créé, mais les approbations et les secrets d'environnement ne s'appliqueront pas. Travaillez sur un dépôt public dédié à l'apprentissage, ou vérifiez le plan de votre organisation avant de bâtir une gouvernance dessus.

À retenir

Une CI verte valide la qualité du code ; elle n'autorise pas à déployer. La CD répond à une question différente, celle de la confiance.
Un déploiement GitHub est un objet tracé : environnement cible, état, URL, historique dans l'onglet Deployments.
La clé environment: soumet le job aux règles de l'environnement : pause pour approbation, refus si la branche n'est pas autorisée, secrets délivrés seulement ensuite.
Nommer un environnement inexistant le crée sans aucune protection : configurez-le dans Settings > Environments avant d'écrire le job.
On construit une fois et on promeut : l'artefact testé en staging doit être exactement celui qui part en production.
Les environnements protégés et leurs secrets exigent un dépôt public en plan Free, ou au minimum GitHub Pro sur un dépôt privé.

Pour aller plus loin

Règles de protection des déploiements : Les quatre garde-fous qui transforment un environnement en véritable frontière, approbations comprises.
Promouvoir un artefact : La chaîne build une fois, déployer deux fois, qui garantit que staging et production reçoivent le même binaire.
Rollback et concurrence : Ce qu'il faut avoir préparé avant l'incident pour revenir en arrière en quelques minutes.