Les points à retenir avant de te lancer
- XAMPP réunit Apache, PHP et MariaDB dans un environnement local prêt à l’emploi.
- WordPress doit être copié dans le dossier web de XAMPP, le plus souvent `htdocs`.
- La base de données se crée dans phpMyAdmin, avec un encodage `utf8mb4` si possible.
- L’installation se termine depuis le navigateur en passant par `localhost`.
- Les blocages viennent surtout d’un port déjà utilisé, d’une base mal renseignée ou d’un mauvais emplacement des fichiers.
Pourquoi XAMPP reste une bonne base pour un WordPress local
Je recommande souvent XAMPP quand l’objectif est de comprendre ce qui se passe vraiment sous WordPress. WordPress.org rappelle qu’un serveur compatible PHP et MySQL ou MariaDB suffit, et Apache Friends présente XAMPP comme un environnement Apache, MariaDB et PHP prêt à l’emploi. Autrement dit, tu n’installes pas un simple “outil WordPress”, tu reconstruis le socle technique qui fait tourner le site.
Le vrai intérêt, c’est le contrôle. Tu vois le dossier des fichiers, tu gères la base, tu touches au fichier `wp-config.php` si nécessaire, et tu comprends vite d’où vient un problème. Pour un site de test, une maquette ou un chantier de maintenance, c’est nettement plus formateur qu’une solution trop automatisée.
| Situation | XAMPP | Ce que ça change |
|---|---|---|
| Apprendre le fonctionnement de WordPress | Très adapté | Tu vois le rôle du serveur, de la base et du fichier de configuration. |
| Tester rapidement un thème ou un plugin | Adapté | Tu peux casser, corriger et repartir de zéro sans risque pour le site en ligne. |
| Obtenir un environnement “zéro effort” | Moyennement adapté | Il faut encore créer la base et lancer l’installation manuellement. |
| Se rapprocher d’un hébergement classique | Adapté | Apache et une base MariaDB donnent un cadre très proche de beaucoup d’hébergements réels. |
En pratique, XAMPP convient très bien dès qu’on veut comprendre, tester et corriger. La suite logique, c’est de préparer proprement l’environnement pour ne pas perdre de temps sur des détails évitables.
Préparer XAMPP sans te battre avec les ports
Le plus simple est d’installer la version la plus récente de XAMPP compatible avec ton système, puis de la laisser dans un chemin clair et court. Je conseille de vérifier immédiatement que Apache et MySQL ou MariaDB démarrent correctement depuis le panneau de contrôle. Si le navigateur affiche `localhost`, tu pars sur de bonnes bases.
- Installe XAMPP avec l’installateur officiel adapté à ton système.
- Lance le panneau de contrôle et démarre Apache et la base de données.
- Teste `http://localhost` et, si besoin, `http://localhost/phpmyadmin`.
- Repère le dossier racine du site, généralement `htdocs`.
- Si Apache ne démarre pas, vérifie un conflit sur le port 80 ou 443 avant d’aller plus loin.
Le point à ne pas rater, c’est le port. Sur certaines machines, un autre service utilise déjà le 80 ou le 443, ce qui bloque Apache sans rapport direct avec WordPress. Dans ce cas, je corrige d’abord le serveur local, pas WordPress lui-même.
Une fois le socle en place, tu peux passer à la partie la plus sensible: la base de données et le compte qui vont accueillir le site.
Créer la base de données et le compte qui vont servir à WordPress
WordPress a besoin d’une base pour stocker les contenus, les réglages et les utilisateurs. Dans XAMPP, je passe par phpMyAdmin parce que c’est le chemin le plus direct et le plus lisible. Si tu veux quelque chose de propre et réutilisable, crée une base au nom simple, sans accent ni espace, puis attribue-lui un utilisateur dédié.
Sur une machine de travail personnelle, tu peux être tenté d’utiliser le compte racine par facilité. Je préfère éviter cette habitude: un utilisateur dédié avec les bons droits, c’est plus clair, plus proche d’un vrai hébergement et plus facile à migrer ensuite.
| Réglage | Valeur recommandée | Pourquoi |
|---|---|---|
| Nom de base | `wordpress_local` ou un nom équivalent | Simple à reconnaître et facile à retrouver plus tard. |
| Utilisateur | Un compte dédié, pas forcément `root` | Meilleure discipline de travail et migration plus propre. |
| Mot de passe | Un mot de passe dédié, même en local | Tu évites de reproduire des habitudes fragiles. |
| Hôte | `localhost` dans la plupart des cas | C’est la valeur la plus courante dans un environnement local. |
| Collation | `utf8mb4` si elle est proposée | Tu gardes une bonne compatibilité pour les contenus WordPress actuels. |
Une fois la base prête, la moitié du travail est déjà faite. Il reste à poser les fichiers WordPress au bon endroit et à lancer l’assistant d’installation depuis le navigateur.
Lancer l’installation de WordPress dans le navigateur
Je place ensuite le dossier WordPress dans le répertoire web de XAMPP. Sur Windows, cela ressemble souvent à `C:\xampp\htdocs\mon-site`; sur macOS ou Linux, le chemin varie, mais la logique reste la même: les fichiers doivent se trouver dans le dossier servi par Apache. Ensuite, j’ouvre l’URL locale correspondante dans le navigateur.
- Décompresse WordPress si ce n’est pas déjà fait.
- Copie son contenu dans un dossier du webroot XAMPP.
- Ouvre l’adresse locale du projet, par exemple `http://localhost/mon-site`.
- Choisis la langue et continue l’installation.
- Renseigne le nom de la base, l’utilisateur, le mot de passe et l’hôte.
- Laisse WordPress créer `wp-config.php` automatiquement ou prépare-le manuellement si tu préfères garder la main.
- Crée le compte administrateur, le titre du site et le mot de passe de connexion.
Le champ qui bloque le plus souvent est celui de la base. Si WordPress ne se connecte pas, je vérifie d’abord que le nom de la base correspond exactement à ce que j’ai créé, puis je contrôle l’utilisateur, le mot de passe et le serveur hôte. Dans un local sain, `localhost` suffit presque toujours.
Une fois l’installation terminée, tu obtiens un vrai site WordPress fonctionnel sur ton ordinateur. Les difficultés les plus courantes ne viennent alors plus de WordPress lui-même, mais de la configuration locale autour de lui.
Les erreurs que je corrige en premier
Quand une installation locale ne marche pas, je commence toujours par les couches techniques autour de WordPress, pas par les thèmes ou les extensions. Dans la majorité des cas, le problème est banal: un port occupé, un service arrêté ou un mauvais dossier. Voici les cas que je rencontre le plus souvent.
| Symptôme | Cause probable | Correction rapide |
|---|---|---|
| Apache ne démarre pas | Le port 80 ou 443 est déjà utilisé par un autre service | Arrête le service en conflit ou change le port d’Apache, puis redémarre XAMPP. |
| Erreur de connexion à la base | Nom de base, identifiant ou mot de passe incorrect | Compare les valeurs saisies dans l’assistant avec la base créée dans phpMyAdmin. |
| Page blanche ou téléchargement du fichier au lieu d’un site | Les fichiers WordPress ne sont pas dans le bon dossier ou PHP n’est pas servi correctement | Vérifie le chemin du projet dans `htdocs` et redémarre Apache. |
| phpMyAdmin inaccessible | Le moteur de base n’est pas lancé ou XAMPP n’est pas démarré complètement | Relance la base dans le panneau XAMPP et recharge `localhost`. |
| Les permaliens ne fonctionnent pas | La réécriture d’URL n’est pas active ou le serveur n’a pas été relancé | Réenregistre la structure des liens et vérifie la configuration Apache. |
Je vois souvent la même erreur de lecture: on pense que “WordPress est cassé”, alors que le problème vient du serveur local. Cette distinction fait gagner beaucoup de temps, surtout quand on travaille sur plusieurs projets dans le même environnement.
Ce que je règle juste après pour garder un vrai environnement de travail
Une fois WordPress installé, je ne m’arrête pas au simple écran d’accueil. Je fais trois ou quatre réglages pour que le local soit réellement utile au quotidien. D’abord, je teste les permaliens. Ensuite, j’active le débogage si je suis en phase de développement. Enfin, je limite les extensions au strict nécessaire pour garder un site propre et rapide à réinitialiser.
- Je vérifie que les permaliens se réenregistrent correctement.
- J’active le débogage local si je dois analyser des erreurs PHP.
- Je conserve une copie du dossier `wp-content` et un export SQL de la base.
- Je garde les plugins au minimum pour éviter les faux problèmes.
- Je note le nom de la base, l’utilisateur et le mot de passe dans un endroit sûr.
Quand le projet doit passer en ligne, ce travail préparatoire paie immédiatement. Tu sais déjà ce qui tourne, tu sais où est la base, et tu peux migrer plus proprement vers un hébergement réel sans découvrir les problèmes au dernier moment. C’est pour ça que je considère le local non pas comme une version “secondaire” du site, mais comme un vrai atelier de production.
