CIIFragments Studio est agréée CII : récupérez jusqu'à 20 % de vos dépenses en développement logicielEn savoir plus
Retour au blog
Nom de domaine expiré : comment notre monitoring a sauvé un clientStudio · 9 min

Nom de domaine expiré : comment notre monitoring a sauvé un client

Nom de domaine expiré, renouvellement automatique en échec, erreur DNS : retour d'expérience sur une panne détectée en 10 minutes par notre monitoring.

KA
Tech Lead

Un nom de domaine qui expire ne prévient pas : un soir, votre site, votre API et votre application cessent de répondre en même temps. Voici comment notre monitoring a repéré ce scénario chez un client en dix minutes, et ce que vous pouvez mettre en place pour qu'il ne vous arrive jamais.

Le monitoring de site web consiste à vérifier automatiquement, à intervalle régulier, que votre site, votre API et votre application répondent correctement. C'est le filet de sécurité le plus fiable contre une panne que personne ne voit venir : l'expiration d'un nom de domaine. Quand le renouvellement automatique échoue sans bruit, seul un contrôle externe permet de réagir avant que le domaine ne soit perdu.

Pourquoi un nom de domaine expiré met hors ligne tout votre écosystème ?

Un nom de domaine expiré coupe la résolution DNS de tout ce qui l'utilise. Le DNS (Domain Name System) est l'annuaire d'Internet : il traduit votre-domaine.fr en adresse IP. Sans lui, aucun navigateur, aucune application mobile et aucun serveur ne sait plus où trouver vos services.

La panne ne touche donc pas seulement le site vitrine. Elle frappe en même temps chaque sous-domaine (api., app., admin.), les e-mails envoyés à votre domaine et les intégrations de vos partenaires. Côté visiteur, Chrome affiche l'erreur DNS_PROBE_FINISHED_NXDOMAIN : le domaine « n'existe plus ».

Ce qui se passe après l'expiration

Un nom de domaine ne s'achète pas : il se loue pour une durée limitée, souvent un an, auprès d'un bureau d'enregistrement (registrar en anglais). C'est la société chez qui vous gérez votre domaine, comme OVHcloud, Gandi ou Ionos.

Pour les extensions génériques (.com, .net, .io…), la politique ERRP de l'ICANN encadre le calendrier :

  • Le bureau d'enregistrement doit envoyer au moins deux rappels avant l'échéance, environ un mois et une semaine avant.
  • Après l'expiration, il doit interrompre la résolution DNS, au minimum pendant les huit derniers jours où le domaine reste renouvelable.
  • Une fois le domaine supprimé, une période de rédemption de 30 jours permet encore au titulaire de le restaurer, généralement contre des frais de restauration.
  • Passé ce délai, le nom retombe dans le domaine public et n'importe qui peut l'enregistrer.

Pour le .fr, l'AFNIC prévoit également une période de rédemption de 30 jours. Ensuite, le nom peut être capté selon la règle du « premier arrivé, premier servi », y compris par des acteurs spécialisés dans la récupération de domaines expirés.

Pourquoi le renouvellement automatique ne suffit pas

Le renouvellement automatique est indispensable, mais il échoue en silence. Chez Fragments Studio, on retrouve presque toujours les mêmes causes :

  • La carte bancaire enregistrée chez le bureau d'enregistrement a expiré ou a été remplacée.
  • Le compte chez le bureau d'enregistrement est au nom d'un ancien salarié ou d'un ancien prestataire.
  • Les rappels partent vers une adresse que plus personne ne lit.
  • L'option a été désactivée lors d'un transfert entre deux bureaux d'enregistrement, puis jamais réactivée.

Ce n'est pas un problème technique, c'est un problème de procédure. Selon l'Annual Outage Analysis 2025 d'Uptime Institute, près de 40 % des organisations ont subi une panne majeure causée par une erreur humaine en trois ans, et 85 % de ces incidents viennent de procédures non suivies ou mal conçues.

Retour d'expérience : un domaine expiré détecté en 10 minutes

