diff --git a/MyIA.AI.Notebooks/Sudoku/Sudoku-10-ORTools-Python.ipynb b/MyIA.AI.Notebooks/Sudoku/Sudoku-10-ORTools-Python.ipynb
index ff73ba3ac8..f24d8ae4c5 100644
--- a/MyIA.AI.Notebooks/Sudoku/Sudoku-10-ORTools-Python.ipynb
+++ b/MyIA.AI.Notebooks/Sudoku/Sudoku-10-ORTools-Python.ipynb
@@ -709,7 +709,7 @@
    "source": [
     "### Interpretation : Résultat OR-Tools CP-SAT\n",
     "\n",
-    "Le solveur OR-Tools a resolu un puzzle difficile en quelques dizaines de millisecondes (temps exact affiche par la cellule de resolution ci-dessus ; CP-SAT etant non-deterministe, la valeur varie d'une execution a l'autre et selon la machine).\n",
+    "Le solveur OR-Tools a resolu un puzzle difficile en quelques dizaines de millisecondes (temps exact affiche par la cellule de resolution ci-dessus ; CP-SAT etant non-déterministe, la valeur varie d'une exécution a l'autre et selon la machine).\n",
     "\n",
     "| Aspect | Valeur | Signification |\n",
     "|--------|--------|---------------|\n",
@@ -717,7 +717,7 @@
     "| **Statut** | FEASIBLE | Solution trouvee |\n",
     "| **Approche** | Declarative | Modèle de contraintes, pas d'algorithme a ecrire |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. **Simplicite du code** : Seuls 30 lignes pour définir le modèle complet\n",
     "2. **Contrainte AllDifferent** : OR-Tools l'implemente de maniere très efficace\n",
     "3. **Pas de parametrage** : L'heuristique par defaut fonctionne très bien\n",
@@ -1339,13 +1339,13 @@
    "source": [
     "### Exemple miroir : Minimiser un cout pondere avec CP-SAT\n",
     "\n",
-    "Miroir de l'exemple precedent (`solve_max_reward_latin_square`) : meme espace de carres latins realisables, meme variables booleennes `x[i,j,v]`, mais on **minimise** un cout dependant de `(i, j, v)` au lieu de maximiser un reward. Cela demontre `model.Minimize(...)` -- le pendant exact de `model.Maximize(...)`.\n",
+    "Miroir de l'exemple précédent (`solve_max_reward_latin_square`) : même espace de carres latins realisables, même variables booleennes `x[i,j,v]`, mais on **minimise** un cout dependant de `(i, j, v)` au lieu de maximiser un reward. Cela demontre `model.Minimize(...)` -- le pendant exact de `model.Maximize(...)`.\n",
     "\n",
     "> **Piege de degenerescence (Prong-B, EPIC #3801).** Une version anterieure de cet exemple minimisait la *somme des valeurs sur la diagonale*. C'etait un objectif **degenere** : chaque cellule diagonale `val[i][i]` appartient a `1..n`, donc le minorant trivial est `n` (somme de `n` fois la valeur `1`), atteignable en plaçant `1` sur chaque case diagonale -- ce qu'**aucune contrainte du carre latin n'interdit**. Le solveur renvoyait bien `OPTIMAL`, mais ce statut ne prouvait **rien** : l'optimum etait le minorant evident, trouvable de tete sans aucune recherche. La capacite d'optimisation distinctive de CP-SAT (branch-and-bound, relaxation lineaire) y etait **invisible** -- exactement le symptome d'un cas trop trivial pour mettre le moteur en valeur.\n",
     "\n",
-    "Avec un cout **pondere aleatoire** `cost[i][j][v]`, l'optimum n'est plus devinable : la solution bon-marche cellule par cellule (prendre la valeur de cout minimal dans chaque case) viole les contraintes de carre latin. CP-SAT doit alors **chercher** parmi tous les carres latins realisables celui de cout total minimal. On rend cette recherche **visible** dans la sortie en comparant l'optimum au *minorant naif* (somme des couts minima par cellule, en ignorant les contraintes) : l'ecart `OPTIMAL - minorant_naif > 0` prouve que les contraintes mordent et que l'optimisation est non-triviale.\n",
+    "Avec un cout **pondere aléatoire** `cost[i][j][v]`, l'optimum n'est plus devinable : la solution bon-marche cellule par cellule (prendre la valeur de cout minimal dans chaque case) viole les contraintes de carre latin. CP-SAT doit alors **chercher** parmi tous les carres latins realisables celui de cout total minimal. On rend cette recherche **visible** dans la sortie en comparant l'optimum au *minorant naif* (somme des couts minima par cellule, en ignorant les contraintes) : l'ecart `OPTIMAL - minorant_naif > 0` prouve que les contraintes mordent et que l'optimisation est non-triviale.\n",
     "\n",
-    "**Question** : pourquoi le meme piege (optimum = borne triviale) guetterait-il aussi un objectif « maximiser la somme des valeurs sur la diagonale » ? *(Indice : le majorant trivial serait `n^2`, atteint en plaçant `n` sur chaque case diagonale -- la encore completable en carre latin.)*\n"
+    "**Question** : pourquoi le même piege (optimum = borne triviale) guetterait-il aussi un objectif « maximiser la somme des valeurs sur la diagonale » ? *(Indice : le majorant trivial serait `n^2`, atteint en plaçant `n` sur chaque case diagonale -- la encore completable en carre latin.)*\n"
    ]
   },
   {
@@ -1488,7 +1488,7 @@
     "| **Puzzles difficiles** | (benchmark ci-dessus) | Pas de degradation significative |\n",
     "| **Taux de succes** | 100% | Solveur complet |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. **Performance consistante** : Les puzzles difficiles ne prennent pas beaucoup plus de temps que les faciles\n",
     "2. **Solveur complet** : Tous les puzzles sont resolus\n",
     "3. **Simplicité** : Le code est concis et lisible\n",
@@ -1522,7 +1522,7 @@
     "- Bin packing et cutting stock\n",
     "- Emploi du temps et allocation de ressources\n",
     "\n",
-    "Le Sudoku est un excellent problème pedagogique car il est facile a comprendre mais assez complexe pour illustrer les concepts cles de la programmation par contraintes.\n",
+    "Le Sudoku est un excellent problème pedagogique car il est facile a comprendre mais assez complexe pour illustrer les concepts clés de la programmation par contraintes.\n",
     "\n",
     "***\n",
     "\n",
diff --git a/MyIA.AI.Notebooks/Sudoku/Sudoku-11-Choco-Python.ipynb b/MyIA.AI.Notebooks/Sudoku/Sudoku-11-Choco-Python.ipynb
index d44f489c40..f81df1173a 100644
--- a/MyIA.AI.Notebooks/Sudoku/Sudoku-11-Choco-Python.ipynb
+++ b/MyIA.AI.Notebooks/Sudoku/Sudoku-11-Choco-Python.ipynb
@@ -159,7 +159,7 @@
     "| **Version JPype** | 1.5.0 (dernière) | Compatible avec Java 8-17 et Python 3.7-3.11 |\n",
     "| **Sortie silencieuse** | Pas de details | Le flag `-q` supprime les messages de progression |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. JPype permet d'instancier des classes Java et d'appeler leurs méthodes depuis Python\n",
     "2. L'installation automatique évite a l'utilisateur de lancer `pip install` manuellement\n",
     "3. La fonction `check_call` leve une exception si l'installation echoue (gestion d'erreur)\n",
@@ -308,7 +308,7 @@
     "| **Statut JVM** | Demarree | La machine virtuelle Java est prete a executer Choco |\n",
     "| **Mode JPype** | Import active | L'API Java est accessible depuis Python |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. Le JAR avec dépendances évite de télécharger séparément toutes les bibliotheques Choco\n",
     "2. La vérification `choco_path.exists()` évite de télécharger le fichier a chaque exécution\n",
     "3. La méthode `jpype.startJVM(classpath=[...])` initialise la JVM avec le classpath Choco\n",
@@ -411,7 +411,7 @@
     "| **IntVar** | org.chocosolver.solver.variables.IntVar | Variable entière avec domaine [min, max] |\n",
     "| **allDifferent** | Méthode de Model | Contrainte globale : toutes les variables doivent etre différentes |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. L'importation reussie prouve que la JVM est demarree et que le JAR Choco est charge\n",
     "2. L'API Java de Choco est accessible directement depuis Python via JPype\n",
     "3. La notation `org.chocosolver.solver.Model` suit les conventions Java (packages)\n",
@@ -512,7 +512,7 @@
     "| **Sudoku_hardest.txt** | 11 puzzles très difficiles | Collection d'Arto Inkala (Sudokus les plus durs) |\n",
     "| **Sudoku_top95.txt** | 95 puzzles difficiles | Collection de référence pour benchmarking |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. L'utilisation d'un chemin absolu (`Path` avec `r\"...\"`) évite les problèmes de repertoire courant\n",
     "2. La méthode `glob('*.txt')` liste tous les fichiers .txt de maniere robuste\n",
     "3. Les fichiers sont organises par niveau de difficulte pour les tests progressifs\n",
@@ -667,7 +667,7 @@
     "- **Colonnes 1-3** : Premier bloc vertical (colonnes 1,2,3 du Sudoku)\n",
     "- **Separateurs** : Lignes `---` et colonnes `|` tous les 3 caractères\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. Le format texte 81-caractères est standard pour les puzzles Sudoku (competitions, echanges)\n",
     "2. La fonction `puzzle_to_grid` convertit ce format lineaire en grille 9x9 pour le traitement\n",
     "3. La fonction `print_grid` ajoute des séparateurs visuels pour faciliter la lecture\n",
@@ -877,7 +877,7 @@
     "- **Blocs 3x3** : Chaque bloc contient exactement les chiffres 1-9 sans répétition\n",
     "- **Cohérence** : Les 45 valeurs initiales sont preservees dans la solution\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. La classe `ChocoSudokuSolver` encapsule toute la logique de modélisation CSP\n",
     "2. L'API Choco 4.10+ est intuitive : `Model` -> `intVar` -> `allDifferent` -> `solve()`\n",
     "3. Le temps de résolution quasi-instantané montre que Choco est parfaitement adéquat pour Sudoku\n",
@@ -1130,7 +1130,7 @@
     "| **Taux de succes** | 3/3 (100%) | Choco resout tous les puzzles faciles testes |\n",
     "| **Temps moyen** | quelques ms (cf. benchmark ci-dessus) | Performance excellente pour des puzzles faciles |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. Les temps de résolution restent très faibles, ce qui est quasi-instantané pour l'utilisateur\n",
     "2. La variation entre les puzzles (cf. mesures de la cellule ci-dessus) montre que même les puzzles \"faciles\" ont des structures différentes\n",
     "3. La contrainte `allDifferent` globale de Choco est très efficace pour reduire l'espace de recherche\n",
@@ -1237,7 +1237,7 @@
     "| **Taux de succes** | 2/2 (100%) | Choco resout tous les puzzles difficiles testes |\n",
     "| **Temps moyen** | fraction de seconde (cf. ci-dessus) | Performance acceptable pour un usage général |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. La variation importante entre les puzzles (cf. mesures de la cellule ci-dessus) montre que la difficulte d'un Sudoku dépend grandement de sa structure\n",
     "2. Les temps de résolution restent sous la seconde, ce qui est excellent pour un solveur CP générique\n",
     "3. Choco avec la stratégie par defaut (InputOrder) est déjà efficace sur les puzzles difficiles\n",
@@ -1478,10 +1478,10 @@
     "\n",
     "| Puzzle | Choco (DomWDEG) | OR-Tools | python-constraint |\n",
     "|--------|-----------------|----------|-------------------|\n",
-    "| Facile | (mesure, voir cellule precedente) | (mesure, voir cellule precedente) | (mesure, voir cellule precedente) |\n",
-    "| Moyen | (mesure, voir cellule precedente) | (mesure, voir cellule precedente) | (mesure, voir cellule precedente) |\n",
-    "| Difficile | (mesure, voir cellule precedente) | (mesure, voir cellule precedente) | Timeout (valeur de configuration) |\n",
-    "| Hardest | (mesure, voir cellule precedente) | (mesure, voir cellule precedente) | Echec |\n",
+    "| Facile | (mesure, voir cellule précédente) | (mesure, voir cellule précédente) | (mesure, voir cellule précédente) |\n",
+    "| Moyen | (mesure, voir cellule précédente) | (mesure, voir cellule précédente) | (mesure, voir cellule précédente) |\n",
+    "| Difficile | (mesure, voir cellule précédente) | (mesure, voir cellule précédente) | Timeout (valeur de configuration) |\n",
+    "| Hardest | (mesure, voir cellule précédente) | (mesure, voir cellule précédente) | Echec |\n",
     "\n",
     "\n",
     "> **Note (mandat #9377/#9434)** : les **durées wall-clock** de cette table comparative sont **machine-dépendantes** par construction (JVM Java startup + JPype bridge Python↔Java + overhead Graphe Choco, charge CPU du runner) et **drainées**. Le **rapport d'ordres de grandeur** (Choco ≈ 5× OR-Tools ≪ python-constraint sur ce puzzle, Timeout pour python-constraint sur les plus difficiles) est **reproductible d'une exécution à l'autre** et **conservé**. Les **mesures exactes** restent **visibles** dans les cellules de mesure amont (cellule de banc d'essai du notebook Sudoku-11-Choco-Python ou notebooks Sudoku-10-OR-Tools-Python / Sudoku-09-python-constraint pour les mesures comparatives). La synthèse pédagogique **tient sur la discrimination qualitative** (production vs pédagogie vs apprentissage), pas sur les valeurs quantitatives ponctuelles.\n"
@@ -1590,7 +1590,7 @@
     "| **Grilles 3x3** | Separees par lignes épaisses | Structure du Sudoku respectee |\n",
     "| **Positionnement** | Coordonnees (c+0.5, 8.5-r) | Inversion de l'axe Y pour affichage correct |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. La distinction visuelle permet de vérifier rapidement que le solveur n'a pas modifie les valeurs initiales\n",
     "2. L'inversion de l'axe Y (`8.5-r`) est nécessaire car matplotlib origin est en bas alors que les matrices ont l'origine en haut\n",
     "3. Les lignes épaisses (`lw=2`) marquent les blocs 3x3, facilitant la vérification visuelle\n",
@@ -1789,7 +1789,7 @@
     "3. **Exploite** différentes stratégies de recherche (DomOverWDeg > InputOrder)\n",
     "4. **Compare** Choco avec d'autres solveurs (OR-Tools, python-constraint)\n",
     "\n",
-    "### Points Cles\n",
+    "### Points Clés\n",
     "\n",
     "- **Choco est ideal pour l'enseignement** et la recherche en CP\n",
     "- **DomOverWDeg** est la stratégie recommandée pour Sudoku\n",
diff --git a/MyIA.AI.Notebooks/Sudoku/Sudoku-12-Z3-CSharp.ipynb b/MyIA.AI.Notebooks/Sudoku/Sudoku-12-Z3-CSharp.ipynb
index 47681df111..31455de70e 100644
--- a/MyIA.AI.Notebooks/Sudoku/Sudoku-12-Z3-CSharp.ipynb
+++ b/MyIA.AI.Notebooks/Sudoku/Sudoku-12-Z3-CSharp.ipynb
@@ -1781,7 +1781,7 @@
     "| Z3 Bit Vector Substitution | Substitution | Réutilise les contraintes génériques | Plus complexe à mettre en oeuvre |\n",
     "| Z3 Bit Vector Tactic | Tactiques | Simplification automatique | Overhead potentiel |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "\n",
     "1. **Vecteurs de bits** : representer chaque case sur 4 bits (valeurs 1-9) suffit et donne des variables plus compactes que les entiers ; c'est aussi l'encodage le plus stable sur les grilles difficiles dans le banc d'essai ci-dessus.\n",
     "\n",
diff --git a/MyIA.AI.Notebooks/Sudoku/Sudoku-12-Z3-Python.ipynb b/MyIA.AI.Notebooks/Sudoku/Sudoku-12-Z3-Python.ipynb
index 1cc184afcf..7e23b0c6da 100644
--- a/MyIA.AI.Notebooks/Sudoku/Sudoku-12-Z3-Python.ipynb
+++ b/MyIA.AI.Notebooks/Sudoku/Sudoku-12-Z3-Python.ipynb
@@ -100,7 +100,7 @@
    "source": [
     "## 1. Solveur Z3 SMT\n",
     "\n",
-    "**Z3** est un solveur **SMT** (*Satisfiability Modulo Theories*) developpe a l'origine par **Microsoft Research** (Leonardo de Moura et Nikolaj Bjorner), desormais publie en **open-source sous licence MIT** dans le depot [`Z3Prover/z3`](https://github.com/Z3Prover/z3). Il combine la puissance des solveurs SAT avec des theories mathematiques (arithmetique, tableaux, bitvectors, etc.)."
+    "**Z3** est un solveur **SMT** (*Satisfiability Modulo Theories*) developpe a l'origine par **Microsoft Research** (Leonardo de Moura et Nikolaj Bjorner), desormais publie en **open-source sous licence MIT** dans le depot [`Z3Prover/z3`](https://github.com/Z3Prover/z3). Il combine la puissance des solveurs SAT avec des théories mathematiques (arithmetique, tableaux, bitvectors, etc.)."
    ]
   },
   {
@@ -518,14 +518,14 @@
     "| **Statut** | sat | Solution trouvee |\n",
     "| **Type de variables** | Int | Entiers symboliques |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. **API simple** : La contrainte `Distinct` est très expressive\n",
     "2. **Théorie des entiers** : Z3 utilise QF_LIA (Linear Integer Arithmetic)\n",
     "3. **Flexibilite** : Z3 peut facilement etendre le modèle avec d'autres contraintes\n",
     "\n",
     "> **Note technique** : La contrainte `Distinct` de Z3 est plus puissante que l'inegalite binaire car elle permet au solveur d'utiliser des algorithmes specialised pour la propagation.\n",
     ">\n",
-    "> **Regle #9434** : le temps de resolution (machine-dependant) est mesure dynamiquement par la cellule de code ci-dessus ; il n'est pas fige ici."
+    "> **Règle #9434** : le temps de resolution (machine-dependant) est mesure dynamiquement par la cellule de code ci-dessus ; il n'est pas fige ici."
    ]
   },
   {
@@ -797,14 +797,14 @@
     "| Puzzle 4 | ~3x plus rapide |\n",
     "| Puzzle 5 | ~2x plus rapide |\n",
     "\n",
-    "**Points cles** :\n",
+    "**Points clés** :\n",
     "1. **BitVectors sont plus proches du hardware** : Z3 peut utiliser des opérations bit-level\n",
     "2. **Domaine restreint** : 4 bits = 16 valeurs, exactement ce qu'il faut pour 1-9\n",
     "3. **Propagation plus efficace** : Les contraintes bit-level sont plus simples a propager\n",
     "\n",
     "> **Note technique** : Les BitVectors sont representes en precision fixe (4 bits ici), ce qui permet a Z3 d'utiliser des algorithmes de propagation plus efficaces. Les entiers symboliques en Z3 ont une precision arbitraire, ce qui ajoute de la complexite.\n",
     ">\n",
-    "> **Regle #9434** : les temps absolus (machine-dependants) sont mesures dynamiquement par la cellule de benchmark ci-dessus ; seuls les ordres de grandeur du speedup (structurels, stables cross-machine) sont conserves ici."
+    "> **Règle #9434** : les temps absolus (machine-dependants) sont mesures dynamiquement par la cellule de benchmark ci-dessus ; seuls les ordres de grandeur du speedup (structurels, stables cross-machine) sont conserves ici."
    ]
   },
   {
@@ -1324,7 +1324,7 @@
     "`Optimize()` resout des problemes ou l'on **maximise** (ou **minimise**) un\n",
     "objectif sous contraintes -- c'est le moteur de la programmation **MaxSMT**\n",
     "(maximisation sat-modulo-theories, utilise en verification, scheduling,\n",
-    "allocation de ressources, debug de modeles).\n",
+    "allocation de ressources, debug de modèles).\n",
     "\n",
     "**Demonstration** : un « carre latin a bonus » -- chaque cellule (i, j) offre un\n",
     "*reward* dependant de la valeur placee. Parmi tous les carres latins 5x5\n",
@@ -1332,8 +1332,8 @@
     "total**. Le statut `sat` certifie que l'optimum est atteint (preuve\n",
     "non-vacuous).\n",
     "\n",
-    "> Miroir de la demo CP-SAT du notebook `Sudoku-10-ORTools-Python` (meme\n",
-    "> probleme, meme reward 178), mais avec l'API SMT `z3.Optimize()` au lieu de\n",
+    "> Miroir de la demo CP-SAT du notebook `Sudoku-10-ORTools-Python` (même\n",
+    "> problème, même reward 178), mais avec l'API SMT `z3.Optimize()` au lieu de\n",
     "> `cp_model.CpModel.Maximize()`.\n"
    ]
   },
