Que révèle le system prompt Claude Fable 5 ?

Le system prompt Claude Fable 5 montre surtout une chose simple : le comportement d’un assistant IA est très cadré avant même votre première question. Refus, ton, mémoire, outils, sujets sensibles… on voit moins une magie noire qu’une grosse couche de règles produit.

C’est quoi un system prompt ?

Un system prompt, c’est l’instruction de plus haut niveau ajoutée avant la conversation pour orienter le comportement du modèle.

Quand je discute avec un assistant IA, je ne parle pas à un modèle “nu”. Il y a déjà des consignes au-dessus de ma demande. Ces consignes peuvent définir le ton, les limites, les priorités, les sujets à refuser, la manière d’utiliser des outils, ou encore certaines règles de sécurité.

Dit simplement, le modèle a appris énormément de choses pendant son entraînement. Il sait rédiger, raisonner, résumer, coder, comparer, expliquer. Mais dans un produit réel, son comportement final dépend aussi d’une couche d’instructions très concrètes. Le modèle sait conduire. Le system prompt lui donne le code de la route du service.

Chez Anthropic, ce n’est pas une idée sortie de nulle part. Les documents publics expliquent déjà que Claude peut être guidé par des instructions système, et que les messages de plus haut niveau passent avant les demandes utilisateur. C’est important de le dire proprement. Ici, quand on parle du system prompt Claude Fable 5, on parle d’une copie publique non officielle, intéressante à analyser, mais à ne pas confondre avec une documentation produit validée par Anthropic.

La hiérarchie ressemble souvent à ça :

Niveau	Rôle
Instruction système	Fixe les règles principales du comportement.
Instruction développeur ou produit	Ajoute des règles liées à l’application, aux outils, au contexte métier.
Demande utilisateur	Exprime ce que vous voulez obtenir dans la conversation.

Ce point est très concret pour les équipes business. Quand un assistant refuse, reformule, évite un sujet ou propose une alternative, ce n’est pas forcément une décision mystérieuse. C’est souvent la conséquence d’une hiérarchie d’instructions. Votre prompt utilisateur compte, oui. Mais il n’est pas seul à bord.

En entreprise, je vois souvent des équipes penser que tout se joue dans “le bon prompt”. En vrai, la qualité vient surtout de la structure globale autour du modèle : les règles, les exemples, les garde-fous, les données disponibles, les outils autorisés. Le prompt utilisateur, c’est la partie visible. Le system prompt, c’est souvent ce qui tient la baraque.

D’où vient cette copie publique ?

La réponse courte, c’est que cette copie viendrait d’un dépôt public de prompts système fuités. Et d’après ce qui circule, elle serait plutôt issue d’une extraction par ingénierie de prompt qu’un piratage démontré. C’est une nuance importante, parce qu’on ne parle pas du tout du même niveau de preuve.

Une fuite, c’est quand un document interne sort de son contexte et devient public. Une exfiltration par prompting, c’est quand quelqu’un pousse le modèle à révéler une partie de ses consignes, souvent via prompt injection ou prompt extraction. Un hack, lui, implique un accès non autorisé à un système, un compte, une base, une infra. Là, à ma connaissance, rien ne permet de dire qu’il y a eu hack. Et je préfère être carré là-dessus.

Le gros piège, avec ce genre de copie, c’est de la lire comme si c’était un PDF officiel signé Anthropic. Ce n’est pas le cas. Une extraction peut être partielle, modifiée, reconstruite, mélangée avec d’autres versions, ou juste datée. J’ai déjà vu ça chez un client qui auditait des prompts “récupérés” sur un outil interne. Une partie était vraie, une autre venait d’anciens tests, et personne ne savait vraiment où commençait la version de prod.

