Automatiser ses déploiements : le guide CI/CD efficace pour 2026

L'essentiel en une minute

Automatiser ses déploiements, c'est confier à une machine la suite d'étapes qui sépare un git push de la mise en production : tests, build, livraison, et retour arrière si quelque chose casse. Pour un développeur seul ou une petite équipe, un fichier YAML d'une soixantaine de lignes suffit, et les offres gratuites de GitHub et de GitLab couvrent un projet de taille modeste.

Ce guide donne un pipeline GitHub Actions complet, son équivalent GitLab CI, les quotas et les prix lus le 12 octobre 2026 sur les pages officielles, puis les stratégies de déploiement, les secrets et le rollback. Les fichiers ont été relus contre la documentation, pas exécutés.

Points clés

• Pour les dépôts privés d'un même compte, GitHub Free inclut 2 000 minutes par mois. GitLab Free en inclut 400 par espace de noms.
• Au-delà du quota, GitHub facture 0,006 $ la minute sur son runner Linux 2 cœurs, GitLab vend des lots de 1 000 minutes à 10 $.
• Les exemples avec actions/checkout@v4 ou le mot-clé only de GitLab sont datés : les actions officielles en sont aux versions 7 et 8, et GitLab déclare only déprécié.
• L'approbation par un relecteur avant production n'existe pas sur un dépôt privé GitHub en offre Free, Pro ou Team. L'équivalent gratuit est un déclenchement manuel du même fichier.
• Un retour arrière se prépare avant l'incident : chez GitHub, une ancienne exécution ne peut être relancée que pendant 30 jours.

CI, livraison continue, déploiement continu : trois niveaux

Derrière le sigle CI/CD se cachent trois niveaux d'automatisation, et le bon niveau dépend de la confiance que vous accordez à vos tests.

Le programme de recherche DORA, piloté par Google Cloud, mesure le résultat avec cinq indicateurs : délai de mise en production, fréquence de déploiement, temps de rétablissement après un déploiement raté, taux d'échec des changements et taux de reprise des déploiements, ou rework rate (guide des métriques DORA, mis à jour le 5 janvier 2026).

Automatiser ses déploiements avec GitHub Actions

Un seul fichier suffit : placé dans .github/workflows/, il décrit trois jobs enchaînés, test, build et deploy. L'exemple vise une application Node.js, comme l'API de notre tutoriel pour créer une API REST avec Node.js et Express.

name: CI/CD

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test

  build:
    needs: test
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v7
        with:
          name: app
          path: dist/
          retention-days: 7

  deploy:
    needs: build
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    timeout-minutes: 10
    environment:
      name: production
      url: https://example.com
    concurrency: production
    steps:
      - uses: actions/checkout@v7
      - uses: actions/download-artifact@v8
        with:
          name: app
          path: dist
      - name: Déployer
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
        run: bash scripts/deploy.sh dist

La dernière ligne est volontairement neutre : scripts/deploy.sh représente la commande de votre hébergeur, rsync, CLI de plateforme ou kubectl. Notre comparatif des offres d'hébergement cloud pour développeurs aide à choisir la cible. Commencez ce script par test -d dist || exit 1 : un artefact expiré ne doit pas aboutir à un déploiement vide.

Tel quel, ce fichier fait du déploiement continu, le troisième niveau du tableau : chaque push sur main part en production. Pour en rester à la livraison continue sans offre payante, ajoutez workflow_dispatch: sous on et réservez deploy à cet événement : le bouton « Run workflow » rejoue alors tests, build et déploiement dans la même exécution. Dans cette variante, seules ces lignes changent :

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  build:
    needs: test
    if: github.event_name != 'pull_request'
    # reste du job inchangé

  deploy:
    needs: build
    if: github.event_name == 'workflow_dispatch' && github.ref == 'refs/heads/main'
    # reste du job inchangé

La page sur le lancement manuel précise que le fichier doit se trouver sur la branche par défaut pour que le bouton apparaisse.

Ce que fait chaque bloc

Chaque mot-clé ci-dessous est décrit dans la référence de syntaxe des workflows de GitHub, consultée le 12 octobre 2026.

• on. Le workflow tourne sur chaque demande de fusion (pull request) vers main, où seul le job test s'exécute, et sur chaque push sur main.
• permissions. Le jeton GITHUB_TOKEN est limité à la lecture du code, le minimum que GitHub recommande.
• needs et if. Un job ne démarre que si celui dont il dépend a réussi : un test rouge bloque le déploiement. Le if de build le réserve aux push, et deploy est ignoré quand build l'est.
• timeout-minutes. Sans cette ligne, un job bloqué peut tourner 360 minutes, la valeur par défaut, et vider votre quota.
• environment. Le job est rattaché à l'environnement production. Sur un dépôt privé en offre Free, retirez ce bloc et créez DEPLOY_TOKEN comme secret de dépôt : d'après la page de gestion des environnements, les environnements et leurs secrets y demandent une offre Pro, Team ou Enterprise.
• concurrency. Deux déploiements vers la production ne s'exécutent jamais en même temps, et un déploiement en attente est remplacé par le plus récent.

