Un transfert de nom de domaine mal préparé se solde par des emails perdus, un site inaccessible ou un domaine bloqué en statut pendingTransfer pendant des jours. La procédure elle-même est simple sur le papier : déverrouiller, récupérer le code EPP, valider côté nouveau registrar. Ce qui pose problème, ce sont les détails techniques que la plupart des guides survolent, notamment la gestion de la zone DNS pendant la bascule et les spécificités liées aux extensions nationales.
Zone DNS et enregistrements à sauvegarder avant le transfert de domaine
Le transfert déplace le contrôle administratif du domaine, pas la zone DNS elle-même. Nous observons régulièrement des pertes d’enregistrements MX ou TXT après migration, parce que la zone hébergée chez l’ancien registrar n’a pas été dupliquée chez le nouveau avant la bascule.
A lire également : Comment recevoir son courrier sans adresse : solutions et conseils pratiques à connaître
Avant toute manipulation, exportez l’intégralité de votre zone DNS. Vérifiez chaque type d’enregistrement : A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), et les éventuels enregistrements SRV. Si votre domaine utilise DNSSEC, désactivez-le avant de lancer le transfert : un enregistrement DS orphelin chez le registre provoque des résolutions échouées tant que le nouveau registrar n’a pas republié ses propres clés.
Recréez tous ces enregistrements chez le nouveau prestataire ou sur un service DNS tiers (Cloudflare, Route 53) avant de déclencher le transfert. Une fois la zone prête des deux côtés, la bascule administrative n’a plus d’impact sur la résolution. Si vous cherchez comment transférer un nom de domaine avec Fireblog, vous retrouverez cette logique de préparation DNS appliquée pas à pas.
A voir aussi : Répondre sur Meetic sans payer : astuces pour échanger sans abonnement
Code EPP, déverrouillage et protection WHOIS : les prérequis techniques du transfert
Trois verrous bloquent un transfert si vous ne les levez pas dans le bon ordre.
- Le statut clientTransferProhibited (ou registrar lock) doit être retiré depuis l’interface de votre registrar actuel. Tant qu’il est actif, toute demande de transfert est refusée automatiquement par le registre.
- Le code d’autorisation EPP (ou Auth-Code) est un mot de passe à usage unique lié au domaine. Sa durée de validité varie selon le registrar, parfois quelques jours seulement. Récupérez-le au moment où vous êtes prêt à lancer la procédure, pas en avance.
- La protection de confidentialité WHOIS doit être désactivée temporairement. Plusieurs registrars masquent l’adresse email du titulaire derrière un proxy. L’email de validation du transfert est envoyé à l’adresse WHOIS : si elle pointe vers un service de confidentialité qui filtre ou redirige mal, la validation échoue silencieusement.
Nous recommandons de vérifier le WHOIS public du domaine après avoir désactivé la protection, pour confirmer que l’adresse email affichée est bien celle que vous consultez. Un email de validation non reçu est la première cause de transfert avorté.
Le blocage de soixante jours après modification WHOIS
La politique ICANN impose un verrouillage de soixante jours après tout changement de titulaire sur les gTLD (.com, .net, .org). Si vous avez récemment modifié le nom ou l’email du titulaire dans le WHOIS, le transfert sera refusé pendant cette période. Planifiez vos mises à jour de coordonnées bien avant la migration, ou effectuez-les après.
Transfert de domaine selon l’extension : gTLD, ccTLD et cas particuliers
Les articles généralistes décrivent un processus universel. En pratique, chaque type d’extension obéit à ses propres règles de transfert.
Pour les gTLD (.com, .net, .org), le processus est standardisé par l’ICANN : code EPP, demande chez le nouveau registrar, email de confirmation, puis un délai de cinq à sept jours pendant lequel l’ancien registrar peut approuver ou laisser expirer la demande. L’approbation explicite côté ancien registrar accélère la procédure.
Les ccTLD (extensions nationales) suivent des règles différentes. Le .fr, géré par l’AFNIC, utilise un code d’autorisation similaire au code EPP, mais la procédure de changement de bureau d’enregistrement passe par une Demande d’Opération Afnic (DOA). Le .uk fonctionne avec un tag system : vous demandez à votre registrar actuel de changer le tag IPS vers le nouveau prestataire, sans code EPP. Le .de (DENIC) impose un Auth-Code mais avec un processus de validation distinct.
Ces différences ont un impact direct sur les délais. Un transfert de .com prend généralement moins d’une semaine. Un ccTLD peut nécessiter plusieurs semaines si des documents d’identité ou de résidence sont exigés par l’autorité nationale.
Emails et certificat SSL après la bascule
Le transfert de domaine ne transfère pas votre hébergement web ni votre messagerie. Si vos enregistrements MX pointaient vers les serveurs de l’ancien registrar, vos emails cesseront de fonctionner dès que la zone DNS sera modifiée. Vérifiez que les MX pointent vers votre fournisseur de messagerie réel (Google Workspace, Microsoft 365, serveur dédié) et non vers un service lié au registrar sortant.
Côté SSL, un certificat Let’s Encrypt se renouvelle automatiquement si la validation DNS ou HTTP est toujours fonctionnelle. Un certificat payant lié à l’ancien hébergeur devra être réémis ou transféré. Contrôlez la date d’expiration et le mode de validation avant le transfert pour éviter un passage en HTTP non sécurisé.
Checklist de vérification post-transfert du nom de domaine
Une fois le domaine affiché chez le nouveau registrar, le travail n’est pas terminé. Nous constatons que la majorité des incidents surviennent dans les quarante-huit heures suivant la bascule, quand personne ne vérifie plus rien.
- Comparez la zone DNS active avec votre sauvegarde initiale. Chaque enregistrement A, MX, CNAME et TXT doit correspondre exactement.
- Envoyez un email test vers et depuis chaque adresse liée au domaine pour confirmer le bon fonctionnement des MX.
- Vérifiez la résolution DNSSEC si vous l’avez réactivée : un outil comme DNSViz permet de repérer une chaîne de confiance cassée.
- Réactivez le verrouillage du domaine (clientTransferProhibited) et la protection WHOIS chez le nouveau registrar.
- Contrôlez que le certificat SSL est valide et que votre site répond bien en HTTPS sans erreur de certificat.
Le transfert d’un nom de domaine reste une opération administrative, pas technique au sens strict. Ce qui provoque les coupures, c’est l’absence de préparation DNS en amont et l’oubli des vérifications en aval. Préparez la zone avant, vérifiez tout après : entre les deux, le transfert lui-même ne prend que quelques clics.