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

Le system prompt Claude Fable 5 révèle surtout une chose simple : un modèle IA, c’est beaucoup de règles avant d’être une personnalité. Je vous montre ce que cet extrait laisse comprendre sur les refus, la sécurité, la mémoire, les outils et le vrai travail d’ingénierie derrière l’assistant.

Qu’est-ce qu’un system prompt ?

Un system prompt est l’instruction de départ qui cadre le comportement du modèle avant même que l’utilisateur écrive son message.

Dans les faits, c’est la couche invisible qui dit à l’IA comment elle doit répondre, ce qu’elle doit refuser, quel ton adopter, quels formats utiliser, quels outils elle peut appeler, quelles limites respecter, et parfois quelle mémoire prendre en compte.

Quand vous utilisez ChatGPT ou Claude, vous voyez une conversation fluide. Mais sous le capot, ce n’est pas magique. Le comportement visible vient d’un mélange entre le modèle entraîné, les règles injectées par l’éditeur, le prompt produit, c’est-à-dire les consignes liées à l’interface ou à la fonctionnalité utilisée, et les instructions système placées tout en haut.

Le point important, c’est la hiérarchie. Toutes les consignes ne se valent pas. Si vous demandez un format précis, mais qu’une règle système impose un refus sur un sujet dangereux, le refus gagne. L’utilisateur peut insister, reformuler, demander “ignore les consignes précédentes”, ça ne devrait pas passer si la couche système est bien conçue.

J’aime bien expliquer ça à mes clients comme une configuration de sécurité et de comportement, pas comme une phrase secrète. Un system prompt sérieux ressemble plus à un fichier long, structuré, avec des blocs, qu’à une astuce de prompt engineering.

Dans l’extrait autour de Claude Fable 5, on voit justement cette logique très config, presque XML. Des blocs pour le comportement, la mémoire, les outils, les artefacts, la recherche, les connecteurs. C’est très parlant, parce que ça montre que l’IA n’est pas seulement “un modèle”. C’est un modèle encadré par tout un environnement d’exécution.

Et côté business, c’est là que ça devient concret. Quand on déploie une IA en entreprise, on ne choisit pas juste entre Claude, GPT ou Mistral. On choisit aussi le cadre de comportement. Ce que l’IA a le droit de faire. Ce qu’elle doit éviter. Ce qu’elle peut mémoriser. Ce qu’elle peut connecter à vos outils internes. J’ai vu des projets échouer non pas à cause du modèle, mais parce que ce cadre était flou.

Élément	Rôle	Impact utilisateur
System prompt	Définit les règles haut niveau du comportement de l’IA.	Cadre le ton, les limites, les refus et la manière de répondre.
Prompt produit	Ajoute les consignes liées à une fonctionnalité ou une interface.	Oriente la réponse selon le contexte d’usage.
Règles de refus	Bloque certaines demandes sensibles ou dangereuses.	Explique pourquoi l’IA refuse parfois malgré une demande claire.
Outils	Autorise l’IA à appeler la recherche, des fichiers, du code ou des connecteurs.	Permet des réponses plus utiles, mais aussi plus encadrées.
Mémoire	Conserve ou réutilise certaines informations selon les règles prévues.	Personnalise l’expérience, avec des enjeux de confidentialité.

Que montre la fuite ?

La fuite montre un extrait long et structuré d’un prompt produit complet attribué à Claude Fable 5, pas une preuve officielle publiée par Anthropic.

Je reste prudent là-dessus. On parle d’un extrait publicisé, visible dans un dépôt public nommé asgeirtj/system_prompts_leaks, pas d’une documentation complète fournie par l’éditeur. Donc je le lis comme une matière d’analyse, pas comme une fiche technique certifiée.

Le fichier évoqué contient 3 826 lignes. C’est énorme pour un simple “prompt”, mais c’est justement ça qui est intéressant. On voit que le comportement d’un assistant IA n’est pas piloté par une petite phrase magique. Ça ressemble beaucoup plus à un cahier des charges opérationnel, avec des règles sur la sécurité, le ton, la retenue, les refus, la mémoire, les outils, les artefacts, la recherche et les connecteurs.

