Plateformes, quotas et mise en production
Choisir entre l’API directe et les plateformes cloud, comprendre les limites de débit, et mettre un service en production sans découvrir les problèmes en même temps que les utilisateurs.
À la fin de ce chapitre, vous saurez
- Choisir la porte d’entrée adaptée à vos contraintes
- Comprendre les limites de débit et concevoir en conséquence
- Gérer les clés, les environnements et la traçabilité
- Mettre en production avec les repères qui évitent l’incident
Dans ce chapitre
Un prototype fonctionne sur une machine, avec une clé personnelle et sans utilisateurs. Un service fonctionne sous charge, avec des quotas, une facture, une trace et quelqu’un que l’on réveille quand ça casse.
Ce chapitre traite du passage de l’un à l’autre.
Choisir la porte d’entrée
Claude est accessible par plusieurs canaux. Le modèle est le même : ce qui change est le contexte contractuel et la disponibilité des fonctionnalités.
L’API directe d’Anthropic. Le canal de référence. Toutes les fonctionnalités y arrivent en premier. Facturation directe.
Les plateformes cloud — Amazon, Google, Microsoft. Le même modèle, servi dans votre environnement cloud, avec votre facturation, vos engagements de conformité, votre gestion d’identité et vos garanties de localisation.
Le choix se fait sur trois critères, dans cet ordre.
Vos contraintes contractuelles et réglementaires. Si votre organisation exige que tout passe par un fournisseur cloud sous contrat, la question est tranchée avant de commencer.
Les fonctionnalités dont vous avez besoin. Toutes ne sont pas disponibles partout. Certaines capacités récentes, certains outils serveur, certains endpoints n’existent que sur le canal direct, ou arrivent ailleurs avec du décalage.
La facturation. Consommer un budget cloud existant simplifie parfois considérablement l’achat.
Les limites de débit
Chaque organisation dispose de quotas : requêtes par minute, jetons d’entrée et de sortie par minute. Ils dépendent du palier d’usage et du modèle.
Trois choses à savoir.
Les quotas sont par modèle, ou par famille. Basculer d’un modèle à un autre ne puise pas forcément dans le même réservoir. C’est parfois une stratégie de contournement légitime, à condition de mesurer.
Un dépassement renvoie une erreur 429, accompagnée d’un en-tête indiquant le délai à attendre. Les bibliothèques officielles gèrent ce cas avec un recul exponentiel. Ne réimplémentez pas ce comportement ; réglez le nombre de tentatives si le défaut ne convient pas.
Les jetons comptent plus que les requêtes. Une application qui envoie de longs contextes atteint sa limite en jetons bien avant sa limite en requêtes. C’est encore un argument pour la mise en cache du chapitre 32.
Concevoir avec les quotas
Une file d’attente plutôt qu’un appel direct. Sur un service à charge variable, placer les requêtes dans une file permet de lisser et de dégrader proprement.
Le traitement par lot pour ce qui peut attendre. Il a ses propres quotas, distincts du temps réel — et il coûte deux fois moins cher.
Une réponse de repli. Quand le service est saturé, un message honnête vaut mieux qu’une page qui tourne : « la demande est en file d’attente, vous recevrez la réponse dans quelques minutes ».
Les clés et les environnements
Quelques règles qui évitent les incidents.
Une clé par environnement. Développement, recette, production. Une clé compromise se révoque sans arrêter le reste.
Jamais dans le code, jamais dans le dépôt. Variables d’environnement, coffre-fort de secrets, gestionnaire du fournisseur cloud.
Des espaces de travail séparés quand la console le permet, avec leurs propres limites : un traitement par lot qui s’emballe ne doit pas assécher le quota de votre service interactif.
Une rotation planifiée, et surtout : une procédure de révocation écrite et testée. Le jour où une clé fuite, on n’improvise pas.
Ce qu’il faut journaliser
Sur chaque appel, quatre informations, et pas plus.
L’identifiant de requête. Il permet de tracer un appel de bout en bout côté Anthropic. C’est la première chose demandée quand vous signalez un problème.
Le modèle utilisé. Indispensable quand vous en faites tourner plusieurs, ou quand un mécanisme de repli en change.
L’usage en jetons. Entrée, sortie, écriture et lecture de cache. C’est votre suivi de coût, et votre détecteur de dérive.
La raison d’arrêt. Une hausse des max_tokens signale des réponses tronquées ; une hausse des refus signale un changement d’usage ou de prompt.
journal.info(
"appel_claude",
extra={
"request_id": reponse._request_id,
"model": reponse.model,
"stop_reason": reponse.stop_reason,
"input_tokens": reponse.usage.input_tokens,
"output_tokens": reponse.usage.output_tokens,
"cache_read": reponse.usage.cache_read_input_tokens,
"cache_creation": reponse.usage.cache_creation_input_tokens,
},
)Ce qu’il ne faut pas journaliser : le prompt complet et la réponse complète. Ils contiennent souvent des données personnelles, et vous venez de les recopier dans un système de journalisation qui n’a pas été conçu pour en accueillir. Voir le chapitre 35.
Si vous avez besoin du contenu pour déboguer, journalisez-le séparément, avec une durée de rétention courte et un accès restreint.
Détecter la dégradation
C’est le point que la plupart des équipes ratent : elles savent détecter une panne, pas une baisse de qualité.
Quatre signaux qui se surveillent avec ce que vous journalisez déjà.
La distribution des raisons d’arrêt. Une hausse des troncatures ou des refus est un signal fort.
La longueur des réponses. Une dérive à la hausse ou à la baisse indique souvent qu’un prompt a changé, ou que les entrées ont changé de nature.
Le taux de lecture en cache. Une chute brutale signifie qu’un invalidateur s’est glissé dans le préfixe. Votre facture le confirmera.
Le taux de validation en aval. Si votre application valide les sorties — schéma, règles métier —, le taux d’échec est le meilleur indicateur de qualité dont vous disposez.
Le chapitre 36 va plus loin, avec des évaluations exécutées régulièrement.
La liste avant la mise en production
Sept questions. Toute case sans réponse écrite est un incident en attente.
| Question | Ce qu’il faut avoir |
|---|---|
| Où sont les clés ? | Coffre-fort, une par environnement, procédure de révocation testée |
| Quelles sont vos limites réelles ? | Mesurées, pas supposées, avec la marge par rapport au pic |
| Quel est le coût par requête ? | Mesuré sur du trafic réel, projeté au volume cible |
| Que se passe-t-il en saturation ? | File d’attente ou repli, jamais une page qui tourne |
| Comment détectez-vous une dégradation ? | Les quatre signaux ci-dessus, avec un seuil d’alerte |
| Que journalisez-vous, et pendant combien de temps ? | Métadonnées oui, contenu séparément et brièvement |
| Qui reçoit l’alerte, et que fait-il ? | Une procédure écrite, pas un nom dans une tête |
Mettre en production un assistant interne
La situation
Un assistant documentaire interne, testé par vingt personnes pendant un mois, doit passer à mille utilisateurs.
Ce que la mesure a révélé
Le suivi du prototype montre trois choses que personne n’avait anticipées.
Le taux de lecture en cache est de 30 %, pas des 90 % attendus : l’instruction système contenait le prénom de l’utilisateur. Un préfixe par personne, donc aucun partage. Le prénom part dans le message utilisateur.
Le pic d’usage est concentré entre 9 h et 10 h — quatre fois la moyenne. Dimensionner sur la moyenne aurait produit une saturation quotidienne.
Sept pour cent des réponses ont une raison d’arrêt max_tokens. Personne ne s’en était aperçu : les réponses paraissaient normales, simplement écourtées.
Les décisions
Une file d’attente avec dégradation explicite au-delà d’un seuil : « votre demande est en attente, comptez une minute ». Une réponse honnête vaut mieux qu’un délai inexpliqué.
Un max_tokens relevé, et une alerte si le taux de troncature dépasse 1 %.
Le traitement des questions non interactives — la réindexation nocturne de la documentation — bascule en lot, dans un espace de travail séparé pour ne pas puiser dans le quota du service interactif.
La journalisation
Métadonnées dans le système de journalisation standard, conservées un an. Contenu des échanges dans un stockage séparé, chiffré, conservé sept jours, accessible à deux personnes.
La détection de qualité
Un jeu de cinquante questions de référence est rejoué chaque nuit, et les réponses comparées à des attentes écrites. Une baisse déclenche une alerte. C’est le seul mécanisme qui attrape une dégradation liée à un changement de prompt ou de version de modèle.
Ce que ça a évité
Le premier jour, un pic à six fois la moyenne. La file a absorbé, quelques utilisateurs ont attendu une minute, et personne n’a vu d’erreur. Sans la mesure préalable, le service serait tombé à 9 h 15.
Ce qu’il faut retenir
Vérifier que c’est passé
3 questions. Rien n’est enregistré, rien n’est envoyé : c’est pour vous.
La liste avant la mise en production
Écrivez la liste de contrôle de votre propre mise en production : où sont les clés, quelles sont vos limites de débit réelles, quel est votre coût par requête mesuré, que faites-vous quand le service est saturé, comment détectez-vous une dégradation de qualité, et qui reçoit l’alerte. Toute case sans réponse écrite est un incident en attente.
Un indice, si vous bloquez
La question la plus souvent sans réponse est la cinquième : la plupart des équipes savent détecter une panne, pas une dégradation de qualité.