La symétrie MCP

Le problème

Dans une architecture classique, l’agent IA appelle des outils d’un côté et l’interface graphique appelle une API REST de l’autre. Deux chemins de code coexistent, implémentés séparément.

Les divergences apparaissent vite :

un bug corrigé d’un côté ne l’est pas de l’autre ;
un nouveau champ n’est pas exposé partout ;
les validations diffèrent.

Résultat : deux versions de la même fonctionnalité, sans assurance qu’elles se comportent de manière identique.

La solution : une route unique

Simon n’a aucun endpoint REST dédié par fonctionnalité. Toute action — qu’elle vienne de l’agent ou de l’interface — passe par le même serveur MCP. L’agent appelle les outils directement ; l’interface les appelle via un unique point d’entrée HTTP qui relaie l’appel au même serveur.

sequenceDiagram
    participant UI as Interface
    participant S as Serveur
    participant M as MCP Python

    UI->>S: Appel via le proxy HTTP
    S->>M: Exécution de l'outil
    M->>M: Logique métier + suivi des modifications
    M-->>S: Résultat JSON
    S-->>UI: Réponse JSON
    S->>UI: Événement db.changed
    UI->>UI: Rafraîchir les vues

L’agent suit le même chemin métier, sauf qu’il appelle le serveur MCP directement — sans passer par le proxy.

Les bénéfices

Risque de divergence réduit — ce que l’agent peut faire, l’interface peut généralement le faire, et inversement. Les écarts restants se traitent dans les formulaires, vues ou permissions, pas dans une logique métier parallèle.
Une seule source de vérité — la logique métier est implémentée une seule fois dans le serveur MCP. Validations, règles métier, effets de bord : tout est au même endroit.
Un seul endroit à tester — les tests des outils MCP couvrent automatiquement les deux chemins, agent et interface.
Cohérence automatique — après chaque modification, les vues se rafraîchissent automatiquement, que le changement vienne de l’agent ou de l’interface.

Les compromis

Performance — chaque appel depuis l’interface transite par le serveur MCP, un processus séparé. En pratique, la latence ajoutée est négligeable pour des opérations comptables.
Complexité du proxy — le serveur doit relayer les appels vers le processus Python et gérer les erreurs. Mais c’est du code d’infrastructure générique, pas de la logique métier.

Pourquoi ça marche

Simon est un logiciel agent-first. L’interface n’est pas le chemin principal — c’est un complément visuel. Construire l’interface comme un client MCP, au même titre que l’agent, est cohérent avec cette philosophie.