Module 3 — La livraison et le déploiement continus (CD)

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 8 minutes

---

Le Module 2 s’est arrêté à un artefact validé, prêt à être déployé. La CD prend le relais à partir de là.

Le cycle complet de la CD

Artefact validé
     │
     ▼
Déployer sur STAGING (un environnement qui imite la production)
     │
     ▼
Tests de bout en bout (E2E) sur cet environnement réel
     │
     ├── Échec  → "Problèmes détectés" → retour au développement
     │
     └── Succès → Déployer en PRODUCTION
                        │
                        ▼
                  Supervision (logs, monitoring)
                        │
                        ▼
         Nouvelle fonctionnalité / correctif → retour au développement

Pourquoi un environnement de staging ?

Les tests unitaires et d’intégration du Module 2 s’exécutent dans un environnement isolé et simplifié (souvent avec des dépendances simulées). Le staging est un environnement qui reproduit fidèlement la production — même configuration réseau, même base de données (avec des données de test), mêmes services externes (ou leurs équivalents de test) — pour détecter des problèmes qu’un test unitaire ne peut pas voir : un mauvais paramétrage d’infrastructure, une variable d’environnement manquante, une incompatibilité avec une version réelle d’un service tiers.

Les tests de bout en bout (E2E) qui s’y exécutent simulent un parcours utilisateur complet (par exemple, avec un outil comme Playwright ou Cypress pour une application web) plutôt que de tester une fonction isolée.

Le déploiement en production

Une fois le staging validé, le même artefact (jamais reconstruit, voir Module 2) est déployé en production. Quelques stratégies courantes, du plus simple au plus prudent :

Stratégie	Principe	Compromis
Recréation	Arrêter l’ancienne version, démarrer la nouvelle	Simple, mais interruption de service pendant la bascule
Rolling update	Remplacer les instances une par une, progressivement	Pas d’interruption totale, mais les deux versions coexistent brièvement
Blue/Green	Déployer la nouvelle version en parallèle de l’ancienne, basculer le trafic d’un coup	Bascule (et retour arrière) quasi instantanés, mais nécessite le double d’infrastructure pendant la transition
Canary	Envoyer une petite fraction du trafic réel vers la nouvelle version avant de généraliser	Détecte un problème en production sur un impact limité, mais plus complexe à mettre en place

Ce site utilise une stratégie de recréation simple (adaptée à un site statique) — analysé en détail au Module 4.

La supervision : le pipeline ne s’arrête pas au déploiement

Un déploiement réussi ne garantit pas qu’aucun problème ne surviendra en conditions réelles (charge, cas limites non testés, dépendance externe qui change de comportement). La supervision (logs, métriques, alertes) est la boucle de rétroaction qui referme le cycle : elle informe l’équipe d’un problème en production, qui redevient alors un correctif à développer — repartant du Module 1.

Et si le déploiement introduit un problème malgré tout ?

C’est là qu’intervient le rollback (retour en arrière) : redéployer la version précédente, connue comme fonctionnelle. Deux conditions rendent un rollback réellement utilisable en urgence :

• Chaque déploiement correspond à un artefact versionné et conservé (voir Module 2) — revenir en arrière, c’est redéployer l’artefact précédent, pas reconstruire à la volée une ancienne version du code.
• Les migrations de base de données sont réversibles, ou au minimum rétrocompatibles avec la version précédente du code — un rollback de code ne sert à rien si le schéma de base de données a déjà changé de façon incompatible.

À retenir

• La CD ajoute à la CI : un déploiement en staging, des tests de bout en bout sur cet environnement réel, un déploiement en production, et une supervision continue.
• Continuous Delivery garde une validation humaine avant la production ; Continuous Deployment l’automatise aussi (voir Module 1).
• Un plan de rollback n’est utile que s’il a été anticipé avant le déploiement, pas improvisé après incident.

Prochaine étape

Module 4 : Étude de cas réelle — les pipelines de ce site