Installer WordPress demande surtout de choisir le bon environnement et de préparer correctement les fichiers, la base de données et le nom de domaine WordPress. Pour apprendre sans risquer un site public, WordPress en local est adapté. Pour publier, OVH, Hostinger et o2switch proposent des installations guidées, mais le parcours exact dépend de l’offre souscrite et de la version de leur interface.
La méthode automatique convient à un site neuf et à la plupart des débutants. Une installation manuelle reste utile pour comprendre la configuration WordPress, contrôler les accès ou migrer un site existant. Dans les deux cas, mieux vaut tester les pages, les formulaires et le certificat HTTPS avant d’annoncer la mise en ligne. Un assistant d’installation fait gagner du temps ; il ne remplace ni une sauvegarde ni une vérification.
En bref
- Utilisez un environnement local pour apprendre, développer et tester des extensions.
- Chez OVH, Hostinger et o2switch, vérifiez que le domaine, l’espace web et la base MySQL sont prêts avant de lancer l’assistant.
- Pour une installation manuelle, transférez les fichiers, importez la base et renseignez les paramètres dans wp-config.php.
- Une migration exige de tester le nouveau serveur avant la bascule DNS et de conserver l’ancien hébergement le temps de valider le site.
Installer WordPress en local pour tester sans toucher au site public
WordPress en local s’exécute sur un ordinateur plutôt que sur un serveur accessible depuis Internet. Cette méthode est pratique pour découvrir l’administration, préparer une refonte ou vérifier qu’une extension fonctionne avant de l’utiliser sur un site en production. Elle évite de publier une page inachevée, mais le site local n’est pas une sauvegarde : il faut aussi protéger et copier ses fichiers si le travail a de la valeur.
Pour débuter, un outil comme Local fournit un environnement de développement avec serveur web, PHP et base de données. Des solutions comme XAMPP ou DDEV conviennent également, mais demandent parfois davantage de réglages. Il faut choisir un seul environnement au départ. Installer plusieurs piles locales qui tentent d’utiliser les mêmes ports peut provoquer des conflits difficiles à diagnostiquer, notamment autour du port 80 ou 443.
Après l’installation de l’outil, créez un nouveau site et indiquez son nom, la version de PHP proposée et le type de serveur disponible. Pour un projet destiné à un hébergeur précis, rapprochez autant que possible les versions de PHP et de la base de données de celles du serveur cible. Une différence de version n’empêche pas toujours WordPress de fonctionner, mais elle peut faire apparaître des erreurs propres à un thème ou à une extension.
L’outil local crée généralement la base de données et les fichiers WordPress automatiquement. L’administration est ensuite accessible depuis une adresse locale indiquée par l’application, par exemple une adresse se terminant par .local. Les identifiants d’administration sont distincts des comptes de l’ordinateur. Il faut donc choisir un mot de passe spécifique et ne pas réutiliser celui d’un service en ligne.
Ce cadre est fait pour le développement, pas pour héberger un site public. Une adresse locale n’est pas joignable par les visiteurs, et l’ordinateur doit rester allumé pour servir les pages. Il ne faut pas exposer l’interface de développement à Internet en ouvrant des ports au hasard sur la box : pour un site accessible, un hébergement WordPress correctement configuré est le choix raisonnable.
Le passage du local à l’hébergement ne consiste pas à copier un dossier au hasard. Les fichiers et la base doivent être transférés ensemble, puis les adresses locales remplacées par le nom de domaine réel. Une copie de test peut s’effectuer sur un sous-domaine ou une préproduction. C’est à ce moment qu’il faut vérifier les liens, les médias et les formulaires avant d’ouvrir le site au public.
Pour une première prise en main, le bon réflexe est de créer une page, installer un thème depuis le répertoire officiel et tester une extension à la fois. Si le site casse après l’activation d’un plugin, le diagnostic est immédiat. En production, où plusieurs extensions et données sont déjà en jeu, le même test peut coûter une heure de dépannage.
Préparer l’hébergement WordPress, le domaine et la base MySQL
Avant d’installer WordPress sur un serveur, vérifiez trois éléments : l’hébergement WordPress est actif, le domaine pointe vers le bon espace et une base de données MySQL peut être créée. Ces composants sont parfois vendus ou gérés séparément. Le domaine peut, par exemple, être enregistré chez un registrar tandis que le site est hébergé chez un autre prestataire. Il faut alors gérer les DNS au bon endroit.
Le domaine sert d’adresse publique au site. Il peut être dirigé par des enregistrements DNS de type A ou AAAA vers le serveur, ou être associé à un espace web depuis le panneau de l’hébergeur. Ne modifiez pas les DNS avant d’avoir vérifié la cible : une erreur peut rendre indisponibles le site et, selon la configuration, certains services liés au domaine. Pour comprendre la gestion du domaine et de ses enregistrements, ce guide sur la gestion d’un domaine avec Cloudflare donne un complément utile.
La base de données MySQL contient les pages, articles, comptes et réglages de WordPress. Créez une base et un utilisateur dédiés, puis notez le nom de la base, l’utilisateur, le mot de passe et l’hôte de connexion. Ce dernier n’est pas toujours localhost : certains hébergeurs indiquent une adresse spécifique dans leur panneau. Une erreur dans un seul de ces paramètres provoque souvent le message signalant que WordPress ne peut pas se connecter à la base.
Les assistants d’installation des hébergeurs créent parfois cette base à votre place. Même dans ce cas, gardez une trace sécurisée des informations, sans les laisser dans un document partagé ou un fichier public. Les identifiants ne doivent pas être envoyés dans un ticket non protégé. Le fichier wp-config.php contient les paramètres de connexion ; ses permissions doivent empêcher les modifications par des utilisateurs non autorisés.
Avant le démarrage, contrôlez aussi la version PHP proposée et la présence des extensions courantes nécessaires à WordPress et aux plugins utilisés. La version requise évolue avec le logiciel et les extensions : consultez les exigences publiées par WordPress et les éditeurs concernés plutôt que de choisir une version au hasard. Sur un site existant, reproduire la version PHP source pendant la migration limite les incompatibilités ; une mise à niveau pourra être testée ensuite.
Une installation neuve ne nécessite pas de migrer une ancienne base, mais elle mérite tout de même une politique de sauvegarde. Une sauvegarde exploitable comprend les fichiers et la base, et doit pouvoir être restaurée. Un instantané conservé uniquement sur le même compte d’hébergement ne protège pas d’une suppression du compte ou d’un incident affectant le serveur. Copiez les sauvegardes ailleurs et effectuez un test de restauration.
| Environnement | Approche conseillée | Vérification à faire |
|---|---|---|
| Ordinateur local | Outil de développement local | Compatibilité PHP et test des extensions |
| OVH | Assistant du panneau ou installation manuelle | Dossier web, base et configuration de l’offre |
| Hostinger | Assistant d’installation ou transfert manuel | Domaine associé et répertoire public |
| o2switch | Outil du panneau ou installation manuelle | Chemin du site et paramètres de base |
Réaliser une installation WordPress OVH, Hostinger ou o2switch
Les interfaces des hébergeurs changent, et les options disponibles dépendent de l’offre. Le principe reste stable : sélectionner le domaine, choisir un répertoire, créer ou sélectionner une base et lancer l’installation. Pour une installation WordPress OVH, commencez par le panneau de gestion de l’hébergement et repérez les fonctions dédiées aux modules ou aux installations. Vérifiez que le domaine est bien associé à l’espace web visé avant de confirmer.
Pour installer WordPress Hostinger, le hPanel propose généralement un parcours guidé dans la gestion du site. Il demande les informations du compte administrateur, le domaine et parfois les paramètres de la base. Utilisez un nom d’utilisateur qui n’est pas simplement « admin » et un mot de passe long, unique et stocké dans un gestionnaire. Un assistant facilite la mise en place, mais ne rend pas le compte invulnérable.
Pour installer WordPress O2switch, ouvrez le panneau associé à l’hébergement et repérez l’outil d’installation disponible, souvent présenté dans la rubrique des applications ou des logiciels. Selon la méthode choisie, le domaine et le chemin d’installation peuvent être demandés. Si WordPress doit être à la racine du domaine, évitez de le placer par inadvertance dans un sous-dossier comme /wordpress, faute de quoi l’adresse publique comportera ce chemin.
Quel que soit le prestataire, relisez le récapitulatif avant de lancer l’installation. Une installation sur le mauvais domaine ou dans un répertoire déjà occupé peut écraser des fichiers ou créer un site à une adresse inattendue. Pour un site déjà actif, ne testez jamais un nouvel assistant sur le répertoire de production sans sauvegarde vérifiée.
- Associez le domaine à l’espace d’hébergement et confirmez le dossier cible.
- Créez une base MySQL dédiée ou vérifiez celle créée par l’assistant.
- Renseignez le titre du site, l’adresse administrateur et un mot de passe unique.
- Ouvrez l’administration, contrôlez les réglages HTTPS et faites une sauvegarde initiale.
Après l’installation, connectez-vous à /wp-admin, vérifiez le titre du site, la langue, le fuseau horaire et les permaliens. Choisissez une structure d’URL lisible avant de publier beaucoup de contenu ; la modifier plus tard peut casser des liens externes si aucune redirection n’est prévue. Le guide sur les mots-clés et leur organisation sur un site web peut aider à préparer les pages avant leur publication.
Une installation automatique installe parfois des extensions ou des thèmes de démonstration. Supprimez ce qui ne sera pas utilisé, mais ne désactivez pas à l’aveugle un composant fourni par l’hébergeur et nécessaire à son fonctionnement. Une extension inutilisée augmente la surface de maintenance ; un plugin abandonné ou vulnérable n’a rien à faire sur un site public.
Pour une installation manuelle, téléchargez WordPress depuis le site officiel, transférez ses fichiers dans le répertoire web, puis ouvrez le domaine dans un navigateur. L’assistant demande les informations de connexion à la base et crée le fichier de configuration. Cette méthode donne davantage de contrôle, mais elle impose de vérifier les permissions, la version du logiciel et l’intégrité du transfert.
Installer WordPress manuellement et sécuriser la configuration
La procédure manuelle est préférable quand l’assistant n’est pas disponible, quand le répertoire doit être maîtrisé ou quand le site est transféré depuis un autre serveur. Elle commence par une sauvegarde complète des fichiers et de la base source. Chez Hostinger, les fichiers se trouvent souvent dans /public_html/ ; chez o2switch, ils sont fréquemment placés dans /www/ ou dans un sous-dossier. Chez OVH, le chemin dépend notamment de l’offre. Il faut confirmer le répertoire exact dans le panneau ou par SFTP.
Transférez les fichiers en SFTP, pas en FTP non chiffré lorsque le service sécurisé est disponible. Pour un grand site, une archive transférée puis extraite sur le serveur est souvent plus fiable que des milliers de fichiers individuels. Si le transfert est fait fichier par fichier, comparez les volumes et vérifiez les journaux du logiciel SFTP : les fichiers manquants dans wp-content/uploads produisent des images cassées qui ne sautent pas toujours aux yeux immédiatement.
Créez ensuite la base et importez le fichier SQL depuis phpMyAdmin ou un accès SSH. En ligne de commande, un export peut être effectué avec mysqldump -u utilisateur -p nom_base > backup-bdd.sql. L’import doit viser une base vide ou une base dont le contenu peut être remplacé sans risque. Avant toute opération qui écrase des données, vérifiez que le fichier de sauvegarde est présent et non vide.
Dans wp-config.php, renseignez le nom de base, l’utilisateur, son mot de passe et l’hôte fournis par le nouvel hébergeur. Ne recopiez pas aveuglément une valeur depuis un autre prestataire : l’hôte de la base peut différer. Gardez ce fichier hors des dépôts publics et ne publiez jamais son contenu dans une capture d’écran ou un forum.
Une migration impose aussi de contrôler les adresses enregistrées en base. Les valeurs siteurl et home dans la table des options doivent correspondre à l’adresse finale. Les anciennes URL peuvent également être présentes dans les articles, les widgets et les réglages sérialisés de PHP. Un remplacement SQL brut peut corrompre ces données ; WP-CLI, avec la commande wp search-replace, traite correctement les contenus sérialisés lorsqu’il est utilisé avec le bon répertoire et les bonnes options.
Avant la bascule DNS, testez le nouveau serveur sans rediriger les visiteurs. Une modification temporaire du fichier hosts de l’ordinateur permet d’associer le domaine à l’adresse IP de destination. L’adresse 203.0.113.42 est réservée à la documentation et ne doit servir que d’exemple : remplacez-la par l’IP communiquée par l’hébergeur. Testez la page d’accueil, les pages internes, l’administration, les images et les formulaires.
La bascule intervient après ces contrôles. Si possible, réduisez le TTL DNS quelques jours avant le transfert, puis mettez à jour les enregistrements nécessaires chez le gestionnaire DNS. Les résolveurs ne se mettent pas tous à jour simultanément : certains visiteurs peuvent atteindre l’ancien serveur pendant la propagation. Conservez-le au moins 48 heures après la bascule et surveillez les erreurs avant de résilier l’ancien contrat.
La sécurité WordPress commence par l’entretien : mettez à jour le cœur, les thèmes et les extensions, retirez les composants inutiles, imposez des mots de passe uniques et activez une authentification renforcée lorsqu’elle est disponible. Configurez un certificat SSL, vérifiez les tâches planifiées et la capacité d’écriture du dossier des médias. Les permissions courantes sont souvent 755 pour les dossiers et 644 pour les fichiers, mais il faut respecter les recommandations de l’hébergeur plutôt que d’appliquer des droits trop ouverts.
Migration WordPress : tester le nouveau serveur avant la bascule DNS
La migration d’un site WordPress fait peur surtout quand fichiers, base de données et DNS sont traités comme une seule opération. En pratique, ce sont trois éléments distincts. Les fichiers comprennent le cœur du CMS, les extensions, les thèmes et les médias ; la base contient le contenu et les réglages ; le DNS dirige le domaine vers le serveur. En séparant ces étapes, le transfert devient vérifiable et le retour arrière reste possible.
Commencez par inventorier l’environnement source : chemin d’installation, version PHP, extensions PHP actives, règles personnalisées dans .htaccess et éventuels caches ou CDN. Ces détails expliquent souvent pourquoi un site fonctionne chez l’ancien prestataire et échoue sur le nouvel hébergement. Une différence de version PHP peut notamment révéler un plugin ancien qui n’a jamais été testé dans un environnement plus récent.
Faites votre propre sauvegarde avant de transférer quoi que ce soit. Téléchargez les fichiers par SFTP ou créez une archive avec SSH, puis exportez la base via phpMyAdmin ou mysqldump. Ne vous contentez pas de supposer que la sauvegarde automatique du fournisseur est restaurable. Un fichier SQL de taille nulle et une archive interrompue sont des incidents simples à éviter en contrôlant leur taille et leur ouverture avant le transfert.
Sur le nouvel hébergement, créez une base dédiée et un compte associé. Importez le dump, transférez les fichiers dans le répertoire approprié et adaptez les paramètres de connexion de wp-config.php. Si l’URL du site change, effectuez un remplacement des anciennes adresses avec WP-CLI ou un outil compatible avec les données sérialisées. Modifier uniquement les deux entrées principales de la table des options ne corrige pas nécessairement les adresses conservées dans les contenus et les réglages de thèmes.
Le test avant DNS est l’étape que les migrations pressées ont tendance à sacrifier. Or, il permet de vérifier le nouveau serveur sans exposer les visiteurs à un site incomplet. Avec un fichier hosts local, le navigateur utilise la nouvelle IP uniquement sur l’ordinateur de test. La page d’accueil ne suffit pas : vérifiez aussi l’accès à l’administration, les liens permanents, la recherche, les formulaires et, pour une boutique, le panier et le parcours de commande.
Quand le site est validé, modifiez les enregistrements DNS concernés chez le registrar ou le fournisseur DNS. Un TTL réduit avant l’opération peut accélérer l’actualisation chez certains résolveurs, mais ne garantit pas une bascule instantanée partout. Pendant cette période, des visiteurs peuvent encore consulter l’ancien serveur. Pour une boutique ou un site avec des commentaires fréquents, il faut prévoir cette fenêtre : des commandes ou des contributions reçues sur l’ancien site après la copie ne seront pas automatiquement présentes dans la nouvelle base.
Cette situation demande une décision explicite. Pour un site vitrine peu modifié, une courte fenêtre de transfert suffit généralement. Pour un site marchand, mieux vaut limiter temporairement les changements ou mettre en place une synchronisation des données, plutôt que d’écraser la base finale avec une copie antérieure. La stratégie dépend du volume d’activité ; une simple copie de fichiers ne résout pas le décalage entre deux bases qui reçoivent des commandes.
Après la bascule, contrôlez le certificat HTTPS, les redirections, les journaux d’erreurs, le cache serveur et les tâches planifiées de WordPress. Purgez les caches du plugin, de l’hébergement et du CDN si le site en utilise un. Gardez l’ancien hébergement disponible jusqu’à ce que les pages et les fonctionnalités aient été testées depuis plusieurs accès réseau ; le supprimer dès que la page d’accueil s’affiche est une prise de risque inutile.
Pour une refonte ou une migration qui modifie aussi l’arborescence, le transfert technique ne suffit pas : les anciennes URL doivent être redirigées et les pages importantes conservées. Les recommandations de préparation d’une refonte WordPress complètent les vérifications serveur. La bonne migration est celle qui laisse le temps de tester, pas celle qui s’achève le plus vite.
Peut-on installer WordPress gratuitement en local ?
Oui. Un outil local peut installer les composants nécessaires sur un ordinateur sans acheter d’hébergement. Le site reste toutefois inaccessible au public tant qu’il n’est pas transféré vers un serveur web.
Quelle méthode choisir pour installer WordPress sur OVH, Hostinger ou o2switch ?
Pour un site neuf, utilisez l’assistant fourni dans le panneau si le domaine et la base sont correctement configurés. La méthode manuelle est utile pour maîtriser le répertoire, reproduire une configuration ou migrer un site existant.
Faut-il créer une base de données MySQL avant l’installation ?
Cela dépend de l’assistant de l’hébergeur. Certains créent la base automatiquement ; une installation manuelle demande généralement de créer la base et l’utilisateur, puis d’indiquer leurs paramètres à WordPress.
Comment éviter une coupure pendant une migration WordPress ?
Transférez et testez le site sur le nouveau serveur avant la modification DNS. Conservez l’ancien hébergement pendant la propagation et prévoyez une méthode spécifique pour les contenus ou commandes ajoutés pendant le transfert.
