Domaine personnalisé GitHub Pages : configuration du DNS, du CNAME et du HTTPS

Configurez un domaine personnalisé GitHub Pages : enregistrements DNS apex et www, rôle du fichier CNAME, vérification du domaine et activation du HTTPS.

Questions fréquentes

Quelles adresses IP utiliser pour un domaine apex sur GitHub Pages ?

La documentation de GitHub (vérifiée en novembre 2026) indique quatre enregistrements A pour l'hôte apex (@) : 185.199.108.153, 185.199.109.153, 185.199.110.153 et 185.199.111.153. Si vous voulez aussi l'IPv6, ajoutez quatre enregistrements AAAA : 2606:50c0:8000::153, 2606:50c0:8001::153, 2606:50c0:8002::153 et 2606:50c0:8003::153. GitHub recommande de conserver les enregistrements A en plus des AAAA. Comparez avec la documentation avant de copier ces valeurs, car GitHub peut les modifier.

Ai-je besoin d'un fichier CNAME dans mon dépôt ?

Seulement si vous publiez depuis une branche. Dans ce cas, enregistrer le domaine personnalisé dans Settings > Pages (Paramètres > Pages) crée automatiquement un commit d'un fichier CNAME à la racine de la branche source. Si vous publiez avec un workflow GitHub Actions personnalisé, GitHub précise qu'aucun fichier CNAME n'est créé et que tout fichier existant est ignoré et inutile.

Pourquoi la case Enforce HTTPS est-elle grisée ?

GitHub indique que l'option peut mettre jusqu'à 24 heures à apparaître après l'ajout du domaine. Le certificat est émis automatiquement : les causes habituelles d'une case bloquée sont donc un DNS qui ne s'est pas encore propagé ou des enregistrements en trop, comme des enregistrements A, AAAA, ALIAS ou ANAME supplémentaires sur l'apex, ou un CNAME sur www qui pointe ailleurs que vers GitHub. GitHub précise aussi que le domaine doit compter moins de 64 caractères. Si cela reste bloqué, cliquez sur Remove (Supprimer) à côté du domaine, saisissez-le à nouveau et enregistrez.

Faut-il utiliser le domaine apex ou www ?

GitHub recommande www. Sa documentation explique que les sous-domaines www sont le type de domaine personnalisé le plus stable, car ils ne sont pas affectés par les changements d'adresses IP des serveurs de GitHub. Quel que soit celui que vous définissez comme domaine personnalisé, GitHub redirige l'autre vers lui, à condition que le DNS des deux pointe vers GitHub Pages.

Combien de temps faut-il pour qu'un domaine personnalisé GitHub Pages fonctionne ?

GitHub indique que la propagation des modifications DNS peut prendre jusqu'à 24 heures. En pratique, beaucoup d'enregistrements se résolvent plus vite, mais prévoyez une journée avant de conclure à une panne.

Peut-on utiliser un enregistrement DNS générique (wildcard) avec GitHub Pages ?

GitHub déconseille fortement les enregistrements génériques comme *.example.com. Sa documentation précise qu'ils vous exposent immédiatement à un risque de détournement de domaine, même si vous avez vérifié le domaine. Créez plutôt des enregistrements pour les sous-domaines précis que vous utilisez.

En bref : dans votre dépôt, ouvrez Settings > Pages (Paramètres > Pages), saisissez votre domaine sous Custom domain (Domaine personnalisé) et enregistrez. Ensuite, chez votre fournisseur DNS, faites pointer www vers <username>.github.io avec un enregistrement CNAME, et faites pointer le domaine nu (example.com) vers GitHub avec quatre enregistrements A. Quand GitHub a fini d'émettre le certificat, cochez Enforce HTTPS. L'ensemble se résume à un réglage du dépôt et à quelques enregistrements DNS. La plupart des retards viennent de la propagation DNS, qui, selon GitHub, peut prendre jusqu'à 24 heures.

Tout ce qui suit a été vérifié dans la documentation officielle de GitHub en novembre 2026. Les valeurs DNS sont ce qui risque le plus de changer : confirmez-les dans la documentation GitHub Pages sur les domaines personnalisés avant de les copier.

Choisissez d'abord le type de domaine

Vous voulez que les visiteurs arrivent sur	À définir comme domaine personnalisé	Enregistrements DNS nécessaires	Remarques
`www.example.com`	`www.example.com`	CNAME sur `www` vers `<username>.github.io`, plus des enregistrements A sur l'apex	Configuration recommandée par GitHub. `example.com` redirige vers www.
`example.com`	`example.com`	Enregistrements A sur l'apex (ou un seul ALIAS/ANAME), plus un CNAME sur `www`	`www.example.com` redirige vers l'apex.
`blog.example.com`	`blog.example.com`	CNAME sur `blog` vers `<username>.github.io`	Aucun enregistrement apex nécessaire.

