Stax améliore-t-il un process Codex établi ?

En bref

Problème : quand un process Codex est déjà cadré, un outil comme Stax améliore-t-il vraiment le résultat, ou ajoute-t-il seulement une couche de contexte ?
Ce que j’ai testé : quatre variantes sur le même repo et le même data pack SEO : sans Stax, avec skill, avec Stax, avec Stax + skill.
Résultat : les deux scorings aveugles donnent le même ordre : st+clear, clear, st+skill, skill.
À retenir : dans ce lab, Stax donne un petit signal positif, surtout sur le caractère actionnable côté repo. La skill aide à formaliser, mais ne gagne pas seule.
Limite : ce n’est qu’un lab, sur un seul repo, un seul data pack, deux scorings Codex et aucune note Claude exploitable.

La question que je voulais poser

Je n’avais pas envie de tester Stax sur une tâche vague. C’est trop facile de lancer un outil d’agent et de conclure qu’il “a l’air mieux” parce qu’il a ajouté des fichiers, des consignes ou une forme de rigueur.

La question utile était plus étroite :

si le process est déjà établi, est-ce que Stax améliore encore quelque chose ?

Pour éviter de juger au feeling, j’ai pris une tâche réelle mais bornée : produire un rapport de quick wins SEO à partir d’exports Google Search Console et Google Analytics pour pezzoslabs.com, puis faire une modification très simple de homepage.

Le rapport permettait de juger la qualité d’analyse. La modification de fichier permettait de voir si l’agent restait propre dans un repo réel. Et les traces donnaient une mesure imparfaite mais utile du coût : durée, tokens, fichiers touchés, validations, relances.

Les quatre variantes

J’ai comparé quatre modes, tous depuis le même commit et avec le même data pack :

Variante	Stax	Skill SEO
`clear`	non	non
`skill`	non	oui
`st+clear`	oui	non
`st+skill`	oui	oui

Les worktrees étaient détachés depuis le même SHA : f5c62e3646c8ef17974fc84ad3d0bca0cb86a000.

Les quatre runs lisaient uniquement les fichiers exportés dans docs/seo-lab-data/. Après la création du data pack initial, les runs n’avaient plus le droit d’utiliser MCP, GA ou GSC en live.

Pour les variantes avec Stax, Stax était initialisé avant toute lecture de données. Pour les variantes avec skill, la skill était créée après une première lecture des données, puis exécutée dans une nouvelle sous-session.

Le data pack

Le pack couvrait la période du 24 avril 2026 au 21 mai 2026 inclus, avec une note dans le README : les rapports journaliers ne contenaient pas de ligne pour le 21 mai.

Les fichiers minimaux étaient :

gsc-queries-28d.csv
gsc-pages-28d.csv
ga-landing-pages-28d.csv
README-data.md

Le pack contenait aussi des exports utiles : page + requête, device, country, daily, sitemaps, pages GA, landing pages organiques, events, acquisition et conversions. Deux exports étaient vides ou non exploitables pour certaines conclusions : gsc-search-appearance-28d.csv et ga-conversions-28d.csv.

Les volumes étaient faibles. C’est important : ce lab ne prouve pas un plan SEO robuste. Il teste surtout la capacité des variantes à rester attachées aux exports, à éviter les conseils génériques, et à produire des recommandations concrètes malgré peu de données.

Ce que chaque run devait faire

Chaque variante suivait le même chemin :

lire le data pack ;
produire un rapport SEO quick wins ;
modifier uniquement la home ;
sauvegarder le diff ;
écrire une trace de run.

La modification de home était volontairement artificielle. Elle ne servait pas à tester la créativité SEO, mais la discipline de modification :

remplacer la meta description par une phrase propre à la variante ;
remplacer le H1 hero par Project Pezzos ;
ne rien changer d’autre volontairement ;
lancer la validation minimale pertinente.

Le scoring aveugle

Les rapports ont été anonymisés :

{
  "A": "clear",
  "B": "skill",
  "C": "st+clear",
  "D": "st+skill"
}

Le mapping n’a été révélé qu’après scoring.

J’ai obtenu deux scorings Codex. Le scoring Claude prévu n’a pas abouti : la commande a été interrompue après 527 secondes, sans sortie exploitable. Ce n’est donc pas un avis Claude.

Les deux scorings Codex donnent le même classement :

Rang	Rapport	Variante révélée	Score 1	Score 2	Moyenne
1	C	`st+clear`	92	93	92,5
2	A	`clear`	91	92	91,5
3	D	`st+skill`	88	84	86
4	B	`skill`	84	83	83,5

Le résultat principal tient en une phrase : Stax gagne dans les deux comparaisons, mais faiblement ; la skill seule ne gagne pas.

Détail du premier scoring

Rapport	GA/GSC	Quick wins	Priorisation	Actionnable repo	Limites	Lisibilité	Total
C	28/30	23/25	14/15	14/15	9/10	4/5	92
A	29/30	23/25	14/15	11/15	10/10	4/5	91
D	29/30	20/25	11/15	15/15	10/10	3/5	88
B	27/30	19/25	12/15	11/15	10/10	5/5	84

Détail du second scoring

Rapport	GA/GSC	Quick wins	Priorisation	Actionnable repo	Limites	Lisibilité	Total
C	28/30	23/25	14/15	14/15	9/10	5/5	93
A	29/30	23/25	14/15	12/15	10/10	4/5	92
D	28/30	18/25	10/15	14/15	9/10	5/5	84
B	27/30	19/25	11/15	11/15	10/10	5/5	83

Ce que Stax a semblé améliorer

La meilleure variante est st+clear. Elle bat clear d’un point de moyenne. Ce n’est pas spectaculaire, mais les deux scorings ont classé le rapport Stax devant le rapport normal.

La différence qualitative était assez constante : st+clear liait mieux les recommandations au repo. Le rapport gardait les données GA/GSC, mais il citait plus facilement des fichiers comme src/pages/..., src/data/accompagnement-pages.ts ou src/data/structuredData.ts.

Ce n’est pas une preuve forte. C’est plutôt un signal : sur un process déjà clair, Stax peut aider l’agent à produire une sortie un peu plus actionnable côté code.

Ce que Stax n’a pas prouvé

Stax n’a pas rendu le workflow moins coûteux dans ce lab.

La lecture initiale a été plus légère avec Stax, mais la génération de rapport a pris plus longtemps :

Variante	Lecture initiale	Rapport	Modification
`clear`	119 s	195 s	83 s
`st+clear`	91 s	261 s	104 s
`skill`	103 s	127 s	89 s
`st+skill`	99 s	187 s	93 s

Le coût total a augmenté avec Stax dans les deux paires comparables :

Variante	Durée totale	Input tokens	Output tokens
`clear`	397 s	1 134 434	16 508
`st+clear`	461 s	1 178 009	19 961
`skill`	512 s	1 625 959	22 099
`st+skill`	594 s	2 180 313	25 856

Je n’ai pas non plus pu observer précisément ce que Stax envoyait ou non à son service. La trace du lab dit seulement que l’orchestration n’a pas passé les exports GA/GSC aux commandes Stax, et que le comportement réseau ou la télémétrie ne sont pas vérifiables depuis stdout seul.

Ce que la skill a apporté

La skill SEO avait un rôle simple : rendre réutilisable la consigne de rapport quick wins, interdire MCP/live data, forcer les recommandations liées aux exports, et garder un format de sortie stable.

Elle a bien servi à formaliser le process. Elle n’a pas gagné le benchmark.

Le rapport skill arrive dernier. Son défaut principal, dans les deux scorings, est d’avoir mis en priorité une amélioration de mesure GA4. C’est utile pour de futurs rapports, mais ce n’est pas le meilleur quick win SEO immédiat à partir des données.

Avec Stax, la skill remonte : st+skill bat skill. Mais elle reste derrière clear et st+clear. Mon interprétation prudente : la skill aide peut-être à rendre un workflow répétable, surtout avec un contexte mieux structuré, mais elle ne remplace pas un prompt clair sur une tâche unique.

Le meilleur quick win trouvé

Les rapports et les scorings convergent sur une recommandation :

optimiser /diagnostic-automatisation-process/.

Les raisons :

position GSC autour de 5,18 ;
11 impressions ;
0 clic ;
engagement GA très fort ;
effort faible : title, meta description, H1/intro, promesse de page.

Ce point est intéressant parce qu’il ne dépend pas vraiment de Stax ou d’une skill. Il montre que le meilleur rapport n’est pas celui qui invente le plus de recommandations, mais celui qui saisit vite l’opportunité la plus concrète dans les exports.

Ce que j’en déduis

Je ne dirais pas : “Stax améliore les agents”. Ce serait trop large.

Je dirais plutôt :

dans ce lab, Stax améliore légèrement les rapports quand le process est déjà cadré ;
le gain se voit surtout dans l’ancrage repo ;
le coût augmente ;
la skill rend le workflow plus explicite, mais ne produit pas mécaniquement un meilleur rapport ;
le meilleur résultat vient de st+clear, donc Stax sans skill SEO dédiée.

Ce résultat me suffit pour refaire un second test. Il ne me suffit pas pour adopter Stax partout.

Ce que je referais autrement

Le protocole a marché, mais il était encore trop fragile.

La prochaine fois, je changerais plusieurs choses :

préparer la skill avant le lab, pour ne pas mélanger coût de création et qualité du rapport ;
randomiser l’ordre des variantes ;
lancer plusieurs répétitions par variante ;
utiliser au moins deux scorers vraiment différents ;
garder les prompts et scores dans un format plus facile à rejouer ;
publier un pack de résultats anonymisé si les données le permettent ;
séparer strictement les diffs de création de skill et les diffs de modification applicative.

Les artefacts publics

J’ai mis les rapports, les prompts, les scorings, les traces synthétiques et les diffs dans le repo public pezzos/seo-stax-skill-lab.

À lire dans l’ordre :

Le repo ne contient pas les CSV GA/GSC bruts, ni les logs JSONL Codex, ni les worktrees complets. Il sert à relire l’expérience, vérifier le protocole et comparer les sorties publiables. Il ne sert pas à rejouer exactement le lab avec les données privées, ni à prouver une performance générale de Stax, de Codex ou des skills.

Les prompts utilisés

Je ne recopie plus tous les prompts dans l’article. Ils font partie de la preuve, mais ils alourdissent trop la note alors que le repo public les garde déjà avec les rapports, les traces et le scoring.

Le protocole tenait en cinq familles de prompts :

lire uniquement le data pack SEO exporté, sans MCP ni données live ;
produire un rapport quick wins relié aux exports GA/GSC et aux fichiers du repo ;
créer puis exécuter une skill seo-quick-wins pour formaliser la même méthode ;
appliquer une modification de home volontairement minimale pour comparer les diffs ;
scorer les rapports anonymisés A/B/C/D avec une grille sur 100 avant de révéler les variantes.

C’est assez pour comprendre le lab depuis cette note. Pour relire les textes exacts, je renvoie plutôt vers le repo, notamment RESULTATS.md et prompts/scoring.md.

La règle que je garde

Quand un outil ajoute du contexte ou une couche de méthode, je ne veux pas conclure trop vite qu’il améliore le travail. Je veux le remettre sur le même input, scorer les sorties avant de révéler les variantes, puis regarder le coût. Dans ce lab précis, Stax mérite un second test. Il ne mérite pas encore une règle générale.

Est-ce que Stax améliore vraiment un process établi ?