Event Scout

Une page d'événement est un mauvais format de données. La même information figure une fois sous forme de tableau, une fois dans le texte d'une newsletter, une fois dans un agenda qui ne se charge qu'en faisant défiler. Une expression régulière y échoue, un modèle de langage non. C'est donc précisément là, et seulement là, que se place le modèle : il lit les pages récupérées, décide de ce qui constitue un événement futur en présentiel à portée, et remplit pour chacun les champs d'un schéma fixe.

Tout ce qui précède et suit est du code ordinaire. Quelles sources sont dues aujourd'hui, comment elles sont récupérées, quand deux entrées désignent le même événement, ce qui sort du registre au bout d'un an et l'apparence du tableau de bord sont écrits dans le code, et non dans une consigne au modèle. Le modèle n'écrit pas non plus lui-même dans le registre. Il livre un fichier, et un script l'intègre dans events.json selon des règles fixes.

Ce fichier est le contrat. Il a un schéma défini, il est l'unique source de vérité, et chaque vue en est générée. Il n'y a ni base de données, ni serveur, ni abonnement. Il en découle l'avantage pratique le plus important : quand quelque chose semble faux, on peut ouvrir le fichier et voir si l'erreur vient de la lecture ou des règles.

Que les règles soient du code ne les rend pas justes. La première version du dédoublonnage considérait deux entrées comme le même événement dès qu'elles portaient le même lien. Or beaucoup d'organisateurs publient toutes les dates d'une série sous une seule page de synthèse, et c'est ainsi qu'en une seule exécution 23 nouvelles dates ont disparu dans leurs prédécesseurs plus anciens. On l'a remarqué parce que l'erreur laissait une trace vérifiable : des événements passés marqués comme retrouvés le jour même. Depuis, un lien identique ne compte comme correspondance que si les dates de début sont espacées de trois jours au plus.

Un modèle de langage sait bien lire une page désordonnée. Tenir un registre n'est pas une tâche de ce genre.

Une source consultée chaque semaine avec la même minutie coûte du temps, même si elle n'a rien livré d'utile depuis des mois. Chaque source tient donc un court historique de rendement : combien d'événements le modèle en a retenus lors des cinq dernières exécutions. La moyenne la place dans l'une de trois bandes. Le jugement du modèle ne pilote ainsi la planification qu'à travers un nombre compté.

La bande A est consultée à chaque exécution. Elle réunit les sources dont la moyenne atteint au moins trois événements retenus et celles jugées particulièrement importantes, même après une exécution vide. La bande B contient les sources ayant un certain rendement ou encore sans historique ; elles redeviennent dues après sept jours, huit au plus par exécution, les plus anciennes d'abord. La bande C regroupe les sources qui ne livrent rien à répétition. Elles sont mises en pause sept, puis quatorze, puis vingt-huit jours, trente au plus, puis réessayées, trois au plus par exécution.

Une page qui se charge mais ne montre aucun événement ne fait que reculer dans l'ordre. Une source n'est considérée comme défectueuse qu'après trois échecs de récupération consécutifs. Les nouvelles sources proviennent notamment d'un registre de réseaux publics, d'accélérateurs, d'instituts de recherche et de clusters de la région : si une organisation y dispose d'une page d'événements absente de la base de sources, celle-ci peut être ajoutée. Le registre lui-même n'est jamais lu comme source d'événements, afin que rien ne soit compté deux fois.