L'importance du déploiement continu dans l'écosystème DevOps
Le déploiement continu : pourquoi c'est devenu non-négociable
Il y a 10 ans, déployer une fois par mois était la norme. Aujourd'hui, les équipes que j'accompagne déploient plusieurs fois par jour. Ce changement de rythme n'est pas un caprice technologique : c'est une nécessité business. Plus vous déployez souvent, plus vous réduisez le risque de chaque déploiement, et plus vite vous livrez de la valeur aux utilisateurs.
Le déploiement continu chez Bloomflow : de 0 à plusieurs fois par jour
Quand j'ai rejoint Bloomflow, les déploiements étaient manuels et hebdomadaires. Un ingénieur prenait 30 minutes pour dérouler une procédure de 15 étapes. Parfois il oubliait une étape, parfois le déploiement échouait à mi-chemin et il fallait tout rollbacker manuellement.
En mettant en place Kubernetes multi-providers (AWS, Scaleway, Outscale), ArgoCD pour le GitOps, et des pipelines GitHub Actions pour le CI, nous avons atteint un rythme de 2-3 déploiements par jour. Chaque merge dans main déclenchait automatiquement le build, les tests, le push de l'image et le déploiement. Le temps total : 8 minutes du commit à la production. Zéro intervention humaine.
Les prérequis que personne ne mentionne
Le déploiement continu ne fonctionne que si trois conditions sont réunies. Premièrement, des tests automatisés fiables. Sans eux, déployer automatiquement revient à jouer à la roulette russe. Chez Coopengo, nous avons investi 3 mois dans la construction d'une suite de tests d'intégration solide avant d'activer le déploiement automatique.
Deuxièmement, un mécanisme de rollback instantané. Chez tous mes clients K8s (KNDS, F2R2, Earny SA, Padam Mobility), le rollback via ArgoCD se fait en revertant un commit Git. C'est rapide (moins de 2 minutes), traçable, et ne nécessite aucune connaissance spéciale de Kubernetes.
Troisièmement, un monitoring post-déploiement. Chez Bloomflow, chaque déploiement était suivi d'un smoke test automatique (vérification des health endpoints) et les métriques Prometheus étaient surveillées pendant 10 minutes pour détecter toute anomalie (hausse du taux d'erreurs, augmentation de la latence).
L'impact sur la qualité logicielle
Contre-intuitivement, déployer plus souvent améliore la qualité. La raison est simple : chaque déploiement contient moins de changements, donc moins de risques. Identifier la source d'un bug dans un déploiement de 3 commits est infiniment plus facile que dans un déploiement de 50 commits.
Chez Coopengo, le passage de déploiements hebdomadaires à quotidiens a réduit le nombre d'incidents en production de 60%. Les incidents qui se produisaient étaient résolus en moyenne 4 fois plus vite grâce à la traçabilité des changements.
Le déploiement continu sur différents clouds
Chaque cloud provider a ses spécificités pour le déploiement continu. Sur AWS (F2R2, TEKYN, Earny SA), le pipeline utilise ECR pour les images et EKS pour le déploiement. Sur GCP (Okeiro), Artifact Registry et GKE Autopilot. Sur OVH Cloud (KNDS, Metronome), le registre Docker OVH et le Managed Kubernetes.
La constante : ArgoCD comme orchestrateur de déploiement. Quel que soit le cloud, ArgoCD surveille le repo Git et synchronise le cluster. Cette abstraction est précieuse car elle permet de changer de provider sans modifier le processus de déploiement.
Mon conseil pour démarrer
Ne cherchez pas à tout automatiser d'un coup. Commencez par automatiser le build et les tests (CI). Une fois que c'est stable et fiable, ajoutez le déploiement automatique en staging. Quand l'équipe est confiante, étendez au déploiement en production avec un mécanisme d'approbation. Enfin, supprimez l'approbation manuelle quand les tests et le monitoring sont suffisamment matures. Cette progression sur 3-6 mois est bien plus efficace qu'un big bang.