Imaginez la scène. On est lundi matin, 9h02. Vous venez de lancer une migration de registrar parce que vous en avez assez de payer trop cher ou que l'interface de votre ancien prestataire vous donne de l'urticaire. Vous avez cliqué sur le bouton pour lancer l'opération OVH Transférer Un Nom De Domaine, persuadé que tout se passerait bien en arrière-plan pendant que vous prenez votre café. Sauf qu'à 11h, votre site est inaccessible. Vos mails pro ne partent plus. Les clients qui essaient de vous joindre tombent sur une erreur DNS "NXDOMAIN". Vous paniquez, vous contactez le support, et là, vous découvrez que votre code de transfert est invalide ou, pire, que vos zones DNS n'ont pas suivi. Ce n'est pas une fiction : j'ai vu des entreprises perdre des milliers d'euros de chiffre d'affaires et des semaines de référencement naturel à cause d'une simple case non cochée ou d'un délai de propagation mal anticipé. Le transfert n'est pas une simple formalité administrative, c'est une opération chirurgicale sur l'artère carotide de votre présence en ligne.
Le piège mortel du verrouillage de transfert et du code AuthInfo
La première erreur, celle qui fait perdre un temps fou à tout le monde, c'est de croire qu'il suffit de demander le transfert pour que ça arrive. Dans la réalité, presque tous les registres (l'organisme qui gère l'extension, comme l'AFNIC pour le .fr ou l'ICANN pour le .com) imposent une sécurité appelée "Transfer Lock". Si vous ne déverrouillez pas manuellement le domaine chez votre prestataire actuel avant de lancer la procédure, l'opération échouera systématiquement au bout de quelques jours.
Le fameux code de transfert, souvent appelé AuthCode ou AuthInfo, est l'autre point de friction. J'ai vu des dizaines de clients copier ce code avec un espace invisible à la fin ou au début. Résultat ? Le système d'OVH rejette la demande. Ce code a une durée de vie limitée. Si vous le récupérez le lundi mais que vous ne lancez l'opération que le vendredi, il y a de fortes chances qu'il soit déjà expiré pour certaines extensions. C'est frustrant, c'est bête, mais c'est la réalité du terrain. Avant de bouger quoi que ce soit, assurez-vous d'avoir un code "propre" et un domaine déverrouillé.
OVH Transférer Un Nom De Domaine et la gestion des serveurs DNS
C'est ici que le sang coule vraiment. Beaucoup pensent que transférer le nom de domaine transfère automatiquement l'hébergement du site ou la configuration des emails. C'est totalement faux. Le transfert de domaine concerne la propriété juridique et la facturation, pas le contenu technique.
L'erreur de la zone DNS vide
Quand vous lancez le processus pour OVH Transférer Un Nom De Domaine, vous avez souvent le choix entre conserver les serveurs DNS actuels ou utiliser ceux de la plateforme de destination. Si vous choisissez les DNS d'OVH sans avoir recréé manuellement chaque ligne de votre zone DNS (les entrées A, MX, CNAME, TXT) dans leur interface au préalable, votre site s'éteindra dès que le transfert sera validé. Le résolveur cherchera des instructions sur les nouveaux serveurs, n'y trouvera rien, et renverra une erreur.
La solution préventive
La seule méthode qui fonctionne pour éviter la coupure consiste à garder les serveurs DNS du prestataire d'origine pendant toute la durée du transfert. Une fois que le domaine est officiellement arrivé dans votre compte, vous pouvez alors migrer les entrées DNS tranquillement. J'ai trop souvent vu des administrateurs faire l'inverse et se retrouver avec un site "dans le noir" pendant 48 heures, le temps que la propagation DNS fasse son travail à travers le monde.
La règle des 60 jours que personne ne lit jamais
Il existe une règle stricte de l'ICANN pour les extensions génériques comme le .com, .net ou .org : vous ne pouvez pas transférer un domaine qui a été créé ou dont le propriétaire a été modifié il y a moins de 60 jours. J'ai accompagné un entrepreneur qui avait racheté un nom de domaine premium sur une place de marché et qui voulait le ramener immédiatement sur son compte principal. Il a payé, il a lancé la procédure, et tout a été bloqué.
Il a dû attendre deux mois avec un domaine éparpillé entre deux plateformes, payant deux factures différentes, incapable d'unifier sa gestion. C'est une perte de temps administrative monumentale. Si vous venez d'acheter un domaine ou de mettre à jour vos coordonnées WHOIS (nom, adresse, email du propriétaire), ne touchez à rien pendant deux mois. Le système rejettera votre demande sans même vous expliquer pourquoi de façon claire, vous laissant avec un message d'erreur cryptique du type "ClientTransferProhibited".
Le drame des adresses emails de contact obsolètes
Voici un scénario classique : vous avez créé votre nom de domaine il y a huit ans avec une vieille adresse email @wanadoo.fr ou @hotmail.com que vous n'utilisez plus. Pour valider le processus, le système doit envoyer un mail de confirmation au contact administratif présent dans la base WHOIS. Si vous n'avez plus accès à cette boîte mail, vous êtes coincé.
J'ai vu des dossiers traîner pendant des mois parce que le propriétaire devait entamer une procédure de "récupération forcée" avec envoi de cartes d'identité et de justificatifs de domicile par courrier postal ou via des interfaces de support lentes. Tout ça parce qu'il n'avait pas vérifié ses informations de contact avant de cliquer sur "transférer". Avant de lancer quoi que ce soit, vérifiez que l'email associé au domaine est bien le vôtre et qu'il est actif. C'est l'étape la plus simple, et pourtant la plus négligée.
Comparaison concrète : la méthode amateur contre la méthode pro
Pour bien comprendre l'impact de ces erreurs, regardons comment deux utilisateurs gèrent la même situation. Ils veulent tous deux migrer un .com d'un registraire américain vers la France.
L'approche amateur (Le crash) L'utilisateur se connecte, récupère son code AuthInfo sans regarder le statut du domaine. Il se rend sur l'interface de destination, entre le mot-clé OVH Transférer Un Nom De Domaine et paie la commande. Il sélectionne "Utiliser les DNS de la plateforme" pour tout centraliser. Le transfert est accepté par le système. Trois jours plus tard, le transfert est effectif. Mais comme il n'avait pas configuré la zone DNS sur la nouvelle interface, ses entrées MX (emails) pointent vers le vide. Il ne reçoit plus aucun message client pendant trois jours, le temps de comprendre le problème et que la nouvelle configuration se répande sur le web. Il perd des prospects et sa réputation en prend un coup.
L'approche professionnelle (La continuité) Le pro commence par exporter son fichier de zone DNS actuelle. Il va ensuite sur l'interface de destination et crée une "Zone DNS seule" (sans le domaine). Il y recopie scrupuleusement chaque entrée. Ensuite, il déverrouille le domaine chez l'ancien prestataire et vérifie son adresse email de contact. Il lance la commande. Il choisit l'option "Conserver les serveurs DNS actuels". Le transfert se fait en arrière-plan. Quand le domaine apparaît enfin dans son tableau de bord, le site n'a jamais cessé de fonctionner. Une semaine plus tard, quand tout est stable, il bascule les serveurs DNS vers les nouveaux. Temps d'arrêt : zéro seconde. Coût financier : uniquement le prix du renouvellement inclus dans le transfert.
Les spécificités du .fr : un monde à part
Si vous travaillez sur une extension nationale française, oubliez une partie de ce que vous savez sur les .com. L'AFNIC a ses propres règles. Par exemple, le transfert d'un .fr est souvent plus rapide (environ 1 à 8 jours) mais il peut être soumis à des vérifications d'éligibilité strictes. Vous devez résider ou avoir votre siège social dans l'Espace Économique Européen ou en Suisse.
J'ai vu des transferts de .fr échouer parce que le SIRET de l'entreprise n'était plus à jour dans la base de données. L'AFNIC ne rigole pas avec la validité des informations. Si vous tentez de transférer un domaine appartenant à une société qui a été liquidée ou renommée sans avoir fait le changement de propriétaire (trade) au préalable, vous allez droit dans le mur. Le transfert sera bloqué et vous devrez payer des frais supplémentaires pour régulariser la situation juridique avant de pouvoir bouger le nom.
La gestion des renouvellements et les dates d'expiration
Une croyance populaire veut que l'on perde les mois d'abonnement restants lors d'un transfert. Pour la plupart des extensions (gTLD), le transfert ajoute un an à la date d'expiration actuelle. Si votre domaine expire en décembre 2026 et que vous le transférez en mai 2026, sa nouvelle date d'expiration sera décembre 2027. Vous ne perdez rien.
Cependant, ne tentez jamais un transfert moins de 15 jours avant la date d'expiration. Si un problème survient (code erroné, mail non reçu) et que le domaine expire pendant la procédure, il peut tomber dans une période de "Rédemption" où les frais de récupération sont astronomiques (souvent autour de 100 à 150 euros). J'ai vu des gens perdre définitivement leur nom de domaine parce qu'ils ont voulu économiser quelques euros en attendant le dernier moment pour changer de prestataire. La règle d'or : on transfère au moins un mois avant l'échéance.
Vérification de la réalité
On ne va pas se mentir : transférer un domaine chez ce prestataire n'est pas une partie de plaisir magique. L'interface est dense, le support peut être lent à répondre si vous n'avez pas un compte premium, et les erreurs ne pardonnent pas. Si vous pensez que cliquer sur un bouton va tout résoudre par enchantement, vous vous trompez lourdement.
La réussite d'une migration repose à 90 % sur la préparation que vous faites CHEZ l'ancien registraire et à 10 % sur l'action chez le nouveau. Si votre zone DNS n'est pas prête, si votre WHOIS est vieux de dix ans ou si vous avez un verrou de sécurité actif, vous allez souffrir. Ce n'est pas une question de chance, c'est une question de rigueur technique. Ne lancez pas cette procédure un vendredi soir avant de partir en week-end. Faites-le un mardi matin, soyez prêt à fouiller dans des lignes de texte techniques, et gardez toujours un accès aux deux comptes jusqu'à ce que la dernière ligne DNS soit propagée. C'est le seul moyen de ne pas finir avec un site mort et une entreprise à l'arrêt.
