Combien de votre infrastructure pensez-vous devoir réécrire pour sortir d’AWS ? Si la réponse qui vous vient ressemble à « presque tout », vous n’êtes pas seul. C’est précisément la phrase que j’entends au premier rendez-vous, et elle fige les décisions, parfois pendant des années. Dans les faits, la plus grosse part d’une infrastructure se déplace sans qu’on touche au code applicatif. Tout le travail consiste à débusquer le reste.
La majeure partie d’une infra quitte AWS sans toucher au code : VM, conteneurs, bases relationnelles, stockage objet. Ce qui coince, ce sont les services maison bien enracinés, avec Lambda et DynamoDB en tête, qu’il faut repérer et chiffrer avant de déplacer la moindre charge.
Commençons par ce qui part tel quel, car la liste est plus longue qu’on ne le craint. Une machine virtuelle Linux ou Windows se redéploie ailleurs : pas de réécriture, du transfert. Les conteneurs, eux, sont portables par construction, c’est même leur seule raison d’exister. Les bases relationnelles comme PostgreSQL ou MySQL gardent le même moteur, vous bougez la donnée et c’est réglé. Quant au stockage objet, l’API S3 est devenue un standard de fait que Scaleway parle, comme beaucoup d’autres. Pour toutes ces briques, on configure et on transfère, sans une ligne de développement. Sur un client industriel l’an dernier, ces quatre catégories couvraient à elles seules autour de 80 % de la facture mensuelle. Le gros est parti en quelques semaines. Sans réveil nocturne.
Le vrai sujet, ce sont les services maison qui se sont infiltrés partout. Les fonctions serverless arrivent en premier : le code se récupère, certes, mais les déclencheurs, le découpage en événements et la facturation à l’invocation sont pensés pour AWS et nulle part ailleurs. DynamoDB est souvent plus douloureux encore, parce qu’aucun équivalent direct ne vous tend les bras. Là, on repart de zéro. Il faut choisir une cible, remodeler le schéma, parfois revenir au relationnel. Quand le modèle de données a été dessiné autour des contraintes de Dynamo, ce chantier n’a plus rien d’une case à cocher. Restent les files et bus d’événements spécifiques, qu’on repose sur une brique standard, ainsi qu’IAM (le service AWS qui gère qui a le droit de faire quoi sur l’infrastructure), dont la logique de droits et de rôles ne s’exporte pas mais se reconstruit. Rien d’insurmontable là-dedans, simplement du travail long et méticuleux, qu’on sous-estime systématiquement parce qu’il ne se voit pas dans le code métier.
Pour chacun de ces points, je mets un chiffre en face. La sortie coûte parfois trois jours ; ailleurs, elle justifie de laisser tourner un bout de service dans AWS encore quelques mois, le temps de traiter le reste sans précipitation. Garder un pied dedans n’a rien d’un échec, c’est une étape. Et tout cela suppose une seule discipline : ne pas déménager en bloc, qui reste le meilleur moyen de tout casser un vendredi. J’inventorie les dépendances, je sépare ce qui part tel quel de ce qui accroche, je chiffre chaque accroche, puis on décide ensemble de l’ordre. Les charges simples filent d’abord, elles prouvent que la démarche tient et allègent la facture immédiatement. Les accroches suivent. Une à une, chacune avec son budget.
Un cas récent résume bien tout ça. Une équipe d’une dizaine de personnes, persuadée d’en avoir pour six mois de réécriture, paralysée depuis un an par cette estimation. On a cartographié leur infra sur deux jours. Bilan : l’écrasante majorité partait sans toucher au code, et trois fonctions serverless concentraient à elles seules toute la difficulté. On a déplacé le reste en six semaines, puis on s’est attaqué aux trois fonctions tranquillement, budget en main. Les six mois redoutés n’ont jamais existé : ils vivaient dans une phrase, pas dans l’infrastructure.