Mises à jour, sauvegardes et rôles

Module 6: Gestion et sécurité · Temps de lecture : 11 minutes

Objectif pédagogique : À l’issue de cette leçon, vous saurez mettre à jour et sauvegarder une boutique WooCommerce sans perdre de commandes, et répartir les droits de sorte que chacun ne puisse faire que ce qui est nécessaire.

Notions clés : mise à jour majeure et mineure, mise à jour de la base de données, extensions et compatibilité, remplacements de modèles (template overrides), modèles obsolètes, sauvegarde avant la mise à jour, commandes entre la sauvegarde et la restauration, tables HPOS, rôles Gestionnaire de boutique (Shop manager) et Client (Customer), moindre privilège, affichage des versions, xmlrpc.php

Pourquoi une boutique diffère d’un site ordinaire

La formation WordPress (leçons 7.2, 8.1 et 8.2) explique comment mettre à jour WordPress, comment créer des sauvegardes et comment les restaurer. Tout cela s’applique à une boutique, avec une grande différence : la base de données change toute la journée. Chaque commande, chaque client, chaque modification de stock et chaque paiement y est enregistré. Sur un site d’information, une sauvegarde de la veille vous fait perdre au pire un article. Sur une boutique, vous perdez des commandes déjà payées.

D’où deux règles de base pour cette leçon :

1. Sur une boutique, la restauration est la dernière étape, pas la première.
2. Faites vos mises à jour selon un plan, et non "vite fait le vendredi après-midi".

Mises à jour de WooCommerce

WooCommerce publie régulièrement de nouvelles versions, avec entre-temps de petits correctifs. Le numéro de version comporte trois parties, par exemple 11.2.2. Un changement du dernier chiffre correspond à un petit correctif ou à une mise à jour de sécurité ; un changement du premier ou du deuxième chiffre apporte de nouvelles fonctions et parfois des modifications auxquelles les extensions ou votre thème doivent s’adapter.

Lors d’une mise à jour de WooCommerce, trois choses se produisent que l’on voit moins avec une extension ordinaire :

• Une mise à jour de la base de données. WooCommerce doit parfois modifier ses tables. Un message apparaît alors dans l’administration indiquant que la base de données est en cours de mise à jour ; cela se déroule en arrière-plan via les actions planifiées (leçon 7.3). Ne l’interrompez pas et vérifiez dans WooCommerce > État si l’opération est terminée.
• Les extensions doivent suivre. Les extensions de paiement, les connexions aux transporteurs et les liaisons comptables indiquent jusqu’à quelle version de WooCommerce elles ont été testées. L’écran des extensions affiche un avertissement si une extension ne mentionne pas une version plus récente. Lisez les notes de version de votre extension de paiement avant la mise à jour : une extension de paiement en panne, c’est une boutique qui ne vend plus.
• Remplacements de modèles. De nombreux thèmes contiennent leurs propres copies des modèles de WooCommerce (le dossier woocommerce/ du thème). Si WooCommerce modifie l’original, la copie devient obsolète. Dans WooCommerce > État (État du système), la section du thème, en bas de page, indique quels modèles il remplace et lesquels sont obsolètes. Les modèles obsolètes peuvent manquer de nouveaux champs ou provoquer des erreurs. Mettez le thème à jour ou demandez une mise à jour à son auteur.

Les mises à jour mineures (dernier chiffre) s’installent de préférence rapidement, idéalement de façon automatique, car elles corrigent souvent des failles de sécurité. Les mises à jour majeures se testent d’abord sur un site de préproduction (staging, leçon 7.3), à un moment calme, avec une sauvegarde réalisée juste avant.

Sauvegardes : ce qui disparaît lors d’une restauration

Un exemple. Maison de thé Example (boutique en ligne à Utrecht, Pays-Bas) effectue une sauvegarde chaque nuit à 03.00. Le mardi à 10.00, l’administrateur met WooCommerce à jour, puis la page produit affiche une erreur. Entre 03.00 et 10.00, six commandes sont arrivées, payées via le prestataire de paiement. Si vous restaurez maintenant la sauvegarde de 03.00 :

