Claude Fable 5 passe actuellement pour l’un des modèles de langage les plus performants disponibles publiquement – mais il est aussi cher et réagit aux prompts autrement que les modèles plus anciens. Le YouTubeur Nate Herk a dépouillé la documentation officielle d’Anthropic sur le prompting de Fable 5 et l’a ramenée à six habitudes pratiques. Nous les avons traduites en français pour vous, recoupées avec les exemples d’origine de la documentation et complétées par des remarques de terrain honnêtes – sans hype autour de l’IA.
L’essentiel en bref
- Six règles de prompting font la différence entre des tâtonnements coûteux et un travail efficace avec Fable 5.
- Le contexte l’emporte sur les ordres : dites au modèle le pourquoi, pas seulement le quoi.
- Choisir sciemment le niveau d’effort – toute tâche n’a pas besoin du modèle le plus cher réglé au maximum.
- Faire vérifier : faites-vous démontrer les résultats au lieu de leur faire aveuglément confiance.
- Moins, c’est plus : avec un modèle aussi intelligent, des instructions courtes et claires pilotent souvent mieux que des règlements longs de plusieurs pages.
Pourquoi le prompting fonctionne différemment avec Fable 5
Fable 5 suit mieux les instructions courtes et claires que les modèles précédents – simplement parce qu’il raisonne mieux. Il « comprend » souvent votre intention avant même que vous ayez détaillé chaque point. Les six règles en découlent directement : elles ne sont pas une fin en soi, elles exploitent cette force de façon ciblée.
Une remarque honnête d’emblée : Fable 5 n’est pas un modèle bon marché. Il coûte environ 10 dollars US par million de tokens d’entrée et 50 dollars US par million de tokens de sortie – soit exactement le double d’Opus 4.8 (5 et 25 dollars US). Pour la plupart des tâches de routine, vous n’en avez pas besoin. Tout l’art consiste à ne l’employer que là où cela vaut vraiment la peine.
Règle 1 : donnez au modèle le « pourquoi »
Anthropic est clair : Fable 5 livre de meilleurs résultats quand il connaît votre intention. Le contexte relie la tâche aux bonnes informations – au lieu de laisser le modèle deviner l’intention lui-même. La documentation propose même, en substance, une formule fixe : « Je travaille sur [la tâche plus large] pour [qui]. Il faut [ce que le résultat rend possible]. Dans ce contexte : [la demande]. »
- Au lieu de : « Écris-moi un courriel à un client au sujet du retard. »
- Mieux : « Je travaille sur le projet plus large suivant, voici le client et voilà sa demande. Avec ce contexte, peux-tu me rédiger un courriel au sujet du retard ? »
Vaut pour : tous les modèles. Qui travaille de toute façon avec des fichiers de contexte ou un système de connaissances bien structuré donne aussi au modèle la possibilité d’aller chercher précisément les bonnes informations.
Règle 2 : dites explicitement ce qu’il ne doit PAS faire
Les modèles d’IA prédisent au fond le prochain mot plausible – et deviennent parfois « créatifs » en faisant des choses que vous ne vouliez pas. Le prompting négatif borne cela. Anthropic procède exactement ainsi dans sa propre documentation. Un exemple vise à ce que Fable 5, à effort élevé, ne « range » pas sans qu’on le lui demande (traduit en substance) :
« N’ajoute pas de fonctionnalités, ne refactorise pas et n’introduis pas d’abstractions allant au-delà de ce que la tâche exige. Une correction de bug n’a pas besoin d’un nettoyage autour. Fais la chose la plus simple qui fonctionne bien. »
La meilleure comparaison : expliquez-le comme à un stagiaire. À un débutant, vous dites tout naturellement ce qu’il ne doit pas faire, parce qu’il ne connaît pas encore le processus. Le deuxième exemple de la documentation pose exactement cette limite (traduit en substance) :
« Quand l’utilisatrice décrit un problème, pose une question ou réfléchit à voix haute – au lieu de demander une modification –, le résultat attendu est ton appréciation. Rapporte ce que tu trouves, et arrête-toi. N’applique aucune correction tant qu’on ne te le demande pas explicitement. »
Vaut pour : tous les modèles.
Règle 3 : laissez-le agir dès qu’il en sait assez
Arrêtez la surplanification. Anthropic formule pour cela un extrait dédié dans la documentation de Fable 5 – justement parce que certaines requêtes, aux niveaux d’effort élevés, peuvent tourner de longues minutes pendant que le modèle rassemble du contexte, construit et se contrôle lui-même (traduit en substance) :
« Si tu disposes d’assez d’informations pour agir, agis. Ne redéduis pas des faits déjà établis dans la conversation, ne rouvre pas une décision que l’utilisatrice a déjà prise, et n’énumère pas des options que tu ne suivras de toute façon pas. »
Et : choisissez le niveau d’effort adapté. Fable 5 propose plusieurs niveaux – low, medium, high, extra high. La recommandation d’Anthropic, littéralement :
- high comme réglage par défaut pour la plupart des tâches
- extra high (xhigh) pour les charges de travail les plus sensibles en capacité
- medium ou low pour le travail de routine
Intéressant : d’après la documentation, même les niveaux d’effort bas de Fable 5 dépassent souvent le niveau le plus élevé des modèles précédents – à moindre coût. À l’inverse, qui fait tourner Fable 5 au maximum pour tout y perd presque toujours. De façon réaliste, vous n’avez besoin du modèle haut de gamme que pour une petite partie de vos tâches.
Règle 4 : faites-lui prouver qu’il a terminé
C’est peut-être la règle la plus importante. Les modèles affirment parfois avoir terminé – alors que ce n’est pas le cas, ou qu’ils n’ont rien vérifié. Anthropic indique que le recoupement de l’avancement avec de vrais résultats d’outils a quasiment éliminé, dans les tests, les rapports d’état inventés. Prévoyez donc des boucles de vérification (traduit en substance) :
« Avant d’annoncer un avancement, recoupe chaque affirmation avec un résultat d’outil issu de cette session. Ne rapporte que le travail pour lequel tu peux montrer des preuves. Si quelque chose n’est pas encore vérifié, dis-le explicitement au lieu de deviner. Si un test échoue, dis-le avec la sortie ; si une étape a été sautée, dis-le. »
Ce conseil vaut pour tous les modèles – et a idéalement sa place, de façon permanente, dans vos Skills, agents et fichiers de configuration, plutôt qu’accolé à chaque prompt isolé.
Règle 5 : ne demandez pas à Fable 5 d’exposer ses pensées
Cette règle est spécifique à Fable – et explicitement nommée dans la documentation officielle. Les prompts, Skills ou instructions de harness qui demandent au modèle de restituer, de transcrire ou d’expliquer son raisonnement interne dans le texte de réponse peuvent déclencher la catégorie de refus reasoning_extraction. Conséquence : davantage de bascules vers Claude Opus 4.8. Lors d’une migration, vérifiez donc si vos Skills et prompts système existants contiennent des formulations du type « explique ton raisonnement ». Si vous avez réellement besoin d’un aperçu du raisonnement, lisez plutôt les blocs structurés thinking – au lieu de le demander au modèle.
Règle 6 : dites moins, pas plus
Cela paraît d’abord contradictoire – on a longtemps entendu que plus de contexte valait mieux. Mais la capacité de Fable 5 à suivre les instructions est si bonne qu’une consigne courte pilote la plupart des comportements aussi sûrement qu’un règlement détaillé – à condition que le modèle travaille dans un bon environnement, avec du contexte, des outils et des Skills.
Ce n’est pas une contradiction avec la règle 1 : donner le « pourquoi » ne veut pas dire tout gonfler. Au lieu de « règle un : sois bref, règle deux : …, règle trois : … », une consigne courte suffit souvent, du type : « Commence par le résultat. Ta première phrase après la fin doit répondre à ce qui s’est passé ou à ce que tu as trouvé. » Et pour les questions de retour : « Ne fais une pause que si le travail l’exige vraiment – lors d’une action destructrice, d’un vrai changement de périmètre, ou quand seule l’utilisatrice peut apporter un élément. » Vaut pour : spécifique à Fable, au sens de sa forte capacité à suivre les instructions.
Bonus : quand Fable transmet discrètement la tâche à Opus 4.8
Fable 5 exécute des classificateurs de sécurité qui visent trois domaines : les techniques offensives de cybersécurité (par exemple la construction d’exploits, de logiciels malveillants ou d’outils d’attaque), les contenus de biologie et de sciences du vivant (par exemple des méthodes de laboratoire ou des mécanismes moléculaires) ainsi que l’extraction du raisonnement résumé du modèle. Si un tel classificateur se déclenche, la requête peut se terminer avec le motif d’arrêt refusal – et peut être transmise automatiquement, par un mécanisme de repli, à Claude Opus 4.8. Bon à savoir : de la recherche en sécurité légitime ou des tâches utiles en sciences du vivant peuvent elles aussi déclencher ces mécanismes de protection. Conséquence pratique : formulez de façon claire et légitime – et, si vous développez via l’API, configurez proprement le repli vers Opus 4.8.
À emporter : téléchargements gratuits
📄 Aide-mémoire : Télécharger la checklist des 6 règles en PDF (en allemand) — une page, à imprimer ou à poser à côté de l’écran.
📘 Version détaillée : Télécharger le guide complet en PDF (en allemand) — les six règles avec exemples et mise en perspective.
Conclusion
Les six règles ne sont pas de la magie, mais de solides règles de métier : donner du contexte, poser des limites claires, laisser agir, vérifier, ne pas demander le raisonnement, rester bref. Quatre d’entre elles valent pour tous les modèles et améliorent vos prompts en général. Deux sont spécifiques à Fable et aident à utiliser efficacement ce modèle haut de gamme coûteux, sans détours inutiles. Le plus grand levier reste toutefois le choix du modèle lui-même : ne prenez Fable 5 que là où vous avez réellement besoin de cette puissance – et ancrez ces règles durablement dans vos Skills et fichiers de configuration, au lieu de les retaper chaque fois.
Sources : la vidéo « How Anthropic Engineers Actually Prompt Fable 5 » de Nate Herk | AI Automation (YouTube, en anglais) ainsi que la documentation officielle d’Anthropic « Prompting Claude Fable 5 ». Exemples traduits en substance depuis l’anglais et mis en perspective.