Workbench Claude ferme le 17 août 2026 : comment migrer ses prompts à temps

Anthropic met en retrait le Workbench historique le 17 août 2026. Concrètement : l'interface de test de prompts que tu connais sur platform.claude.com/workbench (ex-console.anthropic.com/workbench) devient inaccessible ce jour-là. L'API Messages continue de tourner normalement, tes clés restent valides, ta facturation ne bouge pas. Ce qui disparaît, c'est l'endroit où tu as sauvegardé tes prompts, tes variables et tes évaluations depuis parfois deux ans.

Il y a un nouveau Workbench (le playground sur platform.claude.com/playground), mais Anthropic est explicite dans ses release notes : les prompts sauvegardés, variables et evals de l'ancien Workbench ne sont pas migrés automatiquement. C'est un système séparé. Si tu ne fais rien avant le 17 août, tes prompts sauvegardés partent avec le vieux Workbench. Cet article te donne la méthode d'export et un workflow de remplacement propre. Si tu débutes complètement avec Claude, commence plutôt par le guide complet pour apprendre Claude avant de plonger dans ce qui suit.

Ce qui ferme exactement le 17 août 2026

Le périmètre est net, il est publié dans les release notes officielles d'Anthropic (entrée du 17 juillet 2026). L'ancien Workbench est mis en sunset : accès coupé le 17 août 2026. Trois endpoints d'API expérimentaux disparaissent à la même date : /v1/experimental/generate_prompt, /v1/experimental/improve_prompt et /v1/experimental/templatize_prompt. Ces trois-là servaient à générer, améliorer ou transformer un prompt en template depuis l'API. Après le 17 août, tout appel renvoie une erreur.

Ce qui ne bouge pas : l'API Messages standard, tes clés API, la Console (facturation, usage, logs), les Projects et Artifacts côté claude.ai, et bien sûr Claude Code (rien à voir, c'est un autre produit). La confusion classique à éviter : le Workbench, ce n'est pas Claude Code. Le premier est une interface web de test de prompts dans la Console, le second est l'agent CLI. La fermeture ne concerne que le premier.

Anthropic affiche une bannière d'avertissement dans l'ancien Workbench et recommande d'exporter depuis les paramètres de l'organisation avant la date. Aucun export bulk officiel n'est documenté à ce jour dans les release notes. Il faut donc récupérer prompt par prompt, ou écrire un petit script si tu as beaucoup de comptes.

Inventaire : lister ce que tu dois récupérer

Avant d'exporter quoi que ce soit, fais l'audit. Ouvre le Workbench, note ce qui existe. Un tableau simple suffit, tu peux le tenir dans un Google Sheet ou un fichier Markdown.

Pour chaque ligne, note aussi les réglages : température, max_tokens, stop_sequences, top_p, et si tu as configuré du tool use ou du structured output. Ces paramètres font partie du prompt, pas de simples métadonnées.

