Un client retail nous appelle en septembre 2025. Leur premier LLM en production — un assistant produit déployé six mois auparavant — coûte 18 000 €/mois en facture API et marche mal. Ils veulent réduire la facture par trois. Audit : pas de prompt caching, pas de cache de résultats, modèle premium utilisé pour 100 % des requêtes y compris les triviales, pas de fallback, pas d'observabilité. Le projet n'est pas mauvais — il a juste été lancé sans prendre les bonnes décisions d'architecture initiales. Trois mois de refonte, 4 000 €/mois de facture finale, qualité améliorée. Voici les 7 décisions qu'il faut prendre avant la première ligne de code, parce qu'elles coûtent 100× plus cher à corriger après.
Pourquoi les décisions de J−1 valent 100× les rattrapages
Le piège des projets LLM est leur facilité de démarrage. Trois lignes pour appeler une API, un prompt en français, ça « marche ». Le décideur valide, l'équipe enchaîne, et trois mois plus tard la production tient sur sept couches d'arbitraires non discutés.
Le coût d'une décision change radicalement selon le moment où elle est prise :
| Décision | Coût à J−1 | Coût à J+90 |
|---|---|---|
| Choix du modèle | 1 réunion | 2–8 semaines de refonte |
| API vs self-hosted | 2 jours d'analyse | 2–4 mois de migration infra |
| Prompt caching activé | 1 ligne de code | Refonte des prompts |
| Streaming UX | 1 jour | Refonte client + serveur |
| Stratégie de fallback | 3 jours | Outage + perte client |
| Observabilité | 3 jours | Drift silencieux pendant des mois |
Sur les sept décisions, prises correctement à J−1, vous évitez en moyenne 4 mois de refonte cumulés. C'est l'investissement architecture le plus rentable d'un projet LLM.
La grille de décision en 7 questions
Voici la grille que nous utilisons en kick-off chez nos clients. Chaque question doit avoir une réponse argumentée par chiffres, pas par opinion.
# Template de validation pré-projet
modele:
choix: "Claude Sonnet 4.6"
alternative_evaluee: "GPT-4o, Llama 3.3 70B"
justification: "Volume modere + qualite raisonnement requise + budget"
hebergement:
choix: "API Anthropic"
alternative: "Self-hosted Llama sur GPU"
justification: "<500k req/mois → API moins chere"
ux_response:
streaming: true
raison: "Latence percue critique pour chat utilisateur"
caching:
prompt_cache: true
result_cache: "Redis 1h sur questions FAQ"
estimation_economies: "60% sur input tokens"
fallback:
primaire: "Claude Sonnet 4.6"
secondaire: "Claude Haiku 4.5 (overflow)"
tertiaire: "Reponse pre-redigee FAQ"
rate_limit:
par_user: "100 req/h"
par_org: "5000 req/h"
budget_max: "0,15 EUR/req"
observabilite:
traces: "LangFuse self-hosted"
alertes: "Slack si hallucination > 8%"
eval: "Dataset 200 cas, run quotidien"| Décision | Question à se poser | Impact si raté |
|---|---|---|
| 1. Modèle | Quel ratio qualité/coût/latence ? | Refonte 2–8 semaines |
| 2. Hébergement | API ou self-hosted ? | Migration infra majeure |
| 3. UX response | Streaming ou réponse complète ? | Refonte client/serveur |
| 4. Caching | Prompt cache + résultat ? | Facture × 5 |
| 5. Fallback | Que faire si le modèle plante ? | Outage utilisateur |
| 6. Rate limit | Comment limiter le coût/abus ? | Facture imprévisible |
| 7. Observabilité | Comment détecter les dérives ? | Dérive silencieuse |
Les 7 décisions, deep dive
Décision 1 — Le modèle (et ses 2 backups)
Choisir un modèle « parce qu'il est state-of-the-art » est une erreur. Le bon modèle dépend de votre profil de tâche, de votre tolérance latence, et de votre budget. Notre grille de référence en 2026 :
| Modèle | Coût/1M input | Latence p50 | Idéal pour |
|---|---|---|---|
| Claude Opus 4.7 | 15 $ | 2,5 s | Raisonnement complexe |
| Claude Sonnet 4.6 | 3 $ | 1,2 s | Default qualité/prix |
| Claude Haiku 4.5 | 0,80 $ | 0,5 s | Volume élevé, tâches simples |
| GPT-4o | 2,50 $ | 1 s | Concurrent direct Sonnet |
| Llama 3.3 70B | 0,80 $ via API | 0,8 s | Open-source via Groq/Together |
Règle : choisir deux modèles dès le départ. Un primaire et un secondaire. Quand le primaire est down, lent, ou rate-limité, vous bascule sur le secondaire automatiquement. Sans ce choix initial, le premier outage coûte 3 jours d'astreinte panique.
Décision 2 — API vs self-hosted
La question revient en réunion tous les six mois et personne ne tranche. Les chiffres pour 2026 :
| Volume mensuel | Choix optimal | Justification |
|---|---|---|
| < 50k req | API | Self-hosted absurde |
| 50k – 500k req | API + caching | Self-hosted pas rentable |
| 500k – 2M req | À calculer | Dépend du modèle visé |
| > 2M req | Self-hosted ou hybride | Économies > 30 % |
Critères additionnels qui basculent vers self-hosted : données ultra-sensibles (santé, défense), souveraineté (secteur public français), latence critique (< 200 ms en streaming). Sinon, API par défaut.
Décision 3 — Streaming vs buffering
Une réponse LLM qui prend 4 secondes à charger ressemble à un freeze. La même réponse en streaming (mots qui apparaissent au fur et à mesure) ressemble à une frappe humaine et est perçue comme rapide.
| UX cible | Streaming requis ? |
|---|---|
| Chat utilisateur | Oui, obligatoire |
| Génération de document long | Oui, utile pour preview |
| Extraction structurée (JSON) | Non, attendre la fin |
| Réponses courtes < 50 tokens | Optionnel |
| Workflow B2B asynchrone | Non |
Implémentation côté serveur : Server-Sent Events ou WebSocket. Côté client : composant qui reçoit les tokens et update incrementalement. Coût d'implémentation : 2 jours sur stack moderne (Next.js 16, FastAPI). Coût d'ajout après-coup : refonte de l'UI + serveur, 2-3 semaines.
Décision 4 — Caching, le levier économique majeur
Deux types de cache, indépendants et cumulables :
- Prompt caching (côté provider) : Claude met en cache le préfixe stable de vos prompts pendant 5 minutes. Si votre system prompt fait 3 000 tokens et est appelé 1 000 fois/heure, vous économisez 2 700 €/mois sur les input tokens.
- Result caching (côté vous) : Redis ou KV avec hash de la requête → réponse mise en cache 1h pour les questions FAQ récurrentes. Économies typiques : 30–60 % du volume.
Sans caching, votre facture API est divisée par 1. Avec les deux, par 4 à 8. C'est la décision avec le meilleur ratio effort/économies.
Décision 5 — Stratégie de fallback
Anthropic a eu un outage majeur en juillet 2025 (3h30 d'indisponibilité). OpenAI en a eu en novembre 2024 (4h). Si votre LLM est une dépendance critique, vous devez prévoir le scénario où le provider est down.
Trois niveaux de fallback à implémenter :
- Modèle secondaire chez le même provider (Sonnet → Haiku quand surcharge)
- Provider secondaire (Claude → GPT-4o quand Anthropic down)
- Réponse statique dégradée (template FAQ pour les cas courants)
Pattern d'implémentation : retry → primary alternative → secondary provider → static response. Les bibliothèques comme litellm font ça en 5 lignes.
Décision 6 — Rate limiting et contrôle de coût
Sans rate limit côté votre application, un utilisateur ou un bug peut épuiser votre budget API en quelques heures. Cas réels rencontrés en audit :
- Bot qui boucle suite à un bug → 2 700 € en un week-end
- Utilisateur frustré qui spam → 1 200 € en 4 heures
- Test de charge oublié sur staging → 4 800 € en une nuit
Trois niveaux de quota à imposer :
| Niveau | Cible | Valeur typique |
|---|---|---|
| Par user_id | Abus utilisateur | 100 req/h |
| Par organisation | Bug applicatif | 5 000 req/h |
| Par jour total | Plafond budgétaire | 200 €/jour |
Au-delà du plafond : refus + alerte ops. Vaut mieux un service refusé temporairement qu'une facture catastrophique.
Décision 7 — Observabilité dès J0
Le sujet d'un autre article complet, mais en synthèse : traces + métriques + alertes dès le premier déploiement. Sans observabilité, votre LLM dérive en silence et vous l'apprenez par un client mécontent. Stack minimale :
- LangFuse (self-hosted ou cloud) pour les traces
- 4 métriques clés : hallucination rate, latence p95, coût/req, feedback utilisateur
- Alertes Slack sur seuils
Ce n'est pas un nice-to-have. C'est ce qui différencie un projet LLM qui dure 18 mois d'un projet qui meurt après 4 mois.
Les pièges qu'on retrouve dans 80 % des projets en panne
Piège 1 — Le « on verra plus tard » sur le caching
L'équipe est focalisée sur la qualité. Le caching est repoussé. Trois mois plus tard, la facture explose, le caching est ajouté en urgence avec une refonte des prompts. Surcoût total : 4 semaines de dev + 30 000 € de facture surfacturée.
Piège 2 — Pas de plan B sur le modèle
Le projet a été conçu pour Claude. Anthropic change ses tarifs (× 1,5) ou est down trois heures. L'équipe n'a aucun plan B. Pattern à imposer dès le jour 1 : abstraire l'appel LLM derrière une interface, supporter au moins deux providers en code (même si un seul est actif).
Piège 3 — L'observabilité « on l'ajoutera à la v2 »
La v2 n'arrive jamais. Ou elle arrive après l'incident. Le coût d'ajouter LangFuse à J0 est de 3 jours. Le coût de l'ajouter après le premier incident grave est typiquement 10× plus élevé en valeur perdue (deal raté, image dégradée).
| Piège | Coût d'ignorer la décision à J−1 | Coût de la corriger à J+90 |
|---|---|---|
| Pas de caching | 0 € | 30 000 €/an |
| Pas de fallback | 0 € | 1–3 outages/an, 5–50 k€ chacun |
| Pas d'eval | 0 € | Dérive silencieuse, NPS chute |
| Pas de rate limit | 0 € | 1 incident/an à 2–10 k€ |
Ce qu'il faut retenir
Trois règles, dans cet ordre :
- 7 décisions explicites avant la première ligne de code. Documentées, validées par le tech lead.
- Caching et fallback sont structurants, pas optionnels. Les ajouter après-coup coûte des semaines.
- L'observabilité dès J0. Sans elle, vous découvrez les problèmes par les clients.
Pour aller plus loin :
- Documentation Anthropic sur le prompt caching (réduction 90 % du coût input)
- LangFuse self-hosted en 30 minutes
- Bibliothèque
litellmpour les fallbacks multi-providers en 5 lignes
Conclusion
Le client retail évoqué en intro est passé de 18 000 € à 4 000 €/mois en trois mois — mais les trois mois auraient été évités si les 7 décisions avaient été prises au départ. Aucune des décisions n'est complexe individuellement. Ce qui les rend critiques, c'est leur effet cumulé et leur coût de rattrapage. Une demi-journée de cadrage avant le premier commit vaut typiquement deux mois de refonte évités plus tard.
