Migration cloud : déplacer l'existant sans tout casser

Une migration cloud casse rarement pendant la copie. Elle casse au moment où l’on croit avoir fini. En juillet 2026, le disque de notre serveur, qui fait tourner une douzaine de services dont le CRM de Palmora, un portail immobilier que nous opérons pour son agence, était plein, et ses bases de données en danger : le CRM y rangeait lui-même les photos des biens. Nous les avons passées dans un stockage objet sans perdre un fichier ; le piège tenait dans des clés d’accès qui n’arrivaient pas jusqu’à l’application.

Migrer, ici, c’est déplacer ce qui tourne déjà (applications, données, fichiers, noms de domaine) vers un grand fournisseur, chez un autre hébergeur ou de retour sur un serveur à soi. Voici la méthode que nous appliquons, charge par charge, pour des équipes de 20 à 500 personnes. Elle suppose que le socle d’infrastructure qui accueillera ces charges existe déjà.

En bref

• Inventoriez aussi ce qui vit chez vos utilisateurs : session, application installée, notifications.
• Choisissez une stratégie par charge de travail, et modernisez après la migration, pas pendant.
• Copiez, testez, comparez, puis seulement purgez.
• Écrivez les conditions du retour avant de commencer, et gardez l’ancien chemin le temps de la preuve.
• Un hybride voulu n’est pas un échec.

Que faut-il inventorier avant de migrer ?

Le guide de migration de Google Cloud découpe une migration en quatre phases : évaluer, planifier, déployer, optimiser. La première sert à « comprendre votre inventaire d’applications et d’environnement, identifier les dépendances et les exigences des applications, calculer le coût total de possession et établir des références de performance des applications » (nous traduisons).

Les dépendances décident de l’ordre. Pour le guide de planification de Microsoft, « les dépendances entre les charges de travail provoquent des interruptions de service si elles ne sont pas migrées ensemble », et chaque lot doit emporter ce dont ses applications ont besoin, « notamment l’infrastructure prenant en charge des équilibreurs de charge, des enregistrements DNS ou des couches de mise en cache ».

Inventoriez aussi ce que vos utilisateurs gardent de leur côté. Pour un navigateur, une autre adresse est une autre application : quand Challenge Us, une application de défis de groupe que nous avons développée, a changé d’adresse en septembre 2026, la session, les réglages, l’application installée et les notifications restaient sur l’ancienne.

Quelle stratégie pour chaque charge de travail ?

Le guide d’AWS sur les grandes migrations range les options en sept stratégies, les « 7 R » :

• Retire : décommissionner ou archiver ce qui ne sert plus.
• Retain : garder sur place, pour l’instant ou pour de bon.
• Rehost : réhéberger sans rien changer, le « lift and shift ».
• Relocate : transférer de nombreux serveurs vers la version cloud de leur plateforme.
• Repurchase : remplacer par une autre version ou un autre produit.
• Replatform : déplacer avec un peu d’optimisation au passage.
• Refactor or re-architect : revoir l’architecture pour profiter des fonctions propres au cloud.

Pour une grande migration, AWS déconseille la refonte, « parce qu’elle implique de moderniser l’application pendant la migration », et recommande de « réhéberger, relocaliser ou changer de plateforme l’application, puis la moderniser une fois la migration terminée » (nous traduisons). Déplacer et transformer en même temps, c’est ne plus savoir laquelle des deux opérations a cassé.

Les migrations que nous avons menées pour nos clients se rangent dans ces cases : la synchronisation quotidienne de Palmora, réhébergée sur notre serveur sans changer ses étapes ; le stockage des fichiers de son CRM, changé de plateforme par la configuration, sans toucher au code ; les pages de Challenge Us, passées chez un autre hébergeur sans être réécrites. Nous n’avons mené aucune migration vers AWS, Google Cloud ou Azure : leurs guides nous servent ici de vocabulaire commun, quelle que soit la destination.

Pourquoi copier plutôt que déplacer ?

Copier garde l’original intact tant que la copie n’a pas fait ses preuves : le retour en arrière tient alors en une ligne de configuration. Pour les fichiers du CRM de Palmora, après une reconnaissance en lecture seule, nous avons posé quatre garde-fous :