• ces six commandes ont disparu de la base de données, alors que l’argent se trouve bien chez le prestataire ;
• la boutique ne sait plus que le stock a diminué ;
• la boutique recevra peut-être encore du prestataire des notifications (webhooks) concernant des commandes qu’elle ne connaît pas.

C’est pourquoi :

• Faites une sauvegarde juste avant une mise à jour, et pas seulement la nuit. L’écart est alors le plus réduit possible.
• Lors d’une restauration, notez les commandes arrivées après la sauvegarde (à partir des e-mails "Nouvelle commande" et du tableau de bord de votre prestataire), puis saisissez-les à nouveau manuellement, ou exportez-les au préalable.
• Restaurez de préférence uniquement les fichiers (l’ancien dossier de l’extension ou du thème) si le problème vient du code, et laissez la base de données en place. Annuler une mise à jour est souvent possible en installant la version précédente de l’extension ; la formation WordPress, leçon 8.2, montre comment effectuer une restauration ciblée. Si la mise à jour a déjà modifié la base de données, l’ancienne version risque de ne plus fonctionner avec celle-ci : d’où l’intérêt de tester d’abord sur le site de préproduction.
• Sauvegardez plus souvent que pour un site ordinaire : une boutique qui reçoit des commandes toute la journée a besoin d’une sauvegarde de la base de données au moins quotidienne, idéalement plus fréquente, et d’une copie hors du serveur (règle 3-2-1, formation WordPress, leçon 8.1).

Depuis WooCommerce 8.2, les commandes des nouvelles boutiques sont stockées dans des tables dédiées (HPOS, leçon 1.2), comme wp_wc_orders. Une extension de sauvegarde qui ne prend que les "articles" ou qui sélectionne les tables par leur nom doit aussi inclure ces tables. Lors d’un test de restauration (formation WordPress, leçon 8.2), vérifiez que les commandes s’y trouvent réellement.

Chez WebOké, WebOké Backups effectue chaque nuit une sauvegarde conservée 30 jours dans un autre datacenter (DA 16.1) ; vous pouvez en outre créer vous-même une sauvegarde avant une mise à jour dans DirectAdmin ou Installatron. Chez d’autres hébergeurs, le fonctionnement est similaire ; renseignez-vous sur la fréquence et la durée de conservation.

Rôles : qui peut faire quoi

WooCommerce ajoute deux rôles à WordPress (formation WordPress, leçon 3.3) :

• Client (Customer) : un client disposant d’un compte. Il ne peut voir que ses propres commandes et données. Ne donnez jamais de droits d’administration à ce rôle.
• Gestionnaire de boutique (Shop manager) : peut gérer les produits, les commandes, les clients, les codes promo et les réglages de WooCommerce, mais ne peut ni installer d’extensions ni modifier le thème.

Pour les collaborateurs qui préparent les commandes, répondent aux questions des clients ou saisissent des produits, le rôle Gestionnaire de boutique suffit. Le rôle Administrateur est réservé à la personne qui s’occupe de la technique. Chaque collaborateur dispose de son propre compte, avec authentification à deux facteurs (formation WordPress, leçon 7.3) ; pas de compte partagé "boutique". Un gestionnaire de boutique voit toutes les données des clients : supprimez donc les comptes lorsqu’une personne s’en va.

Les clés API (leçon 2.4) sont aussi une forme de droits : accordez à une liaison un accès en lecture seule si elle n’a rien à écrire, et supprimez les clés qui ne sont plus utilisées.

Ce que votre boutique montre à tout le monde

Les attaquants recherchent des boutiques utilisant une ancienne version de WooCommerce ou une extension de paiement présentant une faille connue. Par défaut, WooCommerce place une ligne <meta name="generator" content="WooCommerce 11.2.2"> dans le code source, et la version figure aussi derrière les feuilles de style (?ver=). Masquer est un petit gain ; mettre à jour, un grand. Une boutique bien à jour n’a guère à s’inquiéter d’un numéro de version visible. Une boutique en retard, elle, se trahit.

