Vous avez un site vitrine, une boutique ou un formulaire de devis sous WordPress, et vous voyez apparaître régulièrement une pastille rouge dans votre tableau de bord. Cette fois, il s’agit de WordPress 7.1.1, une mise à jour de maintenance dont la sortie est prévue le jeudi 17 septembre 2026. La question que vous vous posez est simple : est-ce que je clique, et qu’est-ce que je risque si je clique.
À lire aussi : WordPress 7.2 : la bêta et la date de sortie sont déjà calées
Je vais répondre précisément : ce qu’est une version de maintenance, ce que change 7.1.1 par rapport à 7.1, le calendrier réel de cette sortie, comment la tester sans toucher à votre site en ligne, et quoi vérifier une fois la mise à jour passée. Aucune spéculation : uniquement ce qui est publié par l’équipe qui prépare cette version.
À retenir
- La sortie de WordPress 7.1.1 est prévue le jeudi 17 septembre 2026.
- Une version de maintenance corrige des bugs, elle n’ajoute pas de fonctionnalité.
- La Release Candidate 1 est testable depuis le 10 septembre 2026.
- Testez d’abord sur une copie de préproduction, jamais directement en ligne.
- Faites une sauvegarde complète avant de lancer la mise à jour.
- Ce type de sortie peut être reporté si les tests révèlent un problème.
Ce qu’est une mise à jour de maintenance, et ce qu’elle n’est pas
WordPress numérote ses versions en trois chiffres. Le passage de 7.0 à 7.1 est une version majeure : elle apporte de nouvelles fonctionnalités, parfois des changements d’interface et des modifications techniques qui peuvent affecter les extensions et les thèmes. Le troisième chiffre, celui qui fait passer de 7.1 à 7.1.1, désigne une version de maintenance : elle corrige des bugs identifiés après la sortie de la majeure, sans rien ajouter.
Concrètement, cela veut dire qu’après l’installation de 7.1.1, votre éditeur ressemblera à ce que vous connaissez déjà si vous êtes en 7.1. Vous ne devriez pas avoir à réapprendre quoi que ce soit. La précédente mise à jour de maintenance de cette branche, WordPress 7.0.1, publiée en juillet 2026, contenait 31 corrections de bugs. C’est l’ordre de grandeur habituel de ce genre de sortie : beaucoup de petits ajustements, dont la plupart concernent des cas que vous ne rencontrerez jamais.
C’est aussi pour cette raison que ces versions sont, par défaut, installées automatiquement par WordPress sur la majorité des sites. Les mises à jour dites mineures se déclenchent seules, sauf si votre hébergeur ou votre prestataire a désactivé ce comportement. Autrement dit, la vraie question n’est pas « est-ce que je mets à jour », mais « est-ce que mon site est prêt à recevoir la mise à jour ».
Si vous n’avez pas encore installé WordPress 7.1, c’est cette étape qui mérite votre attention, pas la 7.1.1 : les risques de compatibilité viennent des versions majeures.
Le calendrier exact de WordPress 7.1.1
Deux dates comptent pour vous. La première : le 10 septembre 2026, la Release Candidate 1 de WordPress 7.1.1 a été publiée. Une Release Candidate, ou RC, est une version considérée comme terminée par ses développeurs, mise à disposition pour être testée en conditions réelles avant la diffusion générale. Si un problème sérieux est trouvé pendant cette phase, il est corrigé et la sortie est décalée.
La seconde : la sortie finale est annoncée pour le jeudi 17 septembre 2026. Cette date est explicitement conditionnelle, et l’équipe le précise : elle peut être repoussée si les tests de la RC1 font remonter des anomalies. Vous trouverez l’annonce d’origine sur le blog de développement du cœur de WordPress, dans l’annonce officielle de la Release Candidate 1 de WordPress 7.1.1.
Une semaine entre la RC et la sortie, c’est court. Pour vous, cela a une conséquence pratique : si vous voulez tester avant que la mise à jour n’arrive sur votre site, la fenêtre est celle de ces quelques jours. Passé le 17 septembre, vous testerez après coup, ce qui n’est pas la même chose.
Tester la Release Candidate sans toucher à votre site en ligne
Une RC n’a rien à faire sur un site qui reçoit des visiteurs et des commandes. Elle se teste sur une copie, ce que l’on appelle un environnement de préproduction, ou staging : un duplicata de votre site, avec les mêmes extensions et le même thème, accessible à une adresse séparée et invisible pour vos clients. La plupart des hébergeurs proposent cette fonction en un clic dans leur interface ; si ce n’est pas le cas du vôtre, une extension de clonage fait le travail.
Sur cette copie, la démarche tient en quatre gestes :
- Installez la Release Candidate via l’extension officielle de test des versions bêta, ou manuellement si vous savez le faire.
- Parcourez les parcours qui vous font gagner de l’argent : formulaire de contact, prise de rendez-vous, tunnel de commande, connexion à l’espace client.
- Ouvrez deux ou trois pages dans l’éditeur et enregistrez une modification pour vérifier que rien ne bloque.
- Regardez le journal d’erreurs de votre hébergement, qui liste les avertissements techniques déclenchés par le site.
Si tout passe sur la copie, la mise à jour du site réel ne vous réserve pas de surprise. Si quelque chose casse, vous savez lequel de vos plugins est en cause avant que vos clients ne le découvrent. La même méthode s’applique aux versions majeures : j’en détaille les étapes dans mon article sur la vérification de la compatibilité des extensions avant de migrer vers WordPress 7.1.
À lire aussi : Faille plugin migration WordPress : sauvegarde piégée, 3 millions de sites menacés
La checklist avant de lancer la mise à jour
Que vous cliquiez vous-même ou que WordPress installe la version tout seul, ces points se préparent en amont. Ils prennent une vingtaine de minutes et évitent la quasi-totalité des mauvaises soirées.
- Faites une sauvegarde complète, fichiers et base de données, et vérifiez qu’elle est bien téléchargée ailleurs que sur le serveur du site.
- Mettez à jour vos extensions et votre thème avant le cœur de WordPress, car une extension ancienne est la première cause de conflit.
- Notez la version actuelle de votre site et celle de PHP, le langage sur lequel tourne WordPress, pour pouvoir décrire précisément un problème à votre hébergeur.
- Évitez de mettre à jour un vendredi soir ou la veille d’une opération commerciale.
- Vérifiez que vous avez un accès FTP ou un gestionnaire de fichiers chez votre hébergeur, au cas où l’administration deviendrait inaccessible.
Les thèmes méritent une attention particulière, parce que ce sont eux que l’on oublie le plus souvent dans la liste des mises à jour, et qu’un thème abandonné depuis deux ans pose davantage de problèmes qu’une version de WordPress. J’ai détaillé ce point dans mon article sur la mise à jour des thèmes WordPress que tout le monde oublie.
Une sauvegarde qui n’a jamais été restaurée n’est pas une sauvegarde : testez la restauration une fois sur une copie, avant d’en avoir besoin.
Après le 17 septembre : les vérifications qui comptent
La mise à jour est passée, le bandeau a disparu, et c’est le moment où l’on referme l’onglet un peu trop vite. Cinq minutes de contrôle suffisent.
Vérifiez d’abord votre page d’accueil et deux pages internes en navigation privée, pour ne pas voir une version mise en cache par votre navigateur. Videz ensuite le cache de votre site et celui de votre CDN si vous en utilisez un : le cache stocke une copie figée de vos pages, et il peut afficher pendant plusieurs heures un contenu antérieur à la mise à jour. Envoyez un message test depuis votre formulaire de contact et vérifiez qu’il arrive bien dans votre boîte. Passez une commande de test si vous vendez en ligne.
Regardez enfin la liste de vos extensions : une extension désactivée automatiquement pendant la mise à jour est un signal à traiter tout de suite. Si vous cherchez à automatiser une partie de cette surveillance, j’ai comparé plusieurs outils dans mon panorama des plugins IA pour la maintenance et la sécurité WordPress en 2026.
À lire aussi : WordPress lance un programme de sécurité proactif : ce que ça change pour votre site
Ce que je ferais cette semaine
D’ici le 17 septembre, trois actions couvrent le sujet. Lancez une sauvegarde complète aujourd’hui et vérifiez qu’elle est récupérable. Mettez à jour vos extensions et votre thème avant l’arrivée de 7.1.1, pour ne pas cumuler deux changements le même jour. Puis, le jour venu, accordez cinq minutes à la vérification de vos pages et de votre formulaire.
Si ces gestes ne rentrent pas dans votre semaine, ou si votre site fait vivre votre activité et que vous ne voulez pas gérer ces cycles vous-même, c’est exactement ce que couvre un contrat de maintenance WordPress : sauvegarde, test sur copie, mise à jour, contrôle après coup.
FAQ
Mon site va-t-il installer WordPress 7.1.1 tout seul ?
Très probablement oui. WordPress installe par défaut les mises à jour mineures, celles qui changent le troisième chiffre de la version, sans intervention de votre part. Certains hébergeurs et certains prestataires désactivent ce réglage pour garder la main sur le calendrier. Si vous n’avez pas le souvenir d’un tel choix, considérez que la mise à jour arrivera seule.
Faut-il installer la Release Candidate sur mon site ?
Non. La Release Candidate publiée le 10 septembre 2026 est destinée aux tests, pas à la production. Installez-la uniquement sur une copie de préproduction si vous voulez repérer un conflit avant la sortie finale. Sur un site qui reçoit des visiteurs, attendez la version définitive prévue le 17 septembre.
Que se passe-t-il si la sortie du 17 septembre est reportée ?
Rien de problématique pour vous. La date annoncée est conditionnelle : si les tests de la Release Candidate révèlent une anomalie, l’équipe corrige et repousse la diffusion. Votre site reste en 7.1, qui fonctionne. Vous verrez simplement la notification apparaître quelques jours plus tard dans votre tableau de bord.
Est-ce que je risque de perdre mes contenus ?
Une version de maintenance ne touche pas à vos articles, pages, images ni réglages : elle remplace des fichiers du cœur de WordPress. Le risque réel est ailleurs, dans un conflit avec une extension ou un thème mal entretenu, qui peut casser un affichage ou une fonction. La sauvegarde préalable sert précisément à revenir en arrière dans ce cas.
Combien de temps prend l’opération sur un site vitrine ?
La mise à jour elle-même dure une à deux minutes, avec une courte page de maintenance pendant l’opération. La préparation pèse davantage : comptez une vingtaine de minutes pour la sauvegarde et la mise à jour des extensions, puis cinq minutes de contrôle après coup. Sur une boutique avec de nombreuses extensions, prévoyez une heure et un test sur copie.
