Le tableau de bord WordPress a une façon assez polie d’annoncer les mauvaises nouvelles. Il affiche un encadré, ajoute quelques couleurs et explique que la version de PHP utilisée est obsolète. Le site continue pourtant de fonctionner, les lecteurs voient toujours les articles et l’on pourrait facilement repousser le problème de quelques mois.
Sur BlackFury, l’avertissement concerne PHP 7.4.33. Cette branche est arrivée en fin de vie depuis longtemps et ne reçoit plus de correctifs de sécurité. Le système Debian installé sur le serveur approche lui aussi d’une étape importante de son cycle de support.
Il faut donc migrer. Mais pas ce soir, pas avec un apt full-upgrade lancé entre deux cafés et surtout pas sans avoir préparé le retour en arrière.
Cet article n’est pas un script à copier-coller aveuglément. C’est la méthode que je veux utiliser pour savoir exactement ce qui tourne, ce qui doit être sauvegardé et ce qu’il faudra tester avant de toucher au serveur public.
Ce plan prolonge mon retour sur ce que signifie réellement auto-héberger un blog WordPress en 2026. L’autre article décrit les responsabilités quotidiennes de l’hébergeur ; ici, je me concentre sur une opération précise : sortir d’une pile Debian et PHP vieillissante sans transformer la production en terrain d’essai.
Première règle : connaître le vrai point de départ
Avant de choisir une destination, il faut arrêter de se fier à ses souvenirs. « Je crois que c’est Debian 11 » ou « PHP doit être installé depuis les dépôts » ne sont pas des informations suffisantes pour préparer une migration.
D’abord, les premières commandes servent uniquement à établir l’inventaire :
cat /etc/os-release
cat /etc/debian_version
uname -m
uname -r
php -v
php -m
df -h
free -h
systemctl --failed
Elles permettent de relever la version de Debian, l’architecture, le noyau, la version de PHP, les modules chargés, l’espace disponible, la mémoire et les services déjà en échec.
Il faut ensuite identifier le serveur web et la base de données :
apache2 -v
nginx -v
mariadb --version
mysql --version
Certaines commandes répondront simplement qu’elles n’existent pas. C’est justement le but : déterminer ce qui est réellement installé sans deviner.
Ensuite, je compléterai cet inventaire avec les virtual hosts, les certificats, les tâches cron, les unités systemd personnalisées, les pare-feu, les sauvegardes et les dépôts APT supplémentaires. Je ne publierai pas les sorties intégralement, car elles peuvent révéler des noms de machine, des chemins, des domaines internes ou d’autres détails intéressants pour quelqu’un qui n’a rien à faire sur le serveur.
Debian ne se saute pas comme une marche d’escalier
Les notes officielles de Debian définissent des chemins de mise à niveau précis. La migration vers Debian 12 est prévue depuis Debian 11. La migration vers Debian 13 est prévue depuis Debian 12.
Ainsi, si BlackFury tourne sous Debian 11, le chemin normal sera donc :
Debian 11 → Debian 12 → vérifications → Debian 13
Cependant, il ne s’agit pas d’enchaîner les deux montées de version dans la même session. Chaque étape doit devenir un système stable et vérifié avant de préparer la suivante.
Si le serveur tourne déjà sous Debian 12, le travail commence directement par la préparation vers Debian 13. Debian indique qu’une mise à niveau vers Trixie implique notamment un nouveau noyau et donc un redémarrage. Lorsqu’un serveur est administré à distance, il faut prévoir le cas où il ne reviendrait pas correctement après ce redémarrage.
Dans les deux cas, la version de départ relevée pendant l’inventaire doit être inscrite dans le plan de migration. C’est elle qui détermine les notes de publication à suivre, les dépôts à préparer et le chemin de retour arrière.
Vérifier APT avant de lui confier le serveur
Une installation Debian ancienne n’est pas toujours une Debian « pure ». Des dépôts ont pu être ajoutés pour PHP, une base de données, un outil de sauvegarde ou un paquet qui n’existait pas dans la version stable.
Par conséquent, avant toute migration, je veux relever :
- les fichiers dans
/etc/apt/sources.listet/etc/apt/sources.list.d/; - les paquets provenant de dépôts tiers ;
- les paquets retenus avec
apt-mark hold; - les paquets dans un état incomplet ;
- les configurations locales et fichiers laissés par d’anciennes mises à jour.
Quelques contrôles non destructifs et disponibles sur la plupart des installations :
apt-mark showhold
dpkg --audit
apt list --installed
De plus, la liste complète est longue, mais elle fournit une base que l’on peut comparer aux dépôts et à apt-cache policy NOM_DU_PAQUET pour les composants sensibles.
Les notes de publication proposent aussi des recherches plus ciblées. Leur syntaxe dépend toutefois de la version d’APT et de la présence d’aptitude. Par exemple :
# Si aptitude est installé : paquets installés ne provenant pas de Debian
aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
# Paquets devenus obsolètes selon les dépôts actuellement configurés
apt list '~o'
Ces commandes ne répondent pas exactement à la même question et leur résultat change selon que les sources APT ont déjà été modifiées. Il faut donc reprendre la commande de la note de publication correspondant à la version de départ et noter à quel moment elle a été exécutée.
Enfin, je devrai étudier les résultats, pas les supprimer en bloc. Un paquet marqué comme non Debian peut être indispensable au site. Un paquet obsolète peut contenir une configuration que l’on voudra conserver. Les notes de Debian recommandent de traiter ces complications avant la montée de version, mais cela ne signifie pas de lancer une purge automatique sans comprendre ce qu’elle emporte.
PHP : viser une version maintenue, pas seulement une version qui démarre
WordPress recommande actuellement PHP 8.3 ou une version supérieure. Le CMS peut encore fonctionner sur certaines branches plus anciennes, mais « fonctionner » et « être raisonnablement sécurisé » ne veulent pas dire la même chose.
En août 2026, PHP 8.2 ne reçoit plus que des correctifs de sécurité jusqu’à la fin de l’année. PHP 8.3 reste couvert pour la sécurité jusqu’à fin 2027, PHP 8.4 jusqu’à fin 2028 et PHP 8.5 jusqu’à fin 2029.
En pratique, pour BlackFury, le choix ne se fera pas en prenant mécaniquement le numéro le plus élevé. Il dépendra de la version fournie par Debian, de WordPress, du thème Customizr Pro et des extensions réellement utilisées. Un environnement stable livré par la distribution est souvent plus simple à maintenir qu’une pile constituée de plusieurs dépôts tiers uniquement pour gagner un numéro de version.
Cependant, le passage depuis PHP 7.4 est important. Les erreurs peuvent venir de fonctions supprimées, de changements de typage, d’avertissements devenus plus stricts ou d’une extension serveur manquante. WordPress signale déjà l’absence des modules facultatifs imagick et intl. La migration sera l’occasion de construire une liste propre des modules nécessaires au lieu de reproduire aveuglément l’ancienne installation.
Une sauvegarde utile doit permettre de reconstruire
Copier seulement le dossier wp-content ne suffit pas. Sauvegarder uniquement la base non plus.
Concrètement, pour reconstruire BlackFury, il faut au minimum conserver :
- la base de données WordPress ;
- les fichiers du site, dont les médias, thèmes et extensions ;
wp-config.phpet les éventuels réglages placés hors de la racine web ;- la configuration du serveur web ;
- les versions et modules PHP ;
- les certificats et leur méthode de renouvellement ;
- les tâches cron et unités systemd personnalisées ;
- la configuration du pare-feu ;
- la liste des paquets installés ;
- les données et configurations du forum ou des autres services liés ;
- les éléments nécessaires à l’envoi d’e-mails.
D’ailleurs, Debian recommande notamment de sauvegarder /etc, les informations APT et la sélection des paquets avant une montée de version. De son côté, WordPress recommande de sauvegarder régulièrement les fichiers et la base dans un emplacement fiable.
Surtout, la copie doit sortir du serveur. Si la machine, le disque ou le système de fichiers devient inaccessible, une archive placée à côté du site ne constitue pas une solution de secours.
Enfin, il faut la restaurer au moins une fois. Le test peut se faire sur une machine isolée, avec un domaine local et des e-mails bloqués. Le but n’est pas d’obtenir un clone parfait dès le premier essai, mais de vérifier que l’on possède réellement les pièces nécessaires.
Construire un banc d’essai qui ne contacte personne
Une copie de préproduction doit être suffisamment proche du site réel pour révéler les incompatibilités, mais suffisamment isolée pour ne pas provoquer d’effets externes.
Elle ne doit pas :
- envoyer une newsletter aux abonnés ;
- publier sur Discord ou les réseaux sociaux ;
- déclencher des notifications client ;
- envoyer des données de statistiques comme s’il s’agissait du site public ;
- être indexée par les moteurs de recherche ;
- utiliser les mêmes tâches automatisées que la production sans contrôle.
Par conséquent, il faudra remplacer ou neutraliser les secrets, bloquer l’envoi d’e-mails, désactiver les intégrations sortantes et protéger l’accès au clone. Une copie de production contenant les vrais comptes et commentaires reste une copie de données personnelles ; nous devons la protéger avec le même sérieux que le site principal.
Tester par couches, pas seulement regarder l’accueil
Concrètement, le plan de test devra couvrir plusieurs niveaux.
Côté système
- aucun service essentiel en échec ;
- espace disque et mémoire suffisants ;
- pare-feu actif ;
- certificat HTTPS valide ;
- tâches cron exécutées ;
- journaux sans erreur répétitive majeure.
PHP et base de données
- modules PHP attendus chargés ;
- connexion à la base fonctionnelle ;
- absence d’erreurs fatales et d’avertissements massifs ;
- encodage et caractères accentués conservés ;
- performances comparées à l’ancienne pile.
Dans WordPress
- accueil, articles, catégories et pages ;
- connexion et administration ;
- création d’un brouillon sans publication ;
- téléversement d’un média de test ;
- commentaires et anti-spam ;
- recherche, liens permanents et flux RSS ;
- tâches planifiées ;
- affichage mobile ;
- intégrations Jetpack, YouTube, Twitch et Instagram ;
- fonctionnement du lien avec phpBB s’il est toujours utilisé.
Le site de santé WordPress devra être relancé après stabilisation. Il ne doit plus signaler PHP 7.4, et il faudra comprendre les nouvelles alertes plutôt que simplement les masquer.
Prévoir le retour en arrière avant la première modification
Pour chaque étape, il faut définir un critère d’abandon. Par exemple : administration inaccessible, erreurs fatales sur plusieurs pages, base non migrée, perte du renouvellement HTTPS ou absence d’accès après redémarrage.
Selon l’infrastructure, le retour en arrière peut prendre la forme d’un snapshot, d’une restauration complète ou d’un basculement vers l’ancienne machine. La méthode dépendra de l’infrastructure réelle. Ce qui compte est de savoir combien de temps elle prend, où se trouve la sauvegarde et comment vérifier que le service restauré n’écrit pas dans une base déjà modifiée par la nouvelle version.
La phrase « au pire, je restaurerai » n’est pas un plan. Un plan contient les commandes, les emplacements, les accès et le temps nécessaire — vérifiés avant l’incident.
Le vrai objectif : revenir à une maintenance normale
La migration n’est pas terminée lorsque Debian et PHP affichent un numéro récent. Elle est terminée lorsque le site peut à nouveau être maintenu sans opération exceptionnelle.
Ensuite, il faudra documenter la pile, automatiser les sauvegardes, vérifier périodiquement leur restauration, surveiller l’espace disque, planifier les correctifs et retirer les extensions ou thèmes devenus inutiles. Le tableau de bord devra cesser d’être une collection d’alertes que l’on ne regarde plus.
Je documenterai les étapes réelles lorsque la migration de BlackFury commencera. Les commandes exécutées, les incompatibilités rencontrées et les choix de versions feront l’objet d’articles séparés. Pour l’instant, la priorité est moins spectaculaire mais beaucoup plus importante : savoir exactement ce qui existe et être certain de pouvoir le reconstruire.
Parce que la meilleure mise à jour n’est pas celle qui affiche le plus vite « Terminé ». C’est celle qui permet au site de continuer à vivre le lendemain, avec ses articles, ses lecteurs et un administrateur qui a encore envie d’écrire.
