Développer un MCP plutôt qu'un back-office : le changement de paradigme

On continue de livrer des back-offices comme si rien n’avait changé. Une interface d’admin, des tableaux, des filtres, des boutons “relancer”, “valider”, “corriger”. On part du postulat que les utilisateurs ont toujours comme système d’exploitation principal leur navigateur. Ce n’est plus vrai et ça sera de moins en moins le cas. Les opérateurs de backoffice passent désormais, comme tout le monde, leurs journées dans ChatGPT et Claude. Et comme tout le monde, ils s’attendent désormais à ce que les tâches répétitives soient déléguées à un agent, pas exécutées à la main dans un écran de plus.

Cette évolution des produits et des usages conduit à une bascule très concrète dans la façon de concevoir un produit. La bonne question n’est plus “quel back-office construire”, mais “quelles capacités métier exposer, et à qui”.

Ce que nous constatons aujourd’hui c’est que l’on souhaite permettre l’accès aux agents IA à la plupart des fonctions des la plupart des fonctions des backoffices. Ainsi, en terme de conception technique, le plus efficace est de développer un MCP en même temps que le back-office, à partir du même socle.

MCP, définition courte

MCP (Model Context Protocol) est un standard qui permet à un agent — Claude, ChatGPT, Cursor — d’appeler des outils et des actions exposés par une application. Concrètement, un serveur MCP déclare un catalogue de fonctions : “lister les commandes en litige”, “rembourser une transaction”, “réindexer un catalogue”. L’agent les découvre, les appelle avec des arguments typés, et récupère un résultat structuré.

Vu autrement : ce que le back-office offre à un humain derrière des boutons, le MCP l’offre à un agent derrière des appels. Même périmètre métier, autre client.

Pour les lecteurs plus techniques : un MCP n’est pas une simple API REST. Il expose en plus un catalogue qui permet à l’agent l’autodécouverte des actions disponibles. Il offre aussi des protocoles de communication plus sophistiqués, comme le streaming de résultats, qui sont appréciés pour des tâches longues ou interactives.

Le pattern : une couche service, plusieurs clients

L’erreur de conception des systèmes actuels est d’enfermer la logique fonctionnelle dans le back-office lui-même. Les règles métier vivent dans des contrôleurs, des vues, des scripts ponctuels propres à l’interface.

Le problème est que ce code ne peut pas être partagé avec d’autres systèmes car trop couplé, et donc pas réutilisable..

La nouvelle manière d’aborder la conception technique d’un backoffice consiste à créer une couche d’abstraction, sans rien savoir de l’interface. Puis on expose cette couche à plusieurs clients :

• le back-office, pour les opérateurs humains ;
• un MCP, pour les agents ;
• et, parce que ça ne coûte presque rien de plus une fois la couche service en place, une API REST privée, pour les scripts et les intégrations.

L’interface graphique devient un client de la couche service, pas son propriétaire. Le MCP en devient un autre. Un agent n’a pas besoin de cliquer sur un bouton : il a besoin d’appeler proprement l’action qui se trouve derrière le bouton.

Quel coût de développement supplémentaire ?

C’est légitime : développer un MCP, c’est un chantier supplémentaire. Dans les faits, le coût marginal est faible, parce que le travail dur est déjà fait.

Une fois la couche service isolée, chaque client n’est qu’une fine traduction. Le back-office mappe des écrans sur des fonctions. Le MCP mappe des outils sur les mêmes fonctions. L’API REST mappe des routes sur les mêmes fonctions. La validation, les règles métier, les transactions, les effets de bord : tout cela vit une seule fois, au centre.

Le surcoût réel se résume à trois choses : déclarer le catalogue d’outils, décrire les schémas d’entrée et de sortie, et brancher l’authentification. Le piège, à l’inverse, c’est de réécrire la logique dans chaque client — et c’est exactement ce qu’évite la couche service.

Résultat : pour quasiment le même budget et le même temps de dev qu’un back-office classique, on livre trois surfaces d’usage au lieu d’une. L’écart de valeur, lui, n’est pas marginal du tout.

À quoi ça ressemble en pratique

Prenons une capacité courante : créer ou mettre à jour un article de blog. Toute la logique vit une seule fois, dans le service — génération du slug, bascule en publié, validation du statut. Chaque client — l’agent via MCP, les scripts via l’API REST privée, les opérateurs via le back-office — se contente d’appeler le même verbe métier, upsert.

Côté MCP, le handler est presque vide : l’essentiel tient dans la déclaration de l’outil au catalogue. Son nom, sa description et son schéma d’entrée sont ce que l’agent lit pour comprendre quand l’appeler et avec quels arguments — sans qu’un humain ait câblé l’intégration au préalable. C’est la vraie différence avec une API REST : le contrat est auto-décrit.

Le back-office (ici un client Filament) porte en plus le formulaire, la validation d’interface et les permissions de l’admin. Mais dès qu’il s’agit d’agir, il délègue exactement comme les deux autres. Trois surfaces, une seule implémentation — et chaque appelant a sa propre clé d’API, donc ses propres droits.

Les plateformes agentiques deviennent le nouvel ERP

