Comment configurer des alertes de monitoring de domaine

Un domaine qui expire pendant que vous êtes en congé, un concurrent qui récupère un nom que vous surveilliez à la main depuis des semaines, ces situations ne sont pas des accidents rares. Elles arrivent parce que le suivi manuel ne passe pas à l'échelle. Cet article explique comment configurer des alertes de monitoring de domaine : quels types d'événements couvrir, comment paramétrer les seuils, et ce que chaque alerte vérifie concrètement.

Pourquoi les rappels calendrier ne suffisent pas

Un rappel calendrier se déclenche à une date. Les données RDAP, elles, évoluent selon leur propre calendrier, souvent sans préavis.

Le défaut le plus évident : un rappel calendrier ne surveille qu'une date d'expiration. Il ne dit rien sur les changements de statut. Un domaine peut être placé en clientHold (ce qui signifie que ses DNS cessent de répondre) sans aucune communication au propriétaire. Le statut clientTransferProhibited peut être retiré silencieusement, ce qui est souvent la première étape d'un transfert non autorisé. Les nameservers peuvent changer du jour au lendemain.

Imaginez ce qui se passe quand un domaine passe en clientHold de façon inattendue. Votre site devient inaccessible. Vos emails rebondissent. Quand vous vous en rendez compte, plusieurs heures se sont écoulées. Une alerte sur le changement de statut vous aurait prévenu dès le cycle de vérification suivant.

Les vérifications manuelles (ouvrir WHOIS une fois par mois, scanner un tableur) ne donnent qu'un instantané. Elles ne montrent pas ce qui a changé entre deux vérifications.

Les événements qu'un système d'alertes doit couvrir

Un bon système d'alertes va bien au-delà du simple "le domaine va bientôt expirer" :

• Expiration imminente : configurable à J-90, J-30 et J-7 avant l'expiration. Des seuils différents selon les domaines ont du sens, un domaine de production critique mérite une alerte à 90 jours, un domaine défensif de parking peut attendre J-30.
• Changement de statut RDAP : retrait de clientTransferProhibited, ajout de clientHold, apparition de pendingDelete. Chacun signale un problème différent et requiert une action différente.
• Changement de registrar ou de nameservers : un changement soudain de nameservers est l'un des signes les plus clairs d'un hijacking de domaine ou d'un transfert non autorisé en cours.
• Disponibilité : le domaine que vous surveilliez vient de se libérer.

Focus sur les statuts RDAP vs. les statuts WHOIS

La sortie WHOIS est du texte brut. Son format varie selon le registrar, certains écrivent "clientTransferProhibited", d'autres l'abrègent, d'autres encore utilisent une formulation différente. Analyser ce texte de façon fiable est fragile.

RDAP renvoie du JSON structuré avec des codes de statut définis dans la RFC 7483. Les valeurs sont standardisées entre les différents registres. Les alertes basées sur RDAP comparent donc des données homogènes, pas des patterns textuels variables. Et surtout, elles s'appuient sur les données du registre lui-même, pas une copie mise en cache quelque part en amont.

Comment configurer des alertes dans Domain Sentinel

La configuration prend moins de cinq minutes par domaine :

1. Ajouter le domaine à la watchlist. Recherchez le domaine dans la barre de lookup. Que vous le possédiez ou non, cliquez sur "Add to watchlist". Domain Sentinel commence à le surveiller à partir de ce moment.
2. Choisir les événements à surveiller. Pour chaque domaine, sélectionnez les types d'alerte à activer : avertissements d'expiration, changements de statut, changements de registrar/nameservers, disponibilité.
3. Paramétrer les seuils d'expiration. Configurez quand les alertes d'expiration se déclenchent. Par défaut, 30 et 7 jours sont couverts ; vous pouvez ajouter 90 jours pour les domaines critiques.
4. Choisir le canal de notification. L'email est disponible par défaut. Pour les workflows automatisés, la livraison par webhook vous permet de router les alertes vers Slack, PagerDuty, ou tout système acceptant des requêtes POST.

Paramétrage des seuils d'alerte par domaine

Tous les domaines ne méritent pas la même attention. Une agence qui gère 50 domaines clients n'a pas besoin d'alertes à J-90 sur chaque enregistrement défensif, seulement sur ceux qui hébergent des services réels.

Domain Sentinel permet de définir des seuils différents par domaine. Votre domaine de production principal peut avoir des alertes à J-90/J-30/J-7. Un domaine de redirection secondaire n'a peut-être besoin que de J-30 et J-7. Cette granularité compte vraiment quand vous gérez un portefeuille de 20 noms ou plus : elle réduit la fatigue d'alerte tout en maintenant une couverture critique.

Ce que Domain Sentinel vérifie à chaque cycle

À chaque cycle de vérification, Domain Sentinel interroge RDAP pour chaque domaine de votre watchlist. La réponse est comparée au snapshot stocké lors du cycle précédent. Si un champ diffère (statuts, nameservers, registrar, date d'expiration) un événement est enregistré et, si vous avez configuré une alerte pour ce type d'événement, une notification est envoyée.

Les données proviennent directement des registres. Pour .com, c'est Verisign. Pour .fr, c'est l'AFNIC. Aucun cache intermédiaire. Cela compte parce que certains services de monitoring tiers maintiennent leur propre base de données, mise à jour hebdomadairement ou mensuellement, si un domaine passe en pendingDelete un mardi, ils risquent de ne le détecter que le week-end suivant.

Les faux négatifs sont le mode de défaillance dangereux dans le monitoring de domaine. En interrogeant RDAP directement, Domain Sentinel les réduit au minimum.

Cas d'usage : surveillance d'un portefeuille de domaines

Prenons l'exemple d'une agence qui gère 50 domaines clients répartis entre OVH, Gandi et Namecheap. Voici ce que le workflow donnait avant et après la mise en place d'un monitoring centralisé :

	Avant	Après
Suivi d'expiration	Tableau Excel mis à jour manuellement	Automatisé, synchronisé depuis RDAP
Méthode de rappel	Email du registrar (souvent en spam) + entrées calendrier	Alertes configurables par domaine
Détection de changement de statut	Aucune	Alerte immédiate sur tout changement RDAP
Couverture	Dates d'expiration uniquement	Expiration + statuts + nameservers + disponibilité
Risque	Domaines expirant sans que personne le remarque	Détecté des jours ou des semaines à l'avance

L'approche tableur n'est pas mauvaise en principe, elle est juste fragile opérationnellement. Tout système manuel tombe en panne dès que quelqu'un est occupé, change de poste, ou oublie simplement d'ouvrir le fichier.

Si vous gérez plus de trois domaines, le suivi manuel crée un risque opérationnel réel. Ajoutez-les à votre watchlist, configurez les alertes une fois, Domain Sentinel s'occupe du reste.