Transfert de domaines en masse : migrer un portefeuille sans coupure

Déplacer un domaine relève de l’administratif. En déplacer quatre cents relève du projet. Les portefeuilles constitués au fil des années se répartissent en général entre trois ou quatre bureaux d’enregistrement et plusieurs comptes de facturation, avec des extensions génériques et nationales côte à côte, chacune ayant son propre comportement de verrouillage et sa propre date d’expiration. Les étapes ne sont pas difficiles. Ce qui est difficile, c’est de les exécuter dans le bon ordre, en volume, sans couper le site d’un client ni son flux de messagerie. Ce guide couvre la préparation, l’exécution, le traitement des échecs et la vérification qu’exige réellement une migration importante.

Qu’est-ce qu’un transfert de domaines en masse ?

Un transfert de domaines en masse déplace de nombreux noms d’un bureau d’enregistrement vers un autre en un seul envoi coordonné. Chaque domaine est malgré tout déverrouillé séparément, autorisé par son propre code de transfert et traité individuellement par le registre. Le résultat dépend donc de la préparation : coordonnées exactes, codes valides et éligibilité vérifiée avant l’envoi.

À retenir

L’envoi groupé est un confort d’interface. Le registre continue d’évaluer chaque domaine séparément selon ses propres règles.
La plupart des migrations ratées se perdent en préparation : verrou actif, code expiré, adresse de contact que personne ne surveille.
Un changement de bureau d’enregistrement ne déplace ni l’hébergement DNS, ni le site, ni la messagerie. C’est un chantier distinct.
Les extensions nationales suivent leurs propres règles : le .fr relève de l’AFNIC et non du modèle ICANN.
Envoyer un gros lot ne raccourcit pas le traitement au registre, cela raccourcit votre propre temps de traitement.
Un lot pilote de cinq à dix domaines sans risque révèle la plupart des problèmes avant qu’ils n’atteignent les noms qui génèrent du chiffre.

Comment fonctionne un transfert de domaines en masse ?

Un transfert en masse est l’envoi groupé de plusieurs demandes de transfert entre bureaux d’enregistrement, par une liste collée dans le panneau ou par une série d’appels API. Le regroupement se produit à l’interface. En dessous, chaque domaine suit le même trajet qu’un transfert isolé : le bureau receveur transmet la demande au registre avec le code de transfert, le registre le valide, le bureau sortant dispose d’une fenêtre définie pour répondre, et le registre tranche pour ce domaine précis. Trois rôles méritent d’être distingués. Le registre exploite l’extension et détient la donnée de référence. Le bureau d’enregistrement possède l’accréditation ou le contrat auprès de ce registre et dépose la demande pour vous. Le titulaire est le détenteur légal du nom. Un transfert change de bureau. Il ne change pas de titulaire et ne déplace pas le DNS tant que vous ne le faites pas séparément. C’est de là que vient la surprise la plus fréquente. Un lot de 300 domaines renvoyant 274 validations et 26 refus n’a pas partiellement échoué en tant que lot. Il a produit 26 refus individuels, chacun avec son motif et sa correction.

Checklist avant de transférer un domaine

Passez ces points en revue avant d’envoyer quoi que ce soit. Presque toutes les migrations qui dérapent s’expliquent par un point de cette liste sauté sur une partie du portefeuille.

