Note de la rédaction : Claude Fable 5 a été publié le 9 juin 2026. Anthropic le positionne comme un modèle de niveau Mythos, excellent pour les tâches de génie logiciel de longue durée et doté de caractéristiques de sécurité renforcées.

Après la sortie du nouveau modèle, les développeurs ont rapidement commencé à explorer son utilisation dans des scénarios d'ingénierie réels : la prompt d'audit de dépôt partagée par @meta_alchemist en est un cas typique. Elle amène Fable 5 à ne pas simplement générer du code, mais à examiner systématiquement un dépôt de code comme le ferait un responsable technique senior, en quatre phases : d'abord cartographier la structure du projet et la pile technique, puis vérifier l'architecture, la sécurité, les tests, les performances, les dépendances et la documentation sur la base de fichiers réels et de numéros de ligne, ensuite élaborer des stratégies d'amélioration, et enfin décomposer le travail en jalons avec des priorités et des estimations de charge. Certains utilisateurs l'ont déjà utilisé pour réduire la dette technique, découvrir des failles de sécurité et des problèmes d'efficacité passés inaperçus par les anciens modèles. Certains ont également rencontré des problèmes de stabilité de l'environnement sandbox ou d'autres problèmes de jeunesse du modèle.

Dans l'ensemble, la sortie de Fable 5 n'est pas seulement une mise à niveau des capacités du modèle, elle pousse également l'IA à évoluer d'« assistant à l'écriture de code » vers « collaborateur pour l'audit technique et l'amélioration de projet ».

Voici le texte original :

Avez-vous déjà commencé à utiliser Claude Fable 5 ?

La première chose que vous devriez faire est de l'utiliser pour améliorer votre projet principal, afin qu'il améliore considérablement tout le travail que vous avez en cours.

Exécutez la « prompt d'audit et d'amélioration de projet » ci-dessous (vous pouvez la copier-coller directement) dans chaque dépôt de code important pour vous :

Audit de Dépôt de Code et Plan d'Amélioration

Vous êtes un ingénieur logiciel de classe mondiale, de niveau lead/principal, et un expert en audit technique. Votre tâche est d'analyser en profondeur ce dépôt de code, de produire un rapport d'audit honnête et de fournir un plan d'amélioration exécutable, classé par priorité. Suivez strictement les quatre phases ci-dessous dans l'ordre, sans sauter d'étape.

Tous les jugements doivent être fondés sur des preuves réelles de fichiers : citez les chemins de fichiers et les numéros de ligne. Si quelque chose ne peut être vérifié, indiquez-le clairement, ne devinez pas.

Phase 1 / Découverte et Cartographie : Lire d'abord, puis juger

Avant de tirer toute conclusion, explorez systématiquement l'ensemble du dépôt de code :

· Cartographiez la structure des répertoires, identifiez le type de projet, les langages, frameworks utilisés et la cible d'exécution.

· Identifiez les fichiers d'entrée, les modules principaux, ainsi que les principaux flux de données et de contrôle du système.

· Lisez le manifeste du package, le lockfile, les configurations de build, de CI, les fichiers d'environnement/de configuration, et toute la documentation, y compris README, CONTRIBUTING, ADR, etc.

· Déterminez l'objectif de ce projet : ses buts, ses utilisateurs attendus, et son niveau de maturité apparent – s'agit-il d'un prototype, d'un outil interne, d'un service en production, ou d'une bibliothèque ?

· Notez les conventions déjà adoptées par le projet, y compris les styles de nommage, les limites des modules, les modèles de gestion des erreurs, le style de tests, etc., afin que les recommandations ultérieures s'alignent sur la culture d'ingénierie existante, plutôt que de s'y opposer.

Résultat de cette phase : une « carte du dépôt » concise, incluant l'objectif du projet, la pile technique, un croquis d'architecture, les répertoires clés avec une brève description, et tout ce qui vous a paru surprenant.

Phase 2 / Audit : Basé sur des preuves, avec niveaux de gravité

Auditez chacune des dimensions suivantes.

Pour chaque constat, enregistrez :

a) Ce que vous avez constaté

b) Où vous l'avez constaté, au format : fichier:numéro_de_ligne

c) Pourquoi c'est important, c'est-à-dire les conséquences concrètes, pas les principes abstraits

d) Niveau de gravité : Critique / Élevé / Moyen / Faible

Architecture et Conception

Limites des modules, couplage/cohésion, dépendances circulaires, fuite d'abstraction, objets/fichiers Dieu, violation des couches, goulots d'étranglement de l'évolutivité.

Qualité du Code

Code dupliqué, code mort, points chauds de complexité (fonctions les plus longues, avec le plus de branches) ; modèles incohérents ; lacunes dans la gestion des erreurs (exceptions avalées, cas limites manquants) ; vulnérabilités de sécurité des types.

Sécurité

Clés ou identifiants en dur, risques d'injection, désérialisation non sécurisée, validation d'entrée manquante, faiblesses d'authentification/autorisation, dépendances obsolètes avec CVE connues, configurations trop permissives.

Tests

