Le problème que le CI/CD résout
Résumé : jusqu'aux années 2000, livrer un logiciel signifiait accumuler six mois de travail, tout fusionner d'un coup, tester à la main pendant deux semaines, puis déployer un vendredi soir en espérant que rien ne casse. Cette leçon détaille les cinq problèmes structurels de cette approche, et pourquoi ils rendaient l'amélioration continue impossible.
1. Le monde d'avant — la release semestrielle
Voici à quoi ressemblait un cycle de livraison typique dans une entreprise en 2005.
Le point important : ce n'était pas de l'incompétence. C'était l'état de l'art dans une industrie qui n'avait pas encore les outils pour faire autrement.
2. Les cinq problèmes structurels
Chacun de ces problèmes se nourrit des autres, créant un cercle vicieux.
Le problème 5 est le plus insidieux. C'est un cercle vicieux qui s'auto-renforce : la peur de déployer réduit la fréquence, ce qui augmente le risque, ce qui augmente la peur. Le CI/CD casse ce cercle en inversant le sens de la boucle.
3. Le coût réel de détecter un bug tard
Il existe une règle empirique bien documentée en g énie logiciel : plus un défaut est détecté tard, plus il coûte cher à corriger.
Conclusion directe : toute l'économie du CI/CD repose sur rapprocher la détection du défaut du moment où il a été écrit. C'est le principe du shift left — décaler la validation vers la gauche de la chronologie.
4. Un scénario réaliste — le vendredi qui dérape
Illustrons avec un incident concret, du genre que beaucoup d'équipes ont vécu.
Ce que révèle cet incident : ce n'est pas la migration qui est le vrai problème, c'est le fait qu'elle n'ait jamais été jouée automatiquement contre un jeu de données réaliste. Un pipeline de CI/CD correctement conçu aurait exécuté cette migration des dizaines de fois avant vendredi soir.
5. Ce que le CI/CD change concrètement
Le CI/CD ne consiste pas seulement à installer un outil. Il renverse la logique de la livraison.
C'est le point contre-intuitif le plus important du CI/CD : déployer plus souvent rend le système plus stable, pas moins. C'est exactement l'inverse de l'intuition de la plupart des managers, et c'est un résultat solidement établi par les recherches DORA.
6. Les six problèmes que le CI/CD résout directement
7. Les chiffres qui illustrent l'écart
Voici l'écart mesuré entre les équipes les plus performantes et les moins performantes, selon les rapports DORA publiés chaque année depuis 2014.
| Indicateur | Équipes élite | Équipes en difficulté | Écart |
|---|---|---|---|
| Fréquence de déploiement | Plusieurs fois par jour | Entre 1 et 6 mois | ×1000 et plus |
| Délai commit → production | Moins d'une heure | Entre 1 et 6 mois | ×1000 et plus |
| Taux d'échec des changements | 0 à 15 % | 46 à 60 % | ×4 |
| Temps de rétablissement | Moins d'une heure | Plus d'une semaine | ×100 et plus |
Le constat frappant : les équipes qui déploient le plus souvent sont aussi celles dont les déploiements échouent le moins. Vitesse et stabilité ne s'opposent pas — elles progressent ensemble.
Ces quatre indicateurs sont les métriques DORA, détaillées dans la leçon 6.
Retenir en 30 secondes
- Avant le CI/CD, les équipes livraient tous les 3 à 6 mois, dans la douleur.
- Cinq problèmes structurels : intégration tardive, feedback lent, gros lots de changements, déploiement artisanal, peur du déploiement.
- Un bug détecté en production coûte environ 100 fois plus cher qu'un bug détecté à l'écriture.
- Le CI/CD inverse le cercle vicieux : automatiser rend le déploiement banal, donc fréquent, donc petit, donc peu risqué.
- Contre-intuitif mais démontré : déployer plus souvent rend le système plus stable.
- Les équipes élite déploient plusieurs fois par jour avec un taux d'échec quatre fois inférieur.
Suivant : CI, livraison continue, déploiement continu : trois notions distinctes →