LLMOps pour Claude : exploitation, rôles et SLO

TL;DR

Le LLMOps, c’est l’exploitation d’applications construites sur un modèle loué comme Claude. Vous n’entraînez aucun poids. Vous versionnez les prompts, validez chaque changement par des évaluations, suivez latence, erreurs, limitations et coût en tokens, puis migrez avant le retrait du modèle. Anthropic prévient au moins 60 jours avant, Bedrock généralement 6 mois.

Qu’est-ce que le LLMOps, et en quoi diffère-t-il du MLOps ?

Le LLMOps regroupe les pratiques qui gardent une application LLM juste, rapide, abordable et à jour dès que de vrais utilisateurs en dépendent. Avec Claude via Bedrock, Google Cloud ou l’API Claude, le modèle est une dépendance louée. Vos leviers sont les prompts, le contexte, les paramètres, le routage et la version de modèle que vous figez. Le MLOps suppose un modèle maison.

Le travail de l’équipe change en conséquence. Personne ne réentraîne Claude. Le fournisseur publie de nouvelles versions, retire les anciennes à des dates qu’il fixe, et modifie les paramètres qu’un modèle accepte. La facturation se fait au token, pas à l’heure de GPU : allonger un prompt est une décision budgétaire. La qualité se juge sur du texte libre, les tests unitaires ne suffisent pas.

	MLOps (modèle maison)	LLMOps (Claude en service)
Ce que vous modifiez	Données d’entraînement, features, poids	Prompts, contexte, outils, identifiant de modèle, paramètres
Unité de livraison	Artefact de modèle	Version de prompt plus identifiant de modèle figé
Contrôle qualité	Métriques sur jeu de test (accuracy, AUC)	Jeu d’évaluation noté par code, humain ou second LLM
Principal poste de coût	Calcul d’entraînement et de service	Tokens d’entrée, de sortie et de cache par requête
Limite de capacité	Votre cluster	Quotas du fournisseur (RPM, tokens par minute)
Risque de cycle de vie	Dérive des données	Le fournisseur retire le modèle à une date qu’il choisit
Enjeu de protection des données	Données d’entraînement	Prompts et réponses dans les journaux

Nous voyons le LLMOps comme un métier plus étroit que le MLOps, pas plus large. Une équipe qui pratique déjà le SRE et la gestion des changements y retrouve l’essentiel. Les nouveautés sont les évaluations, l’économie des tokens et le retrait des modèles.

À quoi ressemble le cycle de vie LLMOps pour Claude ?

Le cycle compte six étapes récurrentes : versionner le prompt, l’évaluer, le déployer derrière un identifiant de modèle figé, le surveiller, maîtriser les coûts et changer de modèle avant son retrait. Chaque étape a besoin d’un responsable et d’un déclencheur. La dernière est la plus souvent oubliée, alors qu’elle seule a une échéance externe ferme.

1. Versionner les prompts comme du code. Prompt système, définitions d’outils et exemples vivent dans Git, à côté de l’identifiant de modèle figé. Un changement de prompt est une pull request.
2. Valider par les évaluations. Le guide d’évaluation d’Anthropic demande des critères de succès précis et mesurables et une notation automatisée. Plus de questions avec une notation automatique un peu bruitée valent mieux que peu de questions notées à la main. Il recommande aussi de noter avec un autre modèle que celui qui a produit la réponse.
3. Déployer avec un identifiant figé. Utilisez un identifiant complet de modèle ou de profil d’inférence, comme eu.anthropic.claude-sonnet-5 sur Bedrock, jamais un alias que vous ne maîtrisez pas.
4. Surveiller erreurs, limitations, latence et tokens par modèle (section suivante).
5. Maîtriser les coûts avec le cache de prompts et des budgets. Sur Claude Opus 5.5, l’entrée coûte 4 USD par million de tokens et une lecture de cache 0,20 USD (voir la page sur le prompt caching). Les modèles standard lisent le cache à 0,1x du prix d’entrée.
6. Changer de modèle avant le retrait. Rejouer tout le jeu d’évaluation sur le remplaçant, puis basculer l’identifiant figé.

C’est à l’étape 6 que la production casse. La page des dépréciations d’Anthropic garantit au moins 60 jours de préavis pour les modèles publiés. Le 30 septembre 2026, Anthropic a déprécié claude-sonnet-4-5-20250929, retiré le 30 novembre 2026, avec claude-sonnet-5-5 comme remplaçant. Ces dates valent pour l’API Claude. Bedrock et Google Cloud suivent leur propre calendrier. La politique de cycle de vie de Bedrock prévoit des périodes Legacy de 6 mois ou 45 jours, et un modèle Legacy peut perdre l’accès après 15 jours d’inactivité.

