Le system prompt de Claude Fable 5 annonce l’ère du harnais d’agent

Les notes officielles de Claude sur les system prompts publiées par Anthropic valent la lecture, non parce qu’elles révèlent une formule magique, mais parce qu’elles indiquent une direction produit. La page publie des instantanés datés des prompts centraux utilisés par l’interface web de Claude (claude.ai) et ses applications mobiles iOS/Android. Anthropic est explicite sur la limite : ces mises à jour ne s’appliquent pas à l’API Claude. Cette distinction compte. Il ne faut pas traiter cette page comme un prompt d’API, ni comme une autorisation de copier ou d’opérationnaliser un texte de prompt privé.

Ce que la page montre réellement, c’est l’évolution régulière de ce qu’un modèle de pointe est préparé à faire. Les prompts ressemblent de moins en moins à une fiche de personnalité de chatbot, et de plus en plus à un manuel d’exploitation pour agent : comment utiliser les outils, quand demander une clarification, comment citer, comment gérer les fichiers, comment se comporter près des limites de sécurité, comment se remettre de l’incertitude, et comment travailler à l’intérieur d’une surface produit.

Illustration éditoriale d’un manuel d’exploitation se transformant en voies de workflow pour agents

Figure 1 : la tendance des system prompts va de « répondre à l’utilisateur » vers « opérer en sécurité dans un établi de travail ».

Il faut utiliser le nom officiel Claude Fable 5. Son identifiant de modèle API est claude-fable-5. Anthropic parle aussi de Claude Mythos 5 (claude-mythos-5), mais les deux ne doivent pas être fusionnés à la légère. Claude Fable 5 est le modèle généralement disponible ; Mythos 5 a une disponibilité restreinte. Pour cet article, l’essentiel n’est pas le marketing du modèle. C’est que le plus récent prompt de l’interface de chat Claude ressemble à un panneau indicateur d’un changement plus large : le modèle est appelé à faire partie d’un harnais.

De l’assistant amélioré au manuel d’exploitation

Une bonne façon de lire la progression d’Opus à Fable consiste à y voir une évolution de l’environnement d’exécution attendu.

Cette progression est subtile mais importante. Les prompts d’assistant plus anciens portaient surtout sur la qualité de réponse : être utile, sûr, exact, suivre l’intention de l’utilisateur. Le motif plus récent concerne l’exécution du travail. Il suppose que Claude peut opérer dans un lieu où des outils existent, où les fichiers ont un état, où l’historique compte, où les citations doivent être maniées avec soin, et où certaines actions exigent un refus ou une approbation.

C’est exactement ce qui se produit lorsque l’IA passe du statut de « partenaire de conversation » à celui de « participant au travail ». Un partenaire de conversation peut répondre à une question et disparaître. Un participant au travail a besoin d’un bureau, d’une mémoire, d’un calendrier, d’un classeur, d’une manière de demander la permission, d’un endroit où laisser les livrables, et d’un moyen pour les humains d’auditer ce qui s’est passé.

Le changement entre agir et clarifier

L’un des changements les plus significatifs dans la direction d’Opus 4.7 concerne l’équilibre entre agir et clarifier. Beaucoup de workflows IA précoces échouaient de manière banale : le modèle demandait une clarification même lorsque l’étape suivante était évidente. Un utilisateur pouvait dire : « Rédige un plan de lancement à partir de ces notes », et l’assistant s’arrêtait pour demander le ton, l’audience ou le calendrier avant de produire quoi que ce soit d’utile.

La clarification reste nécessaire. Si une décision modifie le périmètre, le risque, le coût, l’exposition juridique ou une action externe, le modèle doit demander. Mais si le détail manquant est mineur, réversible ou inférable, un agent compétent doit avancer avec une hypothèse et l’indiquer clairement.

Cela ressemble à un conseil d’écriture, mais c’est en réalité du design de harnais. Le bon environnement doit laisser le modèle avancer dans les phases à faible risque, tout en s’arrêtant aux points de contrôle à risque élevé. Par exemple :

