« On attend la prochaine version. » La phrase peut désigner une décision de maintenance raisonnable ou un problème que personne n’a vraiment pris en charge. La différence tient à une question : quel défaut précis attendez-vous de voir corrigé ?
Pour un site vitrine, attendre quelques jours peut éviter deux interventions rapprochées. Mais une demande de devis qui n’arrive plus dans la boîte de réception ne devient pas moins urgente parce qu’un correctif WordPress est annoncé. Avant de retenir une date, il faut distinguer le calendrier du logiciel de la situation de votre entreprise.
Le 17 septembre est une cible, pas une réparation promise
Le calendrier officiel de WordPress 7.1.1, consulté le 10 septembre 2026, vise une première version candidate le 10 septembre à 19 h 30 à Paris et une version finale le 17 septembre à 17 h à Paris. Ces horaires restent estimatifs. Avant toute intervention, vérifiez l’annonce de disponibilité : une date inscrite au calendrier ne prouve pas que la version est sortie.
Une version candidate, ou RC, sert à éprouver une version susceptible de devenir finale. Ce n’est pas le signal pour remplacer le logiciel de votre site commercial. Réservez son éventuel essai à une copie isolée, sous la responsabilité du mainteneur.
WordPress présente 7.1.1 comme une version de maintenance consacrée aux corrections de bugs introduits pendant le cycle 7.1 ou volontairement reportés à sa fin. Cela ne signifie ni que tous les défauts signalés seront corrigés, ni que votre extension de formulaire sera réparée par le cœur de WordPress. La liste définitive doit être relue lors de la sortie effective.
Demandez le lien du correctif, pas seulement sa date
Si votre prestataire propose d’attendre, demandez-lui de relier cette attente à une observation : la page concernée, le geste qui déclenche l’erreur et, lorsqu’il existe, le ticket officiel qui décrit le même comportement. Un ticket encore proposé pour 7.1.1 n’est pas une promesse de livraison.
Prenons un exemple fictif : une agence d’architecture à Lyon ne parvient plus à modifier la légende d’une réalisation. Le problème peut se situer dans l’éditeur WordPress, le constructeur de pages ou une extension. Le fait qu’il soit apparu après une mise à jour ne suffit pas à identifier son origine. Le mainteneur doit reproduire le défaut sur une copie et comparer le résultat avec les informations du ticket. Si le correctif appartient finalement au constructeur, attendre uniquement WordPress 7.1.1 ne répond pas au problème.
Une attente correctement motivée pourrait se formuler ainsi : « Le défaut est reproduit sur notre copie, le ticket correspond, une correction est proposée ; nous vérifierons son inclusion et rejouerons ce parcours sur la version finale. » C’est beaucoup plus utile que « la prochaine version devrait régler cela ».
Une semaine d’attente n’a pas le même coût selon le site
Votre site fonctionne sous 7.1. Si les demandes arrivent, les pages restent modifiables et aucun incident n’est identifié, préparez l’arrivée du correctif : sauvegarde, personne disponible et contrôle des parcours après installation. Il n’est pas nécessaire d’inventer une panne pour justifier la maintenance. Vérifiez aussi la politique de mises à jour automatiques réellement appliquée par l’hébergeur et le site : une version mineure peut être installée en arrière-plan, comme l’explique la documentation WordPress.
Votre passage à 7.1 n’a pas encore eu lieu. Si la version actuellement installée ne présente pas d’urgence identifiée, une attente courte et datée peut permettre de préparer un seul passage vers une version finale plus récente. Ce choix doit néanmoins s’appuyer sur l’état exact du site et les avis de sécurité applicables. Attendre une « .1 » n’est pas une politique de sécurité universelle, ni une raison de reporter un correctif urgent déjà disponible.
Une fonction commerciale est cassée. Pour un artisan qui reçoit ses demandes depuis un formulaire, perdre cette fonction exige une prise en charge dès maintenant : vérifier le trajet du message, identifier la cause, envisager un contournement validé et rendre un autre moyen de contact visible si nécessaire. Il ne faut pas attendre le 17 septembre sans diagnostic. Ces mesures sont des recommandations opérationnelles, pas l’annonce d’un bug avéré de WordPress 7.1.
Un site vitrine destiné aux entreprises lyonnaises n’est pas seulement une série de pages. Sa disponibilité utile comprend les appels, les demandes reçues et la capacité de l’équipe à actualiser ses informations.
Ce qu’il faut vérifier avant d’agir
Commencez par conserver une sauvegarde des fichiers et de la base de données, avec une procédure de restauration connue. La documentation officielle recommande une sauvegarde avant mise à jour. Pour la recette, utilisez une copie séparée : accès restreint, pas d’indexation et envois vers de vrais prospects neutralisés. Le blocage de l’indexation ne remplace pas le contrôle d’accès.
Le test décisif n’est pas toujours la page d’accueil. Sur le site d’un bureau d’études, ce sera peut-être le formulaire avec pièce jointe ; pour un cabinet, le lien vers la prise de rendez-vous ; pour un artisan, le bouton d’appel sur téléphone. Choisissez le parcours qui apporte effectivement des contacts à votre entreprise.
Sur la copie, essayez ce parcours avant puis après l’installation de la version finale envisagée. Utilisez des données fictives et une destination de test maîtrisée. Un message « envoyé » affiché à l’écran ne prouve pas la réception : contrôlez la boîte de test ou l’outil destinataire. Vérifiez également les accents, le numéro de téléphone et les champs utiles au traitement de la demande.
Faites ensuite modifier une page représentative par la personne qui le fait habituellement. Relisez son rendu public sur mobile, sans session administrateur. Après la mise en ligne, un contrôle borné du parcours réel devra être convenu avec le responsable du site, sans déclencher de sollicitations chez des tiers.
Enfin, prévoyez ce qui se passe en cas de retour arrière. Restaurer une ancienne base peut effacer les demandes ou modifications reçues depuis la sauvegarde. Le mainteneur doit expliquer comment ces nouveautés seront conservées ; recopier une préproduction sur le site ouvert n’est pas une stratégie de restauration.
Une décision que l’on peut relire la semaine suivante
Conservez une fiche courte, remplie avec les faits de votre site. Les indications ci-dessous sont des champs à renseigner, pas les résultats d’un audit réalisé.
| Point à consigner | Information attendue |
|---|---|
| Symptôme | Page, geste, résultat observé et date d’apparition |
| Environnement | Versions exactes avant/après et changements identifiés |
| Preuve | Reproduction sur copie et ticket pertinent, s’il existe |
| Décision | Intervention, attente motivée ou remise en état préalable |
| Responsabilité | Personne chargée de l’action et date de réexamen |
| Acceptation | Parcours attendu, preuve de réception et critère de reprise |
Si une extension est abandonnée ou concernée par un avis de sécurité applicable, traitez ce risque distinctement. Le correctif du cœur ne remplace pas sa maintenance. Si la restauration n’est pas maîtrisée, faites clarifier ce préalable avant une intervention ordinaire ; en cas d’incident urgent, le responsable technique doit définir la mesure de protection adaptée.
Deux réponses sans détour
Une RC convient-elle à mon site public ? Non : dans cette démarche, elle reste réservée à une copie de test isolée. Une RC ne remplace pas la validation de la version finale sur votre installation.
Le 17 septembre est-il une date garantie ? Non. C’est la date visée dans le calendrier consulté le 10 septembre. Vérifiez l’annonce de sortie avant de considérer la version comme disponible.
Le message à transmettre à votre mainteneur
Vous pouvez partir de cette demande :
« Pour WordPress 7.1.1, merci de confirmer notre version actuelle et la politique de mise à jour automatique. Si nous attendons un correctif, indiquez le défaut reproduit et le ticket correspondant. Après la sortie finale, nous souhaitons valider le parcours de contact et la modification d’une page sur une copie, puis convenir d’un créneau avec sauvegarde et retour arrière. »
Le résultat attendu est une réponse exploitable : qui intervient, sur quelle version, avec quels contrôles et à quelle prochaine date de décision. Pas une garantie abstraite de compatibilité avec toutes les extensions.
Si personne ne peut encore répondre, contactez 1Design pour cadrer la maintenance de votre site. Transmettez l’URL, le symptôme éventuel et vos périodes d’activité à préserver, sans mot de passe. Une intervention ciblée peut suffire ; une amélioration plus large du site internet se discute seulement si le diagnostic le justifie. L’objectif n’est pas d’attendre le bon numéro : c’est de savoir ce que l’intervention doit remettre, ou maintenir, en état de fonctionner.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?