Changer de modèle n’est pas remplacer une chaîne de caractères. Sur Claude 4.7 et suivants, une valeur non par défaut pour temperature, top_p ou top_k renvoie une erreur HTTP 400. Un prompt qui tournait depuis un an échoue alors dès la première requête au nouveau modèle. C’est précisément ce que l’évaluation avant bascule doit détecter.

Quels SLO pour une application sur Claude ?

Fixez quatre SLO par application : disponibilité, latence, coût par requête et taux de réussite aux évaluations. Les cibles ci-dessous sont nos recommandations de départ, pas des engagements d’un fournisseur. Calibrez-les sur deux semaines de mesures propres. Les fournisseurs publient des limites et des métriques, pas les SLO de votre application : le budget d’erreur, c’est vous qui le définissez.

SLO (notre recommandation)	Cible de départ	Mesure sur Bedrock	Mesure sur Google Cloud
Disponibilité : requêtes réussies après relances	99,5 % sur 30 jours	InvocationServerErrors, InvocationThrottles face à Invocations	prediction/online/error_count face à response_count
Délai du premier token, chat en streaming, p95	moins de 3 s	TimeToFirstToken	Latence du premier token dans le tableau de bord d’observabilité
Latence complète, p95	selon le cas d’usage	InvocationLatency	prediction/online/prediction_latencies
Coût par requête, p50	référence plus 20 %	Comptes de tokens du journal d’invocation	Journal requêtes et réponses, métriques token_count
Taux de réussite sur le jeu de référence	aucune baisse face à la version actuelle	Votre pipeline d’évaluation	Votre pipeline d’évaluation

Les métriques d’exécution Bedrock sous AWS/Bedrock incluent TimeToFirstToken pour les appels en streaming et EstimatedTPMQuotaUsage. AWS précise que cette dernière est une approximation, à ne pas utiliser seule pour planifier la capacité. Les requêtes limitées ne comptent ni comme invocations ni comme erreurs : intégrez-les comme terme distinct dans le calcul de disponibilité. Sur Google Cloud, le tableau de bord d’observabilité des modèles affiche QPS, débit de tokens et latence du premier token, y compris pour les modèles partenaires gérés comme Claude.

La limitation mérite sa propre alerte. Bedrock réserve au début de chaque requête les tokens d’entrée plus max_tokens. Les tokens de sortie consomment ensuite le quota à 10x pour Claude Opus 5.5, Sonnet 5, Opus 5 et Fable 5.1, selon la page sur le décompte des tokens. Une valeur max_tokens généreuse par défaut peut ainsi limiter un service bien en dessous de sa consommation réelle.

aws cloudwatch put-metric-alarm --region eu-west-3 --alarm-name claude-throttles --namespace AWS/Bedrock --metric-name InvocationThrottles --dimensions Name=ModelId,Value=<model-id-tel-que-dans-cloudwatch> --statistic Sum --period 300 --evaluation-periods 1 --threshold 10 --comparison-operator GreaterThanThreshold --alarm-actions <sns-topic-arn>

Sur l’API Claude, le 429 dû à une limite de débit porte un en-tête retry-after. Le 429 dû au plafond mensuel de dépenses n’en a pas, et les relances échouent jusqu’au rétablissement de l’accès, d’après la page sur les limites. Alertez séparément sur error.details.error_code = enforced_spend_limit_reached : c’est un incident budgétaire, pas un problème de capacité.

Quels outils dans une pile LLMOps ?

Quatre catégories couvrent l’essentiel : une passerelle pour les clés, le routage et les budgets, le traçage requête par requête, un moteur d’évaluation et le reporting des coûts. Partez de ce que le cloud fournit, ajoutez une instrumentation OpenTelemetry, et n’ajoutez un outil dédié que lorsqu’un manque se fait sentir. Les analyses détaillées font l’objet d’articles séparés.

Catégorie	Inclus dans la plateforme	Standard ouvert ou auto-hébergé
Passerelle	IAM et profils d’inférence Bedrock ; quotas Google Cloud	LiteLLM dans votre réseau européen
Journaux de requêtes	Journalisation des invocations Bedrock (CloudWatch Logs, S3) ; journalisation requêtes et réponses Google Cloud (BigQuery)	OTLP vers votre collecteur
Traçage	CloudWatch, Cloud Monitoring	Conventions GenAI d’OpenTelemetry ; Langfuse via OTLP
Évaluations	Bedrock Model Evaluation	Votre propre banc de test en CI
Coûts	Cost Explorer, Cloud Billing ; Usage and Cost API d’Anthropic	Journaux de dépenses de la passerelle