Les versions datent vite un tutoriel. Au 12 octobre 2026, les dépôts officiels publient actions/checkout v7.0.1, actions/setup-node v7.1.0, actions/upload-artifact v7.0.2 et actions/download-artifact v8.0.2, et les exemples du README de setup-node utilisent Node.js 24.

Le même pipeline avec GitLab CI

Chez GitLab, tout tient dans un fichier .gitlab-ci.yml à la racine, organisé en étapes (stages) plutôt qu'en dépendances entre jobs.

stages:
  - test
  - build
  - deploy

default:
  image: node:24
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/

test:
  stage: test
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run lint
    - npm test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

build:
  stage: build
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy_production:
  stage: deploy
  cache: []
  script:
    - bash scripts/deploy.sh dist
  environment:
    name: production
    url: https://example.com
  resource_group: production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

Trois différences comptent face à GitHub Actions, toutes vérifiées dans la référence YAML de GitLab CI/CD :

• rules remplace only. La page des mots-clés dépréciés demande d'utiliser rules à la place de only et except.
• when: manual crée un bouton. Le job de production attend qu'une personne le lance depuis l'interface : ce fichier s'arrête donc à la livraison continue.
• resource_group joue le rôle de concurrency. Un seul job du groupe s'exécute à la fois, les autres attendent.

Le cache suit l'exemple Node.js de la documentation GitLab sur le cache. Le job de déploiement, qui n'installe rien, le désactive avec cache: [], la forme indiquée par la page sur le cache. Les artefacts de build arrivent dans le job suivant sans étape de téléchargement.

GitHub Actions ou GitLab CI : quotas gratuits et prix

Sur l'offre gratuite, GitHub donne cinq fois plus de minutes que GitLab pour des dépôts privés, et ne compte rien pour un dépôt public sur ses runners standards. Le quota vaut pour tout le compte chez GitHub et pour tout l'espace de noms de premier niveau chez GitLab, pas par dépôt. Le tableau reprend les chiffres lus le 12 octobre 2026 sur la page de facturation de GitHub Actions, la page de prix de GitHub et la page de prix de GitLab.

Le prix de GitHub Team est affiché « pour les 12 premiers mois » (notre traduction). Le stockage ne se compare pas d'une ligne à l'autre : artefacts et paquets chez GitHub, dépôt Git et fichiers LFS chez GitLab.

Le dépassement se paie différemment. GitHub facture à la minute : 0,006 $ sur Linux 2 cœurs, 0,010 $ sur Windows 2 cœurs et 0,062 $ sur macOS, selon sa grille des runners. GitLab vend des lots : 10 $ les 1 000 minutes, en paiement unique. Sa documentation sur les minutes de calcul précise que les minutes achetées et non utilisées sont reportées au mois suivant.

Notre calcul. Un compte consomme 3 000 minutes dans le mois sur ses dépôts privés. Sur GitHub Free, 1 000 minutes dépassent le quota : 1 000 × 0,006 $ = 6 $. Sur GitLab Free, 2 600 minutes dépassent : il faut trois lots, soit 30 $ le premier mois, dont 400 minutes reportées. Si ce rythme se répète, le report ramène la moyenne à 26 $ par mois (2 600 × 0,01 $) : les minutes achetées restent valables 12 mois, selon la page d'achat de GitLab. Ce calcul ignore le stockage.

Trois règles changent la facture réelle :

• L'arrondi par job. GitHub arrondit chaque job à la minute supérieure, selon sa grille des runners : notre pipeline consomme au moins trois minutes par push sur main, une par demande de fusion.
• Le facteur de coût. GitLab multiplie la durée par un coefficient : 1 pour sa machine Linux par défaut, 2 pour la taille au-dessus.
• Vos propres machines. À la date de lecture, ni GitHub (page de facturation) ni GitLab (page de prix) ne décomptent de minutes pour un job exécuté sur un runner que vous hébergez.

Verdict : pour un projet personnel ou une petite équipe, l'offre gratuite de GitHub Actions est la plus large. GitLab Free devient vite juste, sauf à brancher son propre runner.

Rolling, blue-green, canary : quelle stratégie choisir

La stratégie décide de ce que voient vos utilisateurs pendant la mise à jour, et de la vitesse du retour arrière. La colonne « coût » du tableau est notre lecture, pas une mesure.

