diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04b-Wavelet-Scattering/WS-00a-Ondelettes-1D-from-scratch.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04b-Wavelet-Scattering/WS-00a-Ondelettes-1D-from-scratch.ipynb
index ca780780f1..b6444e004b 100644
--- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04b-Wavelet-Scattering/WS-00a-Ondelettes-1D-from-scratch.ipynb
+++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/04b-Wavelet-Scattering/WS-00a-Ondelettes-1D-from-scratch.ipynb
@@ -791,49 +791,19 @@
    "source": [
     "**Lecture — Doppler : le terrain non stationnaire, victoire nette de l'ondelette (sans oracle).** Le seuillage dur atteint **17,83 dB** (+8,86 dB sur le bruité), contre **13,36 dB** pour le meilleur Fourier — le cutoff *libre*, choisi en connaissant le signal — soit **+4,47 dB d'avance sans oracle**. Toutes les variantes Fourier s'effondrent ensemble (11,95 à 13,36 dB) parce que le problème est structurel : le §3 a montré que l'énergie du chirp est étalée sur toutes les échelles (top-3 détails = 32,9 % seulement). Un passe-bas doit donc choisir ce qu'il ampute : le cutoff libre sacrifie **1,70 % de l'énergie propre** — le début du chirp, précisément la partie haute fréquence — et le cutoff étroit (11,95 dB) ampute plus fort encore tout en gardant du bruit dans sa bande.\n",
     "\n",
-    "Côté ondelette, la parcimonie est extrême : **51 coefficients de détail sur 2040** (2,5 %) survivent au seuil $\\lambda = 1{,}369$. Un chirp dont l'information occupe tout le spectre se représente par 51 nombres, parce que chaque portion temporelle du signal trouve *son* échelle — c'est exactement le troc temps-fréquence du §0."
-   ]
-  },
-  {
-   "cell_type": "markdown",
-   "id": "8e7e8296",
-   "metadata": {
-    "papermill": {
-     "duration": 0.003847,
-     "end_time": "2026-09-14T03:04:46.073108",
-     "exception": false,
-     "start_time": "2026-09-14T03:04:46.069261",
-     "status": "completed"
-    },
-    "tags": []
-   },
-   "source": [
+    "Côté ondelette, la parcimonie est extrême : **51 coefficients de détail sur 2040** (2,5 %) survivent au seuil $\\lambda = 1{,}369$. Un chirp dont l'information occupe tout le spectre se représente par 51 nombres, parce que chaque portion temporelle du signal trouve *son* échelle — c'est exactement le troc temps-fréquence du §0.\n",
+    "\n",
     "**Lecture — HeaviSine : le terrain mixte, quasi-égalité, et une lecture honnête.** Le Fourier *libre* (23,28 dB @ fc=0,0100) devance ici le seuillage dur (22,43 dB) de 0,85 dB. Trois observations pour ne pas se mentir :\n",
     "\n",
     "1. **Ce signal est presque à bande limitée** : 97,1 % de l'énergie dans l'approximation a8, amputation du cutoff libre = 0,19 % (presque rien). Quand le signal vit dans une bande étroite, le passe-bas optimal est presque idéal — nous sommes aussi sur le terrain de Fourier, et l'oracle peut choisir un cutoff qui ne détruit presque rien.\n",
     "2. **L'ondelette gagne contre les Fourier non libres** : garde-tout 21,64 dB, étroit 18,94 dB, tous deux battus par 22,43 dB — sans aucune connaissance du signal.\n",
     "3. **La parcimonie est stupéfiante** : 8 coefficients de détail sur 2040 (0,4 %). L'estimateur ondelette décrit ce signal par « deux sinus + deux sauts localisés » en quelques nombres — les sauts survivent comme quelques grands coefficients répartis sur toutes les échelles, les sinus dans l'approximation.\n",
     "\n",
-    "Verdict honnête : quasi-égalité sur un terrain qui favorise Fourier, avec un estimateur qui n'a rien su du signal."
-   ]
-  },
-  {
-   "cell_type": "markdown",
-   "id": "49cacd48",
-   "metadata": {
-    "papermill": {
-     "duration": 0.003999,
-     "end_time": "2026-09-14T03:04:46.082477",
-     "exception": false,
-     "start_time": "2026-09-14T03:04:46.078478",
-     "status": "completed"
-    },
-    "tags": []
-   },
-   "source": [
+    "Verdict honnête : quasi-égalité sur un terrain qui favorise Fourier, avec un estimateur qui n'a rien su du signal.\n",
+    "\n",
     "**Lecture — Stationnaire + burst : le terrain de Fourier, assumé — et le contrepoint du transitoire.** Le passe-bas gagne nettement en SNR global : étroit **19,92 dB**, libre **21,19 dB** (amputation 0,37 %) contre **16,37 dB** pour l'ondelette. C'est le résultat attendu — deux tons éternels sont l'objet parfait de Fourier, et couper à fc = 0,025–0,05 élimine le bruit partout ailleurs. L'asymétrie de protocole joue aussi : ces cutoffs savent où vivent les tons.\n",
     "\n",
-    "Le contrepoint est le **pic du burst** (valeur propre : 1,362). Toutes les méthodes le surestiment — le maximum d'un signal bruité est biaisé vers le haut — mais pas autant : dur **1,485** (écart +0,12), étroit 1,496 (+0,13), garde-tout 1,564 (+0,20). L'ondelette dure est la plus proche du vrai pic, le garde-tout la plus déformée. Surtout, le **doux écrase** le transitoire : pic 0,996, soit **−27 %** — les coefficients du burst, tout juste au-dessus du seuil, sont rétractés de $\\lambda$. Et le SNR local de l'ondelette dure (autour du burst) tombe à 11,44 dB : le transitoire reste le point dur des deux familles."
+    "Le contrepoint est le **pic du burst** (valeur propre : 1,362). Toutes les méthodes le surestiment — le maximum d'un signal bruité est biaisé vers le haut — mais pas autant : dur **1,485** (écart +0,12), étroit 1,496 (+0,13), garde-tout 1,564 (+0,20). L'ondelette dure est la plus proche du vrai pic, le garde-tout la plus déformée. Surtout, le **doux écrase** le transitoire : pic 0,996, soit **−27 %** — les coefficients du burst, tout juste au-dessus du seuil, sont rétractés de $\\lambda$. Et le SNR local de l'ondelette dure (autour du burst) tombe à 11,44 dB : le transitoire reste le point dur des deux familles.\n"
    ]
   },
   {
diff --git a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day4-Foundations/Lab9-First-ADK-Agent.ipynb b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day4-Foundations/Lab9-First-ADK-Agent.ipynb
index 17de7d323b..083bda0ee8 100644
--- a/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day4-Foundations/Lab9-First-ADK-Agent.ipynb
+++ b/MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/Day4-Foundations/Lab9-First-ADK-Agent.ipynb
@@ -329,23 +329,8 @@
                 "\n",
                 "**Reproductibilité.** Le notebook recharge le fichier versionné `sales_data.csv` à chaque exécution : les outils ADK travaillent donc sur le même jeu de données et les mêmes agrégats. Les valeurs citées dans les interprétations (revenus par région et top produits) restent vérifiables directement avec pandas.\n",
                 "\n",
-                "**Pourquoi un CSV.** L'agent ne reçoit pas le DataFrame brut dans son prompt. Les tools pandas fermés sur `df` effectuent les calculs puis transmettent seulement leurs retours structurés à l'agent. Le fichier matérialise le jeu de test sur disque et découple sa provenance de l'état du kernel."
-            ]
-        },
-        {
-            "cell_type": "markdown",
-            "id": "cell-6",
-            "metadata": {
-                "papermill": {
-                    "duration": 0.002657,
-                    "end_time": "2026-09-04T10:22:16.601931+00:00",
-                    "exception": false,
-                    "start_time": "2026-09-04T10:22:16.599274+00:00",
-                    "status": "completed"
-                },
-                "tags": []
-            },
-            "source": [
+                "**Pourquoi un CSV.** L'agent ne reçoit pas le DataFrame brut dans son prompt. Les tools pandas fermés sur `df` effectuent les calculs puis transmettent seulement leurs retours structurés à l'agent. Le fichier matérialise le jeu de test sur disque et découple sa provenance de l'état du kernel.\n",
+                "\n",
                 "### Lecture de l'implémentation : trois briques, une passe unique\n",
                 "\n",
                 "Le code ci-dessus repose sur trois briques fondamentales, et chacune porte une décision de conception claire :\n",
@@ -354,7 +339,7 @@
                 "\n",
                 "- **`run_agent_turn`** — le cœur opérationnel : cette fonction déclenche l'exécution de l'agent pour un tour unique. Elle encapsule l'appel au LLM, la validation des appels de tools selon leurs signatures typées, et retourne un objet `AdkRunResult` contenant la réponse textuelle, les appels de tools effectués avec leurs paramètres, et les métriques d'exécution. Le contexte est passé une seule fois, sans boucle de révision : une seule passe, comme le montre concrètement l'échec étudié dans la section 5. Cette simplicité est voulue pour isoler chaque étape du pipeline.\n",
                 "\n",
-                "- **`AdkRunResult`** — la structure de retour qui matérialise le résultat : `response_text` pour la réponse finale du LLM, `tool_calls` pour la liste détaillée des invocations (avec les noms des tools, leurs arguments sérialisés, et leur statut), et `tool_was_invoked` pour un flag booléen indiquant si au moins un tool a été utilisé. C'est cette transparence qui permet de déboguer les échecs d'appel ou de comprendre précisément pourquoi un tool n'a pas été invoqué dans la suite du laboratoire."
+                "- **`AdkRunResult`** — la structure de retour qui matérialise le résultat : `response_text` pour la réponse finale du LLM, `tool_calls` pour la liste détaillée des invocations (avec les noms des tools, leurs arguments sérialisés, et leur statut), et `tool_was_invoked` pour un flag booléen indiquant si au moins un tool a été utilisé. C'est cette transparence qui permet de déboguer les échecs d'appel ou de comprendre précisément pourquoi un tool n'a pas été invoqué dans la suite du laboratoire.\n"
             ]
         },
         {
@@ -1418,8 +1403,8 @@
             "end_time": "2026-09-04T10:22:31.415357+00:00",
             "environment_variables": {},
             "exception": null,
-            "input_path": "D:\\dev\\CoursIA-vibe\\lab9-adk\\MyIA.AI.Notebooks\\ML\\DataScienceWithAgents\\Track2-GoogleADK\\Day4-Foundations\\Lab9-First-ADK-Agent.ipynb",
-            "output_path": "D:\\dev\\CoursIA-vibe\\lab9-adk\\MyIA.AI.Notebooks\\ML\\DataScienceWithAgents\\Track2-GoogleADK\\Day4-Foundations\\Lab9-First-ADK-Agent_output.ipynb",
+            "input_path": "Lab9-First-ADK-Agent.ipynb",
+            "output_path": "Lab9-First-ADK-Agent.ipynb",
             "parameters": {},
             "start_time": "2026-09-04T10:22:10.904375+00:00",
             "version": "2.6.0"
diff --git a/MyIA.AI.Notebooks/ML/ML.Net/ML-3-Entrainement-Python.ipynb b/MyIA.AI.Notebooks/ML/ML.Net/ML-3-Entrainement-Python.ipynb
index 1b7d93eb5f..096ded6c9b 100644
--- a/MyIA.AI.Notebooks/ML/ML.Net/ML-3-Entrainement-Python.ipynb
+++ b/MyIA.AI.Notebooks/ML/ML.Net/ML-3-Entrainement-Python.ipynb
@@ -500,14 +500,8 @@
     "1. **LinearRegression échoue** (RMSE 7,01) : sur une sinusoïde, une droite est structurellement inadaptée. Le modèle le plus simple est ici le pire — contrairement à l'exemple précédent sur données linéaires.\n",
     "2. **RandomForest bat GradientBoosting** (3,06 vs 3,79) : sur 60 points bruités, le RF (moyenne de 50 arbres peu profonds) est plus robuste au bruit que le GBM (qui additionne des arbres et peut amplifier le bruit). L'écart est faible mais répété sur 5 plis — la CV donne une mesure stable.\n",
     "\n",
-    "AutoML n'a pas « deviné » : il a mesuré. C'est la différence entre l'intuition et la preuve expérimentale."
-   ]
-  },
-  {
-   "cell_type": "markdown",
-   "id": "6e5b515e",
-   "metadata": {},
-   "source": [
+    "AutoML n'a pas « deviné » : il a mesuré. C'est la différence entre l'intuition et la preuve expérimentale.\n",
+    "\n",
     "### Interprétation — pourquoi AutoML sur données sinusoïdales\n",
     "\n",
     "Sur données sinusoïdales, la `LinearRegression` échoue — elle ne modélise\n",
@@ -515,7 +509,7 @@
     "`RandomForest`, `SVR` RBF) s'en sortent bien mieux. **C'est tout l'intérêt\n",
     "d'AutoML** : on ne parie pas sur un algorithme, on laisse la validation\n",
     "croisée désigner le meilleur pour ce dataset — les chiffres du classement\n",
-    "sont lus dans la section précédente."
+    "sont lus dans la section précédente.\n"
    ]
   },
   {
diff --git a/MyIA.AI.Notebooks/ML/ML.Net/ML-5-TimeSeries.ipynb b/MyIA.AI.Notebooks/ML/ML.Net/ML-5-TimeSeries.ipynb
index 3778f056cb..1f8a8f87b5 100644
--- a/MyIA.AI.Notebooks/ML/ML.Net/ML-5-TimeSeries.ipynb
+++ b/MyIA.AI.Notebooks/ML/ML.Net/ML-5-TimeSeries.ipynb
@@ -1070,14 +1070,8 @@
     "| MAE faible | < 10% des ventes moyennes | > 30% des ventes moyennes |\n",
     "| RMSE proche de MAE | Erreurs uniformes | Grosses erreurs ponctuelles |\n",
     "\n",
-    "**Exemple** : Si les ventes moyennes sont de 150, un MAE de 15 (10%) est considéré comme bon."
-   ]
-  },
-  {
-   "cell_type": "markdown",
-   "id": "c773-naive-baseline-interpretation",
-   "metadata": {},
-   "source": [
+    "**Exemple** : Si les ventes moyennes sont de 150, un MAE de 15 (10%) est considéré comme bon.\n",
+    "\n",
     "### Interprétation : au-delà du MAE — la baseline naïve\n",
     "\n",
     "Un MAE ne dit pas si le modèle SSA est *utile* : il dit seulement de combien les prévisions s'écartent en moyenne de la vérité. **La question pédagogique déterminante** est : *le SSA bat-il une prédiction triviale ?*\n",
@@ -1095,7 +1089,7 @@
     "\n",
     "**Gain relatif : 45.2% en MAE, 42.0% en RMSE** — le SSA bat nettement la persistance. La série porte donc une structure (tendance + saisonnalité hebdomadaire) que la dernière valeur seule ne porte pas : l'investissement ML.NET est ici justifié pour la prédiction ponctuelle.\n",
     "\n",
-    "> **Leçon** : corriger le protocole d'évaluation a fait passer le MAE affiché de **33.8** (valeur buggée par l'appariement `SelectMany.Zip`) à **10.5**. C'est exactement pourquoi *toujours comparer à une baseline triviale* (Hyndman & Koehler, 2006) et **aligner chaque prédiction sur sa date cible** sont deux réflexes indissociables de l'évaluation forecasting."
+    "> **Leçon** : corriger le protocole d'évaluation a fait passer le MAE affiché de **33.8** (valeur buggée par l'appariement `SelectMany.Zip`) à **10.5**. C'est exactement pourquoi *toujours comparer à une baseline triviale* (Hyndman & Koehler, 2006) et **aligner chaque prédiction sur sa date cible** sont deux réflexes indissociables de l'évaluation forecasting.\n"
    ]
   },
   {
diff --git a/MyIA.AI.Notebooks/SymbolicAI/SMT/Z3-API/Z3-16-Meal-Planner-Python.ipynb b/MyIA.AI.Notebooks/SymbolicAI/SMT/Z3-API/Z3-16-Meal-Planner-Python.ipynb
index 443479a926..d542864d12 100644
--- a/MyIA.AI.Notebooks/SymbolicAI/SMT/Z3-API/Z3-16-Meal-Planner-Python.ipynb
+++ b/MyIA.AI.Notebooks/SymbolicAI/SMT/Z3-API/Z3-16-Meal-Planner-Python.ipynb
@@ -559,24 +559,9 @@
     "(OBBTP, maxres selon la théorie). L'alternative manuelle — une **dichotomie** sur le coût\n",
     "(`Solver` avec `cost <= mid`, resserrer `mid` jusqu'à unsat) — marche mais demande N appels\n",
     "et une logique de boucle. `Optimize` le fait en un appel, et généralise (`maximize`, objectifs\n",
-    "multiples, front de Pareto — cf. notebook 06)."
-   ]
-  },
-  {
-   "cell_type": "markdown",
-   "id": "f1a6b3c8",
-   "metadata": {
-    "papermill": {
-     "duration": 0.004341,
-     "end_time": "2026-09-28T11:49:45.144579",
-     "exception": false,
-     "start_time": "2026-09-28T11:49:45.140238",
-     "status": "completed"
-    },
-    "tags": []
-   },
-   "source": [
-    "**Lecture chiffrée — le prix de l'équilibre et l'optimum confirmé deux fois.** Trois menus se lisent ensemble : le moins cher (énumération §2 et `Optimize` §4) rend **8,50 EUR** pour 770 kcal et 27 g de protéines ; le menu équilibré (§3) rend **10,50 EUR** pour 630 kcal et 37 g ; le menu libre sans contrainte (§1) tombe à 530 kcal. L'équilibre nutritionnel se facture : **+2,00 EUR/jour** et l'abandon de 140 kcal par rapport au menu le moins cher, en échange de +10 g de protéines — un solveur ne « préfère » pas l'équilibre, il le facture. Et l'optimum de coût se lit en croisant deux méthodes indépendantes : l'énumération exhaustive (36 combinaisons filtrées sur 36) et l'`Optimize` SMT rendent le même minimum **8,50 EUR** avec le même menu (soupe de légumes + pâtes à la bolognaise + mousse au chocolat). Deux algorithmes sans aucune ligne de code en commun qui convergent vers le même chiffre : c'est la validation la plus forte disponible sur un petit domaine — et la raison pour laquelle l'énumération reste le témoin de référence tant qu'elle reste tractable."
+    "multiples, front de Pareto — cf. notebook 06).\n",
+    "\n",
+    "**Lecture chiffrée — le prix de l'équilibre et l'optimum confirmé deux fois.** Trois menus se lisent ensemble : le moins cher (énumération §2 et `Optimize` §4) rend **8,50 EUR** pour 770 kcal et 27 g de protéines ; le menu équilibré (§3) rend **10,50 EUR** pour 630 kcal et 37 g ; le menu libre sans contrainte (§1) tombe à 530 kcal. L'équilibre nutritionnel se facture : **+2,00 EUR/jour** et l'abandon de 140 kcal par rapport au menu le moins cher, en échange de +10 g de protéines — un solveur ne « préfère » pas l'équilibre, il le facture. Et l'optimum de coût se lit en croisant deux méthodes indépendantes : l'énumération exhaustive (36 combinaisons filtrées sur 36) et l'`Optimize` SMT rendent le même minimum **8,50 EUR** avec le même menu (soupe de légumes + pâtes à la bolognaise + mousse au chocolat). Deux algorithmes sans aucune ligne de code en commun qui convergent vers le même chiffre : c'est la validation la plus forte disponible sur un petit domaine — et la raison pour laquelle l'énumération reste le témoin de référence tant qu'elle reste tractable.\n"
    ]
   },
   {
diff --git a/MyIA.AI.Notebooks/SymbolicAI/SMT/Z3-API/Z3-16e-Meal-Planner-Optimize-Python.ipynb b/MyIA.AI.Notebooks/SymbolicAI/SMT/Z3-API/Z3-16e-Meal-Planner-Optimize-Python.ipynb
index bea7867878..15222762f9 100644
--- a/MyIA.AI.Notebooks/SymbolicAI/SMT/Z3-API/Z3-16e-Meal-Planner-Optimize-Python.ipynb
+++ b/MyIA.AI.Notebooks/SymbolicAI/SMT/Z3-API/Z3-16e-Meal-Planner-Optimize-Python.ipynb
@@ -893,23 +893,8 @@
     "\n",
     "Un glouton \"jour par jour\" choisirait, pour chaque jour, les 3 plats les moins chers satisfaisant la fenetre kcal — mais il **ignorerait le couplage hebdomadaire** : apres 2 repetitions, les plats les moins chers deviennent indisponibles (contrainte de variete), et le glouton se retrouve bloque ou contraint de prendre des plats chers en fin de semaine, sans avoir anticipe. Le `Optimize()` de Z3, lui, minimise le **cout total sur les 7 jours simultanement** : il repartit les repetitions bon marche sur toute la semaine pour minimiser la somme globale.\n",
     "\n",
-    "**Capabilite exercee (Prong-B).** La matrice booleenne `Sel[7][24]` (168 variables) est resolue en quelques centaines de millisecondes : l'optimisation SMT reste tractable a cette echelle. La frontiere de convergence est plus loin — un corpus RecipeML a ~11 000 recettes (variables `Sel[7][11000]` = 77 000 Booleens par jour) sortirait du regime d'un simple `Optimize()` et demanderait une decomposition (column-generation, Lagrangian relaxation) : c'est la limite honnete de la \"couverture bornee\" d'un solveur SMT monocall, signalee dans l'Epic #1206.\n"
-   ]
-  },
-  {
-   "cell_type": "markdown",
-   "id": "s6b-lecture",
-   "metadata": {
-    "papermill": {
-     "duration": 0.00262,
-     "end_time": "2026-10-05T02:09:14.908408+00:00",
-     "exception": false,
-     "start_time": "2026-10-05T02:09:14.905788+00:00",
-     "status": "completed"
-    },
-    "tags": []
-   },
-   "source": [
+    "**Capabilite exercee (Prong-B).** La matrice booleenne `Sel[7][24]` (168 variables) est resolue en quelques centaines de millisecondes : l'optimisation SMT reste tractable a cette echelle. La frontiere de convergence est plus loin — un corpus RecipeML a ~11 000 recettes (variables `Sel[7][11000]` = 77 000 Booleens par jour) sortirait du regime d'un simple `Optimize()` et demanderait une decomposition (column-generation, Lagrangian relaxation) : c'est la limite honnete de la \"couverture bornee\" d'un solveur SMT monocall, signalee dans l'Epic #1206.\n",
+    "\n",
     "**Lecture chiffree — quatre ordres de grandeur sur le corpus de jouet.** Le plan a cout minimal ci-dessus (D=7, 24 plats) se resout en une fraction de seconde dans ce notebook (le temps exact est imprime par la cellule de code ci-dessus) ; le [16](Z3-16-Meal-Planner-Python.ipynb) mesure, sur le meme corpus de jouet, l'enumeration des 36 combinaisons **0,06 ms**, le plan SMT booleen D=3 **2,4 ms** et l'`Optimize` a cout minimal D=1 **17,7 ms**. L'enumeration gagne partout ou elle reste tractable — mais sa pente est exponentielle en le nombre de variables quand celle du solveur suit la combinatoire contrainte. Passer de 3 a 7 jours avec corpus elargi et contrainte de variete coute environ deux ordres de grandeur (millisecondes -> fraction de seconde) : observation sur cette paire de runs, pas une loi (jours et corpus changent en meme temps). La lecture pratique : le temps du solveur achete l'exactitude a l'echelle ou l'enumeration explose, et la fenetre [1400, 1900] kcal avec 40 g de proteines reste resolue en moins d'une seconde a D=7.\n"
    ]
   },
