J'ai construit la première version de ce site sur Webflow, et j'ai aimé la construire là. Puis tout ce que je voulais faire s'est mis à réclamer du code sur mesure, ce qui me convenait très bien puisque j'aime écrire du code à peu près autant que j'aime concevoir. Sauf qu'il en fallait toujours plus. Le jour où j'ai regardé sérieusement ce qui était de moi et ce qui venait de l'outil, à peu près 90 % du site était du CSS et du JavaScript que j'avais écrits moi‑même, posés sur un abonnement.
C'est la maintenance qui a tranché, au bout du compte. Webflow sortait une fonctionnalité native et un morceau de mon code devenait redondant, ou se mettait à lutter contre elle. J'entretenais des contournements pour des problèmes qui avaient cessé d'exister. La localisation, que je voulais, était encore une option payante par‑dessus.
Donc : 90 % déjà à moi. Je me suis dit que j'allais aussi bien écrire les 10 % restants, tout posséder et arrêter de payer pour avoir le droit. Les 10 % restants étaient évidemment les difficiles.
Cet article parle de ce que cette reconstruction avait à voir avec la recherche. Le SXO, search experience optimization, c'est l'idée que le classement et l'expérience utilisateur sont un seul métier et non deux, et on l'explique en général en 5 piliers. Ces 5 piliers décrivent assez bien où mon temps est passé. Plutôt que d'expliquer la théorie, qu'on trouve partout, je vais les parcourir sur un site réel, y compris aux 2 endroits où je m'étais trompé sur mon propre travail.
Pourquoi le SXO, et pas seulement le SEO
Là où le SEO a cessé de suffire
J'ai passé une bonne partie de ma carrière du côté perdant de cette discussion. Une expression devait figurer dans un titre, dans cet ordre, même quand elle ne tenait pas dans la ligne et cassait la maquette pour laquelle celle‑ci avait été dessinée. Un mot‑clé doit occuper une place visible, donc il occupe une place visible, et la phrase autour finit par se lire comme si elle avait été écrite pour une machine, parce que c'était le cas. La version qui m'a le plus gêné, c'est un mot‑clé dans un bouton, là où on dispose de 3 ou 4 mots pour dire à quelqu'un ce qui va se passer s'il clique, et où on en dépense 2 pour un robot.
Ça avait un certain sens tant qu'un moteur de recherche ne savait que lire la page. Il comptait des mots‑clés, suivait des liens et devinait le reste, alors on écrivait pour la devinette. Si un libellé devenait plus difficile à saisir d'un coup d'œil, ou cessait de décrire ce qui se passerait en appuyant dessus, c'était le prix du classement et quelqu'un avait décidé qu'il valait la peine.
Il a cessé de ne savoir que lire la page il y a un moment déjà. Un moteur de recherche a maintenant une idée de si quelqu'un est resté ou est reparti vers les résultats pour cliquer sur le suivant, et de si la mise en page a bougé sous son pouce pendant que la page chargeait encore. Ces 2 choses mesurent l'expérience, et ces 2 choses nourrissent le classement.
La séparation était donc réelle, et elle s'est refermée. Les 2 camps avaient besoin d'outils différents et de gens différents pour les défendre, parce qu'un moteur de recherche ne voyait tout simplement pas ce dont les designers parlaient. Il en voit une bonne partie aujourd'hui, et les arguments que je perdais autrefois sont devenus, discrètement, des arguments de classement.
Le SXO se découpe en 5 piliers : la vitesse, l'expérience utilisateur, le contenu, l'intention de recherche, et le fait de regarder ce qui se passe ensuite. Je les prends dans cet ordre. Pas comme 5 définitions, qui sont à une recherche de distance, mais comme un compte rendu de ce que chacun est devenu sur un site précis.
Pilier 1 — Vitesse et mobile
L'essentiel de ce qui rend ce site rapide, je ne l'ai pas fait pour la vitesse.
Les polices sont le cas le plus net. Il y a 9 fichiers qui se chargent depuis mon propre serveur, ce qui se lit sur une checklist de performance comme une décision réfléchie, et ça n'en était pas une. J'ai choisi ces caractères en construisant la marque, parce que c'étaient les bons caractères, et une police sous licence vit sur votre propre serveur que les millisecondes vous intéressent ou non. La vitesse est venue gratuitement avec une décision prise pour de tout autres raisons.
Les statistiques ont pris le même chemin. Je ne fais pas tourner Google Analytics, et les raisons, à peu près dans l'ordre où je les ai pensées :
- J'avais déjà passé un moment pénible à configurer des tableaux de bord GA.
- Je n'aime pas beaucoup l'idée que de grandes entreprises aspirent des données.
- Je n'aime pas les cookies. Enfin si, j'adore les cookies, mais pas sur les sites web. Renoncer à GA m'a permis de renoncer aux cookies, ce qui m'a permis de renoncer à la bannière de cookies, et je préfère autant n'en infliger une à personne.
Mon choix de statistiques s'est donc porté sur Umami. Pourquoi, me direz‑vous ? Parce que c'est la meilleure alternative au monde ? Pour mon usage, oui, mais il se trouve aussi qu'elle porte un nom japonais qui va bien à une marque appelée Edokko, et ça pèse plus lourd dans l'équation que je ne voudrais l'admettre.
Rien de tout ça n'est un argument sur le poids de la page, et la page est plus légère quand même. Ça n'arrête pas de se produire, et c'est je crois le vrai sujet de ce pilier. Héberger les polices soi‑même parce qu'elles sont sous licence supprime une connexion vers le CDN de quelqu'un d'autre. Refuser un prestataire de statistiques en supprime une autre, avec son cookie, la bannière que le cookie exige, et le JavaScript que la bannière exige. Décider par principe et décider pour la vitesse n'ont pas arrêté d'arriver à la même réponse, ce qui relève soit de la chance, soit du signe que les 2 sont moins séparés qu'une checklist de performance ne le laisse croire.
Une chose ici, je l'ai bien décidée en pensant au visiteur. Les statistiques sont servies depuis ce domaine plutôt que depuis celui d'un prestataire, et un script qui vient du site qu'il mesure ne ressemble pas à un traceur pour un bloqueur. Les chiffres que j'obtiens sont donc les chiffres, et non les chiffres moins tous ceux qui font tourner uBlock.
Le reste est sans relief. La typographie s'échelonne avec clamp() depuis un téléphone jusqu'à la
largeur de 1440 px pour laquelle j'ai dessiné, donc rien ne saute à un point de rupture pour
rattraper son retard, et les pages sont construites à l'avance pour qu'un visiteur reçoive du HTML.
Mesuré sur le site en ligne le 9 août 2026, sur une connexion mobile bridée : 0,91 s et 0,0625, contre des seuils de 2,5 secondes et 0,1. Ce sont les pires des 4 routes que j'ai mesurées, pas les meilleures, parce que citer le meilleur chiffre de quoi que ce soit est la façon dont on finit par y croire.
Pilier 2 — UX : navigation et accessibilité
L'accessibilité, c'est là que j'ai découvert que le site me mentait.
J'avais construit un focus ring exprès, un halo bicolore réglé pour que quelqu'un qui navigue au clavier voie où il se trouve, sur le thème clair comme sur le sombre. Je l'avais vérifié en inspectant les éléments, et chaque élément interactif de la page déclarait posséder un indicateur de focus. J'ai arrêté d'y penser.
5 d'entre eux ne l'avaient jamais montré une seule fois : les cartes d'articles, la carte auteur,
les liens du sommaire, les boutons de partage. Tous sont à l'intérieur d'un conteneur en
overflow: hidden, qui rogne ce qu'un élément enfant peint en dehors de sa propre boîte, et un
outline se peint en dehors de la boîte. L'anneau était dessiné et jeté dans la même image. Celui du
navigateur aussi, d'ailleurs, et depuis bien avant que j'écrive la moindre ligne de CSS.
Ce qui m'a empêché d'être choqué, c'est d'avoir remarqué lesquels étaient concernés. Ce sont tous des composants que j'ai faits à la main pour ce site, alors que l'interrupteur dans l'en‑tête, lui, faisait les choses correctement, et celui‑là vient de Noren, le design system que je construis à côté. J'aurais trouvé cet argument suffisant venant de quelqu'un d'autre. Je ne peux pas non plus le contester, ayant mené l'expérience sur moi‑même par accident.
La moitié navigation de ce pilier est plus discrète et je la défendrais tout aussi fermement. Il y a 3 liens dans l'en‑tête du site, ce qui a demandé une certaine retenue. Un article porte un sommaire qui suit où vous en êtes pendant que vous faites défiler, et une barre de progression qui montre ce qu'il reste, ce qui compte plus qu'il n'y paraît sur un texte de 2 000 mots. Changer de langue ne recharge pas la page. Toutes les animations d'ici s'arrêtent si le système du visiteur demande une réduction des animations, y compris celle que je préfère.
Rien de tout cela n'était un chantier d'accessibilité séparé. C'est la même liste lue 2 fois. Le sommaire, ce sont de vrais liens avec de vrais textes, donc quelqu'un qui utilise un lecteur d'écran peut sauter de section en section au lieu d'écouter le tout, et tous les autres retrouvent leur place après être partis se faire un café. Respecter la réduction des animations épargne les gens que le mouvement rend malades, et épargne la batterie de tous les autres. Améliorer l'un améliore l'autre, et j'ai arrêté de tenir 2 listes.
Ce qui mérite d'être transmis tient à la méthode plutôt qu'au CSS. Un style calculé vous dit ce que le navigateur a calculé, ce qui est une autre question que ce qu'il a mis à l'écran, et je vérifiais la première en croyant avoir vérifié la seconde. Aucun outil automatique ne l'a attrapé non plus, puisqu'eux aussi lisent des styles calculés. Il y a maintenant un passage d'axe sur chaque route dans les 2 thèmes à chaque commit, au niveau WCAG 2.1 AA plus les bonnes pratiques, et il fait échouer le build au lieu de produire un rapport que j'apprendrais à faire défiler. Il n'aurait quand même pas attrapé ce bug‑là, et c'est pour ça que je compare aussi des captures d'écran maintenant.
Pilier 3 — Un contenu réellement structuré
La Gazette servait à autre chose.
Quand j'ai écrit cet article la première fois, c'était encore un site d'agence, et le blog faisait ce que font les blogs d'agence : du conseil général, à la deuxième personne, voici comment vous devriez aborder la chose. C'est un métier parfaitement légitime pour un blog. Ça a cessé d'être celui que je voulais donner à celui‑ci.
La consigne est maintenant plus étroite, et elle tient surtout à la précision. Ce que j'ai fait sur une chose précise, ce que ça m'a coûté, là où je m'étais trompé. L'article que vous lisez est le premier écrit de cette façon, et c'est une réécriture de l'un de ces 2 anciens, ce qui est soit propre, soit un peu trop bien tombé selon l'humeur.
C'est une décision structurelle autant qu'éditoriale. Un moteur de recherche qui cherche à savoir si une page mérite d'être classée cherche en partie à savoir si elle dit quelque chose que les autres résultats ne disent pas, et « les 5 piliers du SXO » est disponible partout, tandis que ce que ces 5 piliers ont coûté sur un site précis n'est disponible qu'ici. C'est le seul avantage durable qu'a un petit site, alors je préfère m'en servir plutôt que de concourir au volume contre des gens qui en ont davantage.
La moitié ingrate est réelle aussi. Un seul h1 par page, des titres qui ne sautent jamais un
niveau, et chaque article stocké par langue dans son propre fichier plutôt qu'un fichier unique avec
des traductions greffées sur le côté. Chaque article se décrit également lui‑même dans une forme
qu'une machine peut lire sans deviner : le titre, qui l'a écrit, quand, et dans quelle langue les
mots sont réellement écrits. Ce dernier point travaille plus qu'il n'en a l'air. Là où une URL
anglaise sert encore du français, parce que je n'ai pas fini de traduire, la page retient cette
description entièrement plutôt que de la remplir avec une langue dans laquelle elle n'est pas
écrite.
Pilier 4 — Comprendre l'intention de recherche
L'intention de recherche, c'est la question posée derrière les mots que quelqu'un a tapés. 2 personnes peuvent chercher la même chose et vouloir des pages différentes : l'une veut une définition, l'autre veut savoir si ça vaut son après‑midi. Se classer sur la requête puis décevoir celui qui arrive est pire que ne pas se classer, parce qu'il repart et que ce départ se mesure.
J'ai écrit ce texte pour le deuxième type de lecteur. « C'est quoi le SXO » trouve sa réponse à cent endroits, écrite par des gens qui ont plus d'autorité que moi sur le sujet, donc je n'ai pas écrit ça. Ce que presque personne n'écrit, c'est ce que les 5 piliers coûtent à quelqu'un qui les a réellement faits, et c'est précisément ce que j'aurais voulu lire à l'époque où j'étais celui qui perdait les discussions sur les boutons. C'est aussi la raison d'être de ce site. J'écris pour des gens qui veulent regarder quelque chose se construire, pas pour des gens qui veulent une définition, et ça décide de la forme de chaque article avant qu'un seul mot existe.
Sur un site bilingue, une deuxième intention se superpose à la première, celle de la langue, et le moyen le plus rapide de décevoir quelqu'un est de lui tendre le bon sujet dans la mauvaise.
Chaque article a son propre slug dans chaque langue, plutôt qu'un slug unique avec un drapeau de langue greffé dessus. Chaque page déclare ses équivalents, et nomme la version à servir à un visiteur pour lequel le site n'a pas de meilleure correspondance. Les canoniques sont explicites, le sitemap liste chaque URL avec ses sœurs de langue attachées, et il y a un flux RSS pour les gens qui préfèrent ne passer par l'algorithme de personne.
Et là où une URL anglaise sert du texte français, parce que je n'ai pas encore traduit celui‑là, la page déclare la vraie langue du texte et demande à ne pas être indexée. Elle n'est pas déguisée en traduction. La laisser dans l'index apporterait plus de trafic, et ce n'est pas quelque chose que j'ai envisagé de faire.
Pilier 5 — Regarder ce qui se passe ensuite
On appelle ce pilier la mesure, ce qui le sous‑vend. Ce qu'il veut dire en réalité, c'est une boucle : construire la chose, regarder ce qui s'est passé, apprendre quelque chose qu'on ignorait en la construisant, puis y retourner et faire mieux. Regarder est l'étape qu'on saute, moi compris, parce que construire est plus amusant et que personne ne vous oblige à vérifier.
Ce que je veux savoir de ce site, c'est si des gens reviennent.
C'est une question étroite et il y a un chiffre au bout, qu'Umami appelle la rétention. Les pages vues me disent qu'un billet a été partagé quelque part. La rétention me dit si la personne qui l'a lu a jugé que ça valait le retour, et comme l'intérêt de construire en public est de finir avec des gens qui suivent le travail plutôt que des gens arrivés une fois depuis un résultat de recherche, c'est le chiffre que j'ouvre en premier.
Le reste de ce que je regarde est court. Les pages vues par langue, qui me disent si écrire en anglais d'abord était le bon choix. D'où arrivent les lecteurs, pour savoir quelle plateforme vaut l'effort d'y publier. Et 4 événements qui couvrent ce qu'un lecteur peut réellement faire ici : partager un article, suivre un lien qui en sort, cliquer vers moi ailleurs, ou changer de langue. C'est toute la liste, parce que je ne voulais rien instrumenter dont je n'avais pas la question.
Le tout auto‑hébergé et sans cookie, ce qui fait qu'il n'y a pas de bannière sur ce site, non pas parce que j'ai trouvé un moyen de la contourner mais parce qu'il n'y a rien à mettre dedans.
La mesure qui a changé quelque chose, pourtant, n'était aucune de celles‑là. C'était du temps de processeur.
Ce site a un grain de pellicule par‑dessus tout par défaut, un canvas qui se repeint en continu. Je le soupçonnais depuis un moment, et quand j'ai fini par auditer les performances, j'y suis allé en comptant le condamner et le désactiver par défaut.
Il coûte bien quelque chose. Il s'est aussi avéré ne pas être le coûteux. Un bandeau défilant, le genre d'ornement qu'on cesse de voir au bout d'une semaine, faisait tourner sa boucle d'animation à chaque image sur 3 des types de pages de ce site, y compris quand il était entièrement sorti de l'écran. Rien ne lui avait jamais dit de s'arrêter, parce qu'il ne m'était jamais venu à l'esprit qu'il le devait. Il coûtait plus que le grain, pour quelque chose que personne ne regardait.
Ni l'un ni l'autre n'apparaissait dans les métriques habituelles. Les 2 sont bien trop petits pour compter comme tâches longues, et aucun ne bouge le largest contentful paint ni le décalage de mise en page. Les 2 choses qui coûtaient discrètement le plus étaient invisibles précisément pour les outils censés les trouver.
Mettre le bandeau en pause quand il est hors écran a pris 4 lignes et a réduit d'environ 3 quarts l'usage processeur au repos sur une page d'article. Le grain, je l'ai gardé. Son coût, une fois que j'ai pu le voir, était assez faible pour être ignoré. Je l'ai gardé parce qu'il fait partie de la marque. Edokko n'est pas censé avoir l'air propre. Le grain est là pour la même raison que les vignettes d'articles portent une texture, un peu de pensée Kintsugi, où l'on ne ponce pas la réparation pour la faire disparaître, on la laisse se voir. Ce qui est une chose étrange à dire d'une décision CSS, jusqu'à ce qu'on remarque que c'est aussi ce qu'est cet article en entier.
Conclusion
5 piliers font une carte convenable. Après les avoir parcourus sur un site, ce que j'ajouterais, c'est que 3 d'entre eux relevaient de la discipline et que 2 sont les endroits où il s'est passé quelque chose d'intéressant.
La vitesse, l'intention et la structure, vous savez déjà les faire, et le travail consiste à s'y tenir quand personne ne regarde. Ça aide d'accepter qu'une bonne part du résultat arrive de décisions prises pour des raisons sans rapport, ce qui est soit humiliant, soit soulageant selon le jour.
L'accessibilité et la mesure se sont comportées différemment, parce que toutes les 2 punissent le fait de faire confiance à ses propres outils. Mon focus ring était bon selon le navigateur et invisible à l'écran. Mon problème de performance s'est avéré être le composant d'à côté de celui que je soupçonnais.
Ce qui me laisse avec quelque chose qui ne parle pas vraiment de SXO. « J'ai vérifié » et « j'ai regardé » sont 2 verbes différents, et j'utilisais le premier en me disant que j'avais fait le second.
