Infogérance WordPress ou serveur auto-géré : le vrai partage du travail

Si votre WordPress est sur un VPS (serveur privé virtuel) que vous gérez, restez en auto-gestion seulement si vous avez besoin de root et l’exploitez bien. L’accès root donne le contrôle administrateur complet de la machine. Bien l’exploiter veut dire que quelqu’un répond aux alertes hors des heures de bureau, qu’une restauration a été testée et qu’une deuxième personne connaît la pile. Si vous avez besoin de root mais qu’un de ces points manque, gardez votre serveur et confiez les correctifs, la vérification des sauvegardes et les alertes de nuit à un contrat de service. Si vous ne savez pas dire ce que root vous apporte, l’hébergement WordPress infogéré retire du travail que vous avez sans doute déjà cessé de faire.

L’infogérance prend en charge le système d’exploitation, les mises à niveau de PHP et de la base de données, le renouvellement des certificats, les sauvegardes et, sur la plupart des plateformes, les alertes de nuit. Elle ne prend jamais vos extensions, votre code sur mesure, votre contenu ni votre engagement envers les gens qui comptent sur le site. Les sections suivantes montrent ce partage selon trois modèles, puis vous guident dans l’audit de votre propre serveur.

Ce que vous allez accomplir

• Tracer la frontière des responsabilités pour trois modèles : le VPS auto-géré, la plateforme infogérée, et le serveur auto-géré sous contrat externe de surveillance et d’intervention.
• Nommer le travail d’exploitation récurrent d’un WordPress auto-géré sous forme de tâches précises à des cadences précises, pas d’adjectifs.
• Auditer votre hôte : retard de correctifs, redémarrage en attente, position de PHP et de la base dans leur cycle de vie, santé du renouvellement TLS, restauration prouvée, surveillance externe.
• Séparer les défaillances qui ne frappent que les installations auto-gérées de celles qui vous frappent dans les deux cas.
• Arriver à une décision défendable en réunion, à partir de quatre réponses que vous pouvez donner honnêtement ce soir.

Prérequis

• Un accès SSH avec sudo sur le serveur qui exploite le site, ou les accès pour l’obtenir. Si vous êtes déjà sur une plateforme infogérée sans terminal, plusieurs commandes ci-dessous ne s’exécuteront pas — et cette absence fait elle-même partie de la réponse.
• WP-CLI sur l’hôte, ou la capacité de l’installer. Exécutez chaque commande wp sous le propriétaire des fichiers du site, jamais sous root.
• Un fichier de sauvegarde réellement accessible, assez d’espace disque et les privilèges MySQL pour créer et supprimer une base jetable. L’objectif de l’étape 6 est de la restaurer, pas de l’admirer.
• Les commandes diffèrent selon la famille. Debian et Ubuntu utilisent apt, placent PHP sous /etc/php/<version>/ et déposent un fichier témoin /var/run/reboot-required. RHEL, AlmaLinux et Rocky utilisent dnf, placent PHP sous /etc/php.d/ ou un préfixe SCL, et exposent needs-restarting via le paquet dnf-utils. Les deux formes sont montrées là où elles divergent.
• Aucune fenêtre de maintenance n’est requise pour l’audit. Tout est en lecture seule sauf le test de restauration, qui ne touche qu’une base jetable.

Comment ça fonctionne

Tout site WordPress repose sur la même pile, que vous louiez un VPS ou une plateforme : le matériel et le réseau en bas, puis un hyperviseur, un système d’exploitation, un serveur web et son moteur d’exécution, le TLS, les sauvegardes, la surveillance, puis le noyau WordPress, puis vos extensions et thèmes, puis votre contenu. Les modèles ne diffèrent que sur un point : l’endroit où tombe la frontière entre ce que quelqu’un d’autre exploite et ce que vous exploitez.

Lisez ce schéma de bas en haut. Sur un VPS auto-géré, le travail du fournisseur s’arrête deux couches plus haut : il garde le matériel en vie et l’hyperviseur en marche, et tout ce qui part d’apt vous appartient. Sur une plateforme infogérée, la frontière remonte juste sous le noyau WordPress. La troisième colonne est le juste milieu qu’on oublie : vous gardez votre serveur, mais les correctifs, la vérification des sauvegardes et l’intervention hors heures relèvent d’un contrat d’infogérance serveur WordPress avec quelqu’un dont le métier est de répondre — la frontière atterrit où celle de la plateforme se pose, atteinte par un travail partagé sur une machine que vous contrôlez encore.

