Relier un domaine à un site statique sans confondre les rôles

Quelles informations faut-il réunir ?

Votre nom de domaine, ses réglages DNS et les fichiers du site ne désignent pas la même chose. Avant toute modification, préparez une fiche avec le titulaire du domaine, le compte qui gère les DNS et le projet qui héberge les pages.

Si vous disposez seulement d'une adresse fournie par une plateforme, commencez par comprendre la différence avec un nom de domaine personnel. N'achetez pas une deuxième fois un domaine simplement parce qu'il n'apparaît pas dans le tableau de bord de l'hébergeur.

Vérifiez également l'adresse actuelle du site. Si cette version ne fonctionne pas, corrigez-la avant d'introduire une nouvelle variable DNS. Le parcours Cloudflare Pages traite cette publication initiale.

Préparer un changement limité

Choisissez l'adresse souhaitée : le domaine racine, comme example.com, ou un sous-domaine, comme www.example.com. Ces exemples sont réservés à l'explication ; reprenez ensuite les valeurs exactes de votre propre compte.

Pour Cloudflare Pages, associez le domaine au projet avant le DNS. La racine requiert une zone Cloudflare ; un sous-domaine peut utiliser un CNAME externe. Voir les domaines personnalisés Pages, vérifiés le 10 septembre 2026.

Cette règle ne constitue pas une procédure universelle pour tous les hébergeurs. Suivez celle du service choisi et ne copiez pas une destination DNS trouvée dans la configuration d'un autre site.

Protéger les services qui utilisent déjà le domaine

Faites une copie des enregistrements et de leur destination avant le changement. Repérez les services autres que le site : messagerie, validation de propriété, sous-domaines ou applications.

Voici une grille de préparation originale :

Si DNSSEC est actif et que vous changez de serveurs DNS, ne procédez pas à l'aveugle. Faites vérifier l'articulation entre la signature de zone et les informations conservées chez le registrar avant la bascule. N'appliquez pas une consigne générique de désactivation.

Contrôler chaque résultat séparément

Après association, ouvrez la nouvelle adresse et vérifiez le certificat HTTPS, le contenu et une page interne. Une adresse qui répond ne prouve pas que l'autre variante fonctionne aussi.

Si vous utilisez la racine et www, choisissez celle à communiquer et vérifiez le comportement de l'autre. Testez également un lien vers une page profonde, pas seulement l'accueil.

Envoyez ensuite un message de contrôle entre des adresses que vous maîtrisez si le domaine sert au courrier. Une page web accessible ne valide pas la messagerie. Consignez le résultat et les éventuels écarts au lieu de déclarer tout le domaine opérationnel sur un seul test.

Réagir à un résultat différent selon les appareils

Lorsque deux appareils affichent des résultats différents, notez précisément les adresses et l'heure de contrôle. Comparez les réponses DNS et la destination attendue avant de modifier les mêmes réglages une nouvelle fois.

Évitez d'empiler plusieurs bascules en attendant qu'une fonctionne. Le diagnostic devient plus difficile si personne ne sait quelle configuration est encore en propagation.

Conservez votre fiche avec les accès administratifs décrits sans leurs secrets. Elle servira lors d'un renouvellement, d'un changement de responsable ou d'une migration vers un autre hébergement statique.

Questions fréquentes

Acheter un domaine publie-t-il automatiquement mon site ?

Non. Il faut relier l'adresse au projet d'hébergement et vérifier le résultat. Le domaine n'est pas le dossier contenant vos pages.

Puis-je supprimer tous les anciens enregistrements DNS ?

Non. Identifiez d'abord leur rôle et préservez les services existants. Un enregistrement qui ne concerne pas le site peut être indispensable au courrier.

Le cadenas HTTPS prouve-t-il que la migration est terminée ?

Non. Contrôlez aussi le contenu, les pages internes, les variantes d'adresse et les autres services concernés par le changement.