Point de contrôle	Pourquoi cela compte	Action requise
Verrou de transfert	Un domaine verrouillé est refusé par le registre, quelle que soit la façon dont la demande a été envoyée.	Déverrouiller tous les domaines du lot et confirmer l’état auprès du registre, pas seulement dans le panneau.
Code de transfert valide	La plupart des extensions exigent un code vérifiable par le registre et beaucoup de codes ont une durée limitée.	Générer les codes au plus près de l’envoi, vérifier qu’ils sont complets et redemander ceux qui ont expiré.
Données du titulaire	Les confirmations et les notifications partent vers l’adresse du titulaire enregistrée. La terminologie a évolué : les travaux actuels de l’ICANN centrent le processus sur le titulaire plutôt que sur un contact administratif distinct.	Vérifier que cette adresse est lue par quelqu’un capable d’agir et la corriger avant de commencer.
Enregistrement ou transfert récent	Sur les extensions génériques, la politique de l’ICANN impose souvent une restriction de 60 jours après l’enregistrement, après un transfert précédent et après certains changements de titulaire.	Marquer les domaines concernés et les planifier dans un lot ultérieur plutôt que d’accepter le refus.
Proximité de l’expiration	Un domaine proche de l’échéance peut entrer en période de grâce en cours de traitement et compliquer l’opération.	Renouveler avant de migrer, ou déplacer ces noms dans un lot distinct suivi de près.
Codes de statut	Les statuts de blocage du registre ou du bureau empêchent le transfert et restent invisibles si on ne les consulte pas.	Consulter les codes de statut via WHOIS ou RDAP et lever les blocages avant l’envoi.
DNSSEC	Sur un domaine signé, la validation casse si les enregistrements DS au registre ne correspondent plus à la chaîne de signature.	Si le fournisseur DNS et les clés ne changent pas, prévoir que le bureau receveur reprenne les DS existants. Ne les supprimer que si la chaîne change ou si la reprise est impossible.
Services de confidentialité	Un contact proxy peut s’intercaler entre le registre et la personne qui doit approuver.	Vérifier si le service affecte l’autorisation ou les notifications sur cette extension et ne le désactiver que si le bureau ou le registre l’exige.
Provision du compte	Les transferts sont payants et un paiement refusé bloque le lot.	Approvisionner le compte receveur pour la totalité du lot, extensions premium ou restreintes comprises.
Règles propres à l’extension	Les registres nationaux peuvent réclamer des justificatifs, une présence locale ou une validation supplémentaire.	Isoler ces extensions et confirmer la procédure de chaque registre avant de fixer le calendrier.

Comment transférer plusieurs domaines étape par étape

La séquence suppose un portefeuille de quelques centaines de domaines répartis chez plusieurs bureaux sortants. Adaptez la taille des lots à votre volume, mais pas l’ordre.

Constituer l’inventaire. Exporter tous les bureaux et tous les comptes dans un seul tableau : domaine, extension, bureau actuel, date d’expiration, serveurs de noms, état DNSSEC, état du verrou, adresse du titulaire, responsable métier et criticité.
Regrouper. Trier par extension et par bureau sortant. Ces deux axes déterminent les règles applicables et le panneau dans lequel vous travaillez, donc vos lots.
Classer par criticité. Séparer les domaines générant du chiffre, ceux qui portent la messagerie, les simples redirections et les dépôts défensifs dormants. Les deux dernières catégories sont idéales pour le pilote.
Lever les blocages. Appliquer la liste de contrôle à chaque groupe : déverrouiller, corriger les coordonnées, renouveler ce qui approche de l’échéance et mettre de côté ce qui tombe sous une restriction.
Lancer un lot pilote. Cinq à dix domaines sans risque, sur une seule extension. Le pilote valide votre gestion des codes, le cheminement des confirmations et votre suivi avant qu’une erreur n’atteigne quelque chose d’important.
Collecter les codes de manière sûre. Les récupérer dans la session où vous comptez envoyer, les stocker dans un coffre plutôt que dans un tableur partagé et les traiter comme des identifiants.
Envoyer par vagues. Regrouper par extension et par bureau sortant, garder des lots assez petits pour contenir une erreur systémique et laisser un intervalle entre deux envois.
Suivre l’état chaque jour. Tenir les statuts en attente, validé et refusé par domaine. Le silence n’est pas un progrès : les confirmations dorment souvent non ouvertes dans une boîte partagée.
Vérifier la continuité à chaque lot livré. Contrôler les serveurs de noms, ouvrir le site, envoyer et recevoir un message de test sur les domaines porteurs de messagerie, confirmer que les renouvellements de certificat par validation de domaine fonctionnent toujours.
Clôturer par un audit. Reverrouiller, vérifier les échéances et le renouvellement automatique, rapprocher le décompte final de l’inventaire initial.

Code de transfert et code EPP : comment les préparer

Le code de transfert est l’élément qui prouve la légitimité de la demande. Il apparaît sous plusieurs noms selon les interfaces : code de transfert, code EPP, AuthInfo et, dans les travaux actuels de l’ICANN, Transfer Authorization Code ou TAC. Il s’agit du même contrôle et les exigences de manipulation sont identiques. Trois propriétés provoquent l’essentiel des échecs en volume. Les codes sont souvent à durée limitée : un tableur constitué trois semaines plus tôt est en partie périmé le jour de l’envoi. Certains bureaux transmettent le code uniquement à l’adresse du titulaire au lieu de l’afficher, ce qui transforme une boîte non surveillée en blocage dur. Et les codes distinguent les majuscules et sont assez longs pour qu’un caractère perdu à la copie ne se voie qu’au refus du registre. Traitez-les comme des mots de passe : récupération au plus près de l’usage, stockage dans un gestionnaire de secrets et non dans un document partagé, accès limité à l’équipe de migration, suppression une fois le transfert abouti. Une liste de codes valides couvrant un portefeuille entier constitue, si elle fuit, une trousse complète de détournement.

