L’an dernier, une PME e-commerce me confie sa migration vers Scaleway. La veille de la bascule, je demande à l’équipe interne comment on revient si la nuit tourne mal. Silence. Personne n’avait la réponse, et tout le monde la croyait évidente. On a repoussé la bascule de huit jours pour la trouver. Bien nous en a pris : le jour J, un bug applicatif a corrompu quelques paniers, on est revenus à l’ancienne base en quelques minutes, sans perdre une seule commande. Ma procédure, étape par étape.
Une migration sérieuse se défait à chaque étape : on garde l’ancien environnement debout jusqu’à ce que le nouveau ait encaissé une charge réelle, on avance par vagues qui s’annulent une à une, et on sait d’avance comment ramener les données vers l’ancien si on doit reculer.
1. Écrire le critère de retour, en amont. Pas pendant la nuit de bascule, pas « à l’instinct ». Un seuil chiffré, une heure limite. Tant que ce n’est pas posé noir sur blanc et accepté par le client, je ne planifie même pas de date.
2. Garder l’ancien environnement debout. On n’éteint rien tant que le nouveau n’a pas encaissé une vraie charge. J’ai vu une équipe décommissionner son ancien serveur le lendemain d’une bascule, fière d’avoir fait propre, puis se mordre les doigts quand le batch de facturation de fin de mois a planté côté neuf. Plus aucun environnement vers qui se replier. Le doublon, c’est quelques dizaines d’euros par jour chez Scaleway ; le décommissionnement trop tôt, c’est une nuit blanche et la confiance du client.
3. Découper en vagues qui s’annulent isolément. On ne déplace pas l’application, la base, le DNS et les jobs cron d’un seul geste un vendredi soir. Les services sans état (ceux qui ne stockent rien en propre et peuvent donc être déplacés ou recréés sans rien perdre) partent en premier, ils se rebasculent sans douleur. Puis le trafic, déporté par paliers (10 %, 50 %, en surveillant les métriques à chaque cran). La base et le DNS ferment la marche, parce que ce sont les deux endroits où reculer fait mal.
4. Préparer la synchronisation inverse, et la tester. Sur ce point, presque tout le monde bâcle. Tant que la nouvelle base reste en lecture seule, reculer ne coûte rien. Mais à la première écriture, revenir suppose de ramener ces écritures vers l’ancienne, faute de quoi vous perdez les commandes passées depuis la bascule. Chez cette PME, on avait maintenu une réplication logique active dans les deux sens pendant 48 h — chaque base recopiant ses écritures vers l’autre en continu, la nouvelle réécrivant donc vers l’ancienne. Cette resync, le canal de retour des données, était prête une semaine avant ; le jour du bug, il a suffi de l’enclencher.
5. Défendre le coût du doublon. Deux environnements en parallèle quelques jours, ça se chiffre : l’infra dupliquée plus le temps de tenir la réplication. C’est précisément ce poste que les directions veulent rogner, en réclamant de « gagner deux jours sur la migration ». Là, je refuse, et j’explique pourquoi avec un chiffre. Le doublon est dérisoire face à une bascule ratée sans issue de secours : service à l’arrêt en pleine journée, données coincées dans deux états incohérents. Et l’équipe qui débogue à l’aveugle pendant que le support croule sous les appels.
Sur cette migration, le doublon a tourné six jours. Facture Scaleway du sursis : 41 euros.