Cartographiez le parcours client automobile et vous obtenez presque toujours la même slide : prise d…
De l'API gateway à la couche d'agents IA
Si vous regardez le chapitre 4 de Microservices for Modern Commerce de Kelly Goetsch (O'Reilly, 2016), vous trouvez un passage sur les API gateways qui prend une nouvelle signification en 2026.
Goetsch décrit l'API gateway comme une couche d'agrégation : « Une page web ou un écran sur un appareil mobile peut nécessiter de récupérer des données de dizaines de microservices différents. Chacun de ces clients aura besoin de données taillées pour lui. » Il nomme ensuite les API gateways comme « souvent appelés "Backends for your Frontend" », BFF en abrégé.
L'idée : une couche d'agrégation dédiée qui renvoie différentes formes de données selon le contexte du consommateur. L'Apple Watch a besoin d'un attribut. La page web en a besoin de vingt. L'application mobile en a besoin de quinze différents. Le BFF gère cette agrégation et cette transformation.
Dix ans plus tard, cette couche est plus importante que jamais. Non pas à cause de nouveaux appareils. À cause d'une nouvelle classe de consommateurs d'API : les agents IA.
Ce que le pattern BFF signifiait en 2016
Dans le modèle de Goetsch, le BFF est une couche d'optimisation pour les interfaces utilisateur. Il résout un problème de performance concret : si un client d'application mobile devait appeler directement des dizaines de microservices, trop d'aller-retours se produiraient, trop d'overfetching (trop de données pour le contexte), trop de couplage entre le client et les microservices individuels.
Le BFF gère cette coordination côté serveur :
- Il agrège les données de multiples microservices en une seule réponse
- Il transforme les données dans la forme optimale pour le client
- Il maintient la logique côté client hors des microservices eux-mêmes
Goetsch met aussi en garde contre l'anti-pattern : « Le problème avec les API gateways, c'est qu'elles deviennent des monolithes fortement couplés parce qu'elles doivent savoir comment interagir avec chaque client (des dizaines) et chaque microservice (des dizaines, des centaines, voire des milliers). Le problème même que vous cherchiez à résoudre avec les microservices peut réapparaître si vous n'y prenez pas garde. »
C'est la tension centrale du BFF qui a émergé en 2016 et qui tient toujours en 2026.
Ce que les agents IA représentent en tant que nouvelle classe de consommateurs
En 2026, il existe une nouvelle classe de consommateurs d'API pour laquelle le concept de BFF de Goetsch est directement pertinent : les agents IA.
Les agents IA, qu'il s'agisse de buyer agents (recherchant et achetant des produits pour le compte des clients), d'agents de productivité (créant du contenu ou optimisant des campagnes pour le compte des équipes commerce) ou d'agents de service (gérant la communication client), consomment les API de commerce d'une manière fondamentalement différente des UI classiques.
La différence avec une UI classique :
Une UI web classique est actionnée par des humains. Elle suit un parcours utilisateur prédéterminé : page catégorie vers page détail produit vers panier vers checkout. Les appels d'API sont prévisibles, leur schéma est documenté, leur séquence est définie.
Un agent IA ne suit aucun parcours prédéterminé. Il planifie ses actions dynamiquement en fonction de l'objectif et du contexte. Il a besoin :
- De schémas lisibles par machine : Pas seulement « que renvoie l'API » mais « que peut faire cette API », Swagger/OpenAPI seul est insuffisant ; des descriptions sémantiques des actions sont nécessaires.
- De manifestes d'outils : Une liste d'actions disponibles (rechercher un produit, ajouter au panier, appliquer un coupon, vérifier l'inventaire) avec leurs paramètres et effets de bord.
- D'une sémantique d'action : Pas seulement des API de lecture, mais des actions avec préconditions, postconditions et comportement en cas d'échec définis.
- D'un suivi d'état : Les agents ont besoin d'un mécanisme pour maintenir le contexte courant (panier, session, profil utilisateur) à travers plusieurs appels.
C'est fondamentalement différent d'une API REST optimisée pour l'UI.
BFF 2.0 : une couche d'agrégation capable de servir les agents
L'implication : les BFF doivent être conçus différemment pour les agents que pour les UI. Un BFF moderne dans un contexte de commerce agentique a deux couches :
Couche 1 : la couche BFF classique (pour les UI) Agrège les données des microservices en formes de réponse optimisées pour l'UI. Fonctionne comme décrit en 2016.
Couche 2 : la couche d'interface pour les agents (nouvelle) Expose non pas des vues orientées page mais des interfaces d'outils :
searchProducts(query, filters, maxResults), renvoie une liste de produits structurée, lisible par l'agentaddToCart(productId, quantity, customerId), action idempotente avec état de résultat explicitegetInventory(productId, warehouseContext), en temps réel, fortement cohérent (pas de cache)applyPromotion(cartId, promoCode), avec schéma de succès/échec expliciteinitiateCheckout(cartId, paymentContext), avec un manifeste d'erreurs complet
Chacune de ces actions est conçue pour une consommation machine-to-machine : schéma d'entrée clairement défini, schéma de sortie clairement défini, codes d'erreur clairement définis, idempotente lorsque c'est possible.
Goetsch décrit dans un autre contexte l'idée HATEOAS (REST de niveau 3) : « Les API deviennent auto-documentées, permettant à l'appelant de l'API d'interagir très facilement avec elle sans avoir besoin d'en savoir beaucoup. » C'est exactement le principe qui s'applique aux interfaces d'agents sous une forme moderne, mais avec un manifeste d'outils au lieu de liens HATEOAS.
Pourquoi la couche frontend est l'endroit naturel pour la couche d'agents
Voici l'argument non évident : la couche d'agents n'appartient pas au backend. Elle appartient au niveau de la gestion du frontend.
Pourquoi ? Parce que les agents, qu'il s'agisse de buyer agents ou d'agents de productivité, ont besoin d'accéder à l'état composité de la stack de commerce : le prix actuel pour cet utilisateur, sur ce marché, avec ces promotions actives, avec cette situation d'inventaire. Cet état composité n'existe dans aucun microservice backend unique. Il est créé par l'agrégation de multiples microservices, exactement ce que fait le BFF.
Un FMP qui gère déjà cette couche d'agrégation est l'endroit naturel pour exposer aussi les interfaces d'outils des agents. Le FMP sait déjà :
- Quels microservices sont responsables de quelles données
- Quelles politiques de cache s'appliquent à quelles données
- Quelles règles de personnalisation sont actives pour quel utilisateur
- Quels marchés et localisations existent
Un agent qui accède à cette couche FMP reçoit des données composités, personnalisées et conscientes du marché, sans que la logique de l'agent ait à porter elle-même cette complexité.
Larry AI : l'approche de Laioutr pour le commerce agentique
L'Agentic Frontend Management Platform de Laioutr expose non seulement le rendu des pages. Elle expose les interfaces d'outils des agents comme une fonctionnalité de premier plan.
Larry AI, l'agent IA intégré de Laioutr, démontre ce pattern : il travaille sur la même couche FMP qui sert les UI classiques. Il peut rechercher des produits, exécuter des actions de panier, appliquer des règles de personnalisation et tester des variantes de contenu, non pas via des appels directs aux microservices backend, mais via les interfaces d'outils définies du FMP.
Cela signifie : les nouveaux agents IA peuvent s'appuyer sur une couche d'agrégation déjà existante et bien structurée, au lieu de repartir de zéro à chaque fois. Les nouvelles capacités de commerce (un nouveau microservice dans le backend) sont enregistrées une fois dans la couche d'interface d'outils du FMP et sont immédiatement disponibles pour tous les agents.
C'est l'évolution directe du concept de BFF de Goetsch : de « Backend for your Frontend » à « Backend for your Agents and Frontends ».
Exigences pour être prêt à l'agentique dans votre stack de commerce
Si vous planifiez aujourd'hui d'intégrer des agents IA dans votre stack de commerce, voici les questions qui déterminent le succès :
1. Vos API ont-elles des schémas lisibles par machine ? Une spec OpenAPI est un début. Mais pour la consommation par un agent, vous avez besoin de descriptions sémantiques : quelle est l'intention de cette action ? Quels sont les effets de bord ?
2. Avez-vous une couche d'agrégation qui expose l'état composité ? Un agent qui doit appeler directement 20 microservices n'est pas un agent, c'est un script avec beaucoup de gestion d'erreurs. Vous avez besoin d'une couche BFF qui gère la composition.
3. Vos actions de commerce sont-elles idempotentes ? Les agents peuvent exécuter des actions plusieurs fois (logique de retry, parallélisme). Si « ajouter au panier » n'est pas idempotent, des commandes en double se produisent. Ce n'est pas un problème d'IA, c'est un problème de conception d'API.
4. Avez-vous une couche d'état pour les sessions d'agents ? Un buyer agent qui prépare un achat à travers plusieurs interactions a besoin d'un état persisté : panier actif, produits sauvegardés, négociation en cours avec un agent de service. Cet état doit exister dans la couche FMP, pas dans l'agent lui-même.
5. Comment isolez-vous le trafic des agents du trafic des UI ? Les agents peuvent générer un trafic en rafale (raisonnement parallèle, plusieurs appels d'outils par seconde). Vous avez besoin de rate limiting et de throttling sur la couche d'interface des agents qui n'affecte pas votre trafic UI.
Conclusion : le BFF de 2016 est le fondement de la couche d'agents de 2026
La description par Goetsch de l'API gateway comme « Backend for your Frontend » était en 2016 une décision d'architecture pragmatique pour l'optimisation d'UI multi-canal. En 2026, la même couche est le levier décisif du commerce agentique.
La continuité est directe : la pensée BFF, une couche d'agrégation dédiée qui découple les consommateurs de la complexité du backend, n'est pas dépassée. C'est le fondement d'architecture pour tout ce qui vient après l'UI web classique.
La différence est que les consommateurs ne sont plus uniquement des utilisateurs humains. Ce sont des buyer agents, des agents de productivité, des agents de service. Et ces nouveaux consommateurs ont besoin d'une couche qui va au-delà du rendu de page : interfaces d'outils, sémantique d'action, schémas lisibles par machine.
Un FMP qui gère cette couche aujourd'hui n'est pas seulement une optimisation pour les UI existantes. C'est l'infrastructure du commerce de la prochaine décennie.
Pour en savoir plus sur la façon dont la rétrospective de la décennie du livre de Goetsch encadre les autres évolutions : 10 ans de microservices dans le commerce. Et sur la façon dont la cohérence à terme fonctionne dans les flux d'agents : La cohérence à terme dans le storefront Composable.
[Voir Larry AI en action, réservez une démo gratuite](https://www.laioutr.com/demo)
Source : Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.
Insights connexes
Ressources connexes : Content Management et Composable Digital Experience Platform.