Votre code vieillit en silence : le prompt Claude Fable qui audite tout votre projet et rend le plan de remise à niveau
Le prompt d'audit en 4 phases, traduit et amélioré en français pour Claude Fable 5. Testé sur un vrai projet : 11 constats vérifiables en 3 minutes.
TL;DR — Ce qu'il faut retenir en 30 secondes
- Ce prompt transforme Claude Fable 5 (le modèle le plus avancé d'Anthropic, disponible pour tous depuis le 9 juin 2026) en auditeur technique de n'importe quel projet logiciel existant.
- Il travaille en 4 phases : cartographie du dépôt, audit sévérisé (chaque constat cité fichier:ligne), stratégie d'amélioration, plan de tâches en jalons.
- Testé sur notre propre site (124 fichiers, 26 312 lignes) : 11 constats vérifiables en environ 3 minutes pour les deux premières phases — dont une faille que nous ne soupçonnions pas.
- Version française améliorée à copier-coller ci-dessous, ou en téléchargement
.mddans notre bibliothèque de prompts IA.
Personne ne vous enverra de notification le jour où votre logiciel métier deviendra irrécupérable. La dette technique ne prévient pas : elle s'accumule en silence, version après version, prestataire après prestataire. Et un matin, la modification « simple » que vous demandez est facturée douze jours parce que « le code est fragile ».
Le pire n'est pas la dette elle-même. Le pire, c'est que vous ne savez pas où vous en êtes. Votre outil interne, votre module Odoo personnalisé, votre site, votre application : qui vous a déjà remis un état des lieux honnête, chiffré, vérifiable ? Le prestataire qui maintient le code n'a aucun intérêt à documenter ses propres raccourcis. Et un audit technique humain se facture entre 5 000 et 20 000 € selon la taille du projet — un budget que la plupart des PME n'engageront jamais « juste pour savoir ».
Résultat : les décisions se prennent à l'aveugle. On refond trop tôt (et on jette du code sain), ou trop tard (et on paie la dette au prix fort). Cet article vous donne le troisième chemin : un audit complet, exécuté par Claude Fable 5, pour le prix d'une session d'IA. Le prompt est intégral, en français, copiable en un clic. La valeur est dans la page — pas derrière un formulaire.
Claude Fable 5 change la donne pour l'audit de code
Claude Fable 5 est le premier modèle de la famille Claude 5 d'Anthropic, passé en disponibilité générale le 9 juin 2026 — y compris dans GitHub Copilot et, surtout, dans Claude Code. Ce qui nous intéresse ici n'est pas la fiche marketing, mais deux capacités précises pour l'audit :
- La tenue des longues sessions d'analyse. Auditer un dépôt, c'est lire des dizaines de fichiers, croiser des indices, garder le fil. Les modèles précédents finissaient par « oublier » le début de l'exploration ; Fable 5 est précisément conçu pour la planification longue (annonce Anthropic).
- Le travail en sous-agents parallèles. Dans Claude Code, Fable 5 peut déléguer l'exploration à des agents secondaires — la phase de cartographie d'un gros projet passe de heures à minutes. Notre version du prompt l'y autorise explicitement.
Un mot d'honnêteté, parce qu'on lit beaucoup de bêtises sur les modèles « magiques » : un bon prompt d'audit sur Sonnet vaut mieux qu'une consigne floue sur Fable 5. La structure du prompt fait 80 % du travail. Le modèle fait les 20 % restants — mais sur un dépôt volumineux, ces 20 % sont ceux qui séparent un audit superficiel d'un audit dont chaque constat est vérifiable.
Le prompt d'audit complet en français, à copier-coller
Le prompt ci-dessous s'utilise tel quel : ouvrez une session Claude Code à la racine de votre projet et collez-le comme premier message. Il circule dans la communauté anglophone sous plusieurs variantes — celle-ci est notre traduction française, retravaillée et adaptée à Fable 5 (les améliorations sont détaillées juste après).
Claude Fable : audit complet de projet en 4 phases
Le prompt d'audit à coller dans Claude Code sur n'importe quel projet existant. Cartographie, audit sévérisé fichier:ligne, stratégie, plan d'action en jalons. Version française améliorée pour Claude Fable 5.
📋 Prompt — Audit complet de projet avec Claude Fable 5
Télécharger le .md →Tu es un ingénieur logiciel principal de classe mondiale et un auditeur technique. Ta mission : analyser ce dépôt en profondeur, produire un audit honnête et livrer un plan d'amélioration priorisé et actionnable. Travaille dans les quatre phases ci-dessous, dans l'ordre. N'anticipe pas sur une phase suivante.
Ancre chaque affirmation dans les fichiers réels : cite les chemins de fichiers et les numéros de ligne. Si tu ne peux pas vérifier quelque chose, dis-le explicitement plutôt que de deviner.
Réponds intégralement en français. Le code, les identifiants et les chemins de fichiers restent tels quels.
Si ton environnement permet de lancer des sous-agents ou des tâches parallèles, utilise-les pour accélérer la Phase 1 (exploration) — jamais pour rédiger les conclusions à ta place.
Phase 1 — Découverte & cartographie (lire avant de juger)
Explore le dépôt systématiquement avant de te forger la moindre opinion :
- Cartographie l'arborescence et identifie le type de projet, le(s) langage(s), les frameworks et les cibles d'exécution.
- Identifie les points d'entrée, les modules cœur et le flux principal de données et de contrôle à travers le système.
- Lis les manifestes de paquets, les lockfiles, la configuration de build, la configuration CI, les fichiers d'environnement/config et toute documentation (README, CONTRIBUTING, ADRs).
- Détermine à quoi sert le projet : son objectif, ses utilisateurs visés et sa maturité apparente (prototype, outil interne, service en production, bibliothèque).
- Note les conventions déjà en place (nommage, frontières de modules, patterns de gestion d'erreurs, style de tests) pour que tes recommandations s'inscrivent dans la culture existante au lieu de la combattre.
- Délimite le périmètre : exclus les dossiers générés ou vendorés (build, node_modules, dist…) et dis lesquels tu as exclus.
Livrable de cette phase : une « Carte du dépôt » concise — objectif, stack, croquis d'architecture, répertoires clés avec une description d'une ligne, et tout ce qui t'a surpris.
Phase 2 — Audit (fondé sur les preuves, sévérité notée)
Audite chacune des dimensions ci-dessous. Pour chaque constat, consigne : (a) ce que tu as trouvé, (b) où (fichier:ligne), (c) pourquoi c'est important — conséquence concrète, pas principe vague, (d) la sévérité : Critique / Élevée / Moyenne / Faible.
- Architecture & conception : frontières de modules, couplage/cohésion, dépendances circulaires, abstractions qui fuient, fichiers ou objets fourre-tout, violations de couches, goulots de scalabilité.
- Qualité du code : duplication, code mort, points chauds de complexité (fonctions les plus longues ou les plus ramifiées), patterns incohérents, lacunes de gestion d'erreurs (exceptions avalées, cas limites manquants), trous de sûreté de typage.
- Sécurité : secrets ou identifiants en dur, risques d'injection, désérialisation non sûre, validation d'entrées manquante, faiblesses d'authentification/autorisation, dépendances obsolètes avec CVE connues, configurations trop permissives.
- Tests : trous de couverture (surtout autour de la logique métier cœur), qualité des tests (testent-ils un comportement ou seulement l'exécution ?), types de tests manquants (unitaires/intégration/e2e), patterns instables, code intestable.
- Performance : requêtes N+1, allocations ou copies inutiles, appels bloquants dans des chemins asynchrones, cache ou indexation manquants, croissance non bornée (mémoire, fichiers, files d'attente).
- Dépendances : paquets obsolètes, non maintenus, dupliqués ou inutilement lourds ; risques de licence ; hygiène du lockfile.
- DevEx & opérations : friction de build et d'installation, lacunes CI/CD, absence de lint/format imposés, qualité des logs et de l'observabilité, remontée d'erreurs, histoire du déploiement.
- Documentation : exactitude du README, parcours d'onboarding, comportements critiques non documentés, docs périmées qui contredisent le code.
Règles de cette phase :
- Préfère 15 constats à haute confiance à 50 constats spéculatifs.
- Distingue les faits (« cette fonction n'a aucune gestion d'erreur : src/api/client.ts:142 ») des jugements (« les responsabilités de ce module semblent floues ») et étiquette chacun.
- Liste aussi ce que le dépôt fait bien : les forces comptent pour décider quoi préserver.
- N'édulcore rien : signale les parties les plus laides qui exigent la priorité absolue.
Livrable de cette phase : un « Rapport d'audit » — constats groupés par dimension, triés par sévérité, plus une section Forces.
Phase 3 — Stratégie d'amélioration
Synthétise l'audit en stratégie :
- Identifie les 3 à 5 thèmes qui expliquent l'essentiel des constats (ex. : « aucune frontière imposée entre les couches », « la gestion d'erreurs est artisanale »).
- Pour chaque thème, propose un état cible et le principe qui le sous-tend.
- Énonce des arbitrages explicites : ce que tu recommandes de NE PAS corriger et pourquoi (effort vs gain, risque, maturité du projet).
- Définis à quoi ressemble « terminé » — des signaux mesurables (ex. : « la CI échoue sur les erreurs de lint », « couverture de tests du module cœur ≥ 80 % », « zéro constat Critique »).
Phase 4 — Plan de tâches détaillé
Convertis la stratégie en plan d'exécution. Découpe le travail en tâches discrètes. Chaque tâche doit inclure :
- Titre et description en un paragraphe
- Fichiers et zones affectés
- Critères d'acceptation (comment on vérifie que c'est fait)
- Estimation d'effort (S = moins de 2 h, M = demi-journée, L = 1 à 2 jours, XL = à re-découper)
- Risque du changement lui-même (peut-il casser quelque chose ?)
- Dépendances vers d'autres tâches
Ordonne les tâches en jalons :
- Jalon 0 — Filet de sécurité : tout ce qui est nécessaire avant de refactoriser sereinement (tests autour des chemins critiques, garde-fous CI, sauvegardes).
- Jalon 1 — Correctifs critiques : problèmes de sécurité et de justesse.
- Jalon 2 — Améliorations à fort levier : changements qui facilitent tout le travail futur.
- Jalon 3 — Qualité & finitions : le reste des éléments Moyens/Faibles qui valent l'effort.
Signale séparément les victoires rapides (fort impact, effort S) pour qu'elles soient traitées immédiatement. Pour les 3 tâches prioritaires, inclus une esquisse d'implémentation : approche, étapes clés, pièges.
Format du livrable final
Produis un document unique avec ces sections :
- Résumé exécutif (10 phrases maximum : note de santé globale A à F justifiée, top 3 risques, top 3 opportunités)
- Carte du dépôt
- Rapport d'audit
- Stratégie d'amélioration
- Plan de tâches (jalons + tableau des tâches + victoires rapides)
- Questions ouvertes : tout ce qu'il te faut d'un humain pour trancher (intention produit, candidats à la dépréciation, objectifs de performance)
Enregistre ce document dans un fichier AUDIT-<AAAA-MM-JJ>.md à la racine du dépôt — c'est la seule écriture de fichier autorisée pendant toute la mission.
Contraintes
- Ne modifie AUCUN code pendant cet audit. Analyse uniquement (seule exception : le fichier AUDIT ci-dessus).
- Ne gonfle pas le rapport. Si une dimension est saine, dis-le en une phrase et passe à la suite.
- Calibre tes recommandations sur la maturité du projet. Ne recommande pas une infrastructure d'entreprise pour un prototype de week-end, sauf si les objectifs du propriétaire l'exigent.
- Analyse les besoins réels du projet et formule les recommandations de la façon la plus efficace pour eux.
- Si le dépôt est volumineux, privilégie la profondeur sur les 20 % du code qui font 80 % du travail, et indique quelles zones ont reçu une revue plus légère.
💡 Astuce : le bouton « Copier » ci-dessus récupère le prompt intégral en un clic. Gardez le .md dans un dossier de prompts : vous le réutiliserez sur chaque projet, chaque trimestre.
Ce que cette version améliore par rapport aux variantes anglophones
Les variantes qui circulent sur GitHub et dans les newsletters tech sont solides sur la structure (les 4 phases viennent de là), mais nous avons corrigé cinq points à l'usage :
- La sortie en français est forcée. Sans cette consigne, le rapport sort en anglais — inutilisable pour le partager à un associé ou un prestataire francophone.
- Le rapport est sauvegardé dans un fichier AUDIT-<date>.md. Les versions originales laissent le rapport dans la conversation : fermez la session, tout est perdu. Ici, le livrable survit et se versionne dans Git.
- Les sous-agents sont explicitement autorisés pour l'exploration — et explicitement interdits pour les conclusions. Fable 5 parallélise la cartographie, mais l'analyse reste dans une seule tête.
- Le périmètre est délimité d'entrée (dossiers générés et vendorés exclus, et listés) : sur un projet réel, c'est la différence entre auditer votre code et auditer node_modules.
- L'interdiction de modifier le code est réaffirmée avec son unique exception. C'est ce qui rend le prompt sûr à lancer sur un projet en production, même pour un non-développeur.
Mode d'emploi : lancer l'audit en 10 minutes, sans être développeur
Lancer cet audit ne demande pas de savoir coder — il demande de savoir suivre cinq étapes. Si vous avez déjà utilisé un terminal une fois dans votre vie, vous savez faire.
- Installez Claude Code (l'outil en ligne de commande d'Anthropic) et ouvrez un terminal à la racine du projet à auditer — le dossier qui contient le code source. Si le code est chez votre prestataire, demandez-lui un accès en lecture au dépôt Git : c'est une demande normale, le code vous appartient.
- Lancez Claude Code et collez le prompt intégral comme premier message, sans rien ajouter. Ne mélangez pas les demandes : l'audit d'abord, les corrections plus tard, dans une autre session.
- Laissez travailler. Comptez de 10 minutes (petit projet) à une heure (gros dépôt). Claude annonce chaque phase ; il peut poser une question de cadrage, répondez simplement.
- Ouvrez le fichier AUDIT-<date>.md généré à la racine. Lisez le résumé exécutif d'abord : la note A-F et les 3 risques principaux vous donnent l'essentiel en une minute.
- Décidez avec le plan, pas avec l'intuition. Les victoires rapides se traitent tout de suite ; les jalons 0 et 1 se planifient ; le reste s'arbitre. Et si un prestataire vous propose une refonte, demandez-lui de répondre aux constats fichier:ligne du rapport — vous verrez très vite s'il connaît vraiment votre code.
Testé sur un vrai projet : les chiffres de notre propre audit
Plutôt que de vous promettre des merveilles, nous avons retourné le prompt contre nous-mêmes. Le 10 juin 2026, nous avons exécuté ses deux premières phases (cartographie + audit, en version condensée par sous-agent) sur le code de ce site — augmenter.pro, une application Next.js 16 en production. Voici les résultats bruts, non retouchés.
| Indicateur | Résultat mesuré |
|---|---|
| Taille du projet audité | 124 fichiers source, 26 312 lignes, 35 routes |
| Durée (phases 1-2 condensées) | ≈ 3 minutes, une dizaine d'explorations |
| Constats relevés | 11 au total — 0 critique, 1 sévérité élevée, 5 moyennes, 5 faibles |
| Constat le plus sérieux | Un endpoint API public déclenchant un appel d'IA payant, sans limitation de débit |
| Constats que nous ignorions | 4 sur 11 — dont deux sources de sitemap en conflit et 86 % de duplication entre deux pages |
Trois leçons de cet exercice, selon Pierre Legrand, consultant IA chez augmenter.pro : d'abord, l'audit a trouvé en 3 minutes une exposition de coût (l'endpoint sans limitation) que ni nous ni nos revues de code n'avions repérée. Ensuite, chaque constat est cité fichier:ligne — nous avons pu tout vérifier, et tout était exact. Enfin, le rapport liste aussi les forces (typage strict, zéro secret en dur, images optimisées), ce qui évite le piège classique de l'audit anxiogène qui pousse à tout refaire.
Les limites : ce que ce prompt ne fera pas pour vous
Un conseil honnête vaut mieux qu'une promesse. Voici où s'arrête l'exercice :
- L'audit n'est pas la réparation. Le rapport vous dit quoi faire et dans quel ordre ; exécuter les jalons reste un travail d'ingénierie — par votre équipe, votre prestataire, ou une session Claude Code dédiée et encadrée.
- Le contexte métier lui échappe. Claude voit que deux pages sont dupliquées à 86 % ; il ne sait pas que l'une convertit trois fois mieux que l'autre. Les arbitrages finaux (section « Questions ouvertes » du rapport) vous appartiennent.
- Un très gros dépôt ne sera pas couvert à 100 %. Le prompt l'assume : il concentre la profondeur sur les 20 % du code qui font 80 % du travail, et déclare les zones survolées.
- Ce n'est pas un audit de conformité. Pour un enjeu réglementaire (RGPD, NIS2) ou un litige avec un prestataire, le rapport est un excellent point de départ, pas un document opposable.
Et si le sujet n'est pas votre code mais l'usage de l'IA dans toute votre entreprise, c'est un autre exercice — celui de notre audit IA pour PME.
Questions fréquentes
Qu'est-ce que le prompt d'audit Claude Fable ?
C'est un prompt structuré en 4 phases (cartographie, audit, stratégie, plan d'action) à coller comme premier message d'une session Claude Code ouverte sur un projet existant. Il transforme Claude Fable 5 en auditeur technique : chaque constat est cité fichier:ligne avec une sévérité, et le livrable final est un rapport AUDIT.md avec un plan de remise à niveau en jalons.
Faut-il absolument Claude Fable 5, ou ça marche avec d'autres modèles ?
Le prompt fonctionne avec Claude Opus ou Sonnet, mais Fable 5 (disponibilité générale depuis le 9 juin 2026) tient mieux les très longues sessions d'analyse et la planification multi-étapes — exactement le profil d'un audit de dépôt complet. Sur un petit projet (moins de 10 000 lignes), Sonnet suffit largement.
Le prompt peut-il casser mon code ?
Non. La contrainte est explicite : analyse uniquement, aucune modification de code. La seule écriture autorisée est le fichier de rapport AUDIT-<date>.md à la racine. C'est une différence volontaire avec un agent lâché sans cadre — et c'est ce qui rend l'exercice sûr même sur un projet en production.
Que faire du rapport d'audit une fois généré ?
Trois usages concrets : lire le résumé exécutif (note A-F, top 3 risques) pour savoir où vous en êtes ; traiter les victoires rapides et les jalons 0-1 en interne ou avec votre prestataire ; et utiliser le rapport comme base objective pour challenger un devis de refonte — les constats sont cités fichier:ligne, donc vérifiables par n'importe quel développeur.
Par où commencer
Copiez le prompt, lancez-le sur votre projet le plus stratégique, lisez le résumé exécutif. Trente minutes d'effort pour savoir enfin où vous en êtes — la plupart des dirigeants que nous accompagnons ne reviennent pas en arrière. Pour aller plus loin : cadrez vos futures sessions avec notre prompt d'architecte Claude Code (le pendant « construction » de cet audit), explorez la bibliothèque de prompts IA, ou venez apprendre à piloter tout cela vous-même lors de l'atelier Claude Code pour dirigeant — une demi-journée, en présentiel (78/95) ou en visio partout en France.