Comment lancer un transfert groupé depuis le panneau

L’envoi est en général plus simple que la préparation qui le précède. Dans le panneau revendeur de Domain Name API, les transferts se trouvent sous Domain Management, avec deux onglets qui séparent les usages : une requête pour un nom isolé et une requête groupée pour un lot.

Requête de transfert groupé dans le panneau Domain Name API : un domaine et son code de transfert par ligne. Le champ attend un domaine par ligne, un espace, puis le code de ce domaine. Le format attendu est rappelé juste au-dessus du champ : une liste préparée se colle donc directement, et la requête s’exécute avant tout engagement. Ce format compte dès la préparation, car il détermine la construction de votre tableau d’inventaire : domaine et code en colonnes voisines et dans le même ordre de lignes, et l’export final devient un simple collage au lieu d’un travail de rapprochement. Les limites de lot et de requête sont affichées dans le panneau et peuvent évoluer : vérifiez les valeurs en vigueur dans votre propre compte avant de planifier un gros portefeuille.

Cinq choses à vérifier avant de coller la liste

La préparation a une longue traîne, mais quelques contrôles attrapent l’essentiel de ce qui déraille.

Le code est-il encore valide ? Les codes vieillissent. Récupérez-les le jour de l’envoi, pas la semaine d’avant.
Le déverrouillage est-il réel ? Le panneau dit déverrouillé. C’est le registre qui décide.
Qui reçoit la confirmation ? Si c’est un ancien collaborateur, ce transfert est déjà bloqué.
Qu’est-ce qui expire dans les trente prochains jours ? Renouvelez maintenant, pas au milieu du transfert.
Quels noms portent la messagerie ? Ceux-là partent en dernier, en petit lot et sous surveillance.

Pourquoi un transfert de domaine échoue-t-il et comment y remédier ?

Les échecs se rangent dans un petit nombre de schémas. Le tableau relie le symptôme visible à sa cause probable et à la correction.

Problème	Cause probable	Correction
Refus immédiat	Verrou toujours actif, ou déverrouillage non parvenu au registre.	Contrôler l’état via WHOIS ou RDAP plutôt que dans le panneau, déverrouiller à nouveau et renvoyer.
Code de transfert invalide	Code expiré, tronqué à la copie, ou extension utilisant un autre mécanisme.	Régénérer le code, le coller sans espaces et confirmer l’exigence réelle de l’extension.
Aucune confirmation reçue	Adresse enregistrée obsolète ou filtrée, ou service de confidentialité qui détourne la notification.	Mettre à jour la donnée, vérifier la quarantaine antispam et demander un renvoi avant de modifier autre chose.
Refus pour restriction de 60 jours	Le domaine a été enregistré, transféré ou a changé de titulaire dans les 60 derniers jours.	Noter la date de levée de la restriction et replanifier le domaine dans un lot ultérieur.
Blocage à l’approche de l’échéance	Le domaine a expiré ou est entré en période de grâce pendant le traitement. Le traitement varie selon le bureau et l’extension.	Renouveler chez le bureau sortant, laisser le renouvellement se stabiliser puis relancer le transfert.
Domaine injoignable après transfert	Les DS ne correspondent plus à la chaîne de signature, ou les serveurs de noms ont été réinitialisés.	Rétablir immédiatement les serveurs de noms, puis aligner les DS sur les clés réellement utilisées.
Refus sur une extension nationale	L’extension suit une procédure propre au lieu du code de transfert standard.	Appliquer la procédure publiée par ce registre, qui peut exiger des justificatifs ou une validation supplémentaire.
Un seul domaine bloque tout	Un litige, une décision de justice ou un blocage du registre pèse sur ce nom.	Régler d’abord le fond du dossier ; les domaines litigieux n’ont pas leur place dans le lot.
Lot incomplet sans que cela se voie	Les refus n’ont pas été remontés parce que personne n’a rapproché la liste envoyée de la liste reçue.	Rapprocher les décomptes après chaque lot et traiter tout écart comme un point ouvert.

