Transférer un domaine entre registrars : admissibilité et préservation des services

Délimiter le transfert selon six rôles

Identifiez registre du TLD, registrars actuel et destinataire, titulaire enregistré, opérateur DNS faisant autorité, hébergeur et fournisseur de courriel. Écrivez ce qui doit rester identique et ce qui appelle une décision séparée. Une société peut tenir plusieurs rôles sans rendre contrats, autorité et preuves d’acceptation interchangeables.

La politique gTLD publiée par ICANN attribue au titulaire enregistré l’autorité d’approuver le transfert. Modifier les droits du titulaire ou apporter une modification substantielle aux coordonnées est une autre procédure. Avant une correction de contact proposée, vérifiez ses conséquences avec le registrar responsable ; ne la traitez pas comme un préalable anodin.[1]

Commencer par une fiche de transmission vierge

Par ligne : source datée/emplacement ____, responsable des preuves ____, état/blocage ____ et prochaine revue ____. Utilisez des références privées approuvées. Aucun code d’autorisation, mot de passe ou document d’identité superflu dans la fiche partagée.

Une inconnue critique d’autorité ou d’admissibilité impose HOLD. Ni marge de dates ni site apparemment sain ne la compensent. Conservez les preuves ouvertes ; des lignes de services positives n’autorisent pas le transfert.

Dater la politique et distinguer les restrictions

Le 14 octobre, ICANN affiche la mise à jour du 21 février 2024, à appliquer au plus tard le 21 août 2025. L’en-tête maintient le report de l’application de l’exigence de formulaire d’autorisation (FOA) du registrar destinataire. Le 7 juin 2026, le Conseil adopte 47 recommandations et ordonne leur mise en œuvre ; Transfer Policy Review figure dans la file d’implémentation. L’adoption ne rend pas effectives les procédures de remplacement proposées. Revérifiez la version avant une opération.[1][2][3]

Dans cette politique gTLD, les circonstances d’enregistrement initial ou de transfert récent en I.A.3.7 permettent un refus ; les motifs juridiques, de litige et de changement de titulaire énumérés en I.A.3.8 l’imposent. II.C traite le verrou de changement matériel, la renonciation préalable et les dispositions limitées de retrait, dont la note 7. Lever un clientTransferProhibited ordinaire ne prouve pas que toutes les restrictions ont disparu. Ni attente universelle de 60 jours ni retrait de tout verrou ne sont promis.[1]

Autorisation, notifications et preuves de fin propres aux prestataires restent nécessaires. Les dispositions conditionnelles de cinq jours calendaires pour l’assistance et la réponse du registre concernent certaines obligations, pas le délai total. Une demande ou un reçu de paiement ne confirme pas le changement. Ce guide ne fournit aucun scénario universel de formulaire courriel ou de code.[1]

Documenter séparément la continuité des services

Par dépendance : responsable actuel/source ____, maintien ou migration distincte ____, preuve d’acceptation/opérateur ____ et décision d’attente ou retour ____. Six lignes : la question contractuelle compte autant que les réglages envisagés.

Le guide Cloudflare du 24 avril 2026 exige son propre DNS faisant autorité pour son service de registrar. La page .nl de SIDN illustre contrats propres au registre et coordination avec un nouveau registrar compatible DNSSEC. Ces exemples limités peuvent rouvrir le plan de préservation ; ce ne sont pas des exigences universelles. Un opérateur qualifié choisit la séquence DNS/DS pertinente. Ne généralisez pas une recette de désactivation DNSSEC.[4][5]

Paper Lantern Workshop : des dates anciennes ne suffisent pas

Les sept champs de transmission et six lignes de préservation sont distincts de ce résumé fictif à six lignes. Les 37/29 jours sont une marge, pas une prévision, durée de verrou ou SLA ; les deux jours ne sont pas une échéance de politique. Si B imposait son DNS, l’hypothèse de maintien tomberait et il faudrait un plan DNS séparé et revu. Aucun prestataire n’est présenté comme offrant cette acceptation fictive.

Séparer droit et acceptation du prestataire

La politique gTLD publiée ne fait pas de l’expiration seule un motif général de refus ; restrictions réelles et périodes impayées comptent. Cloudflare exige séparément le renouvellement d’un domaine expiré chez le registrar actuel. Un cas proche de l’échéance ou dont le statut change demande d’abord sa décision statut/renouvellement et des preuves exactes du prestataire. Ni récupération garantie, ni transfert gratuit, ni année supplémentaire inconditionnelle.[1][4]

Exiger des preuves distinctes de transfert et de services

Transmettez la décision d’admissibilité délimitée, références privées d’autorité, instructions datées, fiche à sept champs et registre à six lignes. Les preuves autorisées ultérieures doivent distinguer demande acceptée, changement terminé et acceptation de chaque service. Paper Lantern reste sur HOLD. Ce guide n’exécute aucun transfert et ne garantit pas DNS, TLS, courriel ou liens événementiels sans interruption.