Coût, latence et fiabilité : mettre des agents en production

Votre agent support a répondu parfaitement à la question de démo. Puis vous l'avez activé pour de vrais clients, et vendredi il avait tourné 4 000 fois, coûté 600 $ et laissé douze utilisateurs face à un spinner pendant quatre-vingt-dix secondes avant de tomber en timeout.

Une démo qui marche une fois est un tour de passe-passe. Un produit, c'est ce qui marche encore à la centième exécution, dans le budget, sans se figer. Cette leçon couvre les leviers concrets pour y arriver.

Les trois choses qui cassent en production

Quand vous faites passer un agent de « ça marche sur mon portable » à « ça encaisse du trafic réel », trois problèmes apparaissent :

• Coût : chaque étape d'un agent envoie du texte à un modèle, et vous payez à l'unité de texte. Un agent bavard brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ûle vite de l'argent.
• Latence : le temps d'attente de l'utilisateur. Les agents qui « réfléchissent » sur plusieurs étapes sont lents.
• Fiabilité : est-ce qu'il termine, ou est-ce qu'il se fige, boucle indéfiniment, ou plante sur une mauvaise réponse d'outil ?

Quelques définitions avant d'aller plus loin :

• Agent : un programme qui utilise un grand modèle de langage pour décider de l'action suivante, en appelant souvent des outils (une recherche, une requête en base, un envoi d'e-mail) dans une boucle jusqu'à ce que la tâche soit terminée.
• TokenTokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → : l'unité de facturation des modèles. Environ 3 à 4 caractères, soit à peu près 0,75 mot. « Réinitialiser mon mot de passe » fait environ 4 tokens.

Levier 1 : timeouts et retries

Les outils échouent. Une base de données est lente, une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → renvoie une erreur, un appel réseau cale. Sans protection, votre agent attend indéfiniment ou meurt au premier accroc.

Deux règles règlent l'essentiel :

Timeout : fixez une attente maximale pour chaque appel externe. Si un outil ne répond pas en, disons, 10 secondes, arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtez d'attendre et passez à la suite.

Retry : si un appel échoue, réessayez un petit nombre de fois, en attendant un peu plus longtemps entre chaque tentative (c'est l'*exponential backoff* : attendre 1s, puis 2s, puis 4s). La plupart des échecs sont temporaires et disparaissent à la deuxième tentative.

import time

def call_tool_with_retry(tool_fn, args, retries=3, timeout=10):
    for attempt in range(retries):
        try:
            return tool_fn(args, timeout=timeout)
        except (TimeoutError, ConnectionError):
            if attempt == retries - 1:
                return {"error": "tool unavailable, continue without it"}
            time.sleep(2 ** attempt)  # 1s, puis 2s, puis 4s

Regardez la dernière ligne : au lieu de planter, elle transmet au modèle un message clair. Un bon agent sait souvent s'en remettre (« Je n'ai pas pu joindre le système de commandes, j'ai donc demandé son numéro de commande à l'utilisateur »).

Pour un panorama solide et indépendant des fournisseurs sur les patterns de retry, voir les recommandations SRE de Google sur handling overload and retries.

Levier 2 : plafonner la boucle

Un agent tourne en boucle : réfléchir, appeler un outil, lire le résultat, réfléchir à nouveau. Le danger, c'est la boucle qui ne s'arrête jamais. Le modèle continue de décider « il me faut encore une recherche » et vous continuez de payer.

Plafonnez toujours le nombre d'itérations. Si l'agent n'a pas terminé en, disons, 8 étapes, arrêtez et renvoyez soit la meilleure réponse obtenue, soit un transfert vers un humain.

MAX_STEPS = 8

def run_agent(user_input):
    messages = [{"role": "user", "content": user_input}]
    for step in range(MAX_STEPS):
        response = model.respond(messages, tools=TOOLS)
        if response.is_final:
            return response.text
        result = call_tool_with_retry(response.tool, response.args)
        messages.append({"role": "tool", "content": result})
    return "I couldn't resolve this fully. Escalating to a human agent."

La ligne for step in range(MAX_STEPS) constitue à elle seule le filet de sécurité. Tous les grands frameworks d'agents (l'OpenAI Agents SDK, le Claude Agent SDK, l'ADK de Google) ont un réglage intégré pour cela, généralement appelé max turns ou max iterations. Réglez-le délibérément. La valeur par défaut est souvent plus élevée que ce que vous voulez.

Levier 3 : mamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →îtriser le coût en tokens

