Introduction

Avant de modifier les enregistrements DNS d’un domaine en production, il est prudent de vérifier le site sur le nouveau serveur. Ce guide propose 4 méthodes, classées par utilité : du test local le plus rapide au clone/staging le plus complet. Choisissez la méthode adaptée à votre niveau et au type de site (statique, PHP/WordPress, application externe).

Avant de commencer — prérequis

  • Accès à votre cPanel : nécessaire pour récupérer l’IP du serveur, créer un sous‑domaine ou modifier la zone DNS. Voir : Comment accéder à mon compte cPanel ?.
  • L’adresse IP publique du nouveau serveur (ou l’IP partagée du compte cPanel).
  • Droits administrateur sur l’ordinateur de test si vous comptez modifier le fichier hosts.
  • Pour les sites dynamiques : accès à phpMyAdmin (ou WP Toolkit / Softaculous) afin d’ajuster l’URL de test si nécessaire. Guides : phpMyAdmin, WordPress Toolkit.
  • Si la zone DNS est gérée chez votre registrar (hors cPanel), prévoyez d’éditer les enregistrements chez ce fournisseur.

Méthode 1 — Modifier le fichier hosts (test local, le plus sûr pour vous seul)

Principe : votre ordinateur utilisera l’IP que vous lui indiquez pour un nom de domaine. La modification est locale et n’affecte pas les visiteurs. Utile pour valider rendu, liens, et connexions à la base.

Étapes (Windows)

  1. Récupérez l’adresse IP du nouveau serveur (voir ci‑dessous comment la trouver dans cPanel).
  2. Ouvrez le Bloc‑notes en tant qu’administrateur (clic droit → Exécuter en tant qu’administrateur).
  3. Fichier → Ouvrir → C:\Windows\System32\drivers\etc\hosts. Choisissez « Tous les fichiers » pour voir le fichier.
  4. Ajoutez une ligne en tête du fichier : 203.0.113.10 example.com www.example.com (remplacez l’IP et le domaine par les vôtres).
  5. Enregistrez. Videz le cache DNS local : dans un terminal administrateur exécutez ipconfig /flushdns, puis rafraîchissez votre navigateur (ou redémarrez‑le).

Étapes (macOS / Linux)

  1. Ouvrez un terminal et éditez : sudo nano /etc/hosts (ou votre éditeur favori).
  2. Ajoutez la même ligne que ci‑dessus : IP puis noms de domaine séparés par des espaces.
  3. Enregistrez (Ctrl+O), quittez (Ctrl+X). Sur macOS, exécutez sudo dscacheutil -flushcache et, si besoin, sudo killall -HUP mDNSResponder. Sur Linux, la commande varie selon la distribution (p. ex. sudo systemd-resolve --flush-caches sur certains systèmes) ; redémarrer le navigateur est une alternative simple.

Points importants

  • Le fichier hosts n’affecte que la machine modifiée : parfait pour tests privés.
  • Les e‑mails (MX) restent pointés vers l’ancien serveur tant que vous ne changez pas les DNS publics.
  • HTTPS : attendez‑vous à des avertissements de certificat (mismatch) car le certificat du serveur n’est pas émis pour l’IP locale. Pour tester HTTPS, utilisez un sous‑domaine public (méthode 3).
  • Après tests, supprimez l’entrée ajoutée dans hosts pour revenir au routage DNS normal.

