Pourquoi un domaine client tombe, et pourquoi c'est vous qu'on appelle
Un nom de domaine n'expire presque jamais par négligence pure. Il expire parce que la chaîne qui devait le renouveler a un maillon mort : la carte enregistrée est arrivée à échéance, le renouvellement automatique n'a jamais été activé, ou l'avis du registrar part vers la boîte d'un prestataire parti depuis deux ans. Le registrar a fait son travail, personne n'a lu son message.
Le jour où le nom tombe, le symptôme est brutal et sans détail : le site est injoignable, les e-mails sont rejetés, ou une page de parking du registrar s'affiche à la place du site. Pour le client, la panne n'a pas de cause, elle a un responsable, et c'est celui qui a livré le site. C'est pourquoi une agence ne peut pas traiter les domaines comme un sujet annexe : la responsabilité retombe sur elle, même quand elle n'est pas titulaire du nom.
Titulaire, payeur, gestionnaire : trois rôles à ne pas confondre
Le titulaire d'un domaine est la personne ou la société inscrite comme registrant auprès du registrar. Ce n'est pas celui qui paie, et ce n'est pas celui qui configure le DNS. Cette distinction règle l'objection que tous les clients posent : qui est responsable, l'agence ou le client ?
Si le client est inscrit comme titulaire, le nom lui appartient, mais il ne reçoit les avis que si son adresse est la bonne et lue. Si l'agence s'est inscrite elle-même comme titulaire pour aller plus vite, le nom est inscrit à son nom, et le jour de la rupture de contrat, le transfert devient un sujet de négociation. Dans les deux cas, écrivez noir sur blanc, dans le contrat ou dans un avenant, qui est titulaire, qui renouvelle, qui paie et qui reçoit les avis. Le registre ci-dessous reprend ces quatre informations pour chaque nom.
Le registre : une ligne par domaine, huit repères
Faites défiler le tableau
| Repère | Ce que vous notez | Pourquoi il compte |
|---|---|---|
| Domaine et registrar | Le nom exact et le registrar où il est géré | Savoir où se connecter quand l'incident arrive |
| Titulaire | Le nom légal inscrit comme registrant | Détermine qui peut autoriser un transfert ou une restauration |
| Contacts technique et facturation | Les adresses e-mail de chaque rôle, avec une boîte de l'agence en copie | Les avis partent vers ces adresses, pas vers vous |
| Échéance et renouvellement automatique | La date d'échéance, et oui ou non pour le renouvellement automatique | Base du calendrier d'alertes |
| Moyen de paiement | Le moyen utilisé et sa date d'expiration | Cause fréquente d'échec d'un renouvellement automatique |
| Verrou de transfert | Activé ou non, date du dernier changement | Protège le nom d'un transfert non voulu |
| DNS et serveurs de noms | Qui héberge la zone, quels serveurs de noms sont déclarés | Un nom qui expire coupe tout ce qui en dépend |
| Services dépendants et client responsable | Site, e-mail, applications liées ; le contact côté client | Mesure l'impact et dit qui prévenir |
Le cycle de vie d'un nom : ce que fixe l'ICANN, ce qu'elle ne fixe pas
Pour les extensions génériques (gTLD), la politique de récupération des enregistrements expirés de l'ICANN, appelée ERRP, fixe un socle. Le registrar doit envoyer au moins deux avis avant l'expiration, environ un mois puis environ une semaine avant ; sont jugés conformes des envois entre 26 et 35 jours, puis entre 4 et 10 jours avant. Si le nom n'est ni renouvelé ni supprimé cinq jours après l'expiration, un avis supplémentaire est dû. Le registrar doit aussi permettre le renouvellement jusqu'à la fin de la période d'interruption du DNS.
Trois précisions évitent les contresens. D'abord, expiration et suppression sont deux événements : le DNS est interrompu à l'expiration ou, au plus tard, pendant les 8 derniers jours renouvelables ; la suppression vient ensuite. Ensuite, après la suppression, les registres de gTLD non parrainés offrent une période de rédemption de 30 jours, pendant laquelle le DNS reste désactivé et les transferts interdits, et où la restauration se demande au registrar, avec des frais que celui-ci doit afficher. Enfin, la période de grâce de renouvellement automatique, de 1 à 45 jours, est facultative : certains registrars l'offrent, d'autres non. Ne la comptez jamais comme acquise.
Attention aux extensions nationales (ccTLD) comme .ma ou .sn : leurs durées dépendent du registre et ne sont pas celles-ci. Pour chaque ccTLD de votre portefeuille, lisez la politique du registre et notez-la dans la fiche du domaine.
Les phases, de l'échéance à la suppression
Faites défiler le tableau
| Phase | Ce qui se passe | Ce que vous faites |
|---|---|---|
| Avant l'échéance | Le registrar envoie au moins deux avis, environ un mois puis environ une semaine avant | Vérifier que ces avis arrivent dans une boîte lue |
| À l'expiration | Le DNS est interrompu dès l'expiration si la suppression survient dans les 8 jours, sinon au moins sur les 8 derniers jours renouvelables | Renouveler sans attendre : site et e-mail peuvent être coupés |
| Cinq jours après | Avis supplémentaire si le nom n'est ni renouvelé ni supprimé | Traiter cet avis comme une alerte rouge |
| Renouvellement tardif | Possible jusqu'à la fin de la période d'interruption du DNS | Lire les frais de renouvellement tardif affichés par le registrar |
| Rédemption | 30 jours après la suppression pour les gTLD non parrainés ; DNS désactivé, transferts interdits | Demander la restauration au registrar, frais de restauration à l'appui |
| Extensions nationales | Durées propres à chaque registre | Consulter la politique du registre concerné |
Le calendrier d'alertes de l'agence
- 90 jours avant — contrôle du dossier : titulaire à jour, contacts lus, moyen de paiement valide au-delà de l'échéance. C'est le moment de corriger sans urgence.
- 60 jours avant — confirmation avec le client : on renouvelle, on transfère ou on abandonne le nom. Une décision écrite, pas une supposition.
- 30 jours avant — le renouvellement est passé ou planifié ; sinon, relance du client avec le message type plus bas. L'avis du registrar arrive à peu près à cette date.
- 7 jours avant — dernier contrôle : l'échéance est-elle toujours devant nous ? Si non, on bascule en procédure d'urgence. Le second avis du registrar tombe vers cette date.
- Méthode, pas obligation — ces quatre seuils sont la recommandation de l'agence, pas une règle ICANN. Ajustez-les, mais gardez des seuils fixes et un responsable nommé.
- Les avis du registrar ne remplacent pas ce calendrier — ils partent vers l'e-mail du titulaire, souvent le client ou un ancien contact. Votre calendrier est la seule alerte qui arrive chez vous.
Verrou de transfert, code EPP et changement de titulaire
Activez le verrou de transfert sur tous les noms, par défaut, et ne le levez qu'au moment d'un transfert sortant. Un nom verrouillé ne peut pas partir chez un autre registrar sans que quelqu'un le déverrouille : c'est la protection la plus simple contre un transfert non voulu. Le code de transfert (EPP) se demande au moment de la sortie, pas avant, et se traite comme un mot de passe : le pas-à-pas figure dans le guide sur le transfert sortant.
Un piège de séquencement revient souvent. La politique de transfert de l'ICANN impose un verrou de 60 jours après un changement des informations du titulaire ; il peut être évité par un opt-out, mais seulement avant la demande de changement. Si vous voulez déplacer un nom et changer son titulaire, faites le transfert d'abord, le changement de titulaire ensuite. Dans l'ordre inverse, vous vous retrouvez avec un nom bloqué soixante jours, sans possibilité de le déplacer vers un registrar plus fiable.
Contacts et vérification : RDAP plutôt que WHOIS seul
Chaque année, le registrar envoie un rappel de vérification des données d'enregistrement (RDRP, ancien WDRP). Cet e-mail vient du registrar, pas de l'ICANN, et il part vers le contact titulaire : un contact injoignable laisse ce rappel sans réponse, et personne ne s'en aperçoit. Relisez les contacts de chaque ligne du registre au moins une fois par an, et à chaque départ d'un collaborateur dont l'adresse figurait sur un domaine.
Pour vérifier qui est inscrit, n'utilisez pas seulement WHOIS. Depuis le 28 janvier 2025, RDAP est la source de référence des données d'enregistrement des gTLD, en remplacement de WHOIS. Certaines données peuvent être masquées, ce qui est normal. Interrogez lookup.icann.org, puis confirmez dans l'interface du registrar : la fiche du registrar reste la source pour agir, RDAP sert à contrôler.
Le domaine est déjà expiré : la procédure en six étapes
Confirmer l'état du nom
Interrogez RDAP via lookup.icann.org et ouvrez la fiche chez le registrar. Notez l'état affiché, la date d'échéance et le contact titulaire. Un contrôle DNS rapide complète le tableau :
dig +short NS exemple.com, puisdig +short A exemple.com. Un nom interrompu ne répond plus, ou renvoie vers la page du registrar.Renouveler tout de suite si la période le permet
Tant que le nom est renouvelable, renouvelez immédiatement. Lisez avant de payer les frais de renouvellement tardif que le registrar doit afficher. Le renouvellement relance le DNS ; le rétablissement n'est pas toujours instantané.
Sinon, demander la restauration
Si le nom a été supprimé et se trouve en période de rédemption, la restauration se demande au registrar, qui affiche ses frais de restauration. Elle coûte plus cher qu'un renouvellement ordinaire. Plus le temps passe, moins la reprise est sûre : n'attendez pas.
Vérifier DNS et e-mail après le retour
Contrôlez les serveurs de noms avec
dig +short NS exemple.com, les enregistrements MX avecdig +short MX exemple.com, puis testez le site et l'envoi d'un message. Les caches peuvent retarder le retour à la normale : repassez après quelques heures.Prévenir le client
Informez-le avant qu'il ne le découvre : ce qui s'est passé, ce qui est rétabli, ce qui reste à surveiller. Un message type est proposé juste après cette liste.
Corriger le registre et l'organisation
Écrivez le post-mortem : pourquoi l'avis n'a pas été lu, pourquoi le paiement a échoué. Corrigez la ligne du registre et, si la cause est structurelle, la méthode : contacts, carte, propriétaire du calendrier.
Le message type au client
Objet : domaine exemple.com, rétabli.
Bonjour, le nom de domaine exemple.com avait expiré, ce qui a coupé le site et les e-mails. Nous l'avons renouvelé et rétabli aujourd'hui. Les accès reviennent progressivement, le délai dépend des caches. Nous vérifions le site et les boîtes e-mail et nous vous confirmons le retour complet. Nous avons aussi corrigé la cause : le moyen de paiement et le contact d'avis ont été mis à jour. Nous restons joignables pour toute question.
Ne promettez pas un délai de retour que vous ne contrôlez pas, et ne nommez pas de faute individuelle.
Ce que ServOrbit couvre, et ce qu'il ne couvre pas
Pour un domaine géré chez ServOrbit, la fiche du domaine dans l'espace client permet d'activer ou de lever le verrou de transfert et d'obtenir le code de transfert (EPP). Le contact titulaire (Whois) y est renseignable, ce qui permet de corriger l'adresse qui reçoit les avis. L'Espace agence offre une vue portefeuille des services d'un client : domaines, hébergements, VPS.
Ce guide ne promet rien au-delà. Le calendrier d'alertes décrit plus haut est une méthode que vous mettez en place avec vos outils : nous ne présentons pas de système d'alerte d'expiration automatique, et le registre reste un document que vous tenez. Pour les noms .ma, le coût des renouvellements se lit dans l'article dédié aux tarifs, et les données publiées dans le guide sur le registre.
La documentation officielle
Politique de récupération des enregistrements expirés (ERRP) : https://www.icann.org/resources/pages/errp-2013-02-28-en
Version actualisée de la politique, 2024 : https://www.icann.org/en/contracted-parties/consensus-policies/expired-registration-recovery-policy/expired-registration-recovery-policy-21-02-2024-en
Guide ICANN pour les titulaires, période de grâce de renouvellement automatique : https://www.icann.org/resources/pages/registrant-about-errp-2018-12-07-en
FAQ ICANN sur le changement de titulaire et le verrou de 60 jours : https://www.icann.org/en/transfer-policy-faqs-change-of-registrant-30nov16-en
Rappel annuel des données d'enregistrement : https://www.icann.org/resources/pages/registrars/consensus-policies/drp-en
RDAP et fin de WHOIS : https://www.icann.org/en/announcements/details/icann-update-launching-rdap-sunsetting-whois-27-01-2025-en
Recherche de données d'enregistrement : https://lookup.icann.org