Notre position est simple : une panne doit être détectée par l'équipe de maintenance, pas par les clients de nos clients. Le cas qui suit, vécu en octobre 2026, illustre pourquoi.

Le contexte

L'un de nos clients exploite une plateforme B2C composée de trois briques : un site vitrine, une API et une application web métier. Les trois services partagent le même nom de domaine. Le site vitrine est hébergé chez un éditeur no-code, l'API et l'application sur une autre infrastructure.

Les trois services sont surveillés dans Cockpit, notre plateforme de pilotage de projets, dont le module de monitoring interroge chaque service toutes les 5 minutes.

La chronologie de l'incident

La chronologie de l'incident
Heure (Paris)Événement
Lundi 12 octobre, 19 h 08Premier check en échec sur l'API : aucune réponse HTTP
19 h 18Troisième échec consécutif : alerte envoyée à notre équipe
19 h 18Le site vitrine cesse de répondre à son tour
19 h 37L'application web tombe : les trois services sont hors ligne

Le décalage d'une demi-heure entre les trois services s'explique par les caches DNS : chaque résolveur conserve la dernière réponse connue pendant une durée limitée (le TTL), puis découvre que le domaine ne résout plus.

Le diagnostic et la résolution

Le diagnostic a tenu en une question : qu'ont en commun trois services hébergés chez deux fournisseurs différents, qui tombent ensemble sans renvoyer le moindre code HTTP ? Leur nom de domaine. La vérification de l'enregistrement a confirmé l'expiration : le renouvellement automatique n'était pas passé.

Le domaine étant détenu par le client, nous ne pouvions pas le renouveler nous-mêmes. Nous l'avons donc contacté directement, en lui expliquant la cause et la démarche exacte à suivre chez son bureau d'enregistrement. Dès le renouvellement validé et la résolution DNS rétablie, les trois services sont revenus en ligne dans la même minute, sans intervention sur le code ni perte de données.

L'essentiel est ailleurs : le domaine n'est jamais entré en période de rédemption. Pas de frais de restauration, pas de risque de voir un tiers capter le nom, pas de référencement à reconstruire. Sans alerte, ce client aurait pu découvrir le problème par ses utilisateurs, ou pire, des semaines plus tard.

Monitoring site web : que surveiller pour ne jamais être pris de court ?

Un monitoring efficace vérifie chaque service exposé, depuis l'extérieur, avec des seuils qui distinguent une vraie panne d'un simple ralentissement. Le chapitre monitoring du livre SRE de Google le résume bien : une alerte doit signaler un problème réel et appeler une action humaine.

Monitoring site web : que surveiller pour ne jamais être pris de court ?
ContrôleCe qu'il détecteFréquence conseillée
Disponibilité HTTPSite, API ou application qui ne répond plus1 à 5 minutes
Mot-clé dans la pagePage de parking du bureau d'enregistrement renvoyant un code 2001 à 5 minutes
LatenceService dégradé avant la panne francheÀ chaque check
Date d'expiration du domaineÉchéance qui approche, renouvellement non effectuéQuotidienne, alertes à J-30 et J-7
Certificat SSLCertificat expiré ou bientôt expiréQuotidienne

Le contrôle par mot-clé est souvent oublié. Pourtant, la politique de l'ICANN autorise le bureau d'enregistrement à rediriger un domaine expiré vers une page d'information : le serveur répond alors « 200 OK » et un monitoring qui ne regarde que le code HTTP reste au vert.

Comment nous configurons le monitoring dans Cockpit

Pour chaque projet en maintenance, nous déclarons un moniteur par service exposé : site, API (sur une route /health) et application. Nos réglages par défaut :

  • Un check toutes les 5 minutes, depuis l'extérieur de l'infrastructure du client.
  • Une alerte après 3 échecs consécutifs, pour écarter les faux positifs liés à un incident réseau ponctuel.
  • Un seuil de latence à 500 ms pour signaler un service dégradé avant qu'il ne tombe.
  • Une chronologie d'incident complète (début, fin, nombre de checks en échec) reprise dans le rapport de maintenance du client.

