L'art du déploiement continu dans le cloud moderne
Introduction
Le déploiement continu dans le cloud est devenu un standard, mais chaque cloud provider a ses spécificités. En 15 ans, j'ai déployé en continu sur AWS (F2R2, TEKYN, Coopengo, Earny SA), GCP (Okeiro, Earny SA avant migration), Azure (Cardiologs), OVH (KNDS, Metronome), Scaleway (WizOps.fr) et Outscale (Bloomflow SecNumCloud). Voici les patterns qui fonctionnent partout et les pièges spécifiques à chaque provider.
Le déploiement continu sur AWS avec EKS et Fargate
Chez F2R2, l'architecture AWS multi-comptes utilisait EKS Fargate pour le compute. Fargate supprime la gestion des nodes : chaque pod a son propre micro-VM isolée. Le pipeline GitHub Actions buildait les images Docker, les pushait sur ECR, mettait à jour le tag dans le chart Helm, et ArgoCD synchronisait le cluster EKS. Le déploiement d'un nouveau service prenait environ 90 secondes (provisionnement Fargate + pull de l'image + readiness check). L'avantage : pas de capacity planning, pas de gestion de node groups. L'inconvénient : coût supérieur de 30% par rapport aux EC2 équivalents, et un cold start de 30 secondes qui nécessite un minimum de 2 replicas pour les services critiques.
Le déploiement continu sur GCP avec GKE Autopilot
Chez Okeiro en e-santé, nous avions choisi GKE Autopilot sur le cloud souverain S3NS. Le concept est similaire à Fargate : Google gère les nodes, la facturation se fait au pod. Le déploiement continu utilisait ArgoCD avec Workload Identity pour l'authentification (pas de service account keys). Le Helm chart FHIR que j'ai développé se déployait automatiquement à chaque merge. L'avantage de GKE Autopilot : la sécurité est renforcée par défaut (pods non-root obligatoires, PodSecurityStandards enforced). L'inconvénient : moins de flexibilité sur les configurations de nodes, et des profils de ressources imposés par Autopilot qui peuvent ne pas correspondre à tous les workloads.
Le déploiement continu multi-cloud
Chez Bloomflow, avec des clients sur AWS, GCP, OVH et Outscale (SecNumCloud), le déploiement continu devait être agnostique du cloud. J'ai standardisé l'approche : Helm charts identiques quel que soit le provider, ArgoCD pour le GitOps, et des values files par cloud/client qui adaptaient les spécificités (StorageClass, Ingress Controller, annotations de load balancer). Le pipeline CI produisait une image Docker unique, pushée sur un registry multi-régions. ArgoCD sur chaque cluster déployait la même image avec la configuration adaptée. Cette abstraction a permis de supporter 4 cloud providers sans dupliquer les pipelines, un gain opérationnel considérable.
La gestion des rollbacks automatiques
Le rollback automatique est la dernière ligne de défense du déploiement continu. Chez Earny SA, lors de la migration GCP vers AWS, chaque déploiement était surveillé par un Prometheus qui vérifiait le taux d'erreur 5xx et la latence P95 pendant 5 minutes post-déploiement. Si les seuils étaient dépassés, une alerte déclenchait un rollback ArgoCD vers la version précédente. Ce mécanisme a sauvé la mise 2 fois en 3 mois : une fois pour un problème de driver PostgreSQL incompatible, et une fois pour un memory leak dans une dépendance mise à jour. Le rollback complet prenait moins de 2 minutes, contre les 30 minutes qu'aurait pris un rollback manuel.
Le déploiement continu en contexte souverain
Les contraintes de souveraineté ajoutent une couche de complexité au déploiement continu. Chez Bloomflow, pour un client DGE nécessitant SecNumCloud, les images Docker devaient être stockées dans un registry Outscale (pas GHCR ni ECR). Le pipeline CI pushait d'abord sur GHCR, puis un job de synchronisation copiait l'image vers le registry souverain. ArgoCD sur le cluster Outscale ne pullait que depuis le registry local. Chez KNDS, la contrainte allait plus loin : le pipeline CI devait s'exécuter sur des runners dans un réseau isolé, sans accès Internet sortant. Les dépendances étaient pré-cachées dans un mirror interne. Ces contraintes rallongent le setup initial de 2 à 3 semaines mais n'impactent pas la vélocité une fois en place.
Conclusion
Le déploiement continu dans le cloud moderne requiert une approche adaptable. Les fondamentaux sont les mêmes (GitOps, ArgoCD, monitoring post-déploiement), mais chaque cloud provider et chaque contexte réglementaire apportent des spécificités. La clé est de standardiser au maximum (Helm charts, pipeline CI) tout en permettant la personnalisation par cloud et par client. Cette approche, éprouvée sur 6 cloud providers différents, garantit des déploiements fiables quel que soit le contexte.