Installer WordPress : les réglages à faire avant le premier contenu

Installer WordPress prend quelques minutes et, chez la plupart des hébergeurs, se résume à un clic sur un bouton. Ce n’est pas la partie difficile, et ce n’est pas celle qui mérite votre attention.

Ce qui coûte, ce sont trois choses juste après. La version de PHP, que l’administration de WordPress ne montre pas du tout. La structure des adresses, que la documentation demande de fixer une fois pour toutes — et qui est réglée par défaut de la pire façon possible. Et une case héritée de l’installation de test, capable de retirer le site des moteurs de recherche pendant des mois avant que quelqu’un ne s’en aperçoive.

Les trois se tranchent dans le premier quart d’heure, et les trois se vérifient en deux minutes. Pour un site suisse, une quatrième décision appartient au même quart d’heure : dans combien de langues le site existera, et comment. Ce texte parle de ce quart d’heure-là.

Ce que WordPress exige de l’hébergement

Les exigences sont courtes, et c’est l’éditeur lui-même qui les publie.

D’après la documentation de WordPress.org, l’éditeur recommande PHP en version 8.3 ou plus, MariaDB 10.11 ou MySQL 8.0, et HTTPS. La même page précise que WordPress fonctionne aussi avec PHP 7.4 et MySQL 5.5.5 — en ajoutant que ces versions ont atteint leur fin de vie officielle et peuvent exposer le site à des failles de sécurité.

La confrontation avec la réalité est instructive. D’après les statistiques de WordPress.org, 37 % des installations tournent sur la version recommandée, et 38 % sur PHP 8.1 ou plus ancien, c’est-à-dire sans correctifs de sécurité. Ce n’est pas un problème de WordPress : c’est une couche que choisit le propriétaire du site en achetant son hébergement, et qui se change d’un seul interrupteur dans l’interface du prestataire.

La conclusion pratique pour le jour de l’installation : avant d’installer quoi que ce soit, regardez dans l’interface de votre hébergement quelle version de PHP sert votre domaine, et choisissez la plus récente disponible. Cela prend une minute et vous épargne une migration forcée en milieu d’année, le jour où le prestataire retire l’ancienne version. Les échéances après lesquelles une version cesse de recevoir des correctifs sont rassemblées dans notre texte sur le moment où un site doit être modernisé ; les critères du choix du serveur lui-même, dans notre texte sur l’hébergement.

La version de PHP se vérifie à trois endroits, et il vaut la peine de connaître les trois, parce que chacun répond à une question légèrement différente :

• Dans l’interface de l’hébergement — la rubrique s’appelle « version PHP », « configuration PHP », ou se cache dans les réglages du domaine. Vous y voyez la version utilisée maintenant et la liste des versions disponibles, donc immédiatement s’il y a quelque chose à relever.
• Dans l’administration de WordPress, sous Outils → Santé du site — WordPress signale lui-même une version trop ancienne comme un problème et indique ce qu’il attend. C’est le moyen le plus rapide si vous n’avez pas accès à l’hébergement.
• Par une question au support de l’hébergeur — une phrase suffit : « quelle version de PHP sert mon domaine, et jusqu’à quand sera-t-elle disponible ? » La réponse devrait arriver dans la journée ; son absence est en soi une information.

L’installateur de l’hébergeur ou l’installation manuelle

Il existe deux voies, et elles ne diffèrent pas par le temps qu’elles prennent, mais par ce qu’elles laissent derrière elles.

L’installateur dans l’interface de l’hébergeur. Vous cliquez sur « installer WordPress », vous choisissez le domaine, vous indiquez le nom du site et vos identifiants. Deux minutes plus tard, le site fonctionne. L’avantage est réel : l’hébergeur crée lui-même la base de données, règle les droits sur les fichiers et active en général le certificat dans la foulée. L’inconvénient, parfois, c’est que l’installateur ajoute son propre lot d’extensions — tantôt utiles, tantôt publicitaires — et il vaut la peine de regarder, après l’installation, ce que contenait le paquet.

