L'intégration continue et le déploiement automatisé
Introduction
L'automatisation du déploiement est la suite logique de l'intégration continue. Mais la transition de "mon code passe les tests" à "mon code est en production" est un saut qui effraie beaucoup d'organisations. Voici comment j'ai accompagné cette transition dans des contextes où l'erreur n'était pas une option.
Le déploiement automatisé en contexte santé (HDS)
Chez Coopengo, en environnement certifié HDS, le déploiement automatisé devait respecter des contraintes strictes : traçabilité complète, approbation obligatoire, et rollback garanti. J'ai conçu un pipeline en deux phases. Phase 1 (automatique) : le merge dans main déclenchait le build, les tests, le scan de sécurité et le déploiement en staging. Phase 2 (semi-automatique) : un SRE vérifiait les métriques de staging pendant 30 minutes puis approuvait la promotion en production via un label GitHub. Le déploiement en production était alors automatique via ArgoCD. Cette approche satisfaisait les auditeurs HDS (approbation humaine traçable) tout en minimisant le travail manuel.
Le déploiement automatisé en contexte défense
Chez KNDS, les contraintes étaient encore plus strictes. Le pipeline de déploiement s'exécutait sur des runners isolés dans un réseau privé. Les images Docker étaient scannées deux fois : une fois dans le pipeline CI et une fois par un scanner indépendant avant l'admission dans le cluster. Le déploiement en production nécessitait deux approbations (développeur lead + SRE). Les secrets étaient injectés via OKMS (le KMS d'OVH), sans transit en clair dans le pipeline. Malgré ces contraintes, le délai entre un merge et la production était de 45 minutes, contre 2 semaines avec l'ancien processus de déploiement par ticket. L'automatisation et la sécurité ne sont pas incompatibles.
Le zero-downtime deployment en pratique
Le déploiement sans interruption de service est une promesse de Kubernetes qui nécessite une configuration soignée. Chez Bloomflow, j'avais identifié 3 sources de downtime lors des déploiements : les connexions en cours interrompues (résolu avec terminationGracePeriodSeconds de 30 secondes et un signal SIGTERM bien géré par l'application), le trafic envoyé à des pods pas encore prêts (résolu avec une readiness probe qui vérifiait le chargement complet de l'application), et les migrations de base de données avec lock (résolu avec des migrations non-bloquantes en deux phases : ajout de colonne nullable, puis migration des données, puis contrainte NOT NULL). Après ces corrections, les déploiements étaient invisibles pour les utilisateurs, mesurés par un monitoring synthétique qui faisait des requêtes toutes les secondes.
L'automatisation des rollbacks
Le rollback automatique est la soupape de sécurité du déploiement automatisé. Chez Earny SA, j'ai configuré un Progressive Delivery avec Argo Rollouts : 5% du trafic vers la nouvelle version, analyse automatique des métriques Prometheus (taux d'erreur < 1%, latence P95 < 500ms) pendant 5 minutes, puis progression à 25%, 50%, 100%. Si à n'importe quel palier les métriques dégradaient, rollback automatique en 30 secondes. En 3 mois, ce mécanisme s'est déclenché 2 fois, évitant 2 incidents en production. Les développeurs ont gagné en confiance : ils savaient que le pire qui pouvait arriver était un rollback transparent pour les utilisateurs, pas un incident.
L'automatisation de bout en bout pour les produits WizOps
Sur mes propres produits (WizStatus.com, WizArmor.com, MongoAdmin.dev), l'automatisation est totale : un push sur main déclenche les tests, le build, le push de l'image, et le déploiement via ArgoCD, le tout en moins de 5 minutes. Le monitoring WizStatus surveille ses propres déploiements (c'est le moniteur qui se monitore lui-même). Cette boucle fermée est le niveau ultime de l'automatisation : le produit qui assure sa propre qualité de déploiement. C'est aussi un laboratoire où j'expérimente les pratiques que je déploie ensuite en mission.
Conclusion
Le déploiement automatisé est accessible à toute organisation, même les plus régulées. La clé est de calibrer le niveau d'automatisation au contexte : totalement automatique pour les environnements de développement, semi-automatique avec approbation pour la production dans les secteurs régulés, et systématiquement couplé à un monitoring post-déploiement et un rollback automatique. L'automatisation ne supprime pas le contrôle humain, elle le déplace vers la supervision et l'approbation.