Installer WordPress sur Debian 11 ou Debian 12, ce n’est pas seulement lancer deux ou trois commandes au hasard. Derrière un simple blog ou un site vitrine, tu poses un vrai socle technique : serveur web, base de données, PHP, sécurité…
Le tout doit rester fiable, maintenable et assez souple pour encaisser les futures évolutions de ton projet. Qu’il s’agisse d’un petit site perso ou d’un futur e‑commerce qui va prendre du trafic, la façon dont tu prépares ton serveur dès le départ va clairement influencer la stabilité et les performances de ton WordPress.
Ce guide se concentre sur un scénario courant en 2026 : un serveur Debian 11 ou Debian 12, un choix entre Apache et Nginx, une base MariaDB ou MySQL, et un WordPress récent compatible PHP 8.x. Le but est de dérouler une installation propre, compréhensible, avec des commandes concrètes et quelques retours d’expérience terrain.
Pour rendre tout ça plus parlant, on suit le cas d’un admin d’un petit serveur Debian chez un hébergeur qui veut migrer son vieux site statique vers WordPress sans transformer son VPS en gruyère côté sécurité.
En bref
- Préparer Debian 11 ou Debian 12 avec les bons paquets (Apache ou Nginx, PHP 8.x, MariaDB/MySQL) et un minimum de réglages système.
- Créer une base de données dédiée pour WordPress avec un utilisateur limité, plutôt que d’utiliser le compte root de la base.
- Déployer les fichiers WordPress dans le bon répertoire du serveur web et régler les permissions pour l’utilisateur www-data.
- Configurer le VirtualHost Apache ou le bloc server Nginx pour gérer nom de domaine, HTTPS, URL propres et cache de base.
- Renforcer la sécurité de ton installation (préfixe des tables, droits Unix, modules PHP, durcissement de wp-config.php et des plugins).
Prérequis pour une installation WordPress propre sur Debian 11 ou 12
Avant de parler VirtualHost ou thème graphique, il faut que Debian soit prête à accueillir un WordPress récent. Sur le papier, WordPress reste assez léger, mais dans la pratique, un serveur mal préparé se traduit par des erreurs PHP, des lenteurs ou des soucis de sécurité qui arrivent toujours au pire moment.
Alex, par exemple, a commencé par sous‑dimensionner son VPS et a découvert très vite que 512 Mo de RAM, c’est juste pour un site WordPress avec quelques plugins costauds.
Sur Debian 11 comme sur Debian 12, le socle commun reste le même : un serveur web (Apache ou Nginx), une base de données (MariaDB ou MySQL) et PHP 8.x avec les bonnes extensions. Le choix entre Apache et Nginx dépend surtout de ton affinité et de tes besoins. Pour un premier projet, Apache reste plus intuitif grâce aux .htaccess. Pour une installation plus orientée performance et reverse proxy, Nginx a de sérieux arguments.
Paquets indispensables côté serveur web, PHP et base de données
Sur une Debian neuve, Alex commence par mettre à jour son système, puis installe un environnement LAMP classique avec Apache. Tu peux faire de même avec ces commandes de base :
Apache + PHP + MariaDB sur Debian 11/12
sudo apt update
sudo apt install apache2 mariadb-server php php-mysql php-gd php-curl php-intl php-mbstring php-xml php-zip
Si tu préfères Nginx, la logique est la même : tu remplaces Apache par Nginx et PHP-FPM.
Nginx + PHP-FPM + MariaDB
sudo apt update
sudo apt install nginx mariadb-server php-fpm php-mysql php-gd php-curl php-intl php-mbstring php-xml php-zip
Les modules PHP cités couvrent la majorité des besoins WordPress actuels. Un oubli sur php-mysql ou php-mysqli, et tu te retrouves avec le fameux message « Your PHP installation appears to be missing the MySQL extension » au moment de l’installation. C’est typiquement le genre de détail qui fait perdre 30 minutes alors que la solution tient en une ligne d’apt.
Réglages PHP et ressources système à ne pas négliger
Une fois les paquets installés, Alex ajuste quelques paramètres dans php.ini. Sur Debian 11 ou Debian 12, selon que tu utilises PHP-FPM ou mod_php, le fichier ne se trouve pas exactement au même endroit, mais les options à surveiller restent identiques :
- memory_limit pour éviter les erreurs de type « Allowed memory size exhausted ».
- upload_max_filesize et post_max_size pour les médias lourds et certains thèmes.
- max_execution_time pour les opérations longues (mises à jour, import de démo).
Sur un petit VPS, une base raisonnable pour WordPress en 2026 tourne souvent autour de :
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120
Côté ressources matérielles, un serveur dédié à un seul site vitrine peut tourner correctement avec 1 Go de RAM. Dès que tu ajoutes WooCommerce, des plugins lourds ou plusieurs sites, il vaut mieux viser 2 Go minimum pour garder un peu de marge. Alex, lui, a fini par passer de 1 à 2 Go après avoir constaté que MariaDB swapait dès qu’il lançait un import massif de produits.
Création de la base de données WordPress sur Debian avec MariaDB ou MySQL
Un WordPress, c’est avant tout un jeu de tables dans une base de données. Tout passe par là : contenus, réglages, comptes utilisateurs, extensions, widgets. Sur Debian 11 et Debian 12, MariaDB est souvent installé par défaut, compatible avec les commandes MySQL habituelles. Autant partir sur une base propre avec un schéma dédié, un compte limité et des droits précisément définis.
Dans le cas d’Alex, il aurait pu utiliser directement le compte root MariaDB « juste pour tester ». Mauvaise habitude. Il a pris cinq minutes de plus pour créer une base et un utilisateur spécifiques, ce qui lui évitera plus tard d’exposer tout son serveur de bases de données si WordPress est un jour compromis.
Création de la base et de l’utilisateur dédiés à WordPress
Connexion à MariaDB :
sudo mysql -u root -p
Dans la console, Alex crée d’abord une base. Pour la production, le nom peut rester lisible mais évite les évidences du type « wordpress ».
CREATE DATABASE wp_site_blog CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Ensuite, il crée un utilisateur limité à localhost, avec un mot de passe robuste :
CREATE USER 'wpuser_blog'@'localhost' IDENTIFIED BY 'MotDePasseUltraSolide!2026';
GRANT ALL PRIVILEGES ON wp_site_blog.* TO 'wpuser_blog'@'localhost';
FLUSH PRIVILEGES;
Ce trio de commandes suffit à préparer l’environnement WordPress. La base est vide pour l’instant, mais WordPress créera ses tables lors de la phase graphique d’installation. Alex sort de la console avec un simple :
EXIT;
Choix du préfixe de tables et impact sécurité
La plupart des tutoriels s’arrêtent là, mais un détail mérite de s’y attarder : le préfixe des tables. Par défaut, WordPress propose « wp_ ». Des bots qui scannent le web partent justement de ce préfixe pour lancer des attaques SQL génériques sur des installations mal protégées.
Lors de l’assistant d’installation, Alex modifie ce préfixe en quelque chose de moins trivial, par exemple « sg389_ ». Est‑ce que ça remplace un vrai durcissement de la sécurité côté serveur web et plugins ? Non. Est‑ce que ça complique un peu la tâche aux scripts automatisés ? Oui, et vu le coût de l’action (littéralement un champ à personnaliser), ce serait dommage de s’en priver.
Le couple base dédiée + utilisateur restreint + préfixe personnalisé forme une base correcte. Pour un deuxième site sur le même serveur, Alex recommence exactement la même séquence avec des noms différents, plutôt que de tout entasser dans une seule base. C’est plus propre, plus lisible et plus simple à sauvegarder ou migrer indépendamment.
Déploiement des fichiers WordPress et structure sur le serveur web
Une fois la base prête, place au concret : télécharger l’archive WordPress, décompresser au bon endroit, ajuster droits et permissions. C’est l’étape où beaucoup de gens se retrouvent avec un WordPress accessible seulement via « /wordpress » ou des permissions trop larges qui ouvrent une brèche côté sécurité.
Alex veut que son site réponde directement sur « https://exemple.fr » et non sur « https://exemple.fr/wordpress ». Il travaille donc directement dans la racine du VirtualHost ou du bloc server.
Téléchargement et extraction de WordPress sur Debian
Alex se connecte en SSH sur son serveur, se positionne dans /tmp et télécharge la dernière version :
cd /tmp
wget https://wordpress.org/latest.tar.gz
Avec Apache, si la racine est /var/www/html, il procède ainsi :
sudo rm /var/www/html/index.html 2>/dev/null || true
sudo tar -xzvf latest.tar.gz
sudo mv wordpress/* /var/www/html/
Ensuite, il supprime les éléments devenus inutiles :
sudo rm -rf wordpress latest.tar.gz
Les fichiers WordPress sont maintenant directement à la racine du site. Pas de sous‑répertoire parasite. Ce choix simplifie la gestion du nom de domaine et évite les redirections tordues plus tard.
Permissions Linux adaptées à WordPress
C’est un point souvent négligé. Pour que le serveur web puisse lire et parfois écrire certains fichiers (mises à jour, uploads, cache), il doit en être propriétaire. Sur Debian avec Apache ou Nginx, l’utilisateur système est en général www-data. Alex ajuste donc les permissions :
sudo chown -R www-data:www-data /var/www/html
Ensuite, il veille à ce que les fichiers et dossiers aient des modes raisonnables :
sudo find /var/www/html/ -type f -exec chmod 644 {} ;
sudo find /var/www/html/ -type d -exec chmod 755 {} ;
Donner un 777 sur wp-content pour « régler un problème vite fait » fonctionne parfois à court terme, mais transforme le serveur en cible idéale. Alex préfère prendre le temps de comprendre pourquoi WordPress ne peut pas écrire et corriger proprement les droits plutôt que d’ouvrir tout en lecture/écriture pour tout le monde.
| Type d’élément | Propriétaire recommandé | Droits Unix conseillés | Commentaire |
|---|---|---|---|
| Fichiers PHP, core WordPress | www-data:www-data | 644 | Lecture pour tous, écriture réservée au serveur web |
| Dossiers (wp-admin, wp-includes, wp-content) | www-data:www-data | 755 | Exécution requise pour parcourir les répertoires |
| wp-config.php | www-data:www-data | 400 ou 440 | Fichier sensible, accès lecture seule strict |
| Dossier de cache ou upload spécifique | www-data:www-data | 755 (voire 775) | Selon le plugin de cache ou de médias utilisé |
Une fois ce socle en place, l’étape suivante se joue dans le navigateur : l’assistant WordPress qui va se connecter à la base et générer automatiquement wp-config.php. C’est aussi là que tu définis compte admin, titre du site et langue.
Sécurité et optimisation d’un WordPress sur Debian : les réflexes utiles
Une fois le site en ligne et accessible, beaucoup de personnes s’arrêtent là. Sauf qu’un WordPress exposé sur Internet sans durcissement ni maintenance régulière finit tôt ou tard par poser problème. Entre les bots qui scannent les « /wp-login.php » et les extensions abandonnées, la surface d’attaque grossit vite.
Alex a choisi de traiter sécurité et performance dès l’installation. Pas dans une logique paranoïaque, mais pour éviter les pièges classiques : comptes admin évidents, fichiers sensibles lisibles, absence de sauvegarde, plugins non maintenus.
Durcissement minimal de WordPress et de Debian
Premier geste, Alex supprime le fichier d’exemple wp-config-sample.php qui ne sert plus à rien, puis renforce les droits sur wp-config.php :
sudo rm /var/www/html/wp-config-sample.php
sudo chmod 400 /var/www/html/wp-config.php
Ensuite, lors de l’installation, il a refusé le combo « admin / motdepasse123 ». Le compte administrateur porte un identifiant moins prévisible, avec un mot de passe solide, associé à une adresse mail dédiée au site. Il installe aussi rapidement un plugin de sécurité comme All in One Security ou Wordfence pour :
- Limiter les tentatives de connexion.
- Modifier éventuellement l’URL de login.
- Détecter certains fichiers modifiés ou suspects.
Côté Debian, un simple pare‑feu (ufw ou iptables) qui n’ouvre que les ports nécessaires (22, 80, 443) réduit déjà les risques. Alex désactive également les modules Apache ou Nginx inutiles pour limiter la surface d’attaque.
Plugins clés pour les performances et les sauvegardes
Pour la performance, Alex installe un plugin de cache côté WordPress. Sur un petit VPS, un outil comme WP-Rocket côté payant, ou LiteSpeed Cache / W3 Total Cache côté gratuit, fait une réelle différence. Ils permettent de :
Générer des pages HTML statiques, minifier CSS/JS, différer le chargement de certains scripts et optimiser un minimum les assets. Combiné au cache navigateur activé dans Apache ou Nginx, le site encaisse bien mieux les pics de trafic.
Pour les images, Alex se repose sur un plugin comme Imagify pour compresser et éventuellement convertir les médias en WebP. Sur des pages avec beaucoup de visuels, le gain de poids est net, surtout sur mobile.
Côté sauvegarde, un plugin comme UpdraftPlus s’occupe d’envoyer régulièrement une copie de la base et des fichiers vers un stockage externe (S3, FTP, Google Drive…). Alex a déjà vécu la joie d’un hébergeur qui perd une VM sans backup récent, alors il ne mise plus tout sur les snapshots fournis par défaut.
Au fil des mois, la règle qu’il applique est simple : chaque nouveau plugin est interrogé sur trois points. Est‑ce qu’il est encore maintenu, est‑ce qu’il est vraiment utile, et est‑ce qu’il ne fait pas doublon avec une fonctionnalité déjà en place ? Cette discipline évite les WordPress transformés en usine à gaz avec 40 extensions dont la moitié sont dormantes.
En combinant un serveur web bien configuré, une base de données propre, des permissions maîtrisées et quelques bons réflexes en sécurité, une installation WordPress sur Debian 11 ou Debian 12 reste saine dans le temps. Le reste, c’est surtout du design, du contenu… et un peu de veille régulière sur les mises à jour.
Quelle est la meilleure combinaison pour un petit site WordPress sur Debian 11 ou 12 ?
Pour un site vitrine ou un blog avec peu de trafic, un couple Apache + PHP 8.x + MariaDB sur Debian 11 ou Debian 12 reste un choix solide. Apache est simple à configurer, bien documenté, et WordPress y fonctionne très bien avec mod_rewrite. Un VPS avec 1 Go de RAM, un certificat Let’s Encrypt, un plugin de cache léger et des sauvegardes régulières couvrent déjà la majorité des besoins sans se compliquer la vie avec une stack trop exotique.
Comment corriger l’erreur WordPress sur l’extension MySQL manquante ?
Ce message apparaît quand le module PHP pour MySQL/MariaDB n’est pas installé ou activé. Sur Debian 11 ou Debian 12, installe le paquet php-mysql (ou php8.x-mysql selon ta version), puis redémarre Apache ou PHP-FPM. Par exemple : sudo apt install php-mysql puis sudo systemctl restart apache2. Une fois le module chargé, l’assistant WordPress peut enfin dialoguer correctement avec la base de données.
Puis-je installer WordPress dans un sous-répertoire ou sur un sous-domaine ?
Oui. Pour un sous-répertoire, tu décompresses WordPress dans /var/www/html/mon-site et tu configures Apache ou Nginx pour pointer dessus, puis tu termines l’installation via https://domaine.fr/mon-site/. Pour un sous-domaine, tu crées un VirtualHost ou un bloc server distinct (par exemple blog.domaine.fr) avec un DocumentRoot dédié. Dans les réglages WordPress, tu ajustes ensuite l’URL du site pour refléter ce chemin précis.
Comment réagir si mon site WordPress affiche une page blanche après une mise à jour ?
Une page blanche signale généralement une erreur PHP non affichée. Commence par vérifier les logs d’Apache ou Nginx (par exemple sudo tail -f /var/log/apache2/error.log). Tu peux activer le mode debug dans wp-config.php avec WP_DEBUG et WP_DEBUG_LOG pour consigner les erreurs dans wp-content/debug.log. Si le problème vient d’un plugin, désactive-le en renommant son dossier dans wp-content/plugins, puis réactive les extensions une par une pour isoler la coupable.
Quels réglages simples améliorent vraiment les performances de WordPress sur Debian ?
Trois leviers ont un impact immédiat : un plugin de cache bien configuré pour générer des pages statiques, l’activation d’OPcache dans PHP pour éviter de recompiler les scripts à chaque requête, et l’optimisation des images (compression et formats modernes comme WebP). Ajoute à cela une configuration Apache ou Nginx qui gère la compression GZip et le cache navigateur, et tu gagnes déjà une sensation de fluidité sans changer d’hébergement.
