Auto-héberger WordPress donne une impression très simple : le site tourne sur une machine que l’on administre, donc tout nous appartient et tout reste sous notre contrôle.
La réalité est plus nuancée. Le contenu et la base peuvent se trouver sur le serveur, tandis que les polices viennent d’un service externe, les statistiques d’un autre, les commentaires d’une extension, les vidéos d’une plateforme et les sauvegardes d’un stockage que l’on ne surveille jamais.
À l’inverse, utiliser un service tiers ne signifie pas forcément abandonner toute maîtrise. On peut choisir ce qui lui est transmis, documenter le contrat, prévoir une exportation et conserver un plan de remplacement.
Le contrôle n’est donc pas un bouton activé par l’installation de WordPress. C’est une chaîne. Elle est aussi solide que sa couche la moins comprise.
J’ai déjà expliqué ce que l’auto-hébergement d’un blog implique au quotidien. Ici, l’angle est différent : je dresse la carte des dépendances, de leur propriétaire et du plan de sortie à tester pour chacune.
La réponse courte
Avec un WordPress auto-hébergé, on peut généralement choisir ou administrer :
- le domaine et sa zone DNS ;
- le serveur et son système ;
- le serveur web, PHP et la base de données ;
- les fichiers de WordPress ;
- le thème et les extensions ;
- les contenus et médias ;
- les comptes et permissions ;
- les journaux ;
- les sauvegardes ;
- les intégrations tierces et le code publicitaire.
On ne contrôle jamais totalement :
- les vulnérabilités encore inconnues ;
- le navigateur et le réseau du visiteur ;
- les changements d’un moteur de recherche ;
- la disponibilité d’un service externe ;
- le matériel et l’électricité en amont ;
- les décisions d’un registraire ou d’un fournisseur ;
- ce qu’une extension distante modifie après sa mise à jour ;
- le comportement d’un lecteur après l’export d’un contenu.
L’auto-hébergement permet surtout de choisir les dépendances, observer davantage de couches et préparer une sortie. Il augmente en même temps la responsabilité de les maintenir.
Dessiner la chaîne complète
Avant de parler de souveraineté ou d’indépendance, listez les couches nécessaires à l’affichage d’une page.
visiteur
↓
DNS et nom de domaine
↓
réseau, pare-feu et terminaison TLS
↓
serveur web
↓
PHP
↓
WordPress, thème et extensions
↓
base de données et fichiers médias
↓
services tiers, polices, vidéos, statistiques, publicité
Chaque flèche peut devenir un point de panne, de fuite de données ou de dépendance commerciale.
Une page qui semble « locale » dans l’administration peut déclencher dix requêtes externes dans le navigateur du visiteur.
Le nom de domaine
Le domaine constitue l’adresse durable du site, mais il dépend d’un registraire, d’un registre et d’une configuration DNS.
Ce que l’on peut maîtriser
- choix du registraire ;
- coordonnées du titulaire ;
- renouvellement ;
- verrouillage contre le transfert ;
- double authentification ;
- serveurs DNS ;
- enregistrements du domaine ;
- plan de transfert vers un autre prestataire.
Ce qui peut encore échapper
- panne du prestataire ;
- expiration après un problème de paiement ou d’adresse e-mail ;
- modification imposée par le registre ;
- erreur de configuration DNS ;
- compromission du compte ;
- délai de propagation des changements.
Conservez hors du serveur WordPress :
- identité du registraire ;
- date de renouvellement ;
- procédure de récupération ;
- export ou copie de la zone DNS ;
- code de transfert lorsqu’il est délivré ;
- adresse de contact à jour.
Le domaine ne doit pas dépendre de la seule boîte e-mail hébergée sur le domaine lui-même. En cas de panne globale, la récupération deviendrait circulaire.
Le réseau et le chiffrement
Le visiteur doit atteindre le bon serveur et recevoir un certificat valide. Let’s Encrypt rappelle le fonctionnement général de ses certificats automatisés et les différents types de défis utilisés pour prouver le contrôle d’un domaine. Documenter le défi retenu évite de découvrir trop tard que le renouvellement dépend d’un port, d’un DNS ou d’un prestataire oublié.
La couche comprend selon l’architecture :
- routeur ou pare-feu ;
- redirection de ports ;
- adresse publique ;
- DNS dynamique éventuel ;
- proxy inverse ;
- certificat TLS ;
- protection contre les abus ;
- fournisseur d’accès ou centre de données.
Le contrôle utile
Il ne consiste pas à ouvrir tous les ports puis installer un plugin de sécurité. Il consiste à réduire la surface : seuls les services nécessaires sont exposés, les accès d’administration sont protégés et les journaux permettent de comprendre les tentatives.
La dépendance cachée
Un proxy, un CDN ou un service de protection peut améliorer disponibilité et sécurité. Il voit aussi une partie du trafic et peut devenir indispensable au fonctionnement du site.
Documentez :
- ce qu’il traite ;
- ce qu’il conserve ;
- comment le désactiver ;
- quelle adresse doit être restaurée dans le DNS ;
- comment renouveler les certificats sans lui.
Le serveur et son système
Administrer le système donne accès aux mises à jour, comptes, services, disques, journaux et sauvegardes. Cette liberté devient une dette si personne ne sait quelles versions sont encore maintenues.
Inventaire minimal
- distribution et version ;
- noyau ;
- architecture ;
- espace disque ;
- mémoire ;
- services actifs ;
- ports en écoute ;
- comptes administrateurs ;
- tâches planifiées ;
- emplacement des journaux ;
- méthode de mise à jour ;
- date et méthode de restauration testée.
Un serveur « qui tourne depuis dix ans » peut être un signe de stabilité ou un signe qu’aucune dépendance n’a été revue depuis dix ans.
Ce que l’on ne doit pas mélanger
Migration du système, montée majeure de PHP, mise à jour de WordPress, changement de thème et publication de nouveaux articles ne doivent pas former une seule intervention.
Séparer les fenêtres permet de tester et de revenir en arrière.
Le serveur web
Apache, Nginx ou un autre serveur web reçoit les requêtes, applique des règles et sert les fichiers.
Les points à connaître :
- hôtes virtuels ;
- redirections HTTP vers HTTPS ;
- URL canonique avec ou sans
www; - règles de réécriture WordPress ;
- limites de taille et délais ;
- en-têtes de sécurité ;
- compression ;
- cache ;
- journaux d’accès et d’erreur ;
- permissions des fichiers.
Modifier .htaccess dans l’urgence sans conserver la version précédente peut rendre tout le site inaccessible. Une règle doit être testée, commentée et réversible.
Le plugin WordPress ne remplace pas l’observation du journal du serveur web lorsqu’une requête n’atteint même pas PHP.
PHP
WordPress et ses extensions s’exécutent dans une version de PHP avec ses modules, sa configuration et ses limites.
Les choix sous contrôle
- version installée ;
- modules ;
- mémoire ;
- durée maximale ;
- taille des téléversements ;
- journalisation des erreurs ;
- gestionnaire de processus ;
- cache d’opcode ;
- séparation éventuelle entre sites.
La limite réelle
Une ancienne extension peut bloquer la montée de PHP. Une version de PHP maintenue peut révéler des avertissements qu’un code ancien cachait.
La bonne procédure n’est pas de désactiver toutes les erreurs en production et espérer. Elle consiste à :
- cloner le site ;
- relever les extensions et le thème ;
- tester la nouvelle version ;
- consulter les journaux ;
- corriger ou remplacer les composants incompatibles ;
- vérifier administration, formulaires, médias, tâches planifiées et front public ;
- prévoir le retour à l’environnement précédent.
La base de données
La base contient articles, pages, réglages, comptes, commentaires, métadonnées et une partie de la configuration des extensions.
Posséder le fichier ou le serveur ne suffit pas. Il faut savoir :
- exporter la base ;
- vérifier que l’export n’est pas vide ;
- chiffrer et protéger la sauvegarde ;
- restaurer sur un environnement de test ;
- adapter les URL lors d’une migration sans casser les données sérialisées ;
- identifier les tables ajoutées par les extensions ;
- surveiller leur croissance ;
- supprimer les données seulement avec une politique claire.
Les identifiants
Le compte utilisé par WordPress ne devrait disposer que des droits nécessaires à sa base. Son mot de passe ne doit pas apparaître dans un article, une capture ou un dépôt public.
Le fichier de configuration contenant ces accès doit être inclus dans le plan de restauration, mais protégé séparément.
Les fichiers WordPress
Le cœur, les thèmes, les extensions, les téléversements et les fichiers personnalisés n’ont pas la même valeur.
Réinstallable
Le cœur de WordPress et une extension publique peuvent généralement être récupérés depuis leur source officielle, à condition de connaître la version.
Irremplaçable ou spécifique
- médias originaux ;
- thème enfant ;
- extension personnalisée ;
- configuration serveur ;
- fichiers non versionnés ;
- code ajouté dans un widget ;
- clés et secrets ;
- traductions ou modifications locales ;
- fichiers de preuve liés aux articles.
Une sauvegarde complète doit distinguer ces catégories pour accélérer la restauration.
Le cœur de WordPress
Contrôler les fichiers ne donne pas une bonne raison de les modifier.
Une modification dans wp-includes ou wp-admin sera écrasée par une mise à jour et rendra les écarts difficiles à auditer.
Privilégiez :
- API officielles ;
- hooks ;
- thème enfant ;
- mini-plugin documenté ;
- configuration serveur ;
- contribution au projet lorsque le changement doit être général.
Le contrôle durable consiste à étendre proprement le système, pas à empêcher ses mises à jour. Les prérequis officiels de WordPress donnent le socle technique attendu, tandis que le guide de durcissement de WordPress rappelle que la sécurité dépend aussi du serveur, des permissions, des mises à jour et des accès.
Le thème
Le thème contrôle une grande partie du rendu : modèles, navigation, typographie, zones de widgets et parfois constructeur de pages.
Questions à documenter
- thème actif et version ;
- thème parent ou enfant ;
- licence et accès aux mises à jour ;
- personnalisations stockées en base ;
- code ajouté dans les fichiers ;
- dépendance à un constructeur ;
- modèles de pages particuliers ;
- procédure de retour au thème précédent ;
- captures de référence ordinateur et mobile.
Un contenu enfermé dans des shortcodes propriétaires peut être difficile à migrer même si la base vous appartient.
Testez ce qui reste lisible lorsque l’extension ou le constructeur est désactivé sur une copie.
Les extensions
Chaque extension ajoute une fonction et une dépendance.
Pour chacune, conservez :
- fonction réelle ;
- propriétaire ou éditeur ;
- version ;
- date de dernière mise à jour ;
- données créées ;
- tâches planifiées ;
- services distants ;
- méthode de désinstallation ;
- solution de remplacement ;
- conséquence de sa désactivation.
Active ne signifie pas utile
Une extension peut rester active parce qu’elle l’a toujours été. L’audit doit prouver son utilité actuelle.
Inactive ne signifie pas inoffensive
Un code installé mais désactivé occupe de l’espace, complique l’inventaire et peut conserver des données. Selon la vulnérabilité et l’exposition, il peut encore mériter une mise à jour ou une suppression contrôlée.
La suppression ne doit intervenir qu’après sauvegarde et vérification des données qu’elle gère.
Le contenu
Les articles, pages et médias représentent la partie la plus visible de la maîtrise éditoriale.
Pour qu’ils restent portables :
- utiliser un format HTML aussi propre que possible ;
- limiter les shortcodes propriétaires ;
- conserver les images originales ;
- utiliser des légendes et textes alternatifs ;
- exporter périodiquement le contenu ;
- documenter les redirections ;
- maintenir les URL importantes ;
- conserver les sources et preuves des mises à jour sensibles.
Un export WordPress ne remplace pas toujours la sauvegarde des fichiers médias, du thème et des réglages.
Les comptes et permissions
Être propriétaire du serveur ne justifie pas que chaque compte soit administrateur.
Contrôlez :
- comptes humains ;
- comptes de service ;
- rôles ;
- abonnés anciens ;
- double authentification ;
- sessions actives ;
- mots de passe d’application ;
- accès FTP, SSH et base ;
- procédure de départ ou de récupération.
L’accès WordPress, le compte du domaine et l’administration serveur doivent disposer de moyens de récupération distincts et à jour.
Les sauvegardes
Le contrôle le plus concret est la capacité à reconstruire le site ailleurs. La documentation officielle distingue la sauvegarde de la base, des fichiers et la nécessité de conserver plusieurs copies ; une extension qui annonce « sauvegarde terminée » ne remplace pas un test de restauration.
Une sauvegarde utile contient
- base de données ;
- fichiers médias ;
- thème et personnalisations ;
- extensions spécifiques ;
- configuration WordPress ;
- configuration serveur ;
- certificats ou procédure de renouvellement ;
- zone DNS ou relevé ;
- versions ;
- secrets dans un stockage protégé ;
- documentation de restauration.
Les trois séparations importantes
- copie différente du disque de production ;
- emplacement différent du serveur de production ;
- accès différent du compte principal compromis.
Le test
Restaurer sur une préproduction, vérifier les URL, se connecter, ouvrir plusieurs articles, tester les médias et les formulaires, puis documenter le temps nécessaire.
Une archive jamais extraite ni restaurée reste une promesse.
Les journaux
Auto-héberger permet de conserver les journaux du système, du serveur web, de PHP, de WordPress et des outils de sécurité.
Cette visibilité crée aussi une responsabilité :
- limiter la durée ;
- contrôler l’espace disque ;
- protéger les données personnelles ;
- documenter les finalités ;
- éviter d’enregistrer les mots de passe, corps de formulaire ou cookies sans nécessité ;
- synchroniser l’heure ;
- prévoir une rotation ;
- restreindre les accès.
Collecter davantage n’est pas toujours mieux. Il faut collecter ce qui permet de diagnostiquer et sécuriser, pendant une durée justifiable.
L’e-mail
Les notifications de commentaires, réinitialisations de mot de passe, formulaires et newsletters dépendent d’une chaîne souvent oubliée.
Questions à poser :
- WordPress envoie-t-il directement ou via un relais ?
- qui héberge les boîtes ?
- SPF, DKIM et DMARC sont-ils configurés ?
- les erreurs d’envoi sont-elles visibles ?
- les abonnés peuvent-ils se désinscrire ?
- les listes et preuves de consentement sont-elles exportables ?
- que se passe-t-il si le prestataire disparaît ?
Une publication éditoriale peut déclencher automatiquement une newsletter ou une notification Discord. Cette conséquence doit être testée avant une série de brouillons et de corrections.
Les services tiers
Une vidéo YouTube, un live Twitch, une police, une carte, un formulaire, un antispam, une statistique ou une publicité peut contacter un tiers.
Cartographie minimale
| Service | Donnée transmise | Moment du chargement | Base ou consentement | Méthode de retrait |
|---|---|---|---|---|
| mesure d’audience | à déterminer | avant ou après choix | à documenter | script ou extension |
| publicité | à déterminer | avant ou après choix | consentement selon le cas | bloc ou widget |
| vidéo intégrée | adresse réseau et navigateur possibles | au chargement ou au clic | à documenter | façade ou lien |
| antispam | commentaire et données techniques possibles | lors de l’envoi | à documenter | réglage ou extension |
| newsletter | adresse et statut d’abonnement | inscription et envoi | consentement | export et désabonnement |
Remplacez « à déterminer » par les données réellement observées. Une politique de confidentialité copiée ne remplace pas cette cartographie.
Le consentement
Posséder le serveur ne dispense pas d’obtenir un choix lorsque des traceurs ou services l’exigent. WordPress propose un point de départ sur les outils et responsabilités liés à la vie privée, mais chaque site doit cartographier ses traitements réels. Sur BlackFury, la politique de confidentialité décrit les catégories de services et le moyen de revenir sur ses préférences.
Une plateforme de consentement doit être reliée aux scripts réels :
- aucun chargement anticipé des catégories concernées ;
- accepter, refuser et personnaliser ;
- choix conservé pour une durée justifiée ;
- possibilité de revenir sur le choix ;
- comportement identique sur mobile ;
- test avant choix, après refus et après acceptation.
Le bandeau n’est pas la preuve. Le panneau réseau du navigateur montre ce qui est réellement chargé.
Ce qui reste hors de contrôle
Les moteurs de recherche
On peut fournir un contenu utile, des URL cohérentes et un sitemap. On ne choisit pas la date d’exploration, le classement ni la façon dont chaque résultat sera présenté.
Les navigateurs et appareils
Une page peut se comporter différemment selon les extensions, protections, tailles d’écran et réglages d’accessibilité.
Les logiciels en amont
WordPress, PHP, la distribution, les bibliothèques et le matériel contiennent du code que l’on ne contrôle pas entièrement. On peut choisir les versions, suivre les alertes, isoler et mettre à jour.
Les services externes
Une API peut changer, un réseau social fermer une fonctionnalité et une publicité refuser le site. Le plan doit permettre de continuer sans que le contenu principal disparaisse.
L’erreur humaine
Un accès root et une sauvegarde mal identifiée suffisent à faire beaucoup de dégâts. La documentation, la préproduction, le principe du moindre privilège et les retours arrière réduisent ce risque sans le supprimer.
Mesurer le contrôle réel
Attribuez à chaque couche une note simple.
| Niveau | Signification |
|---|---|
| 0 | dépendance inconnue, aucun accès ni export |
| 1 | service identifié, sortie incertaine |
| 2 | configuration connue, sauvegarde ou export disponible |
| 3 | restauration ou remplacement réellement testé |
Une couche n’atteint pas le niveau 3 parce qu’une documentation promet un export. Il faut l’avoir utilisé.
Questions de contrôle
- Qui possède le compte ?
- Où sont les données ?
- Qui peut les lire ?
- Quelle dépendance externe existe ?
- Comment exporter ?
- Comment restaurer ?
- Comment remplacer ?
- Combien de temps l’opération prend-elle ?
- Quelle preuve montre que le plan fonctionne ?
Une feuille de route raisonnable
Étape 1 : inventaire
Lister domaine, DNS, serveur, versions, WordPress, thème, extensions, comptes, scripts tiers et sauvegardes.
Étape 2 : récupération
Vérifier les accès, coordonnées, doubles authentifications et moyens de secours.
Étape 3 : sauvegarde
Créer une sauvegarde complète, vérifier son contenu et restaurer sur une copie.
Étape 4 : conformité
Cartographier les données, publier les pages nécessaires et relier le consentement aux scripts réels.
Étape 5 : maintenance
Mettre à jour une couche à la fois sur préproduction, puis surveiller les journaux et fonctions essentielles.
Étape 6 : portabilité
Tester l’export, réduire les formats propriétaires et documenter le remplacement des services externes.
Étape 7 : revue périodique
Reprendre l’inventaire après chaque changement majeur et au minimum à une fréquence décidée. La documentation périme comme le logiciel.
Le verdict
WordPress auto-hébergé donne un contrôle réel sur beaucoup de couches, mais il ne les rend pas automatiquement maîtrisées.
La preuve n’est pas le logo de la distribution ni l’accès administrateur. C’est la capacité à expliquer le chemin d’une donnée, mettre à jour une dépendance, restaurer le site et remplacer un service sans perdre le contenu.
L’autonomie n’est pas l’absence de dépendances. C’est la capacité à les choisir, les comprendre et les quitter.
Sources officielles et portée de cette cartographie
Cette cartographie décrit les couches techniques et organisationnelles à vérifier ; elle ne remplace ni la documentation de votre hébergeur, ni celle de votre distribution, ni un conseil juridique adapté aux traitements réellement observés.
