Changer de bureau d'enregistrement pour un nom de domaine, étape par étape

Transférer un nom de domaine consiste à confier sa gestion à un nouveau registrar en gardant le même nom : le transfert repose sur un code d'autorisation remis par le service actuel, depuis l'espace client. Le site internet et les e-mails restent en ligne si la zone DNS existe déjà ailleurs au moment de la bascule.

Ce qu'un transfert de domaine change, et ce qu'il ne touche pas

Un transfert de domaine change uniquement le bureau d'enregistrement qui gère le nom ; l'hébergement du site, les boîtes mail et la zone DNS sont trois services distincts, souvent vendus ensemble mais indépendants. Le registrar loue le nom auprès du registre : l'Afnic pour le .fr, Verisign pour le .com et le .net, d'autres opérateurs pour chaque domaine de premier niveau. Le mot registraire, employé par l'Afnic, désigne le même fournisseur ; les extensions nationales (ccTLD, comme le .fr, le .be ou le .de) suivent les règles du registre de leur pays, les extensions génériques celles de l'ICANN. L'hébergeur fait tourner le site web, parfois la messagerie. La zone DNS, enfin, peut être servie par le registrar, par l'hébergeur ou par un troisième acteur comme un réseau de diffusion de contenu.

Transférer un nom de domaine n'oblige donc pas à déplacer le site, à une condition : savoir où se trouve la zone DNS. Si elle est hébergée chez l'ancien registrar, elle disparaît souvent à la fin du contrat, et le site devient injoignable alors que le nom fonctionne toujours. La migration d'hébergement, elle, déplace les fichiers et la base de données d'un serveur à l'autre : c'est une autre opération, qui peut se faire avant, pendant ou sans transfert. Beaucoup de pages mélangent les deux mots ; ici, transfert désigne seulement le changement de registrar.

Le titulaire, lui, reste le même : le transfert ne modifie ni le droit d'usage du nom ni la personne inscrite dans le whois. Changer de titulaire relève d'une autre procédure, traitée plus bas.

