CI, Continuous Delivery, Continuous Deployment : les différences
Mise à jour :
« On fait du CI/CD ». Vous avez sûrement entendu cette phrase. Mais que cache-t-elle vraiment ?
Derrière ce terme fourre-tout se cachent trois pratiques distinctes :
- CI — Continuous Integration (intégration continue)
- CD — Continuous Delivery (livraison continue)
- CD — Continuous Deployment (déploiement continu)
Oui, les deux dernières partagent le même acronyme. C’est la source de beaucoup de confusion. Et non, ce n’est pas qu’une question de vocabulaire : le niveau d’automatisation choisi impacte directement votre culture d’équipe, vos exigences de tests et votre niveau de risque accepté.
En bref : CI valide le code. Delivery le rend déployable. Deployment le met en production automatiquement. Plus on automatise, plus les exigences de qualité augmentent.
Vue d’ensemble : les trois niveaux
Avant d’entrer dans les détails, voici comment ces trois pratiques s’enchaînent :
Ce qu’il faut retenir : Chaque niveau inclut le précédent. On ne peut pas faire de Delivery sans CI. On ne peut pas faire de Deployment sans Delivery. C’est une progression, pas un choix entre trois options.
Continuous Integration (CI) : la base obligatoire
L’intégration continue est le socle sur lequel tout repose. Le principe : valider chaque modification de code dès qu’elle est poussée, avant qu’elle ne rejoigne la branche principale.
À quoi ça sert concrètement ?
Imaginez une équipe de 5 développeurs. Chacun travaille sur sa branche. Sans CI, voici ce qui se passe :
- Alice pousse du code lundi. Il compile chez elle.
- Bob pousse du code mardi. Il compile chez lui.
- Vendredi, on merge tout. Rien ne compile. Le code d’Alice et de Bob est incompatible, mais personne ne le savait.
Avec CI, le problème est détecté immédiatement. Dès qu’Alice pousse, la pipeline teste si son code fonctionne avec le reste. Si ça casse, elle le sait en 5 minutes — pas en 5 jours.
Ce que fait une pipeline CI
À chaque commit ou pull request, la pipeline exécute automatiquement :
- Compilation — Le code compile-t-il sans erreur ?
- Tests unitaires — Chaque fonction fait-elle ce qu’elle doit faire ?
- Tests d’intégration — Les composants fonctionnent-ils ensemble ?
- Analyse statique — Le code respecte-t-il les conventions (linting, formatage) ?
- Scan de sécurité — Y a-t-il des vulnérabilités connues dans les dépendances ?
Pourquoi c’est non négociable
Le coût de correction d’un bug explose avec le temps. Un bug détecté au moment du commit coûte quelques minutes à corriger. Le même bug découvert en production peut coûter des heures, voire des jours.
Les règles d’or de la CI
Pour que la CI soit efficace, quatre règles doivent être respectées :
- Chaque commit déclenche la CI — Pas d’exception, pas de « je push vite fait sans tester »
- Un échec bloque le merge — Aucun code cassé ne doit atteindre la branche principale
- Les tests sont rapides — Idéalement moins de 10 minutes. Au-delà, les développeurs contournent le système.
- Le feedback est immédiat — Notification directe au développeur (Slack, email, interface web)
Continuous Delivery : prêt à déployer, sur demande
La livraison continue prolonge la CI. Le code n’est pas seulement validé — il est prêt à être déployé en production à tout moment. Mais un humain décide quand appuyer sur le bouton.
L’analogie de l’usine
Pensez à une usine automobile. La CI vérifie que chaque pièce est conforme. La Delivery assemble la voiture complète, la teste sur piste, et la gare dans le parking « prêt à livrer ». Le client (ou le commercial) décide quand elle part.
La voiture est toujours prête. La décision de livrer est séparée de la capacité à livrer.
Ce que fait une pipeline Delivery
Après la CI (qui a validé le code), la pipeline continue :
- Construit un artefact immuable — Une image Docker, un binaire, un package qui ne changera plus
- Déploie en environnement de test — Staging ou préproduction
- Exécute des tests end-to-end — Scénarios utilisateurs complets (parcours d’achat, inscription, etc.)
- Attend une validation — Technique, métier, ou les deux
Pourquoi garder une validation humaine ?
La validation humaine n’est pas un aveu de faiblesse. Au contraire, elle est parfaitement rationnelle dans certains contextes :
Contexte métier
Une nouvelle fonctionnalité doit être annoncée en même temps que sa sortie. Le marketing veut synchroniser la release avec une campagne. Le déploiement automatique ne sait pas lire le calendrier marketing.
Environnement régulé
Dans la santé, la finance ou l’aéronautique, chaque mise en production doit être documentée et approuvée. C’est la loi, pas un choix technique.
Confiance en construction
L’équipe n’a pas encore une couverture de tests suffisante pour dormir tranquille. La validation humaine est un filet de sécurité temporaire, le temps de renforcer les tests automatisés.
Coordination externe
Le déploiement impacte des partenaires, des clients, ou des équipes externes. Il faut les prévenir, parfois attendre leur feu vert.
Le point clé : Avec la Delivery, le code est toujours déployable. La question n’est pas « peut-on déployer ? » mais « veut-on déployer maintenant ? ».
Continuous Deployment : zéro intervention humaine
Le déploiement continu supprime la dernière barrière. Chaque modification validée par la CI part automatiquement en production. Aucun humain dans la boucle.
Ce que ça change
Concrètement : un développeur merge sa pull request à 14h03. À 14h08, le code tourne en production devant de vrais utilisateurs. Sans que personne n’ait cliqué sur « déployer ».
Les prérequis (stricts)
Le Continuous Deployment n’est pas pour tout le monde. Il exige un niveau de maturité élevé sur plusieurs axes :
Couverture de tests excellente
Si un bug passe les tests, il arrive en production. Il n’y a plus de filet humain. Chaque chemin critique de l’application doit être testé automatiquement.
Feature flags
Les feature flags (ou toggles) permettent de déployer du code désactivé. Si une fonctionnalité pose problème, on la coupe sans rollback, sans redéploiement. C’est un interrupteur, pas une machine à remonter le temps.
Rollback automatique
Si les métriques de production dégradent après un déploiement (erreurs 500 en hausse, latence qui explose), la pipeline doit revenir automatiquement à la version précédente. Pas d’attente qu’un humain se réveille à 3h du matin.
Observabilité avancée
Détecter un problème en secondes, pas en heures. Alertes sur les métriques clés, dashboards en temps réel, logs centralisés. Si vous ne voyez pas le problème, vous ne pouvez pas le corriger.
Culture blameless
Avec des déploiements automatiques, les incidents arrivent. L’équipe doit traiter chaque incident comme une opportunité d’amélioration, pas comme une faute à punir. Sinon, les développeurs auront peur de merger.
Qui pratique vraiment le Continuous Deployment ?
Des équipes qui déploient plusieurs fois par jour en production :
- Netflix — Des milliers de déploiements quotidiens
- Amazon — Un déploiement toutes les 11 secondes (chiffre historique de 2015)
- Etsy — Pionniers du déploiement continu depuis 2010
- GitHub — Plusieurs centaines de déploiements par jour
Point important : Ces équipes ont des années d’investissement dans leurs pipelines, leurs tests et leur culture. Le Continuous Deployment n’est pas un point de départ — c’est une destination.
Comparaison côte à côte
| Aspect | CI | Delivery | Deployment |
|---|---|---|---|
| Déclencheur | Commit / PR | Merge dans main | Merge dans main |
| Artefact produit | Optionnel | Obligatoire | Obligatoire |
| Déploiement staging | Optionnel | Obligatoire | Obligatoire |
| Déploiement production | ❌ Non | ✅ Manuel | ✅ Automatique |
| Rollback | N/A | Manuel | Automatique |
| Exigence tests | Unitaires | End-to-end | E2E + canary |
| Délai avant prod | N/A | Heures à jours | Minutes |
| Intervention humaine | Aucune | Validation finale | Aucune |
Comment choisir son niveau d’automatisation
Étape 1 : Commencer par la CI (obligatoire)
Si vous n’avez pas encore de CI, c’est votre priorité absolue. Aucune équipe moderne ne devrait merger du code sans validation automatisée.
Objectif minimal :
- Chaque PR déclenche une pipeline
- Les tests unitaires bloquent le merge s’ils échouent
- Le feedback arrive en moins de 10 minutes
Vous pouvez ignorer le reste tant que ce n’est pas en place.
Étape 2 : Évoluer vers la Delivery (recommandé)
Une fois la CI stabilisée (quelques semaines à quelques mois), ajoutez :
- La construction d’artefacts immutables (images Docker, binaires versionnés)
- Le déploiement automatisé en staging après chaque merge
- Des tests end-to-end sur l’environnement de staging
- Une validation humaine avant le déploiement en production
C’est le niveau de maturité suffisant pour 90% des équipes. La validation humaine n’est pas un échec — c’est souvent la bonne réponse.
Étape 3 : Considérer le Deployment (optionnel)
Avant de vous lancer, posez-vous ces questions honnêtement :
- Tests — Avez-vous une couverture > 80% sur les chemins critiques ?
- Détection — Pouvez-vous détecter un problème en prod en moins de 5 minutes ?
- Rollback — Avez-vous un mécanisme de retour arrière automatique ?
- Culture — Votre équipe accepte-t-elle les incidents sans chercher de coupable ?
Si vous répondez « non » à une seule question, restez en Delivery. Le Deployment viendra naturellement quand les fondations seront solides.
Le piège du « full CD »
Certaines équipes veulent « faire du Continuous Deployment » pour impressionner, pour cocher une case, ou parce que « Netflix le fait ». Sans avoir les prérequis.
Le résultat prévisible :
- Des bugs en production tous les jours
- Des développeurs qui ont peur de merger (et donc mergent moins souvent, ce qui aggrave les problèmes)
- Des rollbacks manuels en urgence le vendredi soir
- Une perte de confiance dans la pipeline (« de toute façon, ça casse toujours »)
Le Continuous Deployment n’est pas un objectif en soi. C’est une conséquence d’une maturité acquise. Forcer l’adoption prématurée crée plus de problèmes qu’elle n’en résout.
La bonne approche : Restez en Delivery. Améliorez vos tests, votre observabilité, votre culture. Un jour, vous réaliserez que la validation humaine n’apporte plus de valeur — parce que vos tests détectent tout. Ce jour-là, passez en Deployment. Pas avant.
À retenir
- CI = Valider chaque commit automatiquement. Obligatoire pour toutes les équipes.
- Delivery = Code toujours déployable, déploiement sur décision humaine. Recommandé pour la plupart.
- Deployment = Déploiement automatique en production. Optionnel, exige une maturité élevée.
- Chaque niveau inclut les précédents. Pas de raccourci.
- Le « full CD » prématuré crée plus de problèmes qu’il n’en résout.
Pour aller plus loin
Comprendre les pipelines
- Qu’est-ce qu’une pipeline CI/CD ? — Les concepts fondamentaux (jobs, stages, runners, artefacts)
- Formes modernes de pipelines — Trunk-based, GitFlow et autres topologies
- Bonnes pratiques CI/CD — Build once, deploy many et autres principes éprouvés
- Anti-patterns CI/CD — Les erreurs classiques à éviter
Sécuriser et fiabiliser
- Sécuriser une pipeline CI/CD — Protéger vos workflows contre les attaques
- Confiance implicite vs explicite — Gérer la confiance dans votre chaîne de build
- Pourquoi bloquer ne suffit pas — Gates vs guardrails, l’approche habilitante
- Pourquoi les pipelines échouent — Les causes organisationnelles et culturelles
Passer à la pratique
- GitHub Actions — Introduction et premiers workflows
- GitLab CI/CD — Configuration et bonnes pratiques
Concepts connexes
- Indicateurs DORA — Mesurer la performance de vos déploiements (fréquence, délai, stabilité)
- La boucle de rétroaction — Pourquoi le feedback rapide est essentiel
- GitOps — Quand Git devient la source de vérité pour l’infrastructure
- Gestion des artefacts — Harbor, Nexus, Artifactory pour stocker vos builds