IA : l’inférence et le contexte pèsent sur la facture

La facture de l’IA ne s’arrête pas à l’entraînement. À l’échelle, le prix par token, la longueur du contexte, la taille des modèles et l’architecture des agents font varier le coût réel des usages. Quatre couches industrielles se partagent, différemment, dépenses et valeur, tandis que la baisse des prix unitaires ne garantit pas une dépense totale moindre.

Des coûts unitaires en baisse, mais des budgets qui peuvent grimper

Le coût d’une capacité donnée d’IA a diminué rapidement, porté par des modèles plus efficaces, des matériels en progrès, des techniques d’inférence en amélioration et une concurrence qui tire les prix vers le bas. Pour autant, un coût unitaire plus faible ne signifie pas nécessairement une dépense totale plus faible. Quand un service devient moins cher, son usage augmente, phénomène observé depuis des décennies en informatique. Un modèle peut coûter dix fois moins à exécuter, mais si l’usage est multiplié par vingt, la dépense totale de calcul grimpe tout de même. Dans ce contexte, le prix d’un appel d’API n’est pas l’indicateur le plus pertinent : la bonne question est la quantité de travail utile obtenue par dollar investi. À mesure que l’IA passe de l’expérimentation à la production, comprendre cette économie compte autant que comprendre les modèles.

Qui paie et qui encaisse : quatre couches, quatre réalités

La chaîne de valeur de l’IA s’organise en quatre couches aux structures de coûts distinctes. Les fabricants de puces vendent le matériel requis quel que soit le modèle dominant ; il importe peu, par exemple, que OpenAI, Anthropic ou Google l’emportent tant que des entraînements continuent. Les fournisseurs de cloud louent centres de données, réseau et capacité GPU, et peuvent bénéficier de la demande sans bâtir un modèle gagnant. Les entreprises de modèles absorbent des coûts lourds d’entraînement, de recherche et d’infrastructure d’inférence, sur un marché qui évolue tous les quelques mois. Enfin, la couche applicative s’appuie sur des modèles existants pour se concentrer sur des problèmes spécifiques, sans entraîner de modèle de base depuis zéro. Dans ce paysage, l’entreprise qui construit le produit n’est pas nécessairement celle qui capte le plus de valeur ; l’issue dépend de la couche considérée et évoluera probablement avec les prix et la technologie.

L’inférence facture chaque échange : tokens, taille des modèles et échelle

Une fois un modèle disponible, chaque utilisation a un coût : c’est l’inférence. À chaque requête, le modèle traite des entrées, effectue de nombreux calculs et produit des sorties, ce qui explique une facturation par token, approximativement un petit morceau de texte. Plus de texte en entrée et en sortie signifie plus de calcul, et les modèles plus grands coûtent davantage par token, indépendamment de la question posée. Des conversations longues et des modèles de grande taille deviennent donc rapidement coûteux. À l’échelle de milliards de requêtes, des coûts unitaires a priori modestes s’additionnent. L’entraînement est ponctuel, tandis que l’inférence ne s’arrête jamais vraiment.

Le prix oublié : le contexte, surtout avec des agents

Passer d’applications de chat simples à des agents opérationnels fait émerger un coût de contexte. Un agent transporte l’historique, des instructions système, des documents récupérés, des résultats d’outils, des recherches en base et parfois les sorties d’autres agents, et la plupart de ces éléments sont renvoyés au modèle à chaque étape. S’il effectue 10 appels en traînant un contexte volumineux identique, on paie pour retraiter plusieurs fois les mêmes informations. Un agent mal conçu transporte un contexte inutile à chaque étape, alors qu’un agent bien conçu ne conserve que ce qui est utile.

Réduire la facture : cache, gestion du contexte et context mesh

Plusieurs décisions d’ingénierie pèsent sur les dépenses. La mise en cache des prompts évite de retraiter des composantes constantes, comme des instructions système, des définitions d’outils ou un document de référence. La mise en cache des réponses permet de restituer une réponse déjà générée à des questions similaires. La gestion du contexte consiste à décider combien de messages conserver, quel niveau de détail d’un appel d’outil transmettre ou quand résumer une séquence de conversation ; à grande échelle, ce sont aussi des décisions économiques. Grâce à MCP, les agents bénéficient d’une méthode unifiée pour accéder aux outils, mais dans une structure réunissant plusieurs centaines d’agents, des accès multiples et superposés aux mêmes systèmes peuvent apparaître : il est possible que deux agents accèdent au même dossier client, sollicitent la même API et conservent chacun leur propre version. Ce type de duplication représente un détail négligeable à faible échelle, mais devient un enjeu de coûts et d’architecture lorsqu’il se généralise. Un context mesh, couche partagée entre agents et outils, proche d’une API gateway pour des services, intercale une médiation unique entre agents et backends. Les économies attendues proviennent d’une découverte d’outils facilitée et de la réduction du travail dupliqué.

Déployer en interne : limites, architecture et retour utile par euro

Dans un produit, le coût finit toujours par se manifester : des limites d’usage existent parce que l’inférence n’est pas gratuite, et la mise en cache évite de retraiter deux fois la même chose. La gestion du contexte compte, car chaque token inutile est tout de même facturé, et l’architecture des agents influe sur la dépense : un agent effectuant dix appels d’outils superflus est plus lent et consomme plus. Pour une adoption interne, l’enjeu est de savoir si l’IA accomplit une tâche de façon suffisamment fiable, rapide et économique par rapport aux alternatives. Rien n’est magique ni gratuit : derrière les démonstrations se trouvent des coûts d’infrastructure, des contraintes réelles et des incitations concurrentielles.