Domaine expiré, site hors ligne : ce qui se passe ensuite

Vendredi votre application marchait. Lundi c’est un avertissement de navigateur pleine page, ou bien il n’y a plus rien du tout, et rien n’a changé dans votre code. Quelqu’un vous envoie une capture d’écran et vous tapez les mots qui sont dessus dans un moteur de recherche : domaine expiré, site hors ligne.

Voici la partie que la plupart des conseils sur le sujet ratent. Deux pannes différentes produisent ce matin-là, elles tournent sur deux horloges différentes, et celle qui a l’air la moins chère est la sérieuse. Un certificat périmé est bruyant, gênant, et remplaçable aujourd’hui. Un domaine périmé est silencieux au début, et si vous le laissez assez longtemps, votre application n’est pas hors ligne. Elle appartient à quelqu’un d’autre.

Deux choses se tiennent entre votre application et les gens qui l’utilisent. Le domaine est le bail de la boutique : le nom au-dessus de la porte et le droit de continuer à s’en servir. Le certificat est la licence en vitrine qui dit que cette boutique est bien celle de l’enseigne. Vous louez les deux. Les deux se renouvellent à une date que vous avez fixée une fois et que vous n’avez pas regardée depuis.

Que se passe-t-il quand mon domaine expire ?

Votre application s’éteint, puis un compte à rebours démarre en trois étapes.

Pour .com et les autres domaines génériques, le calendrier vient de l’ICANN et non de votre bureau d’enregistrement, il est donc globalement le même quel que soit l’endroit où vous avez acheté le nom.

Encore à vous, déjà éteint. Votre bureau d’enregistrement garde le nom renouvelable au tarif normal pendant une fenêtre qu’il choisit, en général quelques semaines. L’Expired Registration Recovery Policy de l’ICANN exige qu’il coupe votre DNS pendant cette fenêtre : pendant au moins les huit derniers jours où le nom est encore renouvelable, il doit cesser de pointer où que ce soit. Votre application tombe donc bien avant que le nom n’aille nulle part, et c’est en général comme ça que le propriétaire l’apprend.

Supprimé, et encore récupérable. Quand le bureau d’enregistrement supprime enfin l’enregistrement, une Redemption Grace Period de 30 jours commence. L’ICANN l’exige de presque tous les registres génériques. Vous seul pouvez ramener le nom pendant cette période, uniquement via le bureau d’enregistrement qui l’a supprimé, et vous payez des frais de restauration en plus du renouvellement. L’ICANN ne fixe pas ces frais, et ils sont bien supérieurs à un renouvellement.

Pending delete. Environ cinq jours pendant lesquels ni vous ni votre bureau d’enregistrement ne changez quoi que ce soit. Ensuite le nom est libéré.

La même politique dit que votre bureau d’enregistrement doit vous écrire : deux fois avant l’expiration, à peu près un mois et une semaine avant, et une fois de plus dans les cinq jours qui suivent. Donc si un domaine à vous a déjà expiré sans prévenir, la chose à vérifier n’est pas le calendrier. C’est quelle adresse figure sur votre compte chez le bureau d’enregistrement.

Les domaines nationaux ont leurs propres calendriers. .io, .co.uk, .de et les autres sortent de cette politique, et certains sont nettement moins indulgents. Si votre application est sur l’un d’eux, lisez la page de cycle de vie de votre registre plutôt que cette section.

Quelqu’un peut-il prendre mon domaine après son expiration ?

Oui, une fois qu’il est libéré, et c’est ce qui distingue ce cas de tout le reste d’un rapport de sécurité.

Tout autre constat est une erreur dans quelque chose qui vous appartient. Vous pouvez aller la corriger. Un domaine libéré quitte votre propriété entièrement : le nom est enregistré au nom de quelqu’un d’autre, et tout ce qui pointait vers votre application pointe maintenant vers cette personne. Les favoris. Le lien dans votre e-mail de bienvenue. L’adresse sur la carte que vous avez distribuée à une conférence. Le lien de réinitialisation de mot de passe que vous avez envoyé la semaine dernière.

Les noms partent vite, aussi. Il existe des entreprises dont le produit entier consiste à demander un domaine à la seconde où il se libère, et c’est pourquoi un nom qui a le moindre trafic reste rarement longtemps sans propriétaire.

