Mise à jour majeure et mineure
Une mise à jour majeure change les deux premiers chiffres de la version de WordPress et apporte des fonctionnalités, une mise à jour mineure ne change que le troisième et se limite aux corrections.
Définition
Une mise à jour majeure change les deux premiers chiffres de la version de WordPress, une mise à jour mineure ne change que le troisième. Ce détail de numérotation décide de tout le reste : ce qui s’installe tout seul, ce qui demande une décision, et ce qui peut casser une page en production.
Qu’est-ce qui sépare une majeure d’une mineure ?
La position du chiffre qui change, et ce que le projet s’autorise à modifier derrière.
WordPress ne numérote pas ses versions comme la plupart des logiciels. Une version majeure est désignée par les deux premières séquences : 6.7 et 6.8 sont deux majeures successives, et 4.0 n’a rien de plus solennel que 3.9. Une version mineure est portée par la troisième séquence, comme 6.8.1. Le projet vise quatre à cinq mois entre deux majeures, et publie les mineures au fil des besoins.
La différence de contenu suit cette règle. Une majeure ajoute des fonctionnalités et des interfaces destinées aux développeurs. Une mineure se limite aux corrections de bogues et aux améliorations qui n’introduisent aucun fichier nouveau. C’est aussi par les mineures que passent les correctifs de sécurité.
| Mise à jour majeure | Mise à jour mineure | |
|---|---|---|
| Numéro concerné | Les deux premiers, 6.7 vers 6.8 | Le troisième, 6.8 vers 6.8.1 |
| Contenu | Fonctionnalités et interfaces développeur | Corrections et sécurité |
| Rythme | Quatre à cinq mois visés | Selon les besoins |
| Comportement par défaut | Dépend de la date d’installation du site | Automatique dans la quasi-totalité des cas |
| Ce qu’il faut vérifier avant | Thème et extensions, sur une copie | Que la sauvegarde de la veille existe |
Que WordPress installe-t-il sans vous le demander ?
Plus de choses qu’on ne le croit, et pas la même chose selon l’âge du site.
Les mises à jour automatiques en arrière-plan existent depuis WordPress 3.7. Elles couvrent quatre familles : le cœur, les extensions, les thèmes et les fichiers de traduction. Les traductions partent seules par défaut, les extensions et les thèmes seulement si quelqu’un l’a demandé, au cas par cas. Le détail de ce mécanisme, ce qu’il couvre famille par famille et les trois endroits où il se règle, est traité par la fiche mises à jour automatiques. Décider quoi automatiser et quoi tester à la main est l’un des arbitrages d’un suivi de maintenance WordPress.
Pour le cœur, le comportement dépend d’une date. Avant WordPress 5.6, tout site n’installait automatiquement que les versions mineures et les traductions. Depuis la 5.6, une nouvelle installation reçoit par défaut les mineures et les majeures, sauf si WordPress détecte un dépôt de gestion de version. Les installations antérieures, elles, conservent l’ancien comportement tant qu’un administrateur ne l’a pas changé.
Le raccourci à éviter. Supposer que deux sites administrés de la même façon se mettent à jour de la même façon. Deux sites du même client, l’un installé en 2019 et l’autre en 2024, n’ont pas le même comportement par défaut sur les versions majeures. La seule réponse fiable est de regarder la configuration de chacun.
Dans quel ordre procéder sur un site en production ?
L’ordre compte plus que la rapidité, parce qu’il détermine ce que l’on saura en cas d’échec.
Vérifier la sauvegarde, pas seulement son existence
Une sauvegarde n’a de valeur que si elle a déjà été remontée quelque part. La question à se poser n’est pas « en ai-je une », mais « sait-on la restaurer, et en combien de temps ». C’est la seule chose qui rend la suite réversible.
Passer par une copie pour les majeures
Une version majeure se teste ailleurs que sur le site vu par les visiteurs. Un environnement de préproduction sert exactement à cela : constater ce qui casse sans que personne ne le voie.
Mettre à jour une chose à la fois
Tout mettre à jour en une fois fait gagner cinq minutes et coûte une heure quand une page casse : plus rien ne dit laquelle des quinze extensions en est la cause. Une par une, le coupable se nomme tout seul.
Regarder le site après, pas seulement le tableau de bord
Une mise à jour peut se déclarer réussie et laisser un formulaire muet ou une mise en page cassée. Le contrôle porte sur les pages qui comptent, vues comme un visiteur, en navigation privée.
Cet ordre est aussi ce qu’un contrat de maintenance décrit quand il est écrit sérieusement : il ne promet pas l’absence de panne, il décrit la procédure qui rend la panne réversible.
Pourquoi une mise à jour casse un site
Rarement à cause du cœur, presque toujours à cause de ce qui s’y greffe.
Le projet WordPress s’impose une contrainte forte : ne pas rompre la compatibilité ascendante, même lors d’une version majeure. C’est l’une de ses règles fondatrices, et elle explique pourquoi la mise à jour du cœur seule provoque peu d’accidents.
Les accidents viennent d’ailleurs. Une extension abandonnée depuis trois ans continue de fonctionner jusqu’au jour où elle s’appuie sur un comportement qui a changé. Deux extensions qui modifient la même chose finissent par se contredire. Et le thème, quand il a été modifié directement au lieu de passer par un thème enfant, perd ses personnalisations à la première mise à jour.
Il existe enfin un cas où la mise à jour n’est pas la cause mais le révélateur : le changement de version de PHP. Une extension ancienne peut s’arrêter net sur un serveur récent, et l’écran obtenu est alors le même que celui d’une mise à jour ratée. La compatibilité PHP se vérifie donc avant, pas après l’écran blanc.
Un site laissé de côté ne se met pas à jour, il s’examine d’abord
Parce que la mise à jour efface une partie de ce qui permettait de comprendre son état.
Sur un site suivi, la mise à jour est une opération de routine. Sur un site resté sans intervention pendant des mois, l’ordre habituel devient risqué, pour une raison que la documentation de WordPress décrit sans la commenter. La procédure officielle de mise à jour manuelle demande de supprimer les anciens fichiers du cœur, puis énumère ce qu’il ne faut surtout pas toucher : le fichier de configuration, le dossier wp-content et le fichier .htaccess.
Ce périmètre préservé est exactement celui où se logent le thème, les extensions et tout ce qui a pu être déposé sur le site. Une mise à jour du cœur remplace le cœur et laisse intact ce qui vit à côté. Elle se déclare réussie, l’écran d’administration affiche une version récente, et un fichier ajouté par un tiers reste en place. Le contrôle de version du cœur est utile, mais il ne dit rien de wp-content.
Le second effet est plus discret. La documentation consacrée aux sites piratés place la documentation en tout premier geste : noter ce que l’on constate, à quelle heure, et ce qui a été fait récemment. Une mise à jour passée avant cet inventaire réécrit des fichiers et leurs dates de modification, qui sont souvent le seul élément permettant de situer le moment où quelque chose a changé.
L’ordre correct est donc inversé sur un site abandonné : établir son état, puis mettre à jour. Si rien n’apparaît, on n’a perdu qu’un peu de temps. Si quelque chose apparaît, on a évité de détruire ce qui permettait de le dater, et l’on est dans le cas d’une alerte de site compromis, pas dans celui d’une mise à jour en retard.
Questions fréquentes
Faut-il désactiver les mises à jour automatiques ?
La documentation de WordPress le déconseille explicitement pour les versions mineures et les traductions : ce sont elles qui portent les correctifs de sécurité, et les laisser actives est présenté comme l’un des meilleurs moyens de garder un site à jour. Ce qui se discute, c’est l’automatisation des versions majeures et celle des extensions, pas celle des mineures.
Comment savoir si mon site installe les majeures tout seul ?
Cela se lit dans la configuration du site, par les constantes définies dans le fichier de configuration ou par un filtre ajouté par une extension. Aucune règle générale ne permet de le deviner depuis l’extérieur, et la date d’installation ne suffit pas non plus, puisqu’un administrateur a pu changer le réglage entre-temps.
Peut-on revenir à la version précédente après une mise à jour ?
Oui, mais le chemin dépend de ce qui a été mis à jour. Revenir sur une extension est simple si l’on dispose de la version antérieure. Revenir sur le cœur ou sur la base de données demande une restauration complète, et donc une sauvegarde prise juste avant l’opération. C’est le retour arrière, et il se prépare avant, jamais pendant.
Une mise à jour reportée pendant deux ans se rattrape-t-elle en une fois ?
Techniquement, WordPress sait passer directement à la dernière version. Le problème n’est pas le cœur, ce sont les extensions et le thème, qui ont accumulé deux ans d’écart chacun de leur côté. Ce rattrapage se traite comme un chantier, sur une copie, et pas comme une opération de routine.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.