• Rédiger le plan maintenant, mais demander avant de l’envoyer aux clients.
• Inspecter le dépôt maintenant, mais demander avant de modifier des fichiers.
• Collecter les sources publiques maintenant, mais signaler les affirmations incertaines avant publication.
• Préparer une proposition de migration de base de données maintenant, mais exiger une approbation avant exécution.

Une fenêtre de chat peut exprimer cette politique en mots. Un harnais peut l’imposer dans le workflow.

Le changement vers la découverte des outils

La direction d’Opus 4.8 souligne un autre point : le modèle doit découvrir son environnement avant de renoncer. Si un navigateur, un lecteur de fichiers, un outil de tableur, un parseur PDF, un exécuteur de code ou un analyseur d’images est disponible, le modèle doit utiliser cette surface disponible au lieu de faire comme si la conversation était tout ce qu’il possède.

Cela change la définition de « l’intelligence ». Un modèle qui dit « je ne peux pas accéder au fichier » peut avoir raison dans une interface et tort dans une autre. La capacité pratique du modèle est désormais la somme de :

1. sa capacité de raisonnement,
2. les outils qui lui sont exposés,
3. les permissions accordées à ces outils,
4. l’état préservé d’une étape à l’autre,
5. la surface Artifact où les résultats peuvent être inspectés.

Voilà pourquoi l’expression agent harness compte. Le harnais n’est pas décoratif. C’est le système qui donne au modèle des yeux, des mains, de la mémoire, des limites et des canaux de sortie. Sans lui, même un modèle puissant peut devenir un passager anormalement éloquent dans une petite boîte de chat.

Frise dessinée à la main allant du comportement d’assistant de chat au manuel complet d’exploitation d’agent

Figure 2 : l’évolution des prompts pointe de l’assistance enrichie vers l’opération structurée : agir, découvrir les outils, préserver l’état et produire des Artifacts.

Pourquoi l’ère du harnais n’est pas seulement un « meilleur chat »

Le changement industriel important n’est pas que les modèles puissent écrire des réponses plus longues. C’est qu’on attend de plus en plus d’eux qu’ils participent à des boucles de travail plus longues. Une vraie boucle possède un état et un risque.

Prenons une tâche de code. L’utilisateur n’a pas besoin d’un paragraphe affirmant que le bug est corrigé. Il a besoin d’un patch, de sorties de tests, d’un résumé des fichiers modifiés et d’une note de revue. Prenons un briefing marché. L’utilisateur n’a pas besoin d’une synthèse confiante sans traçabilité. Il a besoin de sources datées, de citations, des écarts avec le rapport précédent, et d’un endroit où mettre à jour le briefing la semaine suivante. Prenons des opérations au navigateur. L’utilisateur n’a pas besoin d’une promesse selon laquelle un rapport a été téléchargé. Il a besoin du fichier, du dossier, d’une liste d’exceptions, et d’un enregistrement des étapes automatisées par rapport à celles traitées manuellement.

Une interface de chat unique peine à faire cela, parce qu’elle manque de plusieurs éléments dont le travail a besoin :

• État externe : qu’est-ce qui a déjà été lu, modifié, téléchargé ou décidé ?
• Points de contrôle par étape : où le travail doit-il s’arrêter pour approbation ou réorientation ?
• Limites de permission : quelles actions sont en lecture seule, réversibles, visibles à l’extérieur, destructrices ou coûteuses ?
• Reprise : si la tâche échoue à mi-chemin, peut-elle reprendre sans redémarrer à l’aveugle ?
• Cycle de vie des Artifacts : où vit le résultat final après que le chat a défilé ?
• Isolation parallèle : recherche, rédaction, test et revue peuvent-ils se dérouler dans des flux séparés sans se polluer ?
• Observabilité : un humain peut-il inspecter les sources, les actions, les coûts, les échecs et les hypothèses ?

Ce ne sont pas des détails de prompt engineering. Ce sont des détails de surface d’exploitation.

