Plusieurs sites, un seul calendrier : pourquoi l'hiver 2026-2027 met à l'épreuve la gestion de votre parc web

Une entreprise qui exploite plusieurs sites web (site institutionnel, sites de marques, microsites de campagne, extranet, boutique, préproductions oubliées) entre dans un hiver chargé. Entre le 13 octobre 2026 et le 15 mars 2027, plusieurs échéances techniques tombent coup sur coup : fins de support de CMS, fin de vie d'une version de PHP très répandue, raccourcissement de la durée de vie des certificats. Prise site par site, chacune est gérable. Cumulées sur un parc de dix, vingt ou cinquante sites aux versions hétérogènes, elles deviennent un vrai sujet de gouvernance. Ce billet vous donne le calendrier vérifié, la méthode d'inventaire, les arbitrages possibles et un plan d'action sur quatre-vingt-dix jours.

Pourquoi l'hiver 2026-2027 met à l'épreuve un parc de sites web

L'hiver 2026-2027 concentre, en cinq mois, des échéances qui touchent presque tous les parcs de sites : Joomla 5 est passé en correctifs de sécurité seuls le 13 octobre 2026, Drupal 10 arrive en fin de vie le 9 décembre 2026, PHP 8.2 cesse de recevoir des correctifs le 31 décembre 2026, et les certificats TLS raccourcissent encore en février et mars 2027. Le risque ne vient pas d'une échéance isolée, mais de leur simultanéité sur des sites que personne ne suit de la même façon.

Dans la plupart des organisations que nous accompagnons, les sites n'ont pas été créés en même temps, ni par le même prestataire, ni sur le même CMS. Le site corporate a été refondu en 2022 sous WordPress, la marque rachetée tourne encore sous Joomla, le site de recrutement a été livré par une agence disparue depuis, et un microsite de salon professionnel de 2021 est toujours en ligne parce que personne n'a pensé à le fermer. Chacun a son hébergement, son registraire de nom de domaine, ses identifiants et son niveau de mise à jour.

Tant que rien ne casse, cette hétérogénéité reste invisible. Elle se révèle au moment où une contrainte extérieure s'impose à tous les sites en même temps. C'est précisément ce que produit le calendrier des prochains mois : il ne demande pas un effort ponctuel sur un site, il exige une vision d'ensemble du parc, et c'est souvent là que le bât blesse.

Le vrai coût de l'absence de vue d'ensemble

Le coût d'un parc mal gouverné ne se mesure pas seulement en incidents. Il se mesure en heures perdues à retrouver un accès, en interventions d'urgence facturées au prix fort, en sites piratés parce qu'ils étaient sortis de tout suivi, et en décisions repoussées faute de savoir combien de sites sont concernés. À l'inverse, une organisation qui sait exactement ce qu'elle possède peut mutualiser, prioriser et négocier.

Le calendrier vérifié des échéances, d'octobre 2026 à mars 2027

Six dates officielles structurent les prochains mois pour un parc de sites : le 7 octobre 2026 (annonce Let's Encrypt), le 13 octobre 2026 (Joomla 5 en sécurité seule), le 9 décembre 2026 (fin de vie de Drupal 10), le 31 décembre 2026 (fin de PHP 8.2), le 10 février 2027 (certificats Let's Encrypt de 64 jours) et le 15 mars 2027 (certificats publics limités à 100 jours). Toutes ont été vérifiées sur les sources des éditeurs le 19 octobre 2026.

Les sources primaires de ce tableau sont la feuille de route officielle de Joomla, le calendrier des versions du cœur Drupal, la page des versions supportées de PHP et l'annonce de Let's Encrypt du 7 octobre 2026. Nous avons détaillé l'impact budgétaire des fins de support CMS dans notre billet consacré au calendrier 2026-2027 des fins de support ; ici, l'angle est celui du parc dans son ensemble.

Ce que ce calendrier ne dit pas

Un calendrier d'éditeur indique quand un logiciel cesse d'être corrigé. Il ne dit rien de l'état réel de vos sites. Un site Drupal 10 peut déjà être sur une version mineure non supportée : selon le calendrier Drupal, la branche 10.5 a perdu son support de sécurité en juin 2026, et seule la 10.6 reste corrigée jusqu'à décembre. Un site WordPress à jour peut tourner sur un hébergement resté en PHP 8.1, sans correctifs depuis le 31 décembre 2025. C'est pourquoi la première étape n'est pas la mise à jour, mais l'inventaire.

