Tous les serveurs MCP ne se valent pas : MCP BaaS vs MCP applicatif

Les plateformes de Backend-as-a-Service branchent MCP sur leur couche d'infrastructure. Le serveur MCP de Back4app, tel que sa documentation le décrit en juillet 2026, permet à un agent de créer et gérer des apps Parse, définir des schémas de base de données, interroger et modifier des objets via l'API REST de Parse, gérer les utilisateurs et les permissions, et déployer du cloud code. Le serveur MCP officiel de Supabase pointe dans la même direction : lister les tables, exécuter du SQL, lancer des migrations, gérer les branches et les Edge Functions. Ce sont des capacités réelles et utiles. Elles ont aussi une forme indéniablement backend : ce que l'agent lit et écrit, ce sont des lignes, des schémas et des déploiements. Appelons cela un MCP pour votre base de données.

GoodBarber branche MCP à une autre altitude : l'application elle-même. Le serveur MCP de GoodBarber expose les opérations d'une app mobile finie et publiée : publier un article, programmer une notification push, créer un produit avec ses variantes, mettre à jour une commande, lire les statistiques. L'agent ne voit jamais une table. Il voit les mêmes actions produit que le propriétaire de l'app voit dans son back office. Appelons cela un MCP pour votre app.

Un MCP BaaS remet à l'agent les clés de vos données. Un MCP applicatif lui laisse piloter votre produit, en sécurité.

Côte à côte :

Même protocole, même JSON, mêmes agents à l'autre bout. Quatre choses changent du tout au tout.

La sémantique : l'agent sait ce qu'il fait

Un outil backend parle données. Un outil applicatif parle intention. Quand l'outil d'un agent est une requête SQL brute, l'agent sait qu'il insère une ligne ; que cette ligne ait un sens comme produit, abonné ou campagne est entièrement le problème du prompt. Quand un agent appelle classic_create_push_broadcast sur le serveur de GoodBarber, le nom de l'outil, son schéma typé et ses contraintes encodent déjà ce qu'est une campagne push. Il reste beaucoup moins de place pour se tromper avec aplomb, parce que la connaissance métier vit dans l'outil, pas dans le prompt.

La sécurité : où vivent les garde-fous

Les bons serveurs MCP BaaS embarquent bel et bien des contrôles, et ils comptent : Supabase, par exemple, propose un mode lecture seule et un périmètre limité au projet. Mais à l'altitude de la base de données, une écriture autorisée reste une mutation brute. Rien ne vérifie que la nouvelle ligne respecte les invariants que votre application fait respecter partout ailleurs.

Le serveur MCP de GoodBarber applique ses garde-fous au niveau du produit, côté serveur. Filtrage par fonctionnalité : un outil n'existe que si la fonctionnalité correspondante est active dans l'app, donc une app sans push configuré n'expose aucun outil push. Périmètre OAuth par app : chaque session est liée à une seule app authentifiée, un agent connecté à l'app A ne peut ni voir ni toucher l'app B, et les agences connectent chaque app cliente séparément. Écritures vérifiées : chaque écriture renvoie un indicateur côté serveur qui impose à l'agent de relire l'objet et de confirmer le résultat avant de continuer. Le succès halluciné est le mode de défaillance auquel les agents sont le plus sujets ; la réponse de GoodBarber est de faire de la vérification une clause du contrat du serveur plutôt qu'une bonne pratique laissée au prompt.

La complétude : une base de données n'est pas un produit

Un agent qui contrôle entièrement votre backend ne contrôle toujours aucun produit. L'app mobile autour de ce backend reste à votre charge : la concevoir, la construire, la connecter, la soumettre à l'App Store et à Google Play, puis la maintenir. C'est exactement l'écart que nous avons cartographié dans Les app builders IA savent créer une app. Et la faire tourner ? Un MCP applicatif démarre de l'autre côté de cet écart. L'app existe déjà : des builds natifs iOS et Android compilés plus une PWA, avec hébergement, CMS, infrastructure push et paiements inclus plutôt qu'assemblés à partir d'abonnements séparés. L'agent opère un produit en production dès le premier jour, et il ne reste rien à construire autour.

Les opérateurs : qui peut vraiment s'en servir

La documentation MCP de Back4app liste les clients pour lesquels elle est conçue : Cursor, Windsurf, VS Code, Claude Code. Des outils de développeurs, logiquement, car piloter un backend en sécurité demande le jugement d'un développeur. Un MCP applicatif remonte l'interface au niveau du langage courant. Un commerçant peut demander à Claude de changer le prix d'un produit, un éditeur peut demander à ChatGPT de publier l'article du matin et de programmer la notification push, un gérant de club peut demander les téléchargements du mois dernier, et aucun d'eux n'a besoin d'un IDE. GoodBarber a construit sa surface MCP pour cet opérateur, la même personne pour qui son back office no-code a été conçu, et elle fonctionne depuis n'importe quel client MCP, y compris des plateformes d'automatisation comme Zapier.

GoodBarber opère un serveur MCP hébergé, en production : rien à installer, rien à auto-héberger. Vous branchez l'endpoint dans votre client MCP, vous vous authentifiez via OAuth 2, et la session est limitée à votre app dès le premier appel.