Une entreprise qui possède plusieurs noms gagne souvent à les centraliser chez un seul registraire : un renouvellement oublié chez un fournisseur secondaire suffit à perdre une marque, et centraliser les noms simplifie la sécurité des accès (double authentification sur l'espace client) comme le suivi des échéances. Les noms qui protègent une marque dans plusieurs pays sont les premiers concernés, car chaque ccTLD a son propre calendrier de renouvellement.

Avant la demande de transfert : deux vérifications qui évitent les erreurs

La préparation d'un transfert de domaine tient en deux contrôles faits depuis un terminal ou l'interface de gestion du registrar : lire l'état du nom, puis recopier sa zone. Ces deux gestes prennent une dizaine de minutes et évitent la plupart des erreurs constatées sur les forums de support.

Lire le whois du domaine

Une requête whois sur le nom indique le registrar actuel, la date d'expiration et les statuts EPP du domaine. La mention clientTransferProhibited signale un verrou posé par le registrar à la demande du client : il se retire dans l'espace client. Le whois montre aussi l'adresse de contact du titulaire, quand elle n'est pas masquée ; c'est à cette adresse e-mail que partiront les messages de confirmation, il faut donc qu'elle soit lue.

whois exemple.fr | grep -i -E 'registrar|expir|status'
dig +short NS exemple.fr

La seconde commande donne les serveurs de noms en service : s'ils portent le nom du registrar actuel, la zone DNS vit chez lui et doit être recopiée.

Recopier la zone DNS

La zone DNS d'un domaine se recopie enregistrement par enregistrement : A et AAAA du site, MX du courrier, CNAME des sous-domaines, TXT de vérification et TXT d'authentification. Le TXT de l'enregistrement SPF, la clé DKIM et la règle DMARC sont les plus souvent oubliés, et leur absence ne se voit pas tout de suite : le courrier part, puis finit en indésirables chez les grands webmails. Un export au format texte, quand l'interface le propose, sert de référence pour comparer les deux zones ligne à ligne.

Comment obtenir le code d'autorisation ?

Le code d'autorisation d'un nom de domaine se demande au registrar actuel, depuis l'espace client, dans la fiche du nom ; selon les interfaces, il s'appelle auth code, code EPP, AuthInfo, Auth_Info ou code de transfert. Pour les extensions génériques comme le .com, la page de l'ICANN destinée aux titulaires indique que le registrar doit fournir ce code dans les cinq jours calendaires suivant la demande. Pour le .fr, l'Afnic rappelle que le bureau d'enregistrement le remet gratuitement.

Trois blocages reviennent avec ce code. Le verrou de transfert reste actif : il faut d'abord déverrouiller le nom dans l'interface de gestion. L'adresse e-mail du titulaire est périmée : le code part dans une boîte que plus personne ne lit, et la correction des coordonnées passe en premier. Le code a expiré : certains registraires lui donnent une durée de validité courte, il suffit alors d'en générer un nouveau. Faute de bouton dans l'espace client, une demande écrite au support ou à la page de contact du registrar suffit ; la refuser sans motif prévu par la politique n'est pas permis.

L'ICANN a adopté une révision de sa politique de transfert, mise en œuvre par étapes : certains écrans emploient déjà le terme TAC, pour Transfer Authorization Code. Le principe ne change pas, c'est toujours le mot de passe du domaine.

Le processus pour obtenir le code reste le même d'un fournisseur à l'autre ; seule la démarche technique varie : bouton dans la fiche du nom, envoi par e-mail au contact du registrant, ou document signé pour certaines extensions et certains comptes d'entreprise. À ce propos, le code se transmet comme un mot de passe, jamais dans un message public ni dans un ticket partagé.

Changer de registrar : la marche à suivre chez le nouveau bureau d'enregistrement

Changer de registrar se fait côté nouveau bureau d'enregistrement : c'est lui qui reçoit la demande, l'ancien se contente de la laisser passer ou de la refuser. L'ordre des étapes compte, parce que chaque oubli se paie en jours.

1. Recopier la zone DNS chez le futur gestionnaire de la zone, et abaisser le TTL des enregistrements importants quelques jours avant, par exemple à 300 secondes.
2. Vérifier les coordonnées du titulaire, surtout son adresse e-mail.
3. Retirer le verrou de transfert dans l'espace client du registrar actuel.
4. Récupérer le code d'autorisation.
5. Commander le transfert chez le nouveau registrar en saisissant le nom et ce code, puis valider les messages de confirmation reçus par e-mail.
6. Contrôler les serveurs de noms une fois le transfert terminé, puis seulement résilier l'ancien service DNS.

Le code d'autorisation est gratuit ; le transfert lui-même est généralement payant, ses frais couvrant souvent le renouvellement d'une année, selon la politique tarifaire de chaque registraire. Les informations à fournir pour effectuer la commande sont généralement disponibles dans la fiche du nom : nom exact, code, coordonnées du registrant.

La plupart des bureaux d'enregistrement proposent, dans le même tunnel de commande, de reprendre les serveurs de noms en place : c'est l'option la plus sûre, car rien ne bouge côté DNS pendant le transfert lui-même. Le passage des serveurs de noms vers le nouveau prestataire se fait ensuite, à froid, une fois la zone contrôlée.

Combien de temps prend un transfert de domaine ?

Un transfert de domaine générique se conclut en général en moins d'une semaine : une fois la demande de transfert lancée, l'ancien registrar dispose de cinq jours calendaires pour la refuser, faute de quoi la politique de l'ICANN la considère comme acceptée. Beaucoup de registrars proposent un bouton pour l'accepter tout de suite, ce qui raccourcit le délai à quelques heures. Aucune durée en moyenne n'est publiée par l'ICANN ni par l'Afnic : le calendrier dépend de la réactivité des deux prestataires et du titulaire qui doit confirmer.

Plusieurs règles allongent ce temps ou bloquent l'opération. Selon la page de l'ICANN destinée aux titulaires, le registrar peut refuser un transfert dans les 60 jours qui suivent la création du nom ou un précédent transfert, et un changement de titulaire peut entraîner un blocage de 60 jours. Un domaine expiré ou proche de son échéance se transfère mal : le renouveler d'abord, ou s'y prendre plusieurs semaines avant la date d'expiration, évite de se retrouver dans la période de rédemption, où le nom ne bouge plus. Pour les extensions génériques, le transfert ajoute en principe une année au cycle de vie du nom ; pour d'autres, dont certaines extensions nationales, cela dépend des règles du registre et de l'offre du registrar.

Garder site, courrier et certificat SSL en service pendant la bascule

Le site et le courrier d'un nom transféré ne s'arrêtent que si la zone DNS change mal : le transfert seul, serveurs de noms conservés, ne coupe rien. Le risque arrive au moment où les serveurs de noms passent chez le nouveau prestataire. La nouvelle zone doit alors être complète ; un oubli du MX ou du TXT de la clé de signature se traduit par des messages perdus ou classés en indésirables. La syntaxe à publier pour la clé DKIM se vérifie avant la bascule, pas le jour où les plaintes arrivent.

Le TTL abaissé quelques jours plus tôt limite le temps de propagation à quelques minutes : une correction se voit vite. Le certificat SSL du site, lui, est lié au nom et non au registrar ; un certificat gratuit renouvelé automatiquement par l'hébergeur continue de fonctionner tant que les enregistrements A et AAAA pointent au même endroit. Seule exception : une validation par enregistrement DNS, à recopier dans la nouvelle zone comme le reste. Un blog, une boutique ou un simple site vitrine traversent ainsi l'opération sans interruption visible.

Migrer l'hébergement dans le même mois n'est pas nécessaire : séparer les deux démarches limite le risque d'interruption, car une panne se rattache alors à une seule cause. Pour effectuer une migration d'hébergement, le délai de sécurité le plus utile reste celui du TTL, réglé avant chaque changement technique. Les informations de la nouvelle zone se contrôlent avec dig sur chaque enregistrement, avant de couper quoi que ce soit chez l'ancien fournisseur.

Transfert refusé ou bloqué : lire les statuts dans l'ordre

Un transfert de domaine refusé laisse presque toujours une trace dans les statuts EPP du nom, que le whois affiche et que la RFC 5731 de l'IETF définit. Les lire dans l'ordre suivant donne la cause sans attendre le support.

• clientTransferProhibited : verrou posé à la demande du client, à retirer dans l'espace client du registrar actuel.
• serverTransferProhibited : verrou posé par le registre ; il signale souvent un litige, une procédure en cours ou une protection renforcée, et seul le registrar peut en demander la levée.
• pendingTransfer : une demande est déjà en cours ; une seconde commande serait refusée.
• pendingDelete ou période de rédemption : le nom a expiré et n'est plus transférable tant qu'il n'est pas restauré.

Si aucun de ces statuts n'apparaît, la cause tient presque toujours au code d'autorisation (mal recopié, expiré) ou à une confirmation restée sans réponse dans la boîte du titulaire. Le message d'erreur du nouveau registrar donne également un motif, souvent plus précis que les écrans de l'ancien.

Changement de propriété et transfert : deux opérations distinctes

Le changement de propriété d'un nom de domaine modifie le titulaire inscrit au whois, alors que le transfert modifie le registrar ; les deux se font souvent en même temps lors d'une vente de site, et c'est là que surgissent les conséquences les plus lourdes. Pour les extensions génériques, la page de l'ICANN prévient qu'un changement de titulaire peut bloquer tout transfert pendant 60 jours, sauf si le titulaire a refusé ce verrou au moment du changement, quand le registrar le propose. Lors d'une cession, mieux vaut donc transférer le nom vers le registrar de l'acheteur d'abord, puis changer le titulaire chez ce dernier.

Pour le .fr, l'Afnic traite la transmission d'un nom comme une opération distincte du transfert, avec ses propres justificatifs. La date d'expiration, elle, suit le nom : un domaine cédé ou transféré garde son échéance, à laquelle peut s'ajouter l'année du transfert selon l'extension.

Année ajoutée au transfert, nom accentué et hébergeur à prévenir

Le transfert ajoute-t-il une année d'enregistrement ?

Pour la plupart des extensions génériques, oui, le transfert prolonge le nom d'une année. Pour d'autres, dont certaines extensions nationales, cela dépend des règles du registre et de l'offre du registrar.

Un nom accentué se transfère-t-il de la même façon ?

La procédure d'un nom accentué est identique ; seul le nom technique, en Punycode (forme commençant par xn--), apparaît parfois dans les écrans du registrar. La page sur le choix d'un domaine avec accent détaille cette écriture et ses limites pour le courrier.

Faut-il prévenir l'hébergeur ?

L'hébergeur n'a rien à faire tant que les enregistrements DNS pointent toujours vers ses serveurs. Il faut le prévenir seulement si sa propre offre incluait le nom ou la zone DNS, ce qui arrive avec les formules tout compris.

D'autres réponses sur les zones DNS, la messagerie et les sous-domaines se trouvent dans les questions sur les services internet.

Sources : FAQ de l'Afnic sur la gestion des noms en .fr (code Auth_Info, transfert, transmission), page de l'ICANN destinée aux titulaires de noms de domaine sur la politique de transfert entre registrars, RFC 5731 de l'IETF pour les états EPP des domaines. Relevé du 14 octobre 2026.