Le bouton est là. WordPress 7.1 est sorti le 19 août 2026 et le tableau de bord propose désormais la nouvelle version. Sur un site vitrine qui apporte des demandes de devis, la bonne question n'est pourtant pas « la version est-elle officielle ? ». Elle est : à quel moment disposons-nous d'assez de preuves pour la mettre en production ?
Imaginez trois enveloppes posées devant vous :
- verte : mettre à jour dans une fenêtre contrôlée ;
- orange : observer quelques jours et tester un point précis ;
- rouge : corriger ou remplacer une dépendance avant de toucher au site public.
Le numéro de version ne choisit pas l'enveloppe. Votre sauvegarde, votre thème, vos extensions et vos parcours commerciaux la choisissent.
Ce qui a réellement changé depuis la Release Candidate
Avant le 19 août, WordPress 7.1 était un matériau de recette. La version finale peut maintenant être envisagée pour la production, mais sa sortie ne valide pas automatiquement les milliers de combinaisons possibles entre hébergement, PHP, thème, constructeur et extensions.
Le Field Guide officiel signale plusieurs zones qui justifient un contrôle ciblé : l'éditeur d'articles fonctionne désormais systématiquement dans une iframe, les styles de blocs gagnent de nouvelles possibilités responsives, la navigation entre certains écrans d'administration évolue et jQuery UI passe en version 1.14.2. Ces changements seront invisibles sur beaucoup de sites. Sur un site doté de blocs maison, d'un vieux thème ou d'une interface d'administration personnalisée, ils peuvent révéler une incompatibilité.
À l'inverse, il ne faut pas tester des promesses qui ne font pas partie de la version finale. La collaboration en temps réel et React 19 ont été différés. Un plan de recette utile part de ce qui a été livré, puis le rapproche de ce que l'entreprise utilise réellement.
Notre précédent article proposait une répétition générale de WordPress 7.1 RC1 en 90 minutes. Après la sortie finale, il ne s'agit plus de recommencer le même test par principe. Il faut transformer ses résultats en décision de production.
Enveloppe 1 — La sauvegarde donne-t-elle un vrai retour arrière ?
Une mention « sauvegarde terminée » n'est pas encore un plan de reprise. Avant la mise à jour, réunissez quatre réponses dans le même ticket : où se trouvent les fichiers et la base de données sauvegardés, à quelle heure exacte la copie a été créée, qui peut lancer la restauration et combien de temps le retour à l'état précédent devrait prendre.
La meilleure preuve reste une restauration récente sur un environnement séparé. Si personne n'a jamais restauré cette sauvegarde, classez-la comme hypothèse, pas comme garantie.
Pour un site qui reçoit des formulaires ou des commandes, fixez aussi la frontière des données. Une restauration de base peut effacer les demandes reçues entre la sauvegarde et le retour arrière. Selon l'activité, il faudra exporter les nouvelles entrées, choisir une fenêtre creuse ou prévoir une procédure de réconciliation.
Enveloppe verte si la sauvegarde est datée, accessible et restaurable par une personne identifiée. Orange si elle existe mais n'a pas été éprouvée. Rouge si sa localisation ou sa couverture est incertaine.
Enveloppe 2 — Les dépendances critiques parlent-elles de 7.1 ?
Ne cherchez pas à inventorier chaque extension avec le même niveau d'urgence. Commencez par celles qui peuvent bloquer une action commerciale ou administrative : constructeur de pages et thème, formulaire, anti-spam, consentement, SEO, cache, sécurité, réservation, paiement, livraison, espace client, blocs et développements réalisés sur mesure.
Pour chacune, relevez la version installée, la dernière version disponible, la date de sa dernière mise à jour et l'éventuelle déclaration de compatibilité WordPress 7.1. Une case « compatible » dans un catalogue est un indice. Les notes de version de l'éditeur et le test sur votre copie sont de meilleures preuves.
Une extension abandonnée depuis longtemps ne devient pas dangereuse uniquement le jour de WordPress 7.1. La nouvelle version rend simplement la dette plus visible. Dans ce cas, le bon projet peut être son remplacement, pas une attente indéfinie sur une ancienne version de WordPress.
Enveloppe 3 — L'équipe peut-elle encore modifier une page ?
La façade peut être parfaite alors que l'éditeur est cassé. WordPress 7.1 impose l'éditeur d'articles dans une iframe, ce qui isole mieux le contenu des styles de l'administration. Un bloc ancien ou personnalisé peut cependant dépendre d'un comportement précédent.
Sur la copie du site, demandez à une personne qui publie réellement de réaliser une modification ordinaire : dupliquer une page représentative, remplacer une image et son texte alternatif, modifier un titre, un bouton et un lien, vérifier l'aperçu mobile, enregistrer, prévisualiser puis revenir à la version précédente.
Le résultat attendu n'est pas seulement « aucun message d'erreur ». Comparez l'éditeur et la page publique : largeur des blocs, polices, couleurs, marges, état des boutons, galerie et contenu masqué selon la taille d'écran.
Si un contournement est nécessaire, documentez-le. Un site peut techniquement afficher les anciennes pages tout en devenant impossible à maintenir la veille d'une campagne.
Enveloppe 4 — Le chemin vers le contact traverse-t-il encore le site ?
Prenez une demande réaliste, depuis Google ou une page service jusqu'à la boîte de réception. Ne commencez pas dans l'administration.
- Ouvrez le site dans une fenêtre privée sur téléphone.
- Accédez à une page commerciale par son URL, puis naviguez vers le contact.
- Remplissez le formulaire avec une erreur volontaire et vérifiez que le message aide à la corriger.
- Envoyez ensuite une demande valide.
- Contrôlez la confirmation visible, la réception côté entreprise et, si elle existe, la copie envoyée au prospect.
- Vérifiez que la demande apparaît dans le CRM ou l'outil métier lorsque cette connexion existe.
Conservez une capture et l'heure du test. « Le formulaire s'est envoyé » ne prouve pas que le message a atteint la bonne personne ni que le suivi commercial peut commencer.
Pour les sites multilingues ou multisites, faites au moins un parcours par configuration réellement différente. Pour une boutique WooCommerce, ajoutez une commande témoin complète. WooCommerce 11.0.1 mentionne des améliorations de compatibilité avec WordPress 7.1, mais votre paiement, votre thème et vos modules de livraison restent une combinaison locale à vérifier.
Enveloppe 5 — La fenêtre de mise en production est-elle pilotable ?
Une mise à jour contrôlée possède un début, un propriétaire et une condition de sortie. Écrivez ces éléments avant d'ouvrir le tableau de bord : heure de début, personne qui applique la mise à jour, personne qui valide le parcours métier, durée maximale avant décision de retour arrière, pages et journaux à surveiller pendant l'heure suivante et canal utilisé si un incident est détecté.
La surveillance ne doit pas se limiter à la page d'accueil. Contrôlez une page service, le formulaire, une page utilisant des blocs personnalisés, les erreurs serveur et les tâches planifiées. Videz les caches de façon maîtrisée ; sinon, une ancienne page peut masquer un problème ou une purge trop large peut créer un pic de charge.
Sur un site d'entreprise, le meilleur moment n'est pas nécessairement la nuit. Il vaut mieux une fenêtre où le prestataire et un responsable métier sont disponibles qu'une intervention solitaire à 2 heures du matin.
La décision tient sur une fiche, pas dans une intuition
Vert — mise à jour contrôlée
La restauration est crédible, les dépendances critiques sont maintenues, la copie passe les parcours éditorial et commercial, et deux personnes peuvent suivre la fenêtre. Planifiez la mise à jour, puis conservez le dossier de preuves.
Orange — attente courte et datée
Un point reste incertain : par exemple la compatibilité du constructeur, un plugin de formulaire tout juste mis à jour ou une anomalie non bloquante. N'écrivez pas « attendre ». Écrivez quoi observer, qui vérifie et à quelle date la décision sera reprise.
Rouge — chantier préalable
La sauvegarde n'est pas restaurable, une extension critique est abandonnée, la copie casse l'édition ou une demande de contact n'arrive plus. La mise à jour WordPress n'est alors que le révélateur. Chiffrez la correction, le remplacement ou la reprise technique avant de modifier la production.
Cette classification évite deux erreurs symétriques : cliquer trop vite parce que la version est officielle, ou conserver trop longtemps une version ancienne parce qu'aucun responsable n'a posé de date de décision.
Ce que 1Design peut vérifier sans transformer l'audit en chantier ouvert
Un contrôle WordPress 7.1 peut rester borné : inventaire des dépendances critiques, sauvegarde et restauration, copie de recette, test d'édition, parcours de contact ou de commande, puis fiche vert-orange-rouge.
Si votre hébergement, votre thème ou vos extensions rendent cette réponse floue, 1Design peut cadrer une fenêtre de maintenance via son service d'hébergement et gestion technique, ou évaluer si une refonte de site internet à Lyon est plus rationnelle que l'empilement de correctifs. Pour un diagnostic ciblé, contactez 1Design avec la version actuelle, l'URL du site et la fonction que vous ne pouvez pas vous permettre de perdre.
Le livrable utile n'est pas « WordPress mis à jour ». C'est un site dont l'équipe peut encore publier et dont les visiteurs peuvent encore devenir des contacts.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?