Aller au contenu

Cœur et administration WordPressExtensions WordPress Mis à jour le 2026-09-18

Gérer les mises à jour WordPress sur un parc de sites

Apprenez à gérer les mises à jour WordPress sur plusieurs sites sans ouvrir chaque tableau de bord à la main. Ce guide compare MainWP, ManageWP et WP-CLI par SSH, puis vous fait bâtir une routine de mise à jour qui attrape une mauvaise version d'extension avant vos clients.

Ce guide vous montre comment mettre à jour le cœur de WordPress, les extensions et les thèmes sur plusieurs sites depuis un seul endroit. Il s’adresse à l’agence, au pigiste ou à l’équipe interne qui entretient entre 10 et 200 sites et qui ouvre encore chaque tableau de bord à la main. Cette habitude est lente, elle laisse un site traîner des mois sur une vieille extension, et elle rend bien trop facile l’envoi d’une version brisée sur la page de paiement d’un client. La réponse courte, c’est qu’il vous faut un poste de commande, soit un outil capable d’atteindre chaque site, et une routine fixe par laquelle passe chaque mise à jour. À la fin, vous aurez un inventaire de vos sites, un point de restauration testé pour chacun, et une tournée hebdomadaire que vous bouclez en une heure environ.

Ce que vous allez accomplir

  • Bâtir un seul fichier d’inventaire qui liste chaque site que vous entretenez, où il se trouve et comment vous l’atteignez.
  • Choisir entre MainWP, ManageWP et WP-CLI pour chaque site, selon une règle plutôt qu’une préférence.
  • Prendre un point de restauration que vous avez réellement testé, pour qu’une mauvaise mise à jour vous coûte dix minutes au lieu d’une journée.
  • Classer chaque mise à jour en attente dans l’une de trois voies, pour qu’un correctif de sécurité parte aujourd’hui et qu’une version majeure attende la préproduction.
  • État final : chaque site n’a plus rien en attente, répond avec un code HTTP 200 et affiche un journal d’erreurs silencieux.

Prérequis

  • WordPress 6.0 ou plus récent sur chaque site, et un compte Administrateur pour chacun.
  • WP-CLI 2.9 ou plus récent si vous comptez passer par la ligne de commande. WP-CLI est l’outil de ligne de commande de WordPress, et il lance les mises à jour sans navigateur.
  • Un accès SSH pour les comptes que vous contrôlez. SSH, le protocole de shell sécurisé, est la connexion chiffrée à distance utilisée par les hébergeurs cPanel. Tous les hébergeurs partagés ne l’activent pas, alors vérifiez avant d’en dépendre.
  • PHP 8.1 ou plus récent. Beaucoup d’extensions publiées en 2026 refusent de s’activer en dessous.
  • Un endroit pour garder les exports de base qui n’est pas le même serveur, comme un seau de stockage objet ou votre propre poste de travail.
  • Une nuance honnête : sur les serveurs que vous administrez, WP-CLI atteint tout. Sur un hébergement appartenant au client, où vous n’avez qu’un compte WordPress, une extension de tableau de bord comme MainWP ou ManageWP est souvent la seule voie. La plupart des équipes finissent par utiliser les deux.

Comment ça fonctionne

Toutes les méthodes font la même chose au bout du compte. WordPress télécharge une archive ZIP depuis le dépôt d’extensions ou de thèmes, la décompresse par-dessus l’ancien dossier, puis exécute la mise à niveau de base de données que la nouvelle version réclame. Ce travail se déroule toujours sur le site lui-même, avec l’utilisateur système du site. Ce qui change, c’est qui le déclenche et ce qu’il faut installer pour le permettre.

MainWP est un tableau de bord que vous hébergez. Vous installez l’extension MainWP Dashboard sur un site WordPress qui vous appartient, et l’extension MainWP Child sur chaque site que vous gérez. Votre tableau de bord lance une requête HTTPS sortante vers chaque site enfant pour lire les versions et appliquer les mises à jour. Rien ne passe par un tiers, et la connexion est signée par une paire de clés partagée entre les deux extensions.

ManageWP est un service hébergé. Vous installez son extension Worker sur chaque site, et ce sont les serveurs du fournisseur qui appellent. Vous n’avez aucun tableau de bord à tenir à jour, mais les données des sites et les commandes de mise à jour transitent par une infrastructure qui n’est pas la vôtre.