@@ -1483,7 +1483,7 @@
     "lieu de maximiser le reward.\n",
     "\n",
     "**Indices** :\n",
-    "1. Gardez les memes contraintes (carre latin : `PbEq` one-value-per-cell,\n",
+    "1. Gardez les mêmes contraintes (carre latin : `PbEq` one-value-per-cell,\n",
     "   latin rows/cols).\n",
     "2. Remplacez `opt.maximize(reward_total)` par :\n",
     "   ```python\n",
diff --git a/scripts/notebook_tools/twin_pairs.d/sudoku-10-ortools.yaml b/scripts/notebook_tools/twin_pairs.d/sudoku-10-ortools.yaml
index ea2fa524b7..d867a133d1 100644
--- a/scripts/notebook_tools/twin_pairs.d/sudoku-10-ortools.yaml
+++ b/scripts/notebook_tools/twin_pairs.d/sudoku-10-ortools.yaml
@@ -6,6 +6,7 @@
   bridge_verdict: SOTA-OK
   bridge_verdict_reason: "Lib-vs-lib meme moteur Google OR-Tools (3 sous-modules : ConstraintSolver routing, LinearSolver LP, Sat CP-SAT) : Python = `ortools` PyPI package (`from ortools.sat.python import cp_model`, `from ortools.linear_solver import pywraplp`, `from ortools.constraint_solver import pywrapcp`). C# = `Google.OrTools.{Sat,LinearSolver,ConstraintSolver}` NuGet packages (bindings SWIG officiels). Meme solveur C++ natif upstreams de Google Operations Research, accessible via les bindings Python (.whl) et C# (.nupkg). Verifie firsthand (c.235 audit 2026-08-12, myia-po-2023:CoursIA-2) : Python 30 cells / C# 35 cells, structure pedagogique symetrique (memes configurations de puzzles, memes benchmarks CP-SAT, memes options solver). Pont cross-stack impossible : bindings SWIG non bridgeables (meme pattern que Sudoku-18 precedent c.234). Parite semantique mecaniquement preservee tant que les versions PyPI/NuGet restent synchronisees. Verdict SOTA-OK : OR-Tools est la SOTA OR solver pour les deux stacks."
   known_differences:
