Sous le capot : serveur web, PHP et base de données

Module 1: Comment fonctionne WordPress · Temps de lecture : 8 minutes

Objectif pédagogique : Après cette leçon, vous pourrez expliquer étape par étape comment une requête de page devient, sous WordPress, une page HTML, et à quel endroit un cache raccourcit ce parcours.

Notions clés : serveur web (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, requête, index.php, hiérarchie de modèles, dynamique vs statique, TTFB

Une page statique et une page dynamique

Sur un site statique, chaque page existe sous forme de fichier prêt à l'emploi sur le serveur. Le serveur web récupère le fichier et l'envoie. C'est rapide et simple, mais chaque modification nécessite un nouveau fichier.

WordPress est dynamique : la page n'existe qu'au moment où quelqu'un la demande. Il n'y a pas de fichier contact.html. Il y a un texte dans la base de données, un thème avec des modèles et un ensemble de code PHP qui assemble les deux. Cela apporte de la simplicité (vous modifiez le texte depuis votre navigateur), mais cela demande du travail de calcul à chaque visite. Si vous comprenez ce travail de calcul, vous comprendrez aussi plus tard pourquoi un site est lent, pourquoi la mise en cache change autant de choses et pourquoi une mise à niveau de PHP peut parfois tout casser.

Le parcours d'une requête de page

Supposons qu'un visiteur ouvre https://example.com/contact/. Voici ce qui se passe :

1. DNS : le navigateur recherche l'adresse IP de example.com (voir la formation DNS). Il établit une connexion sécurisée avec cette adresse.
2. Serveur web : sur le serveur tourne un serveur web, par exemple LiteSpeed, Apache ou nginx. Celui-ci reçoit la requête. Si un fichier ou un dossier réel portant ce nom existe (une image, une feuille de style), il l'envoie directement. Sinon, la règle du fichier .htaccess (pour LiteSpeed et Apache) ou de la configuration nginx s'applique : « transmettre tout ce qui n'existe pas à index.php ».
3. PHP : index.php est un fichier PHP. Le serveur web le fait exécuter par PHP, le langage de programmation dans lequel WordPress est écrit. PHP charge d'abord wp-config.php (les réglages, avec les informations de la base de données), puis le reste de WordPress, puis toutes les extensions actives et le thème actif.
4. Base de données : WordPress détermine quel contenu correspond à /contact/ et interroge la base de données (MariaDB ou MySQL) : quelle page possède le slug contact, quels sont les réglages du site, quel menu lui est associé ? Une telle question s'appelle une requête. Une page simple nécessite déjà rapidement des dizaines de requêtes ; avec des extensions, ce nombre peut atteindre plusieurs centaines.
5. Thème : WordPress choisit quel modèle du thème met en forme la page. Cela se fait selon la hiérarchie de modèles : pour une page avec le slug contact, WordPress cherche d'abord un modèle page-contact, puis page-<id> (le numéro de la page), puis page, puis singular et finalement index. Le premier modèle qui existe l'emporte.
6. Retour du HTML : le résultat est une page HTML que PHP transmet au serveur web, et que le serveur web transmet au navigateur.
7. Le navigateur lit le HTML et récupère ensuite les feuilles de style, les scripts, les polices et les images. Ce sont bien des fichiers ordinaires, qui proviennent donc directement du serveur web (ou d'un cache).

Entre l'étape 2 et l'étape 6 se situe le temps dont le serveur a besoin pour construire la page. Vous le retrouvez sous la forme du TTFB (time to first byte) : le temps entre la requête et le premier octet de la réponse. Sur un site bien configuré, ce temps est largement inférieur à une seconde. Vous le mesurerez vous-même au module 6.

Pourquoi chaque extension compte

À l'étape 3, toutes les extensions actives sont chargées, à chaque requête. Même si cette extension ne fait rien sur cette page en particulier. Une extension de galerie photo est ainsi également chargée lorsque quelqu'un ouvre votre page de contact. Chaque extension peut effectuer des requêtes supplémentaires, charger du code supplémentaire et ajouter des scripts supplémentaires à la page.

Cela explique deux choses que vous rencontrerez plus souvent dans cette formation :

• Moins d'extensions, c'est généralement plus rapide. Pas parce que le nombre compte en soi, mais parce que chaque extension peut effectuer du travail à chaque requête.
• Une seule extension défectueuse peut paralyser tout le site. Si quelque chose se passe mal à l'étape 3 (par exemple une extension qui ne fonctionne pas avec la nouvelle version de PHP), PHP n'atteint jamais l'étape 6. Le visiteur obtient une page blanche ou le message « Une erreur critique s'est produite sur ce site » (leçon 5.4).

D'où viennent PHP et la base de données

PHP et la base de données fonctionnent sur le serveur de votre hébergeur. Vous choisissez généralement vous-même la version de PHP dans le panneau de contrôle (chez DirectAdmin, cela s'appelle Select PHP version, voir leçon 8.4). La base de données est créée lors de l'installation ; l'installeur le fait souvent automatiquement pour vous (leçon 2.2).

Quelques points à retenir :

• Version de PHP : chaque nouvelle version de PHP est plus rapide et plus sûre, mais du code ancien peut s'y heurter. wordpress.org recommande actuellement PHP 8.3 ou supérieur (situation en novembre 2026).
• Base de données : wordpress.org recommande MariaDB 10.11 ou supérieur, ou MySQL 8.0 ou supérieur. MariaDB est une dérivation de MySQL ; pour WordPress, cela ne fait aucune différence.
• La base de données se trouve généralement sur le même serveur (DB_HOST vaut alors localhost). Pour des hébergements plus importants, elle peut se trouver sur un serveur séparé.

Le cache : raccourcir le parcours

Si cent visiteurs demandent la même page de contact, WordPress la recrée cent fois sans cache. Chaque fois les mêmes requêtes, le même modèle, le même HTML. Un cache de page conserve le HTML après la première fois. Le visiteur suivant reçoit la version enregistrée : les étapes 3 à 6 sont ainsi évitées.

Zonder cache:  browser > webserver > PHP > WordPress + plugins > database > thema > HTML
Met cache:     browser > webserver > opgeslagen HTML

C'est pourquoi la mise en cache apporte le plus grand gain de vitesse (leçon 6.2). Cela explique aussi une confusion fréquente : « j'ai modifié le texte, mais je vois toujours l'ancienne version ». Dans ce cas, vous recevez une version enregistrée ; après avoir vidé le cache, vous verrez la nouvelle.

Tout ne peut pas provenir d'un cache. Un administrateur connecté, un panier d'achat ou une page de paiement sont différents pour chaque visiteur. Une bonne extension de cache les exclut.

En-têtes : ce que le serveur vous indique

Chaque réponse d'un serveur web commence par des en-têtes (headers), avant le HTML. Vous ne les voyez pas sur la page, mais bien dans les outils de développement de votre navigateur (F12, onglet Réseau, cliquez sur la première requête). Un exemple :

HTTP/2 200
server: LiteSpeed
content-type: text/html; charset=UTF-8
link: <https://example.com/wp-json/>; rel="https://api.w.org/"
x-litespeed-cache: hit

• server indique quel serveur web répond.
• link avec wp-json révèle qu'il s'agit de WordPress.
• x-litespeed-cache: hit signifie que cette page provient du cache LiteSpeed. D'autres caches utilisent d'autres noms, comme x-cache: HIT ou cf-cache-status: HIT chez Cloudflare.

Vous n'avez pas besoin de connaître ces en-têtes par cœur. Mais celui qui sait les lire peut résoudre beaucoup de problèmes par lui-même.

Résumé

• WordPress construit chaque page au moment de la requête : serveur web, PHP, extensions, base de données, thème, HTML.
• À chaque requête, toutes les extensions actives sont chargées ; une seule extension défectueuse peut arrêter tout le site.
• La hiérarchie de modèles détermine quel modèle du thème met en forme une page.
• Un cache de page évite le travail de calcul en fournissant du HTML enregistré. Les utilisateurs connectés et les paniers d'achat n'ont pas leur place dans ce cache.
• Les en-têtes d'une réponse indiquent quel serveur web répond et si la page provenait d'un cache.

Quiz

Exercice

Exercice A1.2 : Lisez les en-têtes de votre site. Ouvrez votre propre site (ou wordpress.org) avec les outils de développement de votre navigateur (F12, onglet Réseau, actualisez la page, cliquez sur la première requête). Indiquez quel serveur web figure dans l'en-tête server (ou « aucun » si elle est absente) et s'il existe un en-tête indiquant que la page provenait d'un cache (quel nom et quelle valeur). Le programme demande la même page et compare.

Pour aller plus loin

Ces articles décrivent les étapes dans les panneaux de WebOké ; dans d'autres panneaux, le fonctionnement est similaire.

• Guide DirectAdmin 1.9: Notions expliquées : domaine, sous-domaine, pointeur, DNS, boîte e-mail et base de données
• Guide DirectAdmin 14.1: Choisir la version de PHP (Select PHP version)
• Cours DNS gratuit 1.4: Le voyage d'une requête DNS
• Hiérarchie de modèles (developer.wordpress.org, en anglais) : https://developer.wordpress.org/themes/basics/template-hierarchy/