Retour d’expérience : comment Plecto a migré sa plateforme cloud-to-cloud d’AWS vers Scaleway

Migrer une plateforme de production complète d’AWS vers Scaleway est toujours un pari ambitieux. Pour Plecto, scale-up européenne spécialisée dans le suivi de performance et l’engagement des équipes, ce projet n’a pas seulement été un défi technique : il a aussi représenté une opportunité stratégique de moderniser sa stack et de reprendre le contrôle de ses coûts. Accompagnée par Scaleway et Kaliop, l’équipe a mené à bien une migration cloud-to-cloud réussie, qui combine FinOps et transformation DevOps.

Le point de départ : une facture AWS trop lourde

Historiquement hébergée sur AWS, la plateforme de Plecto s’appuyait sur des services managés comme Kinesis, RDS et des machines virtuelles pour ElasticSearch, ainsi qu’un socle applicatif déployé avec peu d’automatisation. Avec la croissance rapide de ses utilisateurs, les coûts se sont envolés : les bases de données constituaient un poste de dépense majeur, et certains services restaient facturés malgré un usage nul.

Au-delà de la dimension financière, l’équipe technique était confrontée à des processus de déploiement manuels et à un manque d’Infrastructure as Code (IaC), ce qui limitait la scalabilité et augmentait la dette technique.

Pour Plecto, il devenait indispensable d’optimiser ses investissements avec une approche FinOps, tout en transformant son architecture pour soutenir sa croissance.

Le rôle de Scaleway et la décision de migrer

Fin 2024, Plecto se rapproche de Scaleway. Le fournisseur cloud européen propose une combinaison d’IaaS et de PaaS, assortie d’un modèle de consommation compétitif et de mécanismes pour limiter la double facturation pendant la transition. Rapidement, Scaleway associe Kaliop pour concevoir et exécuter la migration.
L’idée initiale de migrer progressivement les comptes clients, est écartée : les interdépendances techniques rendaient cette option trop risquée. La seule stratégie viable était une bascule complète, mais précédée d’un important travail de préparation pour sécuriser chaque étape.

Une préparation minutieuse, puis une bascule finale

La première étape a consisté à moderniser le socle technique. Le flux temps réel a été déplacé de Kinesis vers Kafka grâce à un double envoi temporaire, permettant de valider les performances avant bascule.
En parallèle, l’architecture a été repensée pour s’appuyer sur Kubernetes. Les déploiements ont été automatisés via GitHub, l’utilisation de registries Scaleway pour les images Docker et ArgoCD pour la partie déploiement continu. Cette transition vers l’IaC a apporté scalabilité et résilience, tout en réduisant la dépendance aux interventions manuelles.
Enfin, la migration complète a été réalisée lors d’un week-end planifié. Les bases de données, ElasticSearch, Redis et le reste de l’application ont été basculés en un bloc, après des tests intensifs de synchronisation et de restauration. L’interruption de service a été contenue dans la fenêtre prévue, garantissant une reprise rapide et sans perte de données.

Optimisations après migration

La migration n’était pas la fin du projet. Une série d’optimisations a été déployée dans les semaines suivantes. La compression des messages Kafka a réduit le volume des données par un facteur de trois à quatre. En parallèle, une partie du code applicatif a été corrigée, diminuant le nombre de messages et améliorant la performance globale.
Côté monitoring, une stack d’observabilité complète a été mise en place : Thanos pour le stockage longue durée des métriques, Loki pour les logs et Grafana pour la visualisation en temps réel. Les développeurs disposent désormais d’une visibilité de bout en bout, un atout essentiel pour anticiper les problèmes et ajuster la plateforme via des dashboards et un alerting adapté.
Sur le plan FinOps, la migration a été opérée sur un dimensionnement volontairement généreux afin de limiter les risques lors de la bascule. Grâce à la supervision fine et aux optimisations continues, l’infrastructure a ensuite été ajustée pour atteindre un coût final divisé par deux par rapport à AWS.

Lessons learned : ce que Plecto retient de cette migration

L’expérience de Plecto apporte plusieurs enseignements précieux :

• Un audit préalable est incontournable : il révèle des interdépendances invisibles et permet d’ajuster la stratégie.
• Valider les briques critiques avant la bascule est essentiel : le double flux Kinesis/Kafka a joué un rôle décisif.
• Migrer, c’est transformer : passer aux conteneurs et à Kubernetes a permis d’industrialiser l’infrastructure.
• Un one-shot doit être préparé comme une opération chirurgicale : la réussite repose sur les tests de synchronisation et des scénarios de repli solides.
• L’optimisation continue est la clé : les gains de performance et de stabilité se concrétisent surtout après la migration.

En migrant d’AWS vers Scaleway, Plecto a divisé par deux ses coûts d’infrastructure tout en gagnant en performance et en fiabilité. La plateforme repose désormais sur une architecture modernisée, basée sur Kubernetes, de l’Infrastructure as Code, et bénéficie d’une observabilité complète.
Ce projet illustre qu’une migration cloud-to-cloud n’est pas seulement un changement d’hébergeur : c’est une opportunité de repenser son architecture, d’adopter des pratiques DevOps et FinOps, et de construire un socle technique plus résilient et évolutif.