Comment MCPlato porte cette tendance

MCPlato se comprend mieux comme un espace de travail IA et une surface d’exploitation pour agents, pas simplement comme une autre boîte de réponse. Son vocabulaire produit correspond naturellement à la direction suggérée par les system prompts plus récents de Claude.

Sprite est le coordinateur. Lorsqu’une tâche comporte plusieurs phases ou spécialistes, un Sprite peut décomposer le travail, déléguer à des sessions, suivre l’avancement et rassembler les morceaux. C’est important, car les longues tâches tiennent rarement dans une seule chaîne de pensée ininterrompue.

Wand est un workflow packagé avec état. Au lieu de demander à une IA d’improviser le même processus à chaque fois, un Wand peut définir des phases, des portes, des ressources cadrées et les Artifacts attendus. Le résultat ressemble davantage à une application de travail répétable qu’à un modèle de prompt.

Artifact est le point d’arrivée durable. La sortie ne doit pas rester piégée dans un mur de texte de chat. Elle doit devenir un rapport, un patch, une présentation, un tableur, un dossier, une note de décision, un dossier QA ou un autre objet inspectable.

Skill et Distill Skill préservent le savoir-faire. Quand un workflow fonctionne, les parties réutilisables doivent pouvoir être rappelées. C’est ainsi qu’une équipe passe de prompts héroïques isolés à une pratique opérationnelle partagée.

ClawMode et Scheduled Tasks prolongent le travail dans le temps. Certaines tâches utiles ne sont pas immédiates : un briefing de recherche hebdomadaire, un scan nocturne de dépôt, une pipeline de contenu récurrente, ou un suivi lorsque de nouvelles informations apparaissent.

Les portes de permission et d’approbation bornent l’autonomie. MCPlato ne doit pas être présenté comme une automatisation aveugle. Le meilleur principe est l’autonomie contrôlée : laisser l’IA avancer quand l’action est à faible risque, et demander une approbation humaine lorsque l’action modifie des fichiers, envoie des messages, touche des systèmes externes ou crée un risque métier.

Channels et IM bridges rendent l’interaction asynchrone. Un utilisateur doit pouvoir déléguer une tâche depuis un chat d’équipe, recevoir des mises à jour d’avancement et examiner l’Artifact final sans surveiller une fenêtre de chat au premier plan.

L’état de workspace local-first garde les matériaux, l’état et les sorties proches du travail de l’utilisateur. Cela ne supprime pas toutes les préoccupations de confidentialité ou de sécurité, mais cela change la posture : le workspace devient l’endroit où le contexte est organisé, revu et gouverné.

En bref, MCPlato donne aux modèles le type d’environnement que leurs nouvelles instructions d’exploitation supposent de plus en plus : outils, fichiers, mémoire, permissions, phases, Artifacts et points de contrôle humains.

Illustration éditoriale plate d’un harnais de workspace avec Artifacts, plannings, approbations et voies de sessions

Figure 3 : un harnais transforme la capacité du modèle en boucles de travail observables, permissionnées et centrées sur les Artifacts.

Quatre exemples concrets

1. D’une issue de code au patch, puis à l’Artifact QA

Un utilisateur dépose une issue GitHub dans MCPlato et demande un correctif. Dans un flux limité au chat, l’assistant peut sauter directement vers des suggestions. Dans un flux avec harnais, la tâche devient un travail par étapes :

1. lire l’issue et le contexte du dépôt,
2. rédiger un plan au périmètre limité,
3. demander avant de modifier si le changement est risqué,
4. produire le patch,
5. exécuter les vérifications convenues,
6. produire un Artifact QA avec les fichiers modifiés, les sorties de tests, les risques non résolus et les notes de revue.

Le comportement de Claude entre action et clarification s’y prête bien. L’agent ne doit pas poser de questions inutiles avant d’avoir lu l’issue, mais il doit s’arrêter avant des changements larges ou destructeurs.

2. Briefing de recherche planifié avec citations

