From 1cb5688a69f3cea4ec40ec40de81a80ce3749e0f Mon Sep 17 00:00:00 2001
From: jsboige <jsboige@gmail.com>
Date: Wed, 16 Sep 2026 03:37:25 +0200
Subject: [PATCH 1/4] enrich(search,#13410): densite .NET 03b/03c/11-Csharp au
 plancher 1200 c/cell

Tranche 3 notebooks C# sous plancher, markdown-only (fingerprint md5 des
cellules code inchange, 0 ligne code/output touchee) :
- Search-03b-PatternDatabases-Csharp 796 -> 1231 (lecture BFS retrograde
  P(16,4)=524160, disjonction des groupes -> somme admissible, dominance
  additive >= Manhattan, speedup NaN = frontiere du resoluble, attendus ex1-3)
- Search-03c-LimitedDiscrepancySearch-Csharp 823 -> 1322 (ordre = heuristique,
  pourquoi le glouton echoue, optimum a k=1 + triage CS8632, croisement 103%
  de l'exhaustif, attendus ex1-3)
- Search-11-Metaheuristics-Csharp 842 -> 1257 (4 paysages = 4 diagnostics,
  0,995 = dimension piegee, multi-seed aucun global, plateau Ackley vs vallee
  Rosenbrock, centroid du croisement arithmetique, popsize moyenne non
  monotone, 2-opt et decroisement euclidien, attendus ABC/inertie/Schwefel)

Auto-fix pre-commit : hr --- -> *** dans une cellule existante de 03b.

See #13410

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 .../Search-03b-PatternDatabases-Csharp.ipynb  |  76 ++++++++++++-
 ...-03c-LimitedDiscrepancySearch-Csharp.ipynb |  70 ++++++++++++
 .../Search-11-Metaheuristics-Csharp.ipynb     | 100 +++++++++++++++++-
 3 files changed, 244 insertions(+), 2 deletions(-)

diff --git a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-Csharp.ipynb b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-Csharp.ipynb
index 9256f1534f..43d55d2c4a 100644
--- a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-Csharp.ipynb
+++ b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-Csharp.ipynb
@@ -451,6 +451,18 @@
     "Console.WriteLine($\"PDB simple ({PATTERN.Length} tuiles) : {n5} états en {sw.Elapsed.TotalSeconds:F1}s, distance max = {dmax}\");"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03b-pdb-bfs-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture de la construction : 524 160 = P(16,4), et la table EST la solution précalculée\n",
+    "\n",
+    "La sortie `524 160 états en 1,4 s, distance max = 50` se décompose entièrement à la main. Le BFS rétrograde énumère les positions possibles des 4 tuiles du motif **et** de la case vide dans les 16 cases : 16 × 15 × 14 × 13 = 43 680 arrangements de tuiles, × 12 positions restantes pour la vide = **524 160** états. Le `distance max = 50` dit ensuite que le pire sous-puzzle (les 4 tuiles les plus mal placées) exige 50 coups à lui seul : la table encode donc des optima *partiels* déjà très coûteux, que l'heuristique ira lire en O(1) au lieu de les recalculer. C'est tout le compromis : ~1,4 s de construction une fois, des millions de consultations gratuites ensuite.\n",
+    "\n",
+    "Un point qui surprend : le BFS part du BUT et remonte les coups **à l'envers**. Chaque état atteint à profondeur d est donc à distance *exactement* d de l'objectif — la table est un oracle de distance exacte sur le sous-espace, pas une estimation."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "98244622",
@@ -583,6 +595,16 @@
     "}"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03b-additive-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture des groupes : pourquoi la somme des 4 tables reste admissible\n",
+    "\n",
+    "La sortie donne quatre tables : trois de 524 160 états (groupes de 4 tuiles) et une de 43 680 (groupe de 3 : 16 × 15 × 14 = 43 680, sans position de vide supplémentaire dans ce codage). Les distances max se lisent 21, 17, 19 et 16. Le point structurel : chaque coup du 15-puzzle déplace **une seule tuile**, qui appartient à **un seul** groupe — les coûts des groupes sont disjoints par coup, donc leur somme ne peut jamais surestimer la distance réelle. C'est la différence radicale avec la PDB classique de Culberson & Schaeffer : on y prenait le **max** de plusieurs vues du même puzzle ; Korf & Felner partitionnent en groupes **disjoints** pour pouvoir **sommer**. La même somme appliquée à des groupes qui se chevaucheraient casserait l'admissibilité immédiatement (un même coup compté deux fois)."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "05f3f20b",
@@ -766,6 +788,16 @@
     "Console.WriteLine($\"Sur l'instance de démo : Manhattan={Manhattan(INST)}, h_additive={HAdditive(INST)} (additive >= Manhattan attendu)\");"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03b-dominance-lecture",
+   "metadata": {},
+   "source": [
+    "### Dominance : additive ≥ Manhattan, lues sur l'instance de démo\n",
+    "\n",
+    "La sortie porte trois verdicts distincts. (1) `additive optimal=8 == Manhattan optimal=8` : sur l'instance de test, IDA* trouve le même optimum sous les deux heuristiques — l'optimalité est préservée. (2) `40/40` : sur 40 instances brouillées, h_additive ≤ optimal à chaque fois — l'admissibilité tient en pratique. (3) `Manhattan=26, h_additive=28` : sur l'instance de démo, l'additive **domine** strictement Manhattan. Le lien avec la théorie : Manhattan est exactement la PDB additive des 15 groupes d'**une** tuile — raffiner la partition (1-1-…-1 vers 4-4-4-3) ne peut que resserrer la borne. Un heuristique qui domine *et* reste admissible explore mécaniquement moins de nœuds à optimalité égale : c'est le seul « free lunch » de la recherche heuristique."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "b69f1d52",
@@ -982,6 +1014,16 @@
     "Console.WriteLine(\"additive (4-4-4-3) résout à l'optimum — elle repousse la frontière du résolvable.\");"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03b-frontiere-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture du tableau : ce que « speedup NaN » veut dire\n",
+    "\n",
+    "Deux lignes portent `speedup NaN`, et c'est l'information la plus importante du tableau. Sur I1 (optimal 24), les deux heuristiques terminent : 2 114 nœuds contre 732, rapport 2,9 — l'additive fait mieux, mais Manhattan *suffit*. Sur I2 et I3 (optimaux 45 et 53), Manhattan dépasse le budget de 2 M nœuds **sans conclure** : le rapport est `NaN` parce qu'on ne peut pas diviser par un échec. L'additive, elle, conclut à l'optimum en 299 773 et 392 168 nœuds. La leçon n'est pas « 3× plus vite » mais « résout l'irrésolu » : entre les deux colonnes, ce n'est pas la même classe d'instances qui est accessible. La frontière du résoluble a bougé."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "f1c33b0f",
@@ -1009,6 +1051,16 @@
     "  *mémoire contre qualité d'heuristique*."
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03b-attendus-ex1",
+   "metadata": {},
+   "source": [
+    "### Attendus — Exercice 1 (partition 6-6-3)\n",
+    "\n",
+    "Ce que vous devez observer si votre implémentation est juste : deux PDB de P(16,6) × 10 = 5 765 760 états chacune, une de P(16,3) × 13 = 43 680 — le temps de construction passe de ~4 s à plusieurs dizaines de secondes (d'où l'avertissement de l'énoncé), les distances max par groupe montent (un groupe de 6 est plus mal plaçable qu'un groupe de 4), et h_additive resserre encore : attendez-vous à ce que I1 descende nettement sous les 732 nœuds de la 4-4-4-3. Anti-piège : la partition doit rester **exactement** disjointe (15 tuiles = 6+6+3) ; réutiliser une tuile dans deux groupes compte ses coups deux fois et casse l'admissibilité — la cellule de vérification du §8 doit rester 40/40."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "3d651408",
@@ -1143,6 +1195,16 @@
     "Console.WriteLine(\"Exercice 2 à compléter : PDB symétrique gratuit (Felner et al. 2004).\");"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03b-attendus-ex2",
+   "metadata": {},
+   "source": [
+    "### Attendus — Exercice 2 (PDB symétrique)\n",
+    "\n",
+    "La symétrie du 15-puzzle (miroir vertical + renversement des numéros) transforme toute instance en une instance joker : vous obtenez une **seconde heuristique sans nouveau BFS**. L'usage correct est le max des deux vues — admissible car chacune l'est, et strictement meilleur dès qu'une des deux voit mieux. Si vous obtenez exactement les mêmes valeurs qu'avant, votre `Reflect` est probablement l'identité déguisée (indices : le miroir échange les colonnes, et le renversement remappe les numéros t vers 16 − t)."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "b644cc24",
@@ -1204,6 +1266,18 @@
     "Console.WriteLine(\"Exercice 3 à compléter : généralisation au 24-puzzle (5x5, partition 6-6-6-7).\");"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03b-attendus-ex3",
+   "metadata": {},
+   "source": [
+    "### Attendus — Exercice 3 (24-puzzle)\n",
+    "\n",
+    "Au 24-puzzle (5 × 5), Manhattan est désespérément loose : les instances aléatoires moyennes exigent ~100 coups, et IDA* sous Manhattan explose au-delà de tout budget raisonnable. La structure du code est inchangée (N=5, but 1..24,0) mais les tailles explosent : un groupe de 6 tuiles dans 25 cases donne P(25,6) × 19 soit ~268 millions d'états — la table ne tient plus en mémoire sans encodage compact. C'est précisément pourquoi Korf & Felner ont poussé les partitions avec symétries et la compression : au 24-puzzle, la PDB n'est plus une optimisation, c'est la condition d'entrée.\n",
+    "\n",
+    "**L'arc du notebook** : représenter (permutations), abstraire (sous-espaces), précalculer (BFS rétrograde), sommer (disjonction), vérifier (admissibilité et dominance), mesurer (frontière du résoluble). Ce pipeline est transposable à tout domaine où l'on peut payer du calcul préliminaire pour accélérer des requêtes répétées."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "08e76387",
@@ -1252,7 +1326,7 @@
     "- **Korf, R. E. (1997).** *Finding Optimal Solutions to Rubik's Cube Using Pattern Databases.* AAAI.\n",
     "- **Edelkamp, S. & Schrödl, S. (2012).** *Heuristic Search: Theory and Applications.* Morgan Kaufmann.\n",
     "\n",
-    "---\n",
+    "***\n",
     "\n",
     "← [Search-3 — Recherche informée](../Part1-Foundations/Search-03-Informed.ipynb)\n",
     "\n",
diff --git a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03c-LimitedDiscrepancySearch-Csharp.ipynb b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03c-LimitedDiscrepancySearch-Csharp.ipynb
index 09c839ff55..aa1c8c55c0 100644
--- a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03c-LimitedDiscrepancySearch-Csharp.ipynb
+++ b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03c-LimitedDiscrepancySearch-Csharp.ipynb
@@ -146,6 +146,16 @@
     "Console.WriteLine($\"Capacité du sac : {capacity}\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03c-ratio-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture du banc d'essai : ce que l'ordre des objets encode\n",
+    "\n",
+    "La sortie classe A (ratio 1,33) > B = C (1,20) > D (0,50) > E (0,33) pour une capacité de 10. Deux choses se lisent déjà. D'abord, l'ordre du tableau **est** l'heuristique : LDS parlera de « suivre la recommandation » = prendre les objets dans cet ordre tant que le poids le permet. Ensuite, l'égalité parfaite B = C (mêmes poids 5, valeur 6) fabrique une **indifférence** : l'heuristique ne peut pas les départager, et c'est exactement là que les écarts paieront — la solution optimale [B, C] consiste à *refuser* A (le mieux classé !) pour loger la paire que la capacité (10 = 5 + 5) accueille exactement."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "27e86ae8",
@@ -217,6 +227,16 @@
     "Console.WriteLine($\"Greedy (k=0) : valeur={greedyV}, sélection=[{string.Join(\", \", greedySel)}], nœuds={greedyNodes}\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03c-greedy-lecture",
+   "metadata": {},
+   "source": [
+    "### Pourquoi le glouton échoue ici (et pourquoi c'est instructif)\n",
+    "\n",
+    "`valeur=10, sélection=[A, D], nœuds=5` : le glouton prend A (ratio max, poids 6), ne peut plus loger ni B ni C (6+5 > 10), recolle D (poids 4, valeur 2) et s'arrête à 10. La solution optimale est [B, C] = 12 — deux objets *mieux notés en volume* dont la somme (10) remplit le sac exactement. L'échec n'est pas un accident du banc : il est structurel (le glouton 0/1 n'a pas de ratio d'approximation borné en général). Les 5 nœuds disent aussi son prix : un parcours linéaire. La question que LDS pose est : *peut-on réparer quelques décisions du glouton sans payer le 2ⁿ de l'énumération ?*"
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "72895213",
@@ -387,6 +407,16 @@
     "}\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03c-lds-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture du tableau LDS : l'optimum est à k=1, le coût croît régulièrement\n",
+    "\n",
+    "Trois lectures. (1) La colonne valeur saute de 10 (k=0) à 12 (k=1) puis **ne bouge plus** : un seul écart au glouton — refuser A — suffit à atteindre l'optimum. (2) Les nœuds montent 6, 13, 21, 28, 33, 34 : à k fixé, LDS explore les chemins à au plus k écarts ; k=5 = n−1 couvre déjà tout l'arbre (34 s'approche des 32 feuilles plus les nœuds internes revisités). (3) La sélection [B, C] est stable dès k=1 : LDS ne « change pas d'avis » en explorant plus, il confirme. Les deux warnings `CS8632` de la sortie sont bénins : des annotations de nullabilité `?` utilisées hors contexte `#nullable` (le gabarit interactif compile sans le flag) — ils n'affectent ni l'exécution ni les résultats."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "0880099f",
@@ -605,6 +635,16 @@
     "Console.WriteLine($\"=> LDS atteint l'optimum dès k*={kStar}, en {ldsNodesStar} nœuds ({100.0*ldsNodesStar/exNodes:F1}% de l'exhaustif).\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03c-crossover-lecture",
+   "metadata": {},
+   "source": [
+    "### La colonne « % exhaustif » : où LDS cesse d'être une bonne affaire\n",
+    "\n",
+    "La dernière colonne est la plus parlante : LDS(1) atteint l'optimum pour **40,6 %** du coût de l'énumération (13 nœuds contre 32). Mais la ligne LDS(4) franchit **103,1 %** et LDS(5) 106,2 % : passé un certain k, LDS explore *plus* que l'énumération exhaustive — le décompte par écarts revisite des chemins déjà vus et ajoute du travail. La niche de LDS est donc exactement : **une heuristique assez bonne pour que l'optimal soit à petit k**. Quand l'heuristique est mauvaise (exercice 3), le k optimal monte, la combinatoire gonfle, et LDS dégénère — sans jamais perdre la garantie de complétude à k = n."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "8242686f",
@@ -718,6 +758,16 @@
     "Console.WriteLine(\"Exercice 1 à compléter\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03c-attendus-ex1",
+   "metadata": {},
+   "source": [
+    "### Attendus — Exercice 1 (ILDS)\n",
+    "\n",
+    "Le tableau attendu : k = 0..n en boucle, nœuds cumulés ; la valeur stagne à 12 dès k=1, donc ILDS s'arrête à k=2 si votre critère est « deux tours sans amélioration ». Anti-piège : n'interrompez pas au premier k sans amélioration — sur d'autres instances l'optimum peut réapparaître à k+1 après un plateau ; c'est le compromis arrêt-anticipé classique."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "52ccd683",
@@ -777,6 +827,16 @@
     "Console.WriteLine(\"Exercice 2 à compléter\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03c-attendus-ex2",
+   "metadata": {},
+   "source": [
+    "### Attendus — Exercice 2 (passage à l'échelle)\n",
+    "\n",
+    "À n=18 : l'énumération = 2¹⁸ = 262 144 feuilles ; LDS à k≤3 explore de l'ordre de la somme des binomiaux C(18, i) pour i ≤ 3, soit ~1 000 nœuds — le ratio se creuse avec n tant que l'optimum reste à petit k. Observez le basculement : si vous générez des ratios « adverses » (l'optimal exige de refuser les 4 premiers objets), LDS(3) ne suffit plus et la courbe nœuds(k) croise la ligne 2ⁿ."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "da81ecbe",
@@ -837,6 +897,16 @@
     "Console.WriteLine(\"Exercice 3 à compléter\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s03c-attendus-ex3",
+   "metadata": {},
+   "source": [
+    "### Attendus — Exercice 3 (sensibilité à l'heuristique)\n",
+    "\n",
+    "Avec un ordre aléatoire des objets, le k optimal grimpe vers n/2 et le coût LDS rejoint l'énumération — LDS n'a pas de magie intrinsèque, il *emprunte* la qualité de l'heuristique. La courbe à tracer : k* (l'écart de l'optimal au classement) en fonction du nombre d'inversions de l'ordre testé. Elle doit être grossièrement croissante."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "493df909",
diff --git a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-11-Metaheuristics-Csharp.ipynb b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-11-Metaheuristics-Csharp.ipynb
index ad0d467158..a989116f23 100644
--- a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-11-Metaheuristics-Csharp.ipynb
+++ b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-11-Metaheuristics-Csharp.ipynb
@@ -159,6 +159,16 @@
     "Console.WriteLine($\"\\nVerif : Sphere(0)={Sphere(zero):F6}  Rastrigin(0)={Rastrigin(zero):F6}  Rosenbrock(1)={Rosenbrock(one):F6}  Ackley(0)={Ackley(zero):F6}  (tous attendus ~0)\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-landscapes-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture des quatre paysages : chaque fonction est un diagnostic\n",
+    "\n",
+    "Le tableau de sortie n'est pas une liste : c'est une trousse d'outils de diagnostic. **Sphere** (unimodale, convexe) : tout marche, y compris un gradient — elle sert de *sanity check*. **Rastrigin** (multimodale : cosinus superposés à la sphère) : piège à bassins secondaires — elle teste la capacité à *échapper* aux optima locaux. **Rosenbrock** (vallée parabolique étroite) : le gradient existe partout mais zigzague d'une paroi à l'autre — elle teste la *progression dans un couloir*. **Ackley** (plateau quasi plat + puits central) : presque aucun signal de pente — elle teste l'*exploration* quand le paysage ne guide pas. À chaque paysage son échec caractéristique : c'est pour cela qu'aucun algorithme ne domine le tableau final du §6."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "da4a2fb8",
@@ -317,6 +327,16 @@
     "Console.WriteLine($\"  Optimal attendu : [0,...,0], f=0\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-pso-trapped-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture de la solution : 0,9950 = une dimension piégée\n",
+    "\n",
+    "La solution `[0,0002, -0,0000, 0,0001, 0,9950, ...]` avec objectif 5,97 raconte une histoire précise : trois coordonnées sont posées sur 0 (le global), la quatrième est collée à **0,995, soit ~1,0** — un minimum local du cosinus de Rastrigin (les minima secondaires sont à ~1,0 de l'axe). L'objectif 5,97 se décompose presque exactement en « une dimension piégée » (~1 par dimension piégée, plus les résidus des autres) : l'essaim a trouvé le bon bassin pour 9 dimensions sur 10 et n'a jamais vu le déclic pour la dixième. C'est l'échec *partiel* typique du PSO : convergence intra-bassin excellente, basculement inter-bassins manqué."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "7f536404",
@@ -557,6 +577,16 @@
     }
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-multiseed-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture multi-seed : aucun run ne trouve le global — et c'est la vraie information\n",
+    "\n",
+    "Les 8 seeds finissent tous en « bassin secondaire » (2,99 à 7,98, moyenne 5,20, écart-type 1,60) : **aucun** n'atteint 0. La sortie est honnête là où un rapport mono-run masquerait tout : la variance inter-runs (σ = 1,6 sur une moyenne de 5,2, soit ±31 %) est assez grande pour qu'un seed chanceux et un rapport unique « prouvent » n'importe quoi. C'est la même discipline que les expériences ML multi-seed du repo : un résultat stochastique non répété n'est pas un résultat. Notez aussi la cohérence avec la cellule précédente (convergence monotone *dans* un bassin) : le multi-seed montre que la question n'est pas la vitesse mais *quel* bassin."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "a947499d",
@@ -704,6 +734,16 @@
     "Console.WriteLine($\"  Optimal attendu : [0,...,0], f=0\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-sa-ackley-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture : pourquoi le recuit échoue sur Ackley (15,84) alors qu'il réussit sur Rosenbrock (3,59)\n",
+    "\n",
+    "La solution `[6,02, -6,99, 0,71, 5,01, ...]` est *loin* de l'origine sur la plupart des dimensions : l'algorithme erre sur le plateau d'Ackley sans jamais être guidé vers le puits central — la surface quasi plate ne fournit presque aucune différence de fitness entre voisins, et le critère de Metropolis accepte tout indifféremment. En contraste, sur Rosenbrock (§6 : 3,59), chaque déplacement le long de la vallée *baisse* la fitness : le recuit a une pente à suivre. Le diagnostic est général : **le recuit vit du signal local du paysage** ; sur un plateau, il se comporte en marche aléatoire refroidie."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "34c24168",
@@ -863,6 +903,16 @@
     "Console.WriteLine($\"  Optimal attendu : [1,...,1], f=0\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-ga-rosenbrock-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture de la solution GA : des coordonnées qui décroissent vers 0 au lieu de converger vers 1\n",
+    "\n",
+    "La solution `[0,368, 0,148, 0,028, 0,0095, ...]` est étrange à première vue : Rosenbrock veut *toutes* les coordonnées à 1, mais celles-ci décroissent vers 0 au fil des indices. C'est la signature du **croisement arithmétique** : la moyenne de deux parents rapproche chaque gène du centroïde de la population ; la population s'effondre vers l'intérieur de son nuage initial avant que la sélection n'ait le temps de tirer vers la vallée. La vallée étroite de Rosenbrock (chaque coordonnée doit suivre la précédente au carré) est impitoyable à ce rétrécissement prématuré : la diversité disparaît avant la découverte du couloir. C'est le compromis exploration/exploitation vu de l'intérieur."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "299a1710",
@@ -943,6 +993,16 @@
     "Console.WriteLine(\"\\nTendances : Sphere (unimodale) = facile pour tous ; Rastrigin/Ackley (multimodales) = PSO souvent au-dessus ; Rosenbrock (vallee) = GA robuste.\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-benchmark-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture du tableau final : aucun gagnant — un tableau de correspondances\n",
+    "\n",
+    "Le tableau ne couronne personne : PSO gagne Rastrigin (4,99) et Ackley (0,012), SA gagne Rosenbrock (3,59), GA gagne Sphere — et SA perd Rastrigin de façon catastrophique (39,9, cohérent avec la lecture du plateau ci-dessus). Chaque colonne reflète la mécanique profonde vue section par section : l'essaim (information sociale partagée) couvre bien les multimodales ; le recuit (descente + acceptation d'exception) suit bien les vallées continues ; l'évolutionnaire (population + recombinaison) consolide bien les paysages réguliers. La leçon opérationnelle : **on choisit un algorithme par diagnostic du paysage**, pas par préférence — et on le vérifie en multi-seed (§3)."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "09b2a7bd",
@@ -1023,6 +1083,16 @@
     "Console.WriteLine(\"\\nUne population plus large ameliore la meilleure fitness atteinte (plus d'exploration), au prix du temps (lineaire en popSize).\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-popsize-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture des deux colonnes : la meilleure s'améliore, la moyenne n'est pas monotone\n",
+    "\n",
+    "De 10 à 100 particules, la meilleure fitness passe de 6,77 à 2,11 (plus d'exploration = plus de chances de tomber dans un bon bassin) et le temps croît linéairement (1,2 à 12,4 ms). Mais la colonne **moyenne** fait autre chose : 10,90, 7,09, 4,87, puis **6,23** — elle rebondit à 100. Une grande population n'est pas uniformément meilleure : elle multiplie aussi les essaims qui convergent mal (plus de particules libres de se disperser sur des bassins secondaires), à budget par particule identique. Si vous ne rapportiez que la meilleure colonne, vous concluriez « 100 gagne » ; la moyenne dit « 50 est le meilleur compromis coût/robustesse ». Les deux colonnes ensemble, encore une fois, sont l'information."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "8acb0bde",
@@ -1359,6 +1429,16 @@
     "Console.WriteLine(\"le tour pour eliminer les arenes croisees, la ou un simple swap de 2 villes est trop faible.\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-tsp-lecture",
+   "metadata": {},
+   "source": [
+    "### Lecture du TSP : 548,69 vers 284,64, et pourquoi 2-opt est le bon voisinage\n",
+    "\n",
+    "Le recuit part d'un tour aléatoire (548,69) et le resserre à 284,64 (amélioration 1,93×). Le point structurel : sur un problème **combinatoire** (l'espace = permutations de 15 villes), le voisinage *définit* l'algorithme. Un simple swap de deux villes casse quatre arêtes et en recrée quatre — quasi-tous les voisins sont mauvais. L'inversion de segment (2-opt) retire deux arêtes **croisées** et les rebranche droites : dans le plan euclidien, décroiser raccourcit *toujours* (inégalité triangulaire), donc une grande fraction des voisins 2-opt sont améliorants. Le recuit n'a plus qu'à enchaîner les décroisements et à accepter quelques détours — d'où l'efficacité."
+   ]
+  },
   {
    "cell_type": "markdown",
    "id": "search11-tr2-md-header",
@@ -1614,6 +1694,16 @@
     ""
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-attendus-exercices",
+   "metadata": {},
+   "source": [
+    "### Attendus — les trois exercices\n",
+    "\n",
+    "**ABC (exercice 1).** Trois phases attendues : employées (exploitation locale autour des sources), onlookers (choix pondéré par la fitness), éclaireuses (abandon des sources épuisées après `limit` tours sans progrès — c'est l'échappement aux optima locaux). Résultat typique sur Rastrigin : entre PSO et SA ; l'abandon doit parfois se déclencher pour débloquer un run bloqué à ~6. **Schedules d'inertie (exercice 2).** w linéaire 0,9 → 0,4 est le réglage de référence ; w constant haut = exploration qui ne converge jamais, w constant bas = convergence prématurée — attendez-vous à voir la moyenne multi-seed se dégrader aux deux extrémités, optimum au milieu. **Schwefel (exercice 3).** L'optimum est à ~420,97 *par dimension*, au bord du domaine [-500, 500] — un paysage qui piège les méthodes trop centrées : PSO avec initialisation uniforme s'en sort, GA avec croisement arithmétique tire la population vers le centre et échoue. Le contraste avec Rosenbrock (même phénoménologie de centrage, direction opposée) est la finalité du défi."
+   ]
+  },
   {
    "cell_type": "code",
    "execution_count": 16,
@@ -1657,6 +1747,14 @@
     "Console.WriteLine(\"Exercice 1 a completer : implementez ABC et comparez-le a PSO sur Rastrigin.\");\n"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "id": "s11-transition-inertia",
+   "metadata": {},
+   "source": [
+    "**Transition vers l'exercice 2.** Le schedule d'inertie est le levier qui gère exactement la tension mesurée au §7 : w haut préserve la diversité (exploration), w bas la concentre (exploitation). Votre protocole : les mêmes 8 seeds que la cellule multi-seed, un schedule par run — c'est la seule façon d'attribuer l'effet au schedule et non au hasard."
+   ]
+  },
   {
    "cell_type": "code",
    "execution_count": 17,
@@ -1756,7 +1854,7 @@
     "- [Search-04-LocalSearch](Search-04-LocalSearch.ipynb) : fondements du recuit simule et hill-climbing.\n",
     "- Applications métaheuristiques : [App-13-TSP](../Applications/Hybrid/App-13-TSP-Metaheuristics.ipynb), [App-9-EdgeDetection](../Applications/Hybrid/App-9-EdgeDetection.ipynb).\n",
     "\n",
-    "---\n",
+    "***\n",
     "\n",
     "*Part of #4956 (marathon parite .NET <-> Python).*\n",
     ""

From 6ba0a574fd0d6aaaef81a62a4a78abac7693898b Mon Sep 17 00:00:00 2001
From: jsboige <jsboige@gmail.com>
Date: Wed, 16 Sep 2026 03:38:31 +0200
Subject: [PATCH 2/4] chore(twin,#13410): rebaseline Search-11/12/13 apres
 enrichissement markdown C#
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Audits file-per-audit (blob + content SHA des deux cotes au head de la
tranche densite .NET) — mecanisme #14911. Le cote Python est inchange
(meme SHA qu'avant), le cote C# porte l'enrichissement markdown-only.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 .../0014-2026-09-16-myia-po-2026-CoursIA.yaml               | 6 ++++++
 .../0007-2026-09-16-myia-po-2026-CoursIA.yaml               | 6 ++++++
 .../0009-2026-09-16-myia-po-2026-CoursIA.yaml               | 6 ++++++
 3 files changed, 18 insertions(+)
 create mode 100644 scripts/notebook_tools/twin_pairs.d/search-11-metaheuristics/0014-2026-09-16-myia-po-2026-CoursIA.yaml
 create mode 100644 scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0007-2026-09-16-myia-po-2026-CoursIA.yaml
 create mode 100644 scripts/notebook_tools/twin_pairs.d/search-13-limited-discrepancy-search/0009-2026-09-16-myia-po-2026-CoursIA.yaml

diff --git a/scripts/notebook_tools/twin_pairs.d/search-11-metaheuristics/0014-2026-09-16-myia-po-2026-CoursIA.yaml b/scripts/notebook_tools/twin_pairs.d/search-11-metaheuristics/0014-2026-09-16-myia-po-2026-CoursIA.yaml
new file mode 100644
index 0000000000..a230623ea0
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/search-11-metaheuristics/0014-2026-09-16-myia-po-2026-CoursIA.yaml
@@ -0,0 +1,6 @@
+date: '2026-09-16'
+by: myia-po-2026:CoursIA
+python_sha: 3744321ea7a33090bc4878b5b39aa4280fcd48c8
+csharp_sha: a989116f233715b45b29d5db404ab2b66dc92a88
+content_python_sha: 57c1fe227e75bb9a7f71144d578fd429bbc5bcfde619414ffea7f448ec47f610
+content_csharp_sha: 0c53a588d349a6c7de803a77c3db5437c2645357d1c5827b31cb112b962a466d
diff --git a/scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0007-2026-09-16-myia-po-2026-CoursIA.yaml b/scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0007-2026-09-16-myia-po-2026-CoursIA.yaml
new file mode 100644
index 0000000000..b017e99db5
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0007-2026-09-16-myia-po-2026-CoursIA.yaml
@@ -0,0 +1,6 @@
+date: '2026-09-16'
+by: myia-po-2026:CoursIA
+python_sha: 5444cd1c5b3127ad8d8d79b1b38f6dc84e60eb0e
+csharp_sha: 43d55d2c4a46d71c635400c3e7b275d5f486185f
+content_python_sha: f3d6052c89c9d9fd4bb2712a4ec5a857c37a97200d9d1d6f6ce2560ec0b5edb7
+content_csharp_sha: 3638b80aaaeaa0bf5c67d636d7775d038a7664ff6cbfb8920b423a8644b1dea3
diff --git a/scripts/notebook_tools/twin_pairs.d/search-13-limited-discrepancy-search/0009-2026-09-16-myia-po-2026-CoursIA.yaml b/scripts/notebook_tools/twin_pairs.d/search-13-limited-discrepancy-search/0009-2026-09-16-myia-po-2026-CoursIA.yaml
new file mode 100644
index 0000000000..5ee446cf26
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/search-13-limited-discrepancy-search/0009-2026-09-16-myia-po-2026-CoursIA.yaml
@@ -0,0 +1,6 @@
+date: '2026-09-16'
+by: myia-po-2026:CoursIA
+python_sha: 7243f4c2b7701205258723863a3c39f8387135b0
+csharp_sha: aa1c8c55c0e69ea513078cc15b7f63394a3c3397
+content_python_sha: 22ff5f69261302b637cb07a633dcf7e95f0c07028ed1cfed30b0766b982a809d
+content_csharp_sha: 6b06ae9918314a0de1f6d22af9767f57c094577f6512509ed57e06ed6b21864d

From 4a655666bab3122645f1eeb42b968997a9d04f6f Mon Sep 17 00:00:00 2001
From: jsboige <jsboige@gmail.com>
Date: Sat, 19 Sep 2026 01:23:41 +0200
Subject: [PATCH 3/4] fix(search,#16352): prose arithmetique alignee sur les
 sorties commitees

P(25,6)x19 = 2 422 728 000 (~2,4 Md, pas ~268 M) ; P(16,6) = 5 765 760 et
x10 = 57 657 600 ; 16x15x14 = 3 360 et le vide EST encode (P(16,3)x13) ;
524 160 = P(16,4) x 12 ; k=5 = n (5 objets) ; objectif 5,97 => ~6 dims
piegees (prefixe imprime 4/10 coords) ; Sphere gagnee par PSO (0,0000),
GA domine 4/4. Review ai-01 au head 6ba0a574, markdown-only (C.2).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 .../Search-03b-PatternDatabases-Csharp.ipynb              | 8 ++++----
 .../Search-03c-LimitedDiscrepancySearch-Csharp.ipynb      | 2 +-
 .../Search-11-Metaheuristics-Csharp.ipynb                 | 8 ++++----
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-Csharp.ipynb b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-Csharp.ipynb
index 43d55d2c4a..9bddc4b037 100644
--- a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-Csharp.ipynb
+++ b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-Csharp.ipynb
@@ -456,7 +456,7 @@
    "id": "s03b-pdb-bfs-lecture",
    "metadata": {},
    "source": [
-    "### Lecture de la construction : 524 160 = P(16,4), et la table EST la solution précalculée\n",
+    "### Lecture de la construction : 524 160 = P(16,4) × 12, et la table EST la solution précalculée\n",
     "\n",
     "La sortie `524 160 états en 1,4 s, distance max = 50` se décompose entièrement à la main. Le BFS rétrograde énumère les positions possibles des 4 tuiles du motif **et** de la case vide dans les 16 cases : 16 × 15 × 14 × 13 = 43 680 arrangements de tuiles, × 12 positions restantes pour la vide = **524 160** états. Le `distance max = 50` dit ensuite que le pire sous-puzzle (les 4 tuiles les plus mal placées) exige 50 coups à lui seul : la table encode donc des optima *partiels* déjà très coûteux, que l'heuristique ira lire en O(1) au lieu de les recalculer. C'est tout le compromis : ~1,4 s de construction une fois, des millions de consultations gratuites ensuite.\n",
     "\n",
@@ -602,7 +602,7 @@
    "source": [
     "### Lecture des groupes : pourquoi la somme des 4 tables reste admissible\n",
     "\n",
-    "La sortie donne quatre tables : trois de 524 160 états (groupes de 4 tuiles) et une de 43 680 (groupe de 3 : 16 × 15 × 14 = 43 680, sans position de vide supplémentaire dans ce codage). Les distances max se lisent 21, 17, 19 et 16. Le point structurel : chaque coup du 15-puzzle déplace **une seule tuile**, qui appartient à **un seul** groupe — les coûts des groupes sont disjoints par coup, donc leur somme ne peut jamais surestimer la distance réelle. C'est la différence radicale avec la PDB classique de Culberson & Schaeffer : on y prenait le **max** de plusieurs vues du même puzzle ; Korf & Felner partitionnent en groupes **disjoints** pour pouvoir **sommer**. La même somme appliquée à des groupes qui se chevaucheraient casserait l'admissibilité immédiatement (un même coup compté deux fois)."
+    "La sortie donne quatre tables : trois de 524 160 états (groupes de 4 tuiles) et une de 43 680 (groupe de 3 : P(16,3) = 16 × 15 × 14 = 3 360 arrangements, × 13 positions restantes pour la case vide = 43 680 — le vide est encodé comme pour les groupes de 4). Les distances max se lisent 21, 17, 19 et 16. Le point structurel : chaque coup du 15-puzzle déplace **une seule tuile**, qui appartient à **un seul** groupe — les coûts des groupes sont disjoints par coup, donc leur somme ne peut jamais surestimer la distance réelle. C'est la différence radicale avec la PDB classique de Culberson & Schaeffer : on y prenait le **max** de plusieurs vues du même puzzle ; Korf & Felner partitionnent en groupes **disjoints** pour pouvoir **sommer**. La même somme appliquée à des groupes qui se chevaucheraient casserait l'admissibilité immédiatement (un même coup compté deux fois)."
    ]
   },
   {
@@ -1058,7 +1058,7 @@
    "source": [
     "### Attendus — Exercice 1 (partition 6-6-3)\n",
     "\n",
-    "Ce que vous devez observer si votre implémentation est juste : deux PDB de P(16,6) × 10 = 5 765 760 états chacune, une de P(16,3) × 13 = 43 680 — le temps de construction passe de ~4 s à plusieurs dizaines de secondes (d'où l'avertissement de l'énoncé), les distances max par groupe montent (un groupe de 6 est plus mal plaçable qu'un groupe de 4), et h_additive resserre encore : attendez-vous à ce que I1 descende nettement sous les 732 nœuds de la 4-4-4-3. Anti-piège : la partition doit rester **exactement** disjointe (15 tuiles = 6+6+3) ; réutiliser une tuile dans deux groupes compte ses coups deux fois et casse l'admissibilité — la cellule de vérification du §8 doit rester 40/40."
+    "Ce que vous devez observer si votre implémentation est juste : deux PDB de P(16,6) = 5 765 760 arrangements × 10 = 57 657 600 états chacune, une de P(16,3) × 13 = 43 680 — le temps de construction passe de ~4 s à plusieurs dizaines de secondes (d'où l'avertissement de l'énoncé), les distances max par groupe montent (un groupe de 6 est plus mal plaçable qu'un groupe de 4), et h_additive resserre encore : attendez-vous à ce que I1 descende nettement sous les 732 nœuds de la 4-4-4-3. Anti-piège : la partition doit rester **exactement** disjointe (15 tuiles = 6+6+3) ; réutiliser une tuile dans deux groupes compte ses coups deux fois et casse l'admissibilité — la cellule de vérification du §8 doit rester 40/40."
    ]
   },
   {
@@ -1273,7 +1273,7 @@
    "source": [
     "### Attendus — Exercice 3 (24-puzzle)\n",
     "\n",
-    "Au 24-puzzle (5 × 5), Manhattan est désespérément loose : les instances aléatoires moyennes exigent ~100 coups, et IDA* sous Manhattan explose au-delà de tout budget raisonnable. La structure du code est inchangée (N=5, but 1..24,0) mais les tailles explosent : un groupe de 6 tuiles dans 25 cases donne P(25,6) × 19 soit ~268 millions d'états — la table ne tient plus en mémoire sans encodage compact. C'est précisément pourquoi Korf & Felner ont poussé les partitions avec symétries et la compression : au 24-puzzle, la PDB n'est plus une optimisation, c'est la condition d'entrée.\n",
+    "Au 24-puzzle (5 × 5), Manhattan est désespérément loose : les instances aléatoires moyennes exigent ~100 coups, et IDA* sous Manhattan explose au-delà de tout budget raisonnable. La structure du code est inchangée (N=5, but 1..24,0) mais les tailles explosent : un groupe de 6 tuiles dans 25 cases donne P(25,6) × 19 = 2 422 728 000, soit ~2,4 milliards d'états — la table ne tient plus en mémoire sans encodage compact. C'est précisément pourquoi Korf & Felner ont poussé les partitions avec symétries et la compression : au 24-puzzle, la PDB n'est plus une optimisation, c'est la condition d'entrée.\n",
     "\n",
     "**L'arc du notebook** : représenter (permutations), abstraire (sous-espaces), précalculer (BFS rétrograde), sommer (disjonction), vérifier (admissibilité et dominance), mesurer (frontière du résoluble). Ce pipeline est transposable à tout domaine où l'on peut payer du calcul préliminaire pour accélérer des requêtes répétées."
    ]
diff --git a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03c-LimitedDiscrepancySearch-Csharp.ipynb b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03c-LimitedDiscrepancySearch-Csharp.ipynb
index aa1c8c55c0..b66eaa77af 100644
--- a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03c-LimitedDiscrepancySearch-Csharp.ipynb
+++ b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03c-LimitedDiscrepancySearch-Csharp.ipynb
@@ -414,7 +414,7 @@
    "source": [
     "### Lecture du tableau LDS : l'optimum est à k=1, le coût croît régulièrement\n",
     "\n",
-    "Trois lectures. (1) La colonne valeur saute de 10 (k=0) à 12 (k=1) puis **ne bouge plus** : un seul écart au glouton — refuser A — suffit à atteindre l'optimum. (2) Les nœuds montent 6, 13, 21, 28, 33, 34 : à k fixé, LDS explore les chemins à au plus k écarts ; k=5 = n−1 couvre déjà tout l'arbre (34 s'approche des 32 feuilles plus les nœuds internes revisités). (3) La sélection [B, C] est stable dès k=1 : LDS ne « change pas d'avis » en explorant plus, il confirme. Les deux warnings `CS8632` de la sortie sont bénins : des annotations de nullabilité `?` utilisées hors contexte `#nullable` (le gabarit interactif compile sans le flag) — ils n'affectent ni l'exécution ni les résultats."
+    "Trois lectures. (1) La colonne valeur saute de 10 (k=0) à 12 (k=1) puis **ne bouge plus** : un seul écart au glouton — refuser A — suffit à atteindre l'optimum. (2) Les nœuds montent 6, 13, 21, 28, 33, 34 : à k fixé, LDS explore les chemins à au plus k écarts ; k=5 = n couvre tout l'arbre (34 s'approche des 32 feuilles plus les nœuds internes revisités). (3) La sélection [B, C] est stable dès k=1 : LDS ne « change pas d'avis » en explorant plus, il confirme. Les deux warnings `CS8632` de la sortie sont bénins : des annotations de nullabilité `?` utilisées hors contexte `#nullable` (le gabarit interactif compile sans le flag) — ils n'affectent ni l'exécution ni les résultats."
    ]
   },
   {
diff --git a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-11-Metaheuristics-Csharp.ipynb b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-11-Metaheuristics-Csharp.ipynb
index a989116f23..6c9cc4fbf0 100644
--- a/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-11-Metaheuristics-Csharp.ipynb
+++ b/MyIA.AI.Notebooks/Search/Part1-Foundations/Search-11-Metaheuristics-Csharp.ipynb
@@ -332,9 +332,9 @@
    "id": "s11-pso-trapped-lecture",
    "metadata": {},
    "source": [
-    "### Lecture de la solution : 0,9950 = une dimension piégée\n",
+    "### Lecture de la solution : 0,9950 dans le préfixe imprimé, ~6 dimensions piégées\n",
     "\n",
-    "La solution `[0,0002, -0,0000, 0,0001, 0,9950, ...]` avec objectif 5,97 raconte une histoire précise : trois coordonnées sont posées sur 0 (le global), la quatrième est collée à **0,995, soit ~1,0** — un minimum local du cosinus de Rastrigin (les minima secondaires sont à ~1,0 de l'axe). L'objectif 5,97 se décompose presque exactement en « une dimension piégée » (~1 par dimension piégée, plus les résidus des autres) : l'essaim a trouvé le bon bassin pour 9 dimensions sur 10 et n'a jamais vu le déclic pour la dixième. C'est l'échec *partiel* typique du PSO : convergence intra-bassin excellente, basculement inter-bassins manqué."
+    "Le préfixe imprimé `[0,0002, -0,0000, 0,0001, 0,9950, ...]` ne montre que 4 des 10 coordonnées : trois quasi nulles, une collée à **0,995, soit ~1,0** — un minimum secondaire du cosinus de Rastrigin (les minima secondaires sont à ~1,0 de l'axe). L'objectif **5,969905** dit la suite : à ~1 par dimension piégée, 5,97 ≈ 6 × 1 — environ six des dix dimensions sont coincées dans des minima secondaires, dont cinq invisibles dans ce préfixe (la cellule n'imprime que les 4 premières). C'est l'échec *partiel* typique du PSO : convergence intra-bassin excellente (les dimensions libres retombent à ~0), basculement inter-bassins manqué pour les autres."
    ]
   },
   {
@@ -998,9 +998,9 @@
    "id": "s11-benchmark-lecture",
    "metadata": {},
    "source": [
-    "### Lecture du tableau final : aucun gagnant — un tableau de correspondances\n",
+    "### Lecture du tableau final : PSO devant sur trois fonctions, SA dans la vallée\n",
     "\n",
-    "Le tableau ne couronne personne : PSO gagne Rastrigin (4,99) et Ackley (0,012), SA gagne Rosenbrock (3,59), GA gagne Sphere — et SA perd Rastrigin de façon catastrophique (39,9, cohérent avec la lecture du plateau ci-dessus). Chaque colonne reflète la mécanique profonde vue section par section : l'essaim (information sociale partagée) couvre bien les multimodales ; le recuit (descente + acceptation d'exception) suit bien les vallées continues ; l'évolutionnaire (population + recombinaison) consolide bien les paysages réguliers. La leçon opérationnelle : **on choisit un algorithme par diagnostic du paysage**, pas par préférence — et on le vérifie en multi-seed (§3)."
+    "PSO gagne trois des quatre : Sphere (0,0000, devant le GA à 0,0002), Rastrigin (4,99) et Ackley (0,012) ; SA gagne Rosenbrock (3,59) — et perd Rastrigin de façon catastrophique (39,9, cohérent avec la lecture du plateau ci-dessus). Le GA maison est dominé sur les quatre fonctions à ce réglage. Chaque colonne reflète la mécanique profonde vue section par section : l'essaim (information sociale partagée) couvre bien les multimodales comme l'unimodale ; le recuit (descente + acceptation d'exception) suit bien les vallées continues ; le GA (codage continu, croisement arithmétique) n'a ici aucun terrain d'avantage. La leçon opérationnelle : **on choisit un algorithme par diagnostic du paysage**, pas par préférence — et on le vérifie en multi-seed (§3)."
    ]
   },
   {

From 0a7d51d2bf67bfaa46d51e30da6596d84e7539cc Mon Sep 17 00:00:00 2001
From: jsboige <jsboige@gmail.com>
Date: Sat, 19 Sep 2026 01:24:13 +0200
Subject: [PATCH 4/4] chore(twin,#16352): re-atteste Search-11/12/13 apres
 correctifs prose

--update en DERNIER : les corrections markdown-only deplacent les blob
SHA des jumeaux C#, les attestations 0014/0007/0009 devaient suivre (cf #8957).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 .../0015-2026-09-19-myia-po-2026-CoursIA.yaml               | 6 ++++++
 .../0008-2026-09-19-myia-po-2026-CoursIA.yaml               | 6 ++++++
 .../0010-2026-09-19-myia-po-2026-CoursIA.yaml               | 6 ++++++
 3 files changed, 18 insertions(+)
 create mode 100644 scripts/notebook_tools/twin_pairs.d/search-11-metaheuristics/0015-2026-09-19-myia-po-2026-CoursIA.yaml
 create mode 100644 scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0008-2026-09-19-myia-po-2026-CoursIA.yaml
 create mode 100644 scripts/notebook_tools/twin_pairs.d/search-13-limited-discrepancy-search/0010-2026-09-19-myia-po-2026-CoursIA.yaml

diff --git a/scripts/notebook_tools/twin_pairs.d/search-11-metaheuristics/0015-2026-09-19-myia-po-2026-CoursIA.yaml b/scripts/notebook_tools/twin_pairs.d/search-11-metaheuristics/0015-2026-09-19-myia-po-2026-CoursIA.yaml
new file mode 100644
index 0000000000..c54fe7428e
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/search-11-metaheuristics/0015-2026-09-19-myia-po-2026-CoursIA.yaml
@@ -0,0 +1,6 @@
+date: '2026-09-19'
+by: myia-po-2026:CoursIA
+python_sha: 3744321ea7a33090bc4878b5b39aa4280fcd48c8
+csharp_sha: 6c9cc4fbf03cbc28c97c24b16881612c0c30f0bc
+content_python_sha: 57c1fe227e75bb9a7f71144d578fd429bbc5bcfde619414ffea7f448ec47f610
+content_csharp_sha: 67c3d7389b985bd5aca82e4f34080d569b7b9e57b4a280966ebb117014c12cbf
diff --git a/scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0008-2026-09-19-myia-po-2026-CoursIA.yaml b/scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0008-2026-09-19-myia-po-2026-CoursIA.yaml
new file mode 100644
index 0000000000..1c688b2085
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0008-2026-09-19-myia-po-2026-CoursIA.yaml
@@ -0,0 +1,6 @@
+date: '2026-09-19'
+by: myia-po-2026:CoursIA
+python_sha: 5444cd1c5b3127ad8d8d79b1b38f6dc84e60eb0e
+csharp_sha: 9bddc4b037df96765932688b5cea052d86a5bf48
+content_python_sha: f3d6052c89c9d9fd4bb2712a4ec5a857c37a97200d9d1d6f6ce2560ec0b5edb7
+content_csharp_sha: aa43862d7a01acf9fd555b1ffc578976a78e46bf0a2d9e656887caea3775de1f
diff --git a/scripts/notebook_tools/twin_pairs.d/search-13-limited-discrepancy-search/0010-2026-09-19-myia-po-2026-CoursIA.yaml b/scripts/notebook_tools/twin_pairs.d/search-13-limited-discrepancy-search/0010-2026-09-19-myia-po-2026-CoursIA.yaml
new file mode 100644
index 0000000000..df12785e69
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/search-13-limited-discrepancy-search/0010-2026-09-19-myia-po-2026-CoursIA.yaml
@@ -0,0 +1,6 @@
+date: '2026-09-19'
+by: myia-po-2026:CoursIA
+python_sha: 7243f4c2b7701205258723863a3c39f8387135b0
+csharp_sha: b66eaa77afa929df14c228a60b6ad006007062d0
+content_python_sha: 22ff5f69261302b637cb07a633dcf7e95f0c07028ed1cfed30b0766b982a809d
+content_csharp_sha: 64443598efc759f257ea19943cace2d4ce7d5b5482cc4055ca06988d789399e4