Le rolling update est le comportement par défaut d'un Deployment Kubernetes. La documentation de Kubernetes fixe par défaut à 25 % la part de pods qui peuvent être indisponibles pendant la mise à jour, et à 25 % la part de pods créés en plus. Par défaut, un pod y est jugé disponible dès qu'il est prêt : une sonde de disponibilité (readiness probe) sert à dire quand l'application répond vraiment. Définissez-en une. Nos guides Kubernetes pour débutants et Docker pour débutants posent les bases.

Le blue-green repose sur deux environnements de production aussi identiques que possible, dont un seul reçoit le trafic. Une fois la nouvelle version validée sur l'environnement inactif, le routeur bascule, et il rebascule en cas de problème (Martin Fowler, 1er mars 2010).

Le canary ouvre la nouvelle version à un petit sous-ensemble d'utilisateurs avant de la généraliser (Danilo Sato sur le site de Martin Fowler, 25 juin 2014). Il suppose de savoir router une fraction du trafic et de surveiller des métriques.

Dans les trois cas, deux versions cohabitent un moment. À notre lecture, le schéma de la base et les API doivent alors accepter l'ancienne et la nouvelle : c'est la difficulté que Fowler signale pour le blue-green.

Verdict : avec une seule instance, la priorité est un rollback rapide. À partir de deux, le rolling suffit à la plupart des petites équipes. Pour situer les fournisseurs, voyez notre comparatif AWS, Azure et Google Cloud.

Secrets : ce qui ne doit jamais entrer dans le dépôt

Un jeton de déploiement se range dans le coffre de la plateforme, jamais dans le code. Chez GitHub, un secret se crée dans les réglages du dépôt, puis se lit avec ${{ secrets.NOM }}, comme dans notre job deploy (documentation des secrets, consultée le 12 octobre 2026).

Les règles à connaître, d'après cette page :

• Les forks n'y ont pas accès. À l'exception de GITHUB_TOKEN, aucun secret n'est transmis à un workflow déclenché depuis un fork. Attention au déclencheur pull_request_target, qui peut accéder aux secrets selon la référence de sécurité.
• Pas de secret dans un if. Il faut passer par une variable d'environnement.
• Le masquage n'est pas garanti. GitHub masque les secrets dans les journaux, mais cette même référence prévient qu'une valeur transformée peut y échapper.

Cette référence de sécurité rappelle aussi que toute personne ayant un accès en écriture au dépôt peut lire ses secrets, et recommande d'épingler les actions tierces sur l'empreinte complète d'un commit.

L'approbation avant production a une limite. Un environnement GitHub peut exiger l'accord d'un relecteur. Mais la documentation des environnements précise que, sur les offres Free, Pro et Team, les relecteurs obligatoires ne sont disponibles que pour les dépôts publics. L'équivalent gratuit est la variante workflow_dispatch présentée plus haut.

Chez GitLab, DEPLOY_TOKEN se crée dans Settings > CI/CD > Variables et arrive dans le job comme variable d'environnement. La documentation des variables indique que ces variables sont masquées par défaut depuis GitLab 18.3, et qu'une variable « protégée » n'est fournie qu'aux pipelines des branches et des tags protégés.

Vers un fournisseur cloud, le mieux est de ne stocker aucun identifiant durable : avec OpenID Connect, le workflow obtient un jeton de courte durée, valable pour un seul job (documentation OIDC de GitHub). Le job doit alors déclarer id-token: write, précise la référence OIDC. Les permissions non citées dans un bloc tombent à none : gardez contents: read, sinon l'étape de checkout échoue sur un dépôt privé.

  deploy:
    permissions:
      contents: read
      id-token: write

Rollback : préparer le retour arrière

Un rollback fiable redéploie une version déjà validée, au lieu de corriger dans l'urgence. Quatre mécanismes existent.

• Annuler le commit. Un git revert suivi d'un push relance tout le pipeline : sûr, mais au prix du temps complet des tests et du build.
• Relancer une ancienne exécution GitHub. Une exécution peut être relancée jusqu'à 30 jours après son premier lancement, 50 fois au plus, et elle réutilise le commit d'origine (documentation de GitHub). Notre artefact expire au bout de 7 jours : passé ce délai, relancez l'exécution entière et pas seulement le job deploy.
• Utiliser le bouton de GitLab. Dans la page de l'environnement, « Rollback environment » crée un nouveau déploiement pointant vers l'ancien commit. La documentation des déploiements GitLab précise que seuls les jobs de déploiement sont rejoués. Même limite que chez GitHub : passé expire_in, le job rejoué n'a plus d'artefact. Relancez alors le pipeline complet de l'ancien commit, ou allongez expire_in.
• Revenir en arrière dans Kubernetes. La commande kubectl rollout undo restaure la révision précédente. Kubernetes en conserve 10 par défaut, d'après la documentation des Deployments.

