LLM en production : 5 patterns d'intégration qui tiennent

Passer d'un POC ChatGPT à un service LLM qui sert 10 000 utilisateurs internes change radicalement les contraintes. Latence p95, coût par requête, traçabilité réglementaire, hallucinations en environnement métier : ces sujets n'existent pas dans un notebook. Voici les patterns que nous voyons fonctionner chez nos clients depuis 18 mois, et ceux qui échouent.

1. RAG : sortir du "naïf" rapidement

Le RAG (Retrieval-Augmented Generation) reste le pattern dominant pour ancrer un LLM dans des données d'entreprise. Mais le RAG naïf — embeddings + cosine similarity + top-k — plafonne vite autour de 60-70% de réponses pertinentes sur des corpus métier.

Ce qui fait passer à 85-90% :

• Hybrid search : combiner BM25 (lexical) et dense vectors. Qdrant, Weaviate et Elasticsearch 8.x le supportent nativement.
• Reranking : un cross-encoder (Cohere Rerank 3, BGE-reranker-v2) appliqué sur le top-50 avant de garder le top-5.
• Chunking sémantique plutôt que par taille fixe. La librairie semantic-text-splitter ou les chunkers de LlamaIndex donnent de bien meilleurs résultats que RecursiveCharacterTextSplitter sur des PDF techniques.
• Query rewriting : reformuler la question utilisateur avant la recherche (HyDE, multi-query).

from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever

bm25 = BM25Retriever.from_documents(docs, k=20)
vector = qdrant_store.as_retriever(search_kwargs={"k": 20})

hybrid = EnsembleRetriever(
    retrievers=[bm25, vector],
    weights=[0.4, 0.6],
)
# puis rerank avec Cohere sur le top-40

2. Agents : utiles, mais pas pour tout

Les agents (ReAct, function calling, multi-step) sont survendus. Notre règle empirique : si la tâche tient en 1 ou 2 appels d'outils, un workflow déterministe avec function calling suffit. On ne sort le framework agentique (LangGraph, CrewAI, Pydantic AI) qu'au-delà.

| Cas d'usage | Pattern recommandé | |---|---| | Q&A sur documentation | RAG simple | | Extraction structurée | Function calling + JSON schema | | Workflow 3-5 étapes connues | Graphe d'états (LangGraph) | | Exploration ouverte (recherche, code) | Agent ReAct | | Multi-agents collaboratifs | À éviter en production sauf besoin avéré |

LangGraph s'est imposé chez nos clients pour les workflows complexes : il rend explicite la machine à états, permet le checkpointing (reprise après crash) et le human-in-the-loop. C'est ce qu'on attend d'un système de production.

3. Observabilité : sans ça, vous volez aux instruments cassés

Un LLM en production sans observabilité, c'est un microservice sans logs. Trois outils dominent en 2025 : Langfuse (open source, self-hostable), Arize Phoenix et LangSmith. Tous instrumentent via OpenTelemetry désormais.

Ce qu'il faut tracer a minima :

• Latence par étape (retrieval, LLM call, reranking)
• Tokens in/out par modèle et par tenant
• Score de pertinence des chunks récupérés
• Feedback utilisateur (thumbs up/down) corrélé aux traces
• Évaluations automatiques (LLM-as-judge sur un échantillon)

L'évaluation continue est non négociable. Définissez un dataset de régression de 100-300 exemples annotés et faites tourner Ragas ou DeepEval dans la CI à chaque changement de prompt, de modèle ou de chunking.

4. Garde-fous : défense en profondeur

Les garde-fous se pensent en couches, pas en filtre unique :

1. Entrée : détection de prompt injection (Lakera Guard, Prompt Guard de Meta), PII scrubbing (Presidio).
2. Système prompt durci : instructions explicites, format de sortie contraint via JSON schema ou Outlines/Instructor.
3. Sortie : validation schéma, détection de toxicité, vérification de groundedness (le LLM cite-t-il bien les sources retrieve ?).
4. Politique métier : règles déterministes post-LLM (montants max, mots-clés interdits, validation humaine au-delà d'un seuil).

NVIDIA NeMo Guardrails et Guardrails AI offrent des DSL pour ces couches. Pour les cas sensibles (santé, finance, juridique), prévoyez toujours un fallback humain explicite plutôt qu'une réponse incertaine.

5. FinOps LLM : la facture qui surprend

Un projet typique passe de 200€/mois en POC à 15-40k€/mois en production. Les leviers qui marchent :

• Routing par complexité : GPT-4o-mini ou Claude Haiku pour 70% des requêtes, modèle premium uniquement quand nécessaire. RouteLLM et LiteLLM facilitent ce pattern.
• Prompt caching (Anthropic, OpenAI, Gemini) : -50 à -90% sur les tokens d'input répétés. Indispensable pour les system prompts longs.
• Batch API pour les traitements asynchrones : -50% sur OpenAI et Anthropic.
• Semantic cache (GPTCache, Redis avec vector search) sur les questions fréquentes.
• Distillation : fine-tuner un petit modèle (Llama 3.1 8B, Phi-4) sur les sorties d'un grand modèle pour les tâches répétitives à fort volume.

Mesurez le coût par requête réussie, pas le coût par token. C'est la seule métrique qui aligne ingé et finance.

Checklist de mise en production

• [ ] Dataset d'évaluation versionné (>100 exemples)
• [ ] Pipeline CI exécutant Ragas/DeepEval sur chaque PR
• [ ] Traces Langfuse/Phoenix avec corrélation feedback utilisateur
• [ ] Routing multi-modèles + prompt caching activé
• [ ] Garde-fous entrée/sortie + détection prompt injection
• [ ] Politique de fallback humain documentée
• [ ] Budget alerts sur coût/jour et coût/tenant
• [ ] Plan de rollback prompt et modèle (feature flags)

À retenir

• Le RAG naïf ne tient pas en production : hybrid search + reranking + chunking sémantique sont la baseline 2025.
• N'utilisez un framework agentique que si la tâche est réellement non-déterministe. LangGraph pour les workflows, function calling pour le reste.
• L'observabilité (Langfuse, Phoenix) et l'évaluation continue ne sont pas optionnelles — c'est ce qui distingue un service d'un POC.
• Pensez les garde-fous en couches : entrée, prompt, sortie, politique métier, fallback humain.
• Le FinOps LLM se joue au routing et au caching, pas à la négociation du prix au token.