Pourquoi mon domaine personnalisé ne fonctionne-t-il pas ?
Un domaine personnalisé échoue à l'une de trois couches, et chacune peut échouer indépendamment des autres : l'enregistrement DNS qui fait pointer le nom vers votre hébergeur, le certificat qui permet à votre hébergeur de servir ce nom en HTTPS, ou les redirections qui envoient chaque version de l'adresse au même endroit. L'erreur affichée par votre navigateur indique généralement quelle couche a cédé : lisez-la avant de modifier quoi que ce soit. Pendant la première heure, la cause est souvent une copie en cache de l'ancien enregistrement ; quand le problème dure une journée, cherchez un enregistrement dont vous ignoriez l'existence.
Trois couches, et le navigateur vous dit laquelle a cédé
Connecter un domaine à un site web, ce sont trois tâches distinctes qui se trouvent partager le même écran de paramètres. Le DNS fait pointer le nom vers votre hébergeur. Votre hébergeur doit ensuite obtenir un certificat prouvant qu'il est autorisé à servir ce nom en HTTPS. Et chaque version de l'adresse — avec www, sans www, en http simple — doit aboutir au même endroit. Une couche peut fonctionner alors que la suivante échoue, et c'est pourquoi « mon domaine ne fonctionne pas » peut désigner trois problèmes sans rapport entre eux.
Vérifiez-les dans cet ordre, car chacune dépend de la précédente. Un hébergeur ne peut pas obtenir de certificat pour un nom qui ne pointe pas encore vers lui, et une redirection ne s'exécute jamais sur une connexion que le navigateur a refusé d'ouvrir.
Lisez le symptôme avant de modifier un enregistrement
Le tableau associe ce que vous voyez à la couche qui en est généralement la cause. Avant de vous fier à une ligne, ouvrez l'adresse dans une fenêtre de navigation privée sur un autre réseau, par exemple votre téléphone avec le Wi-Fi désactivé. Votre propre appareil est l'élément du parcours le plus susceptible de conserver une ancienne réponse.
| Ce que vous voyez | Couche | Première chose à vérifier |
|---|---|---|
| Le navigateur indique que l'adresse est introuvable | DNS | Que l'enregistrement existe chez le fournisseur DNS que votre domaine utilise réellement — l'entreprise vers laquelle pointent vos serveurs de noms, qui n'est pas toujours celle où vous avez acheté le domaine — avec exactement le nom et le type demandés par votre hébergeur. |
| Votre ancien site, une page de parking ou la page d'attente du registraire s'affiche encore | Cache DNS | Le TTL de l'enregistrement. Les résolveurs conservent un enregistrement pendant cette durée avant de redemander, si bien qu'une modification n'atteint chaque visiteur qu'une fois sa copie en cache expirée. |
| Un avertissement indiquant que la connexion n'est pas privée, ou que le certificat n'est pas valide pour ce nom | Certificat | L'écran de gestion du domaine chez votre hébergeur. S'il indique encore « en attente » ou « vérification en cours », aucun certificat n'existe encore ; cherchez un enregistrement CAA qui omet l'autorité de certification de votre hébergeur, ou un ancien enregistrement au nom _acme-challenge. |
| La page ne se charge jamais et le navigateur signale trop de redirections | Redirections | Si un proxy placé devant votre hébergeur communique avec lui en HTTP simple alors que l'hébergeur redirige chaque requête HTTP vers HTTPS. Chaque côté ne cesse de renvoyer l'autre. |
| Le domaine nu fonctionne mais pas www, ou l'inverse | DNS et redirections | Chaque nom a besoin de son propre enregistrement. L'un des deux doit ensuite rediriger de façon permanente vers l'autre, afin que le site ne soit pas publié à deux adresses. |
| Votre fournisseur DNS refuse un enregistrement CNAME sur le domaine nu | DNS | La racine d'un domaine ne peut normalement pas porter de CNAME. Utilisez les enregistrements A que votre hébergeur indique pour la racine, ou une fonction du fournisseur qui résout le CNAME à votre place, que Cloudflare appelle CNAME flattening. |
Nous avons vérifié les mécanismes décrits dans ces lignes dans la documentation des éditeurs eux-mêmes le 15 septembre 2026. Celle de Cloudflare, par exemple, indique que les enregistrements passant par son proxy ont un TTL automatique de 300 secondes, tandis que ceux que vous gérez vous-même peuvent être réglés entre 60 secondes et une journée, et que son mode de chiffrement Flexible produit une boucle de redirection lorsque votre serveur d'origine redirige HTTP vers HTTPS. La solution qu'elle indique est le mode Full ou supérieur, ou l'application du HTTPS en périphérie plutôt qu'au niveau de l'origine.
Le certificat resté en attente près de trois heures
AgentCeres — l'AI Growth Officer sur agentceres.com — publie les sites web que ses agents construisent pour ses clients, et ces pages sont servies sous un domaine qui nous appartient, avec un seul certificat wildcard. Connecter votre propre domaine à une page que nous hébergeons n'est pas encore possible : cette section vient donc de la gestion de nos propres domaines et non d'un écran de configuration client. La mise en place de ce certificat nous a valu l'échec le plus instructif de cette page : nous avons demandé au service de certificats de Google de l'émettre, ajouté l'enregistrement de vérification qu'il demandait, et le certificat est resté en cours de provisionnement pendant deux heures et quarante minutes, sans autre motif d'échec qu'une erreur de configuration. Notre enregistrement était correct. Le problème venait d'un enregistrement que nous ne pouvions pas voir.
Le même domaine passait aussi par le proxy de Cloudflare, dont le propre système de certificats avait créé des enregistrements de vérification au même nom _acme-challenge. Ces enregistrements répondaient aux requêtes DNS mais n'apparaissaient jamais dans la liste des enregistrements que nous pouvions modifier. La documentation de Google indique explicitement que le CNAME de vérification doit être le seul enregistrement à ce nom, et qu'un CNAME et un enregistrement TXT présents ensemble à cet endroit peuvent empêcher l'émission. Nous sommes passés à la forme par projet de l'autorisation, qui utilise un autre nom d'enregistrement, et le certificat a été émis quatre minutes plus tard.
La leçon générale : un certificat qui reste en attente sans erreur claire signifie généralement que votre hébergeur cherche quelque chose que votre DNS contredit, et la contradiction peut venir d'un service qui gère des enregistrements pour votre compte. Interrogez le nom avec un outil public de recherche DNS au lieu de vous fier à la liste d'enregistrements d'un tableau de bord. La même configuration nous a aussi appris une règle plus modeste. Un certificat wildcard couvre exactement un niveau de sous-domaine : notre hébergement refuse donc d'emblée une adresse à deux niveaux de profondeur plutôt que de servir une page sur un nom que son certificat ne couvre pas.
Les redirections survivent à l'erreur
Les redirections sont la couche où un mauvais réglage continue de faire des dégâts après que vous l'avez corrigé. Le standard HTTP permet à un navigateur de mettre en cache une redirection permanente 301 dès lors que la réponse ne précise pas combien de temps la conserver : un visiteur tombé sur une mauvaise redirection peut donc continuer d'être envoyé vers la mauvaise adresse par son propre navigateur une fois votre serveur corrigé. La redirection que nous servons depuis les versions nue et www de notre domaine d'hébergement vers notre site principal porte une durée de vie explicite d'une heure, précisément pour cette raison. Tant que vous n'êtes pas sûr qu'une redirection est correcte, testez-la sous forme de redirection temporaire 302.
Choisissez ensuite une version de l'adresse et envoyez-y les autres. Nous avons appris ce que coûte l'impasse sur cette étape, et pourquoi Google n'indexe-t-il pas mon site React raconte cette histoire, tandis que l'entrée balise canonique explique comment les moteurs de recherche choisissent entre des doublons. Et si le domaine se charge mais que les visiteurs voient encore la page d'hier, c'est un problème de cache et non de domaine : pourquoi mon site affiche-t-il encore l'ancienne version vous guide pas à pas.
FAQ
- Combien de temps faut-il pour qu'une modification DNS soit visible ?
- En principe, la durée du TTL de l'ancien enregistrement, plus toute mise en cache sur votre propre appareil et votre réseau. La documentation de Cloudflare fixe les enregistrements passant par son proxy à cinq minutes et permet de régler jusqu'à une journée ceux que vous gérez vous-même. Si l'ancien enregistrement avait un TTL long, abaissez-le la veille du changement, puis attendez que l'ancienne valeur expire. Les 48 heures souvent citées sont un pire cas dû à des TTL longs, pas une règle.
- Dois-je changer mes serveurs de noms ou simplement ajouter des enregistrements ?
- Ajouter les enregistrements demandés par votre hébergeur ne modifie que les noms couverts par ces enregistrements. Changer de serveurs de noms déplace tous les enregistrements du domaine, y compris ceux qui acheminent vos e-mails : recopiez-les d'abord, sinon le courrier peut discrètement cesser d'arriver. Si votre domaine envoie des e-mails, pourquoi mon application n'envoie-t-elle plus d'e-mails couvre les enregistrements qui cassent quand le DNS change de place.
- Pourquoi mon domaine fonctionne-t-il pour moi mais pas pour quelqu'un d'autre ?
- Des réseaux différents interrogent des résolveurs différents, et chaque résolveur conserve sa propre copie en cache jusqu'à l'expiration du TTL. Testez depuis un deuxième réseau avant de conclure que quelque chose est cassé. L'inverse est tout aussi fréquent : cela fonctionne pour tout le monde sauf sur l'appareil qui vous a servi à tester l'ancienne configuration.
- Dois-je acheter un certificat SSL pour un domaine personnalisé ?
- En général, non. La plupart des hébergeurs de sites en demandent un automatiquement dès que le domaine pointe vers eux, auprès d'une autorité de certification qui ne le facture pas. Deux choses bloquent cela sans message d'erreur bien explicite : un enregistrement CAA qui ne nomme que d'autres autorités de certification, et un enregistrement de vérification resté en place qui contredit celui dont votre hébergeur a besoin. En l'absence de tout enregistrement CAA, n'importe quelle autorité de certification publique peut émettre un certificat pour votre domaine.
- Passer mon site sur un domaine personnalisé va-t-il nuire à mon SEO ?
- Pas si chaque ancienne adresse redirige de façon permanente vers son équivalent sur le nouveau domaine, page par page, et que vous conservez l'ancien domaine enregistré pour que ces redirections continuent de fonctionner. Tout envoyer vers la nouvelle page d'accueil fait perdre ce que chaque page avait acquis. Une fois les redirections en place, faites pointer votre sitemap et votre propriété Search Console vers le nouveau domaine.
Want this done for you?
AgentCeres is a managed AI marketing team — specialists draft the work, you approve what ships. 14-day free trial, from $39/month.