Décembre 2026 : passer les mises à jour majeures sans casse

Pourquoi décembre 2026 concentre les mises à jour majeures

Décembre 2026 réunit en quelques semaines trois événements qui touchent la plupart des sites vitrines : WordPress 7.2 sort le 8 décembre, Drupal 12 et Drupal 11.5 sortent la semaine du 7 décembre, et PHP 8.2 cesse de recevoir des correctifs de sécurité le 31 décembre. Un site qui n'a pas de méthode de mise à jour éprouvée aborde donc la fin d'année avec un risque réel de régression ou d'exposition.

Ces dates ne sont pas des estimations de presse. Le calendrier officiel de WordPress 7.2 fixe une première version candidate (RC1) au 17 novembre, une RC2 au 24 novembre, une RC3 au 1er décembre, une répétition générale le 7 décembre et la publication le 8 décembre 2026. WordPress 7.2 sera la dernière version majeure de l'année et embarque un nouveau thème par défaut, baptisé Ipsum. Côté Drupal, le calendrier des versions de Drupal annonce Drupal 12.0.0 et 11.5.0 la semaine du 7 décembre, avec, la même semaine, la fin du support de sécurité des branches 11.3.x et 10.6.x : Drupal 10 atteint sa fin de vie le 9 décembre 2026. Enfin, la page des versions supportées de PHP indique que PHP 8.2 n'est plus couvert après le 31 décembre 2026, alors que PHP 8.6 a atteint sa dernière version candidate (RC5) le 5 novembre et que sa version finale, PHP 8.6.0, est annoncée pour le 19 novembre 2026.

Joomla est le seul des trois grands CMS open source à ne pas publier de version majeure ce mois-ci. La feuille de route de Joomla, mise à jour le 13 octobre 2026, prévoit Joomla 6.2.1 le 24 novembre 2026 et 6.2.2 le 5 janvier 2027. En revanche, Joomla 5 est sorti de son support correctif régulier le 13 octobre 2026 et ne reçoit plus que des correctifs de sécurité jusqu'au 12 octobre 2027 : un site Joomla 5 entre donc dans sa dernière année et doit planifier son passage à Joomla 6.

Pour un dirigeant ou un responsable communication, l'enjeu n'est pas de suivre ces numéros de version. Il est de savoir si son site passera ces changements sans incident, et qui s'en charge. C'est précisément l'objet de ce billet : expliquer ce qu'est une mise à jour majeure, pourquoi elle se prépare, et décrire la méthode qui permet de la conduire sans casser un site en production.

Mise à jour mineure, majeure ou changement de branche : ce qui change vraiment

Une mise à jour mineure corrige des bugs ou des failles sans modifier le fonctionnement du logiciel, alors qu'une mise à jour majeure change des interfaces, des prérequis ou des comportements, ce qui peut rendre incompatibles des extensions, un thème ou du code sur mesure. La première s'applique vite, la seconde se teste avant d'être appliquée.

La logique des numéros de version

Les CMS suivent, avec des nuances, la gestion sémantique des versions. Chez Joomla et Drupal, le premier chiffre (Joomla 5 vers Joomla 6, Drupal 11 vers Drupal 12) signale une rupture de compatibilité possible : du code ancien est retiré, des prérequis techniques montent. Le deuxième chiffre (Joomla 6.2, Drupal 11.5) ajoute des fonctions sans casser l'existant, en principe. Le troisième (Joomla 6.2.1) corrige des bugs ou des failles. La feuille de route de Joomla le rappelle explicitement : les versions mineures ne doivent pas casser la rétrocompatibilité, toute rupture étant reportée à la version majeure suivante.

WordPress fonctionne différemment. Pour lui, une « version majeure » se reconnaît aux deux premiers chiffres : 7.1 puis 7.2 sont deux versions majeures, et 7.1.4 est une version de maintenance ou de sécurité. WordPress publie ainsi trois versions majeures par an, ce qui signifie qu'un site WordPress encaisse en réalité un changement significatif tous les quatre mois environ.