Ce que cette copie prétend contenir, c’est un très long prompt système, environ 3 826 lignes, placé avant les conversations utilisateur. On y trouverait des sections sur le comportement de l’assistant, la mémoire, les outils, les refus, les règles de sécurité et les limites à respecter. Et cette longueur change pas mal la lecture qu’on a d’un assistant IA. On n’est pas juste face à une “personnalité”. On est face à une configuration produit très détaillée, presque un cahier des charges opérationnel.

Les éléments associés à Claude Fable 5 doivent être lus avec la même prudence :

• Lancement indiqué : 9 juin 2026, selon la copie publique.
• Classe : Mythos, avec un positionnement présenté comme supérieur à Opus.
• Architecture : Partage de poids avec Claude Mythos 5, toujours d’après le document.
• Contexte : 1M tokens annoncés, ce qui veut dire une très grande fenêtre de texte exploitable.
• Knowledge cutoff : Janvier 2026, donc limite supposée des connaissances intégrées.
• Tarifs : Mentionnés rapidement dans la copie, mais à ne pas traiter comme des prix officiels.

Pour moi, ce type de document reste utile. Il aide à comprendre les patterns de conception des assistants IA modernes : sécurité, refus, style, outils, mémoire, priorités internes. Mais il faut séparer l’analyse technique de la certitude documentaire. Intéressant, oui. Exploitable comme grille de lecture, oui. À citer comme vérité produit officielle sans recoupement Anthropic, non.

Comment le prompt est-il structuré ?

Quand je regarde ce prompt, je ne vois pas juste une “personnalité” posée au début d’un modèle. Je vois plutôt un gros fichier de configuration annoté, avec du XML imbriqué, donc des balises qui organisent l’information en blocs, un peu comme des dossiers dans des dossiers.

La copie semble tourner autour d’une zone principale appelée claude_behavior. C’est là que se joue le comportement de Claude : comment il parle, comment il nuance, comment il refuse, comment il prend soin de l’utilisateur sans devenir paternaliste. À côté, la table des matières annonce d’autres blocs autour des fonctionnalités : mémoire, outils, recherche, connecteurs, et mécanique agentique. Agentique, ici, veut dire que l’assistant peut potentiellement enchaîner des actions avec des outils, pas seulement répondre avec du texte.

Je reste prudent là-dessus. Toutes les parties ne sont pas disponibles dans l’extrait analysé. Donc je ne vais pas inventer ce qu’il y aurait dans les sections absentes ou tronquées. On sait surtout que l’architecture les prévoit.

La logique produit est assez claire. D’un côté, le prompt définit la manière d’être de l’assistant. De l’autre, il prépare l’usage de capacités externes. Mais ces capacités ne sont pas libres. Elles sont encadrées par des règles, des conditions, des garde-fous. C’est exactement ce que je vois chez des clients quand on passe d’un simple chatbot à un assistant connecté à des outils métier. Le vrai sujet devient vite : “Qu’est-ce qu’il a le droit de faire, quand, et avec quel niveau de certitude ?”

Un détail étrange ressort dans la copie : la règle qui dit de ne jamais émettre de blocs voice_note. Je n’irais pas trop loin dans l’interprétation. Mais ça montre bien une chose : le system prompt ne sert pas seulement à donner un ton. Il sert aussi à empêcher certains formats de sortie ou certains comportements indésirables.

Le poids des limites est frappant. Dans ce type de prompt, il y a souvent plus de règles sur ce qu’il ne faut pas faire que sur ce qu’il faut faire. C’est normal pour un produit grand public. Le risque ne vient pas d’une réponse banale. Il vient d’une réponse dangereuse, illégale, trompeuse, ou impossible à assumer.

Bloc	Rôle	Ce que ça change pour l’utilisateur
claude_behavior	Définit le ton, les refus, les nuances et la posture générale	L’assistant paraît plus stable, plus prudent, moins improvisé
Mémoire	Annonce une gestion possible des informations retenues	L’expérience peut devenir plus personnalisée, si la fonction est disponible
Outils et recherche	Prépare l’accès à des capacités externes	Les réponses peuvent s’appuyer sur autre chose que le modèle seul
Connecteurs	Prévoit des liens avec des services ou données externes	L’assistant peut potentiellement agir dans un environnement plus large
Limites	Encadre les formats, les refus et les usages sensibles	L’utilisateur obtient un assistant plus sûr, mais parfois plus contraint

