Le 19 août est encore loin pour un visiteur. Pour la personne qui maintient un site WordPress utilisé chaque jour pour recevoir des demandes, vendre ou recruter, c’est demain matin.
WordPress 7.1 est entré dans sa phase bêta en juillet et sa sortie générale est planifiée pour le 19 août 2026. Cela ne justifie ni d’installer une bêta sur le site public, ni d’attendre que le bouton « Mettre à jour » apparaisse pour découvrir ce dont le site dépend.
Le travail utile de juillet n’est pas la mise à jour. C’est la préparation d’une décision réversible.
Commencer par le métier, pas par la version
Deux sites sous la même version de WordPress ne courent pas le même risque.
Un site vitrine de cinq pages, sans extension métier et avec un formulaire simple, peut être contrôlé rapidement. Un autre site apparemment similaire peut dépendre d’un constructeur de pages, de champs personnalisés, d’un outil multilingue, d’une synchronisation CRM, d’un consentement analytique et de plusieurs formulaires conditionnels. Une petite boutique ajoute le paiement, les taxes, la livraison, les emails et les tâches planifiées.
Avant d’ouvrir la liste des extensions, écrivez les parcours que le site doit absolument préserver :
- trouver une offre depuis Google et atteindre la bonne page ;
- envoyer un formulaire et recevoir la notification ;
- réserver, demander un devis ou payer ;
- se connecter à un espace client ;
- publier ou modifier une page sans casser sa mise en forme ;
- transmettre une donnée au CRM, à l’outil d’emailing ou au logiciel métier ;
- rester mesurable dans le respect du consentement.
Cette liste devient le contrat de test de la mise à jour. Elle évite de conclure « le site s’affiche » alors que les demandes ne sont plus envoyées.
Au 24 juillet, ce qui est certain — et ce qui ne l’est pas encore
La page officielle du cycle WordPress 7.1 fixe actuellement la sortie générale au 19 août 2026. Après un ajustement lié à la sortie imprévue de WordPress 7.0.2, le calendrier comprend une bêta supplémentaire : Beta 3 le 22 juillet, Beta 4 le 29 juillet, RC1 le 5 août et RC2 le 12 août.
Pendant la phase bêta, les contributeurs testent et corrigent les régressions. Le Field Guide, qui rassemble les notes utiles aux développeurs d’extensions et de thèmes, doit être publié au début de la phase Release Candidate.
La feuille de route mentionne plusieurs chantiers techniques, notamment autour de l’éditeur, de l’API d’icônes, de React 19 et de l’isolation de l’éditeur pour les thèmes basés sur des blocs. Mais une PME ne devrait pas bâtir son calendrier de production à partir d’une promesse de feuille de route. Les décisions de compatibilité doivent s’appuyer sur les notes stabilisées, les annonces des éditeurs réellement utilisés et des tests sur une copie du site.
Autrement dit : préparez l’inventaire maintenant ; arrêtez le verdict après RC1.
Construire une fiche de dépendances qui tient sur une page
Une capture de l’écran « Extensions » ne suffit pas. Pour chaque composant important, consignez son effet réel.
| Composant | Effet métier | Propriétaire / éditeur | Preuve attendue avant 7.1 |
|---|---|---|---|
| Thème ou constructeur | Mise en page, navigation, modèles | Agence ou éditeur | Version compatible, pages types comparées |
| Formulaires | Leads, recrutement, SAV | Marketing / commercial | Envoi, réception, antispam et consentement testés |
| E-commerce ou réservation | Chiffre d’affaires | E-commerce / opérations | Commande ou réservation de bout en bout |
| SEO | Titres, canonicals, sitemap, données structurées | Marketing / SEO | Pages types et sitemap contrôlés |
| Cache / performance | Vitesse et disponibilité | Hébergeur / technique | Purge, pages connectées et non connectées testées |
| Connecteur métier | CRM, ERP, emailing, agenda | Responsable métier | Donnée reçue, erreur visible, reprise possible |
Ajoutez la version actuelle, la date de dernière mise à jour et le lien vers le support de l’éditeur. Marquez aussi les extensions qui ne sont plus maintenues ou dont personne ne connaît la fonction : ce sont souvent elles qui empêchent une mise à jour sereine.
Ne confondez pas « aucune alerte dans l’administration » avec « compatible ». Une extension peut fonctionner sur WordPress 7.1 sans que son éditeur ait encore mis à jour son indication de compatibilité ; l’inverse est aussi possible pour un scénario particulier. Le test métier tranche.
Prouver que la sauvegarde peut réellement revenir en arrière
La documentation WordPress recommande une sauvegarde avant la mise à jour. Pour un site d’entreprise, le mot « sauvegarde » doit être plus précis :
- la base de données est-elle incluse ?
- les fichiers, médias, extensions, thèmes et configurations le sont-ils ?
- où la copie est-elle stockée ?
- combien de temps est-elle conservée ?
- qui peut la restaurer ?
- combien de temps prend une restauration ?
Un email quotidien indiquant « backup successful » n’est pas une procédure de retour arrière. Avant une mise à jour majeure, vérifiez au minimum qu’une sauvegarde récente est lisible, que les accès sont disponibles et que la personne chargée de restaurer connaît la marche à suivre.
Pour une boutique ou un site recevant beaucoup de formulaires, définissez aussi le point de coupure. Restaurer une base vieille de trois heures peut faire disparaître des commandes ou des demandes. La fenêtre d’intervention, le mode maintenance éventuel et le traitement des données arrivées pendant l’opération doivent être décidés avant le clic.
Tester sur une copie fidèle, sans polluer les clients ni les statistiques
Un environnement de test utile ressemble à la production : même version de PHP, mêmes extensions, même thème, mêmes réglages importants et, autant que possible, même configuration de cache.
Il doit cependant être isolé :
- accès protégé et indexation bloquée ;
- aucun vrai email envoyé à un client ;
- paiements en mode test ;
- webhooks, CRM et automatisations neutralisés ou dirigés vers des environnements de test ;
- données personnelles réduites ou protégées selon le besoin ;
- analytics exclus pour ne pas fausser les rapports.
La bêta de WordPress 7.1 peut servir à un prestataire ou à une équipe technique pour détecter tôt une incompatibilité sur cette copie. Elle n’a rien à faire en production. Pour beaucoup de PME, le moment le plus efficace sera après RC1 et la publication du Field Guide : les changements seront mieux documentés, les éditeurs auront davantage d’éléments et il restera du temps avant la sortie finale.
Le contrôle en trois passages
Plutôt qu’une longue checklist indifférenciée, faites trois passages courts.
Passage 1 : le visiteur
Ouvrez le site sur mobile et ordinateur, en navigation privée. Contrôlez la page d’accueil, une page de service, un article, une page issue de Google et une page d’erreur. Testez menu, recherche, liens d’ancrage, bannière de consentement, images, vidéos et principaux boutons.
Regardez surtout les modèles, pas toutes les pages. Si les pages services partagent le même modèle, deux échantillons bien choisis valent mieux qu’un survol de cinquante URL.
Passage 2 : la conversion
Envoyez chaque type de formulaire avec une adresse contrôlée. Vérifiez le message affiché, l’email reçu, l’enregistrement en administration et la transmission au CRM.
Pour une boutique, testez au moins un produit simple et un cas complexe réellement vendu : variante, code promotionnel, frais de livraison, taxe, moyen de paiement, confirmation, stock et remboursement si le périmètre le permet. Pour une réservation, testez créneau, notification, annulation et synchronisation de calendrier.
Passage 3 : l’exploitation
Connectez-vous avec les rôles réellement utilisés. Publiez un brouillon, modifiez une page, téléversez une image et contrôlez les blocs ou champs personnalisés. Vérifiez les tâches planifiées, les journaux d’erreurs, la santé du site, la purge du cache et les sauvegardes.
Enfin, comparez quelques signaux SEO : titre, meta description, canonical, robots, sitemap XML et données structurées sur les principaux modèles. Une mise à jour qui conserve le visuel mais modifie silencieusement ces éléments mérite une correction avant production.
Automatique ne veut pas dire sans surveillance
WordPress permet d’activer les mises à jour automatiques extension par extension et thème par thème. Sa documentation rappelle qu’elles s’appuient notamment sur les tâches WordPress Cron et recommande des sauvegardes permettant un retour arrière.
Pour une extension peu risquée et bien maintenue, l’automatisation peut réduire le retard de sécurité. Pour un composant qui contrôle le paiement, le formulaire principal, la traduction, le cache ou la mise en page, une politique plus encadrée peut être préférable.
Le bon réglage dépend du rôle du composant, pas d’une règle générale « tout automatique » ou « rien automatique ». Documentez :
- ce qui se met à jour automatiquement ;
- qui reçoit et lit les notifications de succès ou d’échec ;
- quels contrôles suivent une mise à jour ;
- quand une intervention humaine est obligatoire.
Une automatisation sans destinataire pour ses alertes n’est pas une maintenance.
Choisir la fenêtre de mise en production
La date de sortie n’est pas une obligation de déployer le soir même. Elle ouvre une fenêtre de décision.
Pour un site simple et bien maintenu, la mise à jour peut suivre rapidement après vérification des sauvegardes et composants. Pour un site commercial complexe, il peut être raisonnable d’attendre les retours initiaux et les versions compatibles des extensions critiques — sans transformer ce délai en abandon de maintenance.
Évitez :
- le vendredi soir sans équipe disponible ;
- la veille d’une campagne, d’un salon ou d’une période de vente forte ;
- une mise à jour simultanée de WordPress, PHP, du thème et de toutes les extensions ;
- une intervention sans mesure avant/après ni procédure de restauration.
Découper les changements permet de savoir lequel a provoqué un problème. Notez l’heure, les versions avant et après, les tests effectués et le résultat. Gardez cette fiche avec la maintenance du site, pas dans la boîte mail d’un seul prestataire.
Quand demander de l’aide avant le 19 août
Une assistance est particulièrement utile si le site :
- génère directement des ventes, réservations ou demandes commerciales ;
- utilise un thème ou des extensions sur mesure ;
- dépend d’un constructeur de pages ancien ou d’une extension abandonnée ;
- n’a pas de copie de test récente ;
- ne dispose pas d’une restauration déjà vérifiée ;
- combine une évolution WordPress avec un changement de PHP ou d’hébergement ;
- présente déjà des erreurs, des tâches planifiées en retard ou des mises à jour bloquées.
Dans ces cas, l’objectif n’est pas de vendre une refonte automatique. Il faut d’abord distinguer ce qui peut être mis à jour, ce qui doit être remplacé et ce qui mérite seulement d’être documenté.
Notre article sur WordPress, PHP et la maintenance 2026 explique la dette technique de fond. La préparation à WordPress 7.1 est un chantier plus court : inventaire, sauvegarde vérifiable, environnement de test, scénarios prioritaires et fenêtre de déploiement.
1Design peut réaliser ce contrôle sur un périmètre défini, puis prendre en charge la gestion technique du site si un suivi régulier est justifié. Le même diagnostic peut aussi relier la création de site internet à Lyon, la structure des pages et l’optimisation SEO locale quand la mise à jour révèle un problème de visibilité ou de conversion. Pour un site devenu trop fragile ou difficile à modifier, la création de site vitrine à Lyon reste une option — mais seulement après avoir établi que la maintenance ne suffit plus.
Contactez 1Design avec l’URL du site, le nom de l’hébergeur et la liste des trois fonctions qui ne doivent surtout pas tomber. Nous vous répondrons avec un périmètre de vérification concret, pas avec une promesse abstraite de « compatibilité WordPress ».
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?