Notez ce qui ne bouge dans aucune colonne. Les extensions, les thèmes, le code sur mesure, le contenu et les règles d’affaires restent au-dessus de la frontière dans les trois cas. C’est la partie la plus souvent mal lue de cette décision.

Ce que l’infogérance ne retire jamais

Une plateforme infogérée ne relira pas une extension avant que vous l’installiez, ne remarquera pas que le nouveau bloc d’en-tête de votre thème sert une image de 4 Mo, et n’écrira pas votre code sur mesure. Elle n’empêchera pas un rédacteur de supprimer une catégorie. La plupart des incidents qui font tomber un WordPress achalandé naissent au-dessus de la frontière — une vulnérabilité d’extension, une mauvaise mise à jour, une requête lente introduite par une nouvelle fonction — et ceux-là vous suivent chez n’importe quel hébergeur.

Ce qu’elle retire réellement, c’est la couche du dessous : les correctifs de paquets et les redémarrages pour prendre un nouveau noyau, les montées de version majeures de PHP et de la base, l’émission et le renouvellement TLS, l’exécution et la rétention des sauvegardes, la rotation des journaux et la marge disque, l’entretien du WAF et des limites de débit, et quelqu’un qui regarde un tableau de bord aux heures où vous dormez. C’est du vrai travail, et c’est celui que la plupart des petites équipes cessent discrètement de faire au quatrième mois.

Le travail récurrent, nommé

Rien de tout cela n’est difficile. Tout cela est facile à reporter, et chaque ligne entre en concurrence avec du travail que quelqu’un vous réclame vraiment.

Ce que vous cédez en passant à l’infogérance

Root, d’abord. Puis tout ce qui en dépend : des démons arbitraires (votre propre Redis, un moteur de recherche, un processus de file d’attente persistant, un import nocturne), des extensions PHP hors de la liste de la plateforme, des options de compilation personnalisées, une granularité de cron plus fine que le plancher de la plateforme, les réglages du noyau et de sysctl, des directives de serveur web sur mesure, des ports d’écoute arbitraires, et l’accès direct à la base depuis l’extérieur.

Cela compte pour une vraie minorité de sites : les montages découplés avec leur propre service de rendu, les chaînes média qui appellent ffmpeg, les intégrations qui exigent un processus de longue durée, ou un chemin de données qu’un contrat vous oblige à contrôler. Pour la plupart des sites de contenu et des boutiques WooCommerce, cela ne change rien — et si vous ne pouvez pas nommer le démon que vous perdriez, vous ne gardez pas le contrôle que vous croyez garder.

Pas à pas : auditez votre propre serveur

1. Mesurez le retard de correctifs. Ne vous fiez pas à votre mémoire ; comptez.

sudo apt update -qq && apt list --upgradable 2>/dev/null | head

Listing...
libssl3/jammy-security 3.0.2-0ubuntu1.19 amd64 [upgradable from: 3.0.2-0ubuntu1.15]
linux-image-generic/jammy-security 5.15.0.125.122 amd64 [upgradable from: 5.15.0.113.114]
php8.1-fpm/jammy-security 8.1.2-1ubuntu2.20 amd64 [upgradable from: 8.1.2-1ubuntu2.14]

Dans la famille RHEL, sudo dnf check-update affiche la même information et sort avec le code 100 quand des mises à jour existent, 0 quand il n’y en a pas — bon à savoir si vous le scriptez. Quelques paquets en attente, c’est normal. Trois pages, dont openssl ou le noyau, vous disent que personne n’a fait de mise à jour depuis des mois.

2. Vérifiez que la machine exécute ce qu’elle a installé.

uptime -p && ls -l /var/run/reboot-required 2>/dev/null || echo "no reboot flag"

up 1 year, 2 months, 6 days
-rw-r--r-- 1 root root 32 Mar 14 06:22 /var/run/reboot-required

Ce duo est la commande la plus révélatrice de cette page : une mise à jour du noyau a été installée il y a près de six mois et le noyau actif est encore l’ancien. Sur RHEL, AlmaLinux et Rocky, l’équivalent est needs-restarting -r, qui affiche Reboot is required ou No core libraries or services have been updated since boot-up.

3. Situez-vous dans le cycle de vie de PHP.

php -v

