Sous le capot : comment ce site est construit

Cette page est technique.

Elle s’adresse à ceux qui veulent savoir comment ce site est fait, et vérifier que ce que j’avance tient.

Je ne vends pas une méthode que je n’applique pas à mon propre site.

Le meilleur moyen de le prouver était de tout écrire.

Aucune extension

Un site WordPress ordinaire en compte entre quinze et quarante.

Celui‑ci n’en a aucune.

Tout ce qu’une extension ferait est écrit dans le thème, en 24 modules qui font ensemble 8 800 lignes de PHP : le référencement, le plan du site, le formulaire de contact et son filtre anti‑robots, le maillage entre les pages, la politique de sécurité, la minification des feuilles de style, le registre des demandes reçues.

Ce n’est pas une coquetterie.

La très grande majorité des sites WordPress compromis le sont par une extension : abandonnée, mal écrite, ou simplement pas mise à jour.

Ce qui n’existe pas ne se pirate pas, et ne casse pas à la mise à jour suivante.

Le revers est honnête à dire : ce site dépend de moi.

Un confrère qui le reprendrait devrait lire le code plutôt que de cliquer dans une interface.

C’est pourquoi chaque module est commenté en français, et dit pourquoi il existe.

Aucune requête vers l’extérieur

Quand vous chargez cette page, votre navigateur ne contacte qu’un seul serveur : le mien.

• Les polices sont hébergées ici, pas chez Google. Votre adresse IP n’est transmise à personne.
• Aucun outil de mesure d’audience, donc aucun cookie, donc pas de bandeau de consentement à vous imposer.
• Aucune vidéo intégrée, aucune carte, aucun bouton de réseau social, aucune bibliothèque chargée depuis un service tiers.

La contrepartie, je l’assume : je ne sais pas combien de personnes visitent ce site, ni ce qu’elles y lisent.

Je le lis dans les journaux du serveur, ce qui est moins précis et parfaitement suffisant.

La page « Aucun cookie » explique comment le vérifier vous‑même en trente secondes.

Une seule feuille de style

Les styles sont écrits à la main, un peu plus de 4 000 lignes, sans aucun cadre du commerce.

Le thème sur lequel ce site est bâti, lui, en apporte 210 kilooctets, dont l’essentiel vise des fonctions que ce site n’utilise pas : constructeurs de pages, carrousels, traduction, dispositions d’en‑tête alternatives.

Ces feuilles sont donc débarrassées de ce qui ne sert pas, puis fusionnées avec les miennes.

Le navigateur reçoit une seule feuille de style au lieu de quatre. Elle pèse 110 kilooctets, dont 18 franchissent réellement le réseau : la compression fait le reste.

Et rien d’autre. WordPress et le thème d’origine ajoutent d’office une trentaine de kilooctets de styles dans chaque page, sans rien demander. Ils sont retirés : il en reste cent octets.

Le tri s’appuie sur les classes relevées sur les 601 adresses du site, pas sur un échantillon : la règle qu’on retire est toujours celle de la page qu’on n’a pas regardée.

Et si le thème est mis à jour un jour, le site recharge tout seul les feuilles d’origine plutôt que de servir un tri devenu faux.

Il n’y a plus aucun fichier JavaScript à télécharger. Le thème d’origine en chargeait trois, jQuery compris : 37 kilooctets pour un menu mobile et des composants que ce site n’utilise pas. Ils sont remplacés par 25 lignes écrites à la main, 778 octets posés dans la page, sous jeton.

Les images sont en WebP, dimensionnées avant d’être déposées, et les illustrations sont dessinées, pas achetées en banque d’images.

Le serveur

nginx sur un serveur dédié, avec HTTP/2, Brotli et gzip.

Pas de mutualisé, pas de panneau de gestion : la configuration est écrite, commentée et sauvegardée.

Les fichiers statiques sont servis directement par nginx, sans passer par PHP, avec un cache d’un mois.

Les sauvegardes sont contrôlées, pas seulement programmées.

Une archive dont personne n’a jamais vérifié le contenu n’est pas une sauvegarde : c’est seulement un fichier de plus sur un disque.

Chaque jeu est ouvert, et son empreinte comparée des deux côtés du transfert.

La sécurité, en plusieurs couches

Un site n’est pas protégé par une mesure, mais par plusieurs, disposées de telle sorte qu’aucune brèche seule ne donne les clés.

La première couche, c’est l’absence d’extension, dont je parlais plus haut : la porte d’entrée la plus courante n’existe pas ici.