Vous pouvez encore essayer de le racheter. Vous négociez alors avec celui qui est arrivé le premier, au prix qu’il annonce. Un certificat qui a expiré ce matin peut être remplacé ce matin ; un domaine libéré le mois dernier n’est peut-être pas à vendre.

Pourquoi mon site affiche-t-il « non sécurisé » alors qu’hier tout allait bien ?

Deux choses différentes produisent cela, et laquelle vous avez est écrit à l’écran.

Une mention dans la barre d’adresse, c’est votre navigateur qui dit que la page est arrivée en HTTP simple, sans aucun certificat en jeu. Votre page se charge quand même en dessous. Rien n’a expiré. Quelque chose sert votre site sans HTTPS, ce qui est un problème à part, pas celui-ci.

Un certificat expiré ou non approuvé n’est pas une mention. C’est un mur. Votre application est remplacée par une page entière : dans Chrome, l’écran qui dit que la connexion n’est pas privée ; dans Firefox, l’avertissement sur un risque de sécurité potentiel. Pour atteindre votre site, il faut trouver un bouton Avancé et cliquer à travers un avertissement qui dit que le site n’est pas sûr. La plupart des visiteurs ne le feront pas.

Lisez le code sous l’avertissement avant de changer quoi que ce soit, parce qu’il dit de quelle réparation vous avez besoin :

Cette dernière ligne vaut d’être lue avant d’aller chercher chez votre hébergeur. Une seule personne signalant un avertissement de certificat peut n’être que l’ordinateur de cette personne.

Pourquoi un certificat HTTPS cesse de se renouveler sans que rien ne casse

Parce que le renouvellement est censé arriver un mois avant que le certificat ne compte, et qu’un renouvellement échoué ne change rien de visible.

La plupart des applications construites ainsi sont servies par un hébergeur qui récupère des certificats chez Let’s Encrypt et les renouvelle pour vous. Let’s Encrypt émet des certificats de 90 jours et recommande de renouveler tous les 60 jours, donc le mécanisme qui garde votre site en vie est censé réussir alors qu’il reste encore 30 jours.

Pour en obtenir un nouveau, votre hébergeur doit prouver à l’autorité qu’il contrôle toujours votre nom : soit en servant un fichier que l’autorité demande sur votre domaine, soit en écrivant un enregistrement dans votre DNS. Tout ce qui casse cette preuve casse le renouvellement. Déplacer votre DNS chez un autre fournisseur. Mettre un proxy devant l’application. Faire pointer le nom ailleurs pour essayer quelque chose puis le remettre. Ajouter un enregistrement CAA, c’est-à-dire une entrée DNS qui nomme les autorités autorisées à émettre pour votre domaine et qui interdit en silence toutes celles qu’elle ne nomme pas.

Rien de tout cela ne fait tomber votre site. Le certificat que vous avez déjà continue de fonctionner, l’application reste donc en ligne et le cadenas reste là pendant que le renouvellement échoue de nouveau chaque jour pendant un mois sans que personne ne regarde.

La lettre qui arrivait autrefois a cessé, elle aussi. Let’s Encrypt a mis fin à ses e-mails de notification d’expiration le 4 juin 2025, après l’avoir annoncé en janvier de la même année : le renouvellement est automatisé chez la plupart des abonnés désormais, et conserver des millions d’adresses e-mail attachées à des données d’émission était un coût en vie privée qu’ils préféraient ne pas porter. Les deux raisons sont bonnes. Cela a quand même supprimé le seul message qui atteignait un humain quand l’automatisme s’arrêtait.

Est-ce que Lovable ou Vercel renouvellent mon certificat à ma place ?

Tant que votre application est sur le sous-domaine du constructeur, les deux dates leur appartiennent et il n’y en a aucune que vous puissiez rater.

Sur votreapp.lovable.app, ou une adresse en vercel.app ou netlify.app, la plateforme possède le nom, renouvelle l’enregistrement, émet le certificat et le renouvelle. Notre propre vérification de domaine ne va même pas les chercher. Elle indique que l’application est sur un domaine géré par une plateforme et qu’il n’y a rien ici à surveiller pour vous.

Connecter un domaine à vous déplace l’un des deux vers vous à coup sûr, et l’autre parfois :

