Protocole d'évaluation — effet mesuré du standard gouverné¶

Statut : protocole, pas de résultats. Ce document définit comment mesurer l'effet du standard agentique gouverné sur les résultats d'agents. Aucun chiffre d'efficacité ne doit être publié (README, site, annonces) tant qu'une campagne complète n'a pas été exécutée selon ce protocole — résultats négatifs inclus.

Question mesurée¶

Un projet enrôlé dans le standard gouverné (profil + patterns + gates fail-closed) produit-il de meilleurs résultats agents qu'un projet témoin identique sans gouvernance, à modèle, tâches et budget égaux ?

Design expérimental¶

Deux bras par tâche : governed (profil starter ou supérieur, gates actifs) vs baseline (même projet, standard non installé).
Projets témoins : examples/web-app-todo (web) et examples/terraform-houseserver (infra). Un troisième témoin externe est souhaitable pour éviter le sur-ajustement aux exemples du kit.
Tâches : suite fixe et versionnée de 8-12 tâches réalistes par témoin (feature, bugfix, refactor, migration), définies AVANT toute exécution dans evals/tasks/<temoin>.yaml.
Répétitions : minimum 5 exécutions par tâche et par bras (variance LLM), même modèle, même version du kit, température documentée.
Aveuglement : l'évaluation humaine des livrables (si utilisée) se fait sans savoir de quel bras provient le diff.

Métriques (toutes collectables depuis les artefacts du kit)¶

Métrique	Source	Bras avantagé attendu
Taux de complétion (tâche livrée ET tests verts)	CI locale / `cc-verify.sh`	?
Régressions introduites (tests cassés post-merge)	suite de tests du témoin	governed
Preuves manquantes au moment du « terminé »	`grimoire standard gate check`	governed (par construction)
Coût tokens / tâche	registre de coût LLM (`llm-cost-registry`)	baseline (hypothèse : la gouvernance a un surcoût)
Interventions humaines nécessaires	journal de session	?
Score de conformité final	`grimoire standard score`	governed (par construction)

Les deux dernières lignes « par construction » ne prouvent rien sur la qualité : elles servent uniquement de contrôle de manipulation (le bras governed doit effectivement être gouverné).

Règles d'honnêteté¶

Pré-enregistrement : tâches, métriques et seuils sont committés avant la première exécution ; tout changement ultérieur est journalisé.
Résultats négatifs publiés : si le bras governed ne montre pas d'avantage (ou montre un surcoût net), le résultat est publié tel quel.
Pas de cherry-picking : le rapport agrège TOUTES les exécutions, pas les meilleures.
Reproductibilité : chaque campagne fige la version du kit, du modèle et des tâches dans son rapport (evals/reports/<date>/).
Règle d'arrêt : un bras conçu après avoir vu un résultat qu'il pourrait expliquer est exploratoire, et ne peut pas changer un verdict (voir A2).

Layout attendu¶

evals/
├── tasks/
│   ├── web-app-todo.yaml          # suite de tâches pré-enregistrée
│   └── terraform-houseserver.yaml
├── runs/                          # sorties brutes par exécution (non committées)
└── reports/
    └── 2026-XX/report.md          # agrégat, stats, conclusion honnête

Critère de succès (à pré-enregistrer)¶

Critère composite en vigueur (composante coût amendée par A1, voir le journal des amendements) : le bras testé est déclaré « utile » si

les régressions baissent d'au moins 30 % relatif vs baseline ;
le taux de complétion ne baisse pas ;
le coût par tâche complétée ne dépasse pas celui du bras baseline de référence. Garde-fou de validité : si le taux de complétion du bras testé est inférieur à 25 %, le coût par tâche complétée est jugé non interprétable et la composante coût est déclarée échouée.

Le coût brut par run reste rapporté dans chaque rapport, à titre informatif (les deux lectures sont toujours publiées), mais n'est plus décisionnel. Tout autre résultat = « non démontré » et le README ne fait aucun claim d'efficacité.

Critère original (campagnes 2026-07-03 et 2026-07-09, conservé pour lecture des rapports correspondants) : régressions −30 % relatif SANS baisse du taux de complétion ni hausse du coût tokens de plus de 25 %.

Journal des amendements¶

A1 — 2026-07-12 — composante coût : du coût brut par run au coût par tâche complétée¶

Moment : après les campagnes 2026-07-03 (baseline/governed) et 2026-07-09 (activated), avant toute exécution d'un bras ultérieur. Aucune donnée du bras suivant n'existait au moment de cet amendement.
Contexte : le bras activated du 2026-07-09 passe les composantes régressions (−61,5 %) et complétion (15/40 vs 6/40) mais échoue sur le plafond de coût brut (+47,4 % > +25 %), d'où le verdict « non démontré ». Le rapport documente que le coût brut par run pénalise mécaniquement un bras qui complète 2,5× plus de tâches (chaque run accompli plus de travail réel) et que le coût par unité de valeur est la métrique économique pertinente (3,68 $/tâche complétée en baseline contre 2,17 $ en activated). Il recommande explicitement de trancher ce choix avant la campagne suivante.
Décision : pour toute campagne exécutée après le 2026-07-12, la composante coût du critère composite est « coût par tâche complétée ≤ celui du bras baseline de référence », avec le garde-fou de validité ci-dessus (complétion < 25 % ⇒ composante échouée). Le coût brut par run est rapporté mais non décisionnel.
Portée : non rétroactif. Le verdict « non démontré » de la campagne 2026-07-09 reste inchangé et ne sera pas réinterprété avec le critère amendé ; seule une nouvelle campagne peut produire un verdict positif.

A2 — 2026-08-28 — règle d'arrêt : ce qui clôt la question, et quand¶

Moment : après les campagnes 2026-07-03 (baseline/governed), 2026-07-09 (activated) et le jugement du bras activated-v2, avant toute exécution du bras baseline-v3. Aucune donnée de baseline-v3 n'existe au moment de cet amendement.
Contexte : trois campagnes, trois verdicts « non démontré ». Le bras activated-v2 atteint la composante coût A1 mais échoue sur la complétion (10/40 < 12). Le bras baseline-v3 est pré-enregistré après ce jugement, pour tester si la dérive du modèle servi explique le déficit — l'ordre est divulgué dans ACTIVATION-V2.md, ce qui est la bonne pratique. Il reste que le protocole ne dit nulle part ce qui clôt la question. Sans règle d'arrêt, chaque résultat négatif produit mécaniquement un bras de plus, et la thèse centrale du produit reste ouverte indéfiniment pendant que le reste se construit dessus.
Décision, en trois clauses :
Un bras conçu après avoir vu un résultat qu'il pourrait expliquer est exploratoire. Son résultat ne peut pas transformer un « non démontré » en « démontré ». Il peut motiver une nouvelle campagne, dont le design est alors figé avant toute exécution — c'est cette campagne-là qui produit un verdict. baseline-v3 tombe sous cette clause.
Deux campagnes pré-enregistrées consécutives qui échouent au critère composite closent la question pour cette intervention sur cette suite de tâches. Le verdict devient « effet non démontré », et il est publié comme tel — le README ne fait aucun claim, ce qui est déjà la règle 2.
Ce qui suit une clôture n'est pas un bras de plus. C'est, au choix et explicitement : changer l'intervention (ce que le standard fait), changer la mesure (ce qu'on appelle un progrès), ou changer la suite de tâches (où l'effet est censé se voir). Le changement est journalisé ici avant la campagne suivante. Reprendre la même intervention, la même mesure et la même suite après une clôture demande une justification écrite.
Portée : non rétroactif sur les verdicts publiés. La clause 1 s'applique dès baseline-v3. Le compteur de la clause 2 démarre à la première campagne pré-enregistrée exécutée après cet amendement.
Ce que cette règle ne dit pas : elle ne préjuge pas du résultat. Si une campagne pré-enregistrée passe le critère composite, la thèse est démontrée sur cette suite, et la règle d'arrêt n'a simplement jamais à s'appliquer.