Lacunes de couverture de tests, surtout pour la logique métier essentielle ; qualité des tests (vérifient-ils un comportement ou simplement qu'ils s'exécutent ?) ; types de tests manquants (unitaires, d'intégration, de bout en bout) ; patterns de tests instables (flaky tests) ; code difficile à tester.

Performance

Requêtes N+1, allocations ou copies inutiles, appels bloquants dans des chemins asynchrones, absence de cache ou d'index, problèmes de croissance non bornée (mémoire, fichiers, files d'attente).

Dépendances

Dépendances obsolètes, non maintenues, dupliquées ou inutilement lourdes ; risques liés aux licences ; état du lockfile.

Expérience Développeur et Exploitation

Coût de build/démarrage, lacunes CI/CD, absence d'applicabilité du lint/formatting, qualité des logs et de l'observabilité, signalement des erreurs, chemins de déploiement.

Documentation

Exactitude du README, parcours de prise en main, comportements critiques non documentés, documentation obsolète en contradiction avec le code.

Règles pour cette phase

Mieux vaut fournir 15 constats de haute confiance que 50 constats spéculatifs.

Distinguer les faits des jugements. Par exemple :

· Fait : « Cette fonction n'a pas de gestion d'erreur : src/api/client.ts:142 »

· Jugement : « Les limites de responsabilité de ce module semblent floues »

Indiquez clairement quelle catégorie est laquelle.

Énumérez également ce que ce dépôt de code fait bien. Les forces sont tout aussi importantes, car elles déterminent ce qu'il faut conserver.

Résultat de cette phase : un « rapport d'audit ». Groupez par dimension, triez par gravité et incluez une section Forces. N'oubliez pas d'identifier les problèmes les plus urgents à traiter en priorité.

Phase 3 / Stratégie d'Amélioration

Syntonisez les résultats de l'audit en une stratégie cohérente :

· Identifiez 3 à 5 thèmes qui expliquent la majorité des problèmes, par exemple « Aucune frontière stricte entre les couches », « La gestion des erreurs est trop ad-hoc ».

· Pour chaque thème, proposez un état cible et le principe sous-jacent.

· Précisez les compromis : quels problèmes vous recommandez de ne pas corriger pour le moment, et pourquoi (mauvais ratio coût/bénéfice, risque élevé, maturité du projet ne le nécessite pas encore).

· Définissez ce que signifie « terminé » – donnez des indicateurs mesurables, par exemple « L'échec du lint fait échouer le CI », « Couverture de tests des modules critiques ≥ 80% », « Réduction à zéro des problèmes de niveau Critique ».

Phase 4 / Plan de Tâches Détaillé

Transformez la stratégie en plan d'exécution :

Divisez le travail en tâches indépendantes. Chaque tâche doit inclure :

· Un titre et une brève description

· Les fichiers/zones impactés

· Les critères d'acceptation (comment vérifier qu'elle est terminée)

· Une estimation de charge : S = moins de 2h, M = une demi-journée, L = 1–2 jours, XL = nécessite une décomposition ultérieure

· Le risque inhérent au changement (risque-t-il de casser une fonctionnalité existante ?)

· Les dépendances vis-à-vis d'autres tâches

Organisez les tâches en jalons (Milestones) :

Jalon 0

Filet de sécurité : Ce qui doit être fait avant de commencer les refactorisations risquées, par exemple des tests sur les chemins critiques, des portes CI, des sauvegardes.

Jalon 1

Corrections critiques : Problèmes de sécurité et de correction (correctness).

Jalon 2

Améliorations à fort effet de levier : Changements qui rendront tout le travail ultérieur plus facile.

Jalon 3

Qualité et finition : Les éléments restants de priorité moyenne ou faible qui valent la peine d'être traités.

Identifiez séparément les quick wins, c'est-à-dire les tâches à fort impact, de charge S, qui peuvent être réalisées immédiatement.

Pour les trois tâches les plus prioritaires, fournissez un bref croquis d'implémentation, incluant l'approche, les étapes clés et les pièges à éviter.

Format de Livrable Final

Générez un document unique contenant les sections suivantes :

Executive Summary (Résumé Exécutif) : Pas plus de 10 phrases. Donnez une note globale de santé (A–F) et justifiez-la ; listez les 3 principaux risques et les 3 principales opportunités.

Carte du Dépôt (Repo Map)

Rapport d'Audit (Audit Report)

Stratégie d'Amélioration (Improvement Strategy)

Plan de Tâches (Task Plan) : Incluant les jalons, le tableau des tâches et les quick wins

Questions Ouvertes (Open Questions) : Listez les informations nécessitant une décision humaine, par exemple les intentions produit, les modules pouvant être abandonnés, les objectifs de performance, etc.

Contraintes

Pendant cet audit, ne modifiez aucun code. Analysez uniquement.

Ne remplissez pas le rapport artificiellement. Si une dimension est saine, une phrase suffit, passez à la suivante.

Calez vos recommandations sur la maturité du projet. À moins que l'objectif du propriétaire du projet ne le nécessite vraiment, ne recommandez pas d'infrastructure de niveau entreprise pour un prototype de week-end.

Analysez les besoins réels du projet et proposez des suggestions de la manière la plus efficace possible.

Si le dépôt de code est très volumineux, priorisez une analyse approfondie des 20% de code les plus centraux, c'est-à-dire ceux qui effectuent 80% du travail, et précisez quelles zones n'ont fait l'objet que d'un examen superficiel.