Le point de départ.
La plateforme on-premise réunissait une interface Vue, deux services Spring Boot, un worker Python Temporal, Temporal, Keycloak, PostgreSQL et MinIO. Elle traitait l’extraction documentaire et des workflows assistés par l’IA, mais les environnements ne partageaient pas un parcours de mise en place fiable.
Parler uniquement de migration cloud aurait décrit la destination, pas le travail. Il fallait déplacer avec méthode les composants avec et sans état, séparer la démonstration de la production et donner aux opérateurs un basculement contrôlé entre deux slots.
J’ai découpé le changement en quatre frontières liées : packaging des workloads, données managées, configuration des environnements et contrôle des releases. Ainsi, « mettre sur Kubernetes » ne pouvait pas devenir toute la conception.
Ce que la conception devait résoudre.
Le nouveau modèle de plateforme devait rendre cinq éléments explicites :
- Les workloads Vue, Spring Boot, Python, Temporal et Keycloak devaient partager un même modèle de déploiement Kubernetes.
- Les responsabilités de PostgreSQL et MinIO devaient passer à Cloud SQL et Cloud Storage sans masquer ce changement derrière d’autres conteneurs.
- L’infrastructure réutilisable devait rester commune, tandis que les valeurs propres à chaque environnement restaient des entrées vérifiables.
- La démonstration et la production exigeaient des contrôles différents parce qu’elles portaient des risques opérationnels différents.
- Le rollout de production nécessitait un slot inactif, des smoke tests et un basculement manuel explicite.
Le diagnostic.
La partie fragile n’était pas un service isolé. C’était le chemin entre le code source et un environnement en fonctionnement. Lorsque ce chemin varie selon l’environnement, chaque modification transporte des hypothèses cachées.
Un simple lift-and-shift aurait reproduit ces hypothèses ailleurs. Exécuter PostgreSQL et MinIO dans le nouveau cluster aurait aussi conservé des responsabilités d’exploitation que Google Cloud pouvait prendre en charge à des frontières managées plus claires.
J’ai donc fait de la reproductibilité et de la réversibilité les exigences centrales. Les modules Terraform définissent la base Google Cloud, Helm package les workloads Kubernetes et les valeurs d’environnement restent séparées des définitions réutilisables.
Le modèle de plateforme obtenu.
GitLab CI lance le parcours de production, Cloud Build produit les images déployables et Artifact Registry conserve la version destinée à GKE. Le déploiement vise le slot blue/red inactif. La readiness Kubernetes et le smoke test doivent réussir avant qu’un opérateur déplace le trafic. Cloud SQL et Cloud Storage remplacent les responsabilités PostgreSQL et MinIO autogérées.
Pourquoi ces technologies convenaient à la migration.
Ces décisions s’inscrivaient dans un produit existant et une destination Google Cloud déjà arrêtée ; elles ne constituaient pas un classement greenfield de toutes les plateformes possibles. La vraie question était de trouver les frontières qui rendaient cet ensemble précis de workloads reproductible et exploitable.
GKE comme frontière commune des workloads
- Pourquoi
- La plateforme réunissait déjà une interface Vue, des services Spring Boot, un worker Python, Temporal et Keycloak. GKE donnait à ces workloads différents un même modèle de déploiement, de readiness et de slots blue/red, tandis que les données managées sortaient du cluster.
- Ce que j’ai écarté
- Répartir les composants entre plusieurs produits serverless aurait imposé plusieurs modèles d’exécution au même parcours de release ; des VM persistantes auraient conservé davantage de configuration et de maintenance propres aux hôtes.
- Ce que cela a coûté
- L’équipe accepte la surface opérationnelle de Kubernetes, le cycle de vie du cluster et la nécessité de rendre explicites les ressources, la readiness et les mises à niveau des workloads.
Des modules Terraform pour la base Google Cloud
- Pourquoi
- Les modules réutilisables regroupaient les définitions communes et exposaient les différences entre environnements sous forme d’entrées visibles et révisables. Cela répondait directement à la configuration propre à chaque environnement que la migration devait supprimer.
- Ce que j’ai écarté
- Une configuration en console ou des templates copiés auraient créé plus vite le premier environnement, mais les changements suivants auraient été moins vérifiables et chaque copie aurait pu diverger seule.
- Ce que cela a coûté
- Les contrats des modules, l’état Terraform et les changements de version des providers exigent de la discipline ; même une petite exception doit être modélisée plutôt que corrigée manuellement en silence.
Helm pour packager les workloads Kubernetes
- Pourquoi
- Helm fournissait une unité de release pour les ressources liées et un emplacement contrôlé pour les valeurs d’environnement, sans copier toute la définition des workloads pour chaque environnement et chaque slot.
- Ce que j’ai écarté
- Des manifestes bruts auraient été plus directs pour un déploiement unique, mais leur duplication entre environnements et slots blue/red aurait rendu plus difficiles à distinguer les changements communs et les écarts volontaires.
- Ce que cela a coûté
- Templates et valeurs ajoutent de l’indirection ; la sortie rendue doit être inspectée et chaque évolution du chart versionnée avec le même soin que le code applicatif.
Des responsabilités séparées entre Cloud Build et GitLab CI
- Pourquoi
- Cloud Build produisait les images dans le parcours Google Cloud, tandis que GitLab CI conservait l’orchestration de production, les vérifications et la décision explicite sur le trafic. Cette séparation reflétait les conséquences différentes de créer un artefact et de le livrer.
- Ce que j’ai écarté
- Une pipeline de déploiement unique et indistincte aurait été plus simple à décrire, mais elle aurait confondu les contrôles de démonstration et de production et couplé build, rollout et basculement du trafic.
- Ce que cela a coûté
- Deux systèmes impliquent des identifiants, des transferts d’artefacts et un diagnostic des erreurs à travers une frontière ; leurs contrats doivent rester alignés.
Règles d’exploitation pour une mise en production réversible.
Le socle technique définit le parcours ; ces règles précisent qui assume l’état, ce qui constitue une preuve et comment faire évoluer la production sans saut irréversible.
Rendre les écarts d’environnement vérifiables
Avant une release, les valeurs propres à l’environnement et les responsabilités liées à l’état sont visibles ensemble, notamment pour les données, la sauvegarde et la reprise. Un écart devient une entrée ou un passage de relais explicite, pas une correction invisible dans un environnement actif.
Le compromisVérifier écarts et responsabilités demande davantage de préparation, mais évite que la dérive de configuration ou une reprise sans responsable n’apparaisse au moment de la bascule.
Vérifier le candidat de bout en bout
Une release est suivie depuis l’image construite jusqu’à l’environnement inactif, puis contrôlée par la readiness, les signaux d’infrastructure et un smoke test. Aucun voyant vert isolé ne représente tout le parcours.
Le compromisCela prend plus de temps que de considérer un build réussi comme une preuve ; le smoke test reste volontairement ciblé et ne prétend pas couvrir tous les parcours métier.
Séparer la preuve sur l’artefact de l’autorité sur le trafic
Un build réussi produit un candidat, mais ne lui ouvre pas la production. Le même artefact est déployé et éprouvé sur le slot blue/red inactif, tandis que la décision de déplacer le trafic reste une action distincte de l’opérateur.
Le compromisCette gouvernance ajoute des passages de relais et exige que les deux slots restent prêts, mais empêche de confondre réussite du build et autorisation de release.
Rendre la bascule explicite et réversible
Le trafic ne se déplace qu’une fois les contrôles visibles et la bascule approuvée par un opérateur. Le slot précédent reste le chemin de retour clair au lieu d’être écrasé en place.
Le compromisCe contrôle introduit une pause volontaire, mais garde visibles l’autorité finale sur la production et le retour arrière lorsque les preuves sont incomplètes.
Livraison et vérification.
J’ai ordonné le travail selon les dépendances et la réversibilité : base Google Cloud, packaging des workloads, externalisation des valeurs d’environnement, déplacement des responsabilités sur les données, puis exercice du parcours de release avant le basculement de production.
La démonstration reste distincte de la production. Cette dernière passe de GitLab CI à Cloud Build et Artifact Registry avant le slot GKE inactif, plutôt que d’écraser l’environnement actif.
La readiness Kubernetes, les alertes Google Cloud et les signaux d’infrastructure sont complétés par un smoke test avant le basculement. Cela ne valide pas chaque parcours métier. Cela établit que le candidat est assez sain pour un cutover contrôlé.
Le résultat livré.
La migration a remplacé un parcours on-premise propre à chaque environnement par des modules d’infrastructure réutilisables, des workloads packagés, des services de données managés et deux slots de production contrôlés.
Le résultat utile n’est pas simplement « fonctionne sur Google Cloud ». C’est un parcours de release révisable avant le déploiement, vérifiable avant le déplacement du trafic et reproductible pour l’environnement suivant.
Je n’associe pas à ce résultat un pourcentage inventé de vitesse ou de fiabilité. Le changement défendable est structurel : moins d’hypothèses propres aux environnements, des responsabilités opérationnelles explicites et une décision de production réversible.
Organisation, produit, endpoints, configuration du stockage, coûts, volumes et dates de livraison sont omis. Les composants et la séquence de livraison proviennent du dossier de projet.