Le ROI de l'IA agentique se joue dans l'arbitrage local/cloud

L'IA agentique dans le retail impose une architecture hybride, combinant IA locale et cloud pour optimiser coûts, sécurité, souveraineté et performance.

Pour un retailer, le coût d'une requête IA est devenu la nouvelle variable d'ajustement de la marge opérationnelle. Le commerce agentique change la nature du problème posé par l'IA au retail. Jusqu'ici, la question du coût se posait à l'échelle d'usages ponctuels : générer une description produit, répondre à une question client, classer un visuel. Avec des agents IA capables d'exécuter des tâches de façon autonome et répétée - comparer des offres, interroger des catalogues, exécuter des actions transactionnelles, orchestrer des workflows entiers sans intervention humaine à chaque étape - le nombre d'appels à un modèle ne se compte plus en centaines, mais en dizaines ou centaines de milliers. C'est à cette échelle que le coût de l'IA cesse d'être un détail budgétaire et devient une question d'architecture.

Quelques exemples concrets donnent la mesure du phénomène. Un agent de tarification qui surveille en continu les prix pratiqués par la concurrence et ajuste automatiquement des milliers de références n'exécute plus une tâche ponctuelle, mais des dizaines de milliers de vérifications quotidiennes. Un agent d'achat agissant pour le compte du client - capable de comparer des offres entre enseignes, de négocier une remise ou de finaliser une commande sans que l'utilisateur ne visite lui-même chaque site multiplie les appels à chaque étape du parcours, de la recherche à la transaction. Un agent de gestion des retours et remboursements évalue l'éligibilité d'un retour, déclenche le remboursement ou l'échange, sans intervention humaine, à l'échelle de milliers de demandes quotidiennes. Il en va de même pour un agent qui contrôle la conformité réglementaire d'une fiche produit avant sa publication simultanée sur plusieurs places de marché, ou pour un agent chargé de synchroniser en continu un catalogue produit sur plusieurs canaux de vente. Dans chacun de ces cas, ce n'est plus l'usage qui est ponctuel, c'est le fonctionnement même de l'agent qui est continu.

Le vrai calcul n'est plus le prix du token, c'est le coût par action

Facturer à l'usage - au token, à la requête - est un modèle parfaitement adapté à des volumes limités ou imprévisibles. Il devient plus discutable dès qu'un agent exécute la même catégorie de tâche des milliers de fois par jour, de façon continue. Dans ce cas, le coût cumulé d'un modèle facturé au token peut, à volume constant, dépasser le coût d'une infrastructure que l'entreprise maîtrise elle-même.

C'est là qu'intervient une option trop souvent écartée par réflexe : héberger soi-même un modèle, sur ses propres serveurs, pour les tâches qui s'y prêtent.

L'IA locale : un coût fixe plutôt qu'un coût variable, mais pas un coût nul

Faire tourner un modèle sur une infrastructure interne - serveur dédié, CPU ou GPU, mémoire - transforme la structure du coût : on ne paie plus à chaque appel, on paie pour une capacité de calcul, qu'on utilise à 10 % ou à 100 %. Au-delà d'un certain volume d'usage, ce coût fixe devient plus avantageux qu'une facturation au token qui, elle, croît linéairement avec le nombre d'actions exécutées.

Cette option présente trois avantages concrets pour des tâches à fort volume et à donnée sensible : la maîtrise du coût, qui ne dépend plus des grilles tarifaires changeantes des fournisseurs ; la souveraineté des données, puisque rien ne transite vers un tiers ; et un niveau de sécurité renforcé, particulièrement pertinent lorsque les agents manipulent des données clients, des données de paiement ou des informations catalogue à caractère concurrentiel.

Il faut cependant se garder d'un raccourci : l'IA locale n'est pas gratuite, elle déplace le coût plutôt qu'elle ne le supprime. Elle suppose un investissement initial en matériel, une charge de maintenance, des compétences internes pour opérer et faire évoluer l'infrastructure, et elle plafonne généralement en capacité de raisonnement par rapport aux modèles les plus avancés disponibles en cloud. Le calcul n'est donc pas "le local coûte moins cher", mais "à partir de quel volume et pour quel niveau de sensibilité des données le local devient-il plus rentable que le cloud."

Le cloud pour les tâches complexes et imprévisibles

À l'inverse, certaines tâches ne se prêtent pas à l'hébergement local : celles qui exigent un raisonnement plus sophistiqué, qui portent sur des volumes irréguliers, ou qui doivent bénéficier des dernières capacités disponibles sur le marché - négociation en langage naturel dans le cadre de protocoles de commerce agentique, interprétation de requêtes complexes, orchestration de tâches multiples. Pour ces cas, un modèle cloud, de type généraliste avancé, reste pertinent : pas d'investissement en infrastructure, une capacité de calcul qui s'ajuste à la demande, et un accès aux modèles les plus performants du moment sans avoir à les héberger soi-même.

Le panachage comme réponse rationnelle