Le transfert de domaine affecte-t-il le DNS, le site et la messagerie ?

Un transfert déplace la fiche d’enregistrement, pas les services qui y sont rattachés. La délégation des serveurs de noms survit en général à l’opération, ce qui explique que la plupart des transferts passent inaperçus. Le risque apparaît quand le bureau sortant hébergeait aussi le DNS : cette zone peut être supprimée au départ du domaine et emporte alors chaque enregistrement A, MX, TXT et CNAME. La séquence sûre sépare les deux changements : déplacer d’abord l’hébergement DNS vers sa destination définitive, vérifier la résolution, laisser tourner quelques jours, puis transférer l’enregistrement. Si les deux doivent bouger ensemble, exportez toutes les zones avant de commencer et reconstruisez-les chez le nouveau prestataire avant de basculer la délégation. Abaissez les TTL des enregistrements critiques un à deux jours plus tôt : une erreur se corrige alors en minutes et non en heures. La messagerie mérite une attention propre parce que ses pannes sont silencieuses. Vérifiez que les MX, SPF, sélecteurs DKIM et la politique DMARC sont reproduits à l’identique. Un sélecteur DKIM manquant n’arrête pas le courrier : il augmente discrètement la part de vos messages qui atterrit en indésirable, et une semaine plus tard personne ne fait le lien avec la migration. DNSSEC demande une décision, pas un réflexe. Si le fournisseur DNS et les clés de signature ne changent pas, les DS au registre restent valides et la seule question est de savoir si le bureau receveur peut les maintenir. Les supprimer n’est justifié que si la chaîne de signature change, si le DNS part chez un prestataire aux clés différentes, ou si le bureau receveur ne peut pas tenir ces enregistrements. Dans ces cas, supprimez d’abord, laissez les anciennes valeurs expirer et resignez après la migration. Un DS qui ne correspond plus rend le domaine injoignable pour tous les résolveurs validants, et c’est l’issue la plus dommageable du processus.

Sécurité du transfert pour un grand portefeuille de domaines

Une migration concentre des privilèges inhabituels sur une même fenêtre : domaines déverrouillés, codes valides et accès élargis. Traitez cette période comme une phase à risque élevé.

Activer l’authentification à deux facteurs sur le compte sortant et le compte receveur avant de commencer, pas après.
Restreindre le nombre de personnes pouvant demander des codes ou déverrouiller, et utiliser des comptes nominatifs.
Distribuer les codes via un gestionnaire de mots de passe. Les fils de courriel et de messagerie survivent bien plus longtemps que la validité des codes.
Reverrouiller chaque domaine dès son transfert abouti. Un portefeuille laissé déverrouillé après migration est un risque permanent.
Surveiller les demandes de code que vous n’avez pas déclenchées. Une génération inattendue pendant une migration mérite une vérification immédiate.

Si vous automatisez, appliquez la même rigueur aux identifiants. Le guide de Domain Name API sur la sécurité des clés d’API et les erreurs d’accès traite des variables d’environnement, des listes d’IP autorisées, de la rotation des clés et de la marche à suivre en cas d’exposition.

Transfert de domaine .fr : les règles AFNIC face aux gTLD

Les extensions génériques comme .com, .net et .org relèvent de la politique de transfert de l’ICANN, qui harmonise l’autorisation, les délais de réponse et les motifs de refus entre bureaux accrédités. Les registres nationaux appliquent leurs propres règles et ne sont pas tenus de suivre ce modèle. Pour le .fr, le registre est l’AFNIC et le changement de bureau s’opère avec le code de transfert obtenu auprès du bureau actuel. La mécanique est reconnaissable, mais les délais, la forme de la validation et le traitement du renouvellement peuvent différer de ce que vous connaissez en .com. Traitez le bloc .fr comme un chantier à part et confirmez la procédure en vigueur avant d’arrêter un calendrier. Sur d’autres extensions nationales les écarts sont plus structurels. Un transfert .uk se termine par le changement de l’étiquette IPS identifiant le bureau gestionnaire, et non par l’envoi d’un code. D’autres registres exigent des justificatifs, une présence locale ou une validation dans leur propre portail. Les génériques se déplacent en gros lots ; les nationales rarement, et supposer le contraire est la première cause de dérapage de calendrier.

Après le transfert : checklist de vérification

Un transfert affiché comme terminé ne signifie pas une migration terminée. Parcourez cette liste lot par lot, tant que les causes restent rattachables.

