Ce que coûte un agent, et pourquoi on le découvre tard
L’économie d’un agent obéit à une règle simple que les dossiers de projet oublient presque toujours : le coût suit le nombre d’étapes. Un agent qui enchaîne douze appels pour répondre à une question coûte environ douze fois ce que coûterait un appel unique, et ce facteur ne se négocie pas. À cent requêtes par jour, personne ne le remarque, parce que tout est abordable à ce volume. À cent mille, il décide de l’existence du système. Le piège tient à ce que l’écart entre ces deux situations n’apparaît jamais pendant la phase où l’on prend les décisions de conception. Un pilote valide la faisabilité à un volume dérisoire, la conception est figée, et la facture complète arrive plusieurs mois plus tard, quand le système est en production et que les options disponibles sont toutes mauvaises. L’exercice qui évite cela prend dix minutes au moment de la conception, et il consiste à multiplier trois nombres qu’on connaît déjà.
Le calcul, en dix minutes
Trois nombres suffisent. Le coût d’un appel unique, que le fournisseur publie. Le nombre d’étapes attendu, qu’un prototype donne en une journée. Et le volume quotidien, que le métier connaît.
L’erreur habituelle porte sur le deuxième. On retient le meilleur cas, trois ou quatre étapes, parce que c’est ce qu’on a observé en essayant le système sur des exemples faciles. La distribution réelle comporte une queue longue : quelques pour cent des cas prennent beaucoup plus d’étapes, et ces cas pèsent lourd dans la moyenne.
La bonne pratique consiste à retenir la médiane observée sur un échantillon représentatif, puis à calculer séparément ce que coûte le décile supérieur. Si ce décile représente à lui seul une fraction importante du total, c’est le premier endroit à optimiser, et souvent le seul nécessaire.
Réduire le nombre d’étapes améliore tout
Une propriété agréable de ce paramètre est qu’il n’oppose pas le coût à la qualité. Un agent qui prend douze étapes là où la conception aurait pu en imposer trois n’est pas plus juste, il est moins contraint.
Réduire ce nombre améliore simultanément quatre choses : la facture, la latence, la prévisibilité, et la facilité de diagnostic quand quelque chose se passe mal. C’est un des rares arbitrages de ce métier où toutes les dimensions vont dans le même sens.
Les moyens sont connus. Placer l’agent à la seule étape qui varie réellement plutôt que sur l’ensemble du processus. Réduire le nombre d’outils, chaque outil supplémentaire allongeant les explorations. Et donner au système ce qu’il lui faut dès le départ plutôt que de le laisser le chercher en plusieurs étapes.
La variance, coût caché
Un agent ne coûte pas la même chose d’une exécution à l’autre pour une même entrée, puisque son chemin varie. Cette dispersion a deux conséquences budgétaires que les prévisions ignorent.
La première est qu’un budget fondé sur une moyenne sera dépassé une partie du temps, et la question utile est de savoir de combien. Un plafond d’étapes par exécution borne cette dérive et devrait figurer dans toute conception, autant pour le budget que pour la sécurité.
La seconde est qu’une modification apparemment anodine peut déplacer la distribution. Changer une consigne, ajouter un outil ou passer à une nouvelle version de modèle modifie la façon dont le système explore, et le coût par requête bouge sans que personne n’ait touché à l’architecture. C’est une raison de suivre cet indicateur en continu plutôt que de l’estimer une fois.
Le volume change la conclusion, pas la conception
Une même conception peut être parfaitement raisonnable à un volume et absurde à un autre, et c’est la seule variable que l’équipe technique ne maîtrise pas. Il vaut donc la peine de demander au métier, au cadrage, non pas le volume d’aujourd’hui mais celui prévu dans dix-huit mois si le système réussit.
Cette question a un effet secondaire utile. Elle oblige le métier à dire ce qu’il attend réellement du projet, et la réponse révèle parfois que le volume visé n’existera jamais, auquel cas la conception la plus simple suffit largement.
Quand le volume prévu est important, la conséquence n’est pas de renoncer mais de choisir une architecture qui s’y prête : moins d’étapes, un modèle plus petit sur les étapes qui ne demandent pas de finesse, et une mise en cache des réponses qui se répètent. Ces trois leviers, appliqués ensemble, changent l’ordre de grandeur de la facture sans changer ce que le système fait.
Comparer à ce qui existe aujourd’hui
La comparaison honnête met le coût complet du système face au coût complet du processus actuel, sur les mêmes cas. Trois postes sont régulièrement oubliés du côté du système.
La relecture humaine, qui subsiste dans presque tous les déploiements sérieux et qui représente souvent la moitié du gain annoncé. L’exploitation, c’est-à-dire le temps de quelqu’un pour surveiller, rejouer le jeu d’évaluation et traiter les incidents. Et le coût des cas que le système remonte plutôt que de traiter, qui reviennent à une personne.
Une fois ces trois postes comptés, beaucoup de projets restent nettement rentables et quelques-uns cessent de l’être. Savoir lesquels avant de construire vaut mieux que de le découvrir à la première facture complète, et c’est exactement ce que cet exercice de dix minutes permet.
