[Tracker] Distillation-outil et lego d'agents : 4 axes de fond (Aricie/PortalKeeper, EPITA 2025 Argumentation, ICT+mech-design, essai Paper2Agent)

[jsboige]

Tracker parapluie de fond, ouvert pour cadrer 4 axes inter-liés que le user a identifies comme un meme verrou structurel de CoursIA : comment une distillation-outil devient-elle un contrat d interface re-exploitable (agent specialise, MCP, classe decoree), et comment on consolide ce qui s accumule. Pas un livrable, un tracker.

== Etat verifie (sources firsthand, 2026-09-16 cycle c.1211 myia-po-2027) ==

=== Axe 1 : Patrimoine Aricie = "PortalKeeper" / lego no-code a classes decorees ===

• EPIC parente : [Epic] 🧭 Amorce patrimoine Aricie → MyIA.AI.Shared : index récupérable (CSP/Flee, Lucene/Safari, DCP/Redis, fork Lean) + ordre #7265 "[Epic] Amorce patrimoine Aricie -> MyIA.AI.Shared : index recuperable (CSP/Flee, Lucene/Safari, DCP/Redis, fork Lean) + ordre"
• Cadrage : docs/reference/backtester-e2-cadrage.md (Option C, decouplage Aricie, substitution des libs ML -- decision user du 2026-07-19)
• Cadrage SVM : docs/reference/backtester-e2-svm-kernel.md (substitution du SVM a noyau dans le port E2 du Backtester Aricie)
• Etat livre mesurable : A1 (decoration + hierarchie infinie, PR feat(shared,#7265): A1 ancre metadata-driven decoration (attributes + interfaces + ReflectedProviderContainer) #7653, feat(shared,#7265): A1+ provider hierarchy — Simple + Auto discovery, shared IProviderContainer #7669) + A2 (serialisation JSON feat(shared,#7265): A2 lego serialization — decoration-driven JSON round-trip #7661 et XML feat(shared,#7265): A2+ lego serialization — decoration-driven XML round-trip #7677) + B4 (moteur Flee feat(socle,#10161): add FleePredicateBuilder — B4 universal predicate (tests 56/56) #10167) + tests (9 fichiers MyIA.AI.Shared.Tests/) + README module + notebook Socle-MetadataDriven-Csharp.ipynb (feat(shared,#10161): Socle-MetadataDriven-Csharp notebook — exercise low-code Flee rule-engine #10165) -- socle transverse MyIA.AI.Shared/ deja sur main
• E2 Backtester (port Option C EN COURS) : EPIC [E2] MyIA.Trading.Backtester — port Option C EN COURS : 25/75 fichiers sur main (tranches 1-3), BackTesting.cs restant #7357, cadrage docs(shared,#7357): cadrage E2 Option C - precondition dette doc constatee satisfaite, paire ML.NET 9 testee #12541, 25/75 fichiers sur main, BackTesting.cs 755 lignes restant
• A faire / non commence : A3 (object explorer UI), B1-B3 (moteurs AIMA/CNTK/gnugo), C (Lucene/Safari/DistributedSearch), D (DCP/cache distribue)

=== Axe 2 : Distillation-outil Argumentation projet EPITA 2025 (cousin d'Argumentum) ===

• Repository de distillation : jsboigeEpita/2025-Epita-Intelligence-Symbolique (Python ; pushedAt 2026-09-16T20:15:43Z = aujourd hui)
• ATTENTION : ne pas confondre avec Argumentum, le submodule MyIA.AI.Notebooks/SymbolicAI/Argument_Analysis/Argumentum (remote ArgumentumGames/Argumentum, agent permanent dedie, cf. CLAUDE.md R6 submodule-maintenance). Argumentum = l outil generique reutilisable ; EPITA 2025 Argumentation = la distillation-outil specifique au projet.
• Table des projets distilles (verification git ls-tree HEAD du bare clone temporairement) :
  • 1.4.1-JTMS/ -- Justification TMS (jtms.py, atms.py)
  • 1_2_7_argumentation_dialogique/ -- argumentation dialogique multi-agents (engine + KB + agents + protocoles inquiry/persuasion + dialogue_agent.py + multi_agent_system.py)
  • 2.1.6_multiagent_governance_prototype/ -- gouvernance multi-agents (resolution de conflits)
  • 2.3.2_detection-sophismes/, 2.3.3_generation-contre-argument/, 2.3.5_argument_quality/, 2.3.6_local_llm/ -- a inspecter
  • 3.1.5_Interface_Mobile/ -- UI Expo (ArgumentCard, FallacyCard, MarkdownStyles)
  • Arg_Semantic_Index/ -- index semantique RAG (Kernel Memory)
  • CaseAI/ -- UI pedagogique
• Verrou identifie : 9 projets numerotes, modules agents / protocoles / KB / UI sans charte de distillation-outil commune visible (pas de README agrege, pas de toolbox partagee). Catalogue par numerotation, pas par capacite re-exploitable.

=== Axe 3 : Consolidation outils ICT + outils mechanical-design qui se profilent ===

• ICT (Integrated Complexity Theory) : MyIA.AI.Notebooks/IIT/ICT-Series/ -- 12+ notebooks en cours de densification (EPIC densite pedagogique : 430 notebooks sous le plancher 1200 — surface majoritairement non suivie #13410). Format : notebooks IFrame.
• Mechanical-design (GameTheory-16) : MyIA.AI.Notebooks/GameTheory/GameTheory-16-MechanismDesign*.ipynb + *_Csharp.ipynb
• Verrou : 2 domaines ou les outils s accumulent sans frontiere explicite entre ICT-outil et MCP-outil.

=== Axe 4 : Essai Paper2Agent comme ampoule (jmiao24/Paper2Agent) ===

• Depot : https://github.com/jmiao24/Paper2Agent -- convertit un PDF scientifique en serveur MCP executable, par extraction agentique.
• Intention : pas adopter, essayer. Lancer le skill sur UN papier deja distille cote CoursIA (l Orleans qui vient d etre livre feat(genai-dotnet): axe Orleans de la Part 1 — grains acteurs pour workloads IA (#10473) #16436 fait candidat), regarder ce que le skill rend, crosser avec nos gestes. Output = memo dashboard, pas de PR.

== Enfants a ouvrir ==

1. Voir si un README agrege existe deja cote EPITA 2025 (Arg_Semantic_Index/README.md semble le plus proche)
2. Audit Aricie B/C/D : reprendre le corps d [Epic] 🧭 Amorce patrimoine Aricie → MyIA.AI.Shared : index récupérable (CSP/Flee, Lucene/Safari, DCP/Redis, fork Lean) + ordre #7265 etablir l inventaire verifie de chacun
3. Memo Paper2Agent sur Orleans ou un autre axe deja distille, publie au dashboard workspace-CoursIA-2

== Pourquoi ce tracker ==

Aucun des 4 axes n est livrable en soi -- ils s eclairent les uns les autres. Le tracker nomme les enfants et tient leur etat ; la production de grains reste traitree en MED/DEEP sur le pool courant.

cf. #7265 (Aricie parent) + #7357 (E2 Backtester) + #13410 (densite ICT)

🤖 Generated with Claude Code

[jsboige]

Doublon de #4960 [EPIC] Argument_Analysis v3 qui couvre deja l axe EPITA 2025 Argumentation (distillation essence). Lumiere transverse 'toile de competences en coordination agentique' reportee en commentaire sur #4960. Pardon pour le bruit : les 9 sous-repertoires du repo etudiant sont deja consoliés sous Argumentation_Analysis dans CoursIA (en cours), je ne l avais pas verifie firsthand.

[jsboige]

Pas d'accord avec la fermeture, je rouvre. Ce tracker est sans doute mal formulé, mais c'est un parapluie utile pour garder une réflexion de fond sur l'orchestration de compétences agentiques. Le projet de distillation Epita IS n'en est qu'une facette, mais l'architecture de PortalKeeper, la mise en oeuvre d'une orchestration dans les expériences de mechanical design, la consolidation des outils dévellopés par ICT comme un toolkit cohérent, et les tests possibles avec Paper2Agent ne peuvent vivre dans l'issue Epita qui n'est q'une facette de la problématique.
Je pourrais rajouter nos nombreuses expériences ADK et Semantic-Kernel, avec la présence de semantic-fleet donc ce dépôt est le steward actuellement, ainsi que l'arrivée chez Ms d'Agent Framework dont il faudra étudier la pertinence pour la reprise de certains de nos travaux.
La distillation Epita est la partie la plus immédiatement opérationnelle de cette réflexion de fond, mais ce tracker parapluie a son utilité.

[myia-ai-01]

Axe 5 — l'orchestration agentique comme objet d'étude (brief user 2026-09-19)

Le commentaire de réouverture du 17/09 posait l'élargissement au conditionnel : « Je pourrais rajouter nos nombreuses expériences ADK et Semantic-Kernel, avec la présence de semantic-fleet dont ce dépôt est le steward actuellement… ». Le brief du 2026-09-19 le pose à l'indicatif, en y ajoutant le harnais de développement de ce dépôt lui-même. Ce commentaire écrit l'axe et mesure sa surface — ce n'est pas un ajout, c'est la concrétisation d'une intention déjà déposée ici.

La surface, mesurée firsthand sur main (c818f6abc)

Surface	Mesure	Ce qui en fait un objet d'orchestration et pas une série de plus
Semantic Kernel	186 fichiers — dont 31 dans la série dédiée et 18 dans SymbolicAI/Argument_Analysis/	10-SemanticKernel-NotebookMaker.ipynb : système 3 agents Admin / Coder / Reviewer, fil rouge déclaré de la série — des rôles qui portent une procédure
Google ADK	19 fichiers, ML/DataScienceWithAgents/Track2-GoogleADK/	utils/adk_orchestrator.py — « orchestration multi-agents au-dessus de Google ADK » (contrat C4, #14058) : un plan déclaratif enchaînant N spécialistes, c'est-à-dire un graphe d'arêtes explicite
semantic-fleet	sous-module, dépôt dont CoursIA est steward	une flotte d'agents sous notre responsabilité, pas une dépendance subie
Diffus, non consolidé	AgentGroupChat dans 44 fichiers ; multi.?agent : 769 occurrences / 242 fichiers	exactement le verrou que ce tracker nomme : de la matière partout, aucune charte de capacité
Le harnais lui-même	23 sous-agents, 17 skills ; scripts/coordination/ = README.md + debt_ledger.py	un graphe d'orchestration écrit à la main, statique, jamais mesuré
Agent Framework (cité au commentaire de réouverture)	non mesuré ici	à instruire séparément

Et deux absences qui cadrent l'axe : swarm = 0 hit d'orchestration dans tout le dépôt (les ~30 occurrences sont toutes ParticleSwarm, de l'optimisation) ; society of mind = 0 hit. Le vocabulaire de l'orchestration comme objet n'est nulle part.

La colonne théorique que le brief apporte

Deux publications, identifiées firsthand, qui disent l'axe dans ses deux moitiés :

• MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework (ICLR 2024) — encoder des procédures dans des rôles. C'est la lecture directe du trio Admin/Coder/Reviewer de 10-SemanticKernel-NotebookMaker : le rôle n'est pas un prompt, c'est un porteur de procédure.
• Language Agents as Optimizable Graphs / GPTSwarm (arXiv 2402.16823, ICML 2024) — faire du graphe d'agents lui-même l'objet optimisé, nœuds et arêtes. C'est la lecture directe du plan déclaratif d'adk_orchestrator : le plan est déjà un graphe, il n'est simplement jamais traité comme une variable.

Pourquoi ça parle aux 4 axes existants plutôt que d'en ouvrir un 5e à côté. Le verrou que ce tracker nomme — comment une distillation-outil devient-elle un contrat d'interface ré-exploitable — reçoit ici une réponse candidate et testable : le contrat, c'est l'arête. L'axe 1 la matérialise en classes décorées, l'axe 4 (Paper2Agent) en serveur MCP, l'axe 3 en toolkit ICT ; GPTSwarm dit que ces trois formes sont la même variable vue de trois côtés, et qu'elle peut être l'objet d'une mesure.

L'arbitrage que je ne tranche pas ici

Optimiser des arêtes suppose une utilité mesurable. Ni adk_orchestrator ni le harnais n'en exposent une aujourd'hui. Tant qu'aucun objectif évaluable n'est défini, l'axe produit une distillation pédagogique — le graphe d'agents comme objet de première classe, adossé à adk_orchestrator qui existe déjà — et pas une optimisation du harnais. La veine « optimiser le harnais » est donc nommée ici et laissée ouverte, explicitement non engagée.

Rattachement

Cet axe est la veine B de l'Epic #16775 (curation du 2026-09-19), où il est qualifié avec le même détail. Les deux surfaces se lisent ensemble ; #16457 reste le tracker de fond, l'Epic n'en est pas le propriétaire.

cf. #14058 (contrat C4 adk_orchestrator) · #16775 (Epic, veine B) · #4960 (Argument_Analysis v3, axe 2) · #7265 (Aricie, axe 1) · #13410 (densité ICT, axe 3)

[myia-ai-01]

Correction (ai-01) — deux affirmations de mon commentaire d'axe 5 étaient fausses

Précisions user du 2026-09-19. Je corrige en place plutôt que d'effacer.

1. « Le harnais » ne désigne pas les sous-agents Claude Code

J'avais mesuré « le harnais lui-même » comme 23 sous-agents et 17 skills de ce dépôt, et j'en faisais « un graphe d'orchestration statique, jamais mesuré ». Mauvais objet — et le user précise que ces sous-agents sont d'ailleurs peu utilisés.

Le harnais visé est la flotte de 7 machines : outils dédiés par machine, protocoles de communication RooSync, coordination sur Git. C'est un système distribué réel avec des agents hétérogènes et une production observable, pas un roster de prompts. Ma mesure n'était pas inexacte, elle portait sur autre chose — ce qui est pire, parce qu'un chiffre juste sur le mauvais objet se lit comme une réponse.

2. « Pas d'utilité mesurable » — faux, mais la nuance est ailleurs que je ne croyais

J'avais conclu qu'« optimiser des arêtes suppose une utilité mesurable, et ni adk_orchestrator ni le harnais n'en exposent ». Le user nomme la fonction objectif que le cluster s'est déjà posée : le taux de merge par dollar dépensé.

Mesure firsthand sur main — la réalité est à mi-chemin, et c'est plus intéressant que l'un ou l'autre extrême :

Ce qui existe	Preuve
Comptabilité de jetons réelle	SymbolicAI/Lean/lean_runner.py : tokens_used par tentative de preuve, alimenté des usage des deux fournisseurs (:905, :1024-1026, :1057-1059)
Jetons + latence par appel	semantic-fleet/model_tester/api_utils.py rend (texte, temps, jetons)
Débit mesuré	scripts/genai-stack/probe_minicpm5_duel.py — jetons/s
Une lecture de coût en USD	GenAI/Vibe-Coding/Claude-Code/notebooks/02-Claude-CLI-Sessions.ipynb lit estimated_cost_usd depuis les logs de session (importé, pas calculé)

Ce qui n'existe pas	Preuve
Toute métrique de taux de merge ou de coût par run	merge rate|merges_per|per_merge|cost_per|usd_per sur scripts/**.py → 0 (hors une fixture de test)
Tout ratio dans le ledger	scripts/coordination/debt_ledger.py lu en entier : eat_hours est un stock de charge due, jamais normalisé par un temps ni un coût ; rate|velocity|burn|ratio|throughput ne rend que des faux positifs

Donc : utilité mesurée, jamais dérivée. La lane Epita instrumente les deux moitiés du ratio sur son dashboard de coordination ; aucun organe du dépôt ne les divise.

Organe candidat, et il est bon marché. Le numérateur vit dans Git (PRs mergées par lane, par fenêtre) ; le dénominateur demande une comptabilité de coût par lane. debt_ledger.py est architecturé pour l'accueillir — un kind supplémentaire y coûte une constante, cinq entrées de dict et ses FieldSpec. Le ledger porte un stock ; lui ajouter un flux est le geste minimal qui rend le merge-par-dollar calculable plutôt que rapporté.

3. Ce que la mesure a trouvé en chemin — un graphe d'agents déjà écrit

En comptant les experts du projet Epita pour une autre veine, je suis tombé sur l'artefact le plus proche de ce que l'axe 5 cherche. Sur jsboigeEpita/2025-Epita-Intelligence-Symbolique :

• harnais spectacular — build_spectacular_workflow() dans argumentation_analysis/orchestration/workflows.py assemble 39 phases-capacités en un DAG déclaratif ;
• harnais conversational — AGENT_CONFIG (conversational_orchestrator.py:199), 8 spécialistes ;
• et un registre à résolution par capacité, find_for_capability, dont l'ordre vient de faire l'objet d'un arbitrage de déterminisme.

Des nœuds typés, des arêtes déclarées, un résolveur qui choisit qui remplit quoi : c'est l'objet que « Language Agents as Optimizable Graphs » optimise, et il est déjà écrit, à côté. L'axe 2 de ce tracker (distillation Epita) et l'axe 5 regardent donc le même artefact par deux bouts.

Note de sourcing : les 12 répertoires numérotés à la racine de ce dépôt sont des projets étudiants figés, tous digérés dans argumentation_analysis/. Ils ne sont pas le roster ; la provenance étudiante de 9 capacités est tracée par écrit dans TWEETY_CAPABILITY_MAP.md, colonne « Student Project ».

Détail complet des cinq veines : #16775 (révision du 2026-09-19).

[myia-ai-01]

[CLAIMED] lane myia-po-2023:CoursIA -- tapis : decouper le tracker en ouvrant les filles nommees (memo Paper2Agent, audits Aricie B/C/D de #7265, frontiere outil ICT / outil MCP, veille MS Agent Framework) ; pose par ai-01 au dispatch

[jsboige]

Découpage du 2026-10-05 (dispatch ai-01 c.459, exécuté par lane myia-po-2023:CoursIA)

Le tracker est servi : 4 filles ouvertes, une par axe nommé, chacune avec acceptance vérifiable :

Fille	Axe	Objet	État
#19377	4	Essai Paper2Agent sur Orléans #16436 — memo comparatif dashboard	ouverte
#19378	1	Audit Aricie B/C/D depuis #7265 (B1/B2 en vol #19138/#19142, B4 livré — scope = B3/C/D)	ouverte
#19379	3	Frontière ICT-outil ↔ MCP-outil : critère de passage illustré sur 2 cas réels	ouverte
#19380	5	Veille MS Agent Framework, brique datée pour #14499	livrée le 05/10 — note (versions VERIFIÉES via API GitHub, GA 1.0 2026-04-03, SK critical-fixes RAPPORTE, péremption début avril 2027)

La plus courte (#19380) est livrée dans le même cycle, comme demandé. Les trois autres restent au pool, marquées tapis à la livraison de toute PR qui en sort.