• Un espace de stockage à part : celui des images du site est purgé de ses fichiers orphelins, et dans un espace commun, ce nettoyage aurait effacé ceux du CRM.
• Une clé d’accès dédiée, limitée à cet espace, révocable sans toucher au site.
• Des fichiers qui restent privés, servis par le CRM derrière sa propre authentification.
• Une sauvegarde de chaque fichier de configuration, l’ancienne valeur gardée en commentaire : c’est elle, le retour en arrière.

Ce CRM est Twenty : nous l’avons en production depuis début 2025, et nous contribuons au projet. Il sait ranger ses fichiers dans un stockage compatible S3, c’est-à-dire qui parle la même interface que le service de stockage d’Amazon : nous l’avons vérifié dans son code. Le piège était ailleurs : la configuration des conteneurs ne transmettait qu’une partie des réglages du stockage, sans les clés d’accès. Il a fallu les ajouter au service principal et au service des tâches de fond.

Comment vérifier avant de basculer, puis avant de purger ?

Avant la bascule, l’accès au nouveau stockage a été testé en lecture et en écriture, la copie s’est terminée sans erreur et la nouvelle configuration a été validée. Après la bascule, trois tests, et un quatrième après la purge :

1. Lecture : une fiche avec photos s’ouvre, servie par le nouveau stockage.
2. Écriture : une image ajoutée arrive dans le nouveau stockage, et l’ancien dossier ne bouge pas.
3. Intégrité : la comparaison des deux côtés ne trouve aucune différence. C’est ce test qui autorise la purge.
4. Preuve finale : l’ancien dossier vidé, toute image encore affichée vient forcément du nouveau stockage.

Une limite : la comparaison portait sur les noms et les tailles des fichiers, dans un seul sens, sans empreinte de contenu. Elle montre qu’il ne manque rien, pas que chaque octet est identique.

Comment basculer avec un chemin de retour ?

Le retour en arrière se décide avant de commencer. Microsoft l’écrit en toutes lettres : « Établissez toujours des critères et des procédures de restauration à l’état antérieur avant de lancer une migration ou un déploiement. » Ses déclencheurs sont mesurables, comme « les limites d’utilisation du processeur, les seuils de temps de réponse ou les taux d’erreur », et la procédure se teste : « Vérifiez que la procédure de retour en arrière ramène le système à un état stable et connu. »

Pour un nom de domaine, tout tient à l’ordre des gestes. Quand Challenge Us a changé d’adresse, une redirection aurait figé l’application : son service worker, le petit programme qui la sert depuis le cache du navigateur, ne se met jamais à jour à travers une redirection. Les deux adresses ont donc servi la même version, l’ancienne ne proposant de déménager qu’une fois la nouvelle prête.

Quand Challenge Us a ensuite changé d’hébergeur, une règle de routage a d’abord placé le nouvel hébergement devant l’ancien, sans toucher au DNS ni couper le service. Puis l’enregistrement DNS (la ligne qui dit où trouver le nom) a été supprimé. Or une règle de routage ne suffit pas sans enregistrement : le domaine a cessé de répondre quelques minutes, jusqu’à ce qu’il soit attaché au nouvel hébergement. Notre règle depuis : garder l’enregistrement et passer par une règle de routage, ou le supprimer et attacher le nom dans la foulée, jamais l’un sans l’autre.

Combien de temps garder l’ancien chemin ?

Une migration ne va pas toujours vers le cloud. Depuis le 23 juillet 2026, la synchronisation quotidienne qui alimente le site de Palmora à partir de son CRM tourne sur notre propre serveur, et non plus dans un service d’intégration continue en ligne. Le CRM y est local, les caches vivent sur disque, les étapes et l’horaire n’ont pas changé, et un verrou empêche deux exécutions de se chevaucher.

L’ancien chemin est resté, en secours manuel. Mais un secours vieillit : son cache est figé depuis juillet, et il revérifierait des milliers d’objets et pourrait tourner des heures. Pour Challenge Us, l’ancienne adresse ne sera jamais coupée : elle ne coûte rien, et c’est elle qui ramène les applications déjà installées. Gardez donc l’ancien chemin tant que quelqu’un l’emprunte, et vérifiez de temps en temps qu’il marche encore.

