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

15 min

Par Stéphane Robert mis à jour le 13 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

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 règles de protection et les secrets d'environnement ne sont pas disponibles partout, et la limite dépend de la fonction. Les secrets et les branches de déploiement d'un dépôt privé demandent au minimum GitHub Pro, ou Team ou Enterprise pour une organisation. Les relecteurs requis (l'approbation) et le délai d'attente sont plus restrictifs : sur Free, Pro et Team, ils ne fonctionnent que sur les dépôts publics, et un dépôt privé exige Enterprise.

Cette limite a une conséquence pédagogique directe : si vous suivez ce module sur un dépôt privé hors Enterprise, l'environnement sera bien créé, mais les approbations 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. Le détail est dans Environnements GitHub Actions.

À 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.
L'approbation par relecteurs requis n'existe que sur les dépôts publics (Free, Pro, Team) ; un dépôt privé exige Enterprise.