Intégration Continue et Déploiement Continu : Les Fondamentaux
Introduction
CI/CD : deux acronymes que j'entends quotidiennement depuis 10 ans. Mais entre la théorie et la pratique terrain, il y a un gouffre. Voici les fondamentaux du CI/CD tels que je les pratique, avec des exemples issus de mes missions les plus marquantes.
L'intégration continue en pratique
L'intégration continue, c'est le réflexe de merger son code souvent et de le valider automatiquement. Chez Bloomflow, chaque développeur poussait son code plusieurs fois par jour. Le pipeline GitHub Actions (lint, typecheck, tests, build) donnait un verdict en moins de 5 minutes. Si le verdict était rouge, le merge était bloqué. Pas de négociation, pas d'exception. Chez Coopengo, le passage d'intégrations hebdomadaires a quotidiennes a réduit les conflits de merge de 80%. Les outils varient (Jenkins chez Coopengo et Cardiologs, GitHub Actions chez Epiconcept et Bloomflow, GitLab CI ponctuellement), mais le principe est universel : intégrer souvent, tester automatiquement, corriger immédiatement.
Tests automatisés : le socle de confiance
Sans tests automatisés, le CI n'a aucune valeur — c'est juste du merge automatique. Chez Bloomflow, trois niveaux de tests : unitaires (a chaque commit, 30 secondes), intégration (a chaque PR, 3 minutes avec Testcontainers), end-to-end (avant release, 15 minutes). Sur WizOps.fr, 51 tests Vitest couvrent le rendu des pages, les interactions API, les composants. Chez KNDS, les tests de sécurité (scan Trivy, validation des NetworkPolicies) s'ajoutaient aux tests fonctionnels. L'automatisation des tests transforme la confiance de "j'espère que ca marche" a "j'ai la preuve que ca marche".
Gestion des configurations : le point souvent négligé
La gestion des configurations est cruciale et souvent sous-estimée. Chez Epiconcept, Ansible garantissait que dev, staging et production étaient identiques. Chez F2R2, les 25 modules Terraform versionnés dans Git définissaient l'état exact de l'infrastructure AWS. Les secrets sont gérés séparément : Vault chez Bloomflow et KNDS, External Secrets sur Kubernetes chez WizOps.fr, GitHub Secrets dans les pipelines. Le principe : tout dans Git (sauf les secrets qui passent par un gestionnaire dédié). Chez Okeiro, les configurations Helm du chart FHIR étaient versionnées avec des valeurs par environnement — zéro configuration manuelle.
Déploiement continu : quand la confiance est acquise
Le CD est la suite logique de la CI, mais il exige que les tests soient fiables. Sur WizOps.fr, chaque merge sur main déploie automatiquement en production via ArgoCD sur Scaleway Kubernetes. Chez Bloomflow, ArgoCD synchronisait automatiquement les manifestes Kubernetes. Chez Padam Mobility, les environnements de dev se créaient et se détruisaient automatiquement avec les branches Git. Chez Earny SA, le CD a permis la migration GCP vers AWS sans downtime : deux pipelines parallèles, un switch DNS progressif. Docker et Kubernetes rendent le CD fiable grace a l'isolation des containers et aux rolling updates.
Surveillance et feedback continu
Le CD ne s'arrete pas au déploiement. Chez Metronome, Prometheus et Grafana surveillaient les métriques post-déploiement en temps réel. Chez SFR Business Team, c'était déja Prometheus et Grafana pour Docker Swarm. Sur WizOps.fr, Sentry capture les erreurs backend Django. Chez Bloomflow, OpenTelemetry tracait chaque requete a travers les microservices. Le feedback continu ferme la boucle : déployer, observer, détecter, corriger, redéployer. Chez F2R2, GuardDuty et WAF complétaient la surveillance avec une couche sécurité. Cette boucle de feedback est ce qui transforme un pipeline en un système vivant.
Conclusion
Les fondamentaux du CI/CD sont simples : intégrer souvent, tester automatiquement, configurer via du code, déployer sans intervention humaine, surveiller en permanence. La complexité est dans l'exécution et l'adaptation au contexte. Après plus de 100 projets, ces principes restent les memes — seuls les outils et les contraintes changent.