Analyse détaillée du prompt FinOps pour Claude Code.
Vue d'ensemble : qu'est-ce que ce prompt ?
Ce prompt n'est pas une question ou une commande simple. C'est une directive de rôle complète (system prompt) qui transforme Claude Code en ingénieur FinOps spécialisé IA. Il définit :
- Une identité professionnelle (ingénieur FinOps)
- Une mission précise (audit + plan d'optimisation)
- Une méthodologie imposée (6 phases séquentielles)
- Des contraintes éthiques (garde-fous techniques et professionnels)
- Un format de livrable attendu
C'est l'équivalent d'un cahier des charges de mission de conseil, encodé en prompt.
Définition courte :
Un ingénieur FinOps analyse, contrôle et optimise les dépenses cloud (AWS, Azure, GCP) en collaborant avec les équipes IT, DevOps, Finance et COMEX pour maximiser la valeur business du cloud.
Anatomie du prompt — décomposition section par section
Section 1 : « Rôle et mission »
Tu es un ingénieur FinOps spécialisé dans les systèmes d'IA générative en production.
Ta mission : auditer ce dépôt et l'usage associé, quantifier les postes de coût...
Ce que ça fait techniquement :
- Active un mode mental spécifique chez Claude (terminologie, raisonnement métier, références normatives)
- Définit le scope : production (pas POC, pas R&D)
- Fixe le livrable attendu : audit + plan chiffré + priorisé
- Pose la contrainte non-négociable : « sans dégrader la qualité ni la latence »
Pourquoi c'est important : Sans ce cadrage, Claude pourrait par défaut :
- Donner des conseils génériques
- Modifier le code sans permission (Claude Code peut écrire)
- Optimiser à l'aveugle (réduire
max_tokenspartout, casser la qualité)
Section 2 : Le temps strictement séparés — le garde-fou n°1
1. Audit (lecture seule) : tu explores, tu mesures, tu rédiges un rapport. Tu ne modifies rien.
2. Implémentation (sur validation) : tu n'appliques un changement qu'après que je l'ai approuvé.
Le problème qu'il résout :
Claude Code a accès à un terminal et peut écrire des fichiers, commiter, installer des dépendances. C'est puissant mais dangereux dans une mission d'audit. Sans cette séparation explicite :
- Claude pourrait modifier le code en croyant "aider"
- Casser un environnement de production
- Installer des dépendances non validées
- Faire des commits parasites
Le pattern utilisé est emprunté à la gouvernance IT : « measure twice, cut once ». En audit Sarbanes-Oxley, ISO 27001, ou ANSSI, on sépare toujours :
- L'observation (collecte de preuves, lecture seule)
- La recommandation (rapport)
- L'action (mise en œuvre validée)
Section 3 : La méthode imposée — 6 phases ordonnées
C'est le cœur opérationnel du prompt. Chaque phase a un but précis :
| Phase | Nom | But | Pourquoi cet ordre |
|---|---|---|---|
| 1 | Découverte | Cartographier sans interpréter | Voir avant de juger |
| 2 | Baseline | Mesurer l'existant | Pas d'optimisation sans référence |
| 3 | Pareto 20/80 | Identifier l'impact | Concentrer l'effort |
| 4 | Quantification | Estimer chaque levier | Comparer les options |
| 5 | Priorisation | Trier par ROI | Séquencer le travail |
| 6 | Livrable | Synthèse + plan | Rendre actionnable |
La règle d'or énoncée : « N'optimise jamais avant d'avoir mesuré. »
C'est un principe anti-cargo cult : il interdit les recommandations génériques type « utilisez le batching » sans avoir prouvé que ça aide dans ce contexte précis.
Section 4 : Les 11 leviers de la checklist
Ce sont les gisements connus d'économies sur un système LLM en production. Le prompt force Claude à examiner chacun, ce qui empêche d'oublier des leviers évidents :
| # | Levier | Gain typique | Effort |
|---|---|---|---|
| 1 | Routage modèles (gros↔petit) | 30-70% | Moyen |
| 2 | Réduction tokens d'entrée | 10-40% | Faible |
| 3 | Prompt caching | 50-90% sur préfixes stables | Faible |
| 4 | Réduction tokens de sortie | 10-30% | Très faible |
| 5 | Batch API (async) | ~50% | Faible |
| 6 | Cache applicatif (exact/sémantique) | 20-80% selon redondance | Moyen |
| 7 | RAG optimisé (reranking, filtres) | 30-60% | Moyen |
| 8 | Limites orchestration agentique | 20-50% | Moyen |
| 9 | Observabilité FinOps | Indirect (active les autres) | Élevé |
| 10 | Infrastructure (quantization, batching GPU) | 30-70% | Élevé |
| 11 | Tarifs/contrats | 10-30% | Variable |
Cette liste est exhaustive et issue de l'état de l'art FinOps LLM (FinOps Foundation, papers Anthropic/OpenAI, retours d'expérience prod). Elle évite les angles morts.
Section 5 : Les garde-fous — l'éthique du conseil
- Ne dégrade jamais la qualité ni la latence de façon silencieuse.
- Ne fabrique aucun chiffre. Une estimation est étiquetée comme telle, avec ses hypothèses.
- Phase d'audit en lecture seule. Aucune écriture, aucun commit, aucune installation.
- Pour chaque économie, propose une mesure de contrôle avant / après.
- Si une donnée manque, dis-le et propose comment l'obtenir.
Décodage de chaque garde-fou :
a) « Ne dégrade jamais la qualité de façon silencieuse »
Tout arbitrage qualité/coût doit être explicite et chiffré.
Pourquoi : un LLM peut techniquement répondre 5× moins cher en passant de Claude Opus à Phi-3, mais si le taux d'hallucination triple, vous perdez plus en SAV qu'en coûts évités. Le prompt force à toujours quantifier le compromis.
b) « Ne fabrique aucun chiffre »
Une estimation est étiquetée comme telle, avec ses hypothèses.
C'est la lutte contre l'hallucination chiffrée — le travers typique des LLM consultants qui inventent « cette optimisation économisera 35% » sans base. Le prompt impose la transparence épistémique : mesuré, estimé, ou inconnu.
c) « Phase d'audit en lecture seule »
Cité plus haut — protège l'environnement.
d) « Mesure de contrôle avant/après »
Sinon le gain n'est pas démontrable.
Principe scientifique : pas de validation = pas de gain. C'est ce qui sépare le FinOps réel de l'optimisation à l'aveugle.
e) « Si une donnée manque, dis-le »
Ne comble pas le vide.
Anti-confabulation. Plutôt que d'inventer des volumétries plausibles, Claude doit proposer l'instrumentation qui permettra de les mesurer.
Le but réel : pourquoi ce prompt existe-t-il ?
Problème business sous-jacent
Les coûts LLM en production explosent silencieusement. Les organisations découvrent typiquement après 3-12 mois :
- Une facture API qui a doublé sans hausse de trafic correspondante
- Des system prompts surdimensionnés par accumulation historique
- Des modèles top-tier utilisés pour des tâches triviales
- Zéro observabilité sur la décomposition des coûts
- Des boucles agentiques qui consomment 20× plus que prévu
Sans méthode rigoureuse, on optimise au doigt mouillé et on dégrade la qualité.
Objectifs du prompt
- Forcer la rigueur méthodologique — pas de raccourci, pas de phase sautée
- Produire un livrable réutilisable — un rapport Markdown structuré, partageable avec une DAF/CISO
- Protéger l'environnement audité — séparation stricte lecture/écriture
- Quantifier l'incertitude — distinguer mesure et estimation
- Rendre les gains démontrables — chaque optimisation a son protocole de validation
C'est, en somme, la transposition d'une mission de conseil senior en prompt exécutable.
Je confirme ma compréhension totale du mandat, des enjeux techniques, légaux et financiers. Le rôle combiné d'Ingénieur Senior FinOps + Délégué à la Protection des Données (DPO) Technique me place au carrefour de l'optimisation opérationnelle responsable : garantir que chaque dollar économisé ne dégrade en aucun cas le niveau de conformité, ni l'expérience utilisateur.
Je m'engage à respecter les Garde-fous absolus énoncés, notamment le principe de la traçabilité des arbitrages (Cost $\leftrightarrow$ Risk) et le statut de lecture seule jusqu'à validation explicite. Le rapport sera fondé sur la méthodologie stricte en 6 phases.
Les limites — ce que ce prompt ne peut PAS faire
Limite 1 : il dépend de la qualité du repo audité
Cas idéal :
- Code instrumenté (logs tokens, latence)
- Dashboards d'usage existants
- Documentation à jour
- Conventions claires dans le code
Cas dégradé (le plus fréquent) :
- Aucune métrique
- Code spaghetti, appels LLM cachés dans des helpers
- Configurations dispersées
- Pas de différenciation dev/staging/prod
Dans le cas dégradé, la Phase 2 (baseline) sera majoritairement "Inconnu" et le prompt produira surtout une liste d'instrumentations à mettre en place, pas des chiffres. C'est attendu et c'est honnête, mais ça peut décevoir si l'on attendait un gain chiffré immédiat.
Limite 2 : Claude ne voit pas les coûts réels
Sauf si vous lui fournissez :
- Les exports de facturation Anthropic / OpenAI / OVH
- Les dashboards Grafana
- Les logs Loki/Prometheus
- Les compteurs de tokens
…Claude estimera à partir du code visible, ce qui produit des fourchettes larges. Plus vous nourrissez l'audit en données réelles, plus les chiffres sont fiables.
Limite 3 : la qualité métier n'est pas mesurée par Claude
Le prompt parle de « sans dégrader la qualité » — mais Claude ne peut pas tester votre qualité métier. Il ne sait pas :
- Si vos utilisateurs tolèrent une réponse 200ms plus lente
- Si votre cas d'usage médical exige 99,9% de précision
- Quel taux d'hallucination est acceptable pour votre RAG juridique
Vous devez fournir ces SLAs ou Claude raisonnera en généralités.
Limite 4 : pas d'analyse contractuelle
Le levier 11 (tarification, contrats) mentionne « paliers tarifaires, engagements de volume » — mais Claude n'a pas accès à :
- Vos contrats négociés avec Anthropic/OpenAI/AWS
- Vos engagements de Reserved Instances
- Vos remises confidentielles
Il peut recommander d'aller négocier, mais pas chiffrer les marges réelles.
Limite 5 : connaissance des tarifs datée
Le prompt anticipe cette limite :
« Vérifie les tarifs et les remises en cours sur la documentation officielle du fournisseur plutôt que de te fier à des prix mémorisés (ils changent). »
Les prix LLM bougent tous les 3-6 mois. Sans accès web, Claude utilise ses connaissances figées (potentiellement obsolètes de 6-18 mois). En production : toujours croiser avec les pages tarifaires officielles au moment de l'audit.
Limite 6 : la Phase 6 reste un brouillon
Le rapport final produit est un point de départ, pas un livrable signé :
- Les chiffres demandent validation humaine
- Les risques qualité demandent du test métier
- Le plan d'action demande arbitrage budgétaire/RH
- La synthèse exécutive demande personnalisation au contexte client
Claude produit un draft à 80%. Les 20% restants (validation, contexte business, ton) restent humains.
Limite 7 : pas de magie sur le coût caché des optimisations
Certaines optimisations recommandées (quantization, fine-tuning, distillation) ont un coût d'implémentation et de maintenance que le prompt sous-estime parfois :
- Quantization → tests qualité poussés, perte parfois irrécupérable
- Fine-tuning → coût d'entraînement, dérive dans le temps, MLOps complet
- Distillation → infrastructure d'entraînement, équipe ML
Le prompt demande de chiffrer l'effort, mais Claude tend à minimiser ces coûts cachés. À pondérer avec une équipe MLOps réelle.
Forces du prompt — pourquoi il marche bien
1. Séparation stricte observation / action
Pattern emprunté à l'audit financier, robuste et éprouvé.
2. Vocabulaire technique précis
Les termes (Pareto, baseline, quick wins, quantization, speculative decoding, AWQ/GPTQ, top_k, reranking) activent les bons modèles mentaux chez Claude. Ce n'est pas du jargon décoratif.
3. Anti-hallucination intégré
Le tag « mesuré / estimé » + niveaux de confiance + interdiction d'inventer = qualité épistémique élevée.
4. Livrable structuré
Le format imposé (synthèse, baseline, constats, tableau de recommandations, plan d'action) garantit la cohérence quelle que soit la complexité du système audité.
5. Universalité
Le prompt fonctionne aussi bien pour :
- Un RAG simple (FastAPI + Ollama)
- Un agent LangChain multi-tools
- Une infrastructure auto-hébergée vLLM
- Un produit SaaS sur Anthropic API
…parce qu'il ne présuppose pas l'architecture, il s'y adapte par la phase de découverte.
Quand utiliser ce prompt
✅ Cas idéaux
- Système LLM en prod depuis au moins 3 mois (vous avez des données)
- Facture qui inquiète la direction
- Souhait de pérenniser un produit IA (passer de POC à industrialisation)
- Audit pré-levée de fonds (montrer la maîtrise des coûts)
- Préparation à la scale (avant ×10 de trafic)
⚠️ Cas où il est inadapté
- POC en cours de validation — trop tôt, focus sur le produit
- Système au repos — pas de données à analyser
- Pure recherche — l'optimisation coût n'est pas la priorité
- MVP < 1 mois — pas encore de baseline significative
🔄 Cas intermédiaires
- Migration en cours (ex: passage d'OpenAI vers Claude) — utile mais demandera des phases supplémentaires
- Architecture hybride (multi-cloud, multi-provider) — possible mais prévoir plus de temps
Conseils d'utilisation avancée
Avant de lancer le prompt
-
Préparez les artefacts :
- Export de facturation 3 derniers mois
- Liste des features qui utilisent du LLM
- SLAs en vigueur (latence acceptable, qualité minimum)
- Logs si disponibles (Grafana, Loki, OpenTelemetry)
-
Définissez le scope :
- Tout le système ? Une feature précise ?
- Audit interne ou pré-audit externe ?
- Budget temps : 1 jour, 1 semaine, 1 mois ?
-
Choisissez l'outil :
- Claude Code (terminal, accès filesystem) : audit complet sur repo entier
- Claude.ai (web) : extraits de code + analyse plus interactive
- API directe : pour intégrer dans un pipeline CI/CD d'audit automatisé
Pendant l'audit
- Ne sautez pas la Phase 2 même si vous êtes pressé — un audit sans baseline est inutile
- Challenge les estimations — demandez « sur quelle hypothèse repose ce chiffre ? »
- Demandez des alternatives — « et si on ne touche pas au modèle, quels leviers ? »
Après l'audit
- Validez 1-2 quick wins en pilote avant de tout déployer
- Mesurez 2 semaines avant et après chaque optimisation
- Re-auditez tous les 6 mois — les coûts dérivent silencieusement
Synthèse en une phrase
Ce prompt transforme Claude Code en ingénieur FinOps senior qui mène un audit méthodique, prudent et chiffré d'un système LLM en production, en respectant des garde-fous stricts (lecture seule, anti-hallucination, mesures avant/après), pour produire un plan d'optimisation actionnable dont les gains seront démontrables — à condition d'être nourri en données réelles et exécuté avec discipline.
Pour aller plus loin
Si vous voulez adapter ce prompt à votre contexte spécifique, les leviers d'évolution sont :
- Ajouter votre stack technique au début (« notre architecture utilise X, Y, Z ») pour des analyses plus ciblées
- Préciser vos SLAs (latence max, qualité min) pour cadrer les arbitrages
- Fournir vos contraintes RGPD/souveraineté pour orienter les recommandations infra
- Limiter à certaines phases (ex: « uniquement Phases 1+2+3 ») si vous voulez démarrer petit
- Ajouter des leviers métier-spécifiques (ex: pour healthcare, ajouter HIPAA compliance check)
