Qui renouvelle le certificat SSL de votre PWA ?

Le scénario est toujours le même. Le site fonctionnait hier. Personne n'a touché à rien — ni au contenu, ni aux réglages, ni au code. Et ce matin, chaque visiteur tombe sur un avertissement en plein écran, avec un bouton « Revenir en arrière » que la plupart s'empressent de cliquer. Rien n'est cassé, au sens propre : tout est encore là, intact. Une date est passée, c'est tout.

Votre app aussi a une face web : sa PWA — la version de votre app qui se visite dans un navigateur, à votre adresse, sur votre domaine. Cette adresse est protégée par le même mécanisme que le reste du web : un certificat. La question de cet article tient donc en une ligne : ce certificat a une date de fin ; qui s'occupe de la suivante ?

Un certificat SSL — le nom vient du protocole des débuts du web ; il a depuis été remplacé par son successeur, TLS, mais l'usage a conservé « SSL » — fait deux choses : il prouve que l'adresse que visite votre utilisateur est bien la vôtre, et il chiffre les échanges. C'est lui, le cadenas dans la barre d'adresse.

Et il expire. Ce n'est ni un défaut ni une négligence : c'est le modèle de sécurité. Un certificat volé ou compromis est dangereux aussi longtemps qu'il est valide — plus sa vie est courte, plus la fenêtre de risque est étroite. Let's Encrypt, l'autorité qui sécurise une grande partie du web, émet des certificats de 90 jours, exprès.

Et le mouvement s'accélère. En 2025, l'industrie — navigateurs et autorités de certification réunis au sein du CA/Browser Forum — a acté un raccourcissement par paliers de la durée de vie maximale des certificats publics : 398 jours aujourd'hui, 200 en 2026, 100 en 2027, 47 jours à partir de mars 2029. À cet horizon, un certificat se renouvelle environ huit fois par an. Le web n'a pas seulement accepté que les certificats expirent : il a décidé qu'ils expireraient de plus en plus souvent.

Une date n'est dangereuse que si personne ne tient le calendrier. L'industrie vient de multiplier les dates.

Imaginez que vous mainteniez vous-même votre app et son infrastructure. Ce calendrier serait le vôtre. Obtenir le certificat, l'installer, prouver à chaque renouvellement que le domaine est bien à vous, recommencer avant chaque échéance. Mettre en place une automatisation, bien sûr — puis surveiller l'automatisation elle-même, car c'est le grand classique du genre : le script de renouvellement qui a cessé de tourner depuis des mois, et qu'on découvre le matin où le certificat expire. Les avertissements, eux, partent vers une adresse e-mail consultée une fois par an.

À 90 jours de durée de vie, ce travail est déjà une astreinte. À 47 jours, il change de nature : le renouvellement manuel cesse d'être une option, même mauvaise. Tenir ce calendrier devient un métier — ou une chose qu'on confie à quelqu'un dont c'est le métier.

Quand vous connectez votre nom de domaine, le certificat de ce domaine est provisionné automatiquement — vous n'avez rien à acheter, rien à installer. Sa date d'expiration est ensuite suivie comme un état du système, et le certificat est renouvelé avant l'échéance : l'incident n'est pas réparé rapidement, il est anticipé. C'est toute la différence entre réagir à une panne et faire en sorte qu'elle ne se produise pas.

C'est aussi pour cela que cette famille d'incidents se prête si bien à être prise en charge : c'est la panne la plus prévisible du monde. Tout est daté, tout est connu d'avance. Il faut seulement que quelqu'un en fasse son travail — chaque jour, pour toutes les apps à la fois, y compris quand les échéances se rapprocheront.

La carte complète de qui s'occupe de quoi est dans le premier article ; pour les échéances, elle est courte.

Votre nom de domaine. Il est enregistré chez votre registrar, à votre nom — c'est ce qui fait qu'il est à vous — et il se renouvelle. Un domaine expiré emporte tout ce qui vit dessus, quelle que soit la santé du reste. Ce renouvellement-là ne peut venir que de vous.

Votre compte développeur Apple et Google. Même logique, même conclusion — il est à votre nom, et sa date est la vôtre. La règle vaut pour toute cette série : ce qui est commun à toutes les apps vit côté plateforme ; ce qui est enregistré à votre nom vit chez vous.

Le bénéfice, comme souvent dans cette série, est invisible : le cadenas est dans la barre d'adresse ce matin, comme hier, comme au prochain renouvellement — et il n'y a rien d'autre à raconter. Pendant que les durées de vie raccourcissent, la seule chose qui change pour vous est : rien.

Pour la version ingénierie de ce qui expire et se dégrade sur trois ans, le détail est côté dev.to. Et si votre app n'existe pas encore, autant la construire là où le calendrier est tenu pour vous : créer mon app avec GoodBarber.

Faut-il acheter un certificat SSL pour votre PWA ?

Avec GoodBarber, non : quand vous connectez votre nom de domaine, un certificat est provisionné automatiquement, puis renouvelé avant chaque échéance. Si vous maintenez votre infrastructure vous-même, l'obtention, l'installation et chaque renouvellement sont à votre charge.

Que se passe-t-il quand un certificat SSL expire ?

Les navigateurs affichent un avertissement en plein écran — « Votre connexion n'est pas privée » — et la plupart des visiteurs rebroussent chemin. Rien n'est cassé : le site et son contenu sont intacts, une date est simplement passée. La remise en route consiste à renouveler le certificat ; sur une plateforme qui tient le calendrier, ce renouvellement précède la date.

Pourquoi les certificats SSL expirent-ils de plus en plus vite ?

Parce que c'est plus sûr : un certificat compromis est dangereux tant qu'il est valide, et une vie courte réduit cette fenêtre. L'industrie a acté en 2025 un raccourcissement par paliers, de 398 jours aujourd'hui vers 47 jours en 2029. Conséquence pratique : le renouvellement manuel devient intenable, et l'automatisation du calendrier cesse d'être un confort pour devenir la seule approche viable.

Mon app native est-elle concernée ?

L'écran « Votre connexion n'est pas privée » est une histoire de navigateur : il concerne votre PWA et les pages web liées à votre app. Votre app native, installée depuis les stores, ne l'affichera pas — mais elle communique elle aussi par des connexions chiffrées, et une partie de ses appels s'appuie sur le même certificat que votre PWA. Le calendrier dont parle cet article la concerne donc aussi.