Quand tu arrives sur BlackFury, tu vois un site WordPress. Des articles, des images, quelques vidéos, des commentaires et un vieux thème qui a traversé pas mal d’années. Rien de très exotique en apparence.
Derrière, en revanche, le site ne repose pas simplement sur un abonnement acheté chez un hébergeur qui s’occupe de tout. Il tourne sur une infrastructure que je gère moi-même, avec Debian, un serveur web, PHP, une base de données, WordPress et toutes les petites couches que l’on finit par oublier lorsque tout fonctionne correctement.
Et c’est justement là que l’auto-hébergement devient intéressant : lorsqu’il fonctionne, il se fait oublier. Lorsqu’une couche vieillit ou casse, tu te souviens très vite que tu es à la fois l’auteur, l’éditeur, l’administrateur système et le support technique.
Alors, est-ce que cela vaut encore le coup d’héberger soi-même son blog en 2026 ? Pour moi, oui. Mais certainement pas parce que ce serait la solution la plus simple.
Un site WordPress, ce n’est pas seulement WordPress
On parle souvent de WordPress comme s’il s’agissait d’un bloc unique. En réalité, le CMS n’est que la partie la plus visible d’une chaîne beaucoup plus longue.
Il faut d’abord un nom de domaine et une configuration DNS correcte. Il faut ensuite une machine ou un serveur, un système d’exploitation maintenu, un serveur web, PHP, une base de données, un certificat HTTPS et un système d’envoi d’e-mails. WordPress arrive par-dessus, suivi du thème, des extensions, des médias, des tâches planifiées, des outils de sécurité et des sauvegardes.
Chaque couche possède son propre calendrier, ses propres mises à jour et ses propres incompatibilités potentielles.
Le site peut donc sembler parfaitement fonctionnel tout en accumulant une dette technique invisible. Une ancienne version de PHP continue de servir les pages. Une extension n’est plus vraiment maintenue mais ne provoque pas encore d’erreur. Une tâche planifiée prend du retard. Une sauvegarde existe peut-être, mais personne n’a essayé de la restaurer depuis des années.
Tant que l’accueil s’affiche, la tentation est grande de ne rien toucher.
Le vieillissement ne prévient pas toujours
Debian possède un cycle de vie assez confortable, mais il n’est évidemment pas infini. Une version bénéficie d’abord du support normal, puis du support longue durée avant d’arriver en fin de vie.
Au moment où j’écris ces lignes, Debian 11 « Bullseye » arrive au terme de son support LTS le 31 août 2026. Debian 12 « Bookworm » est passée sous la responsabilité de l’équipe LTS et doit recevoir des correctifs jusqu’au 30 juin 2028. Debian 13 « Trixie » est la version stable actuelle et son cycle LTS doit aller jusqu’en 2030.
Ces dates ne signifient pas que tous les paquets installés sont automatiquement couverts. Debian recommande l’outil debian-security-support pour repérer les composants qui sortent du périmètre LTS. C’est un détail important sur un serveur WordPress : la distribution peut encore être maintenue alors qu’un paquet critique utilisé par le site ne l’est plus de la même manière.
La première étape n’est donc pas de choisir une nouvelle version au hasard, mais de relever la version exacte actuellement utilisée par le serveur BlackFury. La décision dépend de ce point de départ vérifié, pas d’un souvenir.
Cette différence est importante. Si le serveur tourne encore sous Debian 11, la migration devient urgente. S’il est déjà sous Debian 12, il existe davantage de marge, même si les autres composants peuvent rester en retard.
Debian recommande aux machines encore sous Bullseye de passer d’abord à Debian 12, puis à Debian 13. Sauter directement une version majeure n’est donc pas le raccourci à improviser sur un serveur public : les notes de publication de chaque étape, les dépôts et les paquets devenus obsolètes doivent être examinés.
Dans le cas de BlackFury, l’administration WordPress signale aussi l’utilisation de PHP 7.4.33, une branche qui ne reçoit plus de correctifs de sécurité. Cela ne signifie pas que le site va exploser demain matin. Cela signifie que le temps ne travaille plus pour lui.
Pourquoi je ne clique pas simplement sur « Tout mettre à jour »
WordPress propose un gros bouton rassurant. Plusieurs extensions disposent d’une nouvelle version, le cœur du CMS aussi, et un thème attend son tour. Il serait tentant de sélectionner toutes les cases et de laisser la magie opérer.
Sur un site récent et bien sauvegardé, cela peut très bien se passer. Sur un site qui existe depuis 2017, qui possède des extensions historiques, un thème Premium, des intégrations avec Jetpack, un forum et différents contenus incorporés, je préfère éviter la roulette russe.
Le problème n’est pas seulement de savoir si WordPress accepte une version récente de PHP. Il faut vérifier si le thème la supporte, si le constructeur de pages ne change pas la mise en forme, si les extensions de sécurité cohabitent toujours, si les tâches planifiées repartent et si les anciennes pages s’affichent encore correctement.
Une mise à jour du système peut modifier PHP. Une mise à jour de PHP peut rendre une extension incompatible. Une extension cassée peut empêcher l’accès à l’administration. Et si la seule sauvegarde disponible se trouve sur le même disque que le serveur, elle risque de ne pas être d’un grand secours.
Ce n’est donc pas de la peur. C’est une question d’ordre et de méthode.
Ce que l’auto-hébergement m’apporte encore
La première chose est le contrôle. Je décide de l’organisation du serveur, des outils installés, des sauvegardes, des journaux et des limites que je veux imposer. Je peux accéder aux fichiers, à la base et aux configurations sans attendre qu’une interface commerciale m’autorise à cliquer quelque part.
Je garde aussi une vraie liberté de migration. Le domaine, les contenus et la base ne sont pas enfermés dans une plateforme propriétaire. Si je veux déplacer le site, changer de serveur ou reconstruire une installation, le travail peut être pénible, mais les briques restent accessibles.
L’auto-hébergement est également une formidable machine à apprendre. Administrer un site réel oblige à comprendre les relations entre le réseau, le système, le serveur web, PHP, la base et l’application. Les erreurs ne restent pas dans un laboratoire : elles touchent un service que des lecteurs utilisent réellement. Cela rend prudent, parfois après avoir appris la prudence de la mauvaise façon.
Enfin, il y a une satisfaction difficile à expliquer à quelqu’un qui n’aime pas bricoler. Voir un service fonctionner sur une machine que l’on administre soi-même reste plaisant. Un peu comme conserver une vieille moto en état plutôt que signer un bon de commande dès qu’un voyant s’allume.
Ce que cela coûte réellement
Le coût principal n’est pas forcément la machine ou l’électricité. C’est l’attention.
Il faut surveiller les mises à jour, lire les alertes, vérifier les sauvegardes, renouveler les certificats lorsque l’automatisation échoue, contrôler l’espace disque, comprendre pourquoi une tâche cron ne se lance plus et réagir lorsque les robots décident de tester la page de connexion plusieurs milliers de fois.
Il faut aussi accepter que tout ce temps n’est pas consacré à écrire. Un blog auto-hébergé peut facilement devenir un projet d’administration système avec quelques articles au milieu. C’est précisément ce que je veux corriger aujourd’hui : remettre le contenu au premier plan sans négliger la machine qui le fait vivre.
La sécurité fait partie du prix. WordPress rappelle que le maintien à jour du cœur, des thèmes et des extensions reste l’une des mesures les plus importantes. Les sauvegardes doivent inclure les fichiers et la base, être régulières et, idéalement, exister dans un emplacement distinct du serveur principal.
Une sauvegarde que l’on n’a jamais restaurée est surtout une hypothèse optimiste.
La méthode que je veux appliquer à BlackFury
La première étape est l’inventaire. Version de Debian, dépôts configurés, version de PHP, serveur web, base de données, tâches planifiées, certificats, extensions actives, thème, espace disque et services annexes. Rien ne doit dépendre uniquement de ma mémoire.
La deuxième étape est la sauvegarde complète : fichiers WordPress, base, configuration du serveur, certificats, tâches planifiées et tout ce qui permet de reconstruire le service. Cette sauvegarde doit être copiée ailleurs et faire l’objet d’un test de restauration.
La troisième étape est de créer une copie de travail. Le but est de tester la montée de version du système, PHP, WordPress et les extensions sans transformer le site public en banc d’essai. Même une copie locale imparfaite permet déjà de repérer les erreurs fatales, les pages cassées et les incompatibilités les plus évidentes.
Ensuite seulement vient la migration, couche par couche. On modifie un élément, on teste, on consulte les journaux et on vérifie les fonctions importantes. Accueil, administration, connexion, commentaires, newsletter, médias, tâches planifiées et affichage mobile doivent faire partie de la vérification.
Enfin, il faut observer. Une page qui s’ouvre juste après la mise à jour ne prouve pas que tout fonctionne. Certaines erreurs apparaissent après le passage d’une tâche planifiée, l’envoi d’un e-mail, la publication d’un article ou la visite d’un robot.
Et surtout, chaque étape doit prévoir un retour en arrière clair. Le moment de réfléchir au plan de secours n’est pas celui où la base refuse déjà de démarrer.
Auto-héberger, oui, mais en connaissance de cause
Je ne conseillerais pas l’auto-hébergement à quelqu’un qui veut uniquement écrire et ne jamais entendre parler de mises à jour système. Un hébergeur géré ou une plateforme correctement choisie sera beaucoup plus confortable.
En revanche, pour quelqu’un qui aime comprendre, garder le contrôle et construire son propre environnement, l’expérience reste passionnante. Elle oblige simplement à accepter que la liberté technique s’accompagne d’une responsabilité technique.
BlackFury va continuer à être hébergé de cette manière. Le serveur doit évoluer, la pile logicielle doit être remise à niveau et les sauvegardes doivent devenir une preuve plutôt qu’une supposition. Je documenterai cette remise à plat au fur et à mesure, y compris les erreurs et les choix qui ne fonctionneront pas comme prévu.
Parce qu’au fond, ce serveur ressemble assez bien au reste du site : il a vécu, il traîne quelques vieilles pièces, mais il n’est pas question de le jeter simplement parce qu’il demande un peu d’entretien.