L'inventaire du parc : la première chose que la plupart des entreprises n'ont pas

L'inventaire d'un parc de sites web est un tableau unique qui recense, pour chaque site en ligne, son nom de domaine, son CMS et sa version, sa version de PHP, son hébergeur, son registraire, son certificat, son responsable métier et son prestataire. Sans ce tableau, aucune des échéances de l'hiver ne peut être chiffrée ni planifiée, et les sites oubliés restent hors de tout suivi de sécurité.

Lorsque nous réalisons un premier état des lieux pour un client multi-sites, l'écart entre le nombre de sites déclarés et le nombre de sites réellement en ligne est fréquent. Les sources de ces sites « fantômes » sont toujours les mêmes : microsites événementiels jamais fermés, préproductions laissées accessibles et parfois indexées, anciens domaines de marque qui affichent encore une ancienne version du site, sous-domaines créés pour un test, sites de filiales gérés localement.

Les colonnes indispensables

• Identification : URL principale, alias et sous-domaines, rôle du site (vitrine, recrutement, extranet, boutique, campagne).
• Socle technique : CMS et version exacte (WordPress 6.x, Joomla 5.4.x ou 6.x, Drupal 10.x ou 11.x, PrestaShop 8 ou 9), version de PHP effectivement servie, base de données.
• Infrastructure : hébergeur, type d'offre (mutualisé, VPS, infogéré), localisation des sauvegardes.
• Domaine et certificat : registraire, date d'expiration du domaine, renouvellement automatique activé ou non, émetteur et date d'expiration du certificat, mode de renouvellement.
• Gouvernance : responsable métier, prestataire technique, existence d'un contrat de maintenance, date de la dernière mise à jour.
• Décision : conserver, migrer, fusionner ou fermer, avec une échéance.

Comment retrouver les sites oubliés

Trois sources croisées suffisent généralement. La première est la facturation : les factures d'hébergement et de noms de domaine révèlent des contrats dont personne ne se souvenait. La deuxième est le registraire, dont la console liste tous les domaines d'un compte, avec leurs dates d'échéance. La troisième est l'historique des certificats publics : les journaux de transparence des certificats recensent les sous-domaines pour lesquels un certificat a été émis, ce qui fait souvent ressurgir des préproductions et des tests. Un audit de site web appliqué à l'échelle du parc formalise ce travail et produit le tableau de référence.

Certificats et noms de domaine : des expirations qui ne préviennent plus

Sur un parc de sites, les certificats TLS et les noms de domaine sont la première cause d'incident évitable, car leurs échéances se multiplient et les alertes automatiques disparaissent. Let's Encrypt a cessé d'envoyer ses e-mails d'expiration le 4 juin 2025, la durée maximale des certificats publics est passée à 200 jours le 15 mars 2026 et tombera à 100 jours le 15 mars 2027. Seule l'automatisation supervisée tient la cadence.

Pendant des années, beaucoup de responsables de sites ont compté sur un filet de sécurité implicite : le courriel de rappel. Let's Encrypt l'a supprimé, en expliquant dans son annonce du 22 janvier 2025 que le renouvellement automatique était devenu la norme. Pour un site isolé correctement configuré, cela ne change rien. Pour un parc où certains sites ont été installés à la main, où un hébergement a changé sans que le client ACME soit reconfiguré, ou où un certificat commercial a été posé manuellement, cela signifie qu'une expiration peut survenir sans aucun signal préalable.

Le raccourcissement par étapes

La règle votée au CA/Browser Forum en avril 2025 (ballot SC-081) organise une baisse progressive de la durée maximale des certificats publics : 200 jours depuis le 15 mars 2026, 100 jours à partir du 15 mars 2027, puis 47 jours à partir du 15 mars 2029. De son côté, Let's Encrypt, qui délivrait des certificats de 90 jours, passera son profil par défaut à 64 jours le 10 février 2027, puis à 45 jours le 16 février 2028, selon son plan publié le 2 décembre 2025. Let's Encrypt recommande désormais de renouveler aux deux tiers de la durée de vie du certificat plutôt qu'à intervalle fixe : un renouvellement programmé tous les 60 jours ne suffira plus.