Quand purger, et que mesurer ensuite ?

La purge vient en dernier, après la comparaison, et sous garde : un chemin exact, et la vérification que le dossier contient bien ce qu’on attend. Après elle, le retour reste possible mais change de nature : environ une heure de recopie, la configuration restaurée, un redémarrage. Notre article sur ce qui casse vraiment dans les sauvegardes d’un serveur à soi le rappelle : une copie ne vaut que si l’on sait la remettre en place.

Ensuite, mesurez, car le piège est le silence : une alerte classique part quand une tâche échoue, pas quand elle ne tourne plus du tout. Sur Palmora, chaque tâche planifiée dépose un signal après chaque succès, et un veilleur hébergé hors du serveur alerte quand un signal manque ou date de plus de trente heures : installé sur la machine qu’il surveille, il tomberait avec elle. Ce signal ne doit pas rester figé en cache, sinon il répondrait « tout va bien » pour toujours. Challenge Us mesure, lui, qui ouvre encore l’application par l’ancienne adresse.

Garder une partie sur place : l’hybride est-il un échec ?

Non, s’il est voulu. AWS fait de « Retain » une stratégie à part entière, et cite, parmi ses cas de refonte, une base dont certaines tables, « comme les tables d’informations clients, de patients ou de diagnostics de patients », restent sur site pour des raisons de sécurité et de conformité (nous traduisons). Microsoft demande de documenter pourquoi un composant reste sur place, et de limiter l’entre-deux : « Réduisez le temps de fonctionnement dans un environnement scindé. »

Ces deux projets clients sont hybrides, par choix. Le CRM de Palmora tourne sur notre serveur, ses fichiers vivent dans un stockage objet, et une tâche hebdomadaire de nettoyage reste pour l’instant dans le service d’intégration continue. Challenge Us a changé d’hébergeur pour ses pages, mais sa base de données, ses comptes et ses fonctions serveur n’ont pas bougé. Pour la suite, notre analyse de la dépendance européenne au cloud américain dit ce que le droit européen change aux frais de changement de fournisseur.

La liste de contrôle avant la bascule

• La copie est terminée sans erreur, et l’original est intact.
• Les nouveaux réglages atteignent tous les services concernés, pas seulement le premier.
• La lecture et l’écriture sont testées sur la nouvelle destination.
• Les conditions du retour sont écrites, avec le nom de qui décide.
• L’ancien chemin reste ouvert, et vous savez pour combien de temps.
• Un signal préviendra si le nouveau chemin cesse de tourner.

Par où commencer

Listez ce qui doit bouger, avec pour chaque ligne une stratégie et sa condition de retour. Commencez par une charge dont le retour est simple, des fichiers par exemple. Si vos outils doivent quitter leurs abonnements pour un serveur à vous, notre sortie du SaaS les déplace un par un, données vérifiées et retour arrière prévu. Si la destination est un grand fournisseur ou un cloud européen, écrivez-nous ce qui doit bouger et où vous voulez l’emmener.

Questions fréquentes

Qu’est-ce qu’une migration cloud hybride ?

C’est une migration qui garde, par choix, une partie des charges de travail dans leur environnement d’origine : une base soumise à des règles de conformité, un outil sans équivalent chez le nouveau fournisseur, une tâche qu’il n’est pas encore temps de déplacer. Un hybride voulu a ses raisons écrites et ses échanges surveillés ; un hybride subi est une migration arrêtée en route.

Quels outils pour une migration vers le cloud ?

Trois outils couvrent l’essentiel : un outil de synchronisation qui copie puis compare les deux côtés (rclone, pour les fichiers du CRM de Palmora), l’outil d’export propre à chaque base de données plutôt qu’une copie de son dossier, et l’accès à la zone DNS de vos domaines. L’ordre compte plus que l’outil : copier, comparer, basculer, puis seulement purger.

Faut-il interrompre le service pendant une migration ?

Pas toujours. Microsoft distingue la migration avec temps d’arrêt et celle avec un temps d’arrêt proche de zéro, à choisir pour chaque charge de travail selon sa tolérance à l’arrêt et son importance pour l’activité. Dans les deux cas, évitez les périodes critiques, comme une clôture financière ou un lancement de produit.