Pourquoi une version majeure casse plus souvent les extensions que le cœur

Le cœur d'un CMS est testé par des centaines de contributeurs avant sa sortie. Les extensions, elles, sont développées par des éditeurs indépendants, de taille très variable, qui ne publient pas toujours une version compatible le jour même. Le rapport Patchstack sur l'état de la sécurité WordPress en 2026 montre l'ampleur de cet écosystème : 91 % des nouvelles vulnérabilités découvertes en 2025 concernaient des extensions, 9 % des thèmes, et seulement 6 vulnérabilités de faible priorité le cœur de WordPress. Le même raisonnement vaut pour la compatibilité : quand une mise à jour majeure pose problème sur un site, c'est presque toujours une extension, un thème enfant ou un développement spécifique qui est en cause, rarement le CMS lui-même.

Le cas particulier du changement de version PHP

Une mise à jour majeure du langage serveur produit les mêmes effets qu'une mise à jour majeure du CMS, mais elle est souvent décidée par l'hébergeur, parfois sans préavis lisible. Passer de PHP 8.2 à PHP 8.3 ou 8.4 peut faire apparaître des avertissements de dépréciation, voire des erreurs fatales dans une extension ancienne. Nous détaillons ce point dans notre billet sur la fin de vie de PHP 8.2 au 31 décembre 2026.

Ce que les mises à jour automatiques font, et ce qu'elles ne font pas

Les mises à jour automatiques des CMS appliquent rapidement les correctifs de sécurité, ce qui réduit la fenêtre d'exposition, mais elles ne testent pas votre site après coup : elles ne savent pas si votre formulaire de contact envoie encore ses messages ou si votre page d'accueil s'affiche correctement. Elles complètent une maintenance, elles ne la remplacent pas.

WordPress : majeures automatiques par défaut sur les installations récentes

depuis WordPress 5.6, sortie en décembre 2020, les nouvelles installations de WordPress reçoivent par défaut les mises à jour majeures du cœur, et pas seulement les mineures. Les sites installés avant cette version ont conservé l'ancien comportement (mineures seulement) sauf activation manuelle. Concrètement, beaucoup de sites créés depuis 2021 passeront seuls en WordPress 7.2 dans les heures ou les jours qui suivent le 8 décembre 2026, sans que personne n'ait vérifié la compatibilité de leurs extensions. Ce comportement se règle avec la constante WP_AUTO_UPDATE_CORE ou le filtre allow_major_auto_core_updates : encore faut-il savoir dans quel état se trouve votre installation.

Joomla : mises à jour automatiques du cœur depuis Joomla 5.4

Joomla 5.4, publié le 14 octobre 2025, a introduit les mises à jour automatisées du cœur, reprises dans Joomla 6. C'est un progrès net pour les correctifs de sécurité. Mais le passage d'une branche majeure à l'autre (Joomla 5 vers Joomla 6) reste une opération distincte, avec ses propres contrôles de compatibilité des extensions, que l'outil de mise à jour signale avant de proposer la bascule.

Drupal : un rythme de sécurité à connaître

Drupal publie ses correctifs de sécurité dans une fenêtre fixe, en général le troisième mercredi du mois, et ses versions correctives le premier mercredi. Un site Drupal maintenu sérieusement anticipe donc ces dates. En revanche, la mise à jour automatique du cœur via le module Automatic Updates ne couvre que les versions correctives : le passage de Drupal 11 à Drupal 12, ou de Drupal 10 à Drupal 11, reste un projet à part entière.

Le vrai risque : la mise à jour silencieuse qui casse un détail

L'incident typique n'est pas un écran blanc spectaculaire, que l'on repère en quelques minutes. C'est un formulaire qui n'envoie plus ses courriels, un module de prise de rendez-vous qui affiche une erreur JavaScript sur mobile, une galerie qui ne charge plus, un bandeau cookies qui ne bloque plus les traceurs avant consentement. Ces régressions passent inaperçues pendant des jours, et coûtent des contacts commerciaux ou exposent à un risque de conformité. C'est pourquoi une mise à jour, automatique ou manuelle, doit être suivie d'un contrôle fonctionnel.

