Ce que les tests vérifient d’abord

Avant qu’ipe.rest change, 137 petits tests le vérifient sur notre propre machine. Ils prennent environ huit secondes, sept seulement tournent aussi à chaque déploiement, et certaines choses leur échappent. Voici ce qu’ils regardent.

L’article d’hier parlait de fichiers pour les machines. Celui-ci parle de ce que les lecteurs ne croisent jamais : les vérifications qui tournent avant qu’une page soit publiée. Les chiffres datent du 8 novembre 2026 et viennent du dépôt tel qu’il était avant l’ajout de cet article : une commande, python3 -m unittest discover tests, 137 tests, tous réussis.

Dix fichiers, une commande

Les tests se trouvent dans dix fichiers, 1 850 lignes en tout. L’essentiel concerne le journal : 56 des 137 portent sur ses pages. 23 autres couvrent les autres pages, comme à propos, contact, confidentialité et conditions, et 18 couvrent la page d’accueil. Le reste forme de petits groupes : 9 pour les notifications aux moteurs de recherche, 8 pour les données structurées, 7 pour le déploiement, 7 pour l’affichage des heures, 4 pour le service worker, 4 pour les liens et les versions des ressources, et 1 pour l’image de partage.

Ce qu’ils détectent

Beaucoup de pages d’ici sont générées à partir de nos sources : les articles du journal, le plan du site, le flux, llms.txt et les cartes de la page d’accueil. Un test échoue si un fichier généré n’est pas à jour, si bien que personne ne peut en modifier un à la main et oublier la source.

D’autres tests veillent sur les langues. Chaque article doit exister dans chacune des douze langues, chaque page doit renvoyer vers les autres et vers elle-même, et le plan du site doit lister les mêmes liens que la page. D’autres veillent sur les règles que nous nous sommes fixées : un nouvel article de moins de 300 mots est refusé, un de moins de 400 mots n’obtient qu’un avertissement, un article daté du futur est renvoyé, et la description d’une page ne peut pas être coupée par des points de suspension.

Le service worker, qui permet d’ouvrir une page hors connexion, a un nom de cache qui porte un numéro de version. Un test vérifie que la version dans les liens vers les ressources de chaque page correspond à celle que liste le service worker, afin qu’une feuille de style modifiée ne soit pas servie périmée.

Les sept qui tournent à chaque déploiement

Un seul fichier, qui contient 7 de ces tests, tourne dans le flux de déploiement. Il vérifie le site construit et non le dépôt : que les fichiers dont un visiteur a besoin sont là, que des dossiers comme scripts et tests ne sont pas mis en ligne, et que la page 404 est marquée noindex et renvoie vers l’accueil. S’il échoue, le déploiement s’arrête avant que rien soit publié.

Les 130 autres sont une habitude, pas une barrière. Nous les lançons avant de valider une modification, et rien sur le serveur ne nous y oblige.

Ce qu’ils ne voient pas

Un test réussi dit que les pages s’accordent entre elles, pas qu’elles sont bonnes. Aucun test ne lit les dix traductions ébauchées par machine pour en juger le sens, ce qui explique que ces pages portent une note de traduction par IA. Aucun test d’ici n’ouvre un navigateur : la mise en page sur un écran de téléphone étroit se vérifie à l’œil. Et nous ne pouvons pas dire si un robot d’exploration remarque le soin que nous mettons à garder ces fichiers alignés.

ipe(); // check the plain things, every time

Presque tout ce qui garde un site tranquille tranquille est ennuyeux : un compte qui tombe juste, un lien qui répond, une version qui a avancé. Nous préférons qu’une machine vérifie cela pendant huit secondes plutôt que d’espérer y avoir pensé.