PHP 8.1.2-1ubuntu2.14 (cli) (built: Aug 18 2026 11:41:11) (NTS)

Comparez cette branche au tableau officiel des versions PHP supportées. Une branche dépassant sa date de fin de support de sécurité ne reçoit plus aucun correctif, de personne. Rappelez-vous que php -v rapporte le binaire CLI — la version qui sert votre site est celle du pool FPM, alors exécutez aussi php-fpm8.1 -v ou listez /etc/php/ pour voir les branches installées. Avant de changer de branche, passez par la vérification de compatibilité des extensions lors d’une montée de version PHP.

4. Faites de même pour la base de données.

mysql -V

mysql  Ver 15.1 Distrib 10.6.18-MariaDB, for debian-linux-gnu (x86_64)

Notez la branche et trouvez sa date de fin de vie. Les montées majeures de base sont celles que les équipes reportent le plus longtemps, parce qu’elles exigent un vrai plan de retour arrière.

5. Prouvez que le TLS se renouvelle au lieu de le supposer.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
systemctl list-timers --all --no-pager | grep -iE 'certbot|acme'

notBefore=Aug  3 04:11:02 2026 GMT
notAfter=Nov  1 04:11:01 2026 GMT
Tue 2026-09-09 23:12:00 UTC 10h left Tue 2026-09-09 05:31:04 UTC 7h ago certbot.timer certbot.service

Un certificat valide sans minuterie de renouvellement derrière lui est une panne datée, pas un montage qui fonctionne.

6. Restaurez une sauvegarde, ne vous contentez pas de la lister. C’est l’étape que tout le monde saute, et la seule qui produit une preuve.

sudo mysql -e "CREATE DATABASE restore_test CHARACTER SET utf8mb4;"
time gunzip -c /var/backups/site-2026-09-08.sql.gz | sudo mysql restore_test
sudo mysql restore_test -e "SELECT option_value FROM wp_options WHERE option_name='siteurl'; SELECT COUNT(*) AS published FROM wp_posts WHERE post_status='publish';"

real    4m12.338s
user    0m21.702s
sys     0m6.115s
+---------------------+
| option_value        |
+---------------------+
| https://example.com |
+---------------------+
+-----------+
| published |
+-----------+
|      1842 |
+-----------+

Trois choses en ressortent : l’export s’importe proprement, les décomptes de lignes sont plausibles, et la restauration de la base prend quatre minutes — le plancher de votre temps de reprise, avant d’avoir touché un seul fichier. Confirmez aussi le volet fichiers avec tar -tzf /var/backups/files-2026-09-08.tar.gz | head, puis nettoyez avec sudo mysql -e "DROP DATABASE restore_test;". La procédure complète, y compris la moitié wp-content, est dans vérifier qu’une sauvegarde WordPress est vraiment restaurable.

7. Découvrez si quelque chose d’externe surveille le site.

sudo awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -5

  41229 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...
   8814 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
   2160 Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)
    944 Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bot.html)

Apache écrit dans /var/log/apache2/access.log sur Debian et Ubuntu, /var/log/httpd/access_log dans la famille RHEL. Un agent de surveillance apparaît comme un décompte régulier et ennuyeux. Si aucune ligne de ce genre n’existe, rien hors de la machine ne vérifie le site, et votre détection de panne se résume au premier client qui s’en aperçoit.

8. Lisez l’horaire censé faire tout cela.

sudo systemctl list-timers --all --no-pager | head -8
crontab -l 2>/dev/null; sudo crontab -l 2>/dev/null

NEXT                        LEFT     LAST                        PASSED        UNIT                    ACTIVATES
Tue 2026-09-09 23:12:00 UTC 10h      Tue 2026-09-09 05:31:04 UTC 7h ago        certbot.timer           certbot.service
Wed 2026-09-10 00:00:00 UTC 11h      Tue 2026-09-09 00:00:14 UTC 13h ago       logrotate.timer         logrotate.service
Wed 2026-09-10 06:14:31 UTC 17h      Tue 2026-09-09 06:11:02 UTC 6h ago        apt-daily-upgrade.timer apt-daily-upgrade.service
n/a                         n/a      Mon 2025-10-13 02:30:11 UTC 10 months ago site-backup.timer       site-backup.service
0 3 * * * /usr/local/bin/site-backup.sh >/dev/null 2>&1