Selon la documentation de GitHub, les sous-domaines www sont le choix le plus stable, car ils ne sont pas touchés par les changements d'adresses IP des serveurs de GitHub. Sans raison particulière d'utiliser le domaine nu, choisissez www. Si vous cherchez encore un registrar, notre comparatif des registrars de domaine présente les options, et le coût d'un nom de domaine explique les tarifs de renouvellement.

Pas à pas : connecter le domaine

Ajoutez le domaine dans GitHub. Ouvrez votre dépôt, cliquez sur Settings (Paramètres), puis sur Pages (sous « Code, planning, and automation »). Si l'onglet Settings est masqué, cherchez-le dans le menu déroulant « More ». Saisissez votre domaine dans le champ Custom domain et cliquez sur Save.
Vérifiez ce que GitHub a fait dans votre dépôt. Si vous publiez depuis une branche, GitHub fait un commit d'un fichier CNAME à la racine de cette branche. Si vous publiez depuis un workflow GitHub Actions personnalisé, aucun fichier CNAME n'est créé et tout fichier existant est ignoré.
Supprimez les enregistrements DNS par défaut. Si votre fournisseur DNS a créé automatiquement un enregistrement de parking ou par défaut pour l'hôte que vous allez utiliser, supprimez-le d'abord.
Créez les enregistrements DNS chez votre fournisseur DNS (voir la section suivante).
Attendez la propagation. GitHub annonce jusqu'à 24 heures. Vous pouvez suivre l'avancement depuis un terminal avec dig www.example.com +noall +answer.
Activez Enforce HTTPS dès que l'option devient disponible (voir plus bas).

L'ordre compte moins qu'on ne le croit

Vous pouvez créer les enregistrements DNS avant ou après avoir enregistré le domaine dans GitHub. Le risque, c'est de laisser le DNS pointer vers GitHub Pages alors que le domaine n'est revendiqué par aucun dépôt. GitHub avertit que configurer le DNS sans ajouter le domaine à GitHub peut permettre à quelqu'un d'autre d'héberger un site sur l'un de vos sous-domaines. Enregistrez donc d'abord le domaine dans GitHub, puis passez au DNS.

Les enregistrements DNS

www ou tout sous-domaine : un seul CNAME

Type	Hôte	Valeur
CNAME	`www`	`<username>.github.io`

Utilisez votre nom d'utilisateur ou le nom de votre organisation, sans le nom du dépôt. GitHub précise de ne pas faire pointer le CNAME vers l'adresse unique *.pages.github.io affichée dans les paramètres de votre dépôt.

Domaine apex : quatre enregistrements A (vérifiés en novembre 2026)

Type	Hôte	Valeur
A	`@`	`185.199.108.153`
A	`@`	`185.199.109.153`
A	`@`	`185.199.110.153`
A	`@`	`185.199.111.153`

En option, pour l'IPv6, des enregistrements AAAA sur @ :

Type	Hôte	Valeur
AAAA	`@`	`2606:50c0:8000::153`
AAAA	`@`	`2606:50c0:8001::153`
AAAA	`@`	`2606:50c0:8002::153`
AAAA	`@`	`2606:50c0:8003::153`

GitHub recommande d'ajouter les enregistrements A même si vous ajoutez des AAAA, car l'adoption de l'IPv6 reste inégale. Si votre fournisseur DNS prend en charge les enregistrements ALIAS ou ANAME, vous pouvez en utiliser un seul pointant vers <username>.github.io à la place des enregistrements A et AAAA.

Deux erreurs à éviter :

Des enregistrements en trop sur l'apex. GitHub indique que des enregistrements A, AAAA, ALIAS ou ANAME supplémentaires sur @, ou un CNAME sur www pointant ailleurs, peuvent empêcher la génération du certificat HTTPS.
Faire pointer un sous-domaine vers votre apex. GitHub prévient que cela pose des problèmes pour forcer le HTTPS et peut empêcher le sous-domaine d'atteindre votre site. Faites pointer les sous-domaines vers <username>.github.io.

Certains fournisseurs utilisent @ pour l'hôte apex, d'autres demandent de laisser le champ vide ou de saisir le domaine complet. C'est une particularité du fournisseur, pas un réglage GitHub.

