Comment gérer les SSL de 50 sites clients sans y passer ses nuits
À partir d'une vingtaine de sites clients, le suivi manuel des certificats SSL devient un cauchemar silencieux. Chaque site a son hébergeur, sa configuration, son calendrier — et tout s'effondre dès qu'un certificat passe à la trappe. Si vous gérez 50 sites WordPress en agence, voici comment structurer votre veille SSL pour transformer cinq heures de stress mensuel en quinze minutes de routine sereine.
Le scénario que toutes les agences connaissent
Vendredi 17h. Le téléphone sonne. « Mon site est en panne, les clients me disent qu'ils ont une alerte rouge sur Chrome. » Vous ouvrez le site : certificat expiré depuis quatre heures. Vous saviez que le site existait, vous saviez qu'il avait Let's Encrypt, vous saviez vaguement que tout ça était « automatique ». Sauf qu'un détail vous avait échappé : le client avait migré son hébergement il y a trois mois, sans vous prévenir.
Ce scénario, n'importe quel responsable d'agence l'a vécu au moins une fois. Le problème, c'est que dès qu'on dépasse une certaine taille de parc, ce n'est plus une exception : c'est une statistique. Sur 50 sites avec un taux de panne SSL annuel d'à peine 2 % par site, vous tombez à un incident par an. À 5 %, c'est un incident tous les deux mois — chacun mangeant deux à quatre heures de support d'urgence et un peu de confiance client.
Pourquoi le SSL casse silencieusement en agence
L'hypothèse implicite de la plupart des agences, c'est que « certbot s'occupe de tout ». C'est vrai sur un site, dans un environnement stable et bien documenté. Sur un parc de 50 sites hétérogènes, les modes de panne se multiplient. Voici ceux que l'on voit le plus souvent en audit :
- Le client a migré sans prévenir. Vous gardez la maintenance, lui change d'hébergeur. L'ancien certbot continue de tourner dans le vide pendant que le nouveau serveur n'a rien de configuré.
- Cloudflare a été activé en proxy. Le challenge HTTP-01 passait par le port 80 du serveur d'origine. Le proxy intercepte tout, ACME ne valide plus.
- Le disque est plein. Le renouvellement échoue à l'écriture, certbot logue l'erreur dans un fichier que personne ne lit, et l'expiration s'auto- accomplit deux semaines plus tard.
- Un enregistrement DNS a changé. Le client voulait pointer son domaine sur un nouveau sous-dossier. La validation DNS-01 casse, plus de renouvellement automatique.
- Plesk croit avoir renouvelé. Sauf que le certificat servi par nginx en frontal n'est pas celui qu'a renouvelé Plesk. Le rechargement n'a pas eu lieu.
- L'admin a quitté l'agence. Il avait monté toute la stack ACME il y a deux ans, personne ne sait où sont les configurations ni comment elles tournent.
Aucun de ces cas n'est exotique. Tous arrivent. Et tous ont en commun le même symptôme : le renouvellement automatique échoue sans bruit. Si vous n'avez pas de système qui vérifie indépendamment l'état réel du certificat, vous découvrirez le problème en même temps que le client.
5 conseils pratiques pour reprendre le contrôle
1. Tenir un inventaire vivant de tous les domaines
C'est la base, et c'est presque toujours la première chose qui manque. Un tableau partagé (Notion, Airtable, ou même un bon vieux Google Sheet) qui liste pour chaque domaine : le client, l'hébergeur, le mode de renouvellement (certbot, Plesk, Cloudflare, manuel…), le contact technique, et la date de la dernière vérification manuelle. Mise à jour à chaque arrivée ou départ de client. Sans ça, vous ne savez même pas quoi surveiller.
2. Automatiser le renouvellement — sans s'y fier aveuglément
ACME est votre meilleur ami : certbot, acme.sh, lego, ou un serveur web qui le fait nativement (Caddy, Traefik). Sur chaque serveur, assurez-vous qu'un job de renouvellement tourne et que ses logs sont quelque part de lisible. Mais retenez ceci : l'automatisation n'est qu'une partie du job. La supervision est l'autre moitié, et elle ne peut pas être faite par le même outil qui renouvelle.
3. Surveiller depuis l'extérieur, tous les jours
C'est le point qui change tout. Un monitoring externe et indépendant de votre hébergeur interroge chaque domaine en TLS chaque jour et vous alerte dès qu'une expiration approche, dès qu'une chaîne casse, dès qu'une erreur de configuration apparaît. C'est précisément ce que fait CertWatch : un dashboard unique pour tous vos domaines clients, peu importe leurs hébergeurs, avec des alertes échelonnées à 30, 15, 7 et 1 jour avant chaque expiration. Vous êtes prévenu bien avant que le client puisse l'être.
4. Standardiser la stack quand c'est possible
Cinquante hébergeurs différents, c'est cinquante surfaces de panne différentes. Si vous avez la main sur les choix techniques pour les nouveaux clients, poussez vers une stack unique : un hébergeur que vous maîtrisez, un serveur web qui auto-renouvelle nativement (Caddy est imbattable là-dessus), une convention de configuration documentée. Vous ne pouvez pas tout standardiser sur un parc existant, mais réduire la variance, c'est mécaniquement réduire les modes de panne.
5. Préparer un runbook d'incident SSL
Même avec la meilleure prévention, un incident finira par arriver. Préparez le terrain dès maintenant : qui est notifié, dans quel ordre, par quel canal ? Quelle est la procédure de réémission manuelle sur chacun de vos hébergeurs principaux ? Qui prévient le client, et avec quelle phrase ? Un runbook d'une page par hébergeur vous fera gagner les vingt précieuses minutes qui séparent la panique de la résolution.
Le vrai coût de ne rien faire
Faisons les calculs sur un parc de 50 sites WordPress. Avec un taux de panne SSL réaliste de 3 % par an, vous tombez à environ un incident tous les deux mois et demi. Chaque incident, c'est en moyenne :
- 1 à 2 heures de panne avant que le client ou vous-même ne remarquiez le problème ;
- 30 minutes à 2 heures de support d'urgence pour réémettre, vérifier la chaîne, communiquer ;
- Une discussion désagréable avec le client, qui dilue la confiance dans vos prestations de maintenance ;
- Pour un site e-commerce, une perte sèche de conversion directement chiffrable.
Un seul incident annuel évité paie largement un outil de monitoring dédié. Sur un parc à 50 sites, le ROI est immédiat — et c'est sans compter le confort mental de ne plus avoir à se demander, chaque vendredi soir, lequel de vos clients va appeler en panique.
Conçu pour les agences qui gèrent plusieurs sites
CertWatch surveille quotidiennement tous vos domaines clients, peu importe leur hébergeur, et vous alerte à 30, 15, 7 et 1 jour avant chaque expiration. Plan Pro à 50 domaines — moins cher qu'une seule heure de support d'urgence facturée.
Démarrer la surveillance gratuitementLe mot de la fin
Un certificat SSL expiré, ça ne tue personne. Mais sur un parc de 50 sites, c'est l'accumulation d'incidents évitables qui finit par éroder la marge, la qualité de service perçue, et la sérénité de l'équipe. Les cinq conseils de ce guide ne sont ni révolutionnaires ni complexes — ils demandent simplement d'être appliqués. Un inventaire tenu à jour, des renouvellements automatisés, un monitoring externe quotidien, une stack standardisée et un runbook prêt à l'emploi : voilà ce qui distingue une agence qui dort la nuit d'une agence qui passe ses week-ends à éteindre des incendies.
Le test à 30 secondes : ouvrez votre inventaire client, prenez les trois prochains domaines de la liste, et vérifiez leur état avec notre outil de date d'expiration SSL gratuit. Si l'un d'eux est sous les 30 jours sans que vous le sachiez déjà, c'est le signe qu'il est temps de structurer.
Questions fréquentes
À partir de combien de sites le suivi manuel devient impossible ?+
Au-delà de 15 à 20 sites, le suivi mental ou par tableur Excel commence à dériver. À 50 sites, il faut soit une équipe dédiée, soit un outil automatisé qui vérifie chaque jour l'état des certificats — sinon, vous découvrez les expirations en même temps que vos clients.
Certbot ou acme.sh suffisent-ils en agence ?+
Non. ACME automatise le renouvellement, c'est nécessaire mais pas suffisant. Une cron certbot peut échouer silencieusement pour dix raisons (DNS, pare-feu, disque plein, hébergeur changé…). Sans supervision externe, vous ne le saurez pas avant que le site soit déjà cassé.
Comment surveiller les SSL si chaque site est chez un hébergeur différent ?+
C'est précisément l'avantage d'un monitoring externe comme CertWatch : il interroge chaque domaine en TLS depuis l'extérieur, indépendamment de l'hébergeur. Que vos sites soient sur OVH, o2switch, Infomaniak, Hostinger ou un VPS, la surveillance fonctionne de la même manière partout.
Que faire quand un certificat est déjà expiré ?+
Prévenez le client immédiatement (avant qu'il ne le découvre), forcez le renouvellement manuel ( certbot renew --force-renewal ou via l'interface de l'hébergeur), vérifiez que la chaîne est complète, et documentez la cause pour éviter la récidive. Sur un site e-commerce, chaque heure compte.
Combien coûte un outil de monitoring SSL pour 50 sites ?+
Le plan Pro de CertWatch couvre 50 domaines à un tarif inférieur à une heure de support facturée. Comparé au coût réel d'un incident SSL (panne client, temps de résolution en urgence, perte de confiance), le ROI est atteint dès le premier incident évité.