Module 1 — Qu'est-ce que CI/CD ?

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

Le cycle de vie sans automatisation

Avant de parler de CI/CD, regardons ce que ce cycle remplace. Un développeur modifie du code localement, puis :

Développement local (repo local)
   Fichiers modifiés → suivis par git (staged changes)
                      → figés dans un commit
                      → poussés (push) vers le dépôt partagé

Jusqu’ici, rien n’a encore été vérifié : le code pourrait ne pas compiler, casser une fonctionnalité existante, ou introduire une faille de sécurité — personne ne le sait encore. Historiquement, cette vérification était manuelle : un développeur (ou pire, un testeur, bien plus tard) exécutait les tests à la main, souvent seulement avant une mise en production planifiée, parfois des semaines après l’écriture du code. Les problèmes étaient donc découverts tard, coûteux à corriger, et difficiles à relier au changement qui les avait causés.

CI/CD désigne l’ensemble des pratiques et outils qui automatisent cette vérification et cette mise en production, à chaque changement, de façon systématique et rapide.

Le cycle complet, avec CI/CD

Développer → Modifications trackées (git) → Commit → Push
                                                        │
                                          ─ ─ ─ ─ ─ ─ ─ ┼─ ─ ─ ─ ─ ─ ─  (frontière : dépôt local / CI-CD)
                                                        │
                                          Tests de bout en bout (E2E)
                                          [ c'est ici que la CI se déclenche ]
                                                        │
                                                    Déploiement
                                          [ c'est ici que la CD se déclenche ]
                                                        │
                                                        ▼
                                              retour à Développer

Chaque étape de cette chaîne se déclenche automatiquement l’une après l’autre, ou en parallèle — c’est précisément pour cette raison qu’on appelle ça un pipeline.

CI, Continuous Delivery, Continuous Deployment : 3 sigles, 3 périmètres différents

C’est la confusion la plus fréquente autour de CI/CD — les gens disent souvent « CD » sans préciser laquelle des deux notions ils veulent dire, alors qu’elles n’ont pas le même niveau d’automatisation.

Sigle	Nom complet	Ce qu’il garantit
CI	Continuous Integration (Intégration continue)	Chaque changement de code est automatiquement construit et testé, pour vérifier qu’il s’intègre correctement avec le reste du projet.
CD	Continuous Delivery (Livraison continue)	En plus de la CI, chaque changement qui passe les tests est automatiquement empaqueté et prêt à être déployé — mais le déploiement en production reste déclenché manuellement (un humain valide).
CD	Continuous Deployment (Déploiement continu)	Va plus loin que la Livraison continue : chaque changement qui passe les tests est déployé automatiquement, sans validation humaine.

Continuous Integration  : build + test automatiques
Continuous Delivery     : + empaquetage automatique, déploiement encore manuel
Continuous Deployment   : + déploiement automatique aussi (aucune étape manuelle)

La différence entre Delivery et Deployment tient donc à une seule question : le passage en production nécessite-t-il encore un clic humain ? Beaucoup d’équipes pratiquent la Continuous Delivery (elles gardent volontairement un point de validation manuel avant la production, souvent pour des raisons réglementaires ou de gestion du risque métier) sans pratiquer le Continuous Deployment complet — les deux sont légitimes, et le choix dépend du contexte, pas d’un niveau de maturité supérieur ou inférieur.

Pourquoi cette automatisation compte

Détection précoce : un test qui échoue est visible en quelques minutes après le commit qui l’a cassé, pas des semaines plus tard — le correctif est immédiat car le contexte du changement est encore frais.
Cohérence : le même pipeline s’exécute pour chaque changement, de la même façon, sans dépendre de la rigueur (ou de la fatigue) d’un humain qui suivrait une check-list.
Rapidité de mise en production : un changement validé peut atteindre la production en quelques minutes plutôt qu’à l’occasion de la prochaine fenêtre de déploiement planifiée.
Confiance : une suite de tests qui passe de façon fiable donne à l’équipe la confiance nécessaire pour déployer plus souvent, avec moins de stress par déploiement (car chaque déploiement représente un changement plus petit).

Ce que vous allez construire dans ce cours

Ce cours n’est pas que de la théorie : au Module 4, nous analyserons les vrais pipelines qui font déjà tourner ce site et ses dépôts compagnons — des workflows GitHub Actions réels, déjà exécutés avec succès, pas des exemples fictifs. Et au Module 2, nous exécuterons réellement chaque étape d’un pipeline de CI (lint, tests, build) sur un petit projet, y compris en provoquant volontairement des échecs pour observer ce qu’un pipeline détecte concrètement.

Prochaine étape

Module 2 : L’intégration continue (CI) en détail