Avant de toucher au site : inventaire et lecture des prérequis

La première étape d'une mise à jour majeure consiste à dresser l'inventaire exact du site, cœur, extensions, thème, version de PHP et de base de données, puis à le confronter aux prérequis de la nouvelle version. Cet inventaire prend souvent moins d'une heure et évite la majorité des mauvaises surprises.

Les cinq informations à réunir

• La version exacte du CMS et la branche dont elle dépend (par exemple Joomla 5.4.10, Drupal 10.6, WordPress 7.1.4).
• La liste des extensions, avec pour chacune sa version, sa date de dernière mise à jour et l'existence d'une version annoncée compatible avec la cible. Une extension qui n'a pas été mise à jour depuis plus d'un an est un signal d'alerte.
• Le thème : thème du commerce, thème enfant, ou thème développé sur mesure. Les surcharges de gabarits (overrides Joomla, templates Twig Drupal, fichiers du thème enfant WordPress) sont les premières à souffrir d'un changement majeur.
• Les versions serveur : PHP, MySQL ou MariaDB, et les extensions PHP actives. Joomla 6 exige au minimum PHP 8.3, Drupal 11 également, et Drupal 12 relève encore ces exigences.
• Le code spécifique : petits développements, scripts d'import, connecteurs vers un CRM ou un outil d'emailing. Ce sont souvent les éléments les moins documentés.

Lire les notes de version, pas seulement le numéro

Chaque version majeure s'accompagne de notes de développement qui listent les changements susceptibles d'affecter les extensions. WordPress les regroupe dans un « Field Guide » publié au stade de la version candidate, soit autour du 17 novembre 2026 pour la version 7.2. Joomla et Drupal publient des guides de migration et des listes de fonctions retirées. Les lire, ou les faire lire par votre prestataire, permet de repérer avant toute manipulation qu'un module utilise une fonction supprimée.

Décider ce qui ne sera pas mis à jour

L'inventaire sert aussi à faire le ménage. Une extension désactivée depuis deux ans, un module installé pour un test, un thème inutilisé : autant d'éléments qui ralentissent la mise à jour et élargissent la surface d'attaque. Les supprimer avant la mise à jour majeure simplifie les tests et réduit le risque. Lorsque l'inventaire révèle une dette importante, extensions abandonnées, code non documenté, versions très en retard, un audit préalable devient plus rentable qu'une mise à jour à l'aveugle.

La préproduction : copier, mettre à jour, tester

Une mise à jour majeure ne s'applique jamais en premier sur le site en ligne : elle se joue d'abord sur une copie fidèle du site, appelée préproduction, où l'on peut casser, corriger et recommencer sans conséquence pour les visiteurs. C'est la seule façon de connaître le résultat avant de l'imposer à vos clients.

Une copie fidèle, sinon le test ne vaut rien

La préproduction n'a de valeur que si elle reproduit fidèlement la production : même version de PHP que celle visée, même base de données récente, mêmes fichiers, même configuration serveur dans la mesure du possible. Un test réalisé sur une copie vieille de six mois ou sur un hébergement différent donne une fausse assurance. Nous expliquons plus en détail l'intérêt d'un environnement de préproduction dans notre FAQ dédiée.

Protéger la copie

Une préproduction mal protégée crée elle-même des problèmes : contenu dupliqué indexé par les moteurs de recherche, formulaires de test qui envoient des courriels à de vrais clients, connecteurs qui écrivent dans le CRM de production. Les bonnes pratiques sont simples : accès protégé par mot de passe, directive de non-indexation, envoi de courriels désactivé ou redirigé vers une boîte de test, clés d'API de production remplacées par des clés de test.

L'ordre des opérations