Le fichier xmlrpc.php est une ancienne interface qui permet à des applications de se connecter à WordPress. Il est souvent détourné pour deviner des mots de passe. Si vous n’utilisez aucune application ni aucun service qui en a besoin, fermez-le (chez WebOké, il est fermé par défaut, KB 169). Un xmlrpc.php ouvert répond à une simple requête dans le navigateur par "XML-RPC server accepts POST requests only." et le statut 405. Fermé, il renvoie 403 ou 404.

Résumé

• La base de données d’une boutique change toute la journée : une restauration fait perdre des commandes déjà payées.
• Mises à jour mineures rapidement, mises à jour majeures d’abord en préproduction ; surveillez la mise à jour de la base de données, les extensions et les modèles obsolètes dans WooCommerce > État.
• Sauvegardez juste avant une mise à jour et plus souvent que pour un site ordinaire ; vérifiez que les tables des commandes sont incluses.
• Les collaborateurs reçoivent le rôle Gestionnaire de boutique, pas Administrateur ; chacun a son propre compte avec authentification à deux facteurs.
• Masquer les versions aide peu, mettre à jour aide beaucoup ; fermez xmlrpc.php si vous ne l’utilisez pas.

Quiz

Exercice

Exercice A6.2 : Votre boutique affiche-t-elle des versions ? Saisissez l’adresse de votre boutique, votre version de WordPress (Tableau de bord > Mises à jour) et votre version de WooCommerce (Extensions). Le programme interroge la page d’accueil et le flux, ainsi que le fichier /wp-content/plugins/woocommerce/readme.txt (uniquement les 2 premiers ko, la ligne "Stable tag"). Il recherche les numéros de version de WordPress et de WooCommerce dans les lignes generator et derrière ?ver= dans les feuilles de style de WooCommerce, et consulte les dernières versions sur wordpress.org. Vert si vos versions sont les plus récentes et que ce qui est visible correspond. Orange si seule une mise à jour mineure est en attente, ou si la version est visible mais à jour. Rouge si vous avez une version majeure de retard, si la version visible diffère de celle que vous avez saisie (il tourne autre chose que ce que vous pensez), ou en cas de saisie invalide.

Exercice A6.2b : xmlrpc est-il fermé ? Saisissez l’adresse de votre boutique et cochez la case si vous utilisez une application ou un service qui a besoin de xmlrpc.php. Le programme interroge /xmlrpc.php avec une simple requête GET, sans rien envoyer. Vert en cas de 401, 403, 404, 410, de redirection ou de page HTML ordinaire. Rouge en cas de 405 avec le texte "XML-RPC server accepts POST requests only." sans case cochée ; orange si vous avez indiqué en avoir besoin. Il vérifie aussi si la liste des noms d’utilisateur est publique via /wp-json/wp/v2/users (orange si des noms sont visibles).

Une coche verte signifie que ce contrôle est correct à cet instant, pas que votre boutique est sûre.

Pour aller plus loin

Les étapes décrites dans un panneau valent pour WebOké ; chez d’autres prestataires, le fonctionnement est similaire.

• Formation WordPress gratuite 7.2: Suivre les mises à jour
• Formation WordPress gratuite 8.1: Sauvegardes : quoi, où et à quelle fréquence
• Formation WordPress gratuite 8.2: Restaurer et tester
• Formation WordPress gratuite 3.3: Comptes et rôles
• Guide DirectAdmin 16.1: Quelles sauvegardes propose WebOké
• WebOké Backups : consulter, restaurer ou télécharger une sauvegarde
• WordPress : l'accès à xmlrpc.php ne fonctionne pas
• High Performance Order Storage (developer.woocommerce.com, en anglais) : https://developer.woocommerce.com/docs/features/orders/high-performance-order-storage/