« Votre site a été mis à jour. » Ce message devrait clore une opération, pas ouvrir une enquête. Pourtant, dans une petite entreprise, il arrive souvent sans préciser le site concerné, la version obtenue ni ce qui a été vérifié ensuite. Le dirigeant conserve l’e-mail ; le prestataire considère la tâche terminée. Entre les deux, la preuve reste floue.
La sortie de WordPress 7.1.3, le 6 octobre 2026, donne une raison concrète de clarifier cette réception. L’annonce officielle recense sept correctifs de sécurité et quatre corrections de bugs et recommande une mise à jour immédiate. Le bon livrable n’est donc pas seulement une notification : c’est un court reçu de maintenance, rattaché à votre installation et à des résultats observables.
Le point de départ a changé depuis septembre
Le correctif 7.1.2 du 22 septembre traitait une vulnérabilité de gravité critique. Il ne faut plus le présenter comme le dernier objectif de mise à jour de la branche 7.1 : l’annonce de WordPress 7.1.3, relue le 9 octobre, décrit une nouvelle version de maintenance et de sécurité.
Parmi les sujets corrigés figurent des problèmes touchant l’administration des commentaires, l’export WXR et la divulgation de commentaires sur des publications privées ou non publiées. Ces informations justifient la prise en charge rapide du correctif ; elles ne démontrent pas que votre site a été attaqué. Cet article ne propose aucun test d’exploitation.
WordPress indique que la mise à jour démarre automatiquement sur les sites prenant en charge les mises à jour d’arrière-plan. « Automatique » décrit un mécanisme, pas le résultat de votre installation. Une entreprise qui paie une maintenance doit pouvoir savoir si ce mécanisme a abouti, si une intervention a été nécessaire ou si un blocage reste ouvert. Le calendrier d’un prestataire ou la parution de cet article ne justifie pas d’attendre pour traiter une mise à jour de sécurité.
Trois phrases qui ne prouvent pas la même chose
« Les mises à jour automatiques sont activées » renseigne sur une configuration. « WordPress 7.1.3 est installé » décrit un état du logiciel. « La demande de devis de contrôle a été reçue après intervention » décrit le résultat d’un parcours commercial. Aucune de ces phrases ne remplace les deux autres.
Un e-mail de succès est une pièce utile, surtout s’il identifie le bon site et la bonne version. Mais il peut être ancien, concerner une copie de test ou ne rien dire d’une restauration survenue ensuite. Rapprochez-le d’une lecture actuelle de la version sur l’installation de production par le mainteneur. Une capture publique ou un numéro trouvé dans le code d’une page ne suffit pas à lui seul à établir l’état réel du cœur WordPress.
Inversement, une notification absente ne démontre pas un échec : le site peut avoir été corrigé sans que le message soit arrivé à la bonne personne. La réponse utile est de vérifier l’état puis les traces disponibles, pas de relancer aveuglément la même opération.
Pour une PME française dont le site est suivi par une agence et hébergé chez un autre prestataire, cette distinction évite aussi le renvoi de responsabilité. Qui constate la version ? Qui conserve le journal ? Qui valide le parcours métier ? Ces rôles doivent être nommés dans le suivi d’hébergement et de gestion technique.
Un reçu en six champs, pas un rapport de cinquante pages
Voici une proposition de réception 1Design, pas un document imposé par WordPress ni une certification de sécurité. Un ticket partagé ou une fiche de maintenance suffit. Les éléments techniques détaillés restent dans un espace à accès contrôlé ; le dirigeant reçoit une synthèse exploitable.
1. Le site et le périmètre réellement traités
Indiquez le domaine, l’environnement et le composant : « production, cœur WordPress » est plus précis que « site mis à jour ». Distinguez les extensions, le thème et l’hébergement lorsqu’ils ne font pas partie de l’intervention. Une mise à jour du cœur ne prouve pas que WooCommerce, le module de paiement ou le constructeur de pages sont à jour.
2. La version constatée, avant et après
Conservez la branche, la version avant intervention si elle est connue, puis la version relue après l’opération. Ajoutez l’heure et le fuseau : par exemple « 9 octobre, 09 h 00, heure de Paris », et la méthode de constat du mainteneur. Si l’état initial n’a pas été relevé, écrivez « non documenté » ; ne le reconstituez pas de mémoire pour remplir la case.
3. La trace d’exécution et son résultat
Référencez le journal ou le ticket horodaté : succès, échec ou résultat indéterminé. Si seul l’état final a pu être vérifié, dites-le. Une version actuellement correcte peut être confirmée sans prétendre connaître l’heure exacte de son installation. Le reçu doit séparer ce qui est vu maintenant de ce que les traces permettent de reconstituer.
4. La sauvegarde et la capacité de retour
La documentation officielle de mise à jour recommande une sauvegarde préalable. Demandez ce qu’elle couvre — fichiers et base de données notamment —, sa date et la personne capable de restaurer. « Sauvegarde créée » et « restauration testée » sont deux états différents. Si un test de restauration existe, référencez son résultat et sa date ; sinon, ne le marquez pas comme effectué.
Sur une boutique, revenir à une ancienne base peut effacer des commandes reçues depuis la sauvegarde. Le plan de retour doit donc expliquer comment préserver les données nouvelles. Une restauration vers une version vulnérable n’est pas une clôture satisfaisante : elle laisse un risque à traiter et une décision à documenter.
5. Le contrôle fonctionnel effectivement réalisé
Choisissez un parcours représentatif : demande de devis pour une entreprise de services, réservation ou commande de test pour une boutique. Notez le résultat constaté et la preuve correspondante, pas seulement « testé ». Pour un formulaire, confirmation à l’écran et réception dans la destination convenue sont deux vérifications distinctes.
La préparation se fait avec des données fictives et des destinations maîtrisées. Une copie de test doit être protégée, et ses envois ou paiements réels neutralisés. Tout contrôle sur le site public doit être convenu avec le responsable, sans contacter de vrais prospects ni provoquer une transaction involontaire. Ce sont des recommandations de recette, pas des dysfonctionnements attribués à 7.1.3.
6. Les réserves, leur responsable et la prochaine action
Une réserve n’annule pas toutes les preuves acquises. « Version vérifiée ; restauration non testée » permet d’avancer honnêtement. Mais « à surveiller » sans responsable ne permet pas de clore le suivi. Pour chaque point ouvert, précisez qui intervient, sur quoi et à quelle échéance convenue. Ne transformez pas une pièce absente en case verte.
Exemple fictif : accepter la correction sans inventer le reste
Une entreprise de services lyonnaise reçoit la fiche suivante. Cet exemple est entièrement fictif ; aucun site client n’a été contrôlé pour cet article.
Périmètre : site de production, cœur WordPress uniquement ; extensions hors de cette intervention.
État : version avant intervention non documentée ; 7.1.3 constatée le 9 octobre à 09 h 00, heure de Paris, dans l’administration de production par le mainteneur.
Exécution : notification de succès conservée dans le ticket ; journal détaillé non disponible. L’heure de constat n’est pas présentée comme l’heure d’installation.
Sauvegarde : copie fichiers et base signalée par l’hébergeur ; résultat de restauration non fourni.
Parcours : demande fictive de contrôle retrouvée dans la boîte de test convenue, après intervention ; preuve expurgée jointe au ticket.
Réserve : l’hébergeur doit documenter la capacité de restauration et convenir avec le mainteneur d’un contrôle isolé ; point non clôturé.
Le verdict n’est ni « tout est parfait » ni « rien n’a été fait ». L’état corrigé du cœur et le parcours testé sont documentés ; la capacité de restauration reste à confirmer. Cette formulation donne au dirigeant une action précise sans lui demander de devenir administrateur système.
Ancienne branche ou automatisme bloqué : garder une réponse exacte
L’annonce 7.1.3 indique des rétroportages en cours, lorsque nécessaires, vers les branches éligibles, jusqu’à 4.7 à la date de consultation. Elle rappelle que seule la version la plus récente est activement prise en charge. Il ne faut donc pas exiger le numéro 7.1.3 d’un site resté sur une autre branche comme unique preuve, ni affirmer que tous les anciens sites disposent déjà du correctif.
Le mainteneur doit identifier la publication applicable à la branche exacte, vérifier sa disponibilité et constater son installation. Un rétroportage annoncé ne vaut pas une installation réussie. Une branche ancienne demande aussi une trajectoire vers une version actuelle ; ce chantier se distingue du traitement immédiat du risque.
Si l’automatisme échoue, demandez le blocage précis et sa prise en charge rapide. La documentation WordPress décrit plusieurs méthodes de mise à jour ; choisir la bonne appartient au responsable technique. Une PME n’a pas à modifier des permissions ou supprimer des fichiers sur la foi d’un article généraliste. Un défaut durable de thème ou d’extensions peut justifier une évolution du site internet, mais pas une refonte imposée avant toute correction ciblée.
Les deux limites à laisser écrites sur le reçu
« Corrigé » ne veut pas dire « jamais compromis ». Installer une version corrigée ne recherche pas à lui seul une intrusion antérieure. Des comptes inconnus, des fichiers suspects ou un comportement inhabituel exigent un diagnostic distinct ; le reçu de mise à jour ne constitue pas un certificat d’absence de compromission.
« Parcours testé » ne veut pas dire « site entièrement audité ». Le résultat couvre le scénario, l’environnement et le moment indiqués. Il ne garantit ni toutes les fonctions, ni toutes les extensions, ni la sécurité future. Cette limite n’enlève rien à l’intérêt du contrôle : elle évite simplement de vendre une preuve plus large que le travail réalisé.
La demande à adresser à votre prestataire
Vous pouvez lui transmettre ce message :
« Merci de confirmer la version actuellement installée sur notre site de production après la sortie de WordPress 7.1.3, ou le correctif applicable à notre branche. Nous souhaitons un reçu indiquant le périmètre, la date du constat, les traces disponibles, l’état des sauvegardes et de la restauration, le parcours vérifié et les réserves restantes. Merci de distinguer les points prouvés des éléments non documentés. »
Si personne ne peut produire cette synthèse, présentez à 1Design l’URL du site et le dernier compte rendu de maintenance expurgé. Nous pourrons cadrer la vérification d’une installation et de ses preuves, puis préciser les éventuels travaux séparés. Ce premier échange ne nécessite aucun mot de passe, aucune clé d’accès ni aucune sauvegarde contenant des données clients.
Sources et date de vérification
Sources primaires consultées le 9 octobre 2026 : annonce WordPress 7.1.3 du 6 octobre, modifiée le 8 octobre, annonce 7.1.2 du 22 septembre, historique officiel des sorties et documentation de mise à jour. Le reçu en six champs, les critères de réception et l’exemple constituent des recommandations 1Design. Ils ne décrivent ni un audit réalisé ni des obligations réglementaires nouvelles.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?