Viennent ensuite six en‑têtes de sécurité, présents sur toutes les réponses du serveur, y compris les fichiers statiques et l’administration.

La politique de sécurité du contenu n’utilise pas unsafe-inline.

Chaque script en ligne porte un jeton unique, régénéré à chaque chargement de page : un script injecté par un tiers ne s’exécute pas, faute de connaître ce jeton.

La plupart des sites laissent unsafe-inline parce que c’est plus simple, ce qui revient à ouvrir la porte qu’on venait de poser.

Sur le serveur, les fichiers ne sont modifiables que par leur propriétaire, et les fonctions de PHP qui donnent accès au système sont désactivées côté site.

Concrètement, un fichier malveillant qui parviendrait à se déposer ne pourrait ni s’exécuter dans le dossier des images, ni ouvrir un terminal.

Un pare‑feu bannit automatiquement les adresses qui vont frapper aux portes qu’un visiteur ne demande jamais, comme un fichier de configuration ou un dépôt de code.

Un plafond de requêtes par visiteur écarte les tentatives d’ouverture en force, avant même que le site n’ait à y répondre.

L’accès au serveur se fait par clé, jamais par mot de passe, et les portes d’entrée habituelles de WordPress ne répondent pas.

Le formulaire, enfin, est protégé par un filtre anti‑robots qui ne conserve jamais votre adresse IP en clair, et les demandes reçues sont effacées automatiquement après trois ans.

Le détail figure sur la page de confidentialité.

La structure éditoriale

601 adresses, dont 560 articles, organisées en silos thématiques.

Chaque article renvoie à ses voisins du même sujet, et remonte vers sa page d’expertise.

Aucun lien ne sort d’un silo pour tomber dans un autre, ce qui concentre l’autorité au lieu de la disperser.

Les archives de catégorie sont en noindex, follow : elles restent utiles au visiteur, et cessent de concurrencer les pages qu’elles listent.

Le site publie aussi un fichier llms.txt, qui décrit son contenu aux assistants conversationnels.

Peu de sites le font aujourd’hui : c’est un pari, pas une certitude.

Ce que ça donne à la mesure

Les meilleures notes aux quatre mesures de Google, en mobile comme sur ordinateur : performance, accessibilité, bonnes pratiques et référencement.

Vous pouvez le vérifier vous‑même, chez Google, sans me croire sur parole.

Les en‑têtes de sécurité se vérifient ici, de la même façon.

Maintenant la réserve, et elle compte.

Ces notes récompensent des réglages qui n’ont parfois aucun effet sur ce que voit un visiteur.

Courir après le score conduit à dégrader un site pour gagner des points.

Ce qui compte vraiment, c’est la page qui s’affiche avant que le visiteur ait le temps de partir.

Le reste est une conséquence.

Ce que je n’ai pas fait, et pourquoi

C’est la partie qui manque à la plupart des pages de ce genre.

C’est pourtant la seule qui se vérifie.

• La feuille de style est unique pour tout le site. Environ 16 kilooctets de ses règles ne servent pas à la page qui les charge. La découper par gabarit ferait gagner quelques dizaines de millisecondes au premier affichage, au prix d’un fichier par type de page, et d’un cache qui ne suit plus le visiteur d’une page à l’autre.
• Le site n’a pas de cache applicatif. Il est assez léger pour s’en passer, et un cache mal réglé cause plus de pannes qu’il ne règle de lenteurs.
• Il n’y a pas de mesure d’audience, donc pas de chiffre précis sur les visiteurs. C’est un choix, et il a un coût.
• Les styles ne sont pas intégrés au document. On gagnerait encore quelques dizaines de millisecondes, au prix d’une page plus lourde à chaque visite et d’un code nettement moins clair.

Chacun de ces points est un arbitrage, pas un oubli.

Un site parfait sur le papier qui casse à la première mise à jour ne rend service à personne.

Pourquoi cette page existe

Parce qu’un prestataire qui annonce des résultats sans les montrer demande qu’on le croie sur parole.

Tout ce qui touche à l’affichage se vérifie depuis l’extérieur : le code source, les en‑têtes du serveur, les outils de mesure publics.

Je préfère l’écrire moi‑même, correctement, plutôt que de laisser chacun deviner.

Si vous voulez la même chose sur votre site, écrivez‑moi.

Et si vous êtes du métier et que vous voyez une erreur dans cette page, écrivez‑moi aussi : je la corrigerai.