+    - "Re-baseline 2026-10-14 (hors-flotte:claude-session-16638, #16638) : restauration des accents de la prose markdown (tranche Sudoku #16638, outil canonique restore_accents_canonical.py, invariance strip_accents a 0 finding), cote Python seul ; cote C# byte-identique a main. Aucune cellule de code, sortie ni execution_count touchee. Parite inchangee : attestation (le blob SHA se deplace), pas reparation. --update en DERNIERE operation (cf #8957)."
     - "Socle pedagogique commun : resolution du Sudoku par programmation par contraintes avec OR-Tools CP-SAT (Google.OrTools), meme solveur sous-jacent, meme modelisation (variables IntVar par case, contraintes AllDifferent sur lignes/colonnes/blocs, objectif de satisfaction)."
     - "Idiomes framework symetriques : Python = `from ortools.sat.python import cp_model` (binding Python natif), C# = NuGet `#r \"nuget: Google.OrTools\"` + `using IntVar / SimpleCPSolver / SimpleConstraint` (binding .NET). Les deux cotes deleguent au meme moteur CP-SAT de Google, seules les API de binding different."
     - "Parite structurelle proche : Python 13 cellules code / 17 markdown ; C# 14 cellules code / 21 markdown. Arc pedagogique identique (formulation CP-SAT -> exemple resolu -> benchmark de passage a l'echelle)."
