Le journal revient, et les outils disent leur version

Cette entrée parle du site et non du modèle, et elle commence par une mesure inconfortable. Entre le 2026-08-25 et le 2026-09-08, nous avons livré six pages, porté le site en japonais, en coréen et en français, reconstruit le mur de paiement et retiré un pré-remplissage qui dépensait le clip offert des gens à leur place. Cette page n’a pas bougé une seule fois, parce qu’elle ne contenait aucune entrée. Tout ce qui explorait le site voyait le même journal à chaque visite.

La fraîcheur est un signal de classement à part entière, et elle ne concerne pas que les articles — l’itération d’un outil compte aussi, mais seulement si un robot peut la voir. Le journal des changements est la seule chose ici qui transforme un déploiement en date.

Chaque entrée est une page

Le journal allait être un seul long défilement. C’est la bonne forme pour quelqu’un qui rattrape son retard et la mauvaise pour tout le reste : cinq entrées n’auraient fait qu’une URL, et la mesure de la hausse de prix — la seule chose sur ce domaine que personne d’autre n’a publiée — n’aurait pu être ni liée ni citée pour elle-même.

Chaque entrée a désormais une adresse sous /updates/. L’index ci-dessus conserve la chronologie et renvoie vers les entrées au lieu de réimprimer chaque corps : c’est une carte, pas une seconde copie.

Les outils disent quelle version ils sont

Chaque page d’outil porte maintenant Tool version 2026.09.4 en pied de page, lié ici, et la même chaîne parvient aux lecteurs machine sous forme de softwareVersion, accompagnée d’un pointeur releaseNotes. Elle est lue sur l’entrée la plus récente de cette page, si bien que la version et la note qui l’explique sont le même fichier et ne peuvent pas diverger.

Rien sur ces pages ne permettait auparavant de distinguer une page livrée la semaine dernière d’une page abandonnée depuis deux ans — or c’est exactement la comparaison qui se fait quand on met une interface tierce en balance avec la documentation de l’éditeur.

Trois flux

/feed.xml pour tout, /blog/feed.xml pour les articles, /updates/feed.xml pour les notes de version. Un sitemap dit qu’une URL existe ; un flux dit ceci est nouveau. La séparation tient à la différence de public — s’abonner aux changements livrés n’est pas s’abonner à des essais.

Des dates qui peuvent bouger, et un déploiement qui le dit

Quatre correctifs en dessous :

Neuf des quatorze pages d’outil ne pouvaient pas signaler un changement fonctionnel. La date de révision d’une page se déduit des fichiers dont son contenu provient, et pour la plupart des outils cette liste ne tenait que le texte — réécrire le compilateur de prompts derrière /prompt-generator ne changeait donc rien qu’un robot puisse observer. Chaque page d’outil nomme désormais la configuration qui régit son comportement.
Tous les modèles de prompt partageaient une même date. Le raisonnement était que plusieurs modèles logés dans un même fichier ne peuvent pas être distingués — mais un slug est une chaîne unique, donc git log -S retrouve le commit qui a introduit chacun d’eux.
Le déploiement dit maintenant à IndexNow ce qui a changé, sur une fenêtre de deux jours au lieu de resoumettre tout le site. Un ping qui dit toujours tout ne dit rien.
La génération des dates appelait git deux fois par route. Elle interroge une fois et répond depuis une table.

Ce qui n’est pas corrigé

Huit routes rapportent encore la même seconde, 2026-09-07T15:16:07Z. Nous avons vérifié si c’était un défaut : ce n’en est pas un, un seul commit a réellement ajouté quatre pages de scène, le guide des prompts et l’arbre français d’un seul coup. Les dater séparément serait exactement la fraîcheur inventée que ce pipeline existe pour refuser.