Point important sur Sonnet 5 : si certains de tes prompts tournaient encore sur Sonnet 4.6, sache que le modèle par défaut a changé le 30 juin 2026. Sonnet 5 utilise un tokenizer différent qui produit en moyenne environ 30 % de tokens en plus pour le même texte (chiffre officiel d'Anthropic, variable selon le contenu). Ce n'est pas lié à la fermeture du Workbench, mais si tu profites de la migration pour rejouer tes tests, vérifie tes consommations. La documentation de l'API Anthropic détaille l'endpoint de comptage de tokens pour mesurer sur tes propres charges.

Cas particulier : les prompts déjà en production dans un outil tiers (n8n, Zapier, ton backend). Le code source de ces prompts est safe, tu ne les perds pas. Mais la version de référence stockée dans le Workbench (celle où tu itères) va disparaître. C'est elle qu'il faut archiver.

Exporter ses prompts du Workbench, méthode manuelle

Sans export bulk, c'est du copier-coller structuré. La bonne nouvelle : tu ne le fais qu'une fois. Ouvre chaque prompt sauvegardé, récupère les trois blocs (system, user, assistant si tu as des exemples few-shot) et pose-les dans un fichier versionnable.

Format recommandé : un .md par prompt avec front-matter YAML. Ça se lit dans n'importe quel éditeur, ça se diff dans Git, ça se parse dans un script.

---
name: extract-invoice-v3
model: claude-sonnet-5
temperature: 0.2
max_tokens: 2000
last_edited: 2026-05-12
author: julien
status: prod
---

## System
Tu es un extracteur de données de factures. Retourne un JSON strict
avec les champs : vendor, date, total_ht, tva, total_ttc.
Aucun texte hors du JSON.

## User (exemple)
{{invoice_text}}

## Assistant (exemple attendu)
{"vendor": "...", "date": "...", ...}

Range le tout dans un repo Git : prompts/[projet]/[nom].md. Un README.md à la racine avec l'index, un CHANGELOG.md pour tracer les versions. Si tu as 40 prompts répartis sur 5 projets, compte deux ou trois heures de boulot propre. C'est chiant, ça se fait en une matinée.

Pour les variables et exemples de test que tu avais renseignés dans le Workbench, crée un dossier tests/ à côté avec un fichier JSON ou YAML par cas. Ça deviendra la base de tes tests de non-régression.

Reproduire le workflow de test hors Workbench

Trois options selon ce que tu cherches. Aucune n'est parfaite, chacune couvre un besoin.

Option 1 : script Python direct. Le plus simple si tu es à l'aise en CLI. Une dizaine de lignes suffisent pour rejouer un prompt sur plusieurs inputs et logger les sorties. Tu charges le prompt depuis ton fichier .md, tu appelles l'API, tu compares.

import anthropic, frontmatter

client = anthropic.Anthropic()
prompt = frontmatter.load("prompts/extract-invoice-v3.md")

for test_input in open("tests/invoices.jsonl"):
    msg = client.messages.create(
        model=prompt["model"],
        max_tokens=prompt["max_tokens"],
        temperature=prompt["temperature"],
        system=prompt.content.split("## System")[1].split("##")[0],
        messages=[{"role": "user", "content": test_input}],
    )
    print(msg.content[0].text)

Option 2 : Promptfoo. Outil open source dédié à l'évaluation de prompts. Tu écris tes cas de test en YAML, tu lances promptfoo eval, tu obtiens un tableau HTML avec les diffs entre versions. Utile si tu veux comparer Sonnet 5 vs Opus 4.7 sur le même prompt, ou tester deux formulations concurrentes. C'est ce qui se rapproche le plus de l'expérience Workbench, avec en plus le versionning.

Option 3 : le nouveau playground. platform.claude.com/playground existe et permet de tester des prompts, mais sans reprise de tes anciennes données. Utile pour du test ponctuel, pas pour un workflow versionné. À voir comme un remplaçant de l'interface, pas de la méthode.

Pour les workflows plus poussés (multi-agents, chaînes d'outils, MCP), le playground ne suffira pas. Regarde plutôt du côté d'un serveur MCP qui charge tes prompts depuis ton repo Git, tu gardes une seule source de vérité entre tests et prod.

Versionner ses prompts comme du code

C'est là que la fermeture du Workbench devient une bonne nouvelle déguisée. Le Workbench, c'était une base de données propriétaire dans un fournisseur unique. En passant à Git, tu récupères l'historique complet, les diffs ligne à ligne, les branches pour tester une nouvelle formulation sans casser la prod, les pull requests pour faire relire un prompt par un collègue.

Structure de repo qui marche bien :

prompts/
  billing/
    extract-invoice-v3.md
    classify-expense.md
  support/
    rewrite-reply.md
    tag-ticket.md
tests/
  billing/
    invoices.jsonl
    expenses.jsonl
CHANGELOG.md
README.md

Tag les versions déployées en prod (git tag prompts-v1.2.0) pour pouvoir revenir en arrière si une nouvelle version dégrade la qualité. Ajoute un test de parité : rejoue les 10 mêmes inputs sur l'ancienne et la nouvelle version, compare les outputs. Ça prend cinq minutes à écrire et ça évite les régressions silencieuses.

Pour ceux qui automatisent déjà leur stack, cette structure s'intègre directement dans les scénarios n8n ou Zapier via un simple fetch du .md depuis GitHub. Le prompt devient une ressource externe, plus une chaîne codée en dur dans le workflow. Si le sujet t'intéresse, on creuse ça dans automatiser sa stack avec Claude et MCP.

Checklist de migration avant le 17 août 2026

À imprimer ou coller dans ton gestionnaire de tâches. Vise de finir deux à trois semaines avant la deadline, pas la veille : tu vas trouver des trucs à corriger en cours de route.

• Audit du compte : lister tous les prompts sauvegardés, par organisation si tu en as plusieurs.
• Prioriser : marquer prod / test / obsolète. Les obsolètes ne sont pas exportés, tu gagnes du temps.
• Créer le repo Git avec la structure prompts/ et tests/.
• Exporter chaque prompt en Markdown avec front-matter (modèle, température, max_tokens, date).
• Récupérer les variables et exemples de test dans tests/.
• Choisir un outil de test : script maison, Promptfoo, ou nouveau playground selon le besoin.
• Écrire un test de parité : même input, ancien Workbench vs API directe, comparer les outputs.
• Documenter le repo (README avec conventions, CHANGELOG initial).
• Prévenir l'équipe : où sont les prompts maintenant, comment proposer une modif.
• Archiver une capture d'écran de l'ancien Workbench par prompt critique, au cas où.

Un bon environnement de test de prompts, versionné et testable, c'est la base d'un travail sérieux avec Claude. Si tu construis un produit qui repose sur ces prompts et que tu veux passer du bricolage à quelque chose de solide, notre programme Construire votre produit IA en 5 semaines t'emmène de l'idée à une app Next.js déployée sur Vercel, avec une méthodologie de prompt engineering versionnée dès le premier jour.