Activer le HTTPS

GitHub émet les certificats des domaines personnalisés via Let's Encrypt. Une fois que le DNS se résout correctement :

Retournez dans Settings > Pages.
Repérez la coche à côté de votre domaine : elle indique que la vérification DNS a réussi.
Cochez Enforce HTTPS.

GitHub indique que l'option peut mettre jusqu'à 24 heures à devenir disponible. Si elle n'est pas apparue plusieurs minutes après l'enregistrement, GitHub suggère de cliquer sur Remove à côté du domaine personnalisé, de le ressaisir et de cliquer à nouveau sur Save. Le domaine doit aussi compter moins de 64 caractères pour qu'un certificat puisse être créé.

Si la case reste grisée, parcourez cette liste :

[ ] Le DNS de l'hôte pointe bien vers GitHub (dig affiche les quatre IP ou votre CNAME <username>.github.io)
[ ] Aucun enregistrement A, AAAA, ALIAS ou ANAME superflu sur l'apex
[ ] Le CNAME www pointe vers <username>.github.io, et non vers l'apex ni vers une adresse pages.github.io
[ ] Le domaine dans Settings > Pages correspond exactement à celui saisi dans le DNS
[ ] Vous avez supprimé puis ajouté à nouveau le domaine une fois

Vérifier le domaine (fortement recommandé)

La vérification empêche d'autres comptes GitHub de revendiquer votre domaine si votre site Pages est un jour dissocié. GitHub indique qu'un détournement de domaine est possible si vous supprimez le dépôt, si votre forfait est rétrogradé, ou après toute modification qui dissocie le domaine alors qu'il reste configuré pour GitHub Pages sans être vérifié.

Ouvrez les paramètres de votre profil (pas ceux du dépôt), puis Pages dans la barre latérale.
Cliquez sur Add a domain, saisissez le domaine et confirmez.
Créez l'enregistrement TXT que GitHub vous indique. L'hôte ressemblera à _github-pages-challenge-USERNAME.example.com.
Vérifiez qu'il est visible avec dig _github-pages-challenge-USERNAME.example.com +nostats +nocomments +nocmd TXT.
De retour dans GitHub, utilisez le menu à côté du domaine, choisissez Continue verifying, puis Verify.

GitHub indique que la vérification peut être immédiate ou prendre jusqu'à 24 heures. Laissez ensuite l'enregistrement TXT en place. Évitez aussi les enregistrements génériques comme *.example.com : selon GitHub, ils exposent à un détournement même quand le domaine est vérifié.

Problèmes courants

Erreur 404 sur le domaine personnalisé alors que le site fonctionne sur github.io. Le domaine n'a jamais été enregistré dans Settings > Pages, ou le DNS ne s'est pas encore propagé. Vérifiez les deux.
Le domaine se réinitialise après chaque déploiement. Si vous publiez depuis une branche, le fichier CNAME de la branche source doit contenir votre domaine. Un build qui vide la racine de la branche, ou un déploiement qui omet le fichier, peut le supprimer. Passer à un workflow Actions personnalisé rend ce fichier inutile.
L'apex fonctionne mais pas www (ou l'inverse). Les deux hôtes ont besoin d'enregistrements. Rappelez-vous que GitHub ne redirige l'hôte associé que si son DNS pointe lui aussi vers GitHub Pages.
Le certificat n'arrive jamais. Parcourez la liste ci-dessus en cherchant d'abord les enregistrements parasites.

Si vous préférez ne pas gérer le DNS vous-même

GitHub Pages convient bien aux sites statiques que vous conservez déjà dans un dépôt. Si vous voulez surtout mettre un site en ligne avec votre propre domaine, les domaines personnalisés de We.Inc vous guident à travers la même étape DNS directement dans le créateur de sites, et le guide de connexion de domaine couvre le sujet pour n'importe quel fournisseur. L'offre gratuite de We.Inc vous permet de publier jusqu'à trois sites à partir de modèles prêts à l'emploi ; le créateur IA qui rédige un site à partir d'une description démarre avec l'offre Starter à $20 par mois. Vous pouvez vous inscrire ici.

Commencer gratuitement · Sans carte bancaire

Umair Ali Sadaqat

Fondateur de We.Inc

Umair est le fondateur de We.Inc. Il écrit sur la création de sites web avec l’IA, les agences et la gestion d’un studio web.

Prêt à créer quelque chose de grand ?

Rejoignez les 15,000+ entreprises qui utilisent We.Inc pour lancer, développer et automatiser, le tout depuis une seule plateforme.