Serveur MCP et traduction par IA : concevoir des outils sûrs
Découvrez comment concevoir un serveur MCP de traduction par IA : outils composables, garde-fous pour les fichiers et partage clair des responsabilités.
Concevoir un serveur MCP de traduction que les agents peuvent utiliser sans deviner
Transformer un outil de traduction en ligne de commande en serveur MCP ne revient pas à « copier-coller » les mêmes commandes sous un autre format. Le vrai changement, c'est la façon de s'en servir.
Une personne lance souvent une commande pour obtenir un résultat complet. Un agent, lui, avance autrement : il regarde le contexte, choisit une action, vérifie ce qui s'est passé, puis décide de la suite.
Cette différence devient cruciale dès qu'un outil peut modifier un dépôt. Une traduction peut créer des fichiers, réécrire des liens, changer des métadonnées ou modifier la structure d'un document. Si une seule fonction fait tout à la fois, l'agent a plus de mal à comprendre ce qui a vraiment été traité et quoi faire ensuite.
La conception d'un serveur MCP pour Co-op Translator a mené à une règle simple : pour un agent, les outils doivent rendre leurs responsabilités plus explicites que les commandes destinées aux humains. Concrètement, il faut découper les responsabilités, choisir des valeurs par défaut prudentes, et répartir le travail entre l'agent et le service de traduction.
Pourquoi une commande pratique ne suffit-elle pas pour un agent ?
Une interface en ligne de commande peut prendre en charge un flux complet. Par exemple, une commande de traduction peut repérer les fichiers d'un dépôt, traiter du Markdown et des notebooks, décider où écrire les traductions, adapter les liens et nettoyer des fichiers générés plus anciens. Pour un humain qui veut traduire tout un projet, c'est souvent un avantage : il lance, il obtient.
Mais un agent ne « consomme » pas forcément ce flux en une seule passe. Un agent du type Codex ou Claude Code peut avoir besoin de traduire un document, d'inspecter une partie du résultat, puis de lancer autre chose. Il peut aussi devoir s'arrêter et demander une confirmation avant d'écrire. Dans ce cadre, une fonction monolithique transforme des décisions de l'agent en boîte noire.
La commodité masque des effets de bord
Imaginons un outil qui fait tout en une fois : traduit le texte, réécrit les chemins, met à jour les métadonnées et enregistre les fichiers. Si le résultat est faux, il faut comprendre à quelle étape ça a déraillé. Et si l'agent doit reprendre, il lui faut savoir ce qui a déjà été traité : le texte est-il déjà traduit ? Les liens ont-ils déjà bougé ? Les fichiers ont-ils déjà été écrits ?
Le souci n'est pas que les commandes « complètes » soient mauvaises. Le souci, c'est que l'abstraction qui aide un humain peut perdre son sens pour un agent qui doit choisir entre plusieurs actions possibles. Ce qui est simple à utiliser pour un humain peut devenir ambigu pour un agent.
Concevoir pour la boucle de raisonnement
Un agent travaille par petits pas : observer, agir, vérifier, puis continuer. Les outils doivent permettre ce rythme. Une opération qui rend clairs son entrée, sa sortie et ses effets aide l'agent à vérifier et à reprendre après une erreur.
Dans un projet réel, c'est autant une question de qualité que de sécurité. Une traduction peut se corriger. En revanche, quand des dizaines de fichiers sont modifiés « dans le noir », le diagnostic devient pénible - surtout si le dépôt a déjà des changements non validés. L'interface doit donc dire à l'agent ce qu'il va faire, avant qu'il ne le fasse.
La commande complète reste utile pour démarrer un traitement global. Elle ne peut toutefois pas être la seule surface d'interaction d'un agent. Il faut aussi des opérations plus ciblées, avec des responsabilités assez nettes pour être combinées et contrôlées.
Quels garde-fous prévoir avant de modifier un dépôt ?
Un serveur MCP n'est pas qu'une couche qui appelle des fonctions. Les outils exposés sont choisis par un modèle dans le contexte de l'application hôte, et les paramètres par défaut influencent directement le comportement. Une action capable de créer ou modifier beaucoup de fichiers doit donc être pensée avec la prudence au centre.
Pour la traduction d'un dépôt, Co-op Translator démarre en mode simulation, ou dry run. L'appel indique notamment les langues demandées, le dossier racine, les types de documents à traiter et le fait que l'opération est une simulation :
{
"language_codes": "ko",
"root_dir": ".",
"markdown": true,
"dry_run": true
}
Ce paramètre sert à inspecter le périmètre avant d'autoriser l'écriture. Il ne remplace pas toujours une validation humaine, mais il évite qu'une demande d'analyse déclenche automatiquement une modification persistante.
Rendre l'effet de l'action visible
Un bon garde-fou répond à une question simple : si l'opération est confirmée, qu'est-ce qui va changer ? Le mode simulation aide l'agent à proposer un plan et à demander une validation avant de toucher au dépôt. C'est particulièrement utile dans un espace de travail partagé, quand d'autres changements peuvent être en cours.
La confirmation explicite n'est pas une formalité « à ajouter partout ». Elle se justifie surtout quand l'action est difficile à annuler, concerne beaucoup de fichiers, ou peut écraser du travail existant. À l'inverse, demander une validation à chaque opération sans impact durable ralentit le flux sans améliorer vraiment le contrôle.
Traiter les valeurs par défaut comme une décision produit
Les outils destinés aux agents doivent déjà être « sûrs » avant que l'agent ne formule une demande parfaitement calibrée. Une valeur par défaut prudente limite le risque qu'un modèle interprète une intention générale comme une autorisation d'écriture. Cela ne veut pas dire qu'il faut tuer toute automatisation : une fois le périmètre examiné et les permissions clarifiées, le flux peut continuer.
Un principe opérationnel pratique consiste à distinguer :
- Préparer l'action sans modifier les fichiers.
- Montrer le périmètre et les changements attendus.
- Exécuter l'écriture après accord explicite, quand l'impact le justifie.
Ce découpage aide aussi pour le diagnostic. Si le résultat déçoit, l'équipe peut déterminer si le problème vient du choix des fichiers, de la traduction, ou de l'écriture. Au final, les garde-fous ne servent pas seulement à être prudent : ils rendent le comportement de l'outil plus compréhensible et plus simple à maintenir.
Qui doit traduire : l'agent ou le service ?
Dans un flux classique, Co-op Translator appelle directement un fournisseur de modèles, comme Azure OpenAI ou OpenAI. C'est adapté aux chaînes de production et aux traitements automatisés qu'on veut reproductibles dans un environnement maîtrisé. Le service porte alors le processus, l'accès au modèle et le déroulement complet de la traduction.
Avec MCP, l'application hôte dispose déjà d'un agent et d'un modèle. Pour du Markdown ou un notebook, il n'est pas forcément nécessaire que Co-op Translator appelle un deuxième fournisseur de grands modèles de langage. Le service peut préparer le document, préserver sa structure, puis laisser l'agent hôte traduire les segments.
Le flux se déroule en trois temps :
start_markdown_agent_translationprépare les segments à traiter.- L'agent hôte traduit les segments avec son propre modèle.
finish_markdown_agent_translationreconstruit le document et applique les traitements finaux.
Répartir les responsabilités selon les compétences
Dans cette organisation, l'agent s'occupe de la partie linguistique. Co-op Translator gère tout ce qui l'entoure : découpage en segments, conservation des marqueurs qui protègent le code, reconstruction du frontmatter, remplacement des cellules Markdown d'un notebook, puis normalisation après traduction.
Ce partage évite de demander à l'agent de gérer seul des détails structurels qu'un outil spécialisé peut traiter de façon plus régulière. Il réduit aussi les appels redondants à un fournisseur quand l'environnement hôte a déjà un modèle adapté. Pour l'utilisateur, ce que ça vise est clair : demander une traduction en coréen tout en gardant le formatage Markdown, les blocs de code et les liens.
Choisir selon le contexte d'exécution
Le mode avec fournisseur intégré a des avantages : il convient aux pipelines planifiés, aux traitements répétés, et aux environnements où l'accès au modèle doit être centralisé. Le mode assisté par agent est utile quand l'agent est déjà dans l'espace de travail et que son modèle peut traiter le texte.
Cela dit, il ne faut pas vendre l'une de ces options comme « meilleure » dans l'absolu. Le choix dépend de la gouvernance des accès, de la reproductibilité attendue, du modèle disponible, et du niveau de contrôle souhaité. Par exemple, une équipe européenne peut vouloir vérifier où les données sont traitées et quelles règles internes - ou obligations de protection des données - s'appliquent. La présence d'un serveur MCP ne règle pas ces points à elle seule.
Le principe le plus solide reste de confier chaque partie au composant qui la maîtrise le mieux : l'agent pour la langue quand c'est pertinent, le service pour les structures de documents, les règles de reconstruction et la cohérence globale du flux.
Pourquoi la traduction d'images réclame-t-elle un autre modèle ?
Traduire du texte dans un document et du texte dans une image ne pose pas le même problème technique.
Dans un Markdown ou un notebook, le texte est déjà là, sous forme de caractères. On peut repérer les segments, protéger certains éléments, puis reconstruire le document après traduction.
Dans une image, le texte est « collé » à une composition visuelle. Le système doit le détecter, comprendre sa position, puis placer la traduction dans une zone adaptée. Cela suppose souvent une reconnaissance optique de caractères, des coordonnées (ou des boîtes englobantes) et un rendu qui respecte la mise en page. Même si la traduction linguistique est bonne, elle peut échouer si elle recouvre un élément important, déborde de sa zone, ou change la lecture de l'image.
Le contenu visuel impose une chaîne spécialisée
Pour Co-op Translator, traduire des images reste donc adossé à un fournisseur qui sait gérer la vision, notamment Azure AI Vision pour extraire le texte et obtenir des informations de mise en page. Le modèle de traduction ne suffit pas : il faut aussi des données spatiales pour replacer le texte dans l'image.
Cette dépendance a des conséquences concrètes : il faut prévoir les accès au fournisseur, estimer les coûts et tester sur les types d'images réellement utilisés. Les contraintes changent selon qu'il s'agit d'une capture d'écran, d'une infographie, ou d'une photo contenant du texte. Au fond, une traduction automatisée ne garantit pas une composition visuelle satisfaisante dans tous les cas.
Ne pas confondre MCP et « sans fournisseur »
Avoir un serveur MCP ne veut pas dire que toutes les tâches deviennent locales ou sans dépendance externe. MCP définit une manière d'exposer des outils à une application hôte ; il ne supprime pas les besoins propres à chaque traitement. Un flux texte peut déléguer la traduction à l'agent, tandis qu'un flux visuel nécessite encore un service spécialisé.
Il faut donc l'écrire clairement. Ça évite de laisser croire qu'un utilisateur pourra traiter des images avec les mêmes prérequis qu'un dépôt Markdown. Et ça aide à choisir l'architecture selon la nature des données : texte structuré d'un côté, image et géométrie de l'autre.
La bonne question n'est pas « peut-on tout faire sans fournisseur ? ». La bonne question, c'est quel mode correspond le mieux à la nature des données et au résultat attendu. Pour les images, la qualité dépend autant de la détection et du placement que de la traduction elle-même.
Conclusion
Le message principal est simple : une API destinée à un agent doit rendre plus explicites ses limites que ce que fait une commande destinée à une personne. Des opérations ciblées rendent les actions composables et vérifiables ; une orchestration complète reste utile pour les traitements de projet ; et des valeurs par défaut prudentes évitent les écritures silencieuses.
Pour la traduction, la répartition du travail dépend aussi du contenu. Un agent peut traduire le texte, pendant que le service protège et reconstruit le document. Pour une image, il faut en plus une chaîne de vision et de rendu. Avant d'exposer un outil via MCP, il faut donc identifier ses effets de bord, les étapes qu'il faut garder séparées, et les décisions qui nécessitent une confirmation. C'est cette façon de concevoir le flux - plus que la simple publication de fonctions - qui rend un outil vraiment utilisable par un agent.
Comment découper les outils MCP pour les rendre composables ?
Le découpage commence par les responsabilités, pas par la liste des fonctions « déjà là ». Pour traduire un fichier Markdown, traduire le contenu et réécrire les chemins, ce sont deux opérations distinctes. La première touche au texte et à sa structure. La seconde dépend de l'emplacement source, de l'emplacement cible et d'une politique de réécriture.
On peut visualiser ça comme suit :
Les deux premières opérations font un travail précis. La troisième garde un rôle d'orchestration au niveau du projet, proche de la commande en ligne de commande. Et le point important n'est pas « combien » de fonctions exposer. Le point, c'est que chaque opération modifie quelque chose de compréhensible, avec un « pourquoi ».
Séparer le contenu de son emplacement
Un contenu traduit peut être correct, tandis que les liens ne le sont pas. L'inverse arrive aussi : les chemins sont réécrits correctement, mais il reste un problème de traduction. Si le même outil traite tout sans distinguer les résultats, l'agent ne peut pas facilement gérer chaque type de problème séparément.
En passant explicitement les chemins source et cible à l'outil de réécriture, on donne au service le contexte nécessaire. L'agent peut alors décider quand appeler cette étape, examiner le contenu avant, ou changer la politique de chemins. Résultat : un comportement plus prévisible et des erreurs plus faciles à isoler.
Garder une orchestration pour le travail global
Découper ne veut pas dire supprimer les opérations de haut niveau. Si quelqu'un veut traduire un dépôt entier, il a besoin d'un parcours orchestré. Il est donc logique de conserver une opération « projet », comme
run_translation, tout en proposant des briques plus fines pour les cas où l'agent doit intervenir étape par étape.On obtient alors deux niveaux complémentaires :
C'est autant un choix produit qu'un choix d'API. En pratique, le bon niveau d'abstraction dépend du coût d'une erreur et de la fréquence à laquelle l'utilisateur devra intervenir. Si l'action ne laisse pas beaucoup de traces, une opération large suffit. Pour une écriture qui touche de nombreux fichiers, mieux vaut des étapes visibles, plus contrôlables. L'agent compose alors le flux au lieu de deviner les effets d'une commande opaque.