Pourquoi les refus sont-ils si cadrés ?

Les refus sont très cadrés parce que le prompt cherche à bloquer les aides concrètes qui peuvent produire un dommage réel, sans interdire toutes les discussions factuelles. C’est ça le point important. Claude Fable 5 ne dit pas “on ne parle jamais de sujets sensibles”. Il dit plutôt “on peut en parler, mais on ne donne pas le mode d’emploi”.

Dans la copie du system prompt, les lignes rouges sont assez nettes. On retrouve toujours la même logique : laisser passer l’explication générale, couper dès que ça devient actionnable.

• Armes et explosifs : Le modèle peut donner du contexte historique, juridique ou scientifique général. Mais il ne doit pas fournir de plan, de recette, de dosage, de méthode de fabrication ou d’optimisation.
• Drogues illicites : Il peut parler des risques, des effets ou de prévention. Mais il ne doit pas donner de protocole de synthèse, de dose, de purification ou d’instructions pratiques.
• Code malveillant : Il peut expliquer un concept de cybersécurité à haut niveau. Mais il ne doit pas aider à produire un exploit, contourner une protection ou automatiser une attaque.
• Citations de personnes réelles : Il ne doit pas inventer une phrase et l’attribuer à quelqu’un. Ça paraît basique, mais c’est essentiel pour éviter la désinformation proprement emballée.

Le détail intéressant, c’est que le refus ne doit pas trop expliquer comment il a détecté le problème. Il doit énoncer le principe, pas ouvrir le capot. Parce qu’un refus trop détaillé peut devenir un guide de contournement. Rien de dramatique là-dedans, c’est juste du bon sens produit. Si je dis exactement quelle formulation déclenche la barrière, je donne aussi des pistes pour l’éviter.

En entreprise, c’est là que ça devient très concret. Quand on met une IA dans un workflow support, marketing, data ou automatisation, on ne cherche pas seulement un modèle “intelligent”. On cherche un modèle prévisible quand la demande devient floue, agressive, hors périmètre ou juridiquement sensible. Chez des clients, je vois souvent le même scénario : les premiers tests marchent très bien sur les cas propres, puis les vrais sujets arrivent avec les demandes ambiguës. C’est là que les garde-fous font la différence.

Un bon refus ne doit pas être sec non plus. Il peut rediriger vers une information sûre, proposer une alternative légale, ou expliquer la limite sans humilier l’utilisateur. Pour moi, c’est une compétence produit autant qu’une règle de sécurité.

Que change le devoir de soin ?

Le devoir de soin change quelque chose de très concret : l’assistant ne traite plus tous les sujets comme de simples demandes d’information. Sur les sujets personnels sensibles, surtout la santé mentale, l’automutilation, les troubles alimentaires et la dépendance, il doit changer de posture.

Dans la copie du system prompt Claude Fable 5, cette partie semble assez volumineuse. On sent que ce n’est pas une note en bas de page. L’assistant ne doit pas poser de diagnostic non sollicité, par exemple décider qu’un utilisateur est dépressif, anorexique ou addict sans qu’on lui demande une évaluation. Il ne doit pas donner de méthodes ou de moyens d’automutilation. Il ne doit pas fournir certains chiffrages dangereux non plus, comme des calories ou des calculs qui pourraient renforcer un trouble alimentaire. Sur la dépendance, je reste prudent, parce que la partie disponible semble tronquée dans la copie. Donc je n’irais pas inventer des détails.