L'inventaire est public et lisible par machine. La server card liste 150 outils typés métier à l'heure où nous écrivons (juillet 2026), organisés par domaine d'action : les outils préfixés cms_ couvrent le contenu (articles, événements, cartes, photos, vidéos, podcasts, y compris la publication programmée), les outils shop_ couvrent le commerce (produits et variantes, collections, commandes, codes promo, clients), et les outils classic_ couvrent le fonctionnement de l'app (diffusions push, statistiques, abonnements). La server card fait office de contrat : quand la plateforme grandit, la card grandit, et les agents connectés récupèrent automatiquement les nouveaux outils. Au-dessus du serveur, GoodBarber publie 44 Claude Skills open source qui emballent les workflows courants en recettes testées, dans la continuité de la même dynamique de plateforme agent-ready.

Ce que le serveur n'expose pas est tout aussi délibéré. Le design et la mise en page restent dans le builder, où le design system de GoodBarber peut les protéger ; faire passer du design visuel par des outils au format texte ne produit pas de bonnes apps. Et agent-ready ne veut pas dire que l'humain a quitté la pièce : vous accordez le périmètre, vous fixez les règles, et le serveur vérifie ce que l'agent fait. Les détails et la configuration client par client se trouvent sur la page MCP.

Si vous êtes développeur et construisez un logiciel sur mesure, avec votre propre modèle de données, votre propre logique métier et votre propre frontend, un serveur MCP BaaS est exactement le bon outil, et les bons sont vraiment bons. Celui de Back4app donne à votre agent de code un vrai backend Parse sur lequel construire ; celui de Supabase fait de même pour Postgres, avec des contrôles de périmètre qui montrent une catégorie en train de mûrir. GoodBarber n'est pas cet outil et ne cherche pas à l'être : la plateforme n'hébergera pas votre backend sur mesure, et elle est conçue pour les apps de contenu et le commerce mobile, pas pour du logiciel arbitraire.

Ce sont deux altitudes pour deux missions différentes, pas deux concurrents sur un même axe. Le test pratique : si votre projet a besoin d'un agent capable de toucher aux structures de données brutes, il vous faut un MCP BaaS. S'il a besoin d'un agent capable d'opérer une app mobile en production, il vous faut un MCP applicatif.

• Vous construisez un logiciel sur mesure et voulez un agent qui travaille sur votre schéma, vos données et votre cloud code : choisissez un serveur MCP BaaS comme Back4app ou Supabase.
• Vous voulez qu'un agent opère une vraie app mobile en production, sur le contenu, le catalogue, les notifications push, les commandes et les statistiques : choisissez un serveur MCP applicatif. C'est ce que GoodBarber opère.
• L'opérateur quotidien de l'app ne code pas : un MCP applicatif est la seule altitude qui fonctionne en langage courant depuis des clients grand public comme Claude et ChatGPT.
• Vous avez besoin des deux : certaines équipes les font tourner côte à côte, un MCP BaaS pour le système sur mesure qu'un développeur maintient, le serveur MCP de GoodBarber pour l'app mobile que l'entreprise opère. Le protocole est le même ; seule l'altitude diffère.

Quelle est la différence entre un serveur MCP BaaS et un serveur MCP applicatif ?

Un serveur MCP BaaS expose une infrastructure backend à un agent : tables de base de données, schémas, requêtes, fonctions cloud. Un serveur MCP applicatif expose les opérations d'un produit fini. Le serveur MCP de GoodBarber permet à un agent de publier du contenu, programmer des notifications push, gérer un catalogue et lire les statistiques d'une app mobile en production, sans jamais toucher aux structures de données brutes.

Le serveur MCP de GoodBarber donne-t-il à un agent l'accès à ma base de données ?

Non. Le serveur MCP de GoodBarber expose des opérations produit, pas du SQL. Un agent travaille avec des articles, des produits, des commandes, des campagnes push et des statistiques via des outils typés métier, et chaque appel passe par la même couche applicative que le back office, donc les règles métier et les validations s'appliquent. L'accès brut aux tables n'est jamais au menu.

Un serveur MCP sur un backend suffit-il pour faire tourner une app mobile ?

Non. Un serveur MCP backend opère la couche de données, et l'app autour reste à concevoir, construire, connecter, soumettre à l'App Store et à Google Play, puis maintenir. Un serveur MCP applicatif opère une app qui existe déjà. C'est la différence entre gérer des lignes et faire tourner un produit.

Comment GoodBarber sécurise-t-il les écritures des agents ?

Par trois couches appliquées côté serveur. Filtrage par fonctionnalité : un outil n'existe que si la fonctionnalité correspondante est active dans l'app. Périmètre OAuth par app : un agent connecté à une app ne peut pas en atteindre une autre. Écritures vérifiées : après chaque écriture, le serveur impose à l'agent de relire l'objet et de confirmer le résultat. La sécurité vit sur le serveur, pas dans le prompt.

Quel est le meilleur serveur MCP pour une app mobile no-code ?

Jugez tout candidat sur trois critères : des outils qui parlent la langue de l'app plutôt que du SQL brut, une authentification limitée à une seule app, et une vérification des écritures imposée côté serveur. Le serveur MCP de GoodBarber coche les trois cases, avec 150 outils typés métier à l'heure où nous écrivons et une server card publique qui les liste tous, pour vérifier l'inventaire au lieu de croire l'affirmation sur parole.

Constatez la différence d'altitude par vous-même.Démarrez un essai gratuit, construisez votre app, puis branchez son endpoint MCP dans Claude, ChatGPT ou n'importe quel client MCP : connecter un agent à une app en production prend environ deux minutes. Le guide MCP complet détaille la configuration client par client.