L’installation manuelle. Vous déposez les fichiers, vous créez la base de données et vous remplissez le formulaire d’installation. Cela prend un quart d’heure, demande un accès aux fichiers et à la base, et donne un contrôle complet sur ce qui se trouve sur le serveur. Elle a du sens quand vous déménagez un site, quand l’hébergeur n’a pas d’installateur, ou quand vous voulez être certain que rien n’a été ajouté.

L’installation manuelle tient en cinq étapes, et il est utile de les connaître même si vous passez d’habitude par l’installateur — ce sont exactement les mêmes éléments que l’on reconstitue lors d’un déménagement de site :

1. Télécharger le paquet sur wordpress.org et le déposer dans le répertoire du domaine sur le serveur.
2. Créer la base de données et un utilisateur disposant de tous les droits sur elle — dans l’interface de l’hébergement, en général un seul onglet.
3. Ouvrir l’adresse du domaine dans le navigateur ; WordPress demande de lui-même les informations de la base.
4. Remplir le formulaire d’installation : nom du site, identifiant de l’administrateur, mot de passe, adresse électronique.
5. Vérifier que le site répond à la bonne adresse — avec certificat, et dans la version avec ou sans www que vous avez retenue.

Si la troisième étape se termine par un message d’erreur de connexion à la base de données, les informations de la deuxième ne correspondent pas à ce que vous avez saisi. C’est la cause la plus fréquente d’une installation ratée, et la seule qui s’affiche en clair.

Quelle que soit la voie, le formulaire d’installation vous demande trois choses qui ne se changent pas aussi facilement qu’on le croit :

• L’identifiant de l’administrateur. Ni « admin », ni le nom de l’entreprise. C’est la première moitié des identifiants de connexion, et la seconde est devinée par des machines ; ce qui ferme encore ce chemin, nous l’expliquons dans le texte sur la sécurisation du site.
• L’adresse électronique de l’administrateur. C’est la boîte à laquelle WordPress enverra le lien du mode de récupération le jour où une extension fera tomber le site — le mécanisme est détaillé avec les erreurs serveur. Si vous y inscrivez l’adresse de votre prestataire, c’est lui qui recevra le lien, pas vous.
• L’adresse du site. Avec https://, et dans la version que vous comptez utiliser — avec ou sans www. La modifier après la publication des contenus, ce sont des redirections, pas un interrupteur.

Les réglages qui se font avant le premier contenu

La demi-heure qui suit décide de ce que coûtera chaque correction ultérieure.

La structure des adresses. Une installation neuve utilise la structure « Simple », c’est-à-dire des adresses de la forme example.ch/?p=123. La documentation de WordPress la décrit sans détour : « It is not user-friendly and also not optimized for search engines » — ni lisible pour un humain, ni optimisée pour les moteurs de recherche. Le même texte dit une seconde chose, plus importante : ces adresses « are permanent and should never be changed », elles sont permanentes et ne devraient jamais changer.

L’écran où cela se règle : Réglages → Permaliens. La capture ci-dessus vient de la documentation officielle de WordPress, publiée sous licence CC0, et montre l’interface anglaise ; dans une administration en français, la première option s’appelle « Simple » — c’est celle par défaut.

Ces deux phrases réunies signifient que le choix de la structure des adresses est une décision unique, à prendre avant de publier quoi que ce soit. Pour un site d’entreprise, le choix pratique est « Titre de la publication » : l’adresse contient le titre, et rien d’autre. Une structure avec la date a du sens pour un site d’actualité, où la date fait partie du contenu ; sur une page d’offre, elle ne fait que donner l’impression que le site est ancien. Si vous changez les adresses d’un site en ligne, chaque ancienne adresse a besoin d’une redirection — nous le détaillons dans le guide de la migration de site.

La visibilité dans les moteurs de recherche. Les réglages de lecture contiennent la case « Demander aux moteurs de recherche de ne pas indexer ce site ». On la coche pendant la construction, et c’est un usage raisonnable. Le problème commence quand elle reste cochée après la mise en ligne — ce qui arrive étonnamment souvent, parce que rien ne la rappelle à votre attention.

