Retour au blog

Domaine expiré - ce qui se passe et comment le monitoring WHOIS sauve

· 6 min de lecture

Un domaine expire fait tomber site, e-mail et status page d'un coup, et la restauration prend des heures. Le monitoring WHOIS vous alerte des mois avant.

Domaine expiré - ce qui se passe et comment le monitoring WHOIS sauve

Pourquoi l'expiration est catastrophique

Quand un certificat SSL expire, le navigateur montre un avertissement. Certains clients cliquent "Continuer quand même", le reste part. La perte est significative mais limitée.

Quand le domaine expire, c'est une tout autre histoire :

  • les enregistrements NS sont retirés de la zone TLD
  • le lookup DNS de votre domaine commence à échouer pour tous les utilisateurs
  • site, email (MX) et services internes sur sous-domaines - tout tombe en même temps
  • les intégrations API tierces avec vous échouent
  • après la grace period (typiquement 30 jours) n'importe qui peut acheter le domaine

Grace period : avez-vous encore du temps ?

Après expiration, la plupart des TLDs ont une grace period - une fenêtre pendant laquelle vous pouvez renouveler au tarif standard :

  • gTLD (.com, .net, .org) : jusqu'à 45 jours auto-renew grace, puis 30 jours redemption (à un prix plus élevé, environ 80 €), enfin 5 jours pending delete
  • .sk : période de protection de 40 jours après expiration (renouvellement payant pendant celle-ci), au 41e jour suppression et libération
  • .cz : 60 jours grace, pas de redemption (libre après 60 jours)
  • .eu : 40 jours quarantine
  • .io : 30 jours grace

Pendant la grace period, le DNS ne fonctionne pas. Le domaine existe mais est en état "expired". Une fois celle-ci écoulée, il peut aller aux enchères ou à l'enregistrement libre.

Pire scénario : Quelqu'un d'autre achète votre domaine - typiquement un acheteur de domaines drop-catched à valeur SEO. Vous perdez toute l'identité de marque, tous les liens existants et votre ranking SEO. En dehors d'une procédure UDRP coûteuse, vous n'avez aucun droit légal de le récupérer.

Pourquoi l'auto-renewal échoue

La plupart des registrars offrent l'auto-renewal. En pratique il échoue pour ces raisons :

  • Carte de crédit expirée - raison la plus fréquente. La carte a été réémise, mais les nouvelles données n'ont jamais été mises à jour chez le registrar.
  • Fonds insuffisants - le prélèvement du compte bancaire a échoué et personne n'a remarqué l'email du registrar.
  • L'email du registrar finit dans le spam - vous ne voyez même pas la notification.
  • Changement de propriété ou de compte - le compte du registrar est sur un ancien employé ou une ancienne entreprise.
  • Auto-renewal désactivé - souvent le réglage par défaut chez certains registrars.

WHOIS lookup : ce qu'il fait

Le protocole WHOIS (RFC 3912) est une requête au système du registrar : "Qui possède ce domaine et quand expire-t-il ?". La réponse contient :

$ whois epulz.io

Domain Name: EPULZ.IO
Registry Domain ID: ...
Updated Date: 2026-04-15T09:23:11Z
Creation Date: 2026-02-20T12:00:00Z
Registry Expiry Date: 2027-02-20T12:00:00Z   ← CECI
Registrar: ...
Domain Status: clientTransferProhibited
Name Server: NS1.EXAMPLE.COM
Name Server: NS2.EXAMPLE.COM
...

Pour le monitoring, c'est la Registry Expiry Date qui nous intéresse. C'est la date à laquelle le domaine passe en état expired si vous ne le renouvelez pas.

RDAP : remplacement moderne de WHOIS

WHOIS est né en 1982 (RFC 812), la spécification actuelle est la RFC 3912 de 2004, et il a ses limites (réponse texte non structurée, pas d'authentification, pas de TLS). L'ICANN pousse donc la transition vers RDAP (Registration Data Access Protocol) - un REST API basé sur JSON.

$ curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.events[] | select(.eventAction=="expiration")'

{
  "eventAction": "expiration",
  "eventDate": "2027-02-20T12:00:00Z"
}

RDAP est plus fiable (JSON standardisé au lieu de regex sur du texte non structuré) et dispose de TLS. Un service de monitoring devrait idéalement combiner les deux : RDAP en priorité et WHOIS en fallback pour les TLDs qui n'ont pas RDAP.

Stratégie de notifications

Pour un domaine, des périodes d'avertissement plus longues sont appropriées que pour un cert SSL. SSL se renouvelle automatiquement via certbot (typiquement une marge de 30 jours suffit), mais un domaine demande :

  • une vérification manuelle de la carte de crédit dans le compte du registrar
  • une décision financière éventuelle (un renouvellement multi-année est moins cher)
  • une préparation à un rebrand si vous ne voulez pas renouveler le domaine (rare mais ça arrive)

Planning d'alertes recommandé :

  • 90 jours à l'avance - premier avertissement, temps pour la décision multi-année
  • 30 jours à l'avance - escalation si rien ne se passe
  • 14, 7, 3 et 1 jour à l'avance - alertes critiques

Procédure pratique de renouvellement

  1. Connectez-vous au registrar (vérifiez le mot de passe et la 2FA avant l'expiration).
  2. Vérifiez l'état de la carte de paiement - n'est-elle pas sur le point d'expirer ?
  3. Vérifiez le paramètre auto-renewal - est-il activé ? Pour combien d'années ?
  4. Étendez manuellement d'au moins 2 à 3 ans (un enregistrement plus long réduit le risque d'autres oublis).
  5. Après le renouvellement, attendez 24 heures et vérifiez via whois ou RDAP que la Expiry Date s'est déplacée.

Conclusion

L'expiration de domaine fait partie des causes les plus fréquentes de pannes catastrophiques - et l'une des plus faciles à prévenir. Un monitoring WHOIS régulier ne coûte presque rien et fournit des mois d'avertissement avant une catastrophe que le renouvellement lui-même règle en minutes.

Monitoring d'expiration WHOIS

ePulz.io suit WHOIS pour .sk, .cz, .eu, .com, .io et d'autres TLDs. Notification 30, 14, 7, 3 et 1 jour à l'avance. 7 jours gratuits.

Lancer le monitoring →

Partager: Lien copié

Essayez ePulz.io gratuitement - 7 jours sans carte de crédit.

Créer un compte