Les questions à poser à un partenaire de migration cloud

Demandez comment il saura ce que vous exploitez vraiment

Un plan de migration ne vaut que par l'inventaire sur lequel il repose. Demandez au partenaire comment il le construira : par des entretiens avec les responsables d'applications, à partir des données d'infrastructure comme les métriques des serveurs et les connexions réseau, à partir du code lui-même, ou des trois à la fois. La documentation existante est un point de départ, pas une preuve, car elle s'éloigne peu à peu de ce qui tourne réellement.

Demandez ce que l'inventaire contiendra et à qui il appartiendra ensuite. Une bonne réponse nomme les champs et confirme que l'inventaire vous reste acquis, quelle que soit la suite.

• Chaque application, son responsable métier et son niveau de criticité
• Les environnements d'exécution, frameworks et systèmes d'exploitation, en signalant tout ce qui est en fin de vie
• Les bases de données, partages de fichiers, tâches planifiées et files de messages dont dépend chaque application
• Les intégrations dans les deux sens, y compris celles que personne n'a documentées
• Les licences liées au matériel ou au nombre de processeurs, qui ne se transposent pas forcément au cloud
• Les interruptions acceptables et le calendrier métier : clôtures mensuelles, pics d'activité, échéances réglementaires

Attendez une stratégie par application, pas une seule pour tout le parc

Les applications ne passent pas toutes au cloud de la même façon. Les options habituelles sont de la réhéberger telle quelle (lift and shift), de la replatformer avec de petits changements comme une base de données managée, de la refactorer pour utiliser des services cloud, de la remplacer par un produit SaaS, de la conserver où elle est pour l'instant ou de la retirer. Un partenaire qui propose la même approche pour tout n'a pas regardé d'assez près.

Demandez les critères qu'il utilise pour choisir, et demandez à les voir appliqués à trois ou quatre de vos propres applications avant de signer. Son raisonnement sur vos vrais systèmes vous en apprend plus qu'une slide de méthode. Demandez en particulier comment il traite les applications sur des environnements en fin de vie, car les déplacer sans changement transporte les anciens risques sur la nouvelle plateforme.

Sachez qui conçoit et sécurise la landing zone

La landing zone est l'environnement cible préparé : structure des comptes, identités et accès, réseau, journalisation, chiffrement et garde-fous dont chaque application hérite. Une erreur à ce niveau se répète dans chaque application qui s'y installe. Demandez qui la conçoit, si elle est décrite en code, par exemple avec Terraform, et si votre équipe sécurité la relit avant que la première application ne soit migrée.

La sécurité dans le cloud est partagée. Le fournisseur sécurise l'infrastructure sous-jacente, et vous restez responsable de la façon dont vous la configurez et l'utilisez. Demandez au partenaire quels contrôles il mettra en place, lesquels restent à votre équipe, et comment les accès de ses propres ingénieurs sont accordés, journalisés puis retirés à la fin.

• Des comptes ou projets séparés par environnement, avec la production isolée
• Une authentification unique (SSO) avec des utilisateurs nominatifs et des rôles au moindre privilège, sans identifiants d'administration partagés
• Une journalisation centrale et des pistes d'audit que les ingénieurs du projet ne peuvent pas désactiver
• Le chiffrement au repos et en transit par défaut, avec les secrets tenus hors du code
• Des régions choisies pour respecter vos obligations de localisation des données et le RGPD

Faites-vous présenter une bascule et un retour arrière

La bascule est le moment où le trafic et les données passent sur le nouvel environnement, et c'est là qu'une migration est la plus visible pour le métier. Demandez au partenaire de dérouler une bascule étape par étape pour l'une de vos applications : comment les données sont synchronisées, comment le trafic est redirigé, quelles vérifications sont faites ensuite et qui décide que tout a fonctionné.

Demandez ensuite comment il reviendrait en arrière. Un plan crédible nomme les conditions qui déclenchent un retour arrière, la personne qui prend la décision et la durée pendant laquelle l'ancien environnement reste disponible. Si des utilisateurs ont écrit des données dans le nouvel environnement depuis la bascule, demandez comment ces données reviennent dans l'ancien. Les plans fragiles passent cette question sous silence.

Notre article sur la migration de centaines d'applications existantes vers AWS montre comment ces étapes deviennent des runbooks à l'échelle d'un grand parc.

Exigez de voir les coûts avant la première facture

Les coûts du cloud ne se comportent pas comme ceux d'un datacenter. Vous payez ce qui tourne, y compris les environnements de test que personne n'a éteints, le stockage qui ne cesse de grossir et les données transférées hors du réseau du fournisseur. Demandez une estimation des coûts par application avec ses hypothèses écrites, et demandez comment le partenaire la comparera à la consommation réelle pendant les premiers mois.

La visibilité sur les coûts est un choix de conception, pas un rapport mensuel. Demandez des règles de tags qui rattachent chaque ressource à une application et à un responsable, des budgets et des alertes dès le premier jour, et une revue de la taille des instances une fois que les applications ont tourné sous charge réelle. Dimensionner les serveurs cloud sur l'ancien matériel est un moyen sûr de payer une capacité que personne n'utilise.

Les signaux qui montrent qu'une proposition de migration n'est pas prête

Chacun de ces signaux peut avoir une explication. Plusieurs dans la même proposition signifient généralement que le risque vous a été laissé à découvrir.

• Un calendrier figé avant que quiconque ait vu votre inventaire
• Une seule stratégie de migration appliquée à toutes les applications
• Pas de plan de retour arrière écrit, ou un retour arrière qui repose sur une restauration de sauvegardes dans l'urgence
• Des comptes cloud, du code d'infrastructure ou des pipelines détenus par le partenaire plutôt que par vous
• Des estimations de coûts sans hypothèses, et aucun plan pour les tags ou les budgets
• Un transfert de connaissances prévu pour la dernière semaine

Planifiez le transfert de connaissances dès la première semaine

La migration se termine ; l'exploitation de la plateforme, non. Demandez comment votre équipe apprendra à exploiter ce qui est construit : du travail en binôme sur des tâches réelles pendant la migration, des runbooks pour les opérations récurrentes, et une présentation de la supervision et des alertes aux personnes qui seront d'astreinte.

Demandez que tout soit dans vos comptes et vos dépôts dès le départ : code d'infrastructure, pipelines, runbooks et schémas. Convenez ensuite de la façon dont la passation est validée, par exemple votre équipe déploie une application puis revient en arrière sans l'aide du partenaire.

Nous avons fait partie de l'équipe qui a migré 600+ applications internes du Crédit Agricole de VM historiques vers AWS, en réalisant nous-mêmes 50+ de ces migrations. Si vous voulez un second avis sur une proposition de migration, ou une équipe pour en livrer une partie, nos ingénieurs cloud peuvent passer ces questions en revue avec vous.

FAQ