L’écran Réglages → Lecture dans la documentation de WordPress (licence CC0, interface en anglais) : la case de visibilité est la dernière de la liste, sous les réglages de la page d’accueil et du nombre d’articles — c’est pour cela qu’on la manque si facilement au moment du lancement.

Il vaut la peine de savoir exactement ce que fait cette case. D’après la documentation, depuis la version 5.3, elle insère dans le code de la page la balise <meta name='robots' content='noindex,nofollow' />. La phrase qui suit mérite d’être retenue : « Neither of these options blocks access to your site — it is up to search engines to honor your request ». Autrement dit, le site reste accessible à quiconque connaît l’adresse, et les moteurs de recherche sont seulement priés de ne pas l’afficher. C’est une demande, pas une protection — si un site de test doit réellement rester invisible, on le ferme par un mot de passe.

La page d’accueil, la langue et le fuseau horaire. Par défaut, WordPress affiche en page d’accueil la liste des articles, ce qui correspond rarement à ce qu’on attend d’un site d’entreprise. Choisir une page d’accueil statique, la langue et le fuseau horaire — pour la Suisse, « Zurich » — prend une minute et, contrairement aux deux points précédents, se modifie à tout moment sans conséquence.

Les comptes et les rôles. Une installation neuve a un seul compte — le vôtre, avec tous les droits. Quand d’autres personnes travaillent sur le site, mieux vaut séparer les rôles tout de suite plutôt que de donner à tout le monde un accès administrateur « pour éviter les problèmes ». WordPress en compte cinq, et la différence est pratique : l’Administrateur peut tout faire, y compris installer des extensions et supprimer des comptes ; l’Éditeur gère le contenu de tout le site ; l’Auteur ne publie que ses propres articles ; le Contributeur rédige mais ne publie pas ; l’Abonné ne fait que lire.

La règle est la même que pour les extensions : chaque compte administrateur est un jeu d’identifiants de plus qui ouvre le site. Le prestataire, l’agence de marketing et la personne chargée des contenus n’ont, dans la plupart des cas, pas besoin de tous les droits — et au bout de deux ans, la liste des comptes ne ressemble plus à ce dont quiconque se souvient. C’est pourquoi sa revue est un point à part entière de la sécurisation du site.

La page de politique de confidentialité. WordPress intègre un outil qui en crée une ébauche (Réglages → Confidentialité). Cette ébauche n’est qu’un échafaudage. Pour une entreprise suisse, le cadre est la loi fédérale sur la protection des données révisée (nLPD), en vigueur depuis le 1er septembre 2023 ; et dès que vous traitez les données de personnes établies dans l’Union européenne, le RGPD s’applique en plus. Ce que la page doit contenir concrètement, nous le traitons dans le texte consacré à la protection des données sur le site — la rédaction des clauses elle-même reste un travail de juriste.

Deux ou trois langues : une décision du premier jour

Ici, un site d’entreprise en une seule langue est l’exception, et WordPress mérite qu’on sache précisément ce qu’il fait et ce qu’il ne fait pas dans ce domaine.

La langue de l’administration et celle du site sont deux choses. WordPress est traduit dans de nombreuses langues, et chaque utilisateur peut choisir la langue de son interface dans son profil : la personne qui rédige à Lausanne travaille en français, son collègue de Berne en allemand, sur le même site. Détail utile : il existe un pack « Deutsch (Schweiz) », mais pas de français de Suisse — un site francophone d’ici tourne en « Français », la variante de France.

Le cœur de WordPress ne gère qu’une langue de contenu par site. Publier le même site en français, en allemand et en anglais passe donc par une décision supplémentaire, et elle a le même caractère que la structure des adresses : elle se prend avant le premier contenu, parce qu’elle détermine la forme des adresses de chaque langue et la manière dont chaque page connaît ses traductions. Trois familles de solutions existent — une extension de traduction qui relie les versions entre elles dans une même installation, un réseau multisite avec un site par langue, ou des installations séparées. Elles coûtent à peu près la même chose à l’installation et pas du tout la même chose à vivre : la première se relit en une passe, la dernière se maintient comme plusieurs projets. Nous comparons ces modèles de traduction dans le texte sur le choix d’une plateforme.