Rapprocher le nombre de domaines reçus du nombre envoyé et expliquer chaque écart.
Vérifier les serveurs de noms par rapport à la configuration prévue, pas à ce qui résout par hasard.
Résoudre chaque nom de production et charger le site en HTTPS pour détecter les problèmes de certificat.
Envoyer et recevoir un message de test sur chaque domaine porteur de messagerie, puis contrôler SPF, DKIM et DMARC.
Contrôler les échéances. La plupart des génériques ajoutent un an au transfert ; certaines nationales non.
Régler le renouvellement automatique de façon homogène et confirmer la présence d’un moyen de paiement valide.
Réactiver le verrou de transfert et, le cas échéant, les services de confidentialité.
Si le domaine était signé, vérifier que DNSSEC valide et que les DS correspondent aux clés en usage.
Mettre à jour l’inventaire des actifs et la supervision pour pointer vers le nouveau prestataire.

Panneau revendeur ou API : lequel choisir pour migrer

Aucune des deux voies n’est supérieure dans l’absolu. Tout dépend de la fréquence à laquelle vous répéterez le travail et de la part qui peut être automatisée sans risque.

Cas d’usage	Panneau revendeur	API	Recommandé
Migration unique sous quelques centaines de domaines	Suffisant, aucun développement	L’effort dépasse le gain	Panneau
Migrations récurrentes pour des clients	Répétitif et propice aux erreurs	Reproductible et auditable	API
Portefeuille mixte avec extensions nationales	Absorbe bien les exceptions et les étapes manuelles	Les exceptions demandent une logique dédiée	Panneau, API pour les génériques
Suivi des statuts entre les lots	Rapprochement manuel	Interrogation et reporting programmatiques	API
Synchronisation avec la facturation	Manuelle ou par export	Native via un module ou une intégration	API ou module
Équipe sans ressource de développement	Utilisable immédiatement	Non viable sans ingénierie	Panneau
Exploitation continue après migration	Suffisant à faible volume	Se met à l’échelle avec le portefeuille	API

Si vous automatisez, respectez les règles de débit du prestataire dès la première ligne de code. Domain Name API publie une politique de limites, de throttling et d’usage massif de l’API qui sépare les appels en temps réel sur /api du travail automatisé sur /api-bulk, fixe une limite d’une requête par seconde et par clé, et décrit le retrait exponentiel attendu après une réponse HTTP 429. Construire la file en respectant cette limite dès le départ coûte moins cher que l’ajouter ensuite.

Transfert de domaines en masse avec Domain Name API

Pour une migration, trois éléments comptent. Le panneau et l’API REST couvrent tous deux l’enregistrement, le transfert, le renouvellement et la gestion DNS : le portefeuille peut donc circuler par l’interface qui convient à l’équipe. Des modules existent pour WHMCS, WiseCP, HostBill, Blesta et ClientExec, ce qui devient déterminant quand la facturation ne doit pas se rompre. Et la politique d’usage massif publiée indique le débit automatisé autorisé avant l’écriture du code, et non après. La page revendeurs précise aussi que les revendeurs arrivant d’une autre plateforme sont accompagnés : vous fournissez la liste des domaines, ouvrez les verrous et transmettez les codes, et l’équipe support conduit le processus de transfert. Cette même page pointe le problème déjà décrit plus haut : les messages de validation partent vers les contacts enregistrés et non vers le revendeur. Aucune taille maximale de lot n’est publiée et aucune n’est affirmée ici. Domain Name API est un programme de revendeurs opérant sur l’infrastructure du bureau d’enregistrement accrédité ICANN Atak Domain. Ses chiffres publiés méritent d’être confrontés à vos besoins : accès à plus de 800 extensions, plus de 40 000 revendeurs actifs dans plus de 200 pays et plus de vingt ans d’expérience dans le domaine. Pour les portefeuilles comportant des extensions nationales exigeantes, échangez avec le support avant de fixer le calendrier. Ceux qui évaluent le changement peuvent consulter le programme revendeurs et les options d’intégration API et modules.

Conclusion

Un transfert de domaines en masse est avant tout un exercice de préparation. L’envoi prend quelques minutes ; l’inventaire, la levée des blocages, l’ordonnancement DNS et la vérification sont là où se logent le travail et le risque. Construisez l’inventaire, levez les obstacles, testez avec des noms qui ne peuvent pas vous nuire, migrez par lots contrôlés et vérifiez chaque lot avant d’envoyer le suivant. Si vous évaluez une destination pour votre portefeuille, comparez les tarifs de transfert et de renouvellement sur votre répartition réelle d’extensions, ouvrez un compte revendeur pour tester le panneau avant d’engager un gros lot, et confirmez la manière dont le prestataire traite les extensions nationales dont vous dépendez.