1. Sauvegarde complète de la production (fichiers et base de données), vérifiée.
2. Clonage vers la préproduction et contrôle que le clone fonctionne à l'identique.
3. Mise à jour de la version de PHP si nécessaire, seule, puis premier contrôle.
4. Mise à jour des extensions dans leur dernière version compatible avec l'ancienne et la nouvelle version du cœur.
5. Mise à jour majeure du cœur.
6. Mise à jour des extensions qui exigent la nouvelle version du cœur.
7. Tests de non-régression, corrections, puis nouveau passage complet si des corrections ont été nécessaires.

Cet ordre n'est pas arbitraire. En séparant les changements, on sait immédiatement lequel provoque une erreur. Tout appliquer d'un coup oblige à chercher l'origine d'un problème parmi des dizaines de modifications simultanées.

Le plan de tests de non-régression d'un site vitrine

Un test de non-régression vérifie que tout ce qui fonctionnait avant la mise à jour fonctionne encore après. Pour un site vitrine, une liste écrite d'une vingtaine de contrôles, toujours la même, suffit à couvrir l'essentiel en une à deux heures, et transforme une impression (« ça a l'air d'aller ») en constat vérifiable.

Les parcours qui rapportent

• Envoi de chaque formulaire (contact, devis, candidature) avec réception effective du courriel, y compris dans le CRM si un connecteur existe.
• Prise de rendez-vous, téléchargement de documentation, inscription à une lettre d'information.
• Numéros de téléphone cliquables sur mobile, liens vers les plans d'accès.
• Recherche interne du site, si elle existe.

L'affichage

• Page d'accueil, une page de chaque gabarit (page de service, actualité, liste d'actualités, page de contact, mentions légales).
• Contrôle sur ordinateur, sur tablette et sur au moins deux téléphones de systèmes différents.
• Menus, sous-menus et pied de page, fil d'Ariane.
• Images, galeries, vidéos intégrées, cartes.

Le technique et la conformité

• Console du navigateur sans nouvelle erreur JavaScript, journal d'erreurs PHP sans nouvelle alerte.
• Bandeau de consentement qui bloque toujours les traceurs avant accord, outils de mesure d'audience qui remontent toujours des données.
• Balises title et meta description, données structurées, plan de site XML, fichier robots.txt inchangés.
• Redirections 301 existantes toujours actives.
• Temps de chargement comparable à la situation antérieure.
• Accès à l'administration pour chaque profil d'utilisateur, édition et publication d'un contenu de test.

Comparer plutôt que regarder

Les outils de comparaison visuelle par capture d'écran, qui photographient les pages avant et après la mise à jour et signalent les différences au pixel près, réduisent fortement le temps de contrôle sur les sites de plusieurs dizaines de pages. Ils ne remplacent pas les tests de parcours, car un formulaire peut s'afficher parfaitement et ne rien envoyer.

Le jour J : fenêtre de mise en production, sauvegarde et retour arrière

Une mise en production réussie se décide avant de commencer : on choisit un créneau de faible trafic, on prend une sauvegarde vérifiée juste avant l'intervention, et on fixe à l'avance le critère qui déclenchera un retour à l'état antérieur. Sans plan de retour arrière écrit, une mise à jour ratée devient un incident de plusieurs heures.

Choisir le bon créneau

Le bon créneau dépend de votre activité, pas de la disponibilité du prestataire. Pour un site B2B, un mardi ou un mercredi matin tôt est souvent préférable à un vendredi soir : si un problème apparaît, les équipes sont présentes pour le constater et le corriger. À l'inverse, une période de forte activité commerciale, campagne en cours, salon, fin d'exercice, impose de différer les mises à jour majeures, et de ne laisser passer que les correctifs de sécurité urgents.

La sauvegarde qui compte

La seule sauvegarde utile est celle prise juste avant l'intervention et dont on a vérifié qu'elle se restaure. Les outils dédiés comme Akeeba Backup pour Joomla, les extensions de sauvegarde de WordPress ou les instantanés proposés par l'hébergeur conviennent, à condition que la restauration ait été testée au moins une fois sur ce site. Une sauvegarde jamais restaurée reste une hypothèse.