La conséquence pratique est simple : si le site doit exister en plusieurs langues, même « plus tard », dites-le au moment de l’installation. Ajouter une langue à une structure pensée pour une seule, c’est reprendre les adresses, les menus et les liens internes d’un site déjà rempli.

Les extensions : 68 885 dans le répertoire, et pourquoi ce n’est pas une bonne nouvelle

Le répertoire officiel de WordPress compte aujourd’hui 68 885 extensions — c’est le chiffre que renvoie sa propre interface de programmation. Cela ressemble à un avantage, et c’en est parfois un, mais il y a un revers : 91 % des vulnérabilités découvertes dans l’écosystème WordPress concernent les extensions, et non le cœur. La répartition et ses conséquences sont détaillées dans notre texte sur les mises à jour.

D’où la seule règle qui compte vraiment lors de la première configuration : chaque extension est une chose de plus à mettre à jour et un point d’entrée de plus pour attaquer le site. Un site avec cinq extensions et un site avec trente, ce sont deux niveaux de risque et deux factures de maintenance différents, aussi consciencieusement que l’un et l’autre soient surveillés.

Pour un site d’entreprise ordinaire, il manque en général cinq choses après l’installation, et c’est par elles qu’il faut commencer :

• Un formulaire de contact — sans lui, le site ne recueille pas de demandes.
• Des sauvegardes — sauf si l’hébergeur les réalise d’une façon qui se laisse restaurer.
• Les réglages SEO de base — titres, descriptions et plan du site ; ce qui fait réellement la différence, nous le décrivons dans le texte sur le référencement.
• Un cache, si l’hébergement n’en a pas — il influe sur le temps de réponse du serveur, donc sur les Core Web Vitals.
• Une protection de la connexion — limitation des tentatives et second facteur, décrits dans le texte sur la sécurisation.

Chaque candidate se vérifie en trente secondes dans le répertoire, d’après trois informations affichées pour chaque entrée : le nombre d’installations actives, la date de la dernière mise à jour et la version de WordPress avec laquelle l’extension a été testée. Une extension sans mise à jour depuis deux ans n’est pas stable, elle est abandonnée. À titre de comparaison, les entrées les plus populaires du répertoire dépassent les dix millions d’installations actives et sont testées avec la version courante du cœur, aujourd’hui la 7.1.1.

Encore une chose que personne ne demande à l’installation et qui revient au bout d’un an : une extension désactivée n’est pas une extension supprimée. Inactive, elle reste sur le serveur, garde son code et peut toujours être vulnérable ; elle ne disparaît qu’une fois supprimée. Lors d’un rangement, mieux vaut donc supprimer que désactiver — avec une exception : les extensions qui stockent des données (formulaires, boutique, galeries) peuvent les emporter avec elles, alors on fait une sauvegarde avant.

Une remarque à part sur les constructeurs de pages. Une extension qui assemble la mise en page par glisser-déposer est une décision d’un autre poids qu’un formulaire de contact : elle change la façon dont chaque page est construite, et il est difficile d’en revenir. Nous les examinons dans le texte sur les constructeurs de pages.

Les commentaires. Un WordPress neuf les active pour tous les nouveaux articles, alors qu’un site d’entreprise en a rarement besoin. Laissés sans surveillance, ils collectent du spam qu’il faut supprimer à la main, et qui finit par se retrouver dans le contenu du site. Dans les réglages de discussion, on peut les désactiver par défaut ou exiger l’approbation de chaque commentaire ; l’un comme l’autre prend un instant et épargne un nettoyage hebdomadaire.

Quand quelque chose ne marche pas juste après l’installation

Trois choses cassent le plus souvent dans les premières heures, et toutes trois ont une cause simple.

