Constat mesure (2026-08-29)
MyIA.AI.Notebooks/ML/DataScienceWithAgents/ est la zone d'atterrissage la plus chaude du
depot : python scripts/series_saturation.py mesure 11 notebooks neufs en 14 jours pour
15 PRs. Aucune autre zone n'en est proche (la suivante, Search/Part4-Metaheuristics,
est a 6/22).
Cette issue ne demande pas de ralentir la serie. Elle demande de solder les defauts de
structure que cette cadence a produits, et que personne ne verra tant que chaque PR ne
regarde que sa propre ligne.
Ce que la serie fait deja bien
La convention de lettre sur un numero existant est en place et fonctionne : 2.3b/c/d,
2.5b/c, 2.8b/c/d. Un versant supplementaire d'un sujet existant y prend une lettre au lieu
d'un numero neuf. C'est exactement la bonne forme — ce ticket demande de l'appliquer la ou
elle a ete oubliee, pas de l'inventer.
Les trois defauts a solder
1. Deux fichiers occupent le numero nu 3.6
03-DeepLearning/3.6-Modeles-Generatifs.ipynb (#12995)
03-DeepLearning/3.6-Representations-Contrastives.ipynb (#13003)
Deux sujets distincts (modeles generatifs / representations contrastives) au meme numero,
sans lettre pour les departager. C'est la seule collision d'index nue de toute la serie
(les autres — 2.3, 2.5, 2.8 — sont proprement lettrees).
Trancher : soit 3.6-Representations-Contrastives -> 3.8-... (c'est un sujet a part
entiere, pas un versant du 3.6), soit une lettre si on juge qu'il en est un.
Ma lecture : ce n'est pas un versant — le contrastif n'est pas une variante des modeles
generatifs. Un numero propre est plus juste qu'une lettre.
2. Deux notebooks livres sont absents du tableau « Vue d'ensemble » du README
3.3-Regularisation.ipynb (#12527) et 3.6-Representations-Contrastives.ipynb (#13003)
existent sur disque et n'ont aucune ligne dans le tableau du
README de 03-DeepLearning.
Un etudiant qui lit le README ne sait pas qu'ils existent.
C'est le defaut que la regle E de [pr-review-discipline] vise : chaque PR a mis a jour sa
ligne, aucune n'a re-audite le fichier entier.
3. Verifier que le reste de la serie ne porte pas le meme trou
Le meme audit disque <-> README est a passer sur 01-PythonForDataScience, 02-ML-Cours et
les Lab*. Commande de depart :
git ls-tree -r --name-only origin/main MyIA.AI.Notebooks/ML/DataScienceWithAgents/ \
| grep '\.ipynb$'
Criteres d'acceptation
Pourquoi cette issue existe (mandat user 2026-08-28)
« si un Epic alimente une serie comme MGS, il faut qu'il soit capable de creer autant des
issues de renumerotations et consolidations de Notebooks, transformant par exemple des
numeros eleves en lettres de numeros existants, ou consolidant plusieurs lettres en un
petit nombre d'autres, que d'issues qui rajoutent un nouveau numero. »
La zone la plus chaude du depot n'avait, avant celle-ci, aucune issue de consolidation
ouverte en face de ses 11 notebooks neufs. Le picker sait desormais amortir une zone saturee
et pousser ses grains de consolidation (scripts/series_saturation.py, polarity()) —
encore faut-il qu'il y en ait a pousser. C'est ce que cette issue fournit.
Premier cas d'application deja traite : #13006, renumerotee de 3.3 en 3.6b plutot que
mergee comme une unite de plus.
Constat mesure (2026-08-29)
MyIA.AI.Notebooks/ML/DataScienceWithAgents/est la zone d'atterrissage la plus chaude dudepot :
python scripts/series_saturation.pymesure 11 notebooks neufs en 14 jours pour15 PRs. Aucune autre zone n'en est proche (la suivante,
Search/Part4-Metaheuristics,est a 6/22).
Cette issue ne demande pas de ralentir la serie. Elle demande de solder les defauts de
structure que cette cadence a produits, et que personne ne verra tant que chaque PR ne
regarde que sa propre ligne.
Ce que la serie fait deja bien
La convention de lettre sur un numero existant est en place et fonctionne :
2.3b/c/d,2.5b/c,2.8b/c/d. Un versant supplementaire d'un sujet existant y prend une lettre au lieud'un numero neuf. C'est exactement la bonne forme — ce ticket demande de l'appliquer la ou
elle a ete oubliee, pas de l'inventer.
Les trois defauts a solder
1. Deux fichiers occupent le numero nu
3.6Deux sujets distincts (modeles generatifs / representations contrastives) au meme numero,
sans lettre pour les departager. C'est la seule collision d'index nue de toute la serie
(les autres — 2.3, 2.5, 2.8 — sont proprement lettrees).
Trancher : soit
3.6-Representations-Contrastives->3.8-...(c'est un sujet a partentiere, pas un versant du 3.6), soit une lettre si on juge qu'il en est un.
Ma lecture : ce n'est pas un versant — le contrastif n'est pas une variante des modeles
generatifs. Un numero propre est plus juste qu'une lettre.
2. Deux notebooks livres sont absents du tableau « Vue d'ensemble » du README
3.3-Regularisation.ipynb(#12527) et3.6-Representations-Contrastives.ipynb(#13003)existent sur disque et n'ont aucune ligne dans le tableau du
README de 03-DeepLearning.
Un etudiant qui lit le README ne sait pas qu'ils existent.
C'est le defaut que la regle E de [pr-review-discipline] vise : chaque PR a mis a jour sa
ligne, aucune n'a re-audite le fichier entier.
3. Verifier que le reste de la serie ne porte pas le meme trou
Le meme audit disque <-> README est a passer sur
01-PythonForDataScience,02-ML-Coursetles
Lab*. Commande de depart :Criteres d'acceptation
ci-dessus rend
index en collision : 0)sous-serie — reconciliation disque <-> README ecrite dans le body de la PR
(barre de nav en tete, renvois croises)
git mvpour tout renommage (l'historique du fichier est preserve)re-execution s'avere necessaire, elle fait l'objet d'une PR separee.
Pourquoi cette issue existe (mandat user 2026-08-28)
La zone la plus chaude du depot n'avait, avant celle-ci, aucune issue de consolidation
ouverte en face de ses 11 notebooks neufs. Le picker sait desormais amortir une zone saturee
et pousser ses grains de consolidation (
scripts/series_saturation.py,polarity()) —encore faut-il qu'il y en ait a pousser. C'est ce que cette issue fournit.
Premier cas d'application deja traite : #13006, renumerotee de
3.3en3.6bplutot quemergee comme une unite de plus.