Un bureau d'études de Saint-Genis-Pouilly avait tout prévu pour le samedi. Le prestataire copiait le serveur de fichiers et l'application métier vers le cloud pendant la nuit, modifiait l'adresse du domaine le dimanche matin, et les quinze salariés retrouvaient leurs dossiers le lundi. À 8 h 30, la moitié de l'équipe travaillait effectivement sur le nouveau serveur. L'autre moitié écrivait encore dans l'ancien, parce que son fournisseur d'accès conservait en mémoire l'ancienne adresse pendant vingt-quatre heures. Personne ne l'a remarqué avant le mardi, quand il a fallu réconcilier à la main deux versions divergentes des mêmes dossiers de chantier.
Rien dans cette histoire ne relève d'une faute technique grossière. La copie des données avait fonctionné, la machine cible était correctement dimensionnée, la sauvegarde de départ existait. Ce qui a manqué, c'est le contrôle de la période pendant laquelle deux systèmes pouvaient recevoir des écritures en même temps. Une migration cloud se juge sur cette période, pas sur la vitesse de la copie.
Ce que sans coupure signifie réellement dans un projet de migration
Une bascule sans aucune interruption existe, mais elle suppose une application conçue pour tourner en deux endroits à la fois, avec une base répliquée et un basculement automatique. Ce n'est presque jamais le cas d'une application métier de PME ni d'un serveur de fichiers installé il y a huit ans. L'objectif réaliste est différent : une interruption courte, annoncée à l'avance, encadrée et réversible.
Deux indicateurs servent à fixer cet objectif. Le RPO désigne la perte de données que vous acceptez : si votre dernière copie utilisable date de la veille au soir, vous acceptez de perdre une journée de saisie. Le RTO désigne le délai au bout duquel le service doit être revenu. Ces deux valeurs se décident avec la direction et non avec l'équipe technique seule, parce qu'elles portent sur le métier : une fiduciaire en période de bouclement et un atelier qui facture en fin de mois n'ont pas la même tolérance. Nous les posons comme dans un plan de sauvegarde et de reprise d'activité.
Cet article traite du déroulé de la bascule. La question de savoir si vous devez reprendre la machine telle quelle ou réécrire l'application se pose plus tôt, et nous l'instruisons dans notre article sur le choix entre reprendre une machine telle quelle ou la redécouper.
La période de double écriture est le vrai danger d'une bascule
Le scénario qui coûte le plus cher n'est pas la panne visible. Une panne se voit, se signale et se corrige. Le scénario coûteux est celui où les deux environnements fonctionnent et acceptent des modifications pendant quelques heures : chaque système est cohérent avec lui-même, aucune alerte ne se déclenche, et la divergence se découvre plus tard, quand un document manque ou qu'une écriture comptable a disparu.
Nous traitons donc cette période comme un risque à supprimer, pas à surveiller. Concrètement, l'ancien environnement passe en lecture seule avant la copie finale des données. Les partages de fichiers sont démontés, l'application est arrêtée ou son accès est bloqué au niveau du réseau, et les tâches planifiées de nuit sont désactivées explicitement. Un travail automatique oublié qui continue d'écrire dans l'ancienne base pendant la bascule produit exactement le même résultat qu'un utilisateur resté du mauvais côté.
Le TTL du DNS se prépare une semaine avant, il ne se règle pas le jour de la bascule
Quand vous changez l'adresse à laquelle répond un nom de domaine, ce changement ne se propage pas instantanément. Chaque enregistrement porte une durée de vie, le TTL, qui indique combien de temps les serveurs intermédiaires et les postes conservent la réponse en mémoire. Si ce TTL est réglé à vingt-quatre heures, une partie de vos utilisateurs continuera d'atteindre l'ancien serveur pendant une journée entière après votre modification, et vous n'y pourrez rien.
La manoeuvre correcte tient en trois temps. Une semaine avant la bascule, nous abaissons le TTL des enregistrements concernés à quelques minutes, ce qui n'a aucun effet visible sur le service. Le jour de la bascule, la modification se propage alors en quelques minutes au lieu d'une journée. Quelques jours après, une fois la situation stabilisée, nous remontons le TTL à sa valeur normale. Le même raisonnement s'applique aux adresses internes, aux fichiers hosts laissés sur un poste par un ancien prestataire et aux partenaires qui pointent vers une adresse IP écrite en dur dans leur configuration. Ces derniers doivent être identifiés et prévenus pendant l'audit, car aucun réglage de DNS ne les corrigera.
Migrer par lots plutôt que par une nuit unique
La bascule globale d'un week-end suppose un inventaire parfait du système d'information. Nous n'en avons jamais rencontré. Il reste toujours un copieur qui envoie ses numérisations vers un partage précis, un automate d'atelier qui interroge une adresse fixe, un accès de prestataire créé pour une intervention et jamais retiré, ou une licence logicielle attachée à l'identifiant matériel de l'ancien serveur. Ces dépendances se révèlent pendant la coupure, c'est-à-dire au pire moment, quand la seule option restante est de terminer coûte que coûte.
Nous découpons donc le projet en vagues, du moins risqué vers le plus critique. Une première vague porte sur des données peu sensibles, souvent un partage d'archives, ce qui permet de valider le transfert, les droits d'accès, la sauvegarde de la cible et la supervision. Une deuxième vague porte sur un environnement de test de l'application métier, avec de vrais utilisateurs qui exécutent de vrais parcours. La production vient ensuite, et le changement de DNS figure parmi les dernières étapes. Chaque vague possède ses propres critères de réussite écrits à l'avance : les utilisateurs désignés se connectent, les traitements de nuit se terminent sans erreur, les temps de réponse restent dans une plage acceptée, les impressions fonctionnent.
Un lot est presque toujours oublié : celui de ce qui ne migre pas. Une machine d'atelier pilotée par une carte spécifique ou un périphérique qui exige une liaison locale restent au bureau, et l'écrire dans le plan évite de le découvrir en pleine bascule.
Le repli s'écrit avant la bascule, il ne s'improvise pas pendant
Un plan de repli n'est pas la phrase rassurante selon laquelle on pourra toujours revenir en arrière. C'est une procédure datée qui indique qui décide de l'abandon, à quelle heure au plus tard, quels services sont remis en route dans quel ordre, et ce que l'on fait des données saisies dans le nouvel environnement entre-temps. Ce dernier point est celui que l'on néglige : si vos équipes ont travaillé trois heures sur la nouvelle plateforme, revenir en arrière signifie perdre ces trois heures ou les ressaisir.
Nous conservons également l'ancien environnement en état, éteint mais intact, pendant plusieurs jours. Le supprimer aussitôt pour alléger la facture d'hébergement est une fausse économie, et la question du coût se traite ensuite : notre article sur une facture cloud qui augmente explique pourquoi une migration menée sans discipline de suivi des dépenses reproduit dans le cloud les gaspillages de l'ancienne salle serveur.
Notre déroulé, de l'audit à la fermeture de l'ancien environnement
Nous commençons par un audit d'une à trois semaines selon la taille du système d'information. Il produit l'inventaire des applications et des données, la cartographie des flux réseau, la liste des comptes à privilèges, les valeurs de RPO et de RTO validées par la direction, et la liste de ce qui ne migre pas. Nous vérifions aussi qui détient les accès d'administration : un environnement cloud dont le compte principal appartient à un indépendant parti depuis deux ans n'est pas une cible de migration, c'est d'abord un chantier d'identités.
Vient ensuite l'exécution, vague par vague, avec un point de validation à chaque étape. Nous laissons une documentation utilisable par votre helpdesk : les accès, les procédures de redémarrage, les points de contrôle après une mise à jour. Enfin, l'exploitation courante se discute séparément, sous forme de maintenance cloud plutôt que de journées de conseil sans fin. Nos missions cloud sont facturées 1000 HT / jour et se déroulent à distance dans toute la France et en Suisse, avec un déplacement quand le dossier le justifie vraiment.
Si un plan de bascule vous a été présenté comme l'affaire d'un week-end, transmettez-nous ce plan avant de le valider. Nous vous indiquerons où se trouve la période de double écriture, si le TTL a été préparé, et ce qu'il faut ajouter pour que le lundi matin ressemble à un lundi matin ordinaire.