Mercury Flux : La couche de routage IA derrière nos agents commerciaux

Voici une question à laquelle chaque entreprise déployant des agents IA sera confrontée dans les douze mois : lorsque vous avez cinq agents en fonctionnement — un assistant d'achat, un gestionnaire de catalogue, un analyste, un rédacteur, un bot de support — quel modèle chacun utilise-t-il ?

La réponse par défaut est le modèle que l'équipe qui l'a construit a bien aimé. Cinq applications, cinq choix de modèles codés en dur, cinq copies de la même clé API dans cinq fichiers .env, cinq factures invisibles. Lorsqu'un fournisseur a une panne, cinq applications échouent indépendamment. Lorsque le service financier demande combien coûte l'IA par ligne de produit, personne ne peut répondre.

Nous avons refusé d'accepter cette architecture, alors nous avons construit la couche qui la corrige. Voici l'histoire de Mercury Flux — notre moteur de routage de modèles — et les agents commerciaux qui fonctionnent dessus. C'est aussi un aperçu de la façon dont nous déployons l'IA agentique pour les clients d'entreprise.

TL;DR : Intégrer un modèle dans chaque application d'IA est le nouveau fait d'intégrer des mots de passe dans le code source. Mercury Flux est une couche de routage IA qui se situe entre chaque agent et chaque fournisseur de modèles — Gemini, GLM, Grok, Kimi, n'importe lequel d'eux : chaque application s'authentifie avec sa propre clé, obtient sa propre table de routage (type de tâche → modèle → chaîne de secours) et rapporte sa propre utilisation de jetons. Nos agents commerciaux — un assistant d'achat orienté client et un agent marchand en back-office où chaque écriture attend l'approbation humaine — fonctionnent sur cette pile à environ $0.07 par million de jetons mélangés, soit environ 2 % du coût de l'API de détail. La même pile alimente les pipelines SEO et GEO derrière notre travail de visibilité AI. Le routeur décide du modèle. Les applications ne le savent jamais. C'est le but.

Je suis James, PDG de Mercury Technology Solutions. Nous construisons des ponts AI-humain pour les entreprises, et nous gérons notre propre flotte d'agents à une échelle qui rend les décisions d'architecture non optionnelles — environ 18 milliards de jetons par mois. Flux est le moteur de routage qui rend cela abordable, observable et sous contrôle. Aujourd'hui, je vais vous montrer ce qu'il fait, et pourquoi les agents de commerce sont son premier véritable client.

Le Problème : Éparpillement des Modèles

La pile d'applications AI de 2026 a une couche manquante, et la plupart des équipes le ressentent sans pouvoir le nommer.

Vous avez des fournisseurs de modèles — d'excellents, qui se multiplient : Google, OpenAI, Anthropic, et une vague de challengers solides. Vous avez des cadres d'agents. Ce qui manque, c'est le morceau qui décide quel modèle, pour quelle charge de travail, à quel coût, avec quel plan de secours, facturé à qui.

Sans cette couche, chaque application devient sa propre décision de routage, prise une fois, par un développeur, dans le code. Les conséquences s'accumulent discrètement :

• Cécité aux coûts.Cinq applications, cinq comptes de fournisseur, aucune vue unifiée. Personne ne peut dire combien coûte l'assistant d'achat par rapport au bot de support.
• Éparpillement des clés.Chaque application détient des clés brutes de fournisseur. En faire tourner une signifie une chasse à travers chaque dépôt. Une fuite est une fuite de compte complet.
• Pas de basculement.Le fournisseur a une mauvaise après-midi, et chaque application qui l'a codé en dur tombe avec elle.
• Verrouillage du modèle.Changer une charge de travail vers un modèle meilleur ou moins cher signifie toucher au code de l'application — donc cela n'arrive pas, et vous payez trop cher pour toujours.

Ce n'est pas que les modèles ne soient pas assez bons ; c'est que l'architecture n'a aucune capacité de choix.

Flux de Mercure: La couche qui choisit

Flux est une fine couche impitoyable entre vos agents et les fournisseurs de modèles. Le design se résume en un paragraphe :

Chaque application s'authentifie auprès de Flux avec sa propre clé — jamais une clé de fournisseur. Chaque requête porte un nom de route au lieu d'un nom de modèle : boucle-outil pour le travail d'appel d'outils, texte-long pour la rédaction, analyse pour un raisonnement approfondi. Flux résout le chemin par rapport à la table de cette application — une chaîne ordonnée comme Grok pour la discipline des outils, GLM comme solution de secours — ajoute les véritables identifiants du fournisseur et transfère l'appel. Chaque demande est enregistrée avec une comptabilité par application et par route. Les fournisseurs tombent en panne, Flux bascule. Les modèles changent de prix, vous éditez une table. Les applications ne s'en aperçoivent jamais.

Pensez-y comme au panneau électrique pour l'IA : une alimentation des services publics (les fournisseurs), un disjoncteur pour chaque circuit (les applications), et un compteur sur chaque ligne. Vous ne refaites pas le câblage de la maison pour éteindre une lampe.

L'économie provient du routage lui-même. Les boucles d'outils fonctionnent sur des modèles d'IA choisis pour la discipline d'appel de fonction. La génération de long format fonctionne là où le coût par jeton est le plus bas. Le raisonnement difficile obtient le modèle de pointe uniquement lorsque la tâche en a réellement besoin. À travers notre flotte — agents de commerce, pipelines de contenu SEO, les audits GEO que nous expédions à des clients d'entreprise — cela se cumule à ce tarif de 0,07 $ par million de jetons : deux ordres de grandeur en dessous de ce que le même volume de LLM coûte à des prix de détail premium. Une décision de routage prise une fois, dans une table, au lieu de jamais, dans le code.

