Checklist de dépannage pour domaine personnalisé : DNS et SSL

Ce que « domaine personnalisé non fonctionnel » signifie généralement

« Domaine personnalisé non fonctionnel » est une expression générique pour plusieurs types de pannes. Votre navigateur affiche le symptôme, pas la cause. Avant de modifier quoi que ce soit, décrivez précisément ce que vous voyez.

Les symptômes typiques incluent :

• Une page « domaine introuvable »
• Le domaine charge le mauvais site
• Un avertissement « non sécurisé » alors que HTTPS est activé
• Des boucles de redirection (aller‑retour entre http et https, ou entre le domaine racine et www)

La plupart du temps, une seule chose est en défaut :

• Le DNS pointe vers le mauvais endroit, ou l’enregistrement nécessaire manque
• La cible d’hébergement n’est pas configurée pour ce nom d’hôte (le serveur ne reconnaît pas votre domaine)
• Le SSL n’a pas encore été émis, a été émis pour un autre nom d’hôte, ou ne peut pas être émis parce que le DNS ne correspond pas
• Le cache masque vos changements (cache du navigateur, cache du résolveur DNS, ou anciennes valeurs TTL)

Avant de dépanner, assurez‑vous d’avoir accès à deux endroits : là où vous éditez les enregistrements DNS (registrar ou fournisseur DNS) et là où vous rattachez le domaine côté hébergement. Par exemple, si vous connectez une application déployée sur Koder.ai à un domaine personnalisé, vous avez besoin d’un accès DNS pour le domaine et des paramètres de domaine dans la configuration d’hébergement ou de déploiement de l’app.

Certaines corrections sont instantanées (comme corriger une faute de frappe). D’autres prennent du temps. Les changements DNS peuvent mettre un moment à apparaître, et le SSL ne se complétera généralement pas tant que le DNS ne pointe pas correctement et que le domaine est accessible. L’objectif est d’arrêter de deviner et de confirmer chaque couche dans l’ordre.

Les petits concepts DNS qui comptent (sans le jargon)

La plupart des problèmes de domaine se résument à un décalage entre (1) le nom d’hôte que vous testez, (2) l’endroit où le DNS est géré, et (3) la cible réelle de l’enregistrement. Une fois ces trois éléments alignés, le SSL est généralement la dernière étape.

Les domaines ont deux formes courantes : le domaine racine (example.com, aussi appelé apex) et les sous‑domaines (www.example.com, app.example.com). Ils sont liés mais peuvent avoir des enregistrements DNS différents. Il est donc normal que www fonctionne tandis que l’apex échoue, ou l’inverse.

Les nameservers déterminent qui gère votre zone DNS. Si vous avez acheté un domaine chez une société mais que les nameservers pointent vers une autre, vous devez éditer le DNS là où pointent les nameservers. Beaucoup de situations « je l’ai mis à jour mais rien n’a changé » viennent du fait que les enregistrements ont été modifiés dans le mauvais tableau de bord.

Types d’enregistrements DNS en clair

Voici ce que font les principaux types d’enregistrements :

• A : pointe un nom vers une adresse IPv4 (par exemple 203.0.113.10)
• AAAA : pointe un nom vers une adresse IPv6
• CNAME : pointe un nom vers un autre nom d’hôte (courant pour www)
• TXT : stocke du texte utilisé pour la vérification et la sécurité (contrôles de propriété, SPF, etc.)

Le TTL est le « temps de mise en cache ». Un TTL bas signifie que les caches se rafraîchissent plus vite. Un TTL élevé signifie que vous pouvez devoir attendre plus longtemps, même après avoir corrigé l’enregistrement. Voir l’ancienne valeur pendant un moment peut être normal.

Étape par étape : un simple arbre de décision pour isoler la cause

Quand un domaine personnalisé échoue, vous pouvez généralement le classer dans quatre catégories : le DNS ne résout pas, le DNS résout vers le mauvais endroit, le SSL n’est pas prêt, ou cela échoue seulement pour certains utilisateurs à cause du cache.

Suivez cet arbre de décision :