Concrètement, un parc de vingt sites avec des certificats de 64 jours, c'est plus d'une centaine de renouvellements par an. Chacun dépend d'une chaîne qui peut casser silencieusement : tâche planifiée désactivée lors d'une migration, règle de pare-feu qui bloque la validation, enregistrement DNS modifié, quota atteint. La réponse n'est pas de surveiller à la main, mais de superviser : une sonde externe qui vérifie chaque jour la date d'expiration réelle du certificat servi et alerte à trente jours, puis à sept jours.

Les noms de domaine, échéance la plus banale et la plus grave

Un domaine expiré coupe à la fois le site et, souvent, la messagerie. Pour un .fr, les registraires décrivent une période de rédemption de trente jours pendant laquelle le titulaire peut encore récupérer son nom, moyennant des frais supplémentaires, avant que le domaine ne redevienne disponible. Les délais exacts autour de cette période varient selon les registraires : c'est une raison de plus pour centraliser les domaines du parc chez un nombre réduit de registraires, au nom de l'entreprise, avec renouvellement automatique et une adresse de contact générique qui ne disparaît pas au départ d'un salarié.

Versions hétérogènes : mettre à jour, migrer, fusionner ou fermer

Face aux fins de support, chaque site d'un parc relève de l'une de quatre décisions : le mettre à jour s'il est sur une branche maintenue, le migrer s'il dépend d'une version en fin de vie, le fusionner dans un autre site s'il ne justifie plus un socle propre, ou le fermer proprement s'il n'a plus d'usage. Décider site par site, avec une échéance, évite de tout repousser faute de budget global.

L'erreur la plus fréquente est de traiter le parc comme une liste de mises à jour, alors qu'il s'agit d'abord d'une liste de décisions. Certains sites méritent un investissement, d'autres non. Un microsite de campagne de 2021 qui tourne sur Drupal 9 n'a probablement pas vocation à être migré vers Drupal 11 : son contenu peut être archivé sur le site principal et le domaine redirigé en 301.

Une grille de décision simple

Ne pas oublier les contraintes croisées

Les échéances interagissent. Passer un hébergement mutualisé en PHP 8.3 pour tenir l'échéance du 31 décembre peut casser un site Joomla ou PrestaShop dont une extension n'est pas compatible. À l'inverse, PrestaShop 8 n'est pas officiellement supporté au-delà de PHP 8.1, ce qui place les boutiques restées en version 8 dans une impasse que seule une montée vers PrestaShop 9 résout. Sur un parc, ces dépendances se gèrent dans un seul planning, pas dans des tickets isolés chez des prestataires différents.

Accès, comptes et propriété : qui détient vraiment les clés du parc

Un parc de sites n'est gouverné que si l'entreprise détient elle-même les accès critiques de chaque site : compte du registraire, compte d'hébergement, administrateur du CMS, outils de mesure et de balisage, comptes de sauvegarde. Lorsque ces accès sont dispersés entre salariés partis et prestataires successifs, la moindre intervention urgente commence par une enquête, et un départ peut suffire à bloquer un site.

La reprise d'un site par une nouvelle équipe révèle souvent cette dispersion : le domaine a été déposé au nom personnel d'un ancien responsable communication, l'hébergement est payé par la carte d'une filiale, le compte administrateur WordPress est celui d'une agence qui ne répond plus, et le conteneur Google Tag Manager appartient à un compte que personne ne connaît. Chacun de ces points est réglable, mais rarement en urgence.

Les règles minimales

• Domaines et hébergements au nom de l'entreprise, avec des adresses de contact génériques.
• Un compte nominatif par intervenant sur chaque CMS, jamais d'identifiant partagé, et suppression des comptes à chaque fin de mission.
• Authentification à deux facteurs sur les registraires, les hébergeurs et les comptes administrateurs.
• Un coffre d'accès centralisé, sous le contrôle de l'entreprise : notre FAQ explique à quoi sert un gestionnaire de mots de passe pour les accès d'un site professionnel.
• Une revue des accès au moins une fois par an, idéalement à chaque changement de prestataire.

Ces règles ne sont pas seulement une précaution technique. Elles conditionnent la réversibilité : une entreprise qui détient ses accès peut changer de prestataire sans interruption de service. Une entreprise qui ne les détient pas reste dépendante, même d'un prestataire qui ne lui donne plus satisfaction.

Organiser la maintenance d'un parc : centraliser sans uniformiser

