La nouvelle tombe un lundi matin par un message succinct sur le tableau de bord de l’hébergeur : cessation d’activité sous soixante-douze heures, sans repreneur annoncé, sans garantie explicite sur la disponibilité continue des données pendant la période de transition. Sept sites clients de l’agence étaient hébergés chez ce prestataire, dont deux sites de vente en ligne encore actifs.
Cet article ne déroule pas une méthodologie générale de migration planifiée, sujet déjà traité par ailleurs dans le détail. Il détaille le plan d’action concret suivi heure par heure pour rapatrier ce parc en urgence, avec les compromis qu’une telle situation impose et qui seraient inacceptables en temps normal.
Heures 0 à 6 : sécuriser l’accès avant tout
La première action, avant même de penser à une nouvelle infrastructure, a consisté à télécharger immédiatement toutes les sauvegardes disponibles depuis l’espace client de l’hébergeur, sans attendre de plan de migration détaillé. L’expérience d’autres agences dans des situations similaires montrait que l’accès à l’espace client pouvait devenir instable ou se fermer plus tôt que l’échéance officiellement annoncée.
Pour les sites dont l’accès FTP ou SSH restait fonctionnel, un export complet des fichiers et de la base de données a été lancé en parallèle sur les sept sites simultanément, avec wp db export côté base et une synchronisation rsync côté fichiers vers un stockage temporaire externe à l’hébergeur, loué en urgence dans l’heure suivant l’annonce.
Heures 6 à 18 : prioriser par criticité, pas par ordre alphabétique
Avec sept sites à traiter et un délai contraint, l’équipe a établi une priorisation stricte : les deux sites e-commerce en premier, en raison de l’impact financier direct d’une interruption prolongée ; puis les sites dont les sauvegardes semblaient les plus anciennes ou incomplètes une fois vérifiées, signe qu’ils risquaient de perdre le plus de données en cas de fermeture brutale de l’accès ; enfin les sites vitrines à faible enjeu, traités en dernier.
- Réservation immédiate de serveurs temporaires chez un hébergeur de confiance déjà utilisé par l’agence sur d’autres projets.
- Restauration prioritaire des deux sites e-commerce sur ces serveurs temporaires.
- Vérification fonctionnelle rapide : connexion, affichage du catalogue, test d’une commande en environnement de test avant bascule DNS.
- Bascule DNS anticipée avec un TTL volontairement réduit en amont, quand cela restait possible avant la fermeture de l’accès chez l’ancien hébergeur.
Heures 18 à 36 : les compromis qu’impose l’urgence
Dans une migration planifiée, une phase de recette complète précède systématiquement la bascule en production. Dans ce contexte d’urgence, cette phase a été volontairement réduite au strict test des parcours critiques (connexion, panier, paiement), acceptant le risque de bugs mineurs non détectés sur des pages secondaires, un compromis jugé raisonnable face au risque de perte totale d’accès aux données.
De même, l’optimisation fine de la configuration serveur (réglages PHP-FPM, cache objet, paramétrage MariaDB) a été reportée après la stabilisation, les serveurs temporaires étant déployés avec une configuration standard générique plutôt qu’une configuration sur mesure par site, habituellement la norme sur les projets de l’agence.
Une migration d’urgence n’est jamais une bonne migration. Elle vise un seul objectif : ne perdre ni les données, ni la disponibilité des sites, quitte à sacrifier temporairement la qualité de la configuration.
Heures 36 à 48 : consolidation et communication client
Les dernières heures du délai ont servi à traiter les trois sites vitrines restants, moins critiques mais toujours prioritaires face à l’échéance annoncée, et à envoyer à chaque client concerné une communication précise sur ce qui avait changé : nouvelle infrastructure temporaire, calendrier de retour à une configuration optimisée dans les semaines suivantes, et confirmation explicite qu’aucune donnée n’avait été perdue dans l’opération.
Ce que cet épisode a changé durablement
Depuis cet incident, l’agence maintient pour chaque client une copie de sauvegarde complète stockée en dehors de l’infrastructure de l’hébergeur principal, mise à jour hebdomadairement, indépendamment du service de sauvegarde propre à l’hébergeur. Ce doublon, autrefois perçu comme une dépense superflue pour des sites déjà sauvegardés côté hébergeur, s’est révélé être l’élément qui aurait rendu cette migration d’urgence bien moins stressante si elle avait déjà existé.
Notre verdict
Aucun hébergeur, aussi installé soit-il historiquement sur le marché, ne garantit une continuité indéfinie de son activité. La seule assurance réelle contre ce scénario reste une copie de sauvegarde totalement indépendante de l’infrastructure hébergeant les sites, vérifiée régulièrement et accessible sans dépendre de l’espace client du prestataire concerné.
