CI, Continuous Delivery, Continuous Deployment : quel niveau choisir ?

L'intégration continue valide chaque modification, la livraison continue rend le code déployable à tout moment, le déploiement continu le met en production sans intervention humaine. Les deux dernières partagent l'acronyme « CD », d'où la confusion. Le choix du niveau n'est pas une question de vocabulaire : il engage la culture de l'équipe, ses exigences de tests et le risque qu'elle accepte. Cette leçon définit les trois pratiques, aide à choisir son niveau et montre une chaîne complète qui les enchaîne.

Ce que vous allez apprendre

• Distinguer intégration continue, livraison continue et déploiement continu
• Appliquer les quatre règles qui rendent une CI efficace
• Justifier une validation humaine avant la production
• Vérifier les prérequis du déploiement continu avant de l'adopter
• Lire une chaîne complète et situer sa porte d'approbation
• Reconnaître le piège du « full CD » prématuré

Les trois niveaux d'automatisation

Chaque niveau inclut le précédent : pas de livraison continue sans intégration continue, pas de déploiement continu sans livraison continue. C'est une progression, pas un choix entre trois options équivalentes. Le schéma montre où chacun s'arrête : la CI s'arrête à la validation, la livraison à un artefact prêt, le déploiement à la production.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

L'intégration continue, la base obligatoire

L'intégration continue (CI) valide chaque modification dès qu'elle est poussée, avant qu'elle ne rejoigne la branche principale. Imaginez cinq développeurs, chacun sur sa branche : Alice pousse lundi, Bob mardi, chaque code compile chez son auteur, et vendredi la fusion ne compile plus, parce que les deux changements sont incompatibles sans que personne le sache.

Avec la CI, le problème apparaît immédiatement : dès qu'Alice pousse, la pipeline vérifie que son code fonctionne avec le reste, et elle le sait en quelques minutes plutôt qu'en cinq jours. À chaque commit ou pull request, la pipeline compile, lance les tests unitaires et d'intégration, l'analyse statique et un scan des dépendances vulnérables.

Pourquoi la CI n'est pas négociable

Plus un bogue est découvert tard, plus il coûte : au moment du commit, son auteur a encore le contexte en tête ; en production, il faut retrouver le changement fautif, le corriger sous pression et redéployer. La CI ramène la détection au plus près de l'écriture du code.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Les quatre règles d'une CI efficace

Une CI ne protège que si elle est respectée. Chaque commit la déclenche, sans exception ; un échec bloque la fusion, pour qu'aucun code cassé n'atteigne la branche principale ; les tests restent rapides, idéalement sous dix minutes, faute de quoi les développeurs contournent le système ; et le retour arrive directement au développeur, dans son interface ou sa messagerie.

La livraison continue : prêt à déployer, sur décision

La livraison continue (Continuous Delivery) prolonge la CI : le code n'est pas seulement validé, il est prêt à partir en production à tout moment. Un humain décide quand. Après la CI, la pipeline construit un artefact immuable (image, binaire, paquet), le déploie en recette, lance des tests de bout en bout sur des parcours complets, puis attend une validation.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Pourquoi garder une validation humaine ?

La validation humaine n'est pas un aveu de faiblesse : elle est rationnelle dans quatre situations. Une fonctionnalité doit sortir avec une annonce commerciale, et le déploiement automatique ne lit pas le calendrier marketing. Un secteur régulé (santé, finance, aéronautique) exige que chaque mise en production soit documentée et approuvée. L'équipe n'a pas encore assez de tests pour s'en passer. Ou le déploiement touche des partenaires qu'il faut prévenir.

Le point clé tient en une phrase : avec la livraison continue, le code est toujours déployable. La question n'est plus « peut-on déployer ? », mais « veut-on déployer maintenant ? ». C'est cette disponibilité permanente qui compte, pas l'absence de bouton.

Le déploiement continu : aucune intervention humaine

