[EPIC] Traduction multilingue du depot via datasetupdater Argumentum (low priority) #1650

État mesuré au 2026-10-11 (lane myia-po-2024:CoursIA, tranche acceptance 4 de #13906)

1. Les six PRs du bloc du 10-05 ci-dessous sont toutes MERGÉES (vérifié firsthand 11/10) : #19118 (2026-10-05), #19128 (2026-10-05), #19107 (2026-10-04), #18928 (2026-10-03), #19083 et #19110 (2026-10-04) — les statuts « attente merge coord / re-tampon adjoint » de cette table sont périmés.

2. Quatre livraisons d'octobre non consignées :

PR	Date	Sujet
#18968	2026-10-04	FineTuning FT-01 + FT-03 EN — 23 cellules md + 2 rendus _en
#19121	2026-10-04	base T1 des familles restantes — Complexity, Compression, NLP (502 cellules)
#19175	2026-10-05	FT-02 QLoRA EN — couverture complète + rendu _en
#20058	2026-10-09	9e paire de traduction (EXPECTED_PAIR_COUNT 8 -> 9) — corrige le rouge de base #19996

La séquence 4 du 2026-09-22 reste le plan à exécuter ; aucune de ces PRs ne ferme #1650.

Portée du non-vérifié : fenêtre de l'organe = 2026-10-04 -> 10-10 ; le contenu cellule-par-cellule des rendus _en n'a pas été relu ici.

État mesuré au 2026-10-05 — consolidation de la posture (#1650)

Ce bloc préfixe sans refermer l'issue. La posture est contredite sur deux points, et cinq PRs livrées par le cluster (Octobre) ne sont pas consignées dans le corps ci-dessous.

Posture contredite -- deux points :

1. Suffixe canonique des notebooks pilotant un noyau Lean : la décision 4.1 du 2026-09-22 annonçait un suffixe -Lean-Python (au moins 36 notebooks Python pilotent Lean, aucun suffixé). L'audit de suffixe livré par Rename(#1650): Serre100 08 suffixe -Lean — audit de suffixe Serre100+Langlands #19128 (relecture par mes soins, 2026-10-04) contredit ce point : un seul notebook (Serre100/08) pilote un noyau lean4-wsl natif, donc suffixe -Lean. Les 16 autres notebooks de l'audit sont Python stdlib pur sans exécution Lean, donc pas de suffixe. Le suffixe -Lean-Python était une hypothèse, pas un constat. La convention canonique désormais est -Lean (kernel natif) | rien (Python pur), voir la cadence des notebooks Lean-16b/c.

2. Organe de parité : la décision 3 indiquait « modèle à réutiliser plutôt que réinventer : la parité jumeaux Python/C# — registre de paires avec empreintes de contenu, attestation, audit de dérive (scripts/notebook_tools/check_twin_parity.py, twin-parity*.yml) ». L'organe est désormais livré par Add(ci,#19116): twin-parity-guard -- parite jumeau FR/<lang> scopee au diff de la PR #19118 (twin-parity opérationnel, 2026-10-04). La décision 3 devient donc « s'appuyer sur l'organe livré » et la phase « harnais de localisation » peut s'inspirer directement du registre twin-parity.

Cinq PRs non consignées dans le corps ci-dessous :

PR	Date	Sujet	Statut
#19118	2026-10-04	feat(shared,#19115): organ twin-parity v1 (registre de paires + attestation + audit de dérive)	MERGEABLE / attente merge coord
#19128	2026-10-04	Rename(#1650): Serre100 08 suffixe -Lean — audit de suffixe Serre100+Langlands	MERGEABLE / attente OVERRIDE coord (trappe #13495, cf. DM msg-20261005T022957-173wcn)
#19107	2026-10-04	feat(lean,#18430): Lean-XX carnet sorry 9 → 8 (provennement splits acquis)	CLEAN / attente merge coord
#18928	2026-10-03	test(lean,#18430): oracle _parse_duree_to_minutes (closed-enum 5min-2h, 2h+ loud-fail)	MERGEABLE
#19083 / #19110	2026-10-04	fix(lean,#18430): cadrilles Lean-XX* racine (provennement splits + navigation)	BLOCKED-WITH-SUBSTANCE / attente re-tampon adjoint

Portée vérifiée : la correction de la posture ne touche ni le mandat user 2026-05-28 (« traduire simplement le contenu du dépôt en anglais et en plusieurs autres langues ») ni la décision d'architecture de distribution (1 dépôt par langue). Elle met à jour la séquence 4.1 (suffixe) et la phase 4 (organe twin-parity livré). L'issue reste OPEN, pas de See #N vers un travail de fermeture : aucun des 5 PRs ci-dessus ne ferme #1650, et la séquence 4 du 2026-09-22 reste le plan à exécuter.

---

Mandat utilisateur (verbatim)

"Traduire tout simplement le contenu du dépôt en anglais et en plusieurs autres langues.
C'est un travail pharaonique mais il se trouve qu'en ce moment même Argumentum utilise un outil développé par mes soins l'an dernier pour traduire toutes les contenus du jeu dans des csv massifs.
Je pense qu'après completion de l'issue qui mandate son intégration dans le dépôt en sous-module, on pourra se servir du même moteur pour faire la traduction en un script global. Création des csv à traduire à partir des cellules de notebook et des paragraphes de markdown, exécution du datasetupdater d'argumentum dans toutes les langues actuellement supportées par argumentum (cf le dashboard pour le travail en cours), puis redispatching dans des notebooks xxx_en.ipynb, xxx_es.ipynb etc. Pareil pour les readme et autres docs."

— jsboige, 2026-05-28, à ai-01:CoursIA (low priority, troisième Epic dans la série Conway #1647 / Grothendieck #1646 / Traduction)

Décisions user du 2026-09-22 — architecture de distribution (remplacent les arbitrages des Phases 2, 3 et 4)

Discussion stratégique ai-01 ↔ user du 2026-09-22. Verbatims :

« le caractère beta des notebooks ne me semble pas être un blocage complet au fait qu'on avance sur le sujet de la localisation »

« Non on doit traduire le code, il sera exécuté dans chacun des dépôts localisés »

« je pense qu'il faut qu'on accepte la possibilité de PRs localisées. On a normalement spécifié un système de comparaison des csv et des cellules de notebook pour détecter les évolutions, il faudra juste prévoir que ce système fasse la comparaison entre dépôts distincts. On doit pouvoir s'inspirer de ce qui est fait pour la parité Python/Csharp. »

« OK pour renommer avant de traduire »

1. Un dépôt de distribution par langue — pas de siblings xxx_<lang>.ipynb, pas de fork, pas de LFS

Mesure du 2026-09-22 : le dépôt pèse ~2,8 Go d'historique sur GitHub (104 forks) ; les 1 371 notebooks de l'arbre courant font 639 Mo (médiane 96 Ko, les 5 plus gros GenAI Audio/Image = 124 Mo). Sept langues cibles en siblings = +4,5 Go d'arbre courant dès la première vague, puis chaque ré-exécution multipliée par 8. GitHub recommande de rester sous 5 Go.

2. Le code est traduit et exécuté dans chaque dépôt localisé

Remplace « le code lui-même n'est jamais traduit » (Phase 2) et « conserve execution_count et outputs du source » (Phase 3). Chaque notebook localisé porte ses propres sorties d'exécution réelle (C.2 s'applique dans chaque dépôt de langue, comme ici). Conséquence de chantier : l'extracteur doit couvrir identifiants, chaînes affichées, commentaires et légendes, avec une garde qui vérifie que le code traduit s'exécute (la parité de comportement se mesure à l'exécution, pas au diff).

3. PRs localisées acceptées — comparaison entre dépôts distincts

Une contribution peut arriver dans un dépôt de langue. L'organe de détection d'évolution (CSV par série de #4957, scripts/translation/check_translation_sync.py et ses 6 verdicts, multilingual_drift_audit.py) doit comparer entre dépôts, et non plus seulement à l'intérieur de CoursIA. Modèle à réutiliser plutôt que réinventer (organ-first) : la parité jumeaux Python/C# — registre de paires avec empreintes de contenu, attestation, audit de dérive (scripts/notebook_tools/check_twin_parity.py, twin-parity*.yml). Une paire devient (notebook FR @ sha, notebook <lang> @ sha, dépôt) ; une évolution d'un côté se propage vers l'autre par PR, dans les deux sens.

4. Séquence

1. Renommer avant de traduire : numérotation, suffixe -Lean-Python (au moins 36 notebooks Python pilotent Lean, aucun suffixé), casse du suffixe C# (96 -Csharp vs 34 -CSharp), consolidation des lakes — la mémoire de traduction est indexée par chemin + cell_id, tout renommage postérieur casse les clés dans chaque langue.
2. READMEs à jour (ils listent des chemins).
3. Harnais de localisation (connecteur datasetupdater, génération, exécution, publication, comparaison inter-dépôts) — pas gaté par le caractère beta des notebooks.
4. Première vague : vitrine + READMEs, déclarée beta ; puis séries une à une. Le label « production » d'un notebook reste porté par la revue éditoriale ([EPIC] Revue editoriale user — gater PRODUCTION sur une signature reelle, un dossier a la fois #11259) — c'est précisément l'aide que l'appel public multilingue sollicitera.

Insight pivot — un moteur unique, trois couches CoursIA

Le datasetupdater d'Argumentum existe déjà et tourne en production sur le jeu Argumentum. CoursIA ne réinvente rien : on connecte. Le travail réel se réduit à modeler le contenu pédagogique en CSV équivalent à un dataset Argumentum, puis à redéposer le résultat traduit dans la forme attendue (notebook ou markdown).

Dépendance bloquante — LEVÉE le 2026-06-09, remplacée par trois gates qui vivaient en commentaires

Ce que cette section disait jusqu'au 2026-09-01 : « #1271 doit être mergé avant Phase 1. État actuel (dashboard 2026-05-26) : GELÉ pending feu vert user post-PrCon. »

C'est faux depuis près de trois mois. #1271 est CLOSED le 2026-06-09, et le sous-module Argumentum est présent sur main à MyIA.AI.Notebooks/SymbolicAI/Argument_Analysis/Argumentum (git ls-tree origin/main, gitlink 1c5231f6, vérifié le 2026-09-01). Le datasetupdater est atteignable. Une lane qui tirait cette EPIC lisait « GELÉ », concluait qu'elle était bloquée sur autrui, et la reposait — c'est le mécanisme de délaissement que #11900 décrit, et il a tourné ici pendant 84 jours.

Les trois gates réels — ils existent, mais ils ne sont pas celui-là

Aucun ne bloque le moteur ; tous les trois bloquent la production de traductions. La distinction est ce qui rend cette EPIC de nouveau piochable.

1. Revue éditoriale, par notebook signé — [EPIC] Revue editoriale user — gater PRODUCTION sur une signature reelle, un dossier a la fois #11259 (OPEN). Mandat user du 2026-08-16, inscrit dans un commentaire de cette issue : « [la revue éditoriale] c'est le vrai gate qui permettra de lancer la traduction 8 langues sans avoir l'impression de créer [du volume non relu] ». La traduction se déclenche par notebook signé, jamais par vague.
2. Consolidation avant traduction — décision user du 2026-08-31/09-01, après parcours navigateur de la série GameTheory : « On lancera la trad après consolidation. » GameTheory est la série nommée en premier.
3. Livraison scriptée en hold — i18n notebooks : T4 renderer + CI autonome — sortir du moteur qui tourne a vide (mandat user 2026-08-08) #10038 / PR fix(i18n,#10038): hold translation-sync — neutraliser le trigger on:push (decision user 2026-08-12) #10767. Le trigger on: push de translation-sync.yml est neutralisé par décision user du 2026-08-12 ; le moteur ne tourne plus que sur workflow_dispatch. Ce n'est pas une panne : c'est le hold qui empêche la production de repartir avant les gates 1 et 2.

Ce qui est donc piochable aujourd'hui, sans lever aucun gate

Le moteur et son outillage sont largement construits, et rien n'interdit de les finir ou de les vérifier :

• scripts/translation/ porte 14 modules sur main — extraction (extract_cells_to_csv.py, 37 tests hermétiques test(translation,#4957): cover extract_cells_to_csv.py T1 — 37 tests, stdlib-only hermetic #9265), contrôle de dérive (check_translation_sync.py, 50 tests couvrant les 6 verdicts test(translation,#4957): cover check_translation_sync.py T2 — 50 tests, all 6 drift verdicts #9266), réinjection (translate_csv.py, 22 tests round-trip test(translation,#6949): round-trip fixture-first tests for T3 fork translate_csv.py (22 tests) #7023), plus parité, périmètre, spans de code inline, audit de dérive multilingue.
• translations/ porte ~20 séries en CSV, resynchronisées à plusieurs reprises (chore(translation,#4957): resync GenAI/Texte CSV drift (24 SRC_DRIFT -> 0) #6951, chore(translation,#4957): resync Search/Applications CSV drift (3 SRC_DRIFT -> 0) #7098, chore(translation,#4957): resync symbolicai-lean CSV drift (1 SRC_DRIFT -> 0) #7235, fix(translation,#4957): resync translations/probas-pymc/probas_pymc.csv (262 SRC_DRIFT → 0) #7695).
• translation_golden_set.json n'existe pas (find du 2026-09-01) — c'est le seul sous-critère de la Phase 0.5 qui n'est pas livré, et il est petit : indexer les paires FR/EN déjà produites par le défrichage manuel. C'est le grain le plus immédiat de cette EPIC, et il pré-remplit l'étalonnage de la Phase 4.

Les phases ci-dessous conservent leur rédaction d'origine ; leur état réel est celui du tableau ajouté en tête de la section « Phases ».

État des phases au 2026-09-01 (ai-01) — le plan ci-dessous n'avait jamais été coché

Le plan d'origine séquençait tout derrière « #1271 puis le moteur ». Le plateau a fait l'inverse : le moteur est construit, c'est la production qui est tenue — délibérément, par des décisions user. Lire les phases dans l'ordre du plan induit en erreur ; lire ce tableau ne le fait pas.

Phases

Phase 0 — Prérequis & inventaire (1-2h, hors blocage)

• Vérifier la complétion de [EPIC] Argument_Analysis upgrade — submodule Argumentum + import 2025-Epita-IS (cours EPITA 20/05) #1271 (sous-module Argumentum) → bloqueur de Phase 1
• Inventaire du périmètre à traduire :
  • Notebooks : find MyIA.AI.Notebooks -name "*.ipynb" -not -name "*_output.ipynb" -not -name "*_<lang>.ipynb" (1 181 notebooks source sur origin/main au 2026-08-30 — l'estimation initiale « ~400 » était fausse d'un facteur ~3 ; le README du 17/08 annonçait déjà 1 024)
  • Markdown : find . -name "*.md" -not -path "./node_modules/*" -not -path "./.git/*" (READMEs + docs)
  • Slides : find MyIA.AI.Notebooks -name "slides.md" -o -name "slides_*.md"
• Langues supportées par Argumentum Data-Gate v0.9.0 (relevé dashboard Argumentum workspace 2026-05-28) :
  • EN, FR, ES, AR, FA, ZH, RU, PT — 8 langues, scope v0.9.0 du jeu
  • 4 datasets actifs comme pattern : Rules, Virtues, Scenarii, Fallacies (couvertures 75-100% selon langue × dataset)
  • Backend LLM : gpt-5.5 (mandate fiabilité narrative côté Argumentum, transposable CoursIA)
  • Bornes coût observées Argumentum : ~$8/PR garde-fou, ~$120 cumul sur une Phase complète (~1500 cellules)
  • Maturité prouvée 2026-05-28 (Phase 3 Scenarii ES/FA/AR 100% en 1 cycle, ratio API ~1.0×/cell post-fix tool description) — moteur prêt pour reuse externe
• Cette liste est la source de vérité : toutes les langues vivantes côté Argumentum sont produites côté CoursIA, ni plus, ni moins. Si Argumentum ajoute DE/IT/JA en v1.0, CoursIA suit en cycle suivant.

Phase 0.5 — Défrichage manuel ad-hoc EN→FR (4-8h, déblocable maintenant, sans Argumentum)

Ajouté 2026-06-12 suite mandat user (« commence par identifier et traduire en français de façon ad-hoc, non scriptée, les nombreux docs markdown profonds encore en anglais, en récupérant au passage les versions anglaises en README.en.md telles que visées par la résolution scriptée »). C'est un prélude au moteur Argumentum, pas le moteur lui-même — pas besoin d'en connaître le détail pour exécuter cette phase.

Rationale (pourquoi avant la Phase 1 scriptée).

1. Préalable à l'exécution du moteur. Le datasetupdater Argumentum part des sources françaises pour générer les autres langues. Or un scan du dépôt (2026-06-12) révèle que ~30 docs markdown profonds sont encore en anglais alors que le dépôt est FR-primaire (CLAUDE.md §E). Si le moteur tourne sur un mélange EN/FR incohérent, il traduira de l'anglais vers les autres langues sur ces fichiers, ou produira un mélange. Il faut donc assainir les sources FR d'abord.
2. Déblocable immédiatement. Cette phase ne dépend pas de [EPIC] Argument_Analysis upgrade — submodule Argumentum + import 2025-Epita-IS (cours EPITA 20/05) #1271 (sous-module Argumentum gelé). Tout le travail est de la traduction humaine assistée + git mv/Write.
3. Pré-produit les *.en.md. La manœuvre récupère l'original EN comme <doc>.en.md au passage — exactement le livrable que la Phase 3 scriptée générerait automatiquement plus tard. Le défrichage manuel pré-remplit donc le périmètre EN.
4. Golden set pour le moteur. Les paires FR/EN de qualité humaine produites ici servent de jeu d'étalonage/audit pour valider la qualité du moteur Argumentum en Phase 4 (cf critère ajouté).

Convention naming. Alignement sur l'Epic existant (Phase 3) : README.en.md, <name>.en.md (séparateur point, standard i18n, cohérent avec xxx_<lang>.ipynb). Note : le mandat user écrit Readme_en.md (underscore) ; on standardise sur README.en.md pour cohérence avec la Phase 3 déjà documentée — à confirmer par le user si l'underscore est préférable.

Périmètre issu du scan 2026-06-12 (docs EN-dominants, ratio stop-words EN/FR > 0.60, >100 mots), filtré pour ne garder que les docs CoursIA pérennes :

Exclus du défrichage (tri pérenne vs éphémère) :

• Audits / snapshots éphémères (*AUDIT*.md, qc_projects_audit_*.md, audit_consolidation_qc.md, M10_DM_RETROACTIF.md, verdict.md, quantbooks_execution_status.md, STABLE_SNAPSHOT*.md) → relèvent du nettoyage dashboard (cf harness-hygiene), pas de traduction.
• Harnais (.claude/rules/, .claude/skills/, .claude/agent-memory/, CLAUDE.md) → déjà hors scope déclaré (lecteur unique = agents francophones).
• Upstream Lean (.lake/packages/{mathlib,Cli,importGraph}/) → dépendances tierces, jamais traduire.
• Archives (docs/archive/*) → déjà déplacés, pas prioritaires.
• Worktrees (.claude/worktrees/**) → copies temporaires, ignorer (doublons du repo principal).

Processus ad-hoc par doc (manuel, non scripté) :

1. Copier l'original EN : <doc>.md → <doc>.en.md (contenu anglais préservé verbatim). Pour un README.md : README.md → README.en.md.
2. Réécrire <doc>.md en français (traduction humaine assistée) — devient la source FR primaire.
3. Préserver : structure markdown, blocs code, tables, liens (URLs inchangées), front-matter.
4. Commit atomique par série (règle catalog-pr-hygiene HARD 3) : une PR = une série (ex. « traduit les READMEs EN des stratégies QC », « traduit Probas/PORT_PYTHON_PLAN.md »). Pas de composite cross-séries.
5. Indexer la paire dans un translation_golden_set.json (source FR + source EN + chemin) pour réutilisation Phase 4.

Cette phase produit des fichiers *.en.md qui seront réconciliés avec la sortie du moteur en Phase 3 : si le moteur régénère un .en.md quasiment identique à la version humaine, c'est un signal de qualité ; un écart signale une zone à auditer.

Phase 1 — Connecteur Argumentum → CoursIA (4-6h)

scripts/translation/argumentum_bridge.py :

• Wrapper Python autour du datasetupdater Argumentum
• Validation env (sous-module présent, dépendances Argumentum chargées)
• Endpoint unique translate_csv(input_csv_fr, target_langs) -> dict[lang, output_csv]
• Gestion erreurs / retry / quota
• Importation verbatim du datasetupdater : pas d'altération (cf principe paternité externe).

Phase 2 — Extracteur CSV (8-12h)

scripts/translation/notebook_to_csv.py :

• Lit un .ipynb, parcourt les cells
• Cellules markdown : extrait chaque paragraphe en ligne CSV
  • Préserve formules LaTeX $...$ et $$...$$ (placeholders __LATEX_0__, etc.)
  • Préserve liens markdown (texte traduit, URL conservée)
  • Préserve blocs code inline ` (placeholders)
• Cellules code : extrait uniquement les commentaires # / // (les strings restent en français quand elles font partie de la pédagogie ; le code lui-même n'est jamais traduit)
• Préserve cell_id pour réinjection ordonnée
• Schema CSV (compatible Argumentum datasetupdater) :

notebook_path,cell_id,cell_type,paragraph_idx,placement_hint,source_lang,text_fr,placeholders_json

scripts/translation/markdown_to_csv.py :

• Lit un .md, segmente par paragraphe
• Préserve front-matter YAML, blocs code triple-backtick, tables markdown
• Schema parallèle au notebook avec heading_path au lieu de cell_id

Phase 3 — Réinjecteur (8-12h)

scripts/translation/csv_to_notebook.py :

• Reçoit (notebook_fr_source, csv_translated, target_lang)
• Reconstruit xxx_<lang>.ipynb à partir du source FR, en remplaçant les textes français par leurs traductions
• Réintroduit les placeholders LaTeX / code inline / liens
• Conserve execution_count et outputs du source (cf règle C.2 — pas de re-exécution automatique des notebooks traduits)
• Convention naming : <basename>_<lang>.ipynb

scripts/translation/csv_to_markdown.py :

• Réinjection markdown préservant front-matter, code, tables
• Convention : README.en.md, docs/architecture.en.md, etc.

Phase 4 — Pilote sur 1 série (6-8h)

Choisir une série compacte avec markdown riche. Candidats :

• A : MyIA.AI.Notebooks/IIT/ (PyPhi, 4-6 notebooks, contenu théorique dense)
• B : MyIA.AI.Notebooks/Probas/ (Infer.NET, markdown abondant)
• C : MyIA.AI.Notebooks/SymbolicAI/Lean/ Lean-1 à Lean-3 (introduction Lean, audience internationale forte)

Pipeline complet sur la série pilote dans 2 langues (EN + ES). Validation manuelle de la qualité, ajustements du pipeline.

Arbitrages décidés en Phase 4 :

• Naming : xxx_<lang>.ipynb à côté du source vs répertoires séparés notebooks/<lang>/xxx.ipynb
• Re-exécution des notebooks traduits : oui / non / au cas par cas
• Cellule sélecteur de langue dans le notebook ? Sinon README de série multilingue suffit

Phase 5 — Scale-up batch (16-24h walltime)

Driver scripts/translation/translate_repository.py :

• Itère sur tout le périmètre (notebooks + markdown)
• Parallélise par notebook (multi-thread CSV upload + multi-call datasetupdater)
• Génère un translation_manifest.json avec entrées : source_path, target_lang, sha256_source, timestamp, argumentum_version, status
• Gating obligatoire : revue user sur 5-10 notebooks aléatoires par langue avant publication

Phase 6 — Drift detection & maintenance (6-10h)

Quand un notebook FR source change, comment savoir quelles traductions retraduire ?

• translation_manifest.json conserve sha256_source au moment de la traduction
• scripts/translation/check_drift.py :
  • Compare sha256 actuels vs manifest
  • Liste les (source, lang) à retraduire
  • Mode --auto-retranslate pour batch
• Hook pre-commit optionnel : warning (pas blocking) sur les notebooks FR modifiés sans retraduction associée

Phase 7 — Index langues & navigation (4-6h)

• README racine : section "Languages / Langues / Idiomas / …" listant les langues disponibles
• Top-level index.en.md, index.es.md, … pointant vers les README de série traduits
• README de série en double : README.md (FR) + README.<lang>.md

Phase 8+ (hors scope initial)

• Slides Marp / PPTX
• Pages MkDocs / Jupyter Book multi-langue
• Voice-over multilingue pour notebooks GenAI Audio ([EPIC] GenAI Audiobook v2 — Pivot P4 vers FishAudio S2-Pro (spec originale #1028) #1273 connecté)

Stratégie "fichiers précieux mis en avant" — Argumentum

Le datasetupdater Argumentum est un outil utilisateur (jsboige) précieux. Il doit être :

1. Cité publiquement dans le README racine CoursIA :

   "Translations powered by Argumentum datasetupdater — multilingual CSV translation engine developed by jsboige (2024-2025)."

2. Crédité dans le docstring de argumentum_bridge.py :

   """
   Bridge to Argumentum datasetupdater (jsboige, 2024-2025).
   Multilingual CSV translation engine originally developed for the
   Argumentum card game corpus.
   
   Source: https://github.com/jsboige/Argumentum
   Submodule path: <chemin>
   Bridge integration date: <YYYY-MM-DD>
   """

3. Importé verbatim : pas d'altération du datasetupdater côté CoursIA. Toute adaptation va dans le bridge, jamais dans le sous-module.

4. Documenté dans une page dédiée docs/translation-engine.md :

   • Description du pipeline CoursIA
   • Crédit moteur Argumentum
   • Liste des langues actives
   • FAQ retraduction / drift / contribution

Hall of Fame

Set confirmé Argumentum Data-Gate v0.9.0 (relevé dashboard Argumentum workspace 2026-05-28) : EN, FR, ES, AR, FA, ZH, RU, PT (8 langues, 4 datasets matures : Rules / Virtues / Scenarii / Fallacies). Backend gpt-5.5, garde-fou ~$8/PR, plafond ~$120/Phase. Si Argumentum v1.0 ajoute DE / IT / JA, CoursIA suit en cycle suivant — la matrice Argumentum reste la source de vérité.

Estimation

Risques & mitigation

Critères de complétion

• Sources FR assainies (Phase 0.5) : les ~30 docs EN profonds pérennes sont traduits en FR (source primaire) avec leur original EN récupéré en <doc>.en.md ; translation_golden_set.json constitué
• Golden set réutilisé (Phase 4) : la qualité du moteur Argumentum est auditée par comparaison avec le golden set Phase 0.5 (écart mesuré)
• ≥1 série entière traduite et publiée (Phase 4 pilote)
• Driver batch fonctionnel et reproductible (Phase 5)
• README racine + ≥5 séries indicatives traduites dans ≥2 langues (Phase 5)
• Drift detection opérationnelle (Phase 6)
• Index multilangue navigable depuis README racine (Phase 7)
• Hall of Fame Argumentum cité publiquement (README racine + docs/translation-engine.md)

Hors scope (initial)

• Code Python/C# lui-même : pas de traduction du code, identifiers restent en source
• Outputs notebooks : par défaut conservés du source FR (exception : Phase 5 sub-track re-exec)
• Slides Marp / PPTX : Phase 8+
• Notebooks étudiants (forks) : non concernés, restent en français source
• Pull requests / issues GitHub : non traduits (méta-discussion projet en français)
• CLAUDE.md / .claude/rules/ : non traduits (méta-instructions cluster, lecteur unique = agents francophones)

Voir aussi

• [EPIC] Argument_Analysis upgrade — submodule Argumentum + import 2025-Epita-IS (cours EPITA 20/05) #1271 [EPIC] Argument_Analysis submodule Argumentum — dépendance bloquante
• Epic — Conway tribute Phase 2 : Game of Life, hashlife, Gemini replicator, OTCA Metapixel, CPU patterns en Lean (low priority) #1647 Conway Phase 2 (hashlife + Gemini + OTCA + CPU) — pattern Epic ambitieuse low-priority
• Epic — Hommage à Grothendieck : Mathlib tour, micro-formalisations, notebook Lean-13 (low priority) #1646 Grothendieck Phase 1 — pattern parallèle low-priority
• Epic: Fork Z3.Linq propre + reintegration EPFdevelopment + serie notebooks + PRs upstream #1206 Z3.Linq fork + reintegration — autre travail d'intégration externe
• [EPIC] GenAI Audiobook v2 — Pivot P4 vers FishAudio S2-Pro (spec originale #1028) #1273 Audiobook GenAI — connexion possible Phase 8+ voice-over multilingue
• Dashboard Argumentum workspace — source de vérité langues supportées
• Mémoires de session : feedback-community-witnesses-credited (paternité du datasetupdater), feedback-mandate-amplification ("pharaonique mais réutilisation cleane" = scope assumé)

🤖 Generated with Claude Code pour ai-01:CoursIA cycle 92, suite mandat user 2026-05-28.

Corrections vérifiées (2026-08-30 — tri ROO-1, réfutations Vibe)

• Volumétrie : l'estimation « ~400 notebooks » (ligne inventaire) est réfutée — 1 181 notebooks source mesurés sur origin/main (SHA 68e7a663, git trees truncated:false, exclusions _output/_<lang>), cohérent avec le README (« 1 024 notebooks » au 17/08) et l'audit Vibe (1 011 le 29/08). Toute projection de coût/temps doit se recalculer sur ~1 200, pas 400.
• Schéma CSV divergent de l'existant : le corpus translations/ (33 CSV, 804 notebooks couverts selon l'audit) utilise déjà notebook,cell_id,cell_type,src_lang,src_hash,text_fr,text_en,text_es,text_ar,text_fa,text_zh,text_ru,text_pt,hash_*,translate_policy — vérifié sur translations/genai/audio.csv (origin/main). Le schéma proposé dans cette issue (notebook_path,paragraph_idx,placeholders_json) n'existe nulle part dans le corpus et ignorerait 7 colonnes de langues + les colonnes hash_* de détection de changement. Toute implémentation doit partir du schéma existant.