1. Le domaine se résout‑il du tout ? Si vous voyez NXDOMAIN (ou « domaine introuvable »), l’enregistrement est manquant, vous éditez la mauvaise zone DNS ou les nameservers ne sont pas ceux attendus.
2. S’il se résout, pointe‑t‑il vers la bonne cible ? Si la page charge mais c’est le mauvais site, une page parking ou un ancien serveur, la cible A/AAAA/CNAME est erronée ou un ancien enregistrement prend la priorité.
3. S’il pointe correctement, l’échec concerne‑t‑il seulement le HTTPS ? Si HTTP marche mais HTTPS affiche un avertissement de certificat, le SSL peut être encore en émission, le nom d’hôte sur le certificat peut ne pas correspondre, ou la plateforme attend que le DNS se stabilise.
4. Ça fonctionne sur un appareil ou réseau mais pas sur un autre ? Considérez‑le comme du cache ou de la propagation.
5. Les redirections cassent‑elles (www vs apex) ? Si www fonctionne mais le domaine racine non (ou l’inverse), vous avez probablement configuré un seul nom d’hôte, ou des règles de redirection contradictoires.

Allez plus vite en notant l’exact nom d’hôte en échec (apex vs www) et le message d’erreur exact. Sur les plateformes qui automatisent domaines et certificats, la différence entre « hôte introuvable » et « certificat en attente » vous indique s’il faut corriger les enregistrements DNS ou simplement attendre le SSL après que le DNS soit visible.

Étape 1 : confirmer le nom d’hôte et la cible attendue

Beaucoup d’échecs de domaine commencent par une simple erreur d’alignement : vous avez configuré le DNS pour un nom d’hôte, mais vous testez un autre.

D’abord, notez précisément le nom d’hôte que vous voulez mettre en ligne. Le domaine racine ressemble à example.com. Un sous‑domaine ressemble à www.example.com ou app.example.com. Ce sont des entrées DNS séparées, donc « www fonctionne » ne signifie pas que le domaine racine fonctionnera.

Ensuite, trouvez la cible attendue fournie par votre hébergeur. Certaines plateformes fournissent une adresse IP (pour un enregistrement A ou AAAA). D’autres donnent un nom d’hôte cible (pour un CNAME). Si votre hébergeur fournit une valeur dans un écran de configuration de domaine, considérez‑la comme la source de vérité.

Avant de modifier quoi que ce soit, capturez ce qui est actuellement configuré. Restez simple :

• Copiez les enregistrements DNS actuels pour le nom d’hôte que vous changez
• Notez les enregistrements A, AAAA, CNAME et TXT existants
• Enregistrez le TTL

Confirmez aussi que vous éditez la bonne zone DNS. Il est facile de mettre à jour le mauvais domaine, le mauvais environnement ou le mauvais compte fournisseur.

Étape 2 : choisir le bon type d’enregistrement DNS (A, AAAA, CNAME, TXT)

Beaucoup de problèmes viennent simplement d’un mauvais type d’enregistrement pour le nom d’hôte que vous essayez de connecter. Commencez par séparer deux cas : le domaine racine (example.com) et un sous‑domaine (www.example.com). Ils se comportent différemment chez de nombreux fournisseurs DNS.

Un enregistrement A pointe un nom vers une adresse IPv4. De nombreuses configurations utilisent un A pour le domaine racine car certains fournisseurs n’autorisent pas un CNAME à l’apex. Si votre hôte vous donne une IP, un A est généralement correct.

Un AAAA est la version IPv6. Un AAAA résiduel pointant vers une ancienne destination peut créer un comportement confus « ça marche pour moi », car certains visiteurs utiliseront IPv6 tandis que d’autres utiliseront IPv4. Si votre hébergeur n’a pas fourni de cible IPv6, supprimer un AAAA incorrect corrige souvent des échecs incohérents.

Un CNAME pointe un sous‑domaine vers un autre nom d’hôte (souvent utilisé pour www). Il est utile quand l’hébergeur veut que vous cibliez un endpoint nommé qui peut changer en arrière‑plan.

Un TXT sert à la vérification et aux challenges (y compris certains contrôles SSL). Les erreurs courantes incluent le placement du TXT sur le mauvais nom (apex vs _acme-challenge vs un sous‑domaine), des espaces en trop ou une valeur collée incorrecte.

Avant d’avancer, recherchez les conflits. Ce sont les plus problématiques :

• Un CNAME sur un nom qui a aussi d’autres types d’enregistrements
• Plusieurs enregistrements A ou AAAA pour le même nom alors que vous n’en vouliez qu’un
• Anciens enregistrements laissés pour www ou le domaine racine
• Enregistrements TXT créés sur le mauvais nom

Étape 3 : vérifier les nameservers pour s’assurer que vous éditez le bon endroit

Beaucoup de cas « domaine personnalisé non fonctionnel » ne concernent pas la valeur de l’enregistrement. Ils surviennent parce que l’enregistrement a été ajouté chez le mauvais fournisseur. Si votre domaine utilise les nameservers du Fournisseur A, changer des enregistrements dans le tableau de bord du Fournisseur B ne servira à rien, même si les enregistrements y paraissent corrects.