diff --git a/scripts/notebook_tools/twin_pairs.d/sudoku-10-ortools/0013-2026-10-14-hors-flotte-claude-session-16638.yaml b/scripts/notebook_tools/twin_pairs.d/sudoku-10-ortools/0013-2026-10-14-hors-flotte-claude-session-16638.yaml
new file mode 100644
index 0000000000..46904fa490
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/sudoku-10-ortools/0013-2026-10-14-hors-flotte-claude-session-16638.yaml
@@ -0,0 +1,6 @@
+date: '2026-10-14'
+by: hors-flotte:claude-session-16638
+python_sha: f24d8ae4c5cfc9c2d266d1b455a8401d4f883621
+csharp_sha: eea8ed76aed7f21bcc876bde2600a9d35059bed2
+content_python_sha: c2e5bbb1b5e24624db4ff5a12fb509233ee0d8ad24768b74b4d76770f40a6d32
+content_csharp_sha: 533f4a38b1621df6070d8e5bb07e738a14a67b3292adb5603c569db6f294cd1f
diff --git a/scripts/notebook_tools/twin_pairs.d/sudoku-11-choco.yaml b/scripts/notebook_tools/twin_pairs.d/sudoku-11-choco.yaml
index 43c2a936d2..a491309a87 100644
--- a/scripts/notebook_tools/twin_pairs.d/sudoku-11-choco.yaml
+++ b/scripts/notebook_tools/twin_pairs.d/sudoku-11-choco.yaml
@@ -6,6 +6,7 @@
   bridge_verdict: SOTA-OK
   bridge_verdict_reason: "Lib-vs-lib meme moteur Java Choco-Solver : C# branche IKVM-Choco via DLL `org.chocosolver.solver.dll` trackee sur disque (Choco 4.10.17, IKVM 8.15.0) + 5 `using org.choco.*` explicites + 18 refs `IKVM` runtime + cells 12. Python branche JPype + 11 refs `choco` + 19 refs `jpype` + `from org.chocosolver.solver import Model` runtime. Meme moteur Java Choco-Solver 4.10.17 des deux cotes, accessible via deux chemins distincts (JPype-JVM-runtime cote Python, IKVM-bytecode .NET cote C#). Verifie firsthand (c.234 audit 2026-08-12, myia-po-2023:CoursIA-2) : DLL trackee, csproj IKVM-Choco deja construit (c.218 PR #10561 \"tranche 5 CSP\" a couvert 5 paires dont Choco-bridgeable), kernel .NET Interactive execute le twin C#. Pont IKVM-bytecode .NET vs JPype-JVM-runtime sur le meme moteur Java. Verdict SOTA-OK : Choco-Solver est la SOTA CSP solver pour les deux stacks, aucun autre solveur ne le remplacerait avantageusement. Build IKVM deja fait sur le runner (DLL trackee = artefact build, pas a reconstruire)."
   known_differences:
+    - "Re-baseline 2026-10-14 (hors-flotte:claude-session-16638, #16638) : restauration des accents de la prose markdown (tranche Sudoku #16638, outil canonique restore_accents_canonical.py, invariance strip_accents a 0 finding), cote Python seul ; cote C# byte-identique a main. Aucune cellule de code, sortie ni execution_count touchee. Parite inchangee : attestation (le blob SHA se deplace), pas reparation. --update en DERNIERE operation (cf #8957)."
     - "2026-09-27 (drift unilateral, session cloud d'agnosticisme hors flotte) : cote C# seul. La cellule de configuration IKVM codait le RID win-x64 en dur (ikvmRid = win-x64, plus une reference NuGet IKVM.Image.runtime.win-x64) : sous Linux et macOS, l'init de la JVM IKVM echouait au premier appel Java (TypeInitializationException sur IKVM.Runtime.LibJava, mesure sur CSP-1 avant correctif). Le RID est desormais derive de OperatingSystem et RuntimeInformation.ProcessArchitecture ; IKVM.Image 8.15.0 depend deja des onze paquets IKVM.Image.runtime.<rid>, la reference explicite win-x64 est retiree. Re-execution complete sous Linux (dotnet-interactive 1.0.617701) : 0 erreur, sorties identiques a la base hors RID du home IKVM, separateur decimal (culture) et temps mesures. Jumeau Python inchange. Strips outilles appliques avant l'attestation (probe banner, papermill). Prose : les durees epinglees (473 ms, 56 ms) remplacees par des descripteurs machine-dependants (#9434)."
     - "Edition 2026-08-08 (myia-po-2023:CoursIA-2, #9434 item 3) : les DEUX twins ont evacue leurs valeurs de timing absolues machine-dependantes de la prose d'interpretation (Python cell[18/23/26] : 64.01/8.38/50.43 ms etc. ; C# cell[28] : 728 ms startup JVM IKVM) au profit de descripteurs qualitatifs pointant vers la cellule de mesure live ci-dessus. Markdown-only, pas de re-exec (exception C.2). Parite semantique tenue : socle CP, modelisation, contraintes, asymetrie IKVM/from-scratch inchanges."
     - "Socle pedagogique commun : resolution de Sudoku par programmation par contraintes (CP) avec le solveur Choco -- modelisation (variables, domaines, contraintes), propagation, recherche. Meme solveur (Choco), meme cas d'application (Sudoku). Les deux couvrent Choco, choco, Solver."