WP-CLI par SSH n’installe rien de plus. Vous vous connectez au serveur et vous lancez wp dans le dossier de chaque site. Sur un serveur cPanel, ça compte, parce qu’un même serveur héberge souvent plusieurs comptes cPanel distincts, chacun avec son répertoire personnel et son utilisateur système. Vous pouvez boucler sur tous ces comptes depuis un shell root sans jamais ouvrir de navigateur.

Comparaison côte à côte de MainWP, ManageWP et WP-CLI par SSH, montrant le poste de commande, la façon dont chacun atteint un site, et ce qui doit être installé sur le site

Étapes

1. Bâtissez l’inventaire. Tout le reste dépend de savoir ce que vous entretenez vraiment. Sur un serveur cPanel que vous administrez, trouvez chaque installation WordPress en cherchant le dossier wp-includes, que seul WordPress crée. Lancez ceci en root.

for u in $(ls -1 /var/cpanel/users); do
  find /home/"$u" -maxdepth 4 -type d -name wp-includes 2>/dev/null |
    while read -r d; do echo "$u $(dirname "$d")"; done
done | tee ~/wp-fleet.txt
acmeinc /home/acmeinc/public_html
acmeinc /home/acmeinc/public_html/shop
bleuclair /home/bleuclair/public_html

Chaque ligne représente un site, écrit sous la forme utilisateur cPanel et dossier WordPress. Pour les sites hébergés ailleurs, ajoutez un deuxième fichier qui liste l’adresse du site et le tableau de bord par lequel vous l’atteignez. Gardez les deux sous gestion de versions pour qu’un collègue puisse reprendre le travail.

2. Choisissez un poste de commande par site. Suivez cette règle plutôt qu’une préférence. Si vous avez SSH sur le serveur, prenez WP-CLI, parce que c’est le plus rapide et qu’il n’exige aucune extension de plus. Sans SSH, mais avec la permission du client d’installer une extension, choisissez entre les deux tableaux de bord. Prenez MainWP si vous voulez que les données restent sur votre propre infrastructure. Prenez ManageWP si vous préférez ne pas avoir un autre tableau de bord à faire rouler et à corriger. Si ni l’un ni l’autre n’est permis, le site n’est pas vraiment sous gestion, et il faut le dire par écrit.

3. Confirmez que WP-CLI fonctionne pour chaque compte. WP-CLI refuse volontairement de rouler en root, alors atteignez chaque site avec son propre utilisateur cPanel grâce à sudo.

sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html core version
6.7.2

Si vous obtenez un numéro de version, ce compte est prêt. Ajoutez les options --skip-plugins --skip-themes à toute commande de lecture, pour qu’une extension brisée ne vous empêche pas de lire l’état du site.

4. Prenez un point de restauration, et testez-le une fois. Faites-le avant le premier lot de chaque tournée, pas après un bris. Exportez la base de données et archivez le dossier des extensions.

sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html db export \
  /home/acmeinc/backups/2026-09-18-pre-update.sql --add-drop-table
tar -czf /home/acmeinc/backups/2026-09-18-plugins.tar.gz \
  -C /home/acmeinc/public_html/wp-content plugins
Success: Exported to '/home/acmeinc/backups/2026-09-18-pre-update.sql'.

Testez la restauration une fois, sur une copie de préproduction, avant de vous y fier pour 40 sites. La commande qui relit l’export est wp db import <file>. Une sauvegarde que vous n’avez jamais restaurée est une supposition, pas un point de restauration.

5. Lisez d’un coup tout ce que le parc attend. Demandez à chaque site ce qui lui manque, et écrivez la réponse dans un fichier CSV que vous pourrez trier et partager.

while read -r user path; do
  sudo -u "$user" -H -- wp --path="$path" plugin list --update=available \
    --fields=name,version,update_version --format=csv \
    --skip-plugins --skip-themes 2>/dev/null |
    tail -n +2 | sed "s|^|$user,$path,|"
done < ~/wp-fleet.txt | tee ~/fleet-updates.csv
acmeinc,/home/acmeinc/public_html,wordpress-seo,24.0,24.1
acmeinc,/home/acmeinc/public_html,woocommerce,9.4.2,10.0.0
bleuclair,/home/bleuclair/public_html,akismet,5.3.5,5.3.6

Remplacez plugin par theme pour obtenir la même liste côté thèmes, et lancez wp core check-update pour le cœur.