Les premiers locataires : agents de commerce

La première charge de travail de production de Flux est une paire d'agents de commerce que nous avons construits pour des déploiements de détail, sur un plan de référence ouvert que nous avons durci et étendu avec notre propre runtime.

L'agent d'achat est celui qui fait face au client. Il recherche dans le catalogue, compare les options, planifie les achats, remplit le panier et répond aux questions sur les commandes et les politiques — avec mémoire de ce que le client lui dit. C'est la réponse du magasin au changement qui se produit en ce moment : les acheteurs qui demandaient autrefois à Google "meilleure tente pour deux personnes" demandent de plus en plus directement à ChatGPT, Perplexity ou Gemini et s'attendent à ce que l'assistant du magasin soit plus précis qu'un résultat de recherche. Il est rapide, patient et ne se fatigue jamais de "lequel de ces deux est mieux pour un petit balcon ?"

L'agent marchand est celui du back-office. Il explique les performances, maintient les annonces, agit sur les alertes d'inventaire, ajuste les prix, rédige des campagnes. Et voici la partie qui compte pour les entreprises : chaque écriture qu'il effectue est mise en scène, pas exécutée. Un changement de prix, un réapprovisionnement, une modification d'annonce — chacun arrive comme un changement proposé qui attend qu'un humain l'approuve via une surface d'approbation. L'agent propose ; l'opérateur dispose.

L'architecture de sécurité en dessous est la partie dont nous sommes le plus fiers, car c'est la partie que les démonstrations ne vous montrent jamais :

• Portes de provenance.Le panier n'accepte que les produits qu'un outil de catalogue a réellement retournés lors de cette session. Le modèle ne peut pas halluciner un achat.
• Barrières au moment de l'application.Mouvement de prix trop profond, réapprovisionnement trop important, champ protégé touché — le changement est refusé, peu importe qui l'a approuvé.
• Contexte clôturé.Le texte tiers que l'agent lit est assaini et délimité afin qu'une description de produit malveillante ne puisse pas injecter d'instructions. L'agent lit le web ; le web ne peut pas lire l'agent.

C'est le pont AI-humain que nous construisons pour gagner notre vie : l'IA fait le travail, les humains approuvent les écrits.Pas un chatbot ajouté à une vitrine — un système où l'autonomie et la responsabilité sont séparées par conception.

Ce que le routage nous a apporté : Une comparaison en direct

Parce que Flux sépare le routage du code de l'application, nous avons exécuté la même charge de travail d'agent d'achat à travers deux modèles différents en modifiant une ligne de configuration. La différence était décisive.

Un modèle — fort en prose — a mal géré les contrats d'outils : appels de compétences malformés, recherches répétées, pas d'achat complété. L'autre a géré les mêmes schémas d'énumération proprement, a chargé ses instructions opérationnelles du premier coup et a complété le flux complet de recherche au panier — tout en obéissant correctement à une règle dans son manuel de compétences qui dit que la recherche présente les résultats avant d'écrire dans le panier. Même agent, mêmes portes, même invite. Seul le modèle différait, et le modèle est exactement ce que permet de changer une couche de routage.

Multipliez cette comparaison par chaque charge de travail, chaque client, chaque trimestre. Les modèles s'améliorent et se re-prixent constamment ; les équipes qui peuvent re-router en quelques secondes surpasseront toujours les équipes qui ont programmé une refonte pour le prochain sprint. Flux transforme le choix du modèle d'un engagement architectural en une ligne de configuration.

Pourquoi cela compte pour les entreprises

Si vous déployez une IA agentique — commerce ou autre — trois implications :

1. Le routage par application est un enjeu de base.La charge de travail décide du modèle d'IA : discipline des outils pour les agents, contexte long bon marché pour le contenu, frontière uniquement pour le jugement. Une couche de routage en fait une politique, pas un accident par application.
2. Les clés et les coûts doivent être au même endroit.Les applications s'authentifient auprès du routeur ; seul le routeur détient les identifiants du fournisseur. Le métabolisme des jetons est mesuré par application, par route — donc "quel est le coût de l'IA par ligne de produit ?" devient une requête, pas un audit judiciaire. Traitez-le comme une infrastructure de transformation numérique essentielle, pas comme un outil marketing.
3. L'autonomie nécessite des portes d'approbation.Les agents qui écrivent dans des systèmes de production — paniers, catalogues, prix — ont besoin de changements échelonnés et d'une approbation humaine comme caractéristiques architecturales, pas comme suggestions de prompt. Le plan de commerce que nous exécutons prouve que cela fonctionne sous une charge réelle d'appels d'outils.

Les 43 % de prospects qui tombent dans le fossé entre l'IA et l'humain ? Ils tombent parce que les entreprises déploient soit des systèmes entièrement humains (lents) soit entièrement IA (non responsables). Le pont est l'autonomie échelonnée : des machines qui fonctionnent, des humains qui approuvent, et une couche de routage qui maintient l'ensemble suffisamment abordable pour être réellement déployé — que la charge de travail soit le commerce, le SEO, ou les programmes GEO qui rendent une marque citée lorsque l'IA répond.

C'est Flux de Mercure. Un routeur. Chaque agent. Son propre modèle, sa propre facture, son propre disjoncteur.

Solutions Technologiques Mercure : Accélérez la Digitalité.