Le déploiement continu (Continuous Deployment) supprime la dernière barrière : chaque modification validée part automatiquement en production. Un développeur fusionne sa pull request à 14 h 03 ; à 14 h 08, le code sert de vrais utilisateurs, sans que personne ait cliqué sur « déployer ». En 2011 déjà, Amazon annonçait un déploiement en production toutes les 11,6 secondes en moyenne.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Les prérequis, et ils sont stricts

Sans humain dans la boucle, un bogue qui passe les tests arrive en production. Le déploiement continu exige donc cinq fondations. Des tests qui couvrent chaque chemin critique. Des feature flags, qui livrent du code désactivé et permettent de couper une fonctionnalité sans redéployer. Un retour arrière automatique quand les taux d'erreur ou la latence se dégradent.

Il faut aussi une observabilité qui détecte un problème en secondes, avec alertes, tableaux de bord et journaux centralisés : on ne corrige pas ce qu'on ne voit pas. Et une culture sans blâme, où un incident sert à améliorer le système plutôt qu'à désigner un coupable, sans quoi les développeurs auront peur de fusionner. Les équipes qui pratiquent ce mode y ont investi des années : c'est une destination, pas un point de départ.

Comparaison côte à côte

Le tableau met les trois pratiques en regard sur huit critères. Lisez surtout les lignes « déploiement production » et « intervention humaine » : c'est là que se joue la différence entre les deux CD. Les autres lignes montrent ce que chaque niveau ajoute en exigences, notamment en tests et en retour arrière.

Aspect	CI	Livraison continue	Déploiement continu
Déclencheur	Commit, pull request	Fusion dans main	Fusion dans main
Artefact produit	Optionnel	Obligatoire	Obligatoire
Déploiement en recette	Optionnel	Obligatoire	Obligatoire
Déploiement production	Non	Manuel	Automatique
Retour arrière	Sans objet	Manuel	Automatique
Exigence de tests	Unitaires	De bout en bout	De bout en bout et canary
Délai avant production	Sans objet	Heures à jours	Minutes
Intervention humaine	Aucune	Validation finale	Aucune

Glissez pour voir

Comment choisir son niveau d'automatisation ?

Le bon niveau est celui que l'équipe sait tenir, et il se gravit dans l'ordre. Commencez par la CI si elle manque : c'est la priorité absolue, avec un objectif minimal clair, chaque pull request qui déclenche une pipeline, des tests qui bloquent la fusion en cas d'échec et un retour en moins de dix minutes. Le reste peut attendre tant que ce socle n'est pas en place.

Une fois la CI stabilisée, passez à la livraison continue : artefacts immuables, déploiement automatique en recette après chaque fusion, tests de bout en bout, validation humaine avant la production. C'est le niveau suffisant pour la plupart des équipes, et la validation humaine y est souvent la bonne réponse, pas un échec.

Le déploiement continu se considère ensuite, et seulement si quatre réponses sont « oui » : les chemins critiques sont-ils couverts par des tests automatisés ? Détecte-t-on un problème en production en quelques minutes ? Le retour arrière est-il automatique ? L'équipe traite-t-elle les incidents sans chercher de coupable ? Un seul « non », et la livraison continue reste le bon choix.

À quoi ressemble une chaîne complète, de la CI à la production ?

Une chaîne de livraison continue enchaîne les trois niveaux dans un même fichier : la partie CI valide chaque modification, la partie CD déploie en recette puis en production, et une porte d'approbation sépare les deux dernières étapes. Le fichier ci-dessous est écrit pour GitHub Actions : il se lit sans en connaître la syntaxe, qu'enseigne la formation GitHub Actions, et il illustre ce que les leçons de la formation construisent pas à pas.

Les jobs de CI (lint, test, security) s'exécutent en parallèle, puis build ne démarre que si les trois réussissent, grâce à la clé needs. La partie CD suit le même chaînage jusqu'à la production. L'image est construite une seule fois, étiquetée par le SHA du commit, et c'est elle que les environnements reçoivent.

name: CI/CD Pipeline

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

