System prompt Claude Fable 5 que révèle la fuite ?

Le system prompt de Claude Fable 5 montre surtout une chose simple : le comportement d’une IA est cadré par des règles écrites, pas par une magie interne. On va regarder ce que ce fichier pilote, pourquoi les refus comptent autant, et ce que ça change pour vos propres agents IA.

Qu’est-ce qu’un system prompt ?

Un system prompt est une instruction cachée, injectée avant la conversation utilisateur, qui fixe le comportement attendu du modèle.

Ce n’est pas une petite consigne décorative posée là pour faire joli. C’est une vraie couche de pilotage. Elle peut définir le ton, les limites, les outils disponibles, les règles de sécurité, la façon de refuser une demande, et parfois même la manière de gérer la mémoire ou les artefacts. Par artefacts, je parle des éléments générés dans l’interface, comme un document, un bloc de code, un tableau ou un fichier de travail.

Dans mes missions IA et automatisation, je vois souvent la même erreur. Les équipes pensent que le modèle décide tout seul. Elles testent une réponse, elles trouvent ça bon ou mauvais, et elles concluent que “l’IA sait faire” ou “l’IA ne sait pas faire”. En réalité, une grosse partie du résultat vient de l’encadrement autour du modèle.

Quand vous discutez avec une IA, vous ne parlez pas seulement à un modèle brut. Vous parlez à un modèle enveloppé dans une configuration produit. Cette configuration peut être très légère, ou très stricte. Elle peut pousser le modèle à être prudent, concis, pédagogique, commercial, ou à refuser certains sujets. C’est pour ça que deux outils basés sur des modèles proches peuvent donner des réponses très différentes.

On peut voir ça simplement avec trois couches :

Couche	Rôle
Modèle	Produit les réponses à partir de ses capacités internes
System prompt	Cadre le comportement, les limites et les priorités
Utilisateur	Pose la demande visible dans l’interface

Le point important est là. Votre message utilisateur arrive après un cadre déjà posé. Vous pouvez demander quelque chose, mais le modèle arbitre avec ce qu’on lui a donné avant. Et souvent, ce “avant” pèse plus lourd que ce qu’on imagine.

Que montre la fuite de Claude Fable 5 ?

La fuite montre surtout un prompt produit structuré, presque comme un fichier de configuration, avec des règles de comportement et des blocs de capacités. Pas juste une petite consigne magique du type “sois utile et prudent”. On est plutôt face à un document qui pilote l’expérience réelle du modèle.

Ce point est important, parce que ce genre de fichier n’est pas forcément le prompt court qu’un éditeur peut publier pour expliquer son modèle. Ça ressemble davantage à une version opérationnelle, celle qui sert à cadrer ce que l’assistant doit dire, ne pas dire, comment il doit réagir, quels outils il peut utiliser, et dans quelles conditions.

Claude Fable 5 est le modèle concerné par ce prompt, d’après les éléments disponibles. Je reste prudent ici. Le prompt le décrit comme proche de Claude Mythos 5 côté poids de modèle, donc probablement une base technique similaire, mais avec des garde-fous différents. Les garde-fous, c’est l’ensemble des règles qui orientent ou limitent le comportement du modèle. En clair, deux modèles peuvent avoir une base proche, mais une expérience très différente selon les règles posées autour.

Ce que je trouve intéressant, c’est la séparation assez nette entre le comportement et les capacités. D’un côté, un bloc dit comment l’assistant doit se comporter : ton, limites, priorités, refus, prudence. De l’autre, plusieurs blocs encadrent ce qu’il peut faire avec la mémoire, les outils, les artefacts ou la recherche. Les artefacts, dans ce contexte, ce sont des objets générés ou manipulés par l’assistant, comme du code, un document, une interface ou un fichier de travail.

Élément observé	Ce que ça signifie
Structure type XML ou configuration	Le comportement est organisé en blocs lisibles et pilotables
Bloc comportement	Il définit le style, les limites et les priorités
Blocs capacités	Ils activent ou encadrent mémoire, outils, recherche et artefacts
Règles de refus détaillées	La sécurité est une partie centrale du produit