Les éléments attribués au modèle donnent une idée assez concrète de l’ambition annoncée dans l’extrait :

Classe du modèle	Mythos
Lancement indiqué	9 juin 2026
Budget de contexte	1 million de tokens, donc une très grande quantité de texte que le modèle peut prendre en compte
Knowledge cutoff	Janvier 2026, c’est la date limite des connaissances internes annoncée
Budget interne ouvert	190 000 tokens dans l’extrait
Architecture évoquée	Partage de poids avec un modèle frère plus restreint

Je le redis clairement, ces informations viennent de l’extrait publicisé. Je les traite comme des signaux à analyser, pas comme une vérité officielle gravée dans le marbre.

Le passage le plus intéressant, à mon avis, concerne le routage. L’extrait indique que certains sujets sensibles, comme la cybersécurité, la biologie ou la chimie, pourraient être redirigés vers un autre modèle plus encadré. Le routage serait rare, annoncé sous les 5 % des sessions.

Ça colle très bien avec ce que je vois en entreprise. Quand on déploie de l’IA, on ne veut pas bloquer tout le monde dès qu’un sujet devient technique. Mais on ne veut pas non plus ouvrir toutes les portes sur des sujets à risque. Le bon compromis, c’est souvent ça : garder une expérience fluide pour 95 % des usages, et basculer les cas sensibles vers un système plus contrôlé.

Pourquoi les refus sont centraux ?

Les refus sont centraux parce que le prompt sert d’abord à empêcher l’assistant d’aider sur des risques concrets, pas seulement à le rendre poli. C’est ça que l’extrait révèle assez clairement. On n’est pas juste dans une couche de ton, de prudence ou de “réponse responsable”. On est dans une cartographie des lignes rouges.

Les limites sont nettes : armes, explosifs, drogues illicites avec synthèse ou dosage, code malveillant, exploits informatiques, fausses citations attribuées à de vraies personnes. Le point important, c’est que le modèle ne doit pas seulement éviter de dire des choses “choquantes”. Il doit éviter d’aider quelqu’un à passer à l’action.

Il y a une vraie différence entre parler d’un sujet et rendre ce sujet opérationnel. Expliquer le principe général d’un risque chimique, ce n’est pas donner une procédure de synthèse. Expliquer ce qu’est un malware, un logiciel conçu pour nuire à un système, ce n’est pas fournir un code d’exploitation prêt à adapter. Donner du contexte historique sur une arme, ce n’est pas expliquer comment en fabriquer une.

Cette frontière est souvent là que tout se joue. Une IA d’entreprise peut très bien informer, vulgariser, former. Mais dès que la demande devient exploitable, dangereuse ou directement actionnable, elle doit refuser. Et ce refus doit rester sobre.

Autre détail important : quand le modèle refuse, il ne doit pas expliquer précisément comment il a détecté le problème, ni donner la méthode qui permettrait de contourner la règle. Il expose le principe général. C’est sain. Un refus trop bavard peut devenir une notice de contournement. J’ai déjà vu ça dans des tests internes : le système refuse, mais il donne tellement d’indices que l’utilisateur comprend comment reformuler.

La partie soin et bien-être est tout aussi importante. L’extrait parle aussi de santé mentale, d’automutilation, de troubles alimentaires et de formulations qui peuvent créer une dépendance émotionnelle à l’assistant. J’ai vu ce sujet sous-estimé chez des clients. Ils pensent conformité, RGPD, sécurité des données. Ils oublient que le ton d’une IA peut pousser un utilisateur fragile dans une mauvaise direction.

Pour une IA d’entreprise, les bons réflexes sont simples :

