Un éditeur de logiciel dont le site est le premier canal de vente — et la seule chose qu'il n'avait pas le temps de construire.

eEAT pose des capteurs de température dans les chambres froides et les réfrigérateurs, surtout chez des hôtels et des restaurants. Ce que ça remplace est très concret : le relevé manuel des températures, consigné à la main, qui sert à prouver le respect des normes d'hygiène alimentaire. Les mesures remontent en continu vers un service hébergé en Suisse, et une alerte part quand une valeur sort des clous.

Et l'essentiel de leurs clients arrive par la recherche en ligne. Leur site n'est donc pas une vitrine : c'est le haut de leur entonnoir de vente.

Le site tournait sur WordPress, chargé de greffons empilés au fil des années, et il était lent à s'afficher.

Il était maintenu en interne — par des gens dont le métier est précisément de construire des logiciels. Mais ces gens-là avaient leurs propres outils à livrer à leurs clients. Le site était la seule chose pour laquelle ils n'avaient pas de bande passante, et c'est exactement pour ça qu'ils sont venus nous chercher.

Or le temps de chargement compte dans la façon dont Google classe un site. Pour une entreprise dont le trafic vient de là, un site lent n'est pas un défaut de confort : c'est une perte de chiffre d'affaires qu'on ne voit jamais passer.

Un site construit sur mesure, rendu côté serveur : le contenu part dans le HTML livré, avant que le moindre script ne s'exécute. C'est ce qui fait qu'une page s'affiche vite, et c'est aussi ce qu'un robot d'indexation lit sans rien avoir à exécuter.

Autour, les détails qui font le reste : les images passent par l'optimiseur du cadre et sortent en WebP aux bonnes dimensions, la police est préchargée pour que le texte ne saute pas, le plan du site et le fichier d'exploration sont servis correctement.

La refonte a aussi été l'occasion de retravailler le design.

La question qu'on pose d'habitude à un projet de performance est : qu'est-ce que vous avez retiré ? Une animation, un carrousel, un outil de suivi, une police ? Parce qu'un site rapide est censé être un site où quelque chose a été sacrifié.

Ici la réponse est : rien. Il n'y a pas eu d'arbitrage douloureux, pas de fonctionnalité refusée. Sortir de WordPress et de son empilement de greffons a suffi.

C'est moins héroïque qu'un renoncement, et c'est plus utile à savoir : sur beaucoup de sites, la lenteur n'est pas le prix d'une fonctionnalité qu'on a voulue. C'est le prix d'un empilement que personne n'a décidé.

La vitesse fait entrer dans le classement. Elle ne fait pas être cité.

Le site porte donc, dans son code, dix-sept questions avec leurs réponses, balisées comme telles, un fil d'Ariane, des avis notés, et l'identité du site. Ce balisage-là est précisément ce qu'un moteur de réponse va chercher quand il compose une réponse plutôt qu'une liste de liens.

Un site rapide et muet se charge vite pour ne rien dire. La performance ouvre la porte ; c'est le contenu structuré qui fait entrer.

Ce n'est pas nous qui avons posé la performance comme critère. C'était leur critère numéro un, formulé comme tel avant le début du projet.

Ça change tout. Un projet web arrive d'habitude avec dix qualités souhaitables et aucune hiérarchie entre elles — c'est ce qui produit les sites qui font tout à moitié. Quand le client arrive avec un critère unique et qu'il le tient, chaque arbitrage technique a une réponse évidente.

Le reste du travail a été d'aller les voir. Nous sommes à Genève, ils sont à Lausanne : il aurait été facile de tout faire en visioconférence. Un atelier sur place, avec les bons interlocuteurs dans la pièce, a donné la base sur laquelle l'architecture, le design et le développement se sont appuyés ensuite.

[Ce que la refonte a changé en classement et en trafic n'a pas été mesuré de notre côté, et l'ancien site n'a jamais été relevé. Les chiffres existent dans leurs propres outils d'audience : c'est à eux de les donner.]