Passerelle API vs BFF : découvrez comment chaque pattern influence le versioning, la performance et la séparation des endpoints publics et internes pour les apps web et mobile.
Un point de départ courant est simple : un backend expose un ensemble d'endpoints, et l'application web et l'application mobile les appellent toutes les deux. Ça paraît efficace parce qu'il y a un seul endroit pour ajouter des fonctionnalités, corriger des bugs et appliquer des règles.
Puis la réalité arrive. L'interface web souhaite souvent des écrans denses, des filtres, des exports et des actions admin. Le mobile a en général besoin de moins de champs, d'écrans plus rapides, de flux adaptés au hors-ligne et d'une utilisation prudente de la batterie et des données. Même quand la fonctionnalité est "la même", la forme d'API optimale pour chaque client est rarement identique.
Avec le temps, les endpoints dérivent. Une équipe web ajoute des champs pour une nouvelle vue en tableau. Le mobile demande de supprimer des payloads lourds et de regrouper plusieurs appels en un seul. Quelqu'un ajoute un paramètre "juste pour iOS". Une autre personne réutilise un endpoint admin interne dans l'application publique parce qu'il était "déjà là". Ce qui était au départ une API propre devient une collection de compromis.
Les risques apparaissent vite :
C'est la tension centrale derrière la discussion passerelle API vs BFF. Vous voulez des APIs publiques stables sur lesquelles mobile et web peuvent compter, tout en laissant à chaque client la latitude d'évoluer à son rythme.
Une passerelle API est la porte d'entrée pour vos APIs. Les clients appellent la passerelle, et celle-ci route les requêtes vers le bon service backend. Elle gère souvent des préoccupations partagées que vous ne voulez pas répéter partout : vérifications d'authentification, limites de débit, journalisation des requêtes et façonnage basique des requêtes.
Un backend-for-frontend (BFF) est un petit backend construit pour un client spécifique ou un groupe de clients, comme "web" et "mobile". Le client appelle son BFF, et le BFF appelle les services sous-jacents. L'idée clé est la focalisation : le BFF a le droit de parler le langage du client (écrans, flux et payloads), même si les services centraux restent plus génériques.
Ce que ces patterns ne sont pas : ils ne remplacent pas de bons services de domaine ou un modèle de données propre. Vos services cœur, bases de données et règles métier doivent rester la source de vérité. Une passerelle ou un BFF ne doit pas devenir un énorme fourre-tout de logique métier qui finit par être votre vrai backend.
Une façon simple de les distinguer :
Vous pouvez aussi les combiner. Une configuration fréquente est une passerelle en bordure publique, puis des BFF séparés derrière pour le web et le mobile. La passerelle gère la sécurité extérieure et les règles de trafic, tandis que chaque BFF façonne les endpoints et les réponses pour son client.
La plus grande différence entre une passerelle API et un BFF est l'endroit où vous placez la logique de « porte d'entrée » : routage, vérifications d'authentification et façonnage des réponses.
Avec une passerelle API, le client parle généralement à un point d'entrée partagé. La passerelle transmet les requêtes aux services internes, en effectuant souvent des tâches de base comme la validation de token, les limites de débit et le routage par chemin.
Avec un BFF, chaque type de client (web, iOS, Android) appelle un backend construit spécifiquement pour lui. Ce BFF appelle ensuite les services internes et retourne une réponse adaptée aux écrans et contraintes du client.
Une façon simple d'imaginer le chemin de la requête :
La propriété change souvent aussi. Une équipe plateforme ou infrastructure possède généralement la passerelle car elle affecte toutes les équipes et tous les services. Une équipe feature possède souvent un BFF car il évolue avec l'UI et son cycle de publication.
L'authentification circule souvent ainsi : le client envoie un token, la couche d'edge (passerelle ou BFF) le valide ou le transmet à un service d'auth, puis relaie les détails d'identité (id utilisateur, rôles) aux services aval. La différence est l'endroit où vous appliquez les règles par client. Avec une passerelle, les politiques sont généralement génériques et cohérentes entre les clients. Avec un BFF, vous pouvez ajouter un façonnage spécifique au client, comme retourner un payload plus petit pour le mobile ou combiner plusieurs appels en une réponse sur des réseaux lents.
C'est cette étape de façonnage qui est la force des BFF, mais cela signifie aussi plus d'éléments à déployer et à maintenir cohérents.
Un endpoint public est toute route API que votre application web, mobile, partenaires ou tiers peuvent atteindre. Traitez-le comme hostile par défaut, car vous ne contrôlez pas le réseau sur lequel il circule ni le code client qui l'appelle.
Un endpoint interne est destiné au trafic service-à-service à l'intérieur de votre système. Il peut évoluer plus vite, partir du principe d'un contexte partagé et exposer des données plus riches, mais il ne doit jamais être directement accessible depuis Internet public.
Avec une passerelle API, la séparation est souvent physique et facile à raisonner : seule la passerelle est exposée, et elle décide quelles routes externes existent. Tout ce qui est derrière reste privé. Vous pouvez garder des APIs de service internes expressives, tandis que la passerelle impose une surface plus petite et plus sûre.
Avec le pattern BFF, la séparation est davantage une question de frontières produit. Chaque client (web, iOS, Android) ne parle qu'à son BFF, et le BFF parle aux services internes. Cela vous permet de masquer la complexité interne : le BFF peut appeler trois services, fusionner les résultats et exposer une réponse simple qui correspond à ce que le client a réellement besoin.
La séparation n'est sûre que si vous ajoutez des contrôles pratiques :
Exemple : une appli mobile a besoin d'un écran "Mes commandes". Le BFF peut exposer /orders avec seulement le statut des commandes et les totaux, tandis que le service de commandes interne conserve les détails de coûts et les flags antifraude privés.
La douleur du versioning apparaît généralement quand le web et le mobile évoluent à des rythmes différents. Une équipe web peut publier et revenir en arrière en quelques heures. Une app mobile peut prendre des jours ou des semaines à cause des revues d'app store et des utilisateurs qui ne mettent pas à jour. C'est cet écart qui rend la décision passerelle API vs BFF pratique.
Avec une passerelle API, vous pouvez placer le versioning à une porte d'entrée (par exemple /v1/..., /v2/...). C'est facile à expliquer et à router. L'inconvénient est que la passerelle peut se transformer en musée des versions si de nombreux clients et intégrations partenaires restent sur d'anciennes versions. Vous vous retrouvez à supporter d'anciennes formes des mêmes données plus longtemps.
Avec un BFF, le versioning est souvent "par client". Le BFF mobile peut rester sur un ancien contrat tandis que le BFF web avance, même si les deux parlent aux mêmes services internes. Cela réduit habituellement la pression de garder des versions publiques vivantes indéfiniment. Le compromis est un nombre plus élevé d'éléments à gérer : vous avez désormais plusieurs décisions de version à contrôler et à déployer.
Le versioning au sein des services peut aussi fonctionner, mais il pousse les changements pilotés par les clients profondément dans votre système. Cela peut aussi rendre le code interne plus difficile à lire car la logique du service commence à bifurquer selon les versions clientes.
Les changements non cassants sont vos meilleurs alliés : ajouter des champs optionnels, des endpoints ou accepter des champs d'entrée supplémentaires. Les changements cassants incluent renommer un champ, changer un type (string -> number) ou supprimer un endpoint.
La dépréciation fonctionne mieux quand elle est planifiée :
La performance dans une configuration passerelle vs BFF est surtout un compromis : un saut interne en plus dans votre système versus moins d'allers-retours sur le réseau depuis le client. L'option la plus rapide est souvent celle qui réduit le temps réseau lent et peu fiable du client, même si elle ajoute un petit traitement côté serveur.
Un BFF gagne souvent quand le client ferait autrement de nombreux appels. Au lieu que le web et le mobile appellent cinq endpoints et assemblent les résultats sur l'appareil, le BFF peut récupérer ce dont il a besoin côté serveur et retourner une réponse unique. Cela réduit habituellement la latence totale sur mobile parce que les réseaux cellulaires ajoutent un délai à chaque requête.
Gains de performance courants apportés par une passerelle ou un BFF :
Mais le pattern peut aussi nuire. Chaque couche ajoutée augmente le travail CPU et multiplie les points d'attente. Si vous dupliquez la même logique d'agrégation pour le web et le mobile, vous pouvez doubler le travail et créer des comportements incohérents. Le sur-récupération est une autre perte commune : un endpoint générique qui tente de satisfaire tous les écrans peut retourner des payloads volumineux qui gaspillent temps et bande passante.
Les réalités mobiles accentuent ces compromis. Les réseaux instables entraînent des retries et des timeouts, et chaque appel supplémentaire consomme de la batterie. Les démarrages à froid comptent aussi : si l'application a besoin de plusieurs requêtes avant que le premier écran soit utilisable, les utilisateurs le ressentent.
Règle pratique : optimisez d'abord pour moins de requêtes côté client, puis optimisez le saut ajouté.
Si un écran a besoin de plus de 2-3 appels séquentiels, envisagez l'agrégation. Si les réponses sont larges et surtout inutilisées, pensez à scinder les endpoints ou à utiliser un BFF adapté par client.
Avec passerelle vs BFF, la grande question opérationnelle est combien d'éléments en mouvement vous êtes prêt à exécuter et à supporter. Une passerelle devient souvent une infrastructure partagée pour de nombreuses équipes et clients. Les BFF sont en général des services plus petits, mais vous pouvez vous retrouver avec un BFF par client (web, iOS, Android, partenaires), ce qui augmente la charge de release et d'astreinte.
Sur les tests et les releases, une passerelle peut être plus sûre quand vous avez surtout besoin de routage, auth et limites de débit. Les changements sont centralisés, donc une erreur peut affecter tout le monde. Les BFF réduisent le blast radius car un changement web n'est déployé que sur le BFF web, pas sur le BFF mobile. Le compromis est davantage de pipelines à maintenir et plus de versions en vol.
Pour l'observabilité, il faut pouvoir suivre une requête utilisateur unique à travers les couches, surtout quand un appel mobile déclenche plusieurs appels backend.
La mise à l'échelle diffère aussi. Une passerelle est un point d'étranglement partagé : elle doit supporter les pics et les endpoints chauds sans devenir un goulot. Les BFF permettent de scaler par client, ce qui aide quand le trafic web explose pendant les heures de bureau alors que le mobile reste stable.
En cas d'incident, les pannes peuvent "bouger" selon le pattern. Avec une passerelle, les problèmes apparaissent souvent comme des 5xx généralisés ou des échecs d'auth. Avec des BFFs, les incidents peuvent être isolés à une fonctionnalité d'un client. Rédigez des runbooks clairs sur où regarder en premier, et gardez des comportements de repli simples (par exemple retourner une réponse réduite plutôt que de laisser un timeout se produire).
Choisir entre une passerelle API et un BFF tient moins de la théorie que de ce dont vos clients ont besoin au quotidien.
Commencez par vos clients, pas vos serveurs. Écrivez chaque client que vous supportez (application web, iOS, Android, API partenaire, admin interne) et listez ce que chaque écran clé nécessite. Si la même vue "Détails client" demande des champs et des modèles d'appels différents selon les clients, c'est un signal fort pour du façonnage spécifique au client.
Cartographiez ce que vous avez aujourd'hui. Prenez vos endpoints actuels et marquez ce qui est partagé (opérations cœur de domaine comme commandes, paiements, utilisateurs) versus ce qui est façonné pour la présentation (un résumé de tableau de bord, un payload combiné pour l'écran d'accueil). Les pièces partagées appartiennent au backend cœur. Les pièces façonnées pour la présentation conviennent généralement mieux à un BFF.
Décidez où le façonnage et les règles doivent vivre. Si vous avez surtout besoin de routage, auth, limites de débit, cache et exposition sûre des endpoints publics vs internes, la passerelle est le lieu naturel. Si vous avez besoin d'une composition réelle (appeler plusieurs services, transformer six appels en un, payloads différents par appli), mettez cette logique dans le code du BFF pour qu'elle reste testable et lisible.
Choisissez une règle de versioning et de dépréciation que vous pouvez réellement suivre. Par exemple : "Pas de breaking change sans nouvelle version, et tout champ déprécié reste 90 jours." Avec une approche uniquement passerelle, vous risquez de versionner la surface publique et de traduire derrière elle. Avec des BFFs, vous pouvez souvent garder les APIs cœur stables et ne versionner que les endpoints BFF par client.
Planifiez le déploiement et mesurez. Avant de changer quoi que ce soit, capturez des métriques de référence : p95 de latence, nombre d'appels par écran, tailles de payload et taux d'erreur. Déployez d'abord sur un petit pourcentage, comparez avant/après, puis étendez.
Un exemple simple : si votre application mobile publie mensuellement mais votre portail web publie quotidiennement, un petit BFF mobile peut protéger l'app des changements fréquents du backend tandis que le client web continue d'avancer rapidement.
Imaginez une entreprise avec un portail client web et une application terrain mobile. Les deux ont besoin des mêmes données cœur : clients, interventions, factures et messages. Le portail change chaque semaine. L'app mobile évolue plus lentement parce qu'elle doit passer la revue des stores et doit aussi fonctionner en faible signal.
La douleur apparaît vite. Les utilisateurs mobile veulent des réponses compactes, moins d'appels et des flux qui supportent le hors-ligne (par exemple télécharger les tâches du jour une fois, puis synchroniser les modifications plus tard). Le portail web peut se permettre plus d'appels et des écrans plus riches car il est toujours en ligne et plus simple à mettre à jour.
Le choix "passerelle d'abord" laisse vos services backend majoritairement inchangés. La passerelle gère l'authentification, le routage et des ajustements mineurs comme les headers, les limites de débit et le mapping simple de champs.
Le versioning reste surtout au niveau des APIs de service. Cela peut être bon : moins d'éléments à gérer. Mais cela signifie aussi que les changements spécifiques au mobile vous poussent souvent vers des versions larges comme /v2 parce que les endpoints sous-jacents sont partagés.
L'exposition des endpoints est plus claire si vous traitez la passerelle comme la seule porte publique. Les endpoints internes restent protégés, mais il faut être strict sur ce que la passerelle peut atteindre et publier.
Avec un BFF mobile, l'app mobile parle des endpoints conçus pour les écrans mobiles et les flux de sync. Le BFF peut agréger des données (détails d'une tâche + client + dernier message), tronquer des champs et retourner un payload unique correspondant aux besoins de l'app.
Ce qui change :
Le plus gros piège est de transformer la passerelle en mini-backend. Les passerelles excellent pour le routage, l'auth, les limites de débit et le façonnage simple. Quand vous les chargez de règles métier, vous obtenez une logique cachée difficile à tester, à déboguer et facile à casser lors d'un changement de configuration.
Les BFFs peuvent échouer dans l'autre sens : les équipes créent un BFF par écran ou par fonctionnalité, et la maintenance explose. Un BFF devrait généralement correspondre à un type de client (web, iOS, Android) ou à une zone produit claire, pas à chaque vue UI. Sinon, vous dupliquez les mêmes règles dans dix endroits et le versioning devient un travail à temps plein.
Les erreurs de versioning viennent souvent des extrêmes. Si vous versionnez tout dès le jour 1, vous figez votre API trop tôt et conservez d'anciennes variantes pour toujours. Si vous ne versionnez jamais, vous finirez par publier des changements cassants sans le vouloir. Une règle simple marche bien : ne versionnez pas pour de petits changements additifs, mais versionnez quand vous supprimez ou changez le sens.
La séparation public vs interne est là où les équipes se font mal. Exposer des services internes directement sur Internet (même "temporairement") transforme chaque changement interne en risque d'incident ou de sécurité. Gardez une frontière claire : seule la passerelle ou le BFF doit être public, et les services internes doivent rester privés.
Les problèmes de performance sont généralement auto-infligés : payloads surdimensionnés, trop d'allers-retours et aucun budget pour la latence. Par exemple, une app mobile peut n'avoir besoin que du statut et des totaux d'une commande, mais reçoit l'objet commande complet avec chaque ligne et champs d'audit, rendant chaque requête lente sur réseau cellulaire.
Signes d'alerte :
Si vous êtes bloqué sur le choix passerelle API vs BFF, concentrez-vous sur ce qui cassera en premier dans la vraie vie : les releases, les payloads et les frontières de sécurité.
Si vous répondez "non" à plusieurs de ces questions, votre configuration actuelle risque de devenir problématique à mesure que vos clients grandissent :
Transformez les réponses en plan. L'objectif n'est pas une architecture parfaite, mais moins de surprises lors des publications.
Rédigez votre contrat API en langage clair (entrées, sorties, codes d'erreur, ce qui peut changer). Choisissez un modèle de responsabilité : qui gère les besoins clients (web/mobile) et qui gère les services cœur de domaine. Décidez où le versioning vit (par client ou centralement) et fixez une règle de dépréciation que vous tiendrez.
Ajoutez une surveillance de base avant les gros refactors : taux de requêtes, p95 de latence, taux d'erreur et principaux endpoints par taille de payload. Prototyper d'abord les flux clients les plus risqués.
Si vous construisez avec AppMaster (appmaster.io), une approche pratique consiste à garder la logique métier et les modèles de données dans le backend généré, puis ajouter une fine couche de passerelle ou BFF seulement là où un client a vraiment besoin d'un façonnage différent ou d'une isolation de publication.
Si la checklist est difficile à remplir, prenez cela comme un signal pour simplifier le contrat et resserrer la séparation public vs interne avant d'ajouter d'autres endpoints.
Quand devrais-je utiliser une passerelle API plutôt qu'un BFF ?Commencez par une passerelle API lorsque vous avez surtout besoin d'un point d'entrée public unique avec des contrôles partagés comme l'authentification, les limites de débit et le routage. Ajoutez un BFF lorsque le web et le mobile ont des payloads nettement différents, ont besoin de moins d'appels côté client, ou suivent des cycles de publication indépendants.
Quelle logique doit vivre dans la passerelle et quelle logique dans un BFF ?La passerelle est idéale pour les préoccupations transversales et le contrôle du trafic en bordure : gardez-la centrée sur le routage, l'application de l'auth et le traitement basique des requêtes/réponses. Un BFF effectue la composition côté client, par exemple combiner plusieurs appels de service et tronquer les champs, sans pour autant devenir l'endroit principal des règles métier.
En quoi le versioning diffère-t-il entre une approche uniquement passerelle et une approche BFF ?Une passerelle vous donne une « porte d'entrée » versionnée, simple à expliquer mais qui peut vous obliger à supporter des anciennes versions longtemps. Un BFF permet de versionner par client : le mobile peut rester stable pendant que le web avance, au prix de davantage de services et de contrats à maintenir.
Quelle est la règle la plus sûre pour éviter les changements cassants pour mobile et web ?Privilégiez par défaut les changements non destructifs : ajouter des champs optionnels ou de nouveaux endpoints. Créez une nouvelle version quand vous supprimez des champs, renommez ou changez le type/ le sens d'un champ, car les utilisateurs mobiles peuvent mettre des semaines à mettre à jour.
Comment séparer en toute sécurité les endpoints publics des endpoints internes ?Gardez les services internes privés et n'exposez que la passerelle ou le BFF sur Internet public. Filtrez les réponses pour que les clients reçoivent uniquement ce dont ils ont besoin, et appliquez une autorisation par route afin qu'une action admin interne ne soit pas accessible simplement parce qu'un utilisateur est connecté.
L'ajout d'une passerelle ou d'un BFF ralentira-t-il mon application ?Utilisez un BFF lorsque le client ferait autrement de nombreux appels séquentiels : une agrégation côté serveur est souvent plus rapide que plusieurs aller-retour sur mobile. Une passerelle ajoute aussi un saut supplémentaire ; gardez-la légère et mesurez latence et tailles des payloads pour éviter des ralentissements cachés.
Quel modèle est plus simple à exploiter et à dépanner ?La passerelle est un point de contention partagé : une mauvaise configuration peut toucher tous les clients. Les BFF réduisent le périmètre d'impact en isolant les changements à un client, mais cela implique plus de déploiements, plus de surveillance et plus de rotation d'astreinte.
Quelle surveillance devrais-je ajouter pour une architecture passerelle/BFF ?Utilisez un identifiant de corrélation et propagez-le dans la passerelle/BFF et tous les services en aval pour tracer bout en bout une action utilisateur. Suivez un petit ensemble de métriques par endpoint : taux d'erreur, p95 de latence, débit et taille de payload pour repérer rapidement les régressions de performance.
Quelles sont les erreurs les plus fréquentes avec les passerelles API et les BFF ?Un piège courant est de laisser la passerelle accumuler des règles métier, rendant le comportement difficile à tester et fragile lors d'un changement de config. L'autre piège est de créer trop de BFF (un par écran), dupliquant la logique et rendant le versioning et la maintenance coûteux.
Comment appliquer cela si je construis avec AppMaster ?Conservez les modèles de données et les processus métier dans le backend généré, puis ajoutez une couche mince de passerelle ou de BFF uniquement là où un client a vraiment besoin d'un façonnage ou d'une isolation de publication. Avec AppMaster (appmaster.io), cela signifie généralement garder les endpoints de domaine stables dans le backend Go généré et ajouter une petite couche pour l'agrégation ou la réduction des payloads côté mobile.
27 janv. 2026
8 min
26 janv. 20268 min
21 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