Questions fréquentes

Chaque réponse commence par l’information directe puis ajoute la nuance nécessaire. La structure est volontaire : elle permet à un moteur de réponse d’extraire une réponse courte et exacte sans perdre la réserve.

Qu’est-ce qu’un transfert de domaines en masse ?

C’est l’envoi groupé de plusieurs demandes de transfert entre bureaux d’enregistrement en une seule opération. Le regroupement se fait à l’interface ; chaque domaine reste validé et traité individuellement par son registre.

Puis-je transférer plusieurs domaines en même temps ?

Oui, à condition que chaque domaine remplisse séparément les conditions de son extension. Les domaines verrouillés, ceux sous restriction, ceux proches de l’échéance et ceux sans code valide seront refusés même si le reste du lot passe.

Chaque domaine a-t-il besoin d’un code de transfert ?

La plupart des extensions en exigent un, mais pas toutes. Les génériques utilisent un code appelé selon les sources code de transfert, code EPP, AuthInfo ou TAC. Certaines extensions nationales fonctionnent autrement, comme le .uk avec le changement d’étiquette IPS.

Combien de temps prend un transfert en masse ?

Cela dépend de l’extension, de la réponse du bureau sortant et de la rapidité des confirmations. Les génériques aboutissent souvent en quelques jours après un envoi valide ; les nationales varient sensiblement. Personne ne peut garantir un délai unique pour un portefeuille mixte.

Le transfert d’un .fr fonctionne-t-il différemment ?

En partie. Le registre du .fr est l’AFNIC et le changement s’effectue avec le code de transfert obtenu auprès du bureau actuel, mais les délais et la forme de validation peuvent différer de ce qui est habituel en .com. Traitez le bloc .fr comme un lot distinct.

Peut-on transférer un domaine expiré ?

En général non, et la réponse dépend du bureau et de l’extension. Certains traitent encore le transfert pendant la période de grâce ; une fois en phase de récupération, le transfert n’est plus praticable. Renouveler d’abord est la voie prévisible.

Le transfert affecte-t-il mon site ?

Pas en soi. La fiche d’enregistrement change de bureau et la délégation des serveurs de noms reste en place. Le risque tient au fait que la zone DNS était hébergée chez le bureau sortant, car elle peut être supprimée au départ du domaine. Exportez les zones avant.

La messagerie peut-elle tomber pendant le transfert ?

Oui, si des enregistrements DNS sont perdus ou mal reconstruits. Les MX, SPF, sélecteurs DKIM et DMARC doivent être reproduits à l’identique. L’absence d’enregistrements d’authentification arrête rarement complètement le courrier : elle augmente le classement en indésirable, plus difficile à détecter.

Pourquoi un transfert échoue-t-il ?

Le plus souvent à cause d’un verrou actif, d’un code invalide ou expiré, d’une adresse de contact non surveillée, d’un enregistrement ou d’un transfert datant de moins de 60 jours, de la proximité de l’échéance, d’un blocage du registre ou du bureau, ou d’une extension nationale à procédure propre.

L’envoi groupé accélère-t-il chaque transfert ?

Non. Le regroupement réduit votre temps de traitement, pas celui du registre. Chaque domaine reste évalué selon son propre calendrier et ses propres règles.

Faut-il renouveler avant de transférer ?

Renouvelez tout ce qui approche de l’échéance. La plupart des extensions génériques ajoutent un an au transfert, donc un renouvellement anticipé est rarement perdu et supprime le risque qu’un domaine expire pendant la demande.

Faut-il retirer DNSSEC avant le transfert ?

Pas automatiquement. Si le fournisseur DNS et les clés ne changent pas, les DS existants restent valides et la seule question est de savoir si le bureau receveur peut les maintenir. Retirer puis rétablir ne s’impose que si la chaîne de signature change ou si les enregistrements ne peuvent pas y être tenus.

Une API est-elle indispensable pour un gros portefeuille ?

Non. Une migration unique de quelques centaines de domaines passe très bien par le panneau. L’API devient intéressante quand les migrations se répètent, quand le suivi entre lots doit être programmatique ou quand le portefeuille sera géré en continu ensuite.