# Aucun droit par défaut : chaque job ne reçoit que ce dont il a besoin
permissions: {}

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  # ===== CONTINUOUS INTEGRATION =====

  lint:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          persist-credentials: false
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020  # v7.0.0
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          persist-credentials: false
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020  # v7.0.0
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run test -- --coverage
      - uses: codecov/codecov-action@fb8b3582c8e4def4969c97caa2f19720cb33a72f  # v7.0.0

  security:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          persist-credentials: false
      - name: Run Trivy
        uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0, pinné par SHA
        with:
          scan-type: 'fs'
          severity: 'CRITICAL,HIGH'
      - name: Check secrets
        uses: gitleaks/gitleaks-action@e0c47f4f8be36e29cdc102c57e68cb5cbf0e8d1e  # v3.0.0

  build:
    needs: [lint, test, security]
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          persist-credentials: false
      - uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c  # v4.2.0
      - uses: docker/login-action@06fb636fac595d6fb4b28a5dfcb21a6f5091859c  # v4.5.0
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@53b7df96c91f9c12dcc8a07bcb9ccacbed38856a  # v7.3.0
        with:
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  # ===== CONTINUOUS DELIVERY =====

  deploy-staging:
    if: github.ref == 'refs/heads/main'
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - name: Deploy to staging
        run: |
          echo "Déploiement sur staging..."
          # kubectl, ArgoCD, ou autre outil de déploiement

  integration-tests:
    needs: deploy-staging
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
        with:
          persist-credentials: false
      - name: Run E2E tests on staging
        run: npm run test:e2e
        env:
          BASE_URL: https://recette.inventaire.lab

  deploy-production:
    needs: integration-tests
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://inventaire.lab
    steps:
      - name: Deploy to production
        run: |
          echo "Déploiement en production..."
          # Déploiement avec stratégie Blue/Green ou Canary

Deux réglages de sécurité encadrent ce fichier : permissions: {} retire tout droit au jeton GitHub par défaut, chaque job ne recevant que le strict nécessaire (packages: write pour publier l'image), et persist-credentials: false évite que le jeton reste écrit sur le disque du runner après le checkout. Les étapes Deploy ne font qu'un echo : le déploiement réel dépend de la cible, et la leçon Environnements et promotion en montre un complet.

La clé environment: production est ce qui fait de ce fichier une livraison continue plutôt qu'un déploiement continu. Côté GitHub, elle déclenche une règle de protection configurable : approbation manuelle, restriction de branche ou délai d'attente. Retirez la règle, et le même fichier part en production sans intervention : le niveau d'automatisation se règle sans dupliquer la pipeline.

Le piège du « full CD »

Certaines équipes veulent « faire du déploiement continu » pour cocher une case ou parce qu'une grande entreprise le fait, sans en avoir les prérequis. Le résultat est prévisible : des bogues en production chaque jour, des développeurs qui ont peur de fusionner et fusionnent donc moins souvent, des retours arrière manuels en urgence, puis une perte de confiance dans la pipeline.

Le déploiement continu n'est pas un objectif en soi, c'est la conséquence d'une maturité acquise. La bonne approche consiste à rester en livraison continue et à renforcer tests, observabilité et culture. Le jour où la validation humaine n'apporte plus rien, parce que les tests détectent ce qu'elle aurait vu, le passage au déploiement continu devient naturel.

À retenir

• La CI valide chaque commit automatiquement : elle est obligatoire pour toute équipe.
• La livraison continue garde le code toujours déployable, la mise en production restant une décision humaine.
• Le déploiement continu met en production sans intervention humaine, et exige tests, feature flags, retour arrière automatique, observabilité et culture sans blâme.
• Chaque niveau inclut les précédents : il n'y a pas de raccourci.
• Une validation humaine est souvent la bonne réponse, pas un échec.
• Le « full CD » prématuré crée plus de problèmes qu'il n'en résout.
• Dans une chaîne complète, une porte d'approbation avant la production suffit à faire d'un déploiement continu une livraison continue.

Contrôle de connaissances

Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →