# Retirer un vieux serveur mutualisé partagé par cinq clients sans casse DNS > Décommissionner un serveur historique qui héberge encore plusieurs projets à des stades différents exige de traiter chaque dépendance DNS et certificat séparément. - Auteur : Clément Hadrot - Publié le : 2026-02-17 - Mis à jour le : 2026-02-17 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/retirer-serveur-mutualise-cinq-clients-dns/ ## L’essentiel - Chaque domaine dépend souvent de plusieurs enregistrements DNS distincts à vérifier un par un - Un certificat TLS mal anticipé peut interrompre un site pourtant déjà migré - La coupure finale ne doit intervenir qu'après un délai d'observation sans trafic résiduel Sur quel serveur ce domaine pointe-t-il réellement aujourd'hui ? Une question en apparence simple, mais qui s'est révélée étonnamment difficile à trancher pour l'un des cinq clients hébergés sur ce serveur mutualisé vieillissant, faute de documentation à jour sur ses enregistrements DNS. Ce serveur, provisionné plusieurs années auparavant, accumulait des projets à des stades très différents : deux sites totalement migrés vers une nouvelle infrastructure, un site en cours de migration partielle, et deux sites encore pleinement actifs dessus. Décommissionner un serveur mutualisé de ce type ne peut pas se faire en une seule opération groupée : chaque client suit son propre calendrier, et une coupure prématurée sur l'un d'eux peut interrompre un service encore utilisé sans que cela n'apparaisse dans les statistiques de trafic générales du serveur. ## Étape 1 : inventorier chaque domaine et ses enregistrements réels La première étape a consisté à dresser, domaine par domaine, la liste complète des enregistrements DNS actifs pointant vers l'adresse IP du serveur à décommissionner, via des requêtes `dig` systématiques sur chaque nom de domaine et sous-domaine connu. Cet inventaire a révélé plusieurs sous-domaines oubliés, notamment un environnement de démonstration commerciale monté deux ans plus tôt pour un client, jamais retiré depuis, et toujours techniquement accessible. ``` dig +short A demo-client-anciennete.example dig +short CNAME webmail.client-actif.example dig +short MX client-actif.example ``` Chaque enregistrement identifié a été consigné dans un tableau de suivi, avec son statut : à conserver et migrer, à supprimer définitivement, ou déjà obsolète et sans usage identifié. ## Étape 2 : traiter les certificats TLS avant toute coupure > L'essentiel à retenir : Chaque domaine dépend souvent de plusieurs enregistrements DNS distincts à vérifier un par un ; Un certificat TLS mal anticipé peut interrompre un site pourtant déjà migré ; La coupure finale ne doit intervenir qu'après un délai d'observation sans trafic résiduel Un certificat TLS renouvelé automatiquement sur ce serveur, via un client ACME configuré depuis des années, continuait de valider silencieusement le domaine tant que la validation DNS ou HTTP restait possible. Couper le serveur sans anticiper ce point aurait laissé, pour certains sous-domaines déjà migrés en apparence, un certificat expirant brutalement sur une infrastructure qui n'était plus supposée le gérer, créant une confusion inutile au moment du diagnostic. Pour chaque domaine encore actif ailleurs, un nouveau certificat a été émis et validé sur sa nouvelle infrastructure avant même d'envisager de toucher au serveur d'origine, garantissant qu'aucune dépendance résiduelle ne subsiste au moment de la coupure finale. ## Étape 3 : rediriger, observer, puis seulement couper Pour les deux clients dont le site restait actif sur ce serveur, la migration vers la nouvelle infrastructure a précédé toute modification DNS. Une fois le nouveau serveur validé fonctionnellement, les enregistrements DNS ont été modifiés un par un, jamais tous en même temps, pour isoler facilement l'origine d'un éventuel problème. - Modification DNS d'un seul domaine à la fois, jamais en lot - Période d'observation d'au moins soixante-douze heures après chaque modification - Vérification des journaux d'accès du serveur d'origine pour confirmer l'absence de trafic résiduel Cette dernière vérification, la lecture des journaux d'accès du serveur historique après chaque bascule, s'est révélée décisive : elle a permis de repérer qu'un service de supervision tiers continuait d'interroger directement l'ancienne adresse IP du serveur, en contournant totalement le DNS, une dépendance qui serait restée invisible sans cette observation directe. ## Étape 4 : la coupure finale, en plusieurs paliers Le serveur n'a pas été arrêté d'un coup après la dernière bascule DNS. Il a d'abord été isolé du réseau public, sauf pour le port utilisé par la supervision restante, le temps de corriger cette dernière dépendance identifiée. Une fois cette correction confirmée, le serveur a été arrêté puis conservé, éteint, encore deux semaines avant sa suppression définitive, au cas où une dépendance oubliée se manifesterait par un incident chez l'un des cinq clients. ## Checklist récapitulative 1. Inventorier tous les enregistrements DNS pointant vers le serveur, y compris les sous-domaines oubliés 2. Émettre et valider les certificats TLS sur la nouvelle infrastructure avant toute coupure 3. Migrer les services encore actifs, puis rediriger le DNS domaine par domaine 4. Observer les journaux d'accès du serveur d'origine après chaque bascule 5. Isoler le serveur avant de l'arrêter, puis le conserver éteint un délai de sécurité avant suppression Aucune étape de cette liste n'a été superflue : chacune a permis d'éviter une coupure de service qui serait, sans elle, passée inaperçue jusqu'à ce qu'un client s'en plaigne directement.