Guide de migration vers le cloud pour les entreprises, de l'évaluation à la bascule

Les entreprises migrent rarement une seule fois. Elles migrent un premier système, en tirent des enseignements, puis migrent les dix suivants. Un guide de migration consigne ces enseignements pour que la deuxième vague soit plus rapide et plus sûre que la première : comment les systèmes sont évalués, à quoi ressemble la landing zone, comment se déroule une bascule et ce que signifie « terminé ». Ce guide est celui qui nous sert de point de départ avec nos clients ; il doit être adapté à votre organisation plutôt que suivi à la lettre.

Deux principes le sous-tendent. Premièrement, migrer la fonction métier plutôt que le serveur : la question est de savoir comment une application et ses données continuent de servir les utilisateurs, et non comment copier une machine virtuelle. Deuxièmement, garder chaque étape réversible jusqu’au moment où elle est délibérément rendue définitive.

Le choix de la région vient en premier. Une région située dans le pays, lorsqu’elle existe, offre plusieurs zones de disponibilité pour la résilience et une faible latence pour les utilisateurs locaux. La région AWS Asie-Pacifique (Bangkok) (ap-southeast-7) en est un exemple : elle offre aux organisations ayant des utilisateurs en Thaïlande un choix qui n’existait pas pendant la majeure partie de l’ère du cloud, au lieu de desservir le pays depuis Singapour. Pour les systèmes sensibles à la latence et pour les organisations dont les politiques ou les régulateurs préfèrent que les données restent dans le pays, une région nationale constitue le point de départ par défaut.

Deux précautions s’imposent. Les régions récentes ne proposent pas tous les services dès leur ouverture ; vérifiez la liste des services de la région pour chaque service managé prévu dans la conception avant de vous engager, et préparez une solution de repli (un autre service, ou une autre région pour ce composant). La résidence des données est par ailleurs une décision de politique avant d’être une décision technique : les lois sur la protection des données personnelles telles que le PDPA autorisent les transferts transfrontaliers sous conditions, et les régulateurs sectoriels, dans les services financiers par exemple, peuvent avoir leurs propres exigences. Consignez par écrit les catégories de données qui doivent rester dans le pays et celles qui peuvent être répliquées à l’étranger pour la reprise après sinistre, et faites-le confirmer par les équipes juridique et conformité. Traduisez-le ensuite en restrictions de région dans les politiques de l’organisation, afin qu’une ressource mal placée soit empêchée plutôt que découverte après coup.

La reprise après sinistre mérite la même clarté. Au sein d’une région, plusieurs zones de disponibilité protègent contre la défaillance d’un site. Pour se prémunir contre un événement régional, décidez si une seconde région est acceptable pour les sauvegardes ou un environnement de secours, laquelle, et quels objectifs de délai et de point de reprise l’entreprise est prête à financer.

Tout ce qui, dans la landing zone, peut être défini sous forme de code doit l’être : comptes et politiques organisationnelles, réseaux et routage, identités et rôles, journalisation et pistes d’audit, clés de chiffrement, politiques de sauvegarde, budgets et alertes. Terraform est notre outil de prédilection, car il est déclaratif, indépendant des fournisseurs et peut être relu dans le même flux de pull requests que le code applicatif.

Quelques pratiques permettent de garder le tout maîtrisable. Stockez l’état à distance avec verrouillage, un état par environnement et par composant logique, afin qu’une erreur à un endroit ne puisse pas en corrompre un autre. Créez de petits modules bien nommés pour les éléments créés de façon répétée (un service avec sa définition de conteneur, sa règle d’équilibreur de charge, son rôle IAM et son groupe de journaux) et versionnez-les. Étiquetez chaque ressource avec son responsable, son environnement, son application et son centre de coûts à partir d’un module d’étiquetage unique, car la maîtrise des coûts en dépendra. Exécutez un plan à chaque modification, exigez une relecture et appliquez depuis un pipeline plutôt que depuis un poste personnel. Détectez les dérives de manière planifiée et traitez les modifications manuelles dans la console comme des incidents à régulariser, et non comme la nouvelle norme.

Résultat : l’environnement de la deuxième vague n’est plus un projet, mais une simple pull request.

Chaque runbook comporte une section consacrée au retour arrière ; peu d’équipes l’ont réellement exécutée. Répétez la bascule complète au moins une fois hors production, avec les mêmes personnes, la même liste de contrôle et un chronomètre, puis répétez le retour arrière. Définissez les critères de go/no-go avant le jour J (quels tests doivent réussir, quelles parties prenantes doivent confirmer, avant quelle heure) et désignez la seule personne qui prend la décision. Fixez explicitement le point de non-retour : le moment à partir duquel de nouvelles transactions n’existent que dans la cible et où revenir en arrière implique de rapprocher les données à la main.

Pendant la bascule réelle, communiquez selon un calendrier fixe plutôt qu’au gré des événements : un point d’étape toutes les trente minutes, même pour indiquer que tout se déroule comme prévu, rassure les métiers et permet à l’équipe de rester concentrée. Ensuite, organisez un bref retour d’expérience tant que les détails sont frais et mettez à jour le guide.