La taxe que personne n'avait budgétée est en train de couler les agents IA d'entreprise
Il existe un moment particulier dans l'adoption des technologies d'entreprise où l'enthousiasme se transforme en obligation comptable. Avec les agents d'intelligence artificielle intégrés dans les produits d'entreprise, ce moment est arrivé plus tôt que la plupart des équipes techniques ne l'avaient anticipé, et le mécanisme qui l'a déclenché n'était ni le mauvais modèle de langage ni l'absence de données. C'était une décision d'architecture que personne n'avait présentée comme telle.
L'appeler « taxe de contexte » — comme le font les ingénieurs d'Anthropic et un nombre croissant d'analystes — est une dénomination précise. Non pas parce qu'elle est métaphorique, mais parce qu'elle fonctionne exactement comme une taxe : invisible dans la transaction individuelle, dévastatrice dans l'agrégat. Chaque fois qu'un agent d'entreprise reçoit un HTML brut de 150 kilo-octets pour traiter une question portant sur cinq lignes de données, l'entreprise paie environ 37 500 tokens d'inférence qui ne produisent aucune valeur. Multipliez cela par chaque utilisateur actif, par chaque session, par chaque mois de montée en charge, et ce qui ressemble à un détail technique devient l'élément qui détermine si la marge brute du produit survit.
Les données qui circulent dans l'écosystème le confirment sous différents angles. L'analyse de Splunk sur les coûts des agents isolés a documenté comment une seule interaction de support client est passée de quatre centimes de dollar à un dollar vingt sur trois ans, même pendant que les prix par token baissaient. Le mécanisme à l'origine de cette augmentation n'était pas l'inflation des fournisseurs : c'était le volume de contexte que l'agent retransmettait à chaque étape du flux. Une étude de l'Université Concordia a quantifié le ratio entre tokens d'entrée et de sortie dans les flux agentiques à 2:1, et a constaté que la seule révision de code consommait 59 % de chaque token dépensé. Ce sont des chiffres qui transforment le budget d'infrastructure en quelque chose de très différent de ce qui figurait sur la feuille de route.
Ce qui se décide sans dire qu'on est en train de décider
L'argument central qu'introduit l'analyse du Forbes Technology Council — rédigée par un ingénieur logiciel chez Walmart Global Tech qui dirige la construction d'expériences agentiques pour les vendeurs sur marketplace — ne porte pas sur les outils ni les fournisseurs. Il porte sur trois décisions d'architecture que les équipes prennent par omission, avant que quiconque les nomme lors d'une réunion de conception.
La première est la représentation que reçoit le modèle. Entre HTML brut, captures d'écran et fragments sémantiques, il existe une différence de 30 à 50 fois en coût par tâche, avec des effets sur la précision qui vont à l'encontre de ce que l'intuition suggère. La recherche d'Amazon Science sur l'agent AgentOccam a documenté une amélioration de 29,4 % sur le benchmark WebArena en passant d'une représentation visuelle à un arbre d'accessibilité structuré. Le modèle n'a pas été modifié. Ce qu'il voyait a changé.
La deuxième décision est le moment de la capture. Lorsqu'un agent prend l'état de la page au moment du chargement et non au moment de l'envoi, il capture le squelette de chargement, pas les données que l'utilisateur est en train de regarder. Le rapport décrit des cas où la capture instantanée se déclenchait 1 500 millisecondes avant que l'API réponde. L'agent répondait avec confiance depuis une page vide. Ce n'est pas une hallucination au sens technique : c'est un contexte incorrect servi au mauvais moment.
La troisième est ce qui n'est tout simplement pas envoyé. Un classificateur léger qui achemine avant de récupérer peut éliminer entre 70 % et 85 % des captures instantanées de contexte dans les flux réels. Un utilisateur qui demande comment mettre à jour une configuration en lot a besoin de documentation, pas d'une photographie de sa vue de données actuelle. Ce sont des tokens qui ne seront jamais dépensés.
Ce qui rend ces trois décisions particulièrement coûteuses n'est pas qu'elles soient de mauvaises décisions : c'est que personne ne les présente comme des décisions. Elles s'exécutent par défaut. Le HTML brut est l'option qui ne nécessite aucun prétraitement. La capture au chargement est ce que le framework fait automatiquement. Envoyer tout le contexte disponible semble « sûr ». Cette inertie a un prix.
La différence entre un produit interne et un produit de marché
L'analyse distingue avec précision un point que la plupart des discussions sur les agents d'entreprise ne séparent pas avec suffisamment de clarté : il existe une différence structurelle entre un agent qui sert des employés internes et un agent intégré dans un produit commercial multi-tenant.
Une équipe informatique interne peut absorber une architecture de contexte défaillante. Elle redéploie. Elle ajuste. Elle dispose d'un rayon d'impact contrôlé. Un fournisseur de logiciels B2B qui intègre un assistant IA dans son produit facture par siège, pas par infrastructure. Chaque inefficacité dans la représentation du contexte se multiplie sur l'ensemble de la base de clients simultanément. Le coût par utilisateur actif que la note décrit — passant de 0,40 à 1,10 dollar mensuel en huit semaines de disponibilité générale — n'est pas l'anecdote d'un déploiement mal calibré : c'est la mécanique de ce qui se produit lorsqu'on monte en charge sans avoir audité l'architecture de contexte au préalable.
Chroma a publié en 2025 une évaluation de 18 modèles de frontière qui ajoute une autre dimension au problème. La précision ne se dégrade pas seulement lorsque le contexte est coûteux : elle se dégrade lorsque le contexte est étendu. Plus le volume de contexte d'entrée est important, plus la perte de précision est grande dans les tâches de contexte long, indépendamment du modèle. La taxe de contexte n'est pas uniquement un problème de marge. C'est un problème de produit.
Cela recadre la discussion d'une manière que les comités d'approbation de projets articuler rarement. Lorsqu'on évalue l'opportunité d'intégrer un agent IA dans une plateforme SaaS, la conversation porte généralement sur le modèle, le fournisseur et la sécurité des données. L'architecture de représentation du contexte n'apparaît presque jamais dans cette conversation comme une variable ayant des implications sur la marge brute. Elle apparaît après, dans le post-mortem, lorsque la fonctionnalité promettait une expansion des marges et les a livrées comprimées.
Le marché qui vient après la première vague d'échecs
La statistique de Gartner projetant l'annulation de plus de 40 % des projets agentiques avant fin 2027 n'est pas simplement un avertissement sur la maturité technologique. C'est une description anticipée du processus de filtrage qui suit tout cycle d'adoption où les coûts cachés dépassent les projections initiales. L'analyse du MIT qui a constaté que 95 % des déploiements d'IA générative n'ont produit aucune valeur commerciale mesurable documente la même pression sous un autre angle.
Ce qui n'est toujours pas clair dans le débat public sur les agents, c'est de savoir si les organisations qui annulent des projets le font pour des raisons liées au modèle ou pour des raisons liées à l'architecture. Si la majorité des échecs trouve son origine dans des décisions de contexte — représentation, moment de la capture, volume envoyé — alors le problème n'est pas que les agents ne fonctionnent pas. C'est que les équipes qui les construisent mesurent les mauvaises variables.
Hyland, dans son analyse sur le retour sur investissement de l'IA en entreprise, calcule qu'une couche de contexte d'entreprise unifiée peut générer jusqu'à 10,3 fois le retour sur investissement en IA et automatisation. Le mécanisme qu'il décrit est direct : les équipes qui reconstruisent des intégrations, des mappings et des règles métier pour chaque nouvel agent paient une taxe de fragmentation avant même que l'agent commence à fonctionner. Chaque agent hérite de la dette d'architecture du précédent. La mise à l'échelle ne résout pas ce problème : elle l'amplifie.
La transition qui se profile n'est pas entre des modèles de langage plus ou moins puissants. Elle oppose les organisations qui traitent l'architecture de contexte comme une variable d'infrastructure — à optimiser quand il y a du temps — à celles qui la traitent comme une variable de marge brute à concevoir avant le premier déploiement. La différence entre ces deux positions n'apparaît pas lors des premiers mois de pilote. Elle apparaît lorsque la base d'utilisateurs croît et que le coût par requête devient la métrique qui gouverne si la fonctionnalité peut exister.
Le prochain front n'est pas le modèle, c'est celui qui gouverne le contexte
La guerre des modèles de langage a généré une illusion compréhensible : que le problème central des agents d'entreprise était la qualité de l'inférence. Cette illusion a été utile pendant la phase d'expérimentation, lorsque les entreprises avaient besoin de valider que les modèles pouvaient faire quelque chose d'utile dans leurs domaines. Cette phase est terminée.
Ce qui commence maintenant — et ce qui rend l'analyse sur la taxe de contexte pertinente au-delà de ses détails techniques — c'est la compétition pour savoir qui construit et gouverne la couche de contexte d'entreprise. Non pas le modèle qui raisonne, mais l'infrastructure qui décide ce que le modèle voit, quand il le voit et ce qu'il n'a jamais besoin de voir.
Les signaux sont déjà visibles. L'argument de CIO Dive selon lequel les agents doivent aller vers les données plutôt que les données voyager vers les agents pointe vers le même nœud. La proposition de Seekr de mesurer le coût par réponse vérifiable — plutôt que le coût brut par token — introduit une métrique qui rend la taxe de contexte transparente dans le compte de résultats. Les classificateurs de routage préalables à la récupération que décrit l'analyse de Forbes sont un composant qui n'a pas encore de nom de marché consolidé, mais qui représente une fonction que les plateformes agentiques matures devront offrir de manière native.
Pour les dirigeants qui sont au cœur de décisions d'architecture en ce moment même, la leçon opérationnelle est plus étroite que n'importe quel cadre stratégique. Le modèle n'est pas le goulot d'étranglement. La représentation du contexte l'est. Et c'est une variable de conception, pas une décision de fournisseur, ce qui signifie que la responsabilité de ses conséquences est interne. Les organisations qui construiront cette couche avec un critère de marge en 2026 disposeront de données de coût par requête lorsque le marché commencera à demander des comptes en 2027. Celles qui ne l'auront pas fait seront en train d'expliquer pourquoi la fonctionnalité IA qui promettait d'étendre les marges s'est finalement révélée être leur principale source de compression.
