notebooks(#9377,#8052): porter le mandat « quantitatif tenu par le CI, pas par la prose » a l'interieur des notebooks — la vague #8052 re-epingle des valeurs qui rebougeront

[jsboige]

Le mandat #9377 — « les donnees quantitatives doivent etre tenues par le CI, pas dans la prose manuelle » — a ete applique aux README (comptes de notebooks retires, #9377 ; tailles de fichiers retirees, #9425 ; comptes de cellules retires, #9432). Il n'a pas encore ete applique a l'interieur des notebooks, ou la meme pathologie produit un travail sans fin.

Le symptome, mesure sur la vague #8052 du 2026-08-04

Quatre PR le meme apres-midi alignent une valeur de prose sur une sortie committee :

PR	notebook	valeur re-alignee	nature
#9426	App-7-Wordle	~3.3 -> ~3.1 tentatives	metrique d'algorithme
#9427	App-11-Picross	speedups ~68x -> ~16x, ~1M-100Mx -> ~2.8e24x	structurel
#9427	App-11-Picross	(28-364 ms mesure) -> (24-127 ms mesure)	machine-dependant
#9428	Search-5-GeneticAlgorithms	fitness 42.11 -> 41.71	stochastique
#9429	GT-4c-NashExistence	table de versions NumPy 2.4.2 -> 2.4.6	env-dependant

Les quatre corrigent une contradiction reelle. Mais trois d'entre elles re-epinglent en prose une valeur qui rebougera au prochain passage kernel — c'est-a-dire qu'elles reconstituent le defaut qu'elles corrigent, un cran plus loin.

La ligne de partage

Toutes les valeurs quantitatives ne sont pas equivalentes, et c'est ce qui rend la regle applicable plutot que dogmatique :

• Structurel (ordres de grandeur d'un speedup determine par la taille du probleme : 2^225 combinaisons -> 2.78e24x) — stable d'une machine a l'autre. L'ecrire en prose est legitime.
• Machine-dependant (temps absolus en ms) — derive a chaque re-exec, sur chaque machine. L'ecrire en prose fabrique de la derive.
• Env-dependant (versions de librairie) — derive a chaque bump. fix(gametheory,#8052,#9377): GT-4c delete hand-written NumPy version row (cell[2] = source of truth) #9429 le dit lui-meme : « cell[2] imprime la version dynamiquement, donc une source unique de verite est trivialement restaurable » — puis re-epingle la table a la main.
• Stochastique non-seede (fitness d'un GA) — derive a chaque run. Soit on seede, soit la prose parle de l'ordre de grandeur.

Ce qu'il faut construire

1. Recenser les valeurs quantitatives ecrites en dur dans les cellules markdown des notebooks, et les trier selon les quatre classes ci-dessus. Le recensement seul est du read-heavy borne, delegable.
2. Retirer ou deriver les classes machine/env/stochastique :
   • version : supprimer la ligne ecrite a la main quand une cellule imprime deja la version (cas fix(gametheory,#8052,#9377): GT-4c delete hand-written NumPy version row (cell[2] = source of truth) #9429, le plus simple et le plus frequent) ;
   • timing : remplacer le chiffre par l'ordre de grandeur, ou renvoyer a la sortie de la cellule de benchmark ;
   • stochastique : seeder, ou parler en ordre de grandeur.
3. Garder le structurel, qui est du contenu pedagogique reel.

Critere d'acceptation

• Un recensement chiffre par famille, avec la classe de chaque valeur trouvee.
• Les tables de versions ecrites a la main sont supprimees partout ou une cellule imprime la version — la sortie committee devient la source unique.
• Aucun temps absolu en ms ne subsiste dans une cellule markdown d'interpretation quand la cellule de mesure est juste au-dessus.
• Une note dans .claude/rules/notebook-conventions.md (PR + sign-off user, cf regle §A) enonce la ligne de partage, pour que la prochaine PR [#4208] Audit d'échantillonnage sémantique — claims↔outputs, env vierge, revue-domaine (≥5%/famille) #8052 aligne ou retire selon la classe au lieu de re-epingler.

Pourquoi ca vaut un grain de fond et pas un nettoyage

Sans ca, chaque re-execution d'un notebook reouvre un ticket #8052 sur les memes cellules. La vague du 2026-08-04 en est la demonstration : quatre PR pour quatre notebooks, et le meme apres-midi po-2023 livrait #9425 qui applique deja le bon geste aux README. Le geste est connu ; il n'a simplement jamais ete porte a l'interieur des notebooks.

See #9377
See #8052