Le point de départ.
La plateforme réunissait plusieurs composants pour le traitement documentaire et des workflows assistés par l’IA. Ses environnements ne partageaient pas une voie de configuration fiable. Un déploiement correct à un endroit pouvait rester difficile à reproduire ailleurs.
Parler uniquement de migration cloud aurait décrit la destination, pas le travail. Il fallait remplacer une infrastructure et des étapes ponctuelles par un modèle lisible, vérifiable et reproductible.
Ce que la conception devait résoudre.
Le nouveau modèle de plateforme devait rendre quatre éléments explicites :
- Plusieurs composants applicatifs devaient suivre la même logique de livraison.
- Les différences entre environnements devaient devenir de la configuration, pas du travail manuel non documenté.
- Les changements d’infrastructure devaient être visibles avant d’atteindre un environnement actif.
- Les workloads applicatifs et les services cloud managés avaient besoin d’une frontière opérationnelle claire.
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.
J’ai fait de la reproductibilité l’exigence centrale. Les définitions d’infrastructure, les workloads du cluster et les valeurs d’environnement devaient avoir des responsabilités séparées, tout en suivant la même voie de livraison.
Le modèle de plateforme obtenu.
GitLab CI/CD fournit le chemin de livraison. Terraform définit la base Google Cloud, GKE porte la couche de workloads et les services managés prennent en charge les responsabilités de plateforme qui n’appartiennent pas aux conteneurs applicatifs.
Les décisions importantes.
La migration est devenue fiable grâce à des frontières assumées.
Réutiliser les modules, varier les entrées
Terraform réutilisable maintient une base cohérente. Les valeurs propres à chaque environnement restent des entrées visibles plutôt que des copies d’infrastructure.
Cette approche impose des contrats de modules plus stricts. C’est précisément là que la rigueur est utile.
Un modèle d’exécution commun
GKE donne aux composants applicatifs une cible de déploiement cohérente et permet de raisonner ensemble sur leur configuration d’exécution.
Un modèle de cluster partagé exige toujours une responsabilité claire pour les namespaces, la configuration et les déploiements.
Choisir les services managés
Les services managés Google Cloud retirent aux workloads certaines responsabilités de plateforme lorsque cette frontière est pertinente.
Le gain opérationnel s’accompagne de choix propres au fournisseur, qui doivent rester visibles dans l’architecture.
Livraison et vérification.
Le modèle place les changements d’infrastructure et de workloads sur une voie inspectable dans GitLab CI/CD. Terraform rend l’état cloud attendu vérifiable ; le modèle GKE donne une cible commune aux composants.
La vérification suit la même frontière : d’abord la définition d’infrastructure, puis les ressources de plateforme, enfin les workloads. Cette séquence facilite la localisation d’un échec par rapport à un script différent pour chaque environnement.
Le résultat qualitatif.
L’infrastructure et la livraison suivent désormais un chemin reproductible et traçable. La plateforme peut être abordée comme un système, pas comme une collection d’exceptions propres aux environnements.
Le résultat le plus utile n’est pas seulement l’exécution sur Google Cloud. Le chemin vers un environnement fonctionnel est codifié, vérifiable et cohérent.