Définir le seuil de retour arrière

Avant d'intervenir, on écrit noir sur blanc ce qui déclenche une restauration : par exemple, un formulaire principal en échec non corrigeable en trente minutes, ou une page d'accueil dégradée. Cette règle évite le scénario classique où l'on enchaîne les correctifs improvisés en production pendant des heures. Si un incident survient malgré tout, notre service de dépannage de site internet intervient pour rétablir le site et analyser la cause.

Après la mise en production

Le plan de tests se rejoue en production, de façon allégée, dans l'heure qui suit. Une surveillance renforcée (disponibilité, erreurs serveur, réception des formulaires) est maintenue quelques jours. Enfin, l'intervention est consignée : versions avant et après, anomalies rencontrées, corrections appliquées. Ce journal sert lors de la mise à jour suivante et facilite toute reprise du site par un autre intervenant.

Faut-il mettre à jour le jour de la sortie ou attendre ?

Pour une mise à jour majeure, attendre quelques jours à quelques semaines après la sortie est généralement raisonnable, le temps que les éditeurs d'extensions publient leurs versions compatibles et que les premiers correctifs sortent ; pour une mise à jour de sécurité, en revanche, chaque jour d'attente augmente le risque. Les deux décisions ne se prennent pas de la même façon.

Les correctifs de sécurité n'attendent pas

Le rapport Patchstack de 2026 estime à 5 heures le délai médian pondéré entre la divulgation d'une faille WordPress et sa première exploitation massive. À ce rythme, un correctif de sécurité appliqué une semaine plus tard l'est souvent après les premières attaques. Les versions de sécurité (WordPress 7.1.4, Joomla 6.2.1, versions de sécurité mensuelles de Drupal) doivent donc s'appliquer dans les jours qui suivent leur publication, idéalement dans les 24 à 72 heures, avec un contrôle rapide après coup.

Les versions majeures se planifient

Pour une version majeure, la prudence consiste à tester sur la préproduction dès la version candidate, puis à mettre en production une fois les extensions critiques déclarées compatibles. Les calendriers publiés aident à planifier : RC1 de WordPress 7.2 le 17 novembre, sortie le 8 décembre ; RC1 de Drupal 12 et 11.5 la semaine du 9 novembre, sortie la semaine du 7 décembre. Tester dès la RC laisse trois semaines pour identifier les incompatibilités et alerter les éditeurs concernés.

Attendre ne veut pas dire rester en arrière

Le report doit avoir une limite. Dans le cas de Drupal, la publication de 12.0.0 et 11.5.0 met fin au support de sécurité de 11.3.x : un site resté en 11.3 doit au minimum passer en 11.4 ou 11.5, même s'il n'envisage pas encore Drupal 12. La branche 11.4 reste couverte jusqu'au 21 avril 2027. De même, un site Joomla 5 peut attendre Joomla 6.2.1 ou 6.2.2 pour migrer, mais pas au-delà de l'automne 2027. Une politique claire tient en une phrase : sécurité sous 72 heures, majeure dans les huit semaines, jamais de branche hors support.

Plusieurs sites, plusieurs CMS : raisonner à l'échelle du parc

Une organisation qui gère plusieurs sites, site institutionnel, sites de marque, sites de filiales ou de salons, doit traiter les mises à jour comme une campagne planifiée, avec un inventaire commun, un ordre de passage et des tests standardisés, faute de quoi chaque site prend du retard à son propre rythme et les versions divergent.

Inventaire consolidé. Le point de départ est un tableau unique : chaque site, son CMS, sa version, sa version de PHP, son hébergeur, son responsable fonctionnel et la date de sa dernière mise à jour majeure. En décembre 2026, ce tableau répond immédiatement à trois questions : quels sites sont encore en Drupal 10, quels sites tournent en PHP 8.2, quels sites WordPress vont basculer seuls en 7.2.