Ce changement de paradigme est plus profond qu’il n’y paraît. Pour beaucoup d’entreprises, ChatGPT et Claude deviennent le système d’exploitation du quotidien — leur nouvel ERP de fait. C’est là que les opérateurs veulent déclencher leurs actions, pas dans une fenêtre de back-office ouverte à côté.

En tant qu’éditeur de logiciel, livrer un back-office et s’arrêter là devient désuet. Les fonctions d’administration restent évidemment nécessaires : consulter, corriger, relancer, administrer. Mais l’utilisateur de ces fonctions n’est plus seulement l’humain. C’est aussi l’agent. Et l’agent n’entre pas par l’écran ; il entre par le MCP.

Ne pas exposer ces capacités, c’est obliger l’humain à rester l’unique télécommande du produit. C’est précisément ce que les équipes cherchent à arrêter.

Développer un MCP, concrètement

Au-delà du principe, quelques points d’attention font une énorme différence sur la qualité d’un serveur MCP en production.

Des outils, pas une copie de l’API. Un bon outil MCP correspond à une intention métier (“rembourser une commande”), pas à une opération technique de bas niveau (“UPDATE sur la table orders”). L’agent raisonne mieux avec un verbe métier clair qu’avec un CRUD générique qu’il faut recomposer.

Des schémas stricts. Entrées et sorties typées, contraintes explicites, erreurs lisibles. Un agent se trompe d’argument exactement comme un humain ; un schéma précis transforme une erreur silencieuse en message exploitable.

Une authentification et des droits par appelant. L’agent n’est pas un super-admin. Il agit avec une identité, un périmètre, des permissions limitées. Les actions sensibles passent par les mêmes garde-fous que dans le back-office — voire des garde-fous plus stricts, parce qu’un agent peut enchaîner les appels vite.

De l’idempotence et de la traçabilité. Une action déclenchée par un agent doit être rejouable sans dégât et journalisée comme n’importe quelle action humaine : qui, quoi, quand, avec quels arguments. C’est ce qui rend l’ensemble auditable le jour où une opération tourne mal.

Rien d’exotique ici : ce sont les bonnes pratiques d’une couche service propre — l’arrivée de l’agent ne fait que les rendre obligatoires.

Changer de réflexe produit

La bonne unité de conception n’est plus l’écran, mais la capacité métier. Une fois isolée dans une couche service, l’exposer à un humain, à un agent ou à un script n’est plus qu’un détail d’intégration.

Le vrai changement n’est pas technique, il est dans nos réflexes de conception produit. Pendant quinze ans, imaginer une application web, c’était dessiner des écrans : des parcours, des boutons, des formulaires. À l’ère des agents, ce réflexe devient un angle mort. La première question n’est plus « à quoi ressemble l’interface ? », mais « quelles capacités le produit doit rendre, et à qui les ouvrir ? ». L’écran ne disparaît pas ; il cesse d’être le point de départ.

Ce raisonnement s’inscrit dans une tendance plus large : celle des patterns techniques qui rendent un produit opérable par des agents qui fera l'objet d'un article dédié très bientôt !

Questions fréquentes

‍Développer un MCP ou exposer une API REST : que choisir ?

Ce n'est pas l'un ou l'autre, c'est l'un grâce à l'autre. On implémente la logique dans une couche service, puis on l'expose à la fois en API REST (pour les scripts et intégrations) et en MCP (pour les agents). Le MCP ajoute ce qu'une API REST seule ne donne pas : un catalogue d'outils décrits pour qu'un agent les découvre et les appelle correctement, sans qu'un humain ait câblé l'intégration au préalable.

Faut-il vraiment développer son propre serveur MCP ?

Oui, dès lors qu'on veut exposer des capacités métier spécifiques — propres à son produit ou à son système d'information. Les serveurs MCP génériques couvrent les outils standards (fichiers, GitHub, bases de données), mais ils ignorent vos règles métier. Un MCP sur mesure, adossé à votre couche service, est le seul moyen d'offrir à un agent les actions qui comptent vraiment pour votre activité.

Combien de temps pour développer un MCP ?

Un serveur MCP minimal se monte en quelques heures avec les SDK officiels. Mais ce n'est pas le bon repère. Le coût réel est celui d'isoler proprement la couche service : c'est là que se joue la qualité. Une fois cette couche en place, ajouter le MCP relève surtout de la déclaration d'outils et du branchement de l'authentification.

Développer un MCP, est-ce que ça remplace le back-office ?

Non. Le back-office reste utile pour les tâches qui demandent un œil humain, une vue d'ensemble ou une décision sensible. Le MCP s'adresse à un autre opérateur — l'agent — pour les tâches répétitives et délégables. Les deux deviennent simplement deux clients de la même couche service.

Comment sécuriser un MCP en production ?

Mêmes principes qu'une couche service exposée, en plus stricts. Une identité par appelant, le principe du moindre privilège, des actions sensibles derrière des garde-fous explicites, de l'idempotence et une journalisation complète de chaque appel. Un agent enchaîne les requêtes vite : la traçabilité et le périmètre de droits ne sont pas optionnels.

‍

‍