Comment construire un site web d’entreprise : notes sur notre propre site

Le site d’une entreprise de logiciels est le premier logiciel qu’elle écrit. Le visiteur qui l’ouvre ne voit pas le code, mais il en voit le résultat. Si la page s’ouvre lentement, si une phrase en turc traîne dans une autre langue, si le formulaire de contact échoue en silence, il en tire des conclusions sur le travail de l’entreprise.

C’est pourquoi nous avons construit ce site non comme une brochure, mais comme un petit produit. J’écris ci-dessous quelles décisions nous avons prises, pourquoi, et où nous nous sommes trompés.

Génération statique

Le site est écrit avec Next.js. Dans la première version, les pages étaient régénérées sur le serveur à chaque requête. La cause était une ligne innocente : la mise en page racine lisait l’en-tête de la requête pour trouver la langue. Next considère comme dynamique toute page où il voit cela.

Résultat : Cloudflare ne pouvait mettre aucune page en cache. Chaque visite remontait jusqu’au serveur chez Hetzner. En local, le temps jusqu’au premier octet était de quelques millisecondes. Le code n’était donc pas lent. Le problème allait apparaître à grande échelle.

La solution a été de déduire la langue de l’adresse, et non de la requête. Chaque langue a sa propre mise en page racine, et la langue découle du dossier où se trouve la page. Aujourd’hui, les quelque trois cents pages sont toutes générées une seule fois, à la compilation.

Sept langues et la cohérence

Le site est publié en turc, anglais, français, portugais, allemand, espagnol et arabe. La traduction en elle-même est la partie facile. Le difficile, c’est qu’un texte modifié doit changer à sept endroits à la fois.

La plupart des erreurs trouvées lors des premiers contrôles venaient du même schéma. Une longue chaîne de conditions choisissait le texte selon la langue. Quand elle oubliait une langue, elle tombait en silence dans la dernière branche, et cette dernière branche était généralement le turc. C’est ainsi qu’une phrase en turc apparaissait au milieu d’une page en français.

Nous avons réglé cela avec une fonction utilitaire. Chaque endroit qui choisit un texte doit fournir les sept langues à la fois. S’il en manque une, le code ne compile pas. L’erreur est détectée avant la mise en ligne.

Le titre académique posait un problème semblable. Dans une traduction, le titre « Doç. Dr. » était devenu « professeur ». Désormais, le titre n’est traduit dans aucune langue. Il est repris de la fiche en turc, et un test le vérifie à chaque push.

Les tests

Nous n’avons pas mis en place un framework de test lourd. Nous avons écrit neuf tests avec le module de test intégré de Node. Chacun détecte une erreur que nous avons réellement rencontrée.

Parmi eux : le titre doit rester identique dans toutes les langues, aucun texte ne doit contenir de tiret cadratin, le nom de la marque ne doit pas être traduit, chaque article en turc doit avoir son équivalent dans les six autres langues, et les textes juridiques ne doivent pas être résumés à la traduction. Le dernier test est grossier mais il fonctionne. Si la page juridique d’une langue fait moins de soixante pour cent de la version turque, elle a très probablement été résumée.

À chaque push sur GitHub, la vérification des types, le lint, ces tests et la compilation de production s’exécutent. Si l’un d’eux échoue, la version n’est pas mise en ligne.

La sécurité

La politique de sécurité du contenu est stricte. Aucun script, aucune police, aucune image ne peut être chargé depuis un domaine externe. Les polices viennent de notre propre serveur. Le navigateur du visiteur n’envoie donc aucune requête à un tiers en ouvrant la page. Google Analytics n’est chargé que si le visiteur donne son consentement.

L’écran de protocole de travail de la page d’accueil envoie à un modèle de langage le texte saisi par le visiteur. C’est l’endroit du site le plus facile à détourner. Quelqu’un qui voudrait utiliser gratuitement un modèle payant pourrait appeler directement le point d’accès. Nous l’en empêchons avec plusieurs couches : la vérification que la requête vient bien de notre page, un jeton signé à usage unique et de courte durée, une limite horaire et quotidienne par adresse, un plafond quotidien pour l’ensemble du site et une limite sur le nombre de requêtes qui peuvent atteindre le modèle en même temps.

Le déploiement

Le code est sur GitHub. Coolify tourne sur le serveur chez Hetzner. À chaque push sur la branche principale, il recompile le site sous forme d’image Docker et le met en ligne. Un déploiement prend environ deux minutes et demie.

Cloudflare se trouve devant. Depuis le passage à la génération statique, le HTML peut lui aussi être mis en cache, et les pages y restent jusqu’à une heure.

Où nous nous sommes trompés

Le cache a été une source de vitesse, mais aussi d’illusion. Nous avons mis en ligne une nouvelle version. Coolify a indiqué un succès, mais la page d’accueil s’affichait dans son ancien état. La raison était simple. Cloudflare ne demandait pas la nouvelle copie tant que la sienne n’avait pas expiré.

La bonne solution est de vider le cache automatiquement à la fin de chaque déploiement. Une mise en ligne n’est terminée que lorsqu’elle l’est là où le visiteur la voit, pas seulement sur le serveur.

Il y a aussi l’accessibilité. L’analyse automatique ne trouvait aucune erreur sur les pages. Pourtant, les petites étiquettes de la page d’accueil étaient posées sur une photo semi-transparente, et l’outil d’analyse ne sait pas mesurer le contraste sur une photo. Nous avons mesuré à part les pixels derrière les étiquettes. Le rapport tournait autour de 3:1. En atténuant un peu la photo et en fonçant les étiquettes d’un ton, il est passé au-dessus de 5:1. Même quand l’outil dit « aucune erreur », il faut regarder.

Pourquoi nous le racontons

Dire à un client « nous livrons des logiciels qui fonctionnent » est facile. En écrivant clairement ce que nous avons fait sur ce site, on voit aussi plus facilement sur quoi repose cette phrase.