Posez un chronomètre sur la table. À côté, quatre cartes : publier, être trouvé, recevoir une demande, vendre ou réserver.
La première Release Candidate de WordPress 7.1 a été publiée le 5 août 2026, avant RC2 le 12 août et la sortie finale prévue le 19 août. L’annonce officielle compte plus de 145 mises à jour et correctifs depuis Beta 4, dont 57 dans l’éditeur et 88 dans le cœur. Ce jalon ne transforme pas une préversion en mise à jour recommandée pour le site public. Il rend en revanche un test sur copie beaucoup plus instructif qu’il ne l’était au début de la bêta.
Pour une PME, l’objectif n’est pas de « tout tester ». En 90 minutes, il faut découvrir si WordPress 7.1 menace une fonction essentielle, identifier qui doit corriger le problème et décider si la mise à jour finale pourra être rapide, différée ou précédée d’un chantier technique.
Ce que RC1 change dans la décision
Une Release Candidate est une version potentiellement proche de la version finale. Le calendrier WordPress place à ce moment le Field Guide, le gel des chaînes et la création de la branche 7.1. Les changements sont plus documentés ; les éditeurs de thèmes et d’extensions disposent d’un signal clair pour terminer leurs contrôles.
Mais « candidate » ne signifie pas « validée pour votre entreprise ». WordPress demande de réserver les versions de test aux environnements locaux ou de recette. Entre le cœur et le visiteur se trouvent votre thème, vos extensions, votre version de PHP, votre hébergement, vos personnalisations et vos connexions métier. C’est cette combinaison qu’il faut éprouver.
Notre précédent guide expliquait comment préparer une mise à jour WordPress 7.1 : inventaire, sauvegarde, copie fidèle et fenêtre de déploiement. Le présent test commence une étape plus tard. La copie existe, personne ne peut la confondre avec le site public et les emails, paiements et webhooks externes sont neutralisés.
Si ces conditions ne sont pas réunies, n’installez pas RC1. Consacrez plutôt les 90 minutes à créer cet environnement.
Avant le chronomètre : fixer le résultat attendu
Préparez une fiche avec cinq colonnes : parcours, résultat attendu, résultat constaté, preuve, décision. Ne notez pas seulement « OK ». Une preuve peut être une capture, un email reçu sur une boîte de test, une commande de démonstration, une URL ou une ligne de journal datée.
Choisissez aussi les identifiants de départ : version actuelle de WordPress, version de PHP, thème actif et cinq extensions les plus critiques. Gardez une capture de la page d’accueil, d’une page service, d’un article et d’un écran d’édition avant la mise à niveau de la copie.
Enfin, vérifiez que vous savez revenir à l’état précédent. Un environnement de recette bloqué après le test n’est pas dramatique ; ne pas comprendre pourquoi il l’est rend la répétition peu utile.
Minute 0 à 20 : l’éditeur doit encore produire le bon site
WordPress 7.1 poursuit des évolutions visibles dans l’éditeur : styles responsifs et d’états, traitement des médias, révisions partageables, notifications de mentions et changements techniques autour de l’isolation de l’éditeur. Ce sont de bonnes raisons de commencer par le travail quotidien plutôt que par la page d’accueil.
Avec le rôle réellement utilisé par l’équipe :
- dupliquez un article représentatif ;
- modifiez un titre, un lien, une image et un bloc réutilisé dans le site ;
- prévisualisez en mobile et en ordinateur ;
- enregistrez en brouillon, publiez sur la recette puis revenez à une révision ;
- contrôlez le front dans une fenêtre privée.
Cherchez les écarts entre l’éditeur et la page publique : largeur, couleurs, typographie, espacements, boutons au survol, légendes et recadrage d’image. Un thème ancien ou un bloc maison peut sembler correct en lecture tout en devenant difficile à modifier.
Ajoutez un test de rôle si plusieurs personnes publient. L’administrateur possède des droits qui peuvent masquer une erreur rencontrée par un éditeur ou un auteur. Si l’entreprise utilise un constructeur de pages, faites le même parcours dans ce constructeur ; l’éditeur natif n’est alors qu’une partie du risque.
Décision à la minute 20 : si l’équipe ne peut plus créer ou corriger une page sans contournement, classez la mise à jour « à corriger avant production ». Ne continuez pas en espérant qu’un test de façade compensera ce défaut.
Minute 20 à 40 : le référencement doit conserver ses signaux
Ouvrez quatre modèles : accueil, service, article et une page exclue de l’indexation comme une page de confirmation. Pour chacun, comparez avant et après :
- titre SEO et méta-description ;
- canonical ;
- directive robots ;
- un seul titre principal cohérent ;
- données structurées attendues ;
- présence dans le sitemap lorsque la page doit être indexée.
Contrôlez ensuite une URL modifiée ou redirigée et une page inexistante. Une mise à jour peut laisser les pages visuellement intactes tout en changeant la sortie d’une extension SEO, le rendu d’un bloc ou le fonctionnement d’une redirection.
Ne concluez pas à partir de la seule page d’accueil. Les problèmes apparaissent souvent sur un type de contenu moins visible : fiche équipe, étude de cas, catégorie, fiche produit ou page locale. Si votre trafic dépend de pages de service à Lyon ou dans d’autres villes, incluez-en une dans l’échantillon.
Pour aller plus loin après ce contrôle borné, l’optimisation SEO à Lyon doit relier les signaux techniques au contenu et aux requêtes réellement porteuses. Le test RC vérifie d’abord qu’une mise à niveau ne détériore pas l’existant.
Décision à la minute 40 : une anomalie de canonical, robots ou sitemap bloque la production, même si le site « a l’air normal ».
Minute 40 à 60 : une demande doit parcourir toute la chaîne
Remplissez chaque famille de formulaire avec des données reconnaissables : contact, devis, recrutement, inscription et réservation s’ils existent. Vérifiez quatre endroits :
- le message affiché au visiteur ;
- la notification reçue par l’entreprise ;
- la confirmation éventuelle reçue par le testeur ;
- l’enregistrement dans WordPress, le CRM ou l’outil métier.
Testez aussi une erreur volontaire : champ obligatoire vide, adresse invalide, fichier trop lourd ou consentement absent. Une validation qui ne s’affiche plus correctement sur mobile peut faire chuter les demandes sans provoquer d’erreur serveur évidente.
Si le site utilise un antispam, une bannière de consentement ou une mesure de conversion, vérifiez leur interaction. L’objectif n’est pas de confirmer seulement qu’un email part, mais que le visiteur peut soumettre, comprendre le résultat et que l’équipe reçoit une donnée exploitable sans doublon.
Décision à la minute 60 : toute demande perdue, doublonnée ou envoyée à la mauvaise destination impose une correction et un nouveau test complet de cette chaîne.
Minute 60 à 80 : faire une vente sans argent réel
Pour un site vitrine sans paiement ni réservation, utilisez ces vingt minutes pour le parcours le plus commercial. Pour une boutique WooCommerce, préparez un panier test qui traverse réellement les règles du magasin :
- un produit simple et une variante ;
- un code promotionnel ou un seuil de livraison ;
- l’adresse de facturation et de livraison ;
- un moyen de paiement en mode test ;
- la création de commande, le stock et les emails ;
- l’annulation ou le remboursement si la recette le permet.
Ne testez pas uniquement la carte bancaire. Les virements, paiements différés, points relais, taxes, factures, abonnements et connecteurs ERP sont précisément les branches qui reçoivent moins d’attention.
Regardez le front et le back-office. Le client peut voir un échec alors qu’une commande et une réservation de stock ont été créées. À l’inverse, une page de succès peut s’afficher sans que le paiement ou l’outil logistique ait reçu l’événement attendu.
Décision à la minute 80 : si le résultat commercial est ambigu, la mise à jour reste en recette jusqu’à ce que l’état de commande, le paiement, le stock et le message client racontent la même histoire.
Minute 80 à 90 : lire les signaux faibles et trancher
Terminez par les journaux PHP et WordPress, la santé du site, les tâches planifiées, le cache et quelques mesures simples avant/après. Une seconde de variation isolée ne prouve rien ; une erreur répétée, une tâche bloquée ou une hausse nette du temps serveur mérite une investigation.
Classez le résultat dans une seule des trois cases.
Vert : prêt à retester sur la version finale
Tous les parcours critiques passent, aucune nouvelle erreur significative n’apparaît et les éditeurs des composants essentiels donnent des signaux de compatibilité. Cela ne déclenche pas une mise à jour automatique le 19 août. Cela permet de réserver une fenêtre, refaire une sauvegarde et exécuter une recette courte sur la version finale.
Orange : mise à jour possible après correction bornée
Un composant précis échoue ou manque de preuve : thème, formulaire, extension SEO, passerelle ou code maison. Assignez un responsable, une correction et une date. Évitez de profiter du chantier pour mettre simultanément à niveau PHP, remplacer le thème et ajouter des fonctions sans rapport : vous perdriez la capacité d’identifier la cause d’un écart.
Rouge : la copie révèle une dette de maintenance
La restauration n’est pas maîtrisée, plusieurs extensions sont abandonnées, personne ne connaît les connexions métier ou l’éditeur casse avant même les parcours clients. Le problème dépasse WordPress 7.1. Il faut décider entre remise à niveau, remplacement de composants ou reconstruction progressive.
Une agence web à Lyon utile ne devrait pas prescrire une refonte à partir du seul numéro de version. Le diagnostic doit montrer ce qui fonctionne, ce qui bloque et le coût de chaque voie.
Le livrable tient sur une page, pas dans une impression
À la fin, conservez :
- la matrice des parcours et preuves ;
- les versions testées ;
- les anomalies avec leur niveau d’impact ;
- le responsable et la prochaine action ;
- la décision vert, orange ou rouge ;
- la date du prochain contrôle, idéalement sur RC2 ou la version finale selon le résultat.
Ce document est plus utile qu’un message « RC1 testée, ça semble bon ». Il rend la décision transmissible au dirigeant, au prestataire et à la personne qui assurera la mise en production.
1Design peut exécuter ce test de non-régression sur une copie existante ou cadrer une recette adaptée au site. avec l’URL, l’hébergeur, le thème ou constructeur utilisé et les quatre actions que le site ne doit jamais perdre. Nous proposerons un périmètre de test concret avant de parler de mise à jour, de maintenance ou de refonte.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?