Un certificat expiré ne prévient personne. Il affiche une page rouge à des visiteurs qui, eux, préviennent tout de suite. À plus grande échelle, un certificat périmé dans des logiciels Ericsson a coupé l'internet mobile d'O2 au Royaume-Uni et de SoftBank au Japon le 6 décembre 2018, pendant plusieurs heures. Ce genre d'incident va devenir plus fréquent : la durée de vie maximale des certificats TLS (Transport Layer Security) publics est en train d'être divisée par huit, par décision du CA/Browser Forum, l'instance où navigateurs et autorités de certification fixent les règles communes.
Ce qui est déjà en vigueur, et ce qui arrive
Adopté en avril 2025 sans opposition, le scrutin SC081v3 fixe trois paliers : 200 jours au 15 mars 2026, 100 jours au 15 mars 2027, 47 jours au 15 mars 2029. Les autorités de certification prennent de l'avance : DigiCert plafonne à 199 jours depuis le 24 février 2026, un jour de marge volontaire pour ne jamais toucher la limite. La première marche est donc franchie, et les deux suivantes sont plus raides.
Le même scrutin raccourcit la réutilisation de la validation de contrôle du domaine (DCV) : en 2029, la preuve qu'un domaine vous appartient devra être refaite tous les 10 jours. Chaque renouvellement suppose donc une vérification de propriété fraîche, et celle-ci peut échouer pour ses propres raisons.
Sept à huit cycles par an et par domaine
À 398 jours, un site se renouvelle une fois l'an : assez rarement pour qu'on l'oublie, et l'oubli ne coûte qu'une fois. À 47 jours, chaque domaine passe par sept à huit cycles annuels. Sur un parc de 1 000 certificats, cela représente des milliers d'opérations par an, chacune avec ses quotas et ses échecs silencieux.
Les chiffres disponibles n'incitent pas à la légèreté. Dans l'édition 2026 du rapport PKI Modernization du Ponemon Institute, menée auprès de 1 833 praticiens, 56 % des organisations disent avoir subi une panne non planifiée liée à une expiration de certificat ou à une erreur de configuration. Les causes les plus citées : la mauvaise configuration (50 %) et l'expiration pure (49 %). Le secteur échoue déjà à 398 jours, et passer à 47 multiplie les occasions de rater.

ACME renouvelle, mais qui regarde ?
« On met ACME et c'est réglé » : l'argument n'est vrai qu'à moitié. Ce protocole, celui qu'utilise Let's Encrypt, automatise la demande et l'installation du certificat. Il ne vérifie pas que le renouvellement a eu lieu. Les pannes viennent de détails que personne ne regarde : un jeton d'API expiré, un challenge DNS qui casse après un changement de registrar. Let's Encrypt a d'ailleurs cessé, en juin 2025, d'envoyer ses e-mails de rappel d'expiration, ce qui laisse la surveillance entièrement à la charge de l'exploitant.
Un renouvellement automatique qui échoue ne fait aucun bruit. Il produit simplement un certificat qui ne change pas.
Sur un certificat de 90 jours, une alerte à J-30 laissait trois semaines pour comprendre. À 47 jours, la même alerte en laisse une, et il faut encore que quelqu'un la reçoive.
Vingt sites, un téléphone, et personne d'astreinte
Prenons un studio qui héberge ou maintient une vingtaine de sites clients. Entre les domaines apex et www, les sous-domaines applicatifs et la préproduction, on compte deux à trois certificats par site, soit 40 à 60 au total (estimation de la rédaction, à ajuster selon les parcs). À sept ou huit renouvellements par certificat, cela donne 300 à 450 renouvellements par an, environ un par jour ouvré, que personne n'a budgété.
Reste à savoir qui reçoit l'alerte, à quelle heure, et avec quelle obligation d'y répondre. Une équipe de cinq personnes n'a pas d'astreinte 24/7 et n'en aura pas. Elle peut nommer un responsable et fixer une vérification hebdomadaire des dates d'expiration. C'est une décision de méthode, qui ne demande aucun nouvel outil.

Le malentendu du « Let's Encrypt le fait déjà »
Beaucoup de sites sont déjà couverts par des certificats gratuits renouvelés automatiquement, et l'on en conclut volontiers que le sujet est classé. C'est vrai pour les stacks récentes, conteneurisées, derrière un reverse proxy qui gère ACME en natif. C'est faux pour un PrestaShop sur mutualisé ou pour un sous-domaine oublié depuis deux ans. Le risque se concentre là où l'automatisation n'a jamais été installée, c'est-à-dire sur les sites les plus anciens, ceux qu'on a cessé de regarder.
La ligne qui manque dans les devis
Le certificat lui-même est gratuit chez Let's Encrypt ou coûte quelques euros. La panne se facture en temps : à 500 € la journée (hypothèse de calcul), une intervention d'urgence d'une demi-journée revient à 250 €, sans compter la confiance d'un client qui voit son site s'afficher en rouge. Une maintenance de certificats chiffrée au devis, avec un inventaire tenu à jour et un temps de réaction annoncé, évite qu'une astreinte non mesurée soit absorbée en silence par le studio jusqu'au jour de la panne.
Le calendrier peut encore glisser : DigiCert indique que ses dates futures sont susceptibles d'évoluer, et aucune règle de cette ampleur n'a été appliquée sans ajustements. Mais depuis le plafond de 398 jours imposé par Apple en 2020 puis suivi par les autres navigateurs, chaque révision n'a fait que raccourcir.