diff --git a/scripts/notebook_tools/twin_pairs.d/sudoku-11-choco/0013-2026-10-14-hors-flotte-claude-session-16638.yaml b/scripts/notebook_tools/twin_pairs.d/sudoku-11-choco/0013-2026-10-14-hors-flotte-claude-session-16638.yaml
new file mode 100644
index 0000000000..6269c200dd
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/sudoku-11-choco/0013-2026-10-14-hors-flotte-claude-session-16638.yaml
@@ -0,0 +1,6 @@
+date: '2026-10-14'
+by: hors-flotte:claude-session-16638
+python_sha: f81df1173a98ce70a09a76473552fdebb7d78a94
+csharp_sha: 1c0205e99d5b50737bcbae0a0f43241cdccdbf1c
+content_python_sha: d5c91493edadc1baff713a0400e08c58515cccb8fe08f8c6193059f7190d01a8
+content_csharp_sha: ea0bf0cb9f355917a8a77849dc4b15e2ff8ca34d040be670756bbcf98211b0af
diff --git a/scripts/notebook_tools/twin_pairs.d/sudoku-12-z3.yaml b/scripts/notebook_tools/twin_pairs.d/sudoku-12-z3.yaml
index e9a60a3456..53d7d51d3b 100644
--- a/scripts/notebook_tools/twin_pairs.d/sudoku-12-z3.yaml
+++ b/scripts/notebook_tools/twin_pairs.d/sudoku-12-z3.yaml
@@ -6,6 +6,7 @@
   bridge_verdict: SOTA-OK
   bridge_verdict_reason: "Lib-vs-lib meme moteur Z3 SMT (Microsoft Research, open-source) : Python = `z3-solver` PyPI (`from z3 import Solver, Int, And, Or, Not, sat`, 30 cells code). C# = `Microsoft.Z3` NuGet package (bindings .NET natifs Microsoft officiels, 44 cells code dont 19 cells code + stdlib System.*). Meme solveur Z3 upstreams de Microsoft Research, accessible via les bindings Python (.whl, generes par Z3 Python API) et C# (.nupkg, Microsoft.Z3.NET API). Verifie firsthand (c.235 audit 2026-08-12, myia-po-2023:CoursIA-2) : memes formules SMT (Int sort, And/Or/Not, Distinct, sat check), memes benchmarks (sudoku encode comme 81 Int + 9x9x9 Distinct). Pont cross-stack impossible : Z3 est un solveur C++ natif, les deux bindings sont des API distinctes (Python dynamic vs C# static managed). Parite semantique preservee par la garantie que les deux versions utilisent le meme solver Z3 upstream (memes versions = memes resultats SMT). Verdict SOTA-OK : Z3 est la SOTA SMT solver pour les deux stacks, aucun autre solveur ne le remplacerait avantageusement pour la demonstration SMT."
   known_differences:
+    - "Re-baseline 2026-10-15 (hors-flotte:claude-session-16638, #16638) : restauration des accents de la prose markdown (tranche Sudoku #16638, outil canonique restore_accents_canonical.py, invariance strip_accents a 0 finding), sur les deux jumeaux. Aucune cellule de code, sortie ni execution_count touchee. Parite inchangee : attestation (le blob SHA se deplace), pas reparation. --update en DERNIERE operation (cf #8957)."
     - "2026-09-27 (revue Hermes #17239 + reprise redactionnelle, myia-po-2023:CoursIA-2) : le jumeau **Python** seul a ete edite deux fois sur la PR #18070 -- (a) les 4 reparations atomiques de la revue Hermes du 23/09 12:47Z (F1+F3+F4, plus la nuance mesure de F2), puis (b) la cellule `transition-z3-int-to-bitvec` ramenee a la convention de la serie (une ligne, sans en-tete, comme les intros de classe solveur des cellules 8 et 11 ; le fond etait deja dans `### Interpretation : Z3 Int vs BitVector`). Markdown uniquement : aucune cellule de code touchee, aucune sortie, aucun `execution_count` modifie, donc pas de re-execution due (C.2 exception markdown-only). Le jumeau **C#** n'est pas touche -- son blob SHA est identique a celui de l'attestation precedente (`d1369bf4ad04`). Mecanisme de la seconde attestation : `ff43006695` avait atteste la paire, puis `0659d1248f` a re-edite le Python et deplace son blob (`afd8bf0be86a` -> `5283b2e3b384`), ce qui a rendu l'attestation perimee -- l'attestation est celle du notebook TEL QU'IL EST MAINTENANT (#8957)."
     - "2026-09-02 (grain hr-separateurs famille Sudoku, myia-po-2027:CoursIA) : conversion des separateurs markdown --- vers *** via fix_hr_separator.py (incident #11451 : un --- seul ouvre un bloc YAML Pandoc et casse quarto render) -- jumeau Python seul (2 separateurs). Cellules markdown uniquement, aucune source de code ni output modifiee, pas de re-exec (C.2 exception markdown-only). Les blob et content SHAs deplaces dans l audit ci-dessus sont des artefacts de cette conversion markdown (le content_sha hashe le JSON canonique des cellules), pas une divergence pedagogique."
     - "Socle pedagogique commun : resolution de Sudoku par SMT (Satisfiability Modulo Theories) avec le vrai solveur Z3 (Microsoft Research) -- modelisation des contraintes Sudoku comme formules logiques (BitVec, contraintes all-different sur lignes/colonnes/carres), resolution par le solveur SMT. Les deux cotes utilisent le VRAI Z3 SOTA (meme moteur sous-jacent), meme cas d'application (Sudoku). Les deux couvrent Z3, z3, BitVec, Solver."
diff --git a/scripts/notebook_tools/twin_pairs.d/sudoku-12-z3/0017-2026-10-15-hors-flotte-claude-session-16638.yaml b/scripts/notebook_tools/twin_pairs.d/sudoku-12-z3/0017-2026-10-15-hors-flotte-claude-session-16638.yaml
new file mode 100644
index 0000000000..3e0fa36d02
--- /dev/null
+++ b/scripts/notebook_tools/twin_pairs.d/sudoku-12-z3/0017-2026-10-15-hors-flotte-claude-session-16638.yaml
@@ -0,0 +1,6 @@
+date: '2026-10-15'
+by: hors-flotte:claude-session-16638
+python_sha: 7e23b0c6daa44d0cc96470bfb26054c4a2a0c45b
+csharp_sha: 31455de70eaea7108d9794e321805c092059f6e5
+content_python_sha: 70cb49716694eb64b8b92fef748a06505ef86483214a82cd32ae943d6cd36772
+content_csharp_sha: 9768c2ef04804847bb85e961f6549b64c4203404715342819a111bb4260cf1ad