MCP ou GUI : choisir l’interface d’une opération métier

Une conversation avec un agent aide à retrouver un ticket par son sens et à préparer une modification. Avant une écriture, un formulaire montrant l’ancienne et la nouvelle valeur est souvent préférable. MCP relie une application à des outils ; c’est toujours votre système qui décide qui peut modifier un ticket.

Ce scénario pédagogique de service desk interne ne décrit pas l’intégration prête d’un produit précis. Un employé lit un ticket, propose de changer son responsable et envoie la modification à confirmation. Les noms d’outils et de champs sont illustratifs : implémentez-les et testez-les dans le système retenu.

Distinguez lecture, proposition et écriture

Dans l’architecture MCP, l’application hôte travaille avec des serveurs par des clients, et les serveurs exposent outils et capacités. Le nom d’un tool ne donne pas à lui seul une autorisation métier.

Action	Interface de départ utile	Condition d’accès
Trouver un ticket accessible	MCP et conversation	Le serveur limite les résultats aux droits de l’utilisateur
Proposer un autre responsable	MCP pour le brouillon ; formulaire pour comparer	La proposition ne change pas le dossier
Confirmer la modification	GUI ou formulaire MCP Apps testé	Les champs exacts sont visibles ; le serveur revalide droits et fraîcheur

Cette recommandation vaut pour ce scénario. Une GUI ordinaire peut elle aussi cacher une valeur importante ou appeler un backend insuffisamment protégé. Évaluez le chemin d’écriture réel et les preuves de son fonctionnement.

Supposons que le ticket d’exercice REQ-204 ait team-a comme responsable et que l’utilisateur demande team-b. La conversation retrouve l’objet, mais il faut afficher avant sauvegarde l’ID, l’ancienne valeur, la nouvelle valeur et les conséquences : notification, changement d’accès ou action externe. Une ressemblance de titres ne suffit pas.

La confirmation doit porter sur le changement exact

Un objet interne de confirmation peut être :

{
  "ticket_id": "REQ-204",
  "expected_revision": "r17",
  "changes": {
    "assignee": {"from": "team-a", "to": "team-b"}
  },
  "mode": "proposal"
}

C’est un schéma d’application, pas un standard MCP. À la sauvegarde, le serveur compare revision et droits. Si le ticket a changé, la proposition doit être réaffichée ; le bouton de confirmation ne doit jamais appliquer silencieusement un autre diff.

La section Tools de la spécification MCP couvre les appels visibles, la possibilité pour une personne de refuser l’action, ainsi que la validation côté serveur des entrées et de l’accès. Le protocole n’impose pas une interface de confirmation : l’accès à un serveur MCP n’autorise donc pas toutes les opérations métier.

Définissez le comportement du backend après un timeout. Si la réponse disparaît, demandez d’abord le résultat avec l’identifiant conservé. Une répétition aveugle peut doubler une notification ou un effet externe. Rétablir l’ancien responsable ne rend pas toutes les conséquences réversibles.

Quand utiliser MCP Apps

MCP Apps permet à un outil serveur de fournir une UI interactive dans un client compatible. L’hôte l’affiche dans un iframe sandboxed. Elle convient à la comparaison des champs dans la conversation si les versions client et serveur choisies prennent l’extension en charge.

Le formulaire peut afficher le ticket, le diff proposé et deux boutons explicites, Appliquer et Annuler. Autorisation serveur, contrôle de revision et journal du résultat restent nécessaires. L’iframe sandboxed ne remplace ni les droits du service desk ni la confiance dans un serveur arbitraire.

Gardez une GUI distincte si le client ne peut pas afficher le diff de façon fiable, faire passer la confirmation d’entreprise ou assurer l’accessibilité requise. Si le modèle est indisponible, une personne doit pouvoir ouvrir le ticket par ID et connaître son état réel ; une panne du modèle ne doit pas laisser planer le doute sur l’écriture.

Pilote : modèle via BetterToken, tickets via MCP

Utilisez Claude Desktop comme client et connectez un modèle Claude via BetterToken en suivant le guide de configuration API. Employez votre propre API Key ayant accès au fournisseur Claude et Gateway Base URL https://bettertoken.ai; vérifiez les champs et conditions de votre version dans le guide. Commencez par obtenir une réponse à un court message ordinaire afin de tester séparément la connexion du modèle.

Connectez ensuite un serveur MCP de service desk de test avec le client choisi et testez l’accès à un ticket non secret. BetterToken fournit la couche API du modèle ; les identifiants service desk, droits utilisateur et confirmation d’écriture sont configurés séparément. La connexion du modèle ne prouve pas MCP Apps dans un mode de client donné : vérifiez-le avant de choisir le formulaire intégré. Sinon, conservez la confirmation dans la GUI.

Connectez le modèle via BetterToken pour le scénario de test, puis effectuez les vérifications. Utilisez des données fictives : le contenu d’une réponse MCP transmis au modèle peut entrer dans une requête API. L’autorisation d’utiliser des données réelles doit respecter les règles de votre organisation.

Testez le choix en cas de défaillance

Exécutez l’exercice en test, avec deux rôles et des tickets non secrets. L’un peut modifier le responsable, l’autre ne peut lire que les dossiers autorisés. Conservez le résultat réel de chaque contrôle ; le tableau donne des critères attendus, pas un rapport d’essai.

Contrôle	Résultat attendu
Demande d’un ticket inaccessible d’autrui	Le serveur refuse sans révéler le contenu
Un rôle lecture seule confirme le changement	Le serveur refuse l’écriture
L’utilisateur annule le diff proposé	Le ticket reste inchangé
La revision change après lecture	La sauvegarde s’arrête ; une nouvelle lecture est requise
La réponse après sauvegarde est perdue	Vérifier le statut avant de répéter
Le modèle est indisponible	La GUI permet de lire l’état réel
Clavier et lecteur d’écran	La personne peut comprendre, confirmer ou annuler

Si un contrôle échoue, conservez ce type d’écriture dans l’interface existante et éprouvée jusqu’à correction. La lecture via MCP peut être évaluée séparément ; elle exige aussi droits et limites de résultats.

Conservez une piste d’audit

Enregistrez utilisateur, ID du ticket, diff accepté, revision source, heure, ID d’opération et résultat backend. Ne journalisez pas tokens ou contenu intégral de tickets restreints sans nécessité. Conservation et accès au journal doivent suivre les règles de l’organisation.

Après le pilote, documentez la décision pour chaque action : lecture dans la conversation, préparation en brouillon, écriture dans le formulaire testé choisi. Ajoutez les résultats des tests de défaillance et un responsable des problèmes restants. Étendez MCP seulement aux opérations dont droits, confirmation et reprise après incident sont compris.