diff --git a/MyIA.AI.Notebooks/SymbolicAI/Tweety/Tweety-04-Belief-Revision-Python.ipynb b/MyIA.AI.Notebooks/SymbolicAI/Tweety/Tweety-04-Belief-Revision-Python.ipynb
index 634015efed..bbc4ad92dc 100644
--- a/MyIA.AI.Notebooks/SymbolicAI/Tweety/Tweety-04-Belief-Revision-Python.ipynb
+++ b/MyIA.AI.Notebooks/SymbolicAI/Tweety/Tweety-04-Belief-Revision-Python.ipynb
@@ -767,23 +767,8 @@
     "\n",
     "Une source très crédible peut énoncer une croyance périphérique (faible enracinement) : les deux classements ne se déduisent pas l'un de l'autre. Les opérateurs **Simple** et **Argumentatif** ci-dessus raisonnent en *crédibilité* (multi-agents) ; l'opérateur **Levi**, via la contraction par noyaux, relève du courant AGM mono-agent (enracinement). Le notebook navigue ainsi entre deux familles de la révision de croyances.\n",
     "\n",
-    "> **À noter.** Les sections suivantes (3.2–3.4 : mesures d'incohérence, MUS, MaxSAT) ne *révisent* plus l'incohérence : elles la *mesurent* et la *diagnostiquent*. C'est un courant de recherche complémentaire, distinct de la révision AGM — mais tout aussi utile pour décider *quoi* réviser."
-   ]
-  },
-  {
-   "cell_type": "markdown",
-   "id": "0nknh8tpey7",
-   "metadata": {
-    "papermill": {
-     "duration": 0.003945,
-     "end_time": "2026-06-02T17:37:13.671837+00:00",
-     "exception": false,
-     "start_time": "2026-06-02T17:37:13.667892+00:00",
-     "status": "completed"
-    },
-    "tags": []
-   },
-   "source": [
+    "> **À noter.** Les sections suivantes (3.2–3.4 : mesures d'incohérence, MUS, MaxSAT) ne *révisent* plus l'incohérence : elles la *mesurent* et la *diagnostiquent*. C'est un courant de recherche complémentaire, distinct de la révision AGM — mais tout aussi utile pour décider *quoi* réviser.\n",
+    "\n",
     "#### Interpretation des résultats de revision\n",
     "\n",
     "Les trois opérateurs produisent des résultats différents selon leur stratégie de gestion des conflits :\n",
@@ -818,7 +803,7 @@
     "- **Simple** (comparaison de crédibilité pure) **n'en intègre aucune** : `!p` et `s` viennent d'agents moins crédibles (A2, A3) que le détenteur de `p` (A1), donc la base reste **inchangée**.\n",
     "- **Argumentatif** intègre `s` (info neutre de A3) mais **pas** `!p` (qui contredirait `p` de A1, l'agent le plus crédible), et retire en prime `p=>r` et `!q`.\n",
     "\n",
-    "> **Honnêteté sur l'objectif initial.** Le scénario (commentaire de la cellule de définition) visait à faire ressortir une différence de traitement de `!r` entre Simple et Argumentatif. La sortie réelle de Tweety 1.28+ **ne le confirme pas** : les deux gardent `!r`. Plutôt que de forcer la narration attendue (ce serait malhonnête vis-à-vis de la sortie committée), on retient la différence **réellement observée** — la stratégie d'intégration des nouvelles informations — qui n'en reste pas moins pédagogiquement riche (priorité *Levi* vs crédibilité *Simple* vs raisonnement *Argumentatif*)."
+    "> **Honnêteté sur l'objectif initial.** Le scénario (commentaire de la cellule de définition) visait à faire ressortir une différence de traitement de `!r` entre Simple et Argumentatif. La sortie réelle de Tweety 1.28+ **ne le confirme pas** : les deux gardent `!r`. Plutôt que de forcer la narration attendue (ce serait malhonnête vis-à-vis de la sortie committée), on retient la différence **réellement observée** — la stratégie d'intégration des nouvelles informations — qui n'en reste pas moins pédagogiquement riche (priorité *Levi* vs crédibilité *Simple* vs raisonnement *Argumentatif*).\n"
    ]
   },
   {
diff --git a/scripts/notebook_tools/twin_pairs.d/ml-3-entrainement-automl.yaml b/scripts/notebook_tools/twin_pairs.d/ml-3-entrainement-automl.yaml
index ab1fd4cc11..90bc4ff1d8 100644
--- a/scripts/notebook_tools/twin_pairs.d/ml-3-entrainement-automl.yaml
+++ b/scripts/notebook_tools/twin_pairs.d/ml-3-entrainement-automl.yaml
@@ -6,6 +6,7 @@
   bridge_verdict: SOTA-OK
   bridge_verdict_reason: "Modele nominal lib-vs-lib #10382 (moteurs distincts, chacun prod) : C# = Microsoft.ML (NuGet officiel Microsoft.ML, native .NET : Microsoft.ML.Transforms/Regression/Clustering/TimeSeries) et Python = scikit-learn (pip sklearn, native Python) -- chaque cote atteint le moteur SOTA ML de son ecosysteme, ni pont intermediaire ni reimplementation. Aucune asymetrie de machinerie a corriger. Verifie firsthand : C# Microsoft.ML refs + execution_count, Python sklearn imports."
   known_differences:
+    - "2026-10-08 : redressement densite #17040 (tranche residu ML/SMT/Tweety, PR #19902, lane myia-po-2026:CoursIA) — la cellule '### Interprétation — pourquoi AutoML sur données sinusoïdales' est fusionnée, côté Python (`ML-3-Entrainement-Python.ipynb`, seul côté modifié, jumeau C# non touché), dans la cellule '### Lecture du classement AutoML' qui la précède (deux lectures consécutives d'une même séquence). Markdown-only : cellules de code byte-identiques (8/8), aucun output ni engine touché, aucune ré-exécution due ; parité sémantique inchangée. Rebaseline attestation 0016."
     - "2026-10-01 : prose du leaderboard AutoML cote C# realignee sur la sortie commitee (audit #17700, PR #18643) — la prose citait une execution perimee (10 essais / meilleur 90 262) que la sortie contredit (16 essais / 1 217 349) ; budget AutoML 30 s = nombre d'essais machine-dependant. Markdown-only, aucun output/engine touche ; parite semantique inchangee (C# = AutoML + leaderboard SVG, Python = GridSearchCV/CV deterministe — lecons complementaires, re-audit firsthand des deux jumeaux). Rebaseline attestation 0015 (myia-po-2023:CoursIA)."
     - "2026-08-31 : consolidation #13764 — le bloc sinusoidal C# orphelin (anciennes cellules 21-23, amorce sans titre + intro apres le code + exercice hors sequence) est reintegre en cellule markdown '### Exercice 4 : comparaison SDCA vs LightGbm sur donnees sinusoidales' placee AVANT son code, amorce orpheline supprimee, sequence numerotee continue (Ex1-4). La C# conserve la comparaison manuelle SDCA vs LightGbm = couverture du socle commun 'lineaire vs boosting' (parite twin PRESPECIFEE, entree 2026-08-16 'Asymetrie de couverture') : la malformation etait le defaut, pas l'existence. Cette branche a re-execute le notebook .NET (kernel .net-csharp, papermill 25/25, real outputs : 10 cellules code, execution_count 1..10 monotones, 0 null) et a du ajouter un commentaire `// Exercice 4` en 1re ligne du stub code + auto-fix separateur `---` setext -> `***`. Rebaseline content_csharp_sha par re-audit twin (2026-08-31, myia-po-2024:CoursIA)."
     - "2026-08-16 : migration de la derniere cellule Plotly-CDN du depot vers SVG inline cote C# (issue #11104, PR #11173). Le graphique du leaderboard AutoML passe de `Plotly.NET.Interactive` 3.0.2 (sortie HTML dependante d'un CDN, invisible en export statique) a `SvgChartHelper` (canon #6927, SVG inline sans requete reseau) ; `Microsoft.ML.AutoML` recule 0.23.0 -> 0.22.3 pour rester sous le plafond Roslyn 4.12.0.0 du kernel epingle. Le graphique n'est pas supprime, il devient hors-reseau : parite SEMANTIQUE conservee (meme socle pedagogique, memes moteurs, C# re-execute 10/10 cellules / 0 erreur / 48,7 s). Rebaseline content SHA apres re-audit firsthand (myia-ai-01:CoursIA)."
diff --git a/scripts/notebook_tools/twin_pairs.d/ml-3-entrainement-automl/0016-2026-10-08-myia-po-2026-CoursIA.yaml b/scripts/notebook_tools/twin_pairs.d/ml-3-entrainement-automl/0016-2026-10-08-myia-po-2026-CoursIA.yaml
new file mode 100644
index 0000000000..3c875216a0
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/ml-3-entrainement-automl/0016-2026-10-08-myia-po-2026-CoursIA.yaml
@@ -0,0 +1,6 @@
+date: '2026-10-08'
+by: myia-po-2026:CoursIA
+python_sha: 096ded6c9b53a1ce79e2d7326b057644f0cdf2a0
+csharp_sha: 6c94acd7c342532543c880fac8c50f38b8117a17
+content_python_sha: 77ba5f6ebc41cc1a3a7d4be94fe6860aff57a15473a5f16d9da5fd4192e7510b
+content_csharp_sha: c4b216961bfec1a096bd1d0e7c74db7107ceea9a00d5c0aa7032de6fc4867655
diff --git a/scripts/notebook_tools/twin_pairs.d/ml-5-timeseries.yaml b/scripts/notebook_tools/twin_pairs.d/ml-5-timeseries.yaml
index 455149cbed..71ebdf316b 100644
--- a/scripts/notebook_tools/twin_pairs.d/ml-5-timeseries.yaml
+++ b/scripts/notebook_tools/twin_pairs.d/ml-5-timeseries.yaml
@@ -7,6 +7,7 @@
   bridge_verdict_reason: "Modele nominal lib-vs-lib #10382 (moteurs distincts, algorithmes differents) : C# = Microsoft.ML.Transforms.TimeSeries ForecastBySsa (Singular Spectrum Analysis, ML.NET-native) et Python = statsmodels (STL decomposition + SARIMAX, native Python) -- familles algorithmiques differentes (SSA vs SARIMAX) mais CHAQUE COTE atteint un moteur SOTA de forecast saisonnier de son ecosysteme. Aucun pont intermediaire, aucune reimplementation from-scratch. Verifie firsthand C# + exec, Python statsmodels imports. Adjudication 2026-08-19 (dispatch #10382, comment 5335643895, lane myia-po-2026:CoursIA) : le test du schema est PASSE des deux cotes -- C# : moteur Microsoft.ML.TimeSeries 5.0.0 (nuget cell[1], using cell[14]), point d'entree ForecastBySsa, 15/15 cellules code execution_count != null ; Python : moteur statsmodels, points d'entree STL.fit cell[11] + SARIMAX cell[14], 12/12 execution_count != null. La difference de famille algorithmique n'empeche PAS native-both (le schema le dit explicitement : native-both ne dit rien de la correspondance structurelle cellule-par-cellule) -- c'est la forme exacte du modele nominal PyMC-vs-Infer.NET du mandat owner. Reclassification surface -> native-both."
 
   known_differences:
+    - "2026-10-08 : redressement densite #17040 (tranche residu ML/SMT/Tweety, PR #19902, lane myia-po-2026:CoursIA) — la cellule '### Interprétation : au-delà du MAE — la baseline naïve' est fusionnée, côté C# (`ML-5-TimeSeries.ipynb`, seul côté modifié, jumeau Python non touché), dans la cellule '### Interprétation des métriques' qui la précède. Markdown-only : cellules de code byte-identiques (16/16), aucun output ni engine touché, aucune ré-exécution due ; parité sémantique inchangée. Rebaseline attestation 0006."
     - "2026-09-03 : protocole d evaluation C# refondu par #13001 (#12988) sans changement de moteur : table alignee (origine x horizon, reel vs predit vs naive) remplace le SelectMany.Zip non aligne (MAE 33,8 / RMSE 41,8 bugges), baseline naive executee, + Exercice 6 temperature. Les metriques C# ne sont PAS comparables au twin Python (STL/SARIMAX, cf non-comparabilite documentee ci-dessus) -- divergence de protocole d evaluation, pas de parite de moteur."
     - "2026-08-19 : reclassification surface -> native-both (adjudication dispatch #10382 '3 paires surface', lane myia-po-2026:CoursIA). Les DEUX cotes font le travail du notebook au moyen d'un moteur de production nomme de leur ecosysteme : C# = Microsoft.ML.TimeSeries 5.0.0 ForecastBySsa (15/15 cellules code executees), Python = statsmodels STL + SARIMAX (12/12 executees). La difference de famille algorithmique reste documentee ci-dessous -- difference de METHODE, pas absence de moteur."
     - "2026-08-15 : correction d'auteurs falsifies (issue #11044, tranche W3C SPARQL / ML.NET KDD) — citations remises a leurs auteurs reels (Amizadeh S., DOI KDD, Protocol et al., etc.), markdown-only, aucun changement d'engine/outputs. Parite semantique conservee ; rebaseline content SHA (re-audit 2026-08-15, myia-po-2026:CoursIA-2)."
diff --git a/scripts/notebook_tools/twin_pairs.d/ml-5-timeseries/0006-2026-10-08-myia-po-2026-CoursIA.yaml b/scripts/notebook_tools/twin_pairs.d/ml-5-timeseries/0006-2026-10-08-myia-po-2026-CoursIA.yaml
new file mode 100644
index 0000000000..8c7d209903
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/ml-5-timeseries/0006-2026-10-08-myia-po-2026-CoursIA.yaml
@@ -0,0 +1,6 @@
+date: '2026-10-08'
+by: myia-po-2026:CoursIA
+python_sha: 5e863ede175ce3bf689752df4e3750ac08f2a71f
+csharp_sha: 1f8a8f87b59ba5c437460d078d1c204e8c737a08
+content_python_sha: 083c392f8d9070ae5b22b7bfcbb6b57c5a6a5f8365929cf45134c5a93f2ca3eb
+content_csharp_sha: 3b7b078b821273da3bf63823b00e629fb883c88da5152d1aa52fe4e6c064f564
diff --git a/scripts/notebook_tools/twin_pairs.d/tweety-4-belief-revision.yaml b/scripts/notebook_tools/twin_pairs.d/tweety-4-belief-revision.yaml
index 4e685a8d1f..14d2fefb94 100644
--- a/scripts/notebook_tools/twin_pairs.d/tweety-4-belief-revision.yaml
+++ b/scripts/notebook_tools/twin_pairs.d/tweety-4-belief-revision.yaml
@@ -6,6 +6,7 @@
   bridge_verdict: SOTA-OK
   bridge_verdict_reason: "Lib-vs-lib meme moteur Java TweetyProject (revision des croyances AGM, contraction/revision) : C# branche IKVM 8.15.0 + tweety-beliefdynamics.dll (tracked) + 8 refs `org.tweetyproject.*` actifs (3 cellules avec using explicite + classes Java `SimpleKbReiter`, `DefaultRevisionOperator` invoquees). Python branche JPype + `from java.util import ArrayList, HashSet` + `from org.tweetyproject.beliefdynamics.* import` + meme bibliotheque Java TweetyProject. Verifie firsthand (c.227, 2026-08-12, po-2023:CoursIA-2) : les deux cotes operent sur la meme base de connaissances Java (BeliefSet) avec les memes operateurs de revision, pont IKVM-bytecode vs JPype-JVM-runtime."
   known_differences:
+    - "2026-10-08 : redressement densite #17040 (tranche residu ML/SMT/Tweety, PR #19902, lane myia-po-2026:CoursIA) — la cellule '#### Interpretation des résultats de revision' est fusionnée dans la cellule '#### Lecture AGM du code : noyaux, fonction d'incision et enracinement' qui la précède. Markdown-only : cellules de code byte-identiques (13/13), aucun output ni engine touché, aucune ré-exécution due ; parité sémantique inchangée. Rebaseline attestation 0012."
     - "2026-09-16 (myia-po-2023:CoursIA) #15795 : REBASELINE apres merge main. L'attestation 0008 du 09-12 (python_sha 9e629ca1) est retiree : index en collision avec 0008-po-2024 de main (regle #14911/#15345, le postérieur garde l'index) ET blob perimé (python avance via #15702 fix subprocess et #16002 renum portés par main). Nouvelle attestation 0009 sur les blobs courants (python_sha 5073b3dc). content_csharp_sha inchangé : le jumeau C# n'est pas touché."
     - "Socle commun : revision des croyances (AGM, contraction/revision) via TweetyProject."
     - "Lib-vs-lib : C# via IKVM (`using org.tweetyproject.*`). Python via JPype (`from java.util import ArrayList, HashSet` + `from jpype.types import *`). Meme fondement Java, idiomatique de pont differente."
diff --git a/scripts/notebook_tools/twin_pairs.d/tweety-4-belief-revision/0012-2026-10-08-myia-po-2026-CoursIA.yaml b/scripts/notebook_tools/twin_pairs.d/tweety-4-belief-revision/0012-2026-10-08-myia-po-2026-CoursIA.yaml
new file mode 100644
index 0000000000..47caf1f720
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/tweety-4-belief-revision/0012-2026-10-08-myia-po-2026-CoursIA.yaml
@@ -0,0 +1,6 @@
+date: '2026-10-08'
+by: myia-po-2026:CoursIA
+python_sha: bbc4ad92dcad4b753ea51a843fe454511f56a810
+csharp_sha: 49687bcef04bbeea2d6736ecc5cfc43f91afa335
+content_python_sha: 5cb491793c83730b5bc79cbdeff918c0bc2d094923c053f92c80c7d8a2b3236b
+content_csharp_sha: 77f5579ed24fc54aae0fc156c1b6b0a123deeba399d56d0eac40dc9ddd9d266b