• Définir des lignes rouges claires, écrites, testables.
• Séparer l’information générale de l’instruction actionnable.
• Prévoir des escalades humaines quand le sujet touche à la santé, au juridique ou à la sécurité.
• Journaliser les refus utiles pour améliorer le système sans surveiller inutilement les gens.
• Tester les prompts sur des cas limites, pas seulement sur des demandes propres et gentilles.

À quoi servent mémoire et outils ?

La mémoire et les outils servent à transformer un chatbot en assistant capable d’agir, mais ce sont aussi les parties les plus sensibles à encadrer.

Dans l’extrait analysé, on voit aussi des blocs frères autour de la mémoire, des outils, des artefacts, de la recherche et des connecteurs. Tous les détails ne sont pas disponibles, donc je reste prudent, mais l’intention est assez claire : Claude Fable 5 ne semble pas pensé comme une simple machine à répondre. Il est pensé comme un système qui retient, qui consulte, qui manipule, qui produit.

La mémoire, c’est simple à comprendre. Elle peut servir à retenir vos préférences, votre contexte, vos habitudes de travail, parfois même la façon dont vous aimez recevoir une réponse. Le bloc Memory System Remembering you carefully dit beaucoup avec peu de mots. Retenir, oui. Mais soigneusement.

Une bonne mémoire IA n’est pas un aspirateur à données. Elle doit garder ce qui aide vraiment, éviter les informations sensibles inutiles, et rester compréhensible pour l’utilisateur. Si l’IA se souvient de tout sans que vous sachiez quoi, on crée vite de la défiance. Et franchement, chez les clients, c’est souvent là que les discussions deviennent sérieuses.

Les outils changent encore plus la donne. Computer use, skills, recherche, connecteurs… Dès qu’un modèle peut utiliser un navigateur, appeler une API, lire un document ou agir dans une interface, on change de catégorie de risque. On n’est plus seulement dans la génération de texte. On parle d’exécution, d’accès, de permissions, de traces, de vérification.

Dans mes projets Low code, notamment avec n8n, je traite toujours les agents IA comme des collaborateurs juniors avec des droits limités. Ils peuvent préparer, classer, proposer, déclencher certaines actions. Mais pas tout faire en autonomie sans garde-fous. C’est exactement la logique que ce prompt laisse voir : donner de la puissance, mais avec des limites lisibles.

Élément	Opportunité	Risque	Garde-fou recommandé
Mémoire	Personnaliser les réponses et garder le contexte utile	Retenir trop d’informations ou des données sensibles	Limiter la mémoire aux éléments utiles, visibles et modifiables
Outils	Agir dans des interfaces et automatiser des tâches	Exécuter une mauvaise action avec de vrais impacts	Mettre des permissions strictes et une validation humaine
Recherche	Actualiser les réponses avec des sources externes	Ramener des informations fausses ou non vérifiées	Citer les sources et croiser les résultats
Connecteurs	Relier l’IA aux apps métier	Donner accès à trop de données ou de fonctions	Utiliser des accès minimaux et journaliser les actions
Artefacts	Produire des livrables réutilisables comme du code ou des documents	Créer un résultat propre en apparence mais faux en pratique	Prévoir une revue, des tests et une validation avant usage

Que retenir pour votre IA ?

Ce qu’il faut retenir, c’est qu’une IA fiable se construit avec une architecture de règles, pas avec un simple prompt sympa. Le prompt système, c’est la couche de pilotage. Il définit la hiérarchie des règles, les refus, le soin utilisateur, la mémoire, les outils disponibles, et le routage des sujets sensibles. Dit autrement, ce n’est pas juste “réponds gentiment et sois utile”. C’est plutôt “voilà ton périmètre, voilà tes limites, voilà quand tu t’arrêtes, voilà quand tu demandes de l’aide”.

Si vous déployez un assistant interne, un agent support, un copilote métier ou une automatisation IA, vous devez documenter noir sur blanc ce que l’IA peut faire, ce qu’elle ne doit jamais faire, ce qu’elle doit escalader à un humain, ce qu’elle a le droit de mémoriser, et quels outils elle peut utiliser. C’est moins glamour qu’une démo qui répond en trois secondes avec un ton brillant. Mais c’est exactement ce qui évite les mauvaises surprises en production.

