Les points à vérifier avant de lancer l’installation
- Un hébergement compatible avec PHP 8.3+ et une base MariaDB 10.6+ ou MySQL 8.0+.
- Un accès aux fichiers du site en FTP/SFTP ou, mieux, en SSH si vous l’avez.
- Une base de données dédiée et un utilisateur avec les droits nécessaires.
- Le bon emplacement dès le départ, en racine du domaine ou dans un sous-dossier.
- Un accès HTTPS actif, sinon l’administration démarre déjà avec une faiblesse évitable.
Ce qu’il faut vérifier avant de toucher aux fichiers
Avant d’envoyer le moindre fichier, je commence toujours par l’environnement serveur. WordPress.org recommande aujourd’hui PHP 8.3 ou plus, MariaDB 10.6+ ou MySQL 8.0+, ainsi qu’un serveur Nginx ou Apache avec mod_rewrite et support HTTPS. WordPress peut encore tourner sur des versions plus anciennes, mais je déconseille franchement de bâtir un nouveau site sur une base déjà en fin de vie, surtout pour la sécurité.
| Élément | Recommandation 2026 | Pourquoi je m’y tiens |
|---|---|---|
| PHP | 8.3 ou plus | Meilleure compatibilité, meilleures performances, moins de dette technique |
| Base de données | MariaDB 10.6+ ou MySQL 8.0+ | Support actif et comportement plus prévisible |
| Serveur web | Nginx ou Apache avec mod_rewrite
|
Permaliens propres et règles d’URL fiables |
| HTTPS | Oui | Connexion admin, cookies et formulaires plus sûrs |
Je vérifie aussi deux choses très concrètes, souvent oubliées: l’accès au panneau de base de données, et l’accès aux fichiers du site. Sans FTP, SFTP ou SSH, l’installation devient vite laborieuse; sans panneau MySQL ou phpMyAdmin, vous perdez du temps au pire moment, c’est-à-dire au moment où WordPress attend déjà ses identifiants. Une fois ce socle validé, on peut passer au dépôt des fichiers sans improviser.
Télécharger les fichiers et choisir la bonne méthode de dépôt
Je télécharge ensuite l’archive WordPress la plus récente, je la décompresse en local, puis je l’envoie sur le serveur. Le point qui piège le plus souvent les débutants est simple: il ne faut pas seulement téléverser le dossier wordpress tel quel si le site doit vivre à la racine du domaine. Il faut envoyer le contenu du dossier, pas le conteneur lui-même, sauf si vous voulez réellement installer WordPress dans un sous-répertoire.
En pratique, j’utilise trois scénarios:
- FTP ou SFTP, quand l’hébergement est standard et que je veux une méthode simple.
- SSH, quand j’ai accès au terminal, parce que c’est plus rapide et plus propre.
- Installation locale, si je veux tester avant de publier, par exemple sur un environnement de dev.
Si vous avez un accès shell, WordPress peut aussi être récupéré directement sur le serveur avec wget, puis extrait avec tar. Je trouve cette approche plus fiable sur les gros dossiers, parce qu’elle limite les erreurs de transfert et garde une structure de fichiers plus nette. Quel que soit le mode choisi, je désactive toute option de mon client FTP qui convertirait les noms de fichiers en minuscules, car ce détail peut créer des bugs étranges, surtout sur certaines configurations.
Quand les fichiers sont au bon endroit, la partie vraiment sensible commence: la connexion entre WordPress et sa base de données.
Créer la base de données et préparer wp-config.php
Je crée toujours une base dédiée pour WordPress, avec un utilisateur propre et les droits nécessaires sur cette base uniquement. Si l’hébergeur propose un assistant dans cPanel, Plesk ou un outil équivalent, je l’utilise volontiers, mais je garde le même principe: une base, un utilisateur, un mot de passe fort, et pas d’accès inutile à d’autres bases.
Si je veux préparer l’installation à la main, je renomme wp-config-sample.php en wp-config.php, puis je renseigne les paramètres essentiels:
-
DB_NAMEpour le nom de la base. -
DB_USERpour l’utilisateur de la base. -
DB_PASSWORDpour le mot de passe associé. -
DB_HOSTpour l’hôte de la base, qui n’est pas toujourslocalhost.
Le handbook WordPress précise que l’assistant peut générer ce fichier à votre place si vous sautez cette étape, et c’est pratique quand on veut aller vite. En revanche, je préfère souvent le faire moi-même quand j’ai déjà les identifiants définitifs, parce que cela évite un échange supplémentaire et permet de repérer tout de suite une valeur mal saisie. Si vous réutilisez une base déjà occupée, gardez aussi un préfixe de tables distinct, sinon vous prenez le risque d’écraser des tables existantes.
Une fois la configuration posée, WordPress peut enfin faire ce qu’il fait le mieux: terminer l’installation sans vous noyer dans les détails techniques.
Passer par l’assistant WordPress jusqu’au premier accès
Je visite ensuite l’URL où les fichiers ont été déposés. Si tout est en ordre, l’assistant de WordPress démarre et vous demande quelques informations simples: langue du site, titre du site, identifiant administrateur, mot de passe et adresse e-mail. C’est ici qu’il faut rester rigoureux, parce qu’une mauvaise habitude au premier jour se paie longtemps après.
Je déconseille de créer un compte administrateur nommé admin; c’est une cible trop évidente. Je choisis aussi un mot de passe solide dès l’installation, même si WordPress en propose un, et je vérifie que l’adresse e-mail administrative est correcte, parce qu’elle servira pour les notifications et la récupération d’accès. Si le site est déjà accessible en HTTPS, je m’assure que je termine l’installation sur la version sécurisée de l’URL, pas sur une version en HTTP qui obligera ensuite à corriger des liens ou des cookies.
Après la connexion au tableau de bord, je fais trois vérifications immédiates: le fuseau horaire, la structure des permaliens et le nettoyage du contenu de démonstration. Rien de spectaculaire, mais c’est exactement ce qui évite d’avoir un site “installé” qui reste mal configuré. Une fois cette base validée, il faut encore repérer les erreurs récurrentes qui font perdre du temps inutilement.
Les erreurs qui font échouer une installation pourtant simple
Les installations ratées ne viennent presque jamais d’un gros problème technique. Elles viennent d’une poignée de détails répétitifs, et je les vois revenir constamment.
| Symptôme | Cause probable | Ce que je vérifie en premier |
|---|---|---|
| L’assistant n’apparaît pas | Fichiers au mauvais endroit ou index absent | Structure du dossier envoyé sur le serveur |
| Erreur de connexion à la base | Identifiants faux ou DB_HOST incorrect |
wp-config.php et paramètres du panneau d’hébergement |
| Pages d’administration instables | PHP trop ancien ou modules manquants | Version PHP et extensions du serveur |
| Permaliens cassés |
mod_rewrite absent ou règles non prises en compte |
Configuration Apache/Nginx et réglages des permaliens |
| Fichiers ou dossiers au nom étrange | Client FTP qui a modifié la casse | Réglages de transfert avant upload |
Je vois aussi souvent des installations qui tournent sur une version PHP encore tolérée par WordPress, mais déjà en fin de support chez son éditeur. Techniquement, ça démarre. Pratiquement, c’est une dette de sécurité qui s’accumule dès le premier jour. Si vous voulez un site durable, l’objectif n’est pas seulement que WordPress s’installe, c’est qu’il reste maintenable sans correction d’urgence.
Les réglages que je fais tout de suite après la mise en ligne
Une installation propre n’est vraiment utile que si elle reste saine au fil des semaines. Dès que le tableau de bord est accessible, je passe par une petite liste de réglages qui changent beaucoup de choses dans la durée.
- Je lance les mises à jour du cœur, du thème et des extensions sans attendre.
- Je mets en place une stratégie de sauvegarde avant d’ajouter des plugins supplémentaires.
- Je vérifie que les e-mails sortants fonctionnent correctement, surtout pour les formulaires et la récupération de mot de passe.
- Je limite les extensions au strict nécessaire, parce que chaque plugin ajouté augmente la surface de maintenance.
- Je contrôle les droits de fichiers et l’accès à l’éditeur intégré si le contexte de sécurité l’exige.
Je recommande aussi de penser tout de suite à la suite logique: structure des contenus, réglages SEO de base, et éventuelle migration vers un environnement de préproduction si le site doit encore évoluer. Une installation manuelle bien faite ne sert pas seulement à “avoir WordPress”; elle vous donne une base claire, facile à comprendre et surtout facile à dépanner quand quelque chose bouge plus tard.
Si je devais résumer la méthode en une seule logique, je dirais ceci: vérifiez d’abord la compatibilité, posez les fichiers proprement, sécurisez la base de données, terminez l’assistant sans précipitation, puis verrouillez les réglages essentiels. C’est exactement cette séquence qui transforme une installation manuelle en fondation fiable, au lieu d’un site qui fonctionne seulement tant qu’on ne le touche pas.
