MCP et i18n : l'IA dans le workflow de traduction

Demandez à un assistant IA de traduire « Submit » et il vous renverra « Soumettre ». Correct ? Impossible à dire : s’agit-il d’un bouton d’envoi de formulaire, d’une candidature, d’un paiement ? Sans le contexte, même le meilleur modèle devine. C’est tout le problème de la traduction logicielle — et c’est exactement ce que le Model Context Protocol vient changer.

Cet article explique ce qu’est le MCP, pourquoi connecter l’IA à vos outils change la donne, et ce que cela débloque concrètement pour les équipes qui gèrent des produits multilingues. Si les bases de l’i18n vous manquent, commencez par Qu’est-ce que l’i18n ?.

Qu’est-ce que le MCP (Model Context Protocol) ?

Le Model Context Protocol est un standard ouvert, introduit par Anthropic, qui définit une façon commune de connecter un agent IA à des outils et à des données extérieurs. On le compare souvent à un « port USB-C pour l’IA » : au lieu d’inventer une intégration sur mesure pour chaque application, on expose ses capacités via un serveur MCP, et n’importe quel client compatible — un éditeur de code, un assistant de chat, un agent autonome — peut s’y brancher.

Concrètement, un serveur MCP publie deux choses : des ressources (des données que l’agent peut lire) et des outils (des actions que l’agent peut déclencher). L’agent ne se contente plus de produire du texte dans une fenêtre : il peut lire l’état réel de votre système et agir dessus, de façon encadrée.

Pourquoi connecter l’IA aux outils, et pas seulement au chat

Un modèle de langage dans une boîte de dialogue est brillant mais aveugle : il ne voit que ce que vous collez dedans. Il ignore où une chaîne est utilisée, quelles sont les conventions de votre glossaire, ce qui a déjà été traduit ailleurs. Vous passez donc votre temps à faire l’intermédiaire — copier le contexte, coller la réponse, vérifier à la main.

Le MCP supprime cet intermédiaire. En donnant à l’agent des yeux (lire le contexte) et des mains (agir dans l’outil), on le fait passer de « générateur de texte » à « participant au workflow ». La différence n’est pas cosmétique : c’est l’écart entre un assistant qui suggère et un collègue qui fait.

MCP ou simple API : quelle différence ?

« Mais une API REST ne fait-elle pas déjà ça ? » Pas tout à fait. Une API expose des points d’accès qu’un développeur doit lire, comprendre et câbler dans du code. Le MCP expose des outils qu’un agent IA peut découvrir et utiliser seul, à la volée, parce que chaque outil est décrit dans un format que le modèle sait interpréter.

Trois conséquences pratiques. D’abord, l’intégration est agnostique au client : le même serveur sert un éditeur, un assistant de chat ou un agent autonome, sans adaptateur sur mesure. Ensuite, elle est agnostique au modèle : changez de modèle IA, le branchement tient. Enfin, l’agent compose les outils — lire un contexte, puis proposer, puis vérifier — sans qu’on ait scripté la séquence à l’avance. C’est la différence entre brancher une intégration et donner une compétence.

Le workflow de traduction aujourd’hui

Pour mesurer ce que le MCP apporte, regardons comment la traduction se passe dans la plupart des équipes — et où ça coince.

• Des clés sans contexte. Un fichier de traduction est une liste de clés et de textes. Le traducteur voit checkout.submit = "Submit" mais pas le bouton, ni l’écran, ni la phrase voisine. Il devine.
• Le ping-pong d’outils. Le texte source vit dans le code, les traductions dans une plateforme, le glossaire dans un troisième endroit. On copie-colle entre les trois, et l’information se perd à chaque saut.
• La dérive du glossaire. « Panier », « caddie », « cart » : sans contrôle, un même concept finit traduit de trois façons selon qui a traité la clé.
• Le développeur bloqué. Une clé manque en production ? Il faut sortir de l’éditeur, ouvrir la plateforme, retrouver la clé, la traduire, republier. La friction décourage les petites corrections — et elles s’accumulent.

