De Heroku à AWS sans interruption, avec 14 M$ traités par mois
Migration de Heroku vers AWS en 14 semaines sans interruption : −35 % de coût d’infrastructure, −93 % de temps de déploiement, +800 % de fréquence.
Le client traite environ 14 M$ de transactions par mois, soit plus de 180 000 transactions pour quelque 900 commerçants (TPE et PME) aux États-Unis et au Canada. Toute la plateforme tournait sous la forme d’une application Ruby on Rails monolithique sur Heroku, et cette architecture était devenue le premier frein de l’entreprise.
Les problèmes se chiffraient. Chaque déploiement imposait un redémarrage complet de 38 minutes, autorisé seulement deux fois par semaine dans une fenêtre de maintenance. Un déploiement raté avait provoqué une panne de 47 minutes en heure de pointe et environ 62 000 $ de transactions échouées. Heroku ne permettait pas de dimensionner les composants séparément : les pics de reporting de fin de mois obligeaient à monter en charge toute l’application. Les coûts avaient atteint 14 200 $ par mois et augmentaient de 8 à 12 % chaque mois. Enfin, un seul bug, où qu’il soit, pouvait tout faire tomber : une erreur de formatage dans le reporting avait un jour bloqué la file des paiements pendant 23 minutes, ce qui avait coûté deux prospects grands comptes.
La contrainte du CTO était absolue : pas de fenêtre de migration, aucune perturbation visible pour les commerçants. La migration devait se faire sous le trafic de paiement réel.
Tout a commencé par une évaluation de l’infrastructure, pour 6 000 $ : revue du code Rails (environ 85 000 lignes), cartographie du schéma de 47 tables (dont 12 de plus d’un million de lignes) et traçage des requêtes. Ce traçage a montré que les requêtes de reporting consommaient 60 % du CPU de la base de données en fin de mois, alors que le chemin de paiement lui-même affichait une latence p99 de 340 ms. Nous avons recommandé le modèle strangler fig (« figuier étrangleur ») : extraire les services un par un, faire tourner l’ancien et le nouveau en parallèle, basculer le trafic progressivement. L’ordre d’extraction suivait le risque : notifications, reporting, onboarding, webhooks, et le cœur des paiements en dernier.
Les semaines 3 et 4 ont posé les fondations avant toute extraction : chaque ressource AWS décrite dans Terraform, une chaîne CI/CD GitHub Actions avec analyse de sécurité et déploiements blue-green sur EKS, et une pile d’observabilité Datadog installée dès le départ pour détecter en quelques secondes tout écart entre l’ancien et le nouveau système.
Les extractions à faible risque ont occupé les semaines 5 à 8. Le service de notifications a tourné en parallèle pendant 5 jours avec un taux d’écart de 0,00 % avant la bascule. Le déplacement du reporting vers un réplica en lecture a fait passer le CPU de la base principale de 78 % à 31 % et, par effet de bord, la latence p99 des paiements de 340 ms à 180 ms. Le cœur des paiements a été migré en dernier, avec la plus grande prudence : 48 heures de trafic dupliqué (shadow traffic) sur 12 000 transactions avec 0,00 % d’écart, puis une bascule progressive de 1 % à 100 % du trafic sur 10 jours, avec un plan de retour arrière testé à chaque étape. La semaine 14 s’est conclue par des runbooks, un transfert de connaissances et un game day de 3 heures consacré à l’injection de pannes.
Mesuré sur les 90 premiers jours après la migration, par rapport aux 90 jours précédents : la durée d’un déploiement est passée de 38 minutes à 2,5 minutes par service (−93 %), la fréquence des déploiements de 2 à 18 fois par semaine (+800 %), le coût mensuel d’infrastructure de 14 200 $ à 9 230 $ (−35 %) et la latence p99 des paiements de 340 ms à 145 ms (−57 %). Les requêtes de reporting de fin de mois, qui prenaient 12 à 45 secondes, n’en prennent plus que 2 à 8 (−82 %). Interruptions non planifiées : 70 minutes avant, aucune après. Interruption pendant la migration elle-même : aucune.
Avec une croissance du volume de 15 % par trimestre, les coûts Heroku auraient atteint 22 000 $ par mois en fin d’année. L’architecture AWS est projetée à 11 500 $ par mois pour le même volume, soit une économie annuelle croissante de plus de 120 000 $. La migration de 74 000 $ est amortie en 14,8 mois par les seules économies d’infrastructure, sans compter la disparition d’un risque de panne à 62 000 $ par incident.
Le client a conservé un ingénieur DevOps de Gigabit dans le cadre d’un contrat SRE continu, à 5 500 $ par mois. Sa feuille de route actuelle prévoit un déploiement multirégion, un pipeline de détection de fraude en temps réel et une infrastructure pour SOC 2 Type II.
Trois prestataires nous ont présenté une proposition pour cette migration. Deux proposaient un « lift and shift » de 12 mois avec un week-end de bascule. Gigabit a proposé une approche strangler fig en 14 semaines, avec la garantie de ne subir aucune interruption. Ils ont livré exactement ce qu’ils avaient promis : pas un seul commerçant n’a remarqué que la migration avait eu lieu. Nous sommes passés de deux déploiements par semaine à plusieurs par jour. Rien que cela a changé la vitesse à laquelle nous livrons du produit.
Nos études de cas publiées sont majoritairement nord-américaines. Tous les montants sont en dollars US. Le client est anonymisé.