Une page blanche ou un message d’erreur critique. C’est presque toujours une extension ou un thème qui ne s’accorde pas avec la version de PHP. WordPress envoie alors à l’adresse de l’administrateur un lien vers le mode de récupération, qui suspend le module fautif — c’est l’adresse que vous avez saisie dans le formulaire d’installation. Ce que signifie chaque code d’erreur et qui appeler dans chaque cas, nous le détaillons avec les erreurs serveur.

La page d’accueil fonctionne, les autres pages affichent « introuvable ». C’est le symptôme classique d’un changement de structure des adresses sur un serveur qui n’a pas activé la réécriture des adresses. Il suffit en général d’enregistrer à nouveau les réglages des permaliens dans l’administration ; si cela n’aide pas, la question part chez l’hébergeur. Ce qui se cache encore derrière une erreur 404, et quand il vaut mieux la laisser, nous le décrivons séparément.

Impossible d’entrer dans l’administration. Si ce n’est pas le mot de passe, c’est généralement une extension de sécurité qui a bloqué votre adresse IP après quelques tentatives manquées. Cela se vérifie depuis un téléphone, sur les données mobiles : si le site y répond, le blocage vise votre connexion.

L’apparence : le thème est une décision à part

Après l’installation, WordPress a activé l’un de ses thèmes par défaut, et cela suffit pour commencer à travailler sur les contenus. Le répertoire en compte 8 705, et le choix est plus délicat que celui des extensions, parce que le thème ne décide pas seulement de l’apparence : il décide aussi de ce qui restera le jour où vous en changerez.

Pour le premier quart d’heure, une seule règle suffit : n’installez pas un thème avec son contenu de démonstration tant que vous ne savez pas ce qui est quoi. L’import du « site comme dans l’aperçu » charge un lot complet de pages, d’images et de réglages d’exemple, qu’il faudra ensuite distinguer des vôtres. Le reste de cette décision a son propre texte, parce qu’elle ne tient pas dans un paragraphe.

Avant la mise en ligne

Sept points à cocher. Aucun ne prend plus de quelques minutes, et chacun coûte davantage s’il est oublié :

1. La version de PHP réglée sur la plus récente disponible dans l’interface de l’hébergement.
2. HTTPS fonctionne — adresse avec certificat, sans avertissement du navigateur.
3. La structure des adresses réglée et vérifiée sur une page.
4. La case « ne pas indexer » décochée — c’est le point qui s’efface le plus vite des mémoires.
5. Une sauvegarde réalisée et restaurée une fois, pour savoir qu’elle fonctionne.
6. Les mises à jour automatiques du cœur activées, les extensions selon une routine qui ne casse pas le site.
7. Le formulaire testé avec un vrai message plutôt qu’une supposition — et une surveillance qui vous signalera une panne avant votre client ; ce qu’elle doit vérifier, nous le décrivons dans le texte sur le monitoring.

S’y ajoute un outil que WordPress intègre et que presque personne n’ouvre : Outils → Santé du site. Il liste les problèmes de l’environnement — version de PHP trop ancienne, extensions PHP manquantes, mises à jour désactivées — c’est-à-dire exactement ce qui ne se voit pas sur le site.

Ce que ce texte laisse volontairement de côté

• Le choix du thème — un texte à part, parce que c’est une décision distincte, avec ses propres critères.
• Les constructeurs et éditeurs de mise en page — les constructeurs de pages et le créateur de site en abonnement sont une autre conversation que l’installation.
• La sécurisation du site après la mise en ligne — comment sécuriser un site.
• La routine de mises à jour — la mise à jour d’un site web.
• Les coûts — ce que coûtent le site et son entretien, nous le détaillons dans la rubrique consacrée aux prix.

Le résumé le plus court : l’installation est facile, et la facture vient des réglages qui la suivent. Réglez la version de PHP et la structure des adresses, décochez la case « ne pas indexer », saisissez votre propre adresse d’administrateur, décidez du modèle de langues — et seulement ensuite, attaquez les contenus. Un quart d’heure, et chacun de ces points corrigé plus tard coûte plusieurs fois plus.