6. Classez chaque ligne dans l’une de trois voies. Les extensions WordPress utilisent surtout des versions à trois chiffres, écrites majeure.mineure.correctif. Servez-vous des chiffres comme règle. Un changement du troisième chiffre, comme 5.3.5 vers 5.3.6, est un correctif ou une rustine de sécurité, et il part le jour même sur tous les sites. Un changement du deuxième chiffre, comme 24.0 vers 24.1, apporte des fonctionnalités, et il attend le lot hebdomadaire après le passage d’un site témoin. Un changement du premier chiffre, comme 9.4.2 vers 10.0.0, passe d’abord en préproduction. Envoyez aussi dans la voie préproduction toute mise à jour d’une extension qui gère les paiements, les abonnements ou la mise en page, peu importe ses chiffres, parce que ce sont celles qui cassent de façon visible.

Schéma de décision qui classe une nouvelle version d'extension dans la voie du jour même, la voie du lot hebdomadaire ou la voie préproduction, avec la première action de chacune

7. Mettez à jour le site témoin avant le lot. Choisissez votre site au plus faible achalandage, idéalement un des vôtres, et passez-le toujours en premier. Mettez à jour une extension à la fois en épinglant la version, pour savoir exactement ce qui a changé.

sudo -u bleuclair -H -- wp --path=/home/bleuclair/public_html \
  plugin update wordpress-seo --version=24.1
Installing Yoast SEO 24.1
Downloading installation package from https://downloads.wordpress.org/plugin/wordpress-seo.24.1.zip...
Plugin updated successfully.
Success: Updated 1 of 1 plugins.

Chargez ensuite la page d’accueil du site dans un navigateur et cliquez un vrai parcours, comme un formulaire de contact ou un panier. Attendez une heure avant de lancer le reste. Si une extension fait planter le site, WordPress envoie un courriel de mode de récupération à l’adresse d’administration et garde le site debout : assurez-vous que cette adresse est une boîte que quelqu’un lit.

8. Lancez le lot approuvé. Construisez un fichier de mises à jour approuvées à partir de ~/fleet-updates.csv en supprimant les lignes qui appartiennent à la voie préproduction. Appliquez ensuite exactement ce qui reste.

while IFS=, read -r user path plugin from to; do
  echo "== $path $plugin $from -> $to"
  sudo -u "$user" -H -- wp --path="$path" plugin update "$plugin" --version="$to"
done < ~/approved-updates.csv | tee ~/update-run-2026-09-18.log
== /home/acmeinc/public_html wordpress-seo 24.0 -> 24.1
Success: Updated 1 of 1 plugins.

Gardez ce journal. Quand un client demandera pourquoi son site a changé mardi, c’est la réponse.

9. Mettez le cœur à jour en dernier, puis la base. Les extensions sont habituellement bâties contre la version courante du cœur, alors les mettre à jour d’abord leur évite une version qu’elles n’ont jamais vue. Les mises à jour du cœur amènent leur propre étape de base de données, et WordPress ne termine pas sans elle.

sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html core update
sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html core update-db
Success: WordPress updated successfully.
Success: WordPress database upgraded successfully from db version 59955 to 60421.

10. N’activez les mises à jour automatiques que là où vous les avez jugées sûres. Elles conviennent bien aux petites extensions stables, sur des sites sans code sur mesure. Activez-les par nom, jamais par réglage global.

sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html \
  plugin auto-updates enable akismet classic-editor
sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html \
  config set WP_AUTO_UPDATE_CORE minor
Success: Enabled 2 of 2 plugin auto-updates.
Success: Updated the constant 'WP_AUTO_UPDATE_CORE' in the 'wp-config.php' file with the value 'minor'.

La valeur minor laisse WordPress appliquer seul les versions de sécurité et d’entretien, tout en vous laissant les versions majeures du cœur.

Vérifier que ça fonctionne

Faites ces quatre vérifications après chaque lot, avant de fermer le billet.

D’abord, confirmez qu’aucun site n’attend encore quelque chose que vous vouliez appliquer.

while read -r user path; do
  n=$(sudo -u "$user" -H -- wp --path="$path" plugin list --update=available \
    --format=count --skip-plugins --skip-themes 2>/dev/null)
  echo "$n pending  $path"
done < ~/wp-fleet.txt
0 pending  /home/acmeinc/public_html
0 pending  /home/bleuclair/public_html

Ensuite, confirmez que chaque site répond toujours. Un site qui s’est mis à jour proprement puis qui est mort est le bris que vous voulez attraper le plus tôt.

while read -r user path; do
  url=$(sudo -u "$user" -H -- wp --path="$path" option get home \
    --skip-plugins --skip-themes 2>/dev/null)
  echo "$(curl -s -o /dev/null -w '%{http_code}' -L "$url")  $url"
done < ~/wp-fleet.txt
200  https://acmeinc.example
200  https://bleuclair.example