L’équilibre recherché est intéressant. Il ne s’agit pas d’abandonner l’utilisateur avec un refus froid. Mais il ne faut pas non plus renforcer un comportement dangereux. Un assistant peut écouter, reformuler, reconnaître la difficulté, encourager à parler à une personne réelle, proposer une alternative plus sûre. Il peut dire en gros : “Je peux rester avec vous sur ce sujet, mais je ne vais pas vous aider à optimiser le risque.”

Pour moi, c’est là que ça devient très important avec les agents IA et l’automatisation low code. Un chatbot qui répond mal, c’est déjà un problème. Un agent connecté à des emails, des bases clients, un CRM ou des workflows peut amplifier l’erreur. Il peut envoyer, classer, déclencher, relancer, créer des tâches. Bref, il ne parle plus seulement, il agit.

J’ai déjà vu chez des clients des automatisations très propres techniquement, mais avec des règles produit trop floues. Le vrai sujet n’est pas seulement “quel modèle choisir ?”. C’est surtout : quelles instructions, quelles priorités, quels garde-fous, quels outils, quelle mémoire, quels refus propres on met autour.

Si le system prompt Claude Fable 5 est authentique, ou même simplement proche d’une configuration réelle, il montre une tendance claire. L’avenir des assistants IA se joue dans cette couche d’orchestration, pas seulement dans le modèle lui-même.

Alors, qu’est-ce qu’on doit retenir de ce prompt ?

Ce system prompt Claude Fable 5 montre une chose que je trouve très saine à rappeler : une IA utile n’est pas juste un gros modèle. C’est un modèle entouré de règles, de limites, d’outils et de choix produit. La copie publique doit rester prise avec prudence, parce qu’elle n’est pas une version officielle confirmée. Mais elle donne une bonne grille de lecture. Les refus, la mémoire, le ton, le devoir de soin, tout ça se conçoit. Pour vous, le bénéfice est clair : mieux comprendre comment cadrer vos propres assistants IA avant de les brancher à votre business.

FAQ

• Qu’est-ce qu’un system prompt dans Claude ?
  Un system prompt est une instruction de niveau supérieur donnée au modèle avant la conversation. Il cadre le comportement de l’assistant, son ton, ses limites, ses refus et parfois l’usage de ses outils. La demande utilisateur arrive après, donc elle ne peut pas toujours écraser ces règles.
• Le system prompt Claude Fable 5 est-il officiel ?
  Non, il faut rester prudent. La copie publique décrite est présentée comme extraite par ingénierie de prompt, pas comme un document officiel publié par Anthropic. Elle peut être utile pour analyser une logique produit, mais elle ne doit pas être traitée comme une preuve officielle sans confirmation.
• Pourquoi un assistant IA refuse certaines demandes ?
  Un assistant refuse quand une demande franchit des limites prévues dans ses règles système ou ses mécanismes de sécurité. Les exemples classiques concernent les armes, les drogues illicites, le code malveillant, l’automutilation ou les fausses citations de personnes réelles. Le but est d’éviter une aide concrète à un dommage réel.
• Pourquoi le prompt contient autant de règles négatives ?
  Parce qu’un assistant grand public doit surtout être fiable dans les cas limites. Les réponses normales sont faciles à gérer. Les vrais risques arrivent avec les demandes ambiguës, dangereuses, illégales ou manipulatrices. Les règles négatives servent à rendre le comportement plus prévisible.
• Que peut-on apprendre pour créer ses propres agents IA ?
  On apprend qu’il ne suffit pas de choisir un bon modèle. Il faut écrire des règles claires, hiérarchiser les instructions, définir les refus, limiter les outils, prévoir les cas sensibles et tester les scénarios tordus. C’est cette couche d’orchestration qui rend un agent IA exploitable dans un business.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation no/low code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent mettre de l’IA dans leurs process sans perdre le contrôle sur la donnée, les règles métier et la qualité des réponses. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer vos agents IA ou vos automatisations, contactez-moi.