J’ai vu ce scénario plusieurs fois chez des clients. L’équipe teste deux ou trois prompts, tout le monde trouve ça bluffant, puis on branche l’IA sur de vraies données, de vrais utilisateurs, de vrais cas tordus. Et là, les limites apparaissent. Pas forcément parce que le modèle est mauvais. Souvent parce que personne n’a pris le temps de formaliser le comportement attendu.

Pour auditer rapidement votre assistant IA, je regarderais au minimum ces points :

• Objectif métier : Ce que l’IA doit réellement améliorer, pas juste “faire gagner du temps”.
• Données accessibles : Ce qu’elle peut lire, croiser, résumer ou exploiter.
• Actions autorisées : Ce qu’elle peut déclencher seule, proposer, ou jamais exécuter.
• Refus obligatoires : Les demandes où elle doit dire non clairement.
• Ton attendu : La manière de répondre selon le contexte, support, RH, juridique, vente.
• Escalade humaine : Les cas où un humain doit reprendre la main.
• Logs : Les traces conservées pour comprendre ce qui s’est passé.
• Tests de sécurité : Les tentatives de contournement, d’injection de prompt, ou d’extraction de données.
• Revue régulière : Les règles doivent évoluer avec les usages, les risques et les retours terrain.

La vraie question n’est pas de savoir si un prompt fuitera un jour. La vraie question, c’est si votre propre assistant resterait propre, utile et sûr si quelqu’un le testait sérieusement.

Et si votre IA avait enfin des règles claires ?

Le system prompt Claude Fable 5 montre bien le fond du sujet : une IA utile n’est pas juste un modèle puissant. C’est un modèle cadré par des règles, des refus, une mémoire prudente, des outils limités et une logique d’escalade sur les sujets sensibles. Pour moi, c’est la leçon la plus importante pour les entreprises. Avant de brancher une IA à vos données ou à vos workflows, il faut définir son périmètre réel. Ce qu’elle sait faire, ce qu’elle doit refuser, ce qu’elle doit demander. Le bénéfice est simple : vous gagnez en fiabilité, en sécurité et en confiance utilisateur.

FAQ

• Qu’est-ce qu’un system prompt Claude ?
  Un system prompt Claude est une instruction placée avant les messages utilisateur. Elle cadre le comportement du modèle : ton, format, refus, outils, mémoire et limites de sécurité. L’utilisateur ne la voit pas forcément, mais elle influence fortement les réponses.
• La fuite du prompt Claude Fable 5 est-elle officielle ?
  Non, il faut la traiter comme un extrait publicisé, pas comme une publication officielle complète. L’intérêt est surtout d’analyser la structure décrite : règles de sécurité, blocs de comportement, mémoire, outils, recherche et connecteurs.
• Pourquoi les refus sont-ils aussi détaillés dans un prompt IA ?
  Parce qu’un modèle puissant peut aider sur des sujets dangereux s’il n’est pas cadré. Les refus servent à bloquer les demandes actionnables autour des armes, drogues illicites, cyberattaque, exploits, fausses citations ou situations de mise en danger.
• Quelle différence entre mémoire IA et historique de conversation ?
  L’historique concerne souvent la conversation en cours. La mémoire peut retenir des informations utiles sur la durée, comme des préférences ou du contexte. C’est pratique, mais ça doit rester limité, transparent et utile, surtout en contexte business.
• Que doit faire une entreprise avant de déployer un agent IA ?
  Elle doit définir les objectifs, les données accessibles, les actions autorisées, les refus obligatoires, les cas d’escalade humaine et les tests de sécurité. Un agent IA ne doit pas être seulement impressionnant en démo, il doit rester fiable en conditions réelles.

 

 

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. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets data, IA et automatisation. Si vous voulez cadrer proprement vos agents IA, vos workflows ou vos assistants internes, je peux vous aider. Contactez-moi.