Opposer IA locale et IA cloud serait aussi réducteur que d'opposer un modèle puissant à un modèle léger. La question n'est pas de choisir un camp, mais d'orchestrer les deux selon la nature de la tâche. Dans un contexte de commerce agentique appliqué au retail, cela peut se traduire ainsi : des opérations à fort volume et faible sensibilité de raisonnement - classification d'assets, contrôle de complétude d'un catalogue, détection de doublons, vérifications répétitives sur des données produit - confiées à un modèle hébergé en interne, dont le coût marginal par action devient quasi nul une fois l'infrastructure amortie. Et des tâches plus complexes ou plus rares - génération de contenu élaboré, interprétation de requêtes clients ambiguës, orchestration d'agents multiples - confiées à un modèle cloud avancé, dont le coût au token reste justifié par la valeur produite à chaque appel.

Le principe reste le même que pour le choix entre modèles : réserver la puissance la plus coûteuse aux cas qui la justifient, et faire supporter le volume par une infrastructure dont le coût marginal tend vers zéro. Ce qui change avec le commerce agentique, c'est l'échelle à laquelle cet arbitrage devient nécessaire - et le fait qu'il touche désormais autant à la souveraineté des données qu'à la seule facture.

Gouverner cet arbitrage, pas seulement le subir

Cette bascule pose une exigence de gouvernance nouvelle. Il ne suffit plus de suivre le coût par cas d'usage ou de comparer les tarifs entre fournisseurs cloud : il faut aussi arbitrer, tâche par tâche, entre ce qui doit rester hébergé en interne - pour des raisons de coût à l'échelle, de sécurité ou de souveraineté - et ce qui justifie de faire appel à un modèle tiers. Cet arbitrage n'est pas figé : un volume qui augmente, une donnée qui devient plus sensible, un modèle local qui progresse en capacité, peuvent faire basculer une tâche d'une catégorie à l'autre.

C'est, à un niveau d'ensemble, le rôle que le FinOps a déjà joué pour le cloud : suivre la consommation en continu, allouer les coûts par usage, et permettre à une entreprise de rediriger vers une infrastructure locale les tâches devenues trop volumineuses pour un modèle facturé au token. Ce réflexe reste nécessaire pour l'IA agentique, mais il ne suffit pas à lui seul : un pilotage financier fin de l'existant ne remplace pas le choix d'architecture qui détermine, en amont, ce qui doit être hébergé en interne et ce qui doit rester en cloud. C'est sur ce choix d'architecture, et sur ce qui le rend possible, que se joue la vraie marge de manœuvre.

La donnée produit et média, condition de la rentabilité de l'IA locale

Ce choix d'architecture ne se limite pas à une question de serveur. Héberger un modèle en interne pour des tâches à fort volume - classification d'assets, détection de doublons, contrôle de complétude d'un catalogue - suppose que la donnée qu'il traite soit elle-même exploitable sans recours systématique à un modèle plus puissant pour compenser son désordre. Un modèle léger, hébergé localement, produit de bons résultats sur une donnée structurée ; il multiplie les erreurs, et donc les reprises manuelles, sur une donnée fragmentée. Dans ce cas, la tentation est grande de compenser en basculant la tâche vers un modèle cloud plus coûteux - ce qui annule une partie de l'intérêt économique du choix local.

C'est pourquoi la rentabilité de l'IA agentique dans le retail se joue autant dans le référentiel de données - MDM, PIM, DAM - que dans le choix du serveur ou du fournisseur. Une donnée produit et média bien structurée, avec des taxonomies et des règles métier claires, permet de confier davantage de tâches à une infrastructure locale économique, tout en gardant un niveau de fiabilité suffisant pour des agents qui agissent de façon autonome et répétée. À l'inverse, une donnée mal gouvernée pousse mécaniquement vers des modèles cloud plus puissants et plus coûteux, non pas parce que la tâche l'exige, mais parce que la donnée ne permet pas de faire autrement. L'arbitrage local/cloud et la gouvernance de la donnée ne sont donc pas deux sujets séparés : le second conditionne la marge de manœuvre du premier.

La rentabilité se jouera dans l'architecture, pas dans le fournisseur

Le commerce agentique ne pose pas la question "quelle IA choisir", mais "comment répartir les tâches entre ce que l'on maîtrise en interne et ce que l'on confie à l'extérieur." Les retailers qui en tireront le plus de valeur ne seront pas nécessairement ceux qui auront adopté le plus de modèles ou le plus puissant d'entre eux. Ce seront ceux capables de construire une architecture hybride - serveur local pour le volume et la donnée sensible, IA cloud pour la complexité et l'exception - et de la réviser au même rythme que leurs volumes d'usage et leurs exigences de sécurité évoluent. Et cette architecture, aussi bien pensée soit-elle, restera dépendante d'un facteur plus ancien que l'IA elle-même : la qualité du référentiel de données sur lequel elle s'appuie.

Pour aller plus loin sur ce sujet, rendez-vous les 30 novembre et 1 décembre à Tech for Retail 2026 à Paris Expo, Porte de Versailles.