Aucun de ces mécanismes ne défait une migration de base de données. La parade décrite par Martin Fowler : modifier d'abord le schéma pour qu'il accepte l'ancienne et la nouvelle version du code, déployer, puis nettoyer plus tard.

Verdict : pour automatiser ses déploiements sereinement, écrivez la procédure de retour arrière en même temps que le pipeline, et alignez la conservation des artefacts sur le délai pendant lequel vous voulez pouvoir revenir.

Ce que mesure la recherche DORA

À notre lecture, automatiser ne suffit pas à livrer mieux. Le guide des métriques DORA affirme que vitesse et stabilité ne s'opposent pas, mais les rapports DORA 2024 et 2025 associent l'adoption de l'IA à une stabilité en baisse. Le rapport 2024 estime qu'à mesure que l'adoption de l'IA progressait, le débit de livraison reculait de 1,5 % et la stabilité de 7,2 % (Google Cloud, synthèse du rapport DORA 2024, 23 octobre 2024).

Le rapport 2025, fondé sur les réponses de près de 5 000 professionnels, constate un lien positif entre l'IA et le débit de livraison, mais toujours un lien négatif avec la stabilité (Google Cloud, annonce du rapport DORA 2025, 23 septembre 2025).

L'explication avancée dans l'annonce du rapport 2025 concerne votre pipeline : sans tests automatisés solides et sans retours rapides, l'accélération se traduit en instabilité. Si vous cherchez à coder plus vite avec l'IA, le pipeline est, selon nous, le filet de sécurité. Ces chiffres sont des corrélations issues d'enquêtes.

Par où commencer : 1. le job test sur chaque demande de fusion ; 2. le build et l'artefact ; 3. le déploiement, d'abord vers une recette ; 4. un rollback répété un jour calme.

Ce que nous n'avons pas pu vérifier

Plusieurs points restent hors de portée ou incertains :

• L'exécution des deux fichiers YAML. Chaque mot-clé a été relu dans la documentation, mais aucun pipeline n'a été lancé. Validez-les sur une branche.
• Les seuils de performance DORA. Ils figurent dans les rapports complets, que nous n'avons pas pu relire : ils sont absents de cet article.
• Le prix de GitHub Pro et les prix en euros. La page de prix lue ne présente que les offres Free, Team et Enterprise, en dollars.
• Les conséquences d'un quota GitLab épuisé. La page lue parle de « mesures de restriction » (enforcement) sans les détailler.

Questions fréquentes

Quelle est la différence entre livraison continue et déploiement continu ?

En livraison continue, une personne déclenche la mise en production, par exemple avec un job when: manual chez GitLab. En déploiement continu, elle part seule dès que les tests passent, ce qui suppose des tests fiables et un rollback rapide.

GitHub Actions est-il gratuit ?

Oui pour les dépôts publics, sur les runners standards. Pour les dépôts privés d'un même compte, la page de facturation de GitHub indique 2 000 minutes par mois sur l'offre Free, chiffre lu le 12 octobre 2026. Au-delà, le runner Linux 2 cœurs coûte 0,006 $ la minute.

Faut-il choisir GitHub Actions ou GitLab CI ?

Choisissez celui de la plateforme qui héberge déjà votre code. En offre gratuite, GitHub inclut 2 000 minutes par compte contre 400 par espace de noms pour GitLab, sur des dépôts privés. GitLab garde un avantage : un bouton d'approbation intégré au pipeline, sans offre payante. Chez GitHub, l'équivalent gratuit est la variante workflow_dispatch du même fichier, lancée par le bouton « Run workflow ».

Comment annuler un déploiement raté ?

Redéployez la dernière version saine : git revert puis push, relance d'une ancienne exécution GitHub dans la limite de 30 jours, bouton « Rollback environment » de GitLab, ou kubectl rollout undo sur Kubernetes.

À propos de l'auteur

Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d'IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur.

Méthode. Synthèse de recherche fondée exclusivement sur des sources publiques : documentation et pages de prix de GitHub et de GitLab, documentation de Kubernetes, site de Martin Fowler, guide et rapports du programme DORA. Les deux fichiers YAML ont été relus contre la documentation officielle mais n'ont pas été exécutés. Les citations issues de sources en anglais sont traduites par nos soins. Aucun lien n'est affilié et aucune relation commerciale ne lie l'auteur aux éditeurs mentionnés.

Une erreur ou un prix périmé ? Écrivez à contact@neurautech.com : l'article sera corrigé et la date de mise à jour modifiée.

Dernière mise à jour : 12 octobre 2026.

Images : Domaintechnik et Jordan Harrison (Unsplash License).