Un briefing de recherche hebdomadaire n’est pas une réponse ponctuelle. C’est une boucle récurrente : collecter des sources approuvées, dédupliquer, comparer à la semaine précédente, résumer les changements, citer chaque affirmation concrète et livrer le rapport. Les Scheduled Tasks et Artifacts de MCPlato rendent la sortie persistante ; les channels rendent la livraison asynchrone ; les Skills rendent le format réutilisable.

L’instruction au niveau du prompt de citer les sources devient plus précieuse lorsque le workspace peut conserver ensemble la liste des sources et l’Artifact de briefing.

3. Workflow navigateur et documents

Imaginez une équipe finance qui doit télécharger des rapports depuis un portail web, les combiner avec des tableurs et produire un résumé mensuel. Un bon agent ne doit pas prétendre avoir un accès universel à tous les sites. Il doit respecter les limites de connexion, demander à l’utilisateur de gérer la MFA, découvrir s’il existe un export ou une API, automatiser seulement les étapes approuvées et répétables, valider le nombre de fichiers et produire un rapport d’exceptions.

C’est la différence entre « l’IA peut utiliser un navigateur » et « l’IA peut opérer dans une boucle contrôlée navigateur/documents ».

4. Approbation d’actions risquées

Supposons qu’un agent rédige un e-mail destiné aux clients, prépare une commande qui modifie des données de production, ou propose de supprimer un dossier. Le modèle peut comprendre l’instruction, mais comprendre n’est pas avoir l’autorité. Un harnais doit convertir cette étape en point d’approbation : montrer l’action prévue, l’effet attendu, le plan de retour arrière et les preuves, puis attendre.

C’est là que sécurité et productivité se renforcent. L’utilisateur n’a pas besoin de ralentir chaque étape en lecture seule. Il a besoin d’une porte claire avant une action irréversible ou visible à l’extérieur.

Ce que cela signifie pour les builders

Pour les builders de produits IA, les notes de version des system prompts de Claude sont un signal de design utile. Ne demandez pas seulement : « Quel modèle est le plus intelligent ? » Demandez aussi :

• Dans quel environnement le modèle pense-t-il opérer ?
• Le produit peut-il exposer des outils sans brouiller les permissions ?
• Le workflow peut-il continuer dans le temps sans perdre son état ?
• L’utilisateur peut-il inspecter ce qui s’est passé ?
• Le résultat final peut-il vivre comme un Artifact, et non comme une transcription ?
• Le système peut-il s’arrêter aux bons moments, au lieu de trop demander ou d’agir trop librement ?

La réponse ne viendra pas d’un system prompt plus long à lui seul. Un prompt peut décrire un comportement, mais le produit doit fournir la surface qui rend ce comportement fiable.

Voilà l’ère du harnais : les modèles deviennent plus capables, mais leur capacité ne devient utile que lorsqu’elle est entourée d’état, d’outils, de reprise, d’approbations et d’Artifacts.

Conclusion

Le snapshot du system prompt de Claude Fable 5 est intéressant parce qu’il pointe au-delà de la capacité du modèle. Il montre la forme de l’environnement que les modèles modernes sont préparés à habiter. La frontière n’est plus seulement un « meilleur chat ». C’est le travail d’agent : avec état, conscient des outils, soumis à permissions, attentif aux citations, récupérable et centré sur les Artifacts.

MCPlato est construit pour cette direction. La coordination par Sprite, les Wands, les Artifacts, les Skills réutilisables, le travail planifié, les channels, l’état de workspace local-first et les portes d’approbation ne sont pas des décorations autour d’un modèle. Ce sont la surface d’exploitation qui permet à un modèle puissant de devenir un participant utile au vrai travail.

Le modèle reste le moteur. Le harnais transforme ce moteur en véhicule que les gens peuvent conduire, inspecter, réparer et croire digne de confiance.

Références

1. Anthropic docs, System Prompts release notes.
2. Anthropic docs, Introducing Claude Fable 5 and Claude Mythos 5.