Confirmer les nameservers autoritaires

Vérifiez quels nameservers votre domaine utilise réellement. Vous pouvez généralement le voir dans les paramètres du registrar sous « Nameservers ». Pour un second avis, interrogez le DNS depuis votre ordinateur :

dig NS example.com

Les nameservers renvoyés par cette commande sont les autoritaires.

Un contrôle rapide :

• Si votre hébergeur DNS vous donne des nameservers comme ns1... et ns2..., ces valeurs exactes doivent apparaître chez le registrar.
• Si vous avez récemment changé de fournisseur DNS, confirmez que la bascule est complète avant de faire d’autres modifications d’enregistrement.
• Si une plateforme affiche des « enregistrements suggérés », c’est généralement une aide. Vous devez quand même ajouter les enregistrements chez le fournisseur DNS autoritaire.

Pourquoi « je l’ai mis à jour, mais rien n’a changé » arrive

Si vous mettez à jour des enregistrements chez le mauvais fournisseur, vous verrez souvent deux tableaux de bord qui ne correspondent pas. Seuls les nameservers autoritaires comptent.

Faites aussi attention aux délais après un changement de nameservers chez le registrar. Pendant la fenêtre de transition, les résultats peuvent paraître incohérents selon l’endroit d’où vous testez. Si les nameservers changent encore, suspendrez les modifications d’enregistrement jusqu’à ce que l’ensemble soit stable, puis continuez.

Étape 4 : vérifications de propagation et de cache qui aident vraiment

La « propagation » n’est pas un interrupteur unique. C’est une chaîne de caches DNS (FAI, opérateur mobile, résolveurs publics et vos propres appareils) qui se mettent à jour à des vitesses différentes. C’est pour ça que votre domaine peut fonctionner pour un collègue mais pas pour vous.

Le TTL (time to live) indique combien de temps les caches peuvent garder une réponse. Si l’ancien TTL était d’une heure, certaines personnes verront l’ancienne valeur pendant près d’une heure. Baisser le TTL aide seulement si vous l’avez fait avant de faire le changement.

Pour séparer les délais de cache des erreurs réelles, faites quelques vérifications rapides :

• Testez sur le Wi‑Fi du domicile ou du bureau, puis sur les données mobiles
• Demandez à quelqu’un sur un autre réseau d’essayer
• Utilisez une fenêtre privée (pour éliminer les redirections en cache)
• Redémarrez votre appareil ou videz le cache DNS local si vous savez le faire
• Vérifiez de nouveau le nom d’hôte exact (apex vs www)

Si l’enregistrement est erroné partout où vous vérifiez (mauvaise IP, www manquant, ancien CNAME), corrigez‑le. Si les enregistrements semblent corrects dans la plupart des endroits mais qu’un réseau montre encore l’ancienne valeur, c’est généralement un délai de cache.

Étape 5 : timing du SSL et pourquoi « attendre un peu » est parfois la bonne action

Les certificats SSL échouent généralement pour une raison basique : le fournisseur de certificat ne peut pas valider le domaine tant que le DNS ne pointe pas au bon endroit de façon cohérente.

La séquence normale est simple :

1. Configurez les enregistrements DNS corrects.
2. Attendez qu’ils se résolvent correctement depuis plusieurs points.
3. Effectuez les vérifications requises (souvent un enregistrement TXT).
4. Laissez l’émission du certificat se terminer.

Les blocages courants sont faciles à manquer. Une mauvaise cible A ou CNAME envoie les contrôles de validation vers le mauvais serveur. Un AAAA obsolète peut remplacer votre A fonctionnel pour certains visiteurs, provoquant des échecs HTTPS seulement pour eux. L’absence d’un TXT requis peut empêcher l’émission.

Utilisez les symptômes pour distinguer « encore en émission » de « mal configuré » :

• Encore en émission : HTTP peut fonctionner, mais HTTPS affiche un certificat par défaut temporaire ou un message du type « non valide pour le moment ».
• Mal configuré : vous voyez un autre site, une page de parking de FAI, ou la résolution DNS échoue (NXDOMAIN).

Pendant que vous attendez, n’alternez pas sans cesse les enregistrements. Chaque changement remet le compteur à zéro et peut créer un monde divisé où différents réseaux voient des réponses différentes. Configurez correctement une fois, puis revérifiez la résolution et la validation jusqu’à ce que le certificat soit émis.

