# 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](/projet/journal) 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](/projet/a-faire-valider) et ses tableurs.