Maintenir un parc de sites efficacement consiste à centraliser la supervision, les procédures et le calendrier, tout en respectant la diversité des CMS. On n'impose pas un seul outil à tous les sites, mais une seule méthode : même tableau de bord, mêmes fenêtres de maintenance, mêmes règles de sauvegarde et de test, même niveau de service selon la criticité de chaque site.

Uniformiser à tout prix, en migrant tous les sites vers le même CMS, est rarement rentable à court terme. Ce qui produit un gain immédiat, c'est la mutualisation du travail répétitif : la veille de sécurité est faite une fois pour tous les sites Joomla, les mises à jour WordPress sont testées une fois sur une préproduction de référence, et les procédures de restauration sont écrites une fois et appliquées partout.

Les outils par écosystème

Chaque CMS dispose d'outils de gestion centralisée. Pour WordPress, des consoles comme MainWP ou ManageWP permettent de piloter les mises à jour de nombreux sites depuis un seul tableau de bord. Pour Joomla, le cœur intègre depuis la version 5.4 un mécanisme de mises à jour automatisées du noyau, et des services comme Watchful couvrent la supervision multi-sites. Pour Drupal, la ligne de commande Drush et le module Automatic Updates outillent les opérations répétitives. Pour les sauvegardes, Akeeba Backup reste une référence sur Joomla, avec son équivalent pour WordPress. L'outil compte moins que la règle : aucune mise à jour majeure sans sauvegarde vérifiée et sans test sur une copie.

Hiérarchiser par criticité

Tous les sites d'un parc ne méritent pas le même niveau de service. Une classification en trois niveaux suffit souvent : les sites critiques (boutique, extranet client, site générant des demandes commerciales) avec supervision continue et délai d'intervention court ; les sites importants (institutionnel, recrutement) avec maintenance mensuelle ; les sites secondaires avec maintenance de sécurité minimale ou fermeture programmée. Cette hiérarchie permet de concentrer le budget là où l'interruption coûte cher. C'est le principe de notre offre d'infogérance de parc digital.

Le calendrier de maintenance commun

Un parc bien tenu suit un rythme connu de tous : une fenêtre de mises à jour de sécurité hebdomadaire ou bimensuelle, une revue mensuelle des versions et des certificats, une revue trimestrielle des décisions de migration ou de fermeture, et un test de restauration au moins une fois par an sur chaque site critique. Les éditeurs facilitent cette planification : Joomla, par exemple, publie ses versions correctives à dates prévues, toutes les six semaines environ, sur sa feuille de route.

Combien coûte la maintenance d'un parc de sites : les fourchettes du marché

En France, en 2026, les forfaits de maintenance observés sur le marché vont d'environ 60 € HT par mois et par site pour une maintenance de sécurité de base à 400 € HT par mois pour un niveau incluant un délai d'intervention garanti de quelques heures et des évolutions. Les interventions hors forfait se situent couramment entre 70 et 95 € HT de l'heure. Sur un parc, la mutualisation fait baisser le coût unitaire.

Ces fourchettes proviennent de grilles publiées par des agences françaises en 2026 et d'annuaires de prestataires ; elles donnent un ordre de grandeur, pas un prix. Le niveau intermédiaire le plus souvent cité pour une PME se situe autour de 120 à 180 € HT par mois et par site. Le taux journalier d'un développeur WordPress en agence est couramment annoncé entre 450 et 650 € HT. Nous ne publions pas de tarif, car le coût réel dépend du nombre de sites, de leurs CMS, de leur état de départ et du niveau de service attendu.

Ce qui fait varier le budget d'un parc

• L'hétérogénéité : vingt sites WordPress coûtent moins à maintenir que vingt sites répartis sur quatre CMS et trois hébergeurs.
• L'état de départ : un parc avec plusieurs sites en fin de vie exige un budget de rattrapage avant de passer en régime de croisière.
• La criticité : un engagement d'intervention en quatre heures sur une boutique n'a pas le même coût qu'une maintenance mensuelle sur un site vitrine.
• Les évolutions : la maintenance corrective et de sécurité est distincte de la tierce maintenance applicative, qui couvre les évolutions fonctionnelles.

Le calcul à faire avant de signer

La bonne comparaison n'est pas entre le prix d'un contrat et zéro, mais entre le prix d'un contrat et le coût des incidents évités : une journée d'indisponibilité d'un site générateur de demandes, une restauration après piratage, une migration réalisée dans l'urgence quelques jours avant une fin de support. Un contrat de maintenance web bien construit précise, site par site, ce qui est inclus, le délai d'intervention et la façon dont les migrations sont chiffrées.