Cherchez les tâches de sauvegarde, unattended-upgrades, logrotate et la minuterie de certificat — puis lisez la colonne LAST, pas la liste des noms d’unités. Les deux dernières lignes sont tout le propos : site-backup.timer n’a plus de prochaine exécution et s’est déclenchée pour la dernière fois il y a dix mois, et la crontab de root contient encore une sauvegarde à 3 h que personne ne surveille. La sauvegarde nocturne que tout le monde croit acquise s’est arrêtée en octobre sans rien dire. Une minuterie dont le dernier déclenchement remonte à dix mois est pire que pas de minuterie, parce que vous y croyiez.

Lire l’audit

Quatre réponses tranchent la question, et aucune ne porte sur des fonctionnalités.

Si vous franchissez les quatre portes et que root vous est vraiment nécessaire, restez auto-géré : vous l’exploitez correctement et une plateforme vous retirerait quelque chose que vous utilisez. Si root vous est nécessaire mais qu’un drapeau s’est levé, la colonne du milieu est la réponse honnête — gardez le serveur, et placez les correctifs, la vérification des sauvegardes et l’intervention hors heures sous un contrat d’infogérance WordPress avec quelqu’un dont le métier est de répondre. Si un drapeau s’est levé et que vous ne pouvez pas nommer ce que root vous apporte, une plateforme infogérée retire simplement un travail que vous aviez déjà cessé de faire.

Valider que ça fonctionne

Confirmez que le site lui-même est intact avant de tirer des conclusions de ce qui précède, et que votre base jetable a bien disparu :

sudo -u www-data wp core verify-checksums --path=/var/www/example.com
sudo mysql -e "SHOW DATABASES LIKE 'restore_test';"

Success: WordPress installs verify against checksums.

Un résultat vide à la seconde commande est correct : la base jetable n’existe plus. Si verify-checksums signale des fichiers du noyau modifiés, réglez cela avant toute décision d’hébergement ; vous regardez peut-être une compromission plutôt qu’une comparaison. L’ensemble des commandes est dans la référence des commandes WP-CLI.

Dépannage

apt list --upgradable est vide mais le noyau est vieux. unattended-upgrades installe les correctifs et personne n’a redémarré. Comparez uname -r au paquet linux-image le plus récent installé ; s’ils diffèrent, les correctifs sont sur le disque et pas en mémoire.

needs-restarting est introuvable sur AlmaLinux ou Rocky. Il vient du paquet dnf-utils (yum-utils sur les versions plus anciennes). Installez-le, puis utilisez needs-restarting -r pour le verdict de redémarrage et needs-restarting -s pour les services qui retiennent des bibliothèques périmées.

php -v contredit ce que le site rapporte. Vous lisez le binaire CLI. Vérifiez plutôt le pool FPM : ls /etc/php/ sur Debian et Ubuntu affiche toutes les branches installées, et la configuration du pool nomme celle vers laquelle votre hôte virtuel relaie. Un site peut servir en 8.2 pendant que php en ligne de commande est en 7.4.

Le test de restauration échoue sur la collation. Un export pris sur MySQL 8 et portant utf8mb4_0900_ai_ci n’importera pas dans MariaDB, qui ne connaît pas cette collation. Ce n’est pas une sauvegarde brisée : c’est une contrainte de portabilité qu’il faut connaître avant la nuit où vous en aurez besoin.

La minuterie certbot est active mais le certificat ne se renouvelle pas. Lancez sudo certbot renew --dry-run. Le renouvellement échoue le plus souvent sur un défi HTTP-01 qu’une nouvelle règle de redirection ou une politique WAF bloque désormais, et il échoue en silence parce que personne ne lit la sortie.

Quand ce n’est pas la bonne approche

Cette page compare des modèles d’exploitation, pas des fournisseurs — évaluer la liste de fonctions d’une plateforme précise ou son outillage de restauration est un exercice distinct. Elle suppose aussi une installation WordPress unique et de taille ordinaire ; un parc de deux cents sites change complètement l’arithmétique, parce qu’un travail par site trivial une fois devient tout le métier à l’échelle.

Si votre site est petit, presque statique, rarement mis à jour et ne génère aucun revenu, rien de tout cela n’a besoin d’être tranché. Laissez-le où il est, gardez une sauvegarde hors serveur, et mettez votre attention ailleurs. L’audit ci-dessus ne rapporte que si une panne vous coûte quelque chose de réel.

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.