CI/CD : automatiser tout ce qui se passe entre le commit et la production
Ou : Comment remplacer « ça marchait sur ma machine » par « ça marche partout, automatiquement »
Le vendredi à 17h. Un développeur fait un [git](/glossaire/developpement-web/git/) push et rentre chez lui. Lundi matin, le site est down. Le déploiement a échoué silencieusement, le code ne compile pas sur le serveur, et personne n’a remarqué pendant le week-end.
Le CI/CD — Continuous Integration / Continuous Deployment — existe pour que ce scénario ne se produise jamais. C’est l’automatisation de tout ce qui se passe entre le moment où un développeur pousse du code et le moment où ce code est en production : compilation, tests, analyse de qualité, déploiement.
CI et CD : deux concepts, un pipeline
L’intégration continue (CI)
La CI (Continuous Integration) est la pratique de fusionner le code de tous les développeurs dans une branche commune plusieurs fois par jour, avec à chaque merge une vérification automatique :
- Build — le code compile-t-il ?
- Tests — les tests unitaires et d’intégration passent-ils ?
- Linting — le code respecte-t-il les conventions de style ?
- Sécurité — y a-t-il des dépendances vulnérables ?
Si une étape échoue, le pipeline s’arrête et le développeur est notifié. Le code ne peut pas être fusionné tant que le pipeline est rouge.
Le déploiement continu (CD)
Le CD prolonge la CI jusqu’à la production :
- Continuous Delivery — le code est prêt à être déployé à tout moment, mais un humain appuie sur le bouton.
- Continuous Deployment — le code est déployé automatiquement en production dès que le pipeline CI est vert. Pas de bouton, pas d’intervention humaine.
Les outils
| Outil | Type | Particularité |
|---|---|---|
| GitHub Actions | Cloud, intégré à GitHub | Gratuit pour les projets open source |
| GitLab CI | Cloud ou self-hosted | Intégré à GitLab, très complet |
| Jenkins | Self-hosted | Vétéran, très configurable, complexe |
| CircleCI | Cloud | Rapide, bonne UX |
Le dialogue du pipeline cassé
DevOps Dave : Le pipeline CI met 45 minutes. Les développeurs le contournent en poussant directement sur main.
Security Sarah : Donc vous avez un pipeline CI que personne n’utilise. C’est pire que de ne pas en avoir — ça donne une fausse impression de sécurité.
DevOps Dave : Mais les tests sont importants !
Security Sarah : Alors optimise le pipeline. Parallélise les tests, cache les dépendances, supprime les tests flaky. Un pipeline CI doit passer en 5-10 minutes max. Au-delà, les développeurs le contournent. C’est la nature humaine.
Tableau récapitulatif
| Concept | En une phrase |
|---|---|
| CI | Intégration continue — vérifier automatiquement chaque changement de code. |
| CD | Déploiement continu — livrer automatiquement le code vérifié en production. |
| Pipeline | Séquence d’étapes automatisées (build → test → deploy). |
| Tests automatisés | Tests exécutés automatiquement à chaque commit — le filet de sécurité. |
Le mot de la fin
Le CI/CD est la différence entre « déployer c’est stressant » et « déployer c’est un non-événement ». Les équipes matures déploient en production des dizaines de fois par jour — parce que chaque déploiement est petit, testé, et réversible. Les équipes sans CI/CD déploient une fois par mois, le vendredi, en croisant les doigts.