Un monitoring sans personne pour lire l'alerte ne sert à rien. Chez Fragments Studio, chaque alerte arrive à l'équipe qui connaît le projet, avec le contexte pour agir. Pour l'observabilité côté code, voyez aussi notre article sur NestJS Observe.

Maintenance proactive : la check-list pour sécuriser vos noms de domaine

La maintenance proactive consiste à traiter les risques connus avant qu'ils ne deviennent des incidents. Pour vos noms de domaine, sept actions suffisent :

  1. Activez le renouvellement automatique et renouvelez vos domaines critiques pour plusieurs années.
  2. Enregistrez une carte d'entreprise et notez sa date d'expiration dans votre calendrier.
  3. Utilisez une adresse de contact générique (tech@votre-domaine.fr) plutôt que celle d'une personne.
  4. Ouvrez le compte chez votre bureau d'enregistrement au nom de l'entreprise, avec au moins deux administrateurs et la double authentification.
  5. Activez le verrou de transfert pour empêcher tout transfert non autorisé.
  6. Surveillez la date d'expiration et la disponibilité de chaque service avec un outil externe.
  7. Documentez qui détient quels accès et qui appeler en cas d'incident.

Ces règles valent aussi pour les accès hérités d'un ancien prestataire : c'est l'un des premiers points que nous vérifions quand nous reprenons un projet mal développé.

Questions fréquentes

Que se passe-t-il quand un nom de domaine expire ? Le bureau d'enregistrement, c'est-à-dire la société chez qui le domaine est loué, interrompt la résolution DNS : le site, l'API, les sous-domaines et souvent les e-mails cessent de fonctionner. Le domaine reste ensuite renouvelable quelques jours à quelques semaines, puis entre en période de rédemption de 30 jours. Passé ce délai, il redevient libre et n'importe qui peut l'enregistrer.

Comment savoir si une panne de site vient d'un problème DNS ? Une panne DNS se reconnaît à l'absence totale de réponse HTTP : le navigateur affiche DNS_PROBE_FINISHED_NXDOMAIN au lieu d'une erreur 500 ou 502. Si plusieurs services hébergés chez des fournisseurs différents tombent ensemble, le point commun est presque toujours le nom de domaine ou sa zone DNS.

À quelle fréquence faut-il surveiller un site web ? Pour un site vitrine, un check toutes les 5 minutes suffit. Pour une API ou une application critique, visez 1 à 5 minutes, avec une alerte après 2 ou 3 échecs consécutifs pour éviter les faux positifs. La date d'expiration du domaine et du certificat SSL se contrôle une fois par jour.

Le renouvellement automatique d'un nom de domaine suffit-il ? Non. Il dépend d'un moyen de paiement valide, d'un compte actif chez le bureau d'enregistrement et d'une option qui peut être désactivée lors d'un transfert. Il doit être doublé d'une surveillance externe de la date d'expiration et de la disponibilité des services.

Conclusion

Un nom de domaine expiré est l'une des pannes les plus bêtes et les plus coûteuses qui soient : rien ne casse dans le code, mais tout devient inaccessible. Le renouvellement automatique réduit le risque, il ne le supprime pas. Ce qui fait la différence, c'est un monitoring externe de chaque service et une équipe qui réagit dans les minutes qui suivent l'alerte.

C'est exactement ce que nous attendons d'une maintenance professionnelle : voir le problème avant le client, comprendre la cause vite et l'accompagner jusqu'à la résolution.


Confiez la surveillance de vos services à une équipe qui réagit

Une maintenance efficace, c'est un monitoring en place, des alertes lues et une équipe qui connaît votre projet.

Notre contenu vous a été utile ?

Suivez Fragments Studio sur Google

Ajoutez-nous à vos sources préférées : nos articles remontent alors en priorité dans Top Stories, les AI Overviews et l'AI Mode.

Ajouter aux sources préférées

Prêts à donner vie à vos projets ?

Fragments Studio s'occupe de tout : de la stratégie à la mise en production.

Discuter de mon projet
Discuter de mon projet