Troisièmement, confirmez que les fichiers sur le disque correspondent à ce que le dépôt a publié. Ça attrape un téléchargement coupé en chemin.

sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html core verify-checksums
sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html plugin verify-checksums --all
Success: WordPress installs verify against checksums.
Success: Verified 18 of 18 plugins.

Enfin, lisez les journaux d’erreurs une heure plus tard. Sur cPanel, le journal d’erreurs PHP est habituellement un fichier nommé error_log dans le dossier du site.

tail -n 20 /home/acmeinc/public_html/error_log

Aucune nouvelle ligne datée d’aujourd’hui veut dire que la tournée est propre. Si toutes les vérifications passent sur tous les sites, c’est terminé, et les points de restauration pourront être effacés demain.

Dépannage

« Error: This does not seem to be a WordPress installation. » WP-CLI regarde dans le mauvais dossier, ou wp-config.php se trouve un niveau au-dessus de la racine web. Pointez-le vers le dossier qui contient wp-includes avec --path, et si le fichier de configuration est ailleurs, ajoutez --require ou lancez la commande depuis le dossier parent. Vérifiez d’abord le chemin avec ls /home/<user>/public_html/wp-config.php.

« Error: YIKES! It looks like you’re running this as root. » WP-CLI bloque volontairement les exécutions en root. Tout fichier qu’il créerait appartiendrait à root, et l’utilisateur du site ne pourrait plus y écrire. Utilisez sudo -u <user> -H -- wp ... comme montré plus haut. Évitez --allow-root sur un serveur partagé, pour la même raison.

La mise à jour dit avoir réussi, mais le site affiche encore l’ancienne version. Quelque chose sert du code en cache. Videz le cache d’objets de WordPress, puis le cache d’octets PHP, qui garde le code PHP compilé d’une requête à l’autre.

sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html cache flush
sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html transient delete --all

Si une extension de cache de pages ou un CDN se trouve devant, videz-les aussi. Sur cPanel, redémarrer PHP-FPM pour le compte vide le cache d’octets.

Un site enfant MainWP ou ManageWP apparaît hors ligne. Deux causes couvrent presque tous les cas. Le pare-feu du serveur ou ModSecurity, le pare-feu applicatif web que roulent bien des serveurs cPanel, bloque les requêtes du tableau de bord : autorisez l’adresse IP du tableau de bord pour ce site. Ou une extension de sécurité a désactivé l’API REST, l’interface par laquelle WordPress répond aux requêtes programmatiques, dont dépend l’extension enfant. Rétablissez l’accès REST pour les requêtes authentifiées plutôt que de désactiver l’extension de sécurité.

Une mise à jour d’extension rend le site tout blanc. Revenez à la version inscrite dans votre fichier CSV, puis enquêtez en préproduction.

sudo -u acmeinc -H -- wp --path=/home/acmeinc/public_html \
  plugin update woocommerce --version=9.4.2

Si l’extension a aussi modifié la base de données, restaurez l’export de l’étape 4 avec wp db import. C’est pour ça que le point de restauration vient avant la mise à jour, et non après.

Une nouvelle version d’extension refuse de s’activer. La raison habituelle est une version de PHP inférieure à ce que l’extension exige maintenant. Vérifiez la version PHP du compte avec php -v en SSH, et changez-la dans cPanel sous Select PHP Version ou MultiPHP Manager. Testez d’abord le site sur la nouvelle version de PHP en préproduction, car les vieux thèmes y cassent aussi souvent que les extensions.

Quand ce n’est pas la bonne approche

En dessous de cinq sites environ, un outil de parc demande plus de travail qu’il n’en épargne, et un rappel au calendrier avec l’outil de mise à jour intégré reste honnête et suffisant. Si vos sites portent du vrai code sur mesure, les mises à jour appartiennent à une chaîne de déploiement avec gestion de versions et étape de préproduction. Un bouton de tableau de bord est le mauvais outil dans ce cas, et le guide de la préproduction à la production présente le bon. Si vous cherchez plutôt à décider si vous devez faire ce travail vous-même, lisez d’abord hébergement WordPress infogéré ou autogéré.

Soyez aussi clair sur ce qu’une routine de mise à jour n’est pas. Ce n’est pas un service de sauvegarde, ni un nettoyage de logiciels malveillants, ni un remplacement de la surveillance de disponibilité. Chacun de ces besoins est un métier à part, avec ses propres outils. Pour la liste complète des commandes de mise à jour et de leurs options, consultez la référence des commandes WP-CLI, et pour le comportement des mises à jour lui-même, la documentation WordPress.

Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.