Si vous utilisez une plateforme comme Koder.ai, le flux le plus sûr est le même : confirmez que le DNS pointe vers la cible attendue, supprimez les AAAA incorrects s’ils existent, et laissez le SSL le temps d’être émis après la stabilisation du DNS.

Comment vérifier chaque étape (sans deviner)

Un bon dépannage consiste surtout à comparer : ce que vous voyez vs ce que vous attendez. Ne vous fiez pas à « ça marche sur mon téléphone ». Utilisez des contrôles reproductibles.

Vérifier les réponses DNS par rapport à la cible attendue

Utilisez un outil de recherche DNS (comme nslookup ou dig) et confirmez que la valeur retournée correspond à ce que vous vouliez (une IP pour A ou AAAA, un nom d’hôte pour CNAME, un token pour TXT).

# Apex (domaine racine)
dig example.com A

dig example.com AAAA

# Sous‑domaine www
dig www.example.com CNAME

# TXT (souvent utilisé pour la vérification)
dig example.com TXT

Vérifiez les deux noms que vous pourriez utiliser : l’apex (example.com) et www (www.example.com). Il est courant que l’un soit correct tandis que l’autre pointe toujours vers l’ancien emplacement.

Vérifier le comportement du navigateur (HTTP, HTTPS et redirections)

Ouvrez http:// et https:// pour l’apex et pour www. Vous voulez un domaine « maison » clair et une redirection propre.

• Choisissez un domaine canonique (soit l’apex, soit www) et redirigez l’autre vers celui‑ci.
• Évitez les redirections ping‑pong (A redirige vers B, puis B redirige vers A).
• Si HTTP fonctionne mais HTTPS échoue, le SSL est soit en cours d’émission, soit le DNS pointe encore vers une destination inattendue.

Si les résultats diffèrent selon le réseau, vous observez probablement de la propagation ou du cache. Tenez un petit journal : ce que vous avez changé, où vous l’avez changé, l’heure et ce que vous avez observé.

Erreurs courantes qui font perdre des heures

La plupart des problèmes DNS et SSL ne sont pas des mystères. Ce sont de petites erreurs qui vous font vérifier la mauvaise chose, ou modifier les choses trop vite pour obtenir une lecture claire.

La perte de temps la plus courante est d’éditer le DNS à deux endroits. Cela arrive souvent après un changement de nameservers : vous mettez à jour des enregistrements chez le registrar, mais le DNS est en fait hébergé ailleurs (ou l’inverse). Tout a l’air correct dans un tableau de bord, mais rien ne change publiquement.

Une autre erreur classique est d’essayer de mettre un CNAME sur le domaine racine chez un fournisseur qui ne le permet pas. Vous devrez peut‑être utiliser un enregistrement A, ou un enregistrement de type ALIAS/ANAME si votre fournisseur le propose.

L’IPv6 peut aussi poser problème. Laisser un ancien AAAA peut envoyer certains visiteurs vers le mauvais serveur tandis que d’autres atteignent correctement l’IPv4.

Faites attention aux enregistrements « au cas où ». Plusieurs enregistrements A peuvent se comporter comme un équilibrage de charge accidentel si une cible est erronée, surtout quand vous pointez un domaine personnalisé vers une application hébergée.

Une règle finale : arrêtez de remettre le compteur à zéro.

• Ne changez pas les enregistrements toutes les quelques minutes.
• Ne mélangez pas anciennes et nouvelles cibles en même temps.
• Attendez que les caches se stabilisent avant de juger des résultats.

De petites modifications calmes valent mieux que des bidouillages constants.

Exemple réaliste : www fonctionne mais le domaine racine ne fonctionne pas

Vous lancez une nouvelle app et configurez example.com et www.example.com. Quelques minutes plus tard, www.example.com charge correctement, mais le domaine racine affiche une erreur DNS, charge un ancien site, ou le HTTPS reste en attente. Ce schéma est courant et a généralement une cause simple.

Commencez par la question ennuyeuse : éditez‑vous le DNS au bon endroit ? Si votre domaine est enregistré chez une société mais que le DNS est hébergé ailleurs, vous pouvez modifier des enregistrements toute la journée sans résultat. Vérifiez d’abord les nameservers, puis ouvrez le panneau DNS du fournisseur vers lequel ces nameservers pointent.

Comparez ensuite les deux noms d’hôtes. www est typiquement un CNAME. Le domaine racine est plus délicat : beaucoup de fournisseurs n’autorisent pas un CNAME à l’apex, il nécessite souvent un enregistrement A vers une IP, ou un enregistrement ALIAS/ANAME si disponible.

