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

Le system prompt Claude Fable 5 montre comment un modèle est cadré avant même de répondre. On y voit ses règles, ses refus, son ton, ses garde-fous et son routage sur les sujets sensibles. C’est là que se joue une grosse partie du comportement réel.

C’est quoi un system prompt ?

Un system prompt, c’est la couche d’instructions placée avant les demandes utilisateur, celle qui donne au modèle ses priorités, son ton, ses limites et ses règles de sécurité.

Je le vois comme le cadrage de base du modèle. Pas juste une phrase cachée dans un coin. Une vraie configuration comportementale. C’est ce qui dit à l’IA “voilà comment tu dois te comporter”, avant même que vous lui posiez une question.

Cette couche passe avant les consignes applicatives classiques. Si votre application dit “réponds de façon commerciale”, mais que le system prompt impose “reste neutre, refuse les promesses non vérifiées, ne donne pas de conseil risqué”, le modèle va suivre cette hiérarchie. Il peut accepter, refuser, reformuler, ralentir une réponse, demander une précision. Et souvent, c’est là que tout se joue.

Pour Claude Fable 5, les éléments disponibles donnent surtout un cadre de configuration. Le modèle est décrit comme lancé le 9 juin 2026, classé Mythos-class, avec un très grand budget de contexte et un cutoff défini dans sa configuration. Le budget de contexte, c’est la quantité d’information que le modèle peut garder “sous les yeux” pendant une conversation ou une tâche. Le cutoff, c’est la date limite de connaissance intégrée dans la configuration. Je n’en déduis pas plus. Ces infos parlent du cadre, pas d’une liste magique de capacités.

Dans un usage business, c’est très concret. Quand une entreprise déploie un assistant IA pour le support, la vente, les RH ou l’analyse documentaire, le comportement ne dépend pas seulement du modèle choisi. Il dépend aussi des instructions système qui cadrent son rôle. J’ai souvent vu des équipes juger un modèle trop vite alors que le vrai problème venait du cadrage initial. Le modèle n’était pas “mauvais”. Il était juste mal briefé, ou briefé avec des règles contradictoires.

Élément	Rôle
System prompt	Définit le comportement de fond, les priorités, le ton, les limites et les règles de sécurité.
Prompt utilisateur	Exprime la demande immédiate, avec le contexte et l’objectif de la personne.
Règles applicatives	Ajoutent les consignes propres au produit, au métier ou au workflow.
Garde-fous	Empêchent certaines réponses, réduisent les risques et forcent parfois une reformulation ou un refus.

D’où vient cette fuite ?

Le fichier est présenté comme venant d’un dépôt public open source consacré à des system prompts révélés, et il s’agirait plutôt d’une extraction du prompt que d’un piratage au sens classique.

La nuance est importante. Un piratage, ça veut dire qu’un système a été compromis : accès non autorisé à un serveur, vol de fichiers, intrusion dans une base interne, ce genre de choses. Une extraction, c’est différent. On pousse le modèle, par conversation ou par manipulation de prompt, à révéler une partie de ses instructions internes. Je reste volontairement vague sur la méthode, parce que le sujet intéressant ici n’est pas “comment le refaire”, mais ce que ça nous apprend sur la conception du produit.

Dans ce cas, le fichier décrit correspondrait au prompt produit complet, pas à une version courte, marketing ou institutionnelle. C’est ce qui rend le document intéressant. On y voit une structure, des priorités, des garde-fous, des zones sensibles, des consignes de refus. Mais il faut garder la tête froide. Un contenu public permet d’analyser des choix de design, pas de prouver à 100 % chaque détail de l’implémentation interne. Une ligne peut être obsolète, reformulée, partielle, ou dépendre d’un contexte qu’on ne voit pas.

Pour les équipes IA, l’enjeu est assez clair. Une fuite de system prompt donne de la visibilité sur ce que le modèle essaie de protéger. Elle montre les sujets sensibles, les règles de comportement, les mécanismes de refus, parfois même les arbitrages entre utilité et sécurité. C’est précieux pour comprendre la philosophie du produit. Mais ça rappelle surtout une chose simple : les instructions cachées ne doivent jamais être considérées comme un vrai secret de sécurité.

Sur des projets d’automatisation IA, je pars toujours du principe qu’un prompt peut être testé, contourné ou exposé. Donc je mets les vrais contrôles côté architecture, données et permissions. Le prompt aide le modèle à bien se comporter. Il ne doit pas être la serrure de la maison.

Comment le prompt est structuré ?

Le prompt ressemble moins à une simple consigne en langage naturel qu’à une grosse configuration, structurée avec des blocs proches du XML, où chaque zone sert à cadrer un aspect précis du comportement de Claude.

On voit deux grandes familles. La première, c’est le bloc principal lié à Claude lui-même. Il définit sa personnalité, son ton, sa manière de répondre, son équilibre entre aide et prudence, ses refus, sa posture générale. C’est là qu’on sent le “caractère” du modèle. Pas juste “sois utile”, mais plutôt “sois utile comme ça, dans ces limites, avec ce style, et évite ces dérives”.

