CI, Delivery, Deployment
Trois pratiques, trois niveaux d'automatisation.
On fait du CI/CD. Vous avez sûrement entendu cette phrase. Mais que cache-t-elle ? Derrière ce terme fourre-tout se tiennent trois pratiques distinctes : l'intégration continue (Continuous Integration), la livraison continue (Continuous Delivery) et le déploiement continu (Continuous Deployment). Oui, les deux dernières partagent le même sigle — c'est la source de beaucoup de confusion. Et non, ce n'est pas qu'une question de vocabulaire : le niveau d'automatisation choisi engage votre culture d'équipe, vos exigences de tests et le risque que vous acceptez de porter.
En bref
La CI valide le code. La Delivery le rend déployable. Le Deployment le met en production automatiquement. Plus on automatise, plus les exigences de qualité montent.
Vue d'ensemble : les trois niveaux
Les trois pratiques ne s'opposent pas : elles se contiennent. Chacune reprend la précédente et pousse la chaîne un cran plus loin.
Une seule chaîne, trois portées. Chaque niveau inclut le précédent : il n'y a pas de raccourci.
À retenir
On ne fait pas de Delivery sans CI, ni de Deployment sans Delivery. C'est une progression, pas un choix entre trois options.
Intégration continue : la base obligatoire
L'intégration continue est le socle sur lequel tout repose. Le principe : valider chaque modification dès qu'elle est poussée, avant qu'elle ne rejoigne la branche principale.
Ce qui se passe sans CI
Une équipe de cinq personnes, chacune sur sa branche. Alice pousse du code
lundi : il compile chez elle. Bob pousse le sien mardi : il compile chez lui.
Vendredi, on fusionne : plus rien ne compile. Les deux contributions étaient
incompatibles, mais personne ne pouvait le savoir. Avec la CI, Alice l'apprend
cinq minutes après son push — pas cinq jours plus tard.
Ce que fait une pipeline CI
À chaque commit ou demande de fusion, la pipeline exécute automatiquement :
| Contrôle | Question à laquelle il répond |
|---|---|
| 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 (style, formatage) ? |
| Scan de sécurité | y a-t-il des vulnérabilités connues dans les dépendances ? |
Cinq contrôles, cinq questions — et un verdict unique : la branche est fusionnable, ou non.
Pourquoi c'est non négociable
Le coût de correction d'un défaut explose avec le temps. Un bug détecté au moment du commit coûte quelques minutes le même bug découvert en production peut coûter des jours.
Plus la détection est tardive, plus la correction est chère — la CI ramène le retour à gauche de la courbe.
La CI inverse cette pente : le retour arrive en minutes, et la personne corrige pendant qu'elle a encore le contexte en tête.
Les règles d'or
Quatre règles, sans exception
- Chaque commit déclenche la CI — pas de « je pousse vite fait sans tester ».
- Un échec bloque la fusion — aucun code cassé n'atteint la branche principale.
- Les tests sont rapides — moins de dix minutes au-delà, les développeurs contournent le système.
- Le retour est immédiat — notification directe à l'auteur du commit, pas un tableau de bord que personne ne consulte.
Livraison continue : prêt à déployer, sur demande
La livraison continue prolonge la CI. Le code n'est plus seulement validé : il est prêt à partir en production à tout moment. Mais un humain décide quand appuyer sur le bouton.
Après la CI, la pipeline construit un artefact immuable — image Docker, binaire, paquet qui ne changera plus —, le déploie en environnement de test, exécute des tests de bout en bout (parcours d'achat, inscription, scénarios utilisateurs complets), puis attend une validation : technique, métier, ou les deux.
Pourquoi garder une validation humaine
Ce n'est pas un aveu de faiblesse. Dans plusieurs contextes, c'est la décision rationnelle.
| Contexte | Ce que la porte humaine protège |
|---|---|
| Métier | la fonctionnalité doit sortir en même temps qu'une annonce une pipeline ne lit pas le calendrier marketing |
| Environnement régulé | santé, finance, aéronautique : chaque mise en production doit être documentée et approuvée — c'est la loi, pas un choix technique |
| Confiance en construction | la couverture de tests n'est pas encore suffisante la validation est un filet temporaire, le temps de la renforcer |
| Coordination externe | le déploiement touche des partenaires ou des clients qu'il faut prévenir, parfois attendre |
Quatre bonnes raisons de garder la main sur le dernier pas.
À retenir
Avec la Delivery, le code est toujours déployable. La question n'est plus « peut-on déployer ? » mais « veut-on déployer maintenant ? ».
Déploiement continu : 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. Concrètement, une demande de fusion approuvée à 14 h 03 tourne devant de vrais utilisateurs à 14 h 08, sans que personne ait cliqué sur « déployer ».
Les prérequis, et ils sont stricts
- 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 doit être couvert.
- Drapeaux de fonctionnalité (feature flags) — déployer du code désactivé, puis couper une fonctionnalité qui pose problème sans redéployer. C'est un interrupteur, pas une machine à remonter le temps.
- Retour arrière automatique — si les métriques se dégradent après un déploiement (erreurs 500 en hausse, latence qui explose), la pipeline revient seule à la version précédente. On n'attend pas qu'un humain se réveille à 3 h du matin.
- Observabilité avancée — détecter un problème en secondes, pas en heures : alertes sur les métriques clés, tableaux de bord temps réel, logs centralisés.
- Culture sans blâme — avec des déploiements automatiques, les incidents arrivent. S'ils se soldent par la recherche d'un coupable, plus personne n'ose fusionner.
Qui le pratique vraiment
| Équipe | Rythme de déploiement en production |
|---|---|
| Netflix | plusieurs milliers de déploiements par jour |
| Amazon | un déploiement toutes les 11 secondes (chiffre historique de 2015) |
| Etsy | pionnier du déploiement continu depuis 2010 |
| GitHub | plusieurs centaines de déploiements par jour |
Des ordres de grandeur souvent cités — et rarement remis dans leur contexte.
Ce que ces chiffres ne disent pas
Ces équipes ont derrière elles des années d'investissement dans leurs pipelines, leurs tests et leur culture. Le déploiement continu n'est pas un point de départ : c'est une destination.
Comparaison côte à côte
| Aspect | Intégration | Livraison | Déploiement |
|---|---|---|---|
| Déclencheur | commit ou demande de fusion | fusion dans main | fusion dans main |
| Artefact produit | optionnel | obligatoire | obligatoire |
| Vers le staging | optionnel | obligatoire | obligatoire |
| Vers la production | non | sur décision humaine | automatique |
| Retour arrière | sans objet | manuel | automatique |
| Exigence de tests | unitaires | bout en bout | bout en bout, puis déploiement progressif |
| Délai avant production | sans objet | heures à jours | minutes |
| Intervention humaine | aucune | validation finale | aucune |
Les trois niveaux, ligne à ligne — la colonne de droite ne s'obtient qu'après les deux autres.
Comment choisir son niveau
Étape 1 — installer la CI (obligatoire)
Sans CI, c'est la priorité absolue : aucune équipe ne devrait fusionner du code sans validation automatisée. L'objectif minimal tient en trois points — chaque demande de fusion déclenche une pipeline, les tests unitaires bloquent la fusion quand ils échouent, le retour arrive en moins de dix minutes. Tant que ce n'est pas en place, le reste peut attendre.
Étape 2 — évoluer vers la Delivery (recommandé)
Une fois la CI stabilisée, ajoutez la construction d'artefacts immuables (images Docker, binaires versionnés), le déploiement automatique en staging après chaque fusion, des tests de bout en bout sur cet environnement, et une validation humaine avant la production.
À retenir
C'est le niveau de maturité suffisant pour la grande majorité des équipes. La validation humaine n'est pas un échec : c'est souvent la bonne réponse.
Étape 3 — envisager le Deployment (optionnel)
Avant de se lancer, quatre questions, à se poser honnêtement.
| Axe | Question |
|---|---|
| Tests | la couverture dépasse-t-elle 80 % sur les chemins critiques ? |
| Détection | un problème en production est-il visible en moins de cinq minutes ? |
| Retour arrière | existe-t-il un mécanisme de retour automatique à la version précédente ? |
| Culture | l'équipe traite-t-elle les incidents sans chercher de coupable ? |
Une seule réponse négative suffit : restez en livraison continue.
Le déploiement continu viendra naturellement quand les fondations seront solides.
Le piège du « full CD »
Certaines équipes veulent « faire du déploiement continu » pour cocher une case, ou parce que « Netflix le fait » — sans en avoir les prérequis. Le résultat est prévisible : des bugs en production tous les jours des développeurs qui craignent de fusionner, donc fusionnent moins souvent, ce qui aggrave encore les conflits des retours arrière manuels en urgence le vendredi soir et, au bout, une perte de confiance dans la pipeline — « de toute façon, ça casse toujours ».
Le déploiement continu n'est pas un objectif
C'est la conséquence d'une maturité acquise. Forcer son adoption crée plus de problèmes qu'elle n'en résout. La bonne approche : rester en livraison continue, améliorer les tests, l'observabilité et la culture. Un jour, la validation humaine n'apportera plus rien parce que les tests détecteront tout. Ce jour-là, et pas avant, passez au déploiement continu.
À retenir de cette séance
Intégration continue : valider chaque commit automatiquement — obligatoire pour toute équipe. Livraison continue : code toujours déployable, déploiement sur décision humaine — recommandé pour la plupart. Déploiement continu : mise en production automatique — optionnel, et exigeant. Chaque niveau inclut les précédents : pas de raccourci.
Réponse unique
Quelle pratique produit un code toujours déployable, la mise en production restant déclenchée par un humain ?
Indice · Reste-t-il un bouton à presser ?
[ METTRE EN PRATIQUE ]
Situer son équipe sur les trois niveaux
3 étapes · 30 min · 110 XP
[ CETTE LEÇON DANS LES PARCOURS ]
- Ingénieur DevOpsétape 16 / 23suivant — Anatomie d'un pipeline →