Pourquoi quitter AWS quand tout fonctionne
La question la plus fréquente qu’on nous pose : “Pourquoi migrer si votre infra AWS tourne ?” La réponse tient en trois mots : coûts, données, IA.
Ce retour d’expérience concerne un retailer premium européen — 200M EUR de CA en ligne, une quarantaine de microservices, 15 développeurs, une facture AWS qui dépassait les 45K EUR/mois et une volonté stratégique d’investir massivement dans l’IA.
Le constat était simple : BigQuery et Vertex AI offraient un avantage décisif pour leurs cas d’usage data et IA. Mais migrer un système de production qui traite 2 millions de commandes par an, ce n’est pas un side project du vendredi.
La phase 0 : cadrer avant de toucher au code
Nous avons passé 6 semaines en cadrage pur avant d’écrire la première ligne de Terraform. C’est la partie que tout le monde veut sauter. C’est aussi celle qui détermine le succès ou l’échec.
L’inventaire exhaustif
Première étape : cartographier tout ce qui tourne sur AWS. Pas seulement les services que l’équipe connaît — ceux qu’on a oubliés aussi.
On a découvert :
- 3 lambdas orphelines qui traitaient encore du trafic
- Un bucket S3 de 8 To dont personne ne connaissait le contenu
- Des Security Groups ouverts en 0.0.0.0/0 sur des environnements de staging “temporaires” depuis 2 ans
- 14 instances RDS dont 5 en t3.micro qui ne servaient plus
Leçon : vous ne pouvez pas migrer ce que vous ne connaissez pas. L’audit initial est non négociable.
La matrice de décision service par service
Chaque service AWS a été évalué selon trois axes :
- Équivalent GCP natif — existe-t-il un service managé équivalent ?
- Effort de migration — S (jours), M (semaines), L (mois)
- Risque business — impact si ça casse en production
Le résultat : une roadmap en 4 vagues sur 12 mois (qui en a finalement pris 18).
La migration en 4 vagues
Vague 1 : les fondations (mois 1-3)
Objectif : réseau, IAM, CI/CD, monitoring.
On a commencé par le socle — VPC, Cloud Interconnect, IAM avec Workload Identity Federation, et la migration du pipeline CI/CD de CodePipeline vers Cloud Build.
Erreur commise : vouloir reproduire la topologie réseau AWS à l’identique sur GCP. Les deux clouds ont des philosophies réseau différentes. GCP est global par défaut (un VPC couvre toutes les régions), AWS est régional. Nous avons perdu 3 semaines à essayer de mapper des concepts qui ne se mappent pas.
Leçon : adoptez les paradigmes du cloud cible. Ne traduisez pas — repensez.
Vague 2 : les données (mois 3-7)
Objectif : migrer les bases de données et le stockage.
C’est la vague la plus critique et la plus lente. Nous avons migré :
- RDS PostgreSQL → Cloud SQL : migration relativement directe avec DMS puis pglogical pour la réplication en continu
- DynamoDB → Firestore : refactoring nécessaire — les modèles de données ne sont pas interchangeables
- S3 → Cloud Storage : le plus simple, gsutil transfer a fait le travail
- ElastiCache Redis → Memorystore : quasi transparent
Le point de douleur : DynamoDB vers Firestore. Les deux sont NoSQL mais avec des philosophies radicalement différentes. Le modèle de requêtes, les index, la pagination — tout a dû être repensé. Comptez le double du temps estimé pour toute migration de base NoSQL.
Vague 3 : les applications (mois 7-13)
Objectif : migrer les microservices de ECS/EKS vers GKE.
Bonne nouvelle : les conteneurs sont portables. Mauvaise nouvelle : tout ce qui tourne autour ne l’est pas.
Les Dockerfiles n’ont pas bougé. Mais les Helm charts, les configurations d’autoscaling, les health checks, les politiques réseau — tout a été revu. GKE Autopilot a simplifié beaucoup de choses par rapport à EKS, mais le passage a nécessité de requalifier chaque service.
La stratégie : Strangler Fig Pattern appliqué à l’infrastructure. Un load balancer global (Cloud Load Balancing) routait le trafic vers AWS ou GCP service par service. Chaque microservice migré était d’abord exposé en canary (5% du trafic), puis progressivement basculé.
Vague 4 : l’IA et la data (mois 13-18)
Objectif : la raison initiale de la migration — exploiter BigQuery et Vertex AI.
C’est la phase où l’investissement a commencé à payer. La migration du data lake vers BigQuery a réduit les coûts analytiques de 60% par rapport à Athena + Redshift. Et Vertex AI a permis de déployer des modèles de recommandation produit qui auraient nécessité 3x plus d’effort sur SageMaker pour ce cas d’usage spécifique.
Le bilan financier honnête
Soyons transparents sur les chiffres :
| Poste | Montant |
|---|---|
| Facture AWS avant migration | 45K EUR/mois |
| Facture GCP après migration | 32K EUR/mois |
| Coût du projet de migration | ~380K EUR (18 mois, équipe dédiée) |
| Économie mensuelle | 13K EUR/mois |
| ROI atteint | Mois 29 (~2.5 ans) |
Le ROI pur sur les coûts d’infrastructure n’est pas spectaculaire. Ce qui a justifié le projet, c’est la vélocité gagnée sur les sujets data et IA — des projets qui auraient pris 6 mois sur AWS ont été livrés en 2 mois sur GCP grâce à BigQuery et Vertex AI.
Les 5 leçons que nous retenons
-
Cadrez deux fois, migrez une fois. Les 6 semaines de cadrage initial ont évité des mois de retravail. C’est notre méthode chez Les Artisans du Digital : on ne touche pas au code tant que l’architecture cible n’est pas validée.
-
Migrez par strangulation, pas par big bang. Le Strangler Fig Pattern est la seule approche viable pour un système en production. Le big bang weekend est un mythe dangereux.
-
Les données sont le goulot d’étranglement. Les conteneurs se déplacent facilement. Les données, non. Prévoyez le double du temps estimé pour les migrations de bases de données.
-
Budgetez la double facturation. Pendant 12 mois, vous payez les deux clouds. C’est inévitable. Intégrez-le dans le business case dès le départ.
-
Formez les équipes en parallèle. Nos développeurs ont suivi les certifications GCP pendant la Vague 1. Au moment de migrer les applications, ils étaient opérationnels. Ne sous-estimez jamais la courbe d’apprentissage.
FAQ
Faut-il forcément migrer tout vers un seul cloud ?
Non. Le multi-cloud est une réalité légitime pour certaines organisations — notamment quand des acquisitions amènent des stacks différentes ou quand des contraintes réglementaires l’imposent. Mais le multi-cloud par choix “pour éviter le vendor lock-in” coûte plus cher en complexité opérationnelle qu’il ne protège. Notre recommandation : un cloud primaire, avec des cas d’usage secondaires justifiés.
Combien de temps d’indisponibilité faut-il prévoir ?
Avec une approche Strangler Fig correctement exécutée : zéro downtime perçu par les utilisateurs. Chaque service est migré indépendamment avec basculement progressif. Les seuls moments critiques sont les migrations de bases de données, qui nécessitent des fenêtres de maintenance (généralement la nuit, 30 minutes à 2 heures selon le volume).
GCP est-il vraiment moins cher qu’AWS ?
Ça dépend du profil de charge. GCP est généralement moins cher sur le compute (les CUDs sont plus agressifs que les Reserved Instances AWS) et significativement moins cher sur le stockage et l’analytique (BigQuery vs Redshift). AWS reste compétitif sur le serverless (Lambda vs Cloud Functions) et l’écosystème de services managés. La vraie réponse : faites un FinOps comparatif sur vos workloads réels, pas sur les grilles tarifaires.
Peut-on faire cette migration sans arrêter les développements ?
C’est obligatoire. Un gel de développement de 18 mois est impensable pour un business e-commerce. La stratégie : les nouvelles features sont développées sur le cloud cible dès la Vague 2. Les features existantes continuent de tourner sur AWS jusqu’à leur migration. Cela demande une discipline d’architecture rigoureuse, mais c’est la seule approche viable en production.