Ingénierie des Coûts

L'ingénierie des coûts d'un système multi-agents

18 juillet 2026 · 5 min de lecture

Le coût d'un système multi-agents est une propriété de design. Il se décide quand vous choisissez quel modèle exécute quelle étape, ce qui se passe en cas d'échec, et ce que fait votre infrastructure quand personne ne l'utilise. Découvrir le coût après coup, sur la facture, signifie que le design a sauté une exigence.

Construire Proposal Architect pour le Google for Startups AI Agents Challenge 2026 a posé la question très tôt, parce qu'une démo publique a le pire profil de coût qui soit : un trafic en rafales, non authentifié, contre un backend d'inférence coûteux. Voici les leviers qui ont compté.

Router les modèles là où la qualité se compose

Un pipeline multi-agents n'a pas besoin d'un appel à un modèle premium à chaque étape. La plupart des étapes (extraction, ancrage, composition) tournent bien sur des modèles rapides et peu coûteux. Nous avons réservé le tier premium à exactement une étape, l'agent architecte, parce que la qualité de l'architecture se propage à tout ce qui suit : l'estimation, le prix, la narration. Un appel coûteux qui améliore les appels bon marché autour de lui est un bon échange ; un pipeline d'appels coûteux n'est une subvention pour personne.

Borner le pire cas, pas la moyenne

Les retries sont l'endroit où les budgets meurent en silence. Un pipeline qui relance tout à chaque échec a un coût de pire cas plusieurs fois supérieur à sa moyenne. Deux bornes changent la donne : un deadline dur par appel de modèle et par exécution (un appel suspendu brûle du temps, pas du budget), et un retry par étape qui réutilise l'état amont, de sorte qu'un échec du compositeur coûte un appel de compositeur, pas une ré-exécution complète du pipeline.

Ramener le calcul à l'arrêt à zéro et rendre le pic fini

Les frontends d'inférence serverless se rentabilisent sur les démos et les produits naissants : le scale-to-zero signifie que le calcul du frontend d'inférence tombe à zéro à l'arrêt, et un plafond d'instances signifie qu'un pic de trafic (ou une tentative d'abus) a un plafond connu. Ajoutez un throttle applicatif devant les appels de modèles et les trois limites se composent : le calcul à l'arrêt est gratuit, les rafales sont bornées, et un seul acteur ne peut pas monopoliser le budget.

Traiter les alertes de facturation comme de l'architecture

Une alerte de budget n'est pas un détail d'exploitation ; c'est le détecteur de fumée du système, et sa place est dans la revue de design, à côté de la table des timeouts. Si l'alerte se déclenche un jour, une borne ci-dessus a échoué, et c'est un signal d'ingénierie, pas de comptabilité.

Ce que coûte réellement une exécution

La réponse honnête est un ordre de grandeur, pas un nombre : une exécution bornée est une poignée d'appels de modèles, la plupart sur des tiers bon marché, avec exactement un appel premium. Le chiffre précis bouge avec les modèles, la taille des prompts et la longueur des sorties, et toute précision décimale que nous pourrions imprimer ici serait fausse. Ce que le design garantit, c'est la forme : le coût par exécution est borné, connu d'avance, et dominé par le seul appel que vous avez choisi de rendre coûteux.

La leçon

L'ingénierie des coûts pour les agents est de l'ingénierie ordinaire : router par valeur, borner les modes d'échec, plafonner l'infrastructure et instrumenter l'argent. Les équipes qui traitent le coût comme une propriété émergente sont surprises. Celles qui le traitent comme une exigence ne le sont pas.