C’est la ligne du renouvellement qui surprend les gens. Rien dans le constructeur ne l’annonce. Vous ajoutez un domaine, l’application se charge dessus, et vous possédez désormais une entrée de calendrier que vous n’avez jamais créée.

Comment vérifier les deux tout de suite ?

De l’extérieur, sans vous connecter à quoi que ce soit.

Le certificat. Ouvrez votre application, cliquez sur le cadenas dans la barre d’adresse, ouvrez les détails du certificat et lisez la date de fin de validité. Sur un certificat standard de 90 jours, plus de 30 jours restants veut dire que le renouvellement fonctionne. Moins de 30 jours veut dire que le renouvellement qui aurait déjà dû avoir lieu n’a pas eu lieu.

Le domaine. Connectez-vous à votre bureau d’enregistrement et lisez trois choses. La date d’expiration. Si la carte derrière le renouvellement automatique est toujours valide, parce qu’un renouvellement automatique avec une carte morte est la façon la plus courante dont cela arrive à quelqu’un qui était sûr que c’était impossible. Et l’adresse e-mail du compte, parce que c’est là que partira chaque avertissement qui vous est dû.

Les deux d’un coup. Notre scan gratuit lit les deux depuis l’extérieur, avec sept autres vérifications, en une vingtaine de secondes et sans compte : scannez votre application. Il affiche la date de fin du certificat et, pour un domaine que vous avez enregistré vous-même, celle de l’enregistrement. Sur un sous-domaine de plateforme, il le dit plutôt que de vous inventer une date.

Ce que nous avons trouvé sur 30 998 applications

Les deux constats sont rares, et chacun d’entre eux appartenait à quelqu’un qui avait connecté un domaine à lui.

Entre le 12 et le 14 août 2026, nous avons passé les mêmes neuf vérifications externes sur 30 998 applications en ligne construites avec Lovable, Bolt, v0, Replit et Base44. Parmi les applications dont chaque vérification a obtenu une réponse, 55 sur 30 980 avaient un domaine expiré ou proche de l’expiration, et 32 sur 30 851 avaient un certificat expiré, proche de l’expiration ou non approuvé. Les chiffres complets sont dans notre rapport de scan.

Cela fait 87 applications, ce qui ressemble à une erreur d’arrondi jusqu’à ce qu’on demande qui elles étaient. 1 090 des scans de cette campagne portaient sur une application dont le propriétaire avait enregistré le domaine. Les 87 étaient dans ce groupe, et pas une seule application sur un sous-domaine de plateforme ne portait l’un des deux constats. Parmi les applications qui peuvent avoir ce problème, cela fait à peu près une sur douze.

L’essentiel de cette colonne est un avertissement et non une panne, et c’est la partie utile : quelqu’un avait encore le temps. Cinq des domaines étaient à moins de sept jours et un était déjà parti. Treize des applications montraient à chaque visiteur un avertissement de navigateur au moment où nous avons regardé, cinq avec un certificat expiré et huit avec un certificat que rien n’approuve.

Dans les deux cas, une date passe pendant que personne ne regarde, et c’est exactement le genre de problème pour lequel quelque chose qui vérifie toutes les heures est utile.

Reeve Monitor repasse les neuf vérifications toutes les heures sur jusqu’à trois applications, surveille la disponibilité toutes les 60 secondes et envoie un rapport mensuel. Pour ces deux constats, il fait quelque chose qu’il ne fait pour rien d’autre : il vous écrit qu’un certificat ou un enregistrement arrive à son terme même quand votre note n’a pas changé. Monitor est à €12 par mois au tarif public, avec sept jours gratuits avant le premier prélèvement, et la page des tarifs est parfois en dessous du chiffre indiqué ici et jamais au-dessus.

Monitor surveille et rien de plus. Si vous voulez aussi une copie de votre base de données gardée dans un endroit que votre constructeur ne peut pas atteindre, c’est Care, et cela couvre Supabase.

Ce qu’il faut faire maintenant

Aucun des deux n’est une erreur que quelqu’un a faite dans votre application, et c’est pour cela qu’on les laisse si facilement hors de la liste. Mettez-les dessus. Si vous préférez tout traiter d’un coup, la checklist de sécurité en 10 minutes couvre les neuf vérifications dans l’ordre où elles valent la peine.