C’est dans les journaux que le LLMOps rencontre le RGPD. La journalisation des invocations Bedrock est désactivée par défaut. Activée, elle capture requêtes et réponses complètes, en ligne jusqu’à 100 Ko et dans S3 au-delà, avec des destinations obligatoirement dans le même compte et la même région. La journalisation requêtes et réponses de Google Cloud prend en charge Claude en Preview, écrit dans BigQuery et accepte un taux d’échantillonnage entre 0 et 1. Les deux journaux contiendront toute donnée personnelle saisie par les utilisateurs. Fixez durée de conservation et droits d’accès avant de les activer, et inscrivez le traitement dans votre registre.

Pour un traçage portable, les conventions GenAI d’OpenTelemetry ont encore le statut Development, mais elles définissent déjà un profil Anthropic. Un détail compte pour les tableaux de bord de coûts : le champ input_tokens d’Anthropic exclut les tokens en cache. La convention calcule donc l’entrée totale comme input_tokens + cache_read + cache_write.

from opentelemetry import trace

tracer = trace.get_tracer("claude-app")

def record_usage(span, model: str, usage) -> None:
    span.set_attribute("gen_ai.provider.name", "anthropic")
    span.set_attribute("gen_ai.request.model", model)
    cache_read = usage.cache_read_input_tokens or 0
    cache_write = usage.cache_creation_input_tokens or 0
    span.set_attribute("gen_ai.usage.cache_read.input_tokens", cache_read)
    span.set_attribute("gen_ai.usage.cache_write.input_tokens", cache_write)
    span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens + cache_read + cache_write)
    span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Langfuse accepte l’OTLP sur /api/public/otel en HTTP (JSON ou protobuf, pas gRPC) : les mêmes spans peuvent alimenter une interface de traces auto-hébergée. Les prix des tokens derrière ces tableaux de bord figurent dans notre comparatif des prix de l’API Claude.

Qui fait quoi dans une équipe LLMOps ?

Quatre rôles portent le LLMOps : un product owner pour les critères de qualité, un développeur applicatif pour les prompts et les évaluations, un ingénieur plateforme pour la passerelle, les quotas et la journalisation, et une astreinte pour les incidents. Dans une petite équipe, une personne cumule deux rôles. L’échec vient quand retrait des modèles et maintenance des évaluations n’ont pas de responsable nommé.

Rôle	Responsable de	Tâche récurrente
Product owner	Critères de succès, recette des évaluations	Valide les changements du jeu d’évaluation et les arbitrages qualité
Développeur applicatif	Prompts, outils, cas d’évaluation	Ajoute les échecs de production au jeu d’évaluation
Ingénieur plateforme	Passerelle, quotas, journalisation, IAM	Demandes de quota, réglage de max_tokens, conservation des journaux
Astreinte	SLO de disponibilité et de latence	Alertes de limitation et 5xx, statut fournisseur, retour arrière
DPO	Contenu des journaux, contrat de sous-traitance, sous-traitants ultérieurs	Revoit le périmètre et la durée de journalisation

Le retrait des modèles revient à l’ingénieur plateforme, le développeur applicatif exécutant les évaluations. Le déclencheur est l’e-mail de dépréciation ou le statut Legacy sur une fiche modèle Bedrock. Pour Sonnet 5, cette fiche indique aujourd’hui une fin de vie pas avant le 30 juin 2027 et une période Legacy d’au moins 6 mois. Le choix des régions pour ces mêmes modèles est détaillé dans notre guide Amazon Bedrock en Europe.

Exploiter en interne ou externaliser ?

Exploitez le LLMOps en interne si Claude porte un produit central et que vous disposez déjà d’une astreinte et d’une équipe plateforme. Externalisez une partie si vous avez une ou deux applications Claude, pas d’astreinte 24/7 et personne dont le métier inclut la lecture des avis de dépréciation. Les évaluations restent chez vous dans tous les cas : seule votre équipe sait ce qu’est une bonne réponse.

Ce que coûte l’exploitation interne, d’après notre estimation et non une mesure : pour une application en production, environ un demi-poste d’ingénieur plateforme pour la passerelle, les quotas, la journalisation et les changements de modèle, quelques heures par semaine de développement applicatif pour maintenir les évaluations, et une part d’une astreinte existante. Les tâches récurrentes sont connues : revue hebdomadaire des limitations et du coût par requête, mise à jour mensuelle du jeu d’évaluation, un projet de migration par avis de retrait.

Un prestataire de services managés a du sens pour la couche plateforme : astreinte sur la passerelle et les quotas, mise en place de la journalisation, suivi des calendriers de retrait sur Bedrock et Google Cloud. Il en a moins pour la conception des évaluations et les changements de prompts. Un prestataire qui modifie vos prompts sans passer par votre barrière d’évaluation livre des changements que vous ne pouvez pas juger.