La deuxième famille, ce sont les blocs autour. Ils encadrent les capacités disponibles. Mémoire, outils, artefacts, recherche web, connecteurs, intégrations externes. Là, on n’est plus dans la personnalité. On est dans l’orchestration. Qu’est-ce que le modèle peut utiliser ? Dans quel contexte ? Avec quelles précautions ? J’ai déjà vu ça chez des clients qui empilent des automatisations IA. Le vrai sujet n’est pas seulement la réponse du modèle, c’est tout ce qu’il peut déclencher autour.

Un détail intéressant, c’est la règle initiale sur les blocs voice_note : ne jamais en émettre. Je ne vais pas inventer la raison exacte. Mais ce genre de règle montre un truc important. Le prompt ne contient pas seulement des règles éthiques ou comportementales. Il contient aussi des contraintes de format, de compatibilité, peut-être liées à l’interface, au rendu, ou à des systèmes connectés derrière.

Le fichier mentionne aussi un budget de contexte très élevé. Le contexte, c’est la quantité d’information que le modèle peut garder “sous les yeux” pendant une conversation. Plus ce budget est grand, plus le prompt système peut embarquer de politiques, de cas limites, de règles de style et de configurations d’outils. Mais attention, long ne veut pas dire robuste. Un prompt énorme peut aussi créer des conflits internes, des priorités floues, ou des comportements difficiles à tester.

Pour visualiser la logique, je le simplifierais comme ça. Ce n’est pas le vrai prompt, juste une mini version pédagogique :

[Bloc comportement]
Ton : Clair, prudent, utile
Posture : Répondre directement, poser des limites si besoin

[Bloc refus]
Refuser : Demandes dangereuses, illégales ou non vérifiables
Expliquer : Donner une raison courte et proposer une alternative sûre

[Bloc outils]
Recherche : Autorisée si l’information peut changer
Mémoire : Utilisée seulement si pertinente
Connecteurs : Appelés uniquement avec un objectif explicite

Ce qui ressort, c’est une logique de configuration produit. Le modèle n’est pas juste “prompté”. Il est encadré comme un système complet.

Quelles règles de refus apparaissent ?

Les règles de refus se concentrent surtout sur les dommages concrets : armes, explosifs, drogues illicites, code malveillant, hacking opérationnel et fausses citations attribuées à des personnes réelles.

Ce que je trouve intéressant, c’est que le refus n’est pas posé comme une posture morale générale. Il vise les demandes qui peuvent produire un préjudice direct, rapide, reproductible. Pour les armes et les explosifs, le modèle ne doit pas aider à fabriquer, modifier, optimiser ou contourner des limites de sécurité. Même une demande “juste théorique” reste problématique si elle peut servir à passer à l’action.

Pour les drogues illicites, la règle est assez nette aussi. Elle couvre la synthèse, la production, le dosage, l’amélioration du rendement ou les conseils pratiques. Même quand la demande est présentée comme de la réduction des risques, le modèle doit refuser si ça revient à expliquer comment produire, doser ou rendre l’usage plus efficace. J’ai déjà vu ce genre de glissement chez des clients qui testaient des garde-fous IA : la formulation paraît prudente, mais le contenu demandé reste opérationnel.

Côté cyber, même logique. Le modèle doit refuser le code malveillant, les instructions d’exploitation, l’aide au contournement, l’exfiltration ou le hacking opérationnel. Le fait de dire “c’est pour apprendre” ne suffit pas. Le bon angle, c’est de rester sur de la pédagogie défensive, des principes de sécurité, de la remédiation, ou des exemples neutralisés qui ne permettent pas d’attaquer un système réel.

Le point le plus subtil, c’est la manière de refuser. Le modèle doit expliquer le principe général du refus, sans révéler les détails techniques de détection. C’est important parce qu’un refus trop précis peut devenir une aide indirecte. Si je dis exactement quelle partie déclenche le blocage, je donne aussi une piste pour reformuler et contourner.

Il y a aussi un devoir de précaution sur les sujets sensibles. Pas de diagnostic de santé mentale si l’utilisateur ne l’a pas fourni. Pas de méthodes d’automutilation. Pas de chiffres, d’objectifs ou de seuils pour les troubles alimentaires. Pas de relation de dépendance affective avec l’assistant non plus. Le modèle doit rester utile, mais garder une distance saine.

Type de demande	Réponse attendue du modèle	Raison simple
Armes et explosifs	Refuser l’aide pratique à la fabrication ou à l’optimisation.	Ça peut produire un dommage physique direct.
Drogues illicites	Refuser synthèse, dosage, production ou amélioration.	La réduction des risques ne doit pas devenir un mode d’emploi.
Cyber offensif	Refuser code malveillant et hacking opérationnel.	Une demande éducative peut quand même permettre une attaque.
Fausses citations réelles	Refuser d’inventer des propos attribués à une vraie personne.	Ça peut créer de la désinformation crédible.
Santé mentale et automutilation	Rester prudent, ne pas diagnostiquer, ne pas donner de méthodes.	Le risque humain est immédiat.

Pourquoi le routage est important ?

Le routage sert à envoyer certaines sessions sensibles vers un autre modèle, ou vers un autre niveau de garde-fous, dès que le risque dépasse le cadre normal.

Dans ce qui est décrit autour de Claude Fable 5, moins de 5 % des sessions seraient redirigées. Les sujets mentionnés sont précis : cyber, bio ou chimie. Ces sessions partiraient vers Opus 4.8, présenté comme un niveau plus adapté pour traiter ce type de demandes sensibles.

Ce point est intéressant parce qu’il montre une chose simple : la sécurité d’un système IA ne repose pas seulement sur un gros prompt bien écrit. Le prompt compte, évidemment. Mais il n’est qu’une pièce du système.

Dans une architecture IA sérieuse, on retrouve souvent plusieurs couches autour du modèle :

• Une classification de la demande, pour comprendre si la requête est banale, sensible ou risquée.
• Un choix de modèle, parce que toutes les demandes n’ont pas besoin du même niveau de puissance ou de contrôle.
• Des règles d’accès, surtout quand l’IA peut toucher à des données internes ou à des actions métier.
• Des niveaux de contrôle différents, avec parfois plus de restrictions quand le sujet devient délicat.

C’est exactement la leçon que je retiens pour les entreprises. Pour un assistant interne, on peut imaginer un routage assez simple : une question basique reçoit une réponse directe, une question documentaire va chercher dans la base interne, une demande engageante passe par une validation humaine, et une demande trop risquée est bloquée.

Je ne dis pas que Claude Fable 5 fonctionne exactement comme ça au-delà de ce qui est décrit. Je dis que c’est une bonne manière de penser l’architecture. On ne met pas tout le poids sur le modèle. On construit un circuit autour de lui.

Quand j’accompagne des équipes sur l’IA, je vois souvent le même réflexe au départ : chercher le prompt magique. Je comprends, c’est tentant. Mais le vrai sujet, c’est rarement ça. Le bon réflexe, c’est de concevoir le bon circuit de décision autour du modèle.

La vraie valeur de cette fuite, ce n’est donc pas le texte du prompt en lui-même. C’est ce qu’il révèle sur la manière de construire une IA exploitable, utile, contrôlée, sans faire n’importe quoi.

Alors, qu’est-ce qu’on doit vraiment retenir ?

Le system prompt Claude Fable 5 montre une chose assez nette : un bon modèle ne tient pas seulement à ses poids ou à sa taille. Il tient aussi à son cadrage. Le prompt décrit le ton, les refus, les capacités, la mémoire, les outils et les zones où le modèle doit passer la main. Ce qui m’intéresse le plus ici, c’est la logique d’architecture : instructions système, garde-fous, routage, prudence sur les sujets sensibles. Pour vos projets IA, le bénéfice est clair : vous pouvez concevoir des assistants plus fiables, mieux cadrés et moins risqués.

FAQ

• Qu’est-ce qu’un system prompt dans un modèle IA ?
  Un system prompt est l’instruction de départ donnée au modèle avant la demande utilisateur. Il définit son rôle, son ton, ses limites, ses refus et parfois l’usage de ses outils. C’est une couche prioritaire qui influence fortement les réponses.
• La fuite du system prompt Claude Fable 5 vient-elle d’un piratage ?
  Les éléments disponibles parlent plutôt d’une extraction que d’un piratage. Autrement dit, le modèle aurait été amené à révéler ses instructions. C’est différent d’une intrusion technique dans un système, même si le résultat reste sensible.
• Pourquoi les règles de refus sont-elles aussi détaillées ?
  Elles servent à éviter que le modèle aide à produire un dommage concret. Les catégories citées concernent notamment les armes, explosifs, drogues illicites, code malveillant, hacking opérationnel et fausses déclarations attribuées à des personnes réelles.
• Le routage vers un autre modèle change quoi ?
  Le routage permet de traiter certaines demandes sensibles avec un autre modèle ou un autre niveau de garde-fous. Dans le cas décrit, une petite part des sessions, notamment cyber, bio ou chimie, serait redirigée vers Opus 4.8.
• Quelle leçon pour une entreprise qui déploie de l’IA ?
  La leçon simple, c’est qu’un prompt ne suffit pas. Il faut cadrer le comportement, limiter les accès, prévoir des refus, router les cas sensibles et garder des contrôles hors du modèle. C’est comme ça qu’on passe d’un test IA sympa à un système fiable.

 

 

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 passer de l’expérimentation IA à des systèmes vraiment exploitables, avec des données propres, des workflows solides et des garde-fous sérieux. J’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige webAnalyste et Formations Analytics. Si vous voulez cadrer vos projets IA ou automatisation, contactez-moi.