Aucun de ces problèmes n’est un problème de modèle IA. Ce sont des problèmes de contexte et d’outillage.

Ce que l’IA dans le workflow débloque

C’est ici que connecter l’IA à votre plateforme i18n via MCP devient intéressant. Sans entrer dans la recette, voici la valeur que cela ouvre.

• La traduction informée par le contexte. Parce que l’agent peut lire ce qui entoure une clé — son emplacement, les chaînes voisines, les notes laissées par l’équipe — il propose une traduction qui colle à l’usage réel, pas une traduction « au dictionnaire ». « Submit » redevient « Valider la commande » quand c’est un paiement.
• La cohérence terminologique automatique. L’agent peut confronter chaque proposition à votre glossaire et signaler — ou corriger — un écart, avant qu’une incohérence n’atteigne l’utilisateur.
• L’action là où vous travaillez. Parce que le client MCP vit dans l’outil du développeur (éditeur, CLI, agent), il lit, propose et applique sans jamais vous faire changer d’onglet. La correction d’une clé manquante redevient l’affaire d’une phrase, pas d’un détour de dix minutes.
• Le volume sans la corvée. Amorcer une nouvelle langue sur des centaines de clés, repérer les manques, harmoniser un vocabulaire : le travail mécanique est abattu en masse, et l’humain se concentre sur ce qui mérite son jugement.

Le point clé : l’IA ne remplace pas le système i18n, elle s’y branche. Vos clés, votre glossaire, vos statuts de validation restent la source de vérité ; l’agent travaille avec eux.

Un exemple : de la clé manquante à la correction

Imaginez un développeur qui ajoute un écran et, dans la foulée, une nouvelle clé de texte. Dans le workflow classique, cette clé partira non traduite vers une plateforme, attendra qu’un traducteur la remarque, puis reviendra — des jours plus tard, au mieux.

Avec un agent branché en MCP, la séquence se replie sur elle-même. L’agent repère la clé nouvellement apparue et sans traduction. Il rassemble le contexte — l’écran, les chaînes voisines, l’intention. Il propose une traduction dans chaque langue cible, alignée sur le glossaire. Et il la dépose au statut « à relire », prête pour un humain — le tout sans que personne ait quitté son éditeur.

Le gain n’est pas seulement la vitesse : c’est que le travail se fait au moment et à l’endroit où l’information est la plus fraîche, plutôt que reconstitué de mémoire une semaine plus tard par quelqu’un qui n’a jamais vu l’écran.

Garder l’humain aux commandes

Donner des mains à une IA n’est utile que si l’on garde le contrôle. Le bon modèle n’est pas « l’IA traduit et publie en silence », mais « l’IA propose, l’humain valide ». Les traductions générées arrivent à un statut intermédiaire — proposé, à relire — et un relecteur garde le dernier mot sur le ton, la marque, les nuances culturelles. Le MCP rend l’agent rapide ; le garde-fou humain le rend fiable. Les deux ensemble, pas l’un sans l’autre.

La vision : l’IA comme collègue dans le workflow

Pendant longtemps, l’i18n a opposé deux mondes : les développeurs qui posent les clés et les linguistes qui les traduisent, chacun dans son outil, séparés par des exports et des imports. Le MCP esquisse une troisième voie : un agent qui circule entre les deux, qui comprend le contexte technique et l’intention linguistique, et qui se rend utile à l’endroit exact où le travail se fait.

Ce n’est pas l’IA qui « fait la traduction » à votre place. C’est l’IA comme collègue : elle prend en charge les 80 % mécaniques — le contexte à rassembler, les manques à combler, la cohérence à tenir — pour que les humains gardent les 20 % qui demandent du goût et du jugement. C’est l’expérience que Sonenta rend possible : votre plateforme de traduction exposée via MCP, pour que l’assistant que vous utilisez déjà travaille directement avec vos clés — sans copier-coller, sans changer d’outil. La traduction validée rejoint ensuite votre pipeline de déploiement et part en production sans rebuild.