Un chemin de décision utile :

• Nameservers incorrects ou inattendus ? Corrigez‑les d’abord.
• Nameservers corrects mais example.com n’a pas d’enregistrement (ou pointe ailleurs) ? Corrigez l’apex.
• Les enregistrements semblent corrects mais le comportement diffère selon l’appareil ou le réseau ? Patientez pour la propagation et videz les caches.
• Le DNS se résout correctement mais HTTPS échoue ou est bloqué ? Le SSL attend une résolution DNS cohérente.

L’état final attendu est ennuyeux : example.com et www.example.com pointent vers la même application, l’un est canonique (l’autre redirige), et HTTPS est valide.

Checklist rapide à exécuter en 5 minutes

Quand une configuration de domaine échoue, la plupart des corrections viennent de quelques vérifications rapides. Faites‑les avant de changer autre chose.

• Confirmez que vous éditez le DNS au bon endroit (faites correspondre votre tableau de bord aux nameservers autoritaires du domaine).
• Vérifiez que le nom d’hôte et la cible sont exacts (pas de sous‑domaine manquant, pas de point en trop). Comparez le type d’enregistrement (A, AAAA, CNAME, TXT) à ce que votre hébergeur attend.
• Supprimez les conflits (CNAME plus d’autres enregistrements sur le même nom, ou anciens A/AAAA inutiles).
• Vérifiez depuis deux points de vue (données mobiles et Wi‑Fi). Si l’un fonctionne et pas l’autre, c’est généralement du cache ou de la propagation.
• Respectez le TTL. Si le TTL est de 300 secondes, attendez 5 à 10 minutes avant de juger. Si le TTL est 3600, comptez plutôt une heure.

Après que le DNS soit clairement correct, vérifiez ensuite le SSL. Beaucoup de plateformes n’émettent le certificat que lorsque votre domaine se résout de façon cohérente vers la bonne cible. Si vous vérifiez trop tôt, vous pouvez confondre un délai normal avec une erreur réelle.

Si vous ajoutez un domaine personnalisé à une application déployée sur Koder.ai, considérez l’écran de configuration du domaine comme la référence pour la cible attendue, puis revérifiez le statut uniquement après que le DNS ait eu le temps de se propager.

Prochaines étapes : rendre la configuration de domaine répétable pour chaque lancement

La manière la plus rapide d’éviter de répéter les erreurs DNS et SSL est de garder une courte « note de configuration de domaine » pour chaque projet. C’est un runbook réutilisable que vous pouvez copier la prochaine fois que vous lancez quelque chose.

Modèle simple de note de configuration de domaine

Conservez‑le dans la documentation du projet et remplissez‑le avant de toucher au DNS :

• Domaines et noms d’hôtes (apex, www et tout sous‑domaine)
• Types d’enregistrements et cibles attendues (A, CNAME, TXT) et leur origine
• Où le DNS est édité (quel fournisseur) et les nameservers actifs
• Attentes SSL (qui l’émet, à quoi ressemble l’état « prêt »)
• Étapes de vérification à exécuter (outil et résultat attendu)

Pendant le lancement, désignez une personne responsable du DNS. Le DNS casse le plus souvent quand deux personnes « corrigent » des choses différentes en même temps (par exemple l’un change les nameservers pendant que l’autre édite des enregistrements).

Côté hébergement, prévoyez des retours en arrière sûrs. Si votre plateforme prend en charge des snapshots ou rollback, faites‑en un avant de modifier le routage pour pouvoir revenir rapidement à l’état précédemment fonctionnel. Si vous construisez sur Koder.ai, vous pouvez utiliser Planning Mode pour écrire les étapes du domaine, les appliquer dans l’ordre et revenir en arrière si un changement casse la production.

Quand escalader (et vers qui)

Si vous avez confirmé que le DNS est correct et que vous voyez encore des échecs, arrêtez de deviner et escaladez avec des preuves :

• Le registrar indique des nameservers verrouillés ou vous ne pouvez pas les modifier
• Les modifications DNS n’apparaissent nulle part après la fenêtre TTL attendue
• Le SSL échoue longtemps après que le DNS se résout correctement (comptez des heures, pas des minutes)
• Vous voyez des enregistrements conflictuels que vous ne pouvez pas supprimer (bug de l’UI du fournisseur ou DNS split)

Quand vous escaladez, incluez le nom d’hôte, les enregistrements attendus, les résultats de résolveur actuels et des horodatages. Cela transforme des allers‑retours lents en une résolution rapide.