Méthodologie
Comment on travaille ici. Ce ne sont pas des principes généraux : chaque règle vient d'une erreur commise sur ce projet, et journal.md dit laquelle.
Mesurer avant d'affirmer
Le score de recherche était à 14/20 et la cause « évidente » était la racinisation française de Pagefind. Elle était fausse. Deux mesures ont suffi à trouver les vraies causes, et le score est passé à 18/20 sans toucher au jeu de requêtes.
Avant d'écrire un correctif, produire le chiffre qui dit que le problème existe. Après, produire celui qui dit qu'il a disparu. Un correctif sans mesure n'est qu'une hypothèse déployée.
Un succès n'est pas une preuve
Trois pannes consécutives se sont présentées comme des réussites : un 200 d'Umami qui jetait
l'événement, un test qui appelait une fonction autrement que le code réel, un compteur « supérieur
à zéro » qui passait au vert avec une vue sur deux perdue.
Donc : vérifier l'effet, pas l'appel. Interroger la donnée stockée, pas le code de retour. Comparer un écart, pas un total.
Un test doit pouvoir échouer pour la bonne raison
Un test qui ne distingue pas « une vue » de « deux vues pour un seul geste » ne sert à rien. Avant de le déclarer bon, se demander : si ce que je crains arrivait maintenant, ce test virerait-il au rouge ?
Le test de fumée applicatif compare l'écart mesuré au nombre de requêtes acceptées et vérifie les URL reçues ; c'est ce qui a attrapé deux régressions qu'un seuil à zéro aurait laissées passer.
Écarter après mesure, et le dire
Le moissonneur ANR était au plan. Il a été écarté parce que l'open data ne couvre que 14 % des projets concernés, et la mesure figure dans le plan à la place de la case cochée. Une tâche abandonnée sans sa raison revient tous les six mois.
Ne pas fabriquer ce qu'on ne sait pas
Les présentations manquantes décrivent des laboratoires réels : elles ne se génèrent pas, elles s'écrivent ou se cherchent à la source. Même règle pour un lien : un garde-fou sur la forme du code ANR évite de fabriquer une URL à partir d'un identifiant inattendu — mieux vaut pas de lien qu'un lien mort.
Rendre les chiffres revérifiables
data/raw/ n'est pas versionné : sans référence figée, tout nombre publié devient invérifiable le
lendemain. pnpm data:freeze fige un manifeste et un échantillon ; data:verify signale la
dérive et bloque le push. Si le changement est voulu, on refige et on explique pourquoi.
Écrire la raison, pas seulement la règle
Les commentaires du code disent ce qui a été constaté et quand : « vérifié le 26/10/2026 sur Chrome », « mesuré, 12 fiches contre 31 ». Un commentaire qui répète le code ne survit pas ; un commentaire qui porte une mesure empêche de défaire le correctif par inadvertance.
Séparer ce qui est établi de ce qui ne l'est pas
Les pages de documentation disent ce qui a été vérifié, par quelle commande et à quelle date — et
annoncent en tête ce qui ne l'a pas été. analytics/deployment.md s'ouvre sur « rien de cette
page n'a été éprouvé ». C'est plus utile qu'une page qui a l'air complète.
Les décisions qui ne nous appartiennent pas
Périmètre, personnes publiées, consentement, licence : ces arbitrages reviennent à la Direction de la recherche, à la DPO, au service juridique. La règle est de poser une hypothèse praticable, l'afficher comme telle, et préparer la pièce qui permet de trancher — pas d'attendre, pas de décider à leur place. D'où a-faire-valider.md et ses tableurs.