Ordre de passage. On commence par le site le moins critique qui partage la même pile technique que les autres, de façon à repérer les incompatibilités communes avant de toucher aux sites qui génèrent des contacts. Les extensions et thèmes mutualisés entre sites sont corrigés une fois, puis déployés partout.

Standardiser pour aller plus vite. Le même plan de tests, adapté à chaque site, le même journal d'intervention et la même politique de sauvegarde permettent de traiter un parc de dix ou vingt sites en quelques semaines sans dégrader la qualité. C'est le principe de notre offre d'infogérance de parc digital, pensée pour les organisations qui ne veulent plus suivre ces échéances site par site.

Combien coûte une mise à jour majeure bien faite

Le coût d'une mise à jour majeure dépend surtout de l'état de départ du site : un site régulièrement maintenu passe une version majeure en quelques heures de travail incluses dans un contrat, alors qu'un site laissé plusieurs années sans mise à jour peut demander plusieurs jours de remise à niveau, voire une migration. Le prix de la maintenance régulière se compare donc au coût d'un rattrapage.

Les repères de marché

Les grilles publiées par des prestataires parisiens en 2026 situent un contrat de maintenance WordPress pour un site d'entreprise entre 80 et 450 € HT par mois, en trois paliers d'environ 80 à 150 €, 180 à 280 € et 300 à 450 € HT, selon la fréquence des mises à jour, le délai d'intervention garanti et les heures d'évolution incluses. D'autres grilles régionales publiées la même année montent jusqu'à 900 € HT par mois pour les niveaux de service les plus exigeants. Ces chiffres sont indicatifs et proviennent d'offres commerciales : ils varient fortement selon ce que le contrat couvre réellement.

Ce qu'il faut vérifier dans un contrat

• Les mises à jour majeures sont-elles incluses, ou seulement les mineures ?
• Une préproduction est-elle utilisée, et qui la fournit ?
• Un plan de tests écrit est-il appliqué après chaque intervention ?
• Quel est le délai d'application des correctifs de sécurité ?
• La montée de version de PHP est-elle prise en charge ou facturée à part ?
• Qui décide du report d'une mise à jour majeure, et comment est-il tracé ?

Le coût de l'inaction

Un site resté plusieurs années sans mise à jour majeure cumule les écarts : extensions abandonnées à remplacer, thème incompatible, version de PHP à faire monter de plusieurs crans. Le rattrapage se chiffre alors en jours de travail plutôt qu'en heures, et il intervient souvent dans l'urgence, après une faille ou une montée de version imposée par l'hébergeur. C'est l'argument le plus solide en faveur d'une maintenance continue : elle étale l'effort et supprime l'urgence.

Aborder décembre 2026 avec une méthode plutôt qu'avec de l'espoir

Les mises à jour majeures de fin 2026 ne sont pas une menace en soi : elles deviennent un risque uniquement lorsqu'elles sont appliquées sans inventaire, sans préproduction, sans plan de tests et sans retour arrière. Avec cette méthode, un site vitrine bien tenu les traverse sans que ses visiteurs s'en aperçoivent.

Concrètement, les quatre prochaines semaines peuvent s'organiser ainsi : inventaire et vérification des prérequis dès maintenant, préparation de la préproduction avant le 17 novembre, tests sur les versions candidates entre le 17 novembre et le 7 décembre, mise en production planifiée après la sortie et la publication des extensions compatibles, et traitement de PHP 8.2 avant le 31 décembre. Pour les sites Drupal 10, l'échéance du 9 décembre impose d'avoir déjà lancé la migration.

Depuis 2005, Pulsar Agency assure la maintenance de sites existants sous WordPress, Joomla et Drupal pour des PME et des grands comptes en Île-de-France et dans les Hauts-de-France. Nous prenons en charge l'inventaire, la préproduction, les tests et la mise en production, avec un journal d'intervention à chaque passage. Si vous souhaitez que les mises à jour de votre site ne soient plus un sujet d'inquiétude, découvrez notre contrat de maintenance web Pulsar Agency et parlons de votre site.

Questions fréquentes sur les mises à jour majeures de CMS