CI/CD
Ensemble de pratiques DevOps automatisant l'intégration du code (CI) et son déploiement en production (CD), via des pipelines de build, tests et livraison continue.
CI/CD (Continuous Integration / Continuous Delivery ou Deployment) désigne l'ensemble des pratiques et outils DevOps qui automatisent l'intégration du code source, son test et son déploiement en production via des pipelines programmables. 83% des équipes de développement utilisent des pipelines CI/CD en 2024, et les équipes qui les adoptent déploient 208 fois plus fréquemment selon le rapport DORA.
Définition technique
Intégration continue (CI)
La CI automatise la compilation, les tests et la validation du code à chaque commit poussé sur le repository. Le pipeline typique exécute : checkout du code, installation des dépendances, compilation (build), tests unitaires, tests d'intégration, analyse statique (linting), et scan de sécurité (SAST). En cas d'échec, le développeur est notifié immédiatement et le merge est bloqué.
L'objectif est de détecter les régressions au plus tôt : un bug découvert en CI coûte 10x moins cher qu'en production. Les pratiques clés incluent : commits fréquents (plusieurs fois par jour), branche principale toujours verte (tous les tests passent), et builds rapides (< 10 minutes pour maintenir le flow de développement).
Livraison et déploiement continus (CD)
La livraison continue (Continuous Delivery) garantit que le code est toujours dans un état déployable. Le pipeline CD ajoute : construction d'artefacts (images Docker, packages), déploiement en environnement de staging, tests end-to-end, et validation manuelle avant production. Le déploiement continu (Continuous Deployment) supprime l'étape manuelle : chaque commit validé est automatiquement déployé.
Les stratégies de déploiement avancées incluent : blue-green (deux environnements identiques, bascule instantanée), canary (déploiement progressif sur un pourcentage du trafic), et feature flags (activation/désactivation de fonctionnalités sans déploiement).
Enjeux actuels
CI/CD et vibe coding
Le vibe coding rend la CI/CD plus critique que jamais. Le code généré par IA peut contenir des failles de sécurité, des régressions ou des dépendances vulnérables que seul un pipeline automatisé détecte systématiquement. En due diligence technique, l'absence de CI/CD sur un projet « vibe codé » est un signal d'alarme majeur : cela signifie que le code généré par IA est déployé sans vérification automatisée.
Sécurité du pipeline (DevSecOps)
Le pipeline CI/CD est lui-même une surface d'attaque. L'injection de code malveillant dans le pipeline (compromission de dépendances, secrets exposés dans les logs) peut compromettre toute la chaîne de production. Le framework SLSA (Supply-chain Levels for Software Artifacts) définit des niveaux de maturité pour sécuriser les pipelines, de la traçabilité basique des builds (niveau 1) à l'isolation complète des environnements de build (niveau 4).
Standards et spécifications
DORA Metrics
Quatre métriques clés de performance DevOps : fréquence de déploiement, lead time, MTTR, taux d'échec
SLSA (Supply-chain Levels for Software Artifacts)
Framework de sécurité pour la chaîne de production logicielle et les pipelines CI/CD
Questions fréquentes
Quelle est la différence entre CI, CD (delivery) et CD (deployment) ?
L'intégration continue (CI) automatise la compilation et les tests à chaque commit : le code est fusionné fréquemment (plusieurs fois par jour) dans une branche partagée, avec feedback immédiat en cas d'erreur. La livraison continue (Continuous Delivery) garantit que chaque version est toujours prête à être déployée en production, avec une validation humaine avant la mise en ligne.
Le déploiement continu (Continuous Deployment) va plus loin : chaque commit qui passe tous les tests est automatiquement déployé en production, sans intervention humaine. Netflix, Amazon et Etsy utilisent le déploiement continu avec des centaines de déploiements par jour. La plupart des entreprises s'arrêtent à la livraison continue avec une approbation manuelle.
Quels outils de CI/CD utiliser ?
Les plateformes cloud dominent : GitHub Actions (intégré à GitHub, gratuit pour open source), GitLab CI (intégré à GitLab, pipeline-as-code), CircleCI (performance, parallélisation), et Jenkins (open source, auto-hébergé, 300+ plugins). Les solutions cloud-native incluent AWS CodePipeline, Google Cloud Build et Azure DevOps.
Le choix dépend de l'écosystème : GitHub Actions pour les projets GitHub, GitLab CI pour les entreprises utilisant GitLab, Jenkins pour le contrôle total. Les pipelines modernes utilisent des containers (Docker) pour garantir la reproductibilité et la portabilité des builds.
Pourquoi la CI/CD est-elle un critère de due diligence ?
L'absence de CI/CD est un red flag en due diligence technique. Un projet sans pipeline automatisé dépend de déploiements manuels (« on pousse sur main »), ce qui augmente le risque d'erreurs, de régressions et de failles de sécurité non détectées. Les projets « vibe codés » sans CI/CD sont particulièrement risqués car le code généré par IA n'est jamais vérifié automatiquement.
En due diligence, on vérifie : l'existence et le contenu du pipeline (build, tests, linting, SAST), la couverture de tests réelle (pas seulement le pourcentage gonflé par l'IA), le temps de build (< 10 minutes est sain), et le taux d'échec des déploiements (< 5% pour les équipes performantes selon DORA).