Le domaine personnalisé d'un client bloque pour une raison qui revient plus que toutes les autres : le marketing croit que c'est à l'IT de jouer, et l'IT croit que le marketing a déjà tout envoyé. Techniquement, rien n'est cassé. La demande dort juste dans une boîte mail.
Ce guide passe en revue les quatre endroits où une config se coince, comment savoir qui contrôle le DNS du client avant de promettre une date, et LA demande à envoyer à l'IT pour qu'elle ne puisse pas être mal comprise.
TLDR : demande un seul CNAME sur un sous-domaine, envoie le hostname et la cible exacts dès le premier message, désigne une personne qui suit le dossier, et n'assigne le domaine à la page qu'une fois le certificat affiché comme actif. La plupart des retards viennent du passage de relais : un suivi bien calé règle plus de choses que n'importe quelle astuce DNS.
Les quatre endroits où le domaine personnalisé d'un client se coince
Voici où on voit les configs bloquer, dans l'ordre où ça arrive.
| Étape | Ce qui cloche | Ce que ça donne |
|---|---|---|
| Demande | L'IT reçoit « merci de pointer le domaine vers notre nouvel outil » sans hostname ni cible | Une réponse qui demande quoi faire, trois jours plus tard |
| Enregistrement DNS | Mauvais type d'enregistrement, enregistrement sur le domaine racine, ou faute de frappe dans la cible | Le domaine ne pointe jamais vers ta page |
| Certificat | L'enregistrement est bon mais le certificat n'est pas encore émis | Le statut reste sur Pending, le navigateur affiche un avertissement |
| Assignation | Le domaine est vérifié mais pas rattaché au portail ou à la page de liens | Le domaine affiche une page blanche ou par défaut |
Trouve d'abord ton étape. Chacune a sa propre solution, et la plupart des agences renvoient le même mail pour régler un problème qui se joue deux étapes plus loin.
Savoir qui contrôle le DNS du client avant de promettre une date
La personne qui a validé le projet n'est presque jamais celle qui peut modifier la zone. Avant de donner une date de mise en ligne au client, pose trois questions :
- Qui gère le DNS du domaine ? Ça peut être une équipe IT, une agence web d'il y a trois ans, ou le login registrar du fondateur que plus personne ne retrouve.
- Où est-il hébergé ? Le registrar (GoDaddy, Namecheap, etc.) et l'hébergeur DNS peuvent être deux entreprises différentes.
- Y a-t-il un proxy ou une couche de sécurité devant ? Un proxy chez l'hébergeur DNS peut empêcher l'émission du certificat.
Si la réponse à la première question est « on n'est pas sûrs », stop, règle ça d'abord. Récupérer un login registrar perdu peut prendre plus de temps que toute la config.
Envoie à l'IT une demande qui ne peut pas être mal comprise
Les équipes IT traitent chaque demande floue comme un ticket de sécurité. Fais la tienne courte et précise. Copie ceci et complète les trous :
Merci d'ajouter un enregistrement DNS pour nos outils de réseaux sociaux. Type : CNAME. Nom : portal (l'adresse devient donc portal.clientname.com). Cible : le hostname qu'on te donne ci-dessous. Laisse tous les autres enregistrements tels quels. Réponds-moi quand c'est sauvegardé et je confirme de mon côté.
Trois détails comptent ici :
- Utilise un sous-domaine. Un CNAME ne peut pas être placé sur le domaine racine, et demander à l'IT de toucher au domaine racine rend la demande risquée à leurs yeux.
- Dis ce que tu ne demandes pas. « Laisse tous les autres enregistrements tels quels » lève leur plus grosse inquiétude.
- Demande une réponse, pas un silence. Un enregistrement sauvegardé sans message ne t'apprend rien.
Un enregistrement devient généralement visible en quelques minutes à quelques heures. Laisse passer un jour ou deux avant de conclure que quelque chose cloche.
Pourquoi le certificat reste sur Pending alors que l'enregistrement est bon
C'est le blocage qui énerve tout le monde, parce que le DNS a l'air correct. La plateforme doit voir l'enregistrement avant de pouvoir émettre le certificat du domaine, donc vérifie dans cet ordre :
- Le hostname correspond exactement. Une lettre en trop ou un espace collé à la fin suffit.
- Aucun proxy devant l'enregistrement. Si l'hébergeur DNS fait proxy, passe l'enregistrement en DNS only jusqu'à l'émission du certificat.
- Aucun enregistrement CAA ne bloque l'émetteur. Certaines équipes sécurité en ajoutent et les oublient des années plus tard.
- Assez de temps s'est écoulé. Laisse passer quelques heures avant d'escalader.
Notre pas-à-pas sur quoi vérifier quand le SSL d'un domaine personnalisé échoue creuse chacun de ces points.
Assigne le domaine à la page en dernier, et donne un responsable au suivi
Ne rattache le domaine au portail ou à la page de liens du client qu'une fois le statut affiché comme actif. Le faire trop tôt, c'est comme ça qu'un domaine vérifié finit par afficher une 404.
Si tu gères des portails clients ou des pages link-in-bio sur Mydrop, le statut du domaine et l'état du certificat sont visibles de ton côté : tu peux dire à l'IT exactement ce qui manque, au lieu de deviner. Découvre comment le portail client et les pages link-in-bio utilisent un domaine de marque, et pourquoi les clients en réclament un dans pourquoi les clients d'agence ont besoin de leur propre domaine personnalisé.
Ensuite, mets des dates dessus :
| Jour | Action | Responsable |
|---|---|---|
| 0 | Envoyer la demande avec hostname et cible exacts | Toi |
| 2 | Demander un statut en une ligne | Toi |
| 5 | Proposer un appel de 15 minutes avec l'IT, écran partagé | Toi |
| Après sauvegarde de l'enregistrement | Confirmer le statut, assigner la page, tester sur un téléphone | Toi |
Prochaine étape : ouvre le dernier client dont le domaine est encore en attente, repère à laquelle des quatre étapes ça bloque, et envoie la demande ci-dessus avec le hostname exact rempli, aujourd'hui.


















Avis Google
Avis Trustpilot