Onepager — Vers un écosystème d'agents auto-améliorant¶

Statut : réflexion / vision (draft) · Auteur : Romain · Origine : discussion Romain × Alban (22/06/2026) Rattachement doctrine : pilier #1 « boucle d'apprentissage > spécification amont »

TL;DR¶

Améliorer chaque agent de l'Outil d'analyse coûte cher en temps et surtout en contexte (signaux dispersés : data, feedback UI, quali oral, contrôles aléatoires). Notre impact = capacité à (1) comprendre les frictions et (2) livrer de nouvelles versions d'agents. Le Claude Agent SDK est un levier sur ces deux moteurs à la fois : un agent qui explore et diagnostique sans réinventer la roue, et des workflows autonomes qui codent les correctifs — gardés par nos eval campaigns. On ne part pas de zéro : on soude des briques déjà existantes (/scan-feedback, Workflow 2.0, eval_campaigns) en une boucle fermée qui s'améliore toute seule.

Le constat¶

Améliorer un agent demande un contexte énorme : son prompt, son schéma, ses cas d'échec, les règles métier, la doctrine — éparpillés sur plusieurs repos + Neon + CRs.
Les insights viennent de partout et sous des formes hétérogènes :
Quali oral : réunions, synchro Cédric, retours AM (vit dans les CRs)
Feedback écrit : utilisateurs de l'interface d'analyse
Data : sorties agents, corrections humaines, décisions comité (Neon prod)
Contrôles aléatoires : QA par échantillonnage
Aujourd'hui, agréger tout ça pour un seul agent = des heures de travail manuel. → c'est le vrai goulot, pas l'écriture du code.

La thèse¶

Notre impact dépend de deux capacités :

Comprendre les frictions / erreurs par agent
Implémenter de nouvelles versions

Le Claude Agent SDK adresse les deux — et les met bout à bout en une boucle.

La boucle (flywheel)¶

    Signaux                Diagnostic            Implémentation         Juge
    (data, feedback   →    Agent explorateur  →  Workflow de code   →   Eval
     UI, quali, QA)        (SDK)                 autonome (SDK)         campaigns
        ↑                  Hypothèses                Nouvelle              │
        │                  priorisées                version agent         │
        └──────────────────  Prod  ←───────────────────────────  PASS ────┘
                                              (sinon : retour)

Chaque tour de boucle est de plus en plus autonome ; l'humain valide aux points à fort levier (priorisation des hypothèses, review de PR).

Levier A — Embarquer le SDK dans un agent « diagnostic »¶

Un agent qui explore de façon autonome : lit Neon, les corrections humaines (metadataSources, ADR-014), les feedbacks UI, les CRs, fait des contrôles aléatoires.
Capitalise sur tout ce qui est embarqué nativement (Read / Grep / Bash / WebSearch, sub-agents, MCP) → on ne réécrit pas un framework d'exploration.
Sortie attendue : hypothèses d'amélioration priorisées par agent, pas un dashboard.
Carburant le plus riche : les corrections humaines déjà captées (capture passive, pilier #4 / ADR-018) = dataset labellisé gratuit des erreurs agents.

Levier B — Workflows autonomes qui codent les améliorations¶

Lancer des workflows qui implémentent les correctifs — y compris sur des agents qui ne tournent pas sur le SDK (le SDK est l'ouvrier, pas une contrainte d'archi).
Extension possible du workflow agent, avec preview isolée par PR selon l’ADR du 6 août 2026, déclenchée par une hypothèse validée plutôt que directement par un signal brut.

On ne part pas de zéro¶

Brique de la boucle	Ce qui existe déjà
Diagnostic	`/scan-feedback` (feedback règles métier hebdo → Notion / Slack)
Implémentation	Workflow 2.0 (ticket → branche → PR → preview isolée)
Juge / fitness	`golden_references` / `eval_campaigns` / `eval_results`
Carburant	corrections humaines `metadataSources` (ADR-014)
Observabilité	LangSmith comme backend unique (ADR-021)

Le SDK ne crée pas une nouvelle usine, il soude ces pièces en un flywheel.

Observabilité — investir dans le logging pour accélérer la boucle¶

La vitesse d'amélioration est directement proportionnelle à la qualité de ce qu'on observe. Un agent diagnostic ne vaut que ses traces : sans logging riche, il devine ; avec un logging riche, il raisonne sur des faits.

LangSmith est déjà branché (traces LLM par agent, métadonnées par run). C'est notre source de vérité sur ce que chaque agent a réellement vu, demandé et produit — inputs, prompts, tool calls, sorties, latence, coût.
C'est le substrat du Levier A : l'agent explorateur lit ces traces pour relier une erreur métier à sa cause (prompt ? RAG ? schéma ? source ?), au lieu de partir de zéro à chaque fois.
Donc on doit investir dans le logging — délibérément et en continu : tracer chaque agent de bout en bout, capter systématiquement les cas d'échec et les corrections humaines associées, enrichir les métadonnées (version d'agent, sources retenues, confiance). Chaque trace manquante est un angle mort qui ralentit la boucle.
Principe : plus le logging est dense et structuré, plus le diagnostic est rapide et fiable, donc plus le cycle diagnostic → correctif tourne vite. Le logging n'est pas un coût d'observabilité — c'est l'investissement qui compose la vitesse d'amélioration.

Garde-fous (conditions de viabilité)¶

Fitness function non négociable : rien ne merge sans battre la baseline sur les golden refs. C'est ce qui sépare auto-amélioration et auto-dérive.
HITL aux points à fort levier : l'humain valide l'hypothèse et review la PR, il ne collecte plus le contexte à la main.
Anti-monitoring (anti-pattern LIDAR #4) : le diagnostic produit des actions priorisées, jamais un tableau de bord qui grossit.
Le SDK ≠ fiabilité : c'est un harnais d'orchestration, pas une triangulation. Il ne remplace pas la cascade convergence (ADR-001).

Trajectoire¶

Crawl : Levier A en lecture seule sur 1 agent — produit un rapport d'hypothèses, validé à la main. Zéro risque prod.
Walk : brancher A → B sur 1 agent, avec eval gate + review humaine obligatoire.
Run : boucle semi-autonome multi-agents ; l'humain ne fait plus que prioriser et arbitrer les PR.

Risques & questions ouvertes¶

Lock-in Claude / dépendance fournisseur ⚠️ : tout le harnais (SDK + binaire) repose sur l'écosystème Anthropic. On reproduirait alors avec Claude exactement la dépendance qu'on subit aujourd'hui avec Manus — où une baisse de qualité, un changement de modèle, de pricing ou de comportement côté fournisseur dégrade notre pipeline sans qu'on ait la main. Risques concrets : régression silencieuse à chaque update de modèle, hausse de coût subie, rupture d'API. Mitigations à garder en tête : isoler le SDK derrière notre contrat d'agent (AgentResult) pour qu'il reste remplaçable ; conserver des chemins non-SDK (OpenAI structured_output, baselines) ; faire de l'eval gate notre garde-fou anti-régression (toute baisse de qualité fournisseur est détectée par les eval campaigns avant la prod).
Coût / latence d'exécution du SDK (sous-process binaire) en prod.
Qualité du signal : garbage in → garbage out ; dépend de la richesse des captures.
Boucle de Goodhart : optimiser la métrique d'eval ≠ optimiser la vraie qualité métier.
Périmètre du Run : jusqu'où va l'autonomie sans validation humaine ?

Prochain pas¶

Prototyper le Levier A sur un agent (ex. estimate_value ou un legal_*) : un agent diagnostic en lecture seule qui produit un rapport d'hypothèses priorisées.