Le plan d'action en quatre-vingt-dix jours

D'ici la mi-janvier 2027, un parc de sites peut être remis sous contrôle en trois étapes : un inventaire complet en octobre, le traitement des urgences de fin de support et de PHP avant le 31 décembre, puis l'automatisation supervisée des certificats et des domaines avant le 10 février 2027. Chaque étape produit un livrable vérifiable, ce qui permet de suivre l'avancement sans expertise technique.

Semaines 1 à 4 : savoir ce que l'on possède

• Constituer le tableau d'inventaire à partir des factures, des consoles de registraires et des journaux de certificats.
• Identifier pour chaque site le CMS, sa version exacte et la version de PHP servie.
• Repérer les sites sans responsable, sans contrat ou sans sauvegarde vérifiable.
• Livrable : un tableau unique, partagé entre la direction, le marketing et la DSI.

Semaines 5 à 10 : traiter les échéances de décembre

• Décider du sort de chaque site Drupal 10 avant le 9 décembre 2026.
• Planifier le passage de chaque hébergement en PHP 8.3 ou 8.4 avant le 31 décembre, après test sur une copie.
• Programmer les fermetures et fusions, avec leurs redirections 301.
• Livrable : la liste des sites migrés, fusionnés, fermés ou en risque accepté et documenté.

Semaines 11 à 13 : sécuriser ce qui expire

• Vérifier que chaque certificat est renouvelé automatiquement et que le client ACME suit la durée réelle du certificat.
• Mettre en place une supervision externe des certificats et des domaines, avec alertes à trente et sept jours.
• Regrouper les domaines au nom de l'entreprise, avec renouvellement automatique.
• Livrable : un tableau de bord des expirations, sans aucune échéance non surveillée.

Questions fréquentes

À partir de combien de sites parle-t-on d'un parc à gouverner ?

Dès trois ou quatre sites gérés par des prestataires ou sur des CMS différents, une gouvernance de parc devient utile. Le critère n'est pas le nombre, mais la dispersion : plusieurs hébergeurs, registraires ou versions de CMS suffisent à créer des angles morts, notamment sur les certificats, les domaines et les fins de support.

Que se passe-t-il si un site Drupal 10 n'est pas migré avant le 9 décembre 2026 ?

Le site continue de fonctionner, mais il ne reçoit plus aucun correctif, y compris de sécurité. Chaque faille publiée après cette date reste ouverte. Le risque augmente avec le temps, et les extensions contribuées cessent elles aussi progressivement d'être maintenues pour Drupal 10.

Faut-il passer tous les sites d'un parc sur le même CMS ?

Pas nécessairement. Uniformiser réduit le coût de maintenance à long terme, mais une migration complète coûte cher et prend du temps. La démarche la plus rentable consiste à unifier la méthode (supervision, sauvegardes, calendrier) et à profiter de chaque fin de support pour décider s'il faut migrer, fusionner ou fermer un site.

Les certificats Let's Encrypt de 64 jours imposent-ils une action de notre part ?

Oui, une vérification. Si le renouvellement est automatique et suit la durée réelle du certificat, rien ne change. Si une tâche renouvelle à intervalle fixe, par exemple tous les 60 jours, elle deviendra insuffisante à partir du 10 février 2027. Une supervision externe des dates d'expiration détecte ces cas avant la coupure.

Peut-on confier la maintenance d'un parc à un seul prestataire sans perdre la main ?

Oui, à condition que l'entreprise reste titulaire de ses domaines, hébergements et accès, et que le contrat prévoie la réversibilité : remise des accès, documentation et sauvegardes en fin de mission. Un prestataire unique simplifie la coordination ; la propriété des accès garantit votre liberté de changer.

Reprendre la main sur votre parc de sites

Les échéances de l'hiver 2026-2027 sont connues et datées ; ce qui manque le plus souvent, c'est la vue d'ensemble. Depuis 2005, Pulsar Agency maintient des sites WordPress, Joomla, Drupal et PrestaShop pour des PME et des grands comptes en Île-de-France et dans les Hauts-de-France. Nous commençons par l'inventaire, nous priorisons selon la criticité de chaque site, puis nous prenons en charge la maintenance, les migrations et la supervision. Découvrez notre offre d'infogérance de parc digital et demandez un premier état des lieux de vos sites.