Ce qu’il faut exiger d’un prestataire LLMOps :

1. Un SLA aligné sur vos SLO : délai de réaction aux alertes de limitation et 5xx, avec les définitions de SLO dans le contrat, pas un simple “best effort”.
2. Un contrat de sous-traitance (art. 28 RGPD) couvrant les journaux : où sont stockés journaux d’invocation et traces, combien de temps, et qui peut lire le contenu des prompts.
3. La liste des sous-traitants ultérieurs, y compris tout SaaS de traçage ou d’évaluation ajouté par le prestataire.
4. Le modèle d’accès : accès uniquement par des rôles dans votre compte AWS ou Google Cloud, tracés dans CloudTrail ou Cloud Audit Logs, jamais par des clés racine partagées.
5. Une obligation sur les dépréciations : l’engagement écrit de signaler chaque avis de retrait et de rejouer votre jeu d’évaluation sur le remplaçant avant la bascule.
6. La réversibilité : prompts, jeux d’évaluation, tableaux de bord et alarmes dans votre dépôt, pour qu’une reprise ne parte pas de zéro.

FAQ

Quelle différence entre LLMOps et MLOps ?

Le MLOps gère des modèles que vous entraînez : pipelines de données, entraînements, artefacts. Le LLMOps gère des applications sur un modèle loué que vous n’entraînez pas. Le travail se déplace vers le versionnage des prompts, les évaluations, le coût en tokens, les quotas du fournisseur et la migration avant le retrait d’une version.

Quel préavis avant le retrait d’un modèle Claude ?

Sur l’API Claude, Anthropic prévient au moins 60 jours avant le retrait d’un modèle publié. Bedrock fixe ses propres dates, avec une période Legacy de 6 mois ou 45 jours, 6 mois pour la plupart des modèles. Google Cloud a aussi son propre calendrier. Seule compte la plateforme que vous appelez réellement.

Combien fait économiser le cache de prompts sur Claude ?

Une lecture de cache coûte 0,1x du prix d’entrée sur les modèles standard et 0,05x sur Claude Opus 5.5 : 4 USD en entrée contre 0,20 USD par million de tokens. Une écriture de cache 5 minutes coûte 1,25x. Sur l’API Claude, les lectures de cache ne comptent pas non plus dans la limite de tokens d’entrée par minute pour la plupart des modèles.

Sur quelles métriques alerter pour Claude sur Bedrock ?

Sur InvocationThrottles, InvocationServerErrors et TimeToFirstToken par identifiant de modèle, dans l’espace de noms AWS/Bedrock. Pour les coûts, suivez InputTokenCount, OutputTokenCount et les compteurs de tokens de cache. Traitez EstimatedTPMQuotaUsage comme une approximation, comme AWS le fait lui-même.

Anthropic ou AWS fournissent-ils des SLO pour les applications LLM ?

Non. Les fournisseurs publient limites de débit, quotas, codes d’erreur et métriques. Les SLO de votre application, comme 99,5 % de disponibilité ou un délai cible du premier token, sont vos propres définitions. Les cibles de cet article sont nos recommandations de départ.

Faut-il activer la journalisation des invocations en production ?

Oui, avec des garde-fous. Sans journaux, impossible de diagnostiquer ou de bâtir des cas d’évaluation à partir d’échecs réels. Mais ces journaux contiennent des données personnelles. Restreignez l’accès, fixez une durée de conservation, documentez-la dans votre registre des traitements et échantillonnez sur Google Cloud si une journalisation complète n’est pas nécessaire.

Sources

1. Anthropic : Model deprecations (1 octobre 2026)
2. Anthropic : Rate limits (1 octobre 2026)
3. Anthropic : Prompt caching (1 octobre 2026)
4. Anthropic : critères de succès et évaluations (1 octobre 2026)
5. Anthropic : erreurs de l'API (1 octobre 2026)
6. Anthropic : Usage and Cost API (1 octobre 2026)
7. AWS : métriques CloudWatch de bedrock-runtime (1 octobre 2026)
8. AWS : journalisation des invocations (1 octobre 2026)
9. AWS : décompte des tokens dans Amazon Bedrock (1 octobre 2026)
10. AWS : cycle de vie des modèles Bedrock (1 octobre 2026)
11. AWS : fiche modèle Claude Sonnet 5 (1 octobre 2026)
12. Google Cloud : quotas des modèles Claude (1 octobre 2026)
13. Google Cloud : journalisation requêtes et réponses (1 octobre 2026)
14. Google Cloud : surveiller les modèles (1 octobre 2026)
15. OpenTelemetry : conventions sémantiques GenAI (1 octobre 2026)
16. Langfuse : intégration OpenTelemetry (1 octobre 2026)