Vous payez deux choses : ce que vous envoyez au modèle (tokens d'input) et ce qu'il écrit en retour (tokens d'output). L'output coûte en général plusieurs fois plus cher par token que l'input.

Trois façons concrètes de réduire la facture :

Élaguez le contexte. Les agents accumulent l'historique : chaque résultat d'outil, chaque message passé. À l'étape 6, vous pouvez renvoyer 20 000 tokens de transcript à chaque appel. Résumez les anciennes étapes ou supprimez les résultats d'outils dont vous n'avez plus besoin.

Mettez en cache ce qui est stable. Votre system promptsystem promptLes instructions cachées qui définissent le comportement d'un assistant IA avant toute question : son rôle, son ton, ses limites et ses règles.Voir la définition complète → et vos définitions d'outils sont identiques à chaque appel. La plupart des fournisseurs proposent le *prompt caching*, qui facture une fraction du prix pour un input répété. L'activer tient souvent à une ligne de config et peut réduire le coût d'input de 50 à 90 %.

Demandez moins d'output. « Répondez en moins de 3 phrases » ou renvoyer des données structurées plutôt que de la prose réduit directement le côté output, le plus cher.

Levier 4 : utiliser un modèle plus petit pour les étapes de routine

C'est le plus gros levier que la plupart des équipes ratent. Vous n'avez pas besoin de votre modèle le plus puissant et le plus cher à chaque étape.

L'essentiel du travail d'un agent est routinier : classer une question, extraire un numéro de commande, décider quel outil appeler. Un petit modèle, rapide et bon marché, s'en sort très bien. Gardez le grand modèle pour l'étape réellement difficile, comme rédiger la réponse finale nuancée.

C'est ce qu'on appelle le model routing : un modèle bon marché fait le tri et n'escalade vers le modèle coûteux que si nécessaire.

def handle(query):
    # le modèle bon marché classifie
    category = small_model.classify(query, ["simple_faq", "complex_issue"])

    if category == "simple_faq":
        return small_model.answer(query)      # chemin bon marché
    else:
        return large_model.run_agent(query)   # chemin coûteux, seulement si nécessaire

Si 70 % de vos questions support portent sur des réinitialisations de mot de passe et des statuts de livraison, les router vers un petit modèle signifie que vous ne payez le prix fort que sur les 30 % restants.

Avant / après : le coût par résolution d'un agent support

Voici un exemple calibré sur du réel. Un agent support traite 10 000 tickets par mois. La métrique qui compte est le coût par résolution : dépense totale divisée par le nombre de tickets résolus sans intervention humaine.

Avant (build naïf) :

• Chaque ticket utilise le grand modèle à toutes les étapes.
• Historique complet de la conversation renvoyé à chaque étape. Pas de cache.
• Pas de plafond d'itérations, donc les tickets bloqués bouclent jusqu'à 20 fois.
• Moyenne : 15 appels modèle par ticket, ~18 000 tokens chacun.

Cela revient à environ 0,42 $ par ticket, et environ 8 % des tickets bouclent jusqu'au timeout, donc ne se résolvent pas du tout. Certains utilisateurs attendent plus de 60 secondes.

Après (build production) :

• Un petit modèle fait le tri. 65 % des tickets (FAQ, vérifications de statut) se résolvent sur le chemin bon marché.
• Prompt caching sur le system prompt et les outils.
• Contexte élagué : anciens résultats d'outils résumés après 3 étapes.
• Plafond d'itérations à 8, avec escalade propre vers un humain.

Nouveaux chiffres :

Même agent, même qualité de réponses, environ 4x moins cher et bien plus rapide. Rien de tout cela n'a exigé un modèle plus intelligent. Cela a exigé de la discipline sur le *quand* utiliser le modèle coûteux, et des garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → pour que rien ne s'emballe.

Mesurez avant d'optimiser

Ne devinez pas où passent l'argent et le temps. Activez le tracing (un log de chaque étape : quel modèle, combien de tokens, combien de temps, succès ou échec). Tous les grands SDK d'agents incluent le tracing, et des outils ouverts comme Langfuse vous donnent un dashboard indépendant des fournisseurs.

Cherchez d'abord les gains évidents :

• Quelle étape consomme le plus de tokens ? (En général un contexte surchargé.)
• Quel outil est le plus lent ? (Ajoutez un timeout.)
• Combien d'étapes prend un ticket typique ? (Si c'est proche de votre plafond, creusez.)

Optimisez la ou les deux premières lignes. Ignorez le reste tant que ça ne compte pas.

Une checklist de mise en production simple

Avant de diriger du trafic réel vers un agent, vérifiez :

1. Chaque appel d'outil a un timeout et une limite de retries.
2. La boucle de l'agent a un plafond d'itérations strict avec un fallback propre.
3. Le prompt caching est activé et le contexte est élagué.
4. Les étapes de routine utilisent un modèle plus petit.
5. Le tracing est activé pour voir le coût et la latence par exécution.

Les détails propres à chaque fournisseur (noms exacts des réglages, activation du caching) figurent dans les blocs d'approfondissement OpenAI, Claude et Gemini. Les leviers ci-dessus valent pour tous.

Points clés

• Plafonnez la boucle et posez des timeouts sur chaque outil. Ces deux garde-fous évitent les deux pires pannes en production : le coût qui s'emballe et les requêtes qui se figent.
• Routez selon la difficulté. Un modèle bon marché et rapide pour le tri et les étapes de routine ; le modèle coûteux réservé au travail réellement difficile. C'est en général votre plus gros gain de coût.
• Suivez le coût par résolution, pas le coût par appel. Il relie la dépense à la valeur effectivement délivrée et met en évidence les tickets qui brûlent de l'argent sans aboutir.
• Élaguez le contexte et activez le prompt caching. Les agents renvoient discrètement des historiques qui gonflent ; ces deux gestes réduisent fortement le coût d'input pour un effort minime.
• Activez le tracing avant d'optimiser. Mesurez quelle étape est lente ou coûteuse, corrigez la première ou les deux premières, et arrêtez-vous là.