Méthode 2 — URL temporaire via mod_userdir (http://IP/~utilisateur)

Si votre hébergeur active mod_userdir, vous pouvez ouvrir l’URL http://IP/~username. Avantage : pas de changement local sur les postes. Inconvénient : incompatibilités fréquentes avec certains handlers PHP et erreurs liées au chemin.

Étapes

  1. Demandez à l’hébergeur s’il autorise l’accès via http://IP/~username. Si vous gérez le serveur avec WHM, l’option se trouve dans Security Center → Apache mod_userdir Tweak.
  2. Ouvrez http://203.0.113.10/~username (exemple) dans votre navigateur.

Limitations

  • Incompatibilités courantes : PHP via CGI/FastCGI, PHP‑FPM et certains modules (ex. mod_ruid2) peuvent empêcher le fonctionnement correct des scripts ; des erreurs 500 peuvent apparaître.
  • SSL : accès via IP ou URL temporaire déclenche un avertissement de certificat.
  • Ne permet pas toujours de reproduire la configuration exacte (chemins, répertoires documentroot, règles .htaccess basées sur le nom d’hôte).

Méthode 3 — Créer un sous‑domaine de test et ajouter un enregistrement A (test public conseillé)

La méthode la plus proche d’un basculement réel : créez test.votredomaine.tld et pointez son enregistrement A vers la nouvelle IP. Vous pouvez partager l’URL avec un client et obtenir des certificats AutoSSL pour HTTPS après propagation.

Ouvrir Zone Editor dans le tableau de bord cPanel
Ouvrir Zone Editor dans cPanel pour ajouter ou modifier un enregistrement A.

Étapes (dans cPanel)

  1. Connectez‑vous à cPanel (voir Comment accéder à mon compte cPanel ?).
  2. Ouvrez Zone Editor (Domains → Zone Editor). Sélectionnez le domaine puis cliquez sur Manage.
  3. Cliquez sur Add Record, choisissez le type A. Remplissez :
    • Name : test (cela crée test.votredomaine.tld)
    • Address : l’adresse IP du nouveau serveur
  4. Sauvegardez. Attendez la propagation (quelques minutes à quelques heures selon caches et TTL).
Formulaire d’ajout d’un enregistrement A dans la zone DNS
Exemple : ajouter un enregistrement A pointant test.votredomaine.tld vers la nouvelle IP.

Conseils pratiques

  • Si la zone DNS est gérée chez un registrar externe, créez l’A record chez ce fournisseur.
  • Pour tester HTTPS : attendez la propagation puis activez AutoSSL (cPanel) sur test.votredomaine.tld pour obtenir un certificat valide.
  • Réduisez le TTL quelques heures avant un basculement planifié pour accélérer la propagation si vous le pouvez.

Méthode 4 — Cloner / staging (pour WordPress et sites dynamiques complexes)

Pour un site WordPress ou une application complexe, créez une copie (clone) sur un sous‑domaine : cela évite tout conflit avec la version en production et permet des tests fonctionnels et de performance complets.

Formulaire de clonage d’un site WordPress dans WP Toolkit
WP Toolkit (cPanel) : cloner une installation WordPress vers un sous‑domaine ou un dossier de test.

Cloner avec WP Toolkit (cPanel)

  1. Ouvrez WP Toolkit dans cPanel et repérez l’installation à cloner.
  2. Choisissez Clone : indiquez la destination (sous‑domaine ou dossier), vérifiez la base de données et lancez le clonage.
  3. Après clonage, désactivez tout cache (plugin de cache) puis testez les fonctionnalités : connexion admin, formulaires, paiements, etc.

Clonage manuel (non‑WordPress ou si WP Toolkit non disponible)

  1. Copiez les fichiers avec File Manager ou FTP vers le dossier de test (ex. test.votredomaine.tld/public_html).
  2. Exportez la base de données via phpMyAdmin et importez‑la dans une nouvelle base ; mettez à jour le fichier de configuration (ex. wp-config.php).
  3. Mettez à jour les URL dans la base (WordPress : siteurl et home dans la table wp_options) — utilisez phpMyAdmin pour modifier en toute prudence.
Modifier les entrées siteurl et home de WordPress dans phpMyAdmin
phpMyAdmin : modifier siteurl et home si le clone est servi depuis un sous‑domaine.

Actions à faire après les tests (check‑list)

  1. Supprimez l’entrée ajoutée au fichier hosts sur vos postes de test.
  2. Supprimez ou réaffectez le sous‑domaine de test si vous n’en avez plus besoin.
  3. Notez la configuration DNS actuelle (A, MX, TXT) avant tout basculement pour pouvoir restaurer en cas de problème.
  4. Après modification des DNS publiques, surveillez la propagation et la délivrabilité des e‑mails (MX, SPF/DKIM/DMARC).

Dépannage rapide

  • Je vois encore l’ancien site : vérifiez le fichier hosts (tous les postes de test), videz le cache du navigateur, videz le cache applicatif (plugins WordPress), et attendez la propagation si vous avez ajouté un enregistrement A.
  • Erreur 500 / page blanche : consultez les logs d’erreurs cPanel (Metrics → Errors) et vérifiez la version PHP dans MultiPHP Manager. Si le site fonctionne via hosts mais pas via mod_userdir, la cause est souvent l’incompatibilité du handler PHP.
  • Avertissement de certificat HTTPS : normal si vous testez par IP ou via hosts. Pour valider HTTPS, utilisez un sous‑domaine public et demandez un certificat AutoSSL après que le sous‑domaine pointe vers le serveur.
  • Impossible de vous connecter à WordPress : mettez à jour siteurl et home via phpMyAdmin (table wp_options), supprimez les cookies liés au site et désactivez les plugins de sécurité/caching si nécessaire.
  • Services externes (OAuth, paiements) ne fonctionnent pas : ces services vérifient souvent l’URL exacte. Testez sur un sous‑domaine public ou en staging accessible publiquement plutôt que par hosts local.

Limitations importantes

  • Le test via hosts ne reproduit pas l’expérience de vos visiteurs (caches DNS publics, CDN, règles basées sur l’IP du client, services externes vérifiant le domaine).
  • Certificat TLS/HTTPS et HSTS : les tests locaux peuvent masquer des problèmes que seule la version publique permettra d’identifier.
  • Mod_userdir peut présenter des comportements différents (chemins, headers) par rapport à un site servi par le nom de domaine réel.

Quelle méthode choisir ?

  • Test rapide seul (développeur) : fichier hosts.
  • Partage avec un client / QA : sous‑domaine + enregistrement A (méthode 3).
  • Vérifier HTTPS et services externes : sous‑domaine public (AutoSSL possible).
  • Site WordPress complexe : clone/staging via WP Toolkit ou Softaculous (méthode 4).

Ressources internes

Résumé

Pour des vérifications rapides et strictement locales, modifiez le fichier hosts. Pour des tests partagés et proches de la production, créez un sous‑domaine A pointant vers la nouvelle IP. Pour des sites WordPress ou des tests approfondis, préférez un clone/staging via WP Toolkit ou Softaculous. Pensez toujours à sauvegarder la configuration DNS et à supprimer les modifications locales quand vous avez fini.

Documentation de référence

Documentation consultée le 16 octobre 2026. Les outils peuvent varier selon votre hébergement.