Chaque version visite le site avant vous

La journée a commencé par un audit complet de la plateforme. La page d’accueil était plus lourde qu’elle n’en avait l’air : son film de démonstration en lecture automatique était un fichier 1080p de 14 à 20 Mo par langue. Réencodé en 720p, il a ramené la page à environ un sixième de son poids, et le film démarre plus vite sur un téléphone.

Le même passage a corrigé une série de défauts d’accessibilité sur dix-neuf pages, des liens soulignés dans le texte aux blocs de code accessibles au clavier. Puis est venu le gros changement du jour : le site est passé à Next.js 16, qui compile avec Turbopack et donne à la couche de requêtes un nouveau nom et une nouvelle place dans le code.

Chaque mise en ligne avait déjà un contrôle. Il attendait que le bilan de santé de la nouvelle version réponde : le conteneur tourne, la base de données répond, l’API fonctionne. C’est utile, et ce n’est pas ce que vit un visiteur.

Un visiteur demande une page. Avant qu’elle ne soit dessinée, une petite couche de requêtes choisit la langue à servir, renvoie une personne non connectée hors du tableau de bord et marque chaque réponse avec la version qui l’a produite. Un bilan de santé peut être parfaitement vert alors que cette couche manque. Avec une couche renommée par la mise à jour du framework, nous voulions qu’une version qui ne sert pas de vraies pages soit impossible à publier, pas seulement improbable.

Le contrôle fait donc ce que ferait une personne attentive après une mise en ligne : il ouvre le site. Après le bilan de santé, il demande une poignée de vraies adresses et vérifie chaque réponse.

• La page d’accueil et la page des tarifs, sans préfixe de langue, doivent répondre normalement.
• Les pages d’accueil et des tarifs en français doivent répondre aussi, pour prouver les deux chemins de la couche de langue.
• Une adresse qui n’existe pas doit répondre 404, pour qu’un site qui dit oui à tout ne puisse pas passer.
• Le tableau de bord doit rediriger un visiteur non connecté, preuve que la couche de requêtes tourne.

Une version qui répond à l’API mais pas aux pages échoue, et le trafic reste sur la version précédente. Personne n’a besoin de remarquer quoi que ce soit.

Visiter des pages ne convainc que si l’on sait quelle version a répondu. Chaque réponse porte un en-tête avec le commit exact qui l’a construite, et le contrôle exige ce commit sur chaque page vérifiée. Une version plus ancienne, ou une copie en cache, ne peut pas passer à la place de la nouvelle.

L’ordre des opérations a changé le même jour. Nos tests et notre mise en ligne démarraient côte à côte à chaque changement, si bien qu’un test en échec ne pouvait pas arrêter une version. Désormais, la mise en ligne ne commence qu’après la réussite de toute la suite de tests, et elle construit précisément le commit testé. Avant tout déploiement, les tests démarrent le site compilé et font la même visite.

Au total, une nouvelle version de PageToVid franchit quatre étapes avant de vous parvenir :

1. 1toute la suite de tests passe sur ce commit précis
2. 2le site compilé démarre et réussit la visite des pages en test
3. 3la version déployée répond à son bilan de santé
4. 4la version déployée sert de vraies pages en deux langues, une vraie 404 et une redirection qui fonctionne, chacune marquée de son commit

Le principe est simple, et il guide désormais chaque contrôle que nous ajoutons : tester ce que la personne voit, pas seulement ce que la machine annonce. Un bilan de santé dit que le serveur est en vie. Seule une page dit que le produit fonctionne. D’autres chapitres de la plateforme sont sur le blog.