Acheter un nom de domaine ne suffit pas à le faire mener à votre site. Tant que personne n'a indiqué où se trouvent les fichiers du site, le nom affiche au mieux une page d'attente du bureau d'enregistrement, c'est-à-dire la société qui vous l'a vendu. Pour lier un nom de domaine à un site, il faut deux réglages qui se répondent : l'un chez cette société, l'autre chez l'hébergeur qui garde votre site.
La difficulté vient de ce partage. Chaque service n'explique que sa propre moitié, avec des sigles comme A ou CNAME qui ne sont jamais traduits, et vous ne savez ni où faire la modification, ni si l'attente qui suit est normale ou si quelque chose a raté.
Ce guide donne les valeurs exactes pour GitHub Pages et Netlify, la démarche chez un hébergeur web classique et un exemple de bout en bout. Il montre ensuite comment vérifier que le changement a pris, activer le HTTPS et débloquer les cas les plus fréquents.
Déclarez d'abord votre domaine chez votre hébergeur, puis ajoutez dans la zone DNS du domaine les lignes qu'il vous indique : des enregistrements A vers ses adresses IP pour le domaine seul, un enregistrement CNAME pour la version avec www. Comptez jusqu'à 24 heures, parfois 48, pour que le changement soit visible partout, puis activez le HTTPS, que GitHub Pages et Netlify fournissent automatiquement.
Ce qui se passe quand quelqu'un tape l'adresse de votre site
Votre site n'est pas rangé derrière son nom. Ses fichiers sont gardés sur un ordinateur relié en permanence à Internet, chez votre hébergeur, et cet ordinateur se repère par une adresse IP, une suite de chiffres comme 185.199.108.153. Le nom de domaine existe pour que personne n'ait à retenir ces chiffres.
Il faut donc un système qui traduise le nom en adresse IP : c'est le DNS. Le guide d'OVHcloud sur les serveurs DNS le résume ainsi : un ensemble d'éléments « permettant de faire correspondre un nom de domaine avec une adresse IP ». Quand un visiteur tape votre adresse, son navigateur interroge une chaîne d'ordinateurs spécialisés, les serveurs DNS, jusqu'à atteindre ceux qui sont responsables de votre domaine. Ces derniers lisent la fiche de réglages du domaine et répondent avec l'adresse IP de l'hébergeur, que le navigateur contacte ensuite pour afficher le site.
Cette fiche de réglages s'appelle la zone DNS. Elle se présente comme un tableau dont chaque ligne est un enregistrement, avec quatre colonnes : le sous-domaine concerné, le type d'enregistrement, la cible et le TTL, une durée sur laquelle vous reviendrez plus bas. Relier votre domaine revient à écrire les bonnes lignes dans ce tableau, et deux types de lignes suffisent dans presque tous les cas.
L'enregistrement A : un nom vers une adresse IP
L'enregistrement A relie un nom à une adresse IP au format classique, quatre nombres séparés par des points. L'enregistrement AAAA fait la même chose avec les adresses IPv6, plus longues et écrites avec des deux-points. C'est l'enregistrement A qui sert pour le domaine seul, sans rien devant, par exemple monsite.fr. Les interfaces appellent ce domaine seul la racine ou l'apex, et le notent souvent @ ou laissent le champ du nom vide.
L'enregistrement CNAME : un nom vers un autre nom
L'enregistrement CNAME ne donne pas d'adresse IP. Il dit qu'un nom est l'alias d'un autre nom : www.monsite.fr renvoie par exemple vers votre-nom.github.io, et le navigateur suit ce second nom pour trouver l'adresse IP. Les hébergeurs le demandent surtout pour la version avec www.
Une règle explique pourquoi deux types coexistent. La documentation d'OVHcloud sur les enregistrements l'énonce clairement : « le domaine seul doit obligatoirement et directement pointer vers une adresse IP avec un champ de type A ». Il n'y a donc pas de CNAME sur le domaine seul. Certains fournisseurs proposent pour ce cas un type ALIAS ou ANAME, qui se comporte comme un CNAME tout en restant autorisé à la racine.
Le tableau suivant résume le rôle de chaque type et la ligne que vous écrirez le plus souvent.
| Type | À quoi il sert | Nom habituel | Exemple de cible |
|---|---|---|---|
| A | Relier un nom à une adresse IPv4 | @ (domaine seul) | 185.199.108.153 |
| AAAA | Relier un nom à une adresse IPv6 | @ (domaine seul) | 2606:50c0:8000::153 |
| CNAME | Faire d'un nom l'alias d'un autre nom | www | votre-nom.github.io |
Où faire les réglages : chez qui sont gérés les DNS de votre domaine
La zone DNS se trouve chez le service dont les serveurs DNS sont déclarés pour votre domaine. Ce peut être le bureau d'enregistrement lui-même, et vous modifiez alors la zone depuis votre compte client chez lui. Si vous avez un jour confié ces serveurs à un autre service, comme votre hébergeur ou Cloudflare, la zone qui compte est chez ce service. OVHcloud le précise dans son guide d'édition de zone DNS : si le domaine n'utilise pas ses serveurs DNS, « vous devez réaliser la modification depuis l'interface du prestataire gérant la configuration de votre nom de domaine ».
Pour savoir où vous êtes, ouvrez la fiche de votre domaine chez le bureau d'enregistrement et cherchez la rubrique des serveurs DNS, souvent appelée « Serveurs DNS » ou « Nameservers ». Si les noms affichés contiennent celui du bureau d'enregistrement, comme dns12.ovh.net, la zone est chez lui. S'ils contiennent le nom d'un autre service, c'est chez ce service que vous ferez les modifications, car un domaine n'a qu'une seule zone DNS active à la fois.
Ne changez pas les serveurs DNS de votre domaine simplement pour le relier à un site. Lors d'un tel changement, d'après OVHcloud, le contenu de l'ancienne zone n'est pas recopié dans la nouvelle : les lignes qui faisaient fonctionner vos adresses e-mail peuvent disparaître. Ajouter des enregistrements dans la zone existante suffit.
L'autre moitié du réglage se passe chez l'hébergeur. Il doit savoir que ce nom correspond à votre site, sinon il reçoit les visiteurs sans savoir quoi leur montrer. C'est par là qu'il faut commencer.
Étape 1 : déclarer le domaine chez l'hébergeur
L'ordre compte. La documentation de GitHub sur les domaines personnalisés demande d'ajouter le domaine sur GitHub avant de toucher au DNS, parce qu'un domaine qui pointe vers GitHub sans y être déclaré pourrait permettre à quelqu'un d'autre d'héberger un site sur l'un de vos sous-domaines. Netlify suit la même logique : vous ajoutez le domaine au site, puis l'interface vous donne les lignes à créer. Déclarez donc le domaine chez l'hébergeur d'abord.
Sur GitHub Pages
Sur GitHub Pages, le réglage se fait dans le dépôt de votre site, c'est-à-dire l'espace GitHub qui contient ses fichiers. Ouvrez l'onglet Settings, puis la rubrique Pages dans la colonne de gauche. Sous Custom domain, tapez votre domaine, par exemple monsite.fr, puis cliquez sur Save. Si votre site est publié depuis une branche, GitHub ajoute alors un petit fichier nommé CNAME à la racine du dépôt, qui contient simplement votre domaine. Si vous n'avez pas encore publié votre site, publier votre premier site sur GitHub Pages est l'étape qui précède celle-ci.
Sur Netlify
Sur Netlify, ouvrez votre site, choisissez Domain management dans la colonne de gauche, puis Add a domain et Add a domain you already own. Après avoir tapé votre domaine, Netlify vous demande si vous gardez votre fournisseur DNS actuel : c'est l'option External DNS Provider qui correspond à la démarche décrite ici. Netlify ajoute alors automatiquement les deux versions, avec et sans www, et un lien Pending DNS verification apparaît à côté du domaine. Ce lien affiche les valeurs exactes à saisir pour votre site, et ce sont celles-là qui font foi.
Netlify donne aussi un conseil qui change le choix du domaine principal. Sa page sur les domaines multiples recommande fortement, quand vous gardez un fournisseur DNS externe, de choisir la version www comme domaine principal ; la version sans www est alors redirigée automatiquement vers elle.
Chez un hébergeur web classique
Si votre site est sur un hébergement web classique (offre mutualisée, WordPress hébergé), la logique est la même. Ajoutez d'abord le domaine dans l'espace client de l'hébergeur, dans la rubrique qui gère les domaines du site. L'hébergeur vous indique alors l'adresse IP de l'hébergement, ou les lignes exactes à créer dans la zone. Si le domaine et l'hébergement sont chez la même société, l'association se fait souvent depuis la même interface. Comptez ensuite jusqu'à 48 heures, comme l'indique Infomaniak.
Étape 2 : ajouter les enregistrements dans la zone DNS
Une fois le domaine déclaré, retournez dans la zone DNS. Avant d'ajouter quoi que ce soit, regardez les lignes qui existent déjà : beaucoup de bureaux d'enregistrement créent à l'achat un enregistrement A qui envoie le domaine vers leur page d'attente. GitHub le dit sans détour : si votre fournisseur DNS a créé un enregistrement par défaut, supprimez-le avant de continuer. Faites de même pour les anciens enregistrements AAAA, et gardez une seule série de lignes pour le domaine seul, sinon les visiteurs tombent tantôt sur votre site, tantôt sur l'ancienne cible.
Le tableau ci-dessous reprend les valeurs publiées par les deux plateformes, pour le domaine seul d'un côté et pour www de l'autre.
| Plateforme | Domaine seul (@) | Version www |
|---|---|---|
| GitHub Pages | Quatre enregistrements A, de 185.199.108.153 à 185.199.111.153 : seul le troisième nombre change, de 108 à 111 | CNAME vers votre-nom.github.io, sans le nom du dépôt |
| Netlify | ALIAS ou ANAME vers apex-loadbalancer.netlify.com si votre fournisseur le permet, sinon un seul enregistrement A vers 75.2.60.5 | CNAME vers nom-du-site.netlify.app |
Pour GitHub Pages, vous pouvez ajouter en plus les quatre adresses AAAA indiquées par GitHub, de 2606:50c0:8000::153 à 2606:50c0:8003::153, mais toujours en complément des enregistrements A. Pour Netlify, n'ajoutez aucun AAAA : sa page de dépannage des certificats précise que son répartiteur de trafic ne gère pas IPv6 et demande de supprimer tous les AAAA restants.
Les noms des champs changent d'un bureau d'enregistrement à l'autre. Le champ du nom s'appelle selon les cas « Hôte », « Nom » ou « Sous-domaine », et vous y mettez @ ou rien du tout pour le domaine seul, www pour la version www. Le champ de la cible s'appelle « Valeur », « Cible » ou « Pointe vers ».
Chez certains bureaux d'enregistrement, une cible qui est un nom doit se terminer par un point : votre-nom.github.io. et non votre-nom.github.io. Sans ce point, l'interface ajoute votre propre domaine à la fin de la cible, et le CNAME ne mène plus nulle part. C'est ce que prévoit la norme du DNS pour un nom sans point final.
Une dernière ligne est à éviter, quel que soit l'hébergeur : l'enregistrement générique *, qui couvre tous les sous-domaines possibles. GitHub le déconseille fortement parce qu'il expose votre domaine à une prise de contrôle par un tiers.
Exemple complet : relier un domaine à un site GitHub Pages
Les étapes précédentes prennent tout leur sens une fois enchaînées. Prenons un domaine monsite.fr, acheté chez un bureau d'enregistrement dont vous utilisez les serveurs DNS, et un site déjà publié à l'adresse votre-nom.github.io. Voici le parcours complet, dans l'ordre.
- Sur GitHub, ouvrez le dépôt du site, puis Settings, puis Pages. Sous Custom domain, tapez
monsite.fret cliquez sur Save. - Chez le bureau d'enregistrement, ouvrez la zone DNS de
monsite.fret supprimez l'enregistrement A créé par défaut sur@, ainsi que tout ancien enregistrement AAAA sur@. - Ajoutez quatre enregistrements A sur
@, un par adresse :185.199.108.153,185.199.109.153,185.199.110.153et185.199.111.153. - Ajoutez un enregistrement CNAME avec le nom
wwwet la ciblevotre-nom.github.io, en ajoutant le point final si votre interface l'exige. S'il existe déjà une ligne pourwww, modifiez-la au lieu d'en créer une seconde. - Attendez que le changement se diffuse, puis vérifiez-le avec un outil DNS, comme expliqué un peu plus bas.
- Revenez dans Settings, puis Pages. Quand le contrôle DNS est réussi et qu'une coche apparaît à côté de votre domaine, cochez Enforce HTTPS dès que la case devient disponible.
- Ouvrez
https://monsite.frpuishttps://www.monsite.fr: la seconde adresse doit vous renvoyer vers la première, avec le cadenas.
Grâce aux deux séries de lignes, GitHub crée lui-même la redirection entre la version www et la version sans www. Si vous aviez tapé www.monsite.fr à la première étape, la redirection se ferait simplement dans l'autre sens.
Sur Netlify, le même parcours tient en cinq étapes :
- Dans votre site, ouvrez Domain management, puis Add a domain et Add a domain you already own, et tapez
monsite.fr. - Ouvrez le lien Pending DNS verification pour relever les valeurs exactes de votre site.
- Dans la zone DNS, supprimez l'ancien enregistrement A et tous les AAAA sur
@, puis créez un ALIAS versapex-loadbalancer.netlify.com, ou à défaut un seul enregistrement A vers75.2.60.5. - Créez un CNAME avec le nom
wwwet la ciblenom-du-site.netlify.app. - Suivez la création du certificat dans Domain management, puis HTTPS.
Combien de temps attendre : la propagation DNS
Juste après l'enregistrement de vos lignes, le site ne répond souvent pas encore, et c'est normal. Les serveurs DNS qui ont déjà répondu pour votre domaine gardent leur ancienne réponse en mémoire pendant une durée fixée par le TTL de chaque ligne, sigle anglais de « durée de vie ». Tant que cette durée n'est pas écoulée, certains visiteurs reçoivent encore l'ancienne adresse. On appelle propagation ce temps nécessaire pour que la nouvelle réponse remplace l'ancienne partout.
Pour un ajout ou une modification de lignes dans la zone, GitHub, Netlify et OVHcloud annoncent tous un délai pouvant aller jusqu'à 24 heures. Infomaniak indique de son côté qu'une modification DNS « peut prendre jusqu'à 48 heures », et un changement de serveurs DNS, plus lourd, demande aussi jusqu'à 48 heures chez OVHcloud. Ces délais sont des maximums : bien souvent, le changement est visible bien plus tôt. Ils peuvent aussi évoluer, et la page d'aide de votre bureau d'enregistrement reste la référence pour le sien.
Votre propre navigateur peut aussi vous tromper, car il garde lui-même une copie des pages déjà visitées. Si le site s'affiche ailleurs mais pas chez vous, la page de dépannage de GitHub conseille de vider le cache du navigateur. Plutôt que de recharger la page en boucle, mieux vaut interroger le DNS directement.
Vérifier que le DNS a bien changé
Le plus simple est un outil en ligne. Le Dig de la Google Admin Toolbox lance directement dans le navigateur la vérification que fait la commande dig présentée plus bas, et DNSChecker montre cette réponse depuis de nombreux endroits du monde, ce qui permet de voir où la propagation est déjà faite. Choisissez le type A pour monsite.fr, puis le type CNAME pour www.monsite.fr.
Si vous préférez le terminal, la fenêtre où l'on tape des commandes, la commande dig est fournie sur Mac. Sur Linux, elle est souvent déjà présente, sinon elle s'installe avec le paquet bind9-dnsutils sur Debian et Ubuntu. Windows ne l'inclut pas, mais il dispose de nslookup, un outil de Microsoft qui interroge le DNS de la même façon. Remplacez monsite.fr par votre domaine dans les commandes suivantes, d'abord sur Mac ou Linux :
dig monsite.fr +noall +answer -t A
dig www.monsite.fr +noall +answer -t CNAMESur Windows, les deux mêmes vérifications s'écrivent ainsi :
nslookup -type=A monsite.fr
nslookup -type=CNAME www.monsite.frPour un site GitHub Pages, la première commande doit afficher les quatre adresses de GitHub et aucune autre. Une adresse en plus signale un ancien enregistrement resté dans la zone, et un CNAME qui affiche autre chose que votre-nom.github.io signale une erreur de saisie. Quand les deux réponses sont bonnes, il reste à sécuriser l'adresse.
Activer le cadenas HTTPS une fois le domaine relié
Le HTTPS chiffre les échanges entre le navigateur du visiteur et votre site, ce qui empêche un tiers de les lire ou de les modifier en route. Pour l'activer, l'hébergeur a besoin d'un certificat, un fichier électronique qui atteste que le site servi correspond bien à votre nom de domaine. GitHub Pages et Netlify le demandent pour vous à Let's Encrypt, un organisme à but non lucratif qui délivre ces certificats gratuitement.
Ce certificat ne peut être délivré qu'une fois le DNS pointé vers l'hébergeur, puisque c'est en vérifiant le DNS que l'hébergeur prouve qu'il sert bien votre domaine. C'est pourquoi le HTTPS arrive en dernier. Pendant la propagation, si vous ouvrez votre adresse en https://, le navigateur peut afficher un avertissement de connexion non sécurisée : le certificat n'est simplement pas encore prêt, et il suffit d'attendre.
Le cadenas lui-même a changé d'apparence dans certains navigateurs. Google a annoncé sur le blog de Chromium le remplacement de l'icône du cadenas de Chrome par une icône de réglages. Dans Chrome, c'est donc l'adresse qui commence par https://, sans avertissement, qui vous confirme que tout fonctionne.
Sur GitHub Pages
Dès que vous enregistrez le domaine, GitHub lance un contrôle DNS, puis demande le certificat ; une coche apparaît à côté du domaine quand tout est en place. Le HTTPS peut mettre jusqu'à une heure à fonctionner après la configuration, et la case Enforce HTTPS jusqu'à 24 heures à devenir cliquable, d'après la page de dépannage de GitHub. Une fois cochée, elle redirige automatiquement toute visite en http:// vers https://, comme l'explique la page de GitHub sur le HTTPS.
Sur Netlify
Sur Netlify, vous n'avez rien à demander : sa page sur le HTTPS indique qu'il demande et renouvelle automatiquement le certificat de chaque domaine ajouté. Vous suivez son état dans Domain management, puis HTTPS. En cas d'échec, Netlify réessaie toutes les 10 minutes pendant les 24 premières heures ; au-delà, un problème de DNS est probable et la section suivante vous aidera à le trouver.
Le cadenas est actif, mais certaines images ou styles ne se chargent plus. Le code de votre site appelle sans doute ces fichiers avec une adresse en http://. GitHub appelle cela du contenu mixte : remplacez http:// par https:// dans ces adresses, en cherchant http:// dans les fichiers du site.
Dépannage : les blocages les plus fréquents et leur solution
Les pages de dépannage de GitHub et de Netlify reviennent surtout sur deux causes : une ligne en trop dans la zone, ou une ligne qui pointe au mauvais endroit. Chaque cas ci-dessous se reconnaît à un symptôme précis.
Un ancien enregistrement A ou AAAA est resté
Le site s'affiche une fois sur deux, ou la vérification DNS montre une adresse que vous ne reconnaissez pas. C'est en général l'enregistrement de la page d'attente du bureau d'enregistrement, ou celui d'un ancien hébergeur. Supprimez toute ligne A ou AAAA sur @ qui ne figure pas dans les valeurs de votre hébergeur. GitHub précise que des enregistrements en trop peuvent aussi empêcher la création du certificat, et Netlify demande de ne garder qu'un seul enregistrement A sur le domaine seul.
Le CNAME sur le domaine seul est refusé
L'interface refuse d'enregistrer un CNAME sur @, ou affiche une erreur de conflit. Elle applique simplement la règle vue plus haut : le domaine seul prend des enregistrements A, ou un ALIAS ou ANAME si votre fournisseur en propose. Pour Netlify sans ALIAS, utilisez l'enregistrement A vers 75.2.60.5 ; pour GitHub Pages, les quatre enregistrements A.
La version www ne répond pas
monsite.fr fonctionne mais www.monsite.fr affiche une erreur. Vérifiez qu'un CNAME existe bien pour www, qu'il n'y en a qu'un, et qu'il pointe vers l'adresse de la plateforme, votre-nom.github.io ou nom-du-site.netlify.app. Un cas revient souvent chez GitHub : un CNAME www qui pointe vers monsite.fr au lieu de votre-nom.github.io. GitHub prévient que cette configuration pose problème pour le HTTPS et peut même empêcher la version www d'atteindre le site.
Le certificat n'est pas émis ou la case Enforce HTTPS reste grisée
Si le contrôle DNS est réussi mais que le certificat tarde, commencez par vérifier qu'aucune ligne en trop ne traîne, puis relancez la demande. Sur GitHub, cliquez sur Remove à côté du domaine, retapez-le et cliquez sur Save ; GitHub recommande ce geste après toute modification du DNS. Sur Netlify, le bouton Renew certificate de la rubrique HTTPS sert surtout quand le certificat couvre une version du domaine mais pas l'autre.
Deux autres causes sont citées par les hébergeurs. Si votre domaine passe par un service intermédiaire, comme le mode proxy de Cloudflare, ce n'est plus l'hébergeur qui reçoit directement les visiteurs : la page de dépannage de Netlify demande de désactiver ce passage avant que le certificat puisse être créé. Si votre zone contient un enregistrement CAA, qui liste les organismes autorisés à délivrer des certificats pour votre domaine, il doit autoriser letsencrypt.org.
La propagation dépasse 48 heures
Si votre site reste inaccessible après 48 heures, vérifiez la configuration DNS plutôt que de continuer à attendre. Vérifiez d'abord que vous avez modifié la bonne zone : si les serveurs DNS de votre domaine appartiennent à un autre service que celui où vous avez travaillé, vos lignes ne sont lues par personne. Contrôlez ensuite avec DNSChecker que toutes les régions donnent la même réponse. Si quelques-unes affichent encore l'ancienne, l'outil Flush Cache de Google Public DNS permet de demander à Google d'oublier sa copie. Si tout est correct et que rien ne bouge, le support de votre bureau d'enregistrement peut voir ce que vous ne voyez pas.
Un domaine relié, ce sont deux réglages qui se répondent
Un nom de domaine mène à votre site quand l'hébergeur sait qu'il lui appartient et que la zone DNS envoie les visiteurs vers lui. Une fois que vous savez ce que disent un enregistrement A et un CNAME, les instructions de n'importe quelle plateforme deviennent lisibles, et chaque blocage se ramène à une ligne à retrouver dans un tableau.
En pratique, retenez l'ordre : déclarer le domaine chez l'hébergeur, écrire les lignes A et CNAME dans la zone qui est réellement active, vérifier avec Dig ou DNSChecker, puis activer le HTTPS. Si rien ne bouge après 48 heures, revenez à la section de dépannage.