Ce qui frappe, ce n’est pas la présence d’une instruction secrète incroyable. C’est la quantité de détails mis dans le cadrage. C’est très produit, très opérationnel, presque administratif. J’ai vu la même logique chez des clients qui industrialisent des assistants internes : le vrai travail n’est pas seulement dans le modèle, il est dans tout ce qu’on met autour pour rendre son comportement stable, prévisible et exploitable.

Pourquoi les refus sont-ils aussi importants ?

Les refus sont importants parce qu’ils tracent les lignes rouges que le modèle ne doit pas franchir, même si l’utilisateur reformule sa demande. C’est là qu’on voit si un agent IA est juste “sympa à utiliser” ou s’il est vraiment cadré.

Dans le system prompt de Claude Fable 5, les refus ne sont pas décoratifs. Ils couvrent des zones sensibles très concrètes. Armes et explosifs. Drogues illicites. Code malveillant. Faux propos attribués à des personnes réelles. Le modèle peut parler de ces sujets à un niveau général, historique ou préventif, mais il ne doit pas donner d’aide exploitable pour causer un dommage, fabriquer quelque chose, contourner une loi, piéger un système ou salir quelqu’un.

La logique est assez saine. Le modèle n’a pas besoin de dire “j’ai détecté tel pattern dans votre demande”. Ça donnerait presque un mode d’emploi pour contourner la règle. Il doit plutôt expliquer le principe de sécurité, poser une limite claire, puis proposer une alternative sûre. Par exemple, parler de cybersécurité défensive au lieu d’aider à écrire un code malveillant. Ou expliquer les risques d’une substance sans aider à en obtenir, en fabriquer ou en consommer.

Il y a aussi la notion de duty of care. En français, je traduis ça par devoir de précaution. Sur la santé mentale, la santé physique, l’automutilation ou les troubles alimentaires, le prompt impose des garde-fous très concrets.

• Ne pas diagnostiquer à la place d’un professionnel.
• Ne pas fournir de moyens explicites pour se faire du mal.
• Ne pas donner de chiffres cibles dangereux, comme des objectifs de poids ou de restriction.
• Éviter les généralisations du type “c’est normal” ou “ce n’est rien”.

Pour une entreprise, c’est loin d’être un détail technique. Un agent IA sans règles de refus propres, c’est un risque produit, juridique et réputationnel. J’ai déjà vu des équipes traiter ça comme une case conformité à cocher à la fin. Mauvaise idée. Les refus font partie du design du produit. Ils définissent ce que votre IA accepte de faire, mais surtout ce qu’elle refuse de faire au nom de votre marque.

Bon refus	Mauvais refus
Explique la limite simplement	Répond de façon froide ou vague
Redirige vers une alternative sûre	Laisse deviner comment contourner
Protège sans humilier l’utilisateur	Sur-réagit à des demandes légitimes

Que peut-on en tirer pour vos IA ?

La leçon principale, c’est qu’une IA fiable se construit autant avec du cadrage, des règles et des tests qu’avec le choix du modèle. Un bon modèle aide, oui. Mais sans consignes solides, il improvise là où vous aviez besoin de stabilité.

Ce que je recommande aux entreprises qui déploient des assistants IA ou des agents low code, c’est d’arrêter de traiter le system prompt comme une note écrite vite fait à la fin du projet. Il faut écrire un vrai prompt système. Clair. Versionné. Testé. Presque comme une spec produit.

Dans un assistant IA sérieux, je sépare toujours plusieurs choses :

• Les règles comportementales : Le ton, la prudence, la manière de répondre, les limites à respecter.
• Les capacités : Ce que l’agent sait faire, les outils qu’il peut appeler, les données qu’il peut consulter.
• Les refus : Les demandes interdites, sensibles ou à rediriger vers un humain.
• Les tests : Les formulations piégeuses, les demandes ambiguës, les cas où l’utilisateur insiste.

Dans n8n, Make, Zapier ou un workflow IA maison, le prompt système doit être traité comme une pièce d’architecture. Pas comme un texte bricolé à la fin entre deux nodes. Si votre agent peut envoyer un email, modifier un CRM, lire des données clients ou déclencher une facture, alors ses règles ne sont pas décoratives. Elles sont une barrière de sécurité.

J’ai déjà vu des assistants internes très bons sur les réponses simples, mais dangereux dès qu’on leur donnait un accès outil sans règle claire. Ils répondaient bien aux questions RH ou support. Puis dès qu’on ajoutait une action, par exemple créer un ticket, modifier une fiche client ou envoyer une synthèse, ça partait en zone grise. Le problème n’était pas le modèle. C’était le cadrage.

Bloc à prévoir	Question à se poser
Mission	À quoi sert vraiment cet agent IA ?
Périmètre	Ce qu’il peut faire et ce qu’il ne doit pas faire
Refus	Quelles demandes doivent être bloquées ou redirigées ?
Outils	Quels accès sont autorisés et sous quelles conditions ?
Mémoire	Quelles informations peut-il retenir, oublier ou réutiliser ?
Escalade	Quand faut-il repasser à un humain ?
Tests	Quelles reformulations peuvent contourner les règles ?

Le bon réflexe, c’est de garder une trace des décisions de conception. Pourquoi tel refus existe. Pourquoi tel outil est limité. Pourquoi l’agent doit demander confirmation avant d’agir. Ça évite les prompts magiques que personne n’ose toucher trois mois plus tard.

Et si le vrai sujet était le cadrage ?

Ce que je retiens de ce system prompt Claude Fable 5, c’est que l’IA produit n’a rien d’un objet mystérieux livré brut à l’utilisateur. Elle est cadrée, limitée, orientée, parfois très finement. Les règles de refus, la duty of care, la séparation entre comportement et capacités montrent une chose simple : la qualité d’un assistant dépend beaucoup de son architecture de consignes. Pour vos projets IA, c’est une bonne nouvelle. Vous pouvez agir dessus. En travaillant mieux vos prompts système, vos garde-fous et vos tests, vous gagnez en fiabilité, en sécurité et en valeur business.

FAQ

• Qu’est-ce qu’un system prompt en IA ?
  Un system prompt est une instruction cachée placée avant les messages de l’utilisateur. Il sert à définir le rôle de l’assistant, son ton, ses limites, ses règles de sécurité et parfois les outils qu’il peut utiliser.
• Pourquoi le system prompt de Claude Fable 5 est intéressant ?
  Il montre que le comportement d’une IA dépend d’un cadrage très précis. On voit une logique de configuration produit, avec des blocs dédiés au comportement, aux capacités et aux refus.
• Une IA refuse-t-elle seulement à cause du modèle ?
  Pas seulement. Le modèle compte, mais les règles de refus peuvent être largement définies dans le prompt système et dans les couches de sécurité autour du modèle. C’est souvent un mélange entre modèle, instructions et routage produit.
• Pourquoi les règles de refus sont-elles si détaillées ?
  Parce qu’elles protègent l’utilisateur, l’entreprise et le produit. Elles évitent que l’IA aide sur des sujets dangereux comme les armes, les drogues illicites, le code malveillant ou des contenus sensibles liés à la santé.
• Comment utiliser cette logique dans un projet IA d’entreprise ?
  Je conseille de traiter le system prompt comme une vraie brique d’architecture. Il faut définir la mission, le périmètre, les outils autorisés, les refus, les cas sensibles, l’escalade humaine et les tests avant de mettre l’agent en production.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation no code et 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 utiles, cadrés et exploitables. Avec webAnalyste et Formations Analytics, 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. Si vous voulez structurer vos agents IA, vos automatisations ou vos prompts système, contactez-moi.