WP-Bench : un benchmark officiel pour mesurer les IA sur WordPress (et pas sur du code générique)

On a tous eu ce moment : un modèle te sort une fonction PHP “presque” correcte, mais qui ignore une convention WordPress, oublie un nonce, mélange des APIs, ou invente un hook. Sur des benchmarks généralistes, ces écarts passent souvent sous le radar. C’est précisément l’idée derrière WP-Bench, le benchmark IA officiel orienté WordPress, disponible en open source : https://github.com/WordPress/wp-bench.

L’objectif est simple : évaluer des modèles de langage sur des tâches WordPress réelles, depuis la compréhension des concepts (APIs, coding standards, architecture de plugins, patterns de sécurité) jusqu’à la capacité à générer du code qui tourne réellement dans un environnement WordPress.

Pourquoi un benchmark WordPress change la donne

WordPress alimente une part énorme du web, mais l’évaluation des modèles reste très souvent centrée sur des exercices de programmation génériques. Résultat : un modèle peut sembler excellent sur du “toy code” et se révéler fragile dès qu’on touche aux réalités WordPress (hooks, WP_Query, permissions/capabilities, internationalisation, escaping, etc.).

• Mieux choisir ses outils : si tu développes des plugins “AI-powered” ou si tu relies un coding assistant à ton workflow, comparer les modèles sur des cas WordPress permet de prendre des décisions plus rationnelles.
• Mettre WordPress sur la carte des labos IA : l’ambition affichée est de faire de WP-Bench une référence utilisée en pré-release par les fournisseurs (OpenAI, Anthropic, Google, etc.), pour que la performance WordPress ne soit pas un détail ajouté à la fin.
• Aller vers un leaderboard open source : l’équipe travaille vers un classement public des résultats pour aider la communauté à comparer les modèles sur des tâches WordPress, de façon transparente.

Deux axes d’évaluation : “Knowledge” et “Execution”

WP-Bench structure l’évaluation autour de deux dimensions complémentaires.

1) Knowledge : vérifier la compréhension WordPress

Le volet Knowledge s’appuie sur des questions à choix multiple pour tester la compréhension de concepts WordPress : APIs, hooks, patterns de sécurité, coding standards… avec un accent sur des ajouts plus récents cités dans l’annonce, comme Abilities API et Interactivity API (des APIs modernes sur lesquelles les modèles peuvent être moins à l’aise).

2) Execution : juger du code qui tourne vraiment

Le volet Execution est le plus intéressant côté dev : on demande au modèle de générer du code, puis ce code est évalué par un runtime WordPress. Autrement dit, on ne note pas seulement “la forme” : on exécute, on vérifie, on fait remonter des erreurs et des assertions.

Comment WP-Bench note un modèle (le flux de correction)

Le mécanisme décrit est celui d’un harness (un orchestrateur) qui pilote le modèle, puis délègue la correction à WordPress lui-même.

1. Le harness envoie un prompt au modèle pour obtenir du code WordPress.
2. Le code généré est transmis au runtime WordPress via WP-CLI (outil en ligne de commande pour piloter WordPress).
3. Le runtime lance une analyse statique : syntaxe, standards, signaux sécurité.
4. Le code est exécuté dans un environnement isolé (sandbox) avec des assertions côté tests.
5. Le système renvoie un résultat en JSON : score + feedback détaillé.

Installation et exécution : démarrage rapide

WP-Bench se compose d’un outil Python (le harness) et d’un runtime WordPress (basé sur un projet wp-env côté Node). Le workflow se fait en quatre étapes : environnement Python, clés d’API, runtime WordPress, puis exécution du benchmark.

1) Installer le harness (Python)

python3 -m venv .venv && source .venv/bin/activate
pip install -e ./python

python3 -m venv .venv && source .venv/bin/activate
pip install -e ./python

2) Définir les clés des providers dans un fichier .env

WP-Bench peut appeler différents fournisseurs de modèles. La configuration se fait via un fichier .env.

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...

3) Démarrer le runtime WordPress (le “grader”)

cd runtime
npm install
npm start

cd runtime
npm install
npm start

4) Lancer le benchmark

cd ..
wp-bench run --config wp-bench.example.yaml

cd ..
wp-bench run --config wp-bench.example.yaml

Les résultats sont écrits dans output/results.json, avec des logs par test dans output/results.jsonl.

Comparer plusieurs modèles dans un seul run

Un point pratique : tu peux lancer une campagne multi-modèles en listant plusieurs entrées dans la config. Le harness les exécute séquentiellement et produit un tableau comparatif.

models:
  - name: gpt-4o
  - name: gpt-4o-mini
  - name: claude-sonnet-4-20250514
  - name: claude-opus-4-5-20251101
  - name: gemini/gemini-2.5-pro
  - name: gemini/gemini-2.5-flash

models:
  - name: gpt-4o
  - name: gpt-4o-mini
  - name: claude-sonnet-4-20250514
  - name: claude-opus-4-5-20251101
  - name: gemini/gemini-2.5-pro
  - name: gemini/gemini-2.5-flash

Les noms de modèles suivent les conventions de LiteLLM : https://docs.litellm.ai/docs/providers.

Configurer WP-Bench : dataset, grader et paramètres de run

La configuration se fait via un fichier YAML (à partir de wp-bench.example.yaml). Tu y définis notamment la suite de tests, le type de grader, et des options comme limit ou concurrency.

dataset:
  source: local              # 'local' or 'huggingface'
  name: wp-core-v1           # suite name

models:
  - name: gpt-4o

grader:
  kind: docker
  wp_env_dir: ./runtime      # path to wp-env project

run:
  suite: wp-core-v1
  limit: 10                  # limit tests (null = all)
  concurrency: 4

output:
  path: output/results.json
  jsonl_path: output/results.jsonl

dataset:
  source: local              # 'local' or 'huggingface'
  name: wp-core-v1           # suite name

models:
  - name: gpt-4o

grader:
  kind: docker
  wp_env_dir: ./runtime      # path to wp-env project

run:
  suite: wp-core-v1
  limit: 10                  # limit tests (null = all)
  concurrency: 4

output:
  path: output/results.json
  jsonl_path: output/results.jsonl

Options CLI utiles

wp-bench run --config wp-bench.yaml          # run with config file
wp-bench run --model-name gpt-4o --limit 5   # quick single-model test
wp-bench dry-run --config wp-bench.yaml      # validate config without calling models

wp-bench run --config wp-bench.yaml          # run with config file
wp-bench run --model-name gpt-4o --limit 5   # quick single-model test
wp-bench dry-run --config wp-bench.yaml      # validate config without calling models

Structure du dépôt : qui fait quoi ?

Le dépôt est organisé de façon assez lisible : une partie Python pour orchestrer, une partie runtime pour corriger, des datasets versionnés, et des notebooks pour analyser les résultats.

.
├── python/          # Benchmark harness (pip installable)
├── runtime/         # WordPress grader plugin + wp-env config
├── datasets/        # Test suites (local JSON + Hugging Face builder)
├── notebooks/       # Results visualization and reporting
└── output/          # Benchmark results (gitignored)

.
├── python/          # Benchmark harness (pip installable)
├── runtime/         # WordPress grader plugin + wp-env config
├── datasets/        # Test suites (local JSON + Hugging Face builder)
├── notebooks/       # Results visualization and reporting
└── output/          # Benchmark results (gitignored)

Suites de tests : Knowledge vs Execution, et wp-core-v1

Les suites de tests vivent dans datasets/suites/<suite-name>/ et se découpent en deux répertoires : execution/ pour les tâches de génération de code avec assertions, et knowledge/ pour les QCM.

• execution/ : tâches de code, assertions et catégories (un JSON par catégorie).
• knowledge/ : questions à choix multiple (un JSON par catégorie).

La suite par défaut, wp-core-v1, couvre notamment des APIs du core, des hooks, des opérations base de données et des patterns de sécurité.

Charger un dataset depuis Hugging Face

WP-Bench peut aussi charger une suite depuis Hugging Face via la config.

dataset:
  source: huggingface
  name: WordPress/wp-bench-v1

dataset:
  source: huggingface
  name: WordPress/wp-bench-v1

État actuel et limites connues (à garder en tête)

WP-Bench est annoncé comme une première version et il y a des limites assumées. C’est important si tu veux interpréter correctement les scores.

• Taille du dataset : la suite actuelle est encore petite ; il faudra plus de cas couvrant davantage d’APIs et de patterns WordPress pour une mesure “exhaustive”.
• Couverture des versions : la suite penche vers des fonctionnalités associées à WordPress 6.9 (Abilities API, Interactivity API). C’est en partie volontaire (les modèles y trébuchent davantage), mais ça peut biaiser les résultats car ces éléments sont postérieurs à l’entraînement de nombreux modèles.
• Saturation du benchmark : les premiers tests montrent des scores très élevés sur des notions WordPress plus anciennes, ce qui réduit le “signal”. Le défi est de construire des tests réellement discriminants, pas seulement des questions nouvelles.

En pratique : à quoi ça sert pour un dev WordPress ?

WP-Bench vise un usage très concret : quand tu relies un modèle à ton IDE, à un agent, ou à un plugin qui génère du code, tu veux savoir s’il gère correctement les fondamentaux WordPress (permissions, sécurité, conventions), mais aussi s’il sait produire du code exécutable sans “halluciner” des APIs.

Le fait d’avoir un grader basé sur un runtime WordPress, avec analyse statique et assertions, rend les résultats plus actionnables qu’un simple score textuel : tu peux mieux comprendre où ça casse (standards, sécurité, exécution) et pas uniquement que ça casse.

Ressources

• Dépôt GitHub WP-Bench : https://github.com/WordPress/wp-bench
• AI Building Blocks for WordPress : https://make.wordpress.org/ai/2025/07/17/ai-building-blocks/
• Canal Slack #core-ai : https://wordpress.slack.com/archives/C08TJ8BPULS