Quand les agents de code traduisent votre application : ce qui casse, ce qu'il faut garder

La traduction assistée par agent (agent-assisted translation) est la pratique consistant à laisser un agent de code IA, l'assistant qui lit et modifie déjà votre base de code, ajouter des clés de traduction et rédiger les chaînes traduites dans le cadre d'un changement de code, au lieu de confier les chaînes à une étape de traduction séparée après coup. C'est rapide, peu coûteux, et pour une seule pull request souvent bon. Les problèmes ne sont pas dans cette pull request. Ils sont dans la douzième.

Ce billet est un article de catégorie, pas un comparatif. Il porte sur ce que les agents font vraiment bien, ce qui ne se conserve pas d'une version à l'autre, et le schéma qui garde la vitesse sans perdre la trace.

Ce que les agents font vraiment bien

La version honnête commence par les forces, parce qu'elles sont réelles. Un agent de code à qui l'on demande d'ajouter un écran de paramètres en six langues dispose, au moment d'écrire le libellé allemand, de plus de contexte qu'un traducteur qui reçoit un tableur : il sait que le composant est un bouton, que {{count}} est un nombre et non un nom, ce que disent les chaînes voisines, comment le développeur précédent a nommé des clés similaires, et si la valeur est interpolée dans une phrase. Il écrit la clé, la valeur par défaut et les traductions en une seule passe, sans transfert, sans export, sans attente.

Il est aussi bon pour la plomberie qui bloquait autrefois entièrement la localisation. Les agents branchent une bibliothèque i18n, enveloppent les chaînes en dur, extraient les clés et lancent la commande de synchronisation, et ils le font pour la fonctionnalité secondaire pour laquelle aucune équipe n'aurait budgété un cycle de traduction. Des fonctionnalités qui sortaient autrefois en anglais uniquement sortent désormais dans toutes les langues du projet. Ce n'est pas rien, et aucune critique de la traduction par agent ne devrait prétendre le contraire.

Ce qui casse dans le temps

Tout ce qui suit est invisible dans une seule pull request. Cela apparaît d'une pull request à l'autre, et c'est pourquoi les équipes s'en aperçoivent tard.

La cohérence entre les versions

Chaque exécution d'un agent part d'un contexte vide. Rien dans la session ne se souvient que le nom du produit reste non traduit, que « subscription » est devenu « Abo » et non « Abonnement » en allemand trois versions plus tôt, ou que l'espagnol utilise « tú » et non « usted ». L'agent choisit une formulation défendable isolément, et une autre formulation défendable le mois suivant. Le registre est le cas le plus pénible : dans les langues où la distinction est grammaticale, un écran qui vouvoie suivi d'un écran qui tutoie se lit comme un bug, pas comme un choix de style.

La relecture et la provenance

Quand un client, un avocat ou un auditeur demande pourquoi l'application a dit ce qu'elle a dit en italien, un pipeline de fichiers édités par un agent n'a qu'une réponse : un commit signé par un bot, approuvé par un relecteur qui ne lisait pas l'italien et a vérifié le diff pour la syntaxe. Il n'y a pas de relecteur attitré, pas de trace de décision par chaîne, et aucun moyen de distinguer la supposition d'un agent du choix d'un traducteur une fois que les deux sont dans le même fichier. Depuis le 2 août 2026, c'est aussi une question réglementaire : l'article 50 du règlement européen sur l'IA s'applique, et selon les lignes directrices finales de la Commission, une traduction IA fidèle est exemptée du marquage lisible par machine, tandis que les textes qui informent le public sur des questions d'intérêt public nécessitent une divulgation visible, sauf s'ils ont fait l'objet d'une relecture humaine documentée avec une personne assumant la responsabilité éditoriale. Le détail juridique est dans l'explication de l'article 50 ; la conséquence pratique est que « relu » doit être quelque chose que vous pouvez montrer, segment par segment, et un workflow de relecture est ce qui produit cette preuve. Rien de tout cela n'est un conseil juridique.

La gouvernance terminologique

Le glossaire existe, généralement sous forme de document. L'agent le lit ou non, le lit dans une session et pas dans la suivante, et ne peut pas savoir qu'un terme a été ajouté après sa dernière exécution. Les termes interdits reviennent. Les noms de produits sont traduits. Le correctif qu'on propose alors, « mettre le glossaire dans les instructions de l'agent », fonctionne jusqu'à ce que le glossaire ait quatre cents entrées et que les instructions doivent aussi couvrir tout le reste. La terminologie est un problème de données, et des données qu'un processus sans état doit retenir ne sont pas gouvernées, elles sont espérées. Le glossaire a sa place dans un système que l'agent peut interroger, pas dans un prompt.

La QA sur le corpus, pas sur le diff

Un agent vérifie les chaînes qu'il a touchées. Les défauts qui atteignent réellement la production sont transversaux aux clés : la même valeur source traduite de trois façons selon les namespaces, un placeholder présent dans onze langues et perdu dans la douzième, un nombre modifié en chemin. On les trouve en comparant chaque valeur d'une langue à sa source et au reste de cette langue, à chaque enregistrement, ce qu'aucune relecture de pull request ne fait. La taxonomie et la façon dont les contrôles automatiques la détectent sont dans ce qui casse vraiment dans les traductions.

Pluriels, placeholders et chaînes à risque

Les langues qui ont plus de deux formes de pluriel (polonais, arabe, russe) ont besoin de formes que la source anglaise n'a pas. Les agents les produisent correctement isolément et de façon incohérente en masse, et une clé _few erronée est un bug d'exécution, pas un problème de style. Puis il y a les chaînes pour lesquelles « le modèle a généralement raison » n'est pas un niveau acceptable : mentions légales, conditions tarifaires, formulations médicales et de sécurité, libellés d'accessibilité. Un agent les traite comme n'importe quelle autre chaîne, parce que dans le diff elles ressemblent à n'importe quelle autre chaîne.

Comment les équipes gèrent la traduction par agent de code aujourd'hui

Quatre configurations couvrent l'essentiel de ce que nous observons, et la remarque honnête est que la première convient à certaines équipes.

• L'agent édite les fichiers de langue dans la pull request. Le plus rapide, le moins cher, et très bien tant que les membres de l'équipe lisent toutes les langues et que rien ne dépend du texte. La dérive décrite ci-dessus commence le premier jour et devient visible vers la dixième version.
• L'agent plus une étape LLM en CI. L'agent ajoute les clés, un workflow au push traduit automatiquement les valeurs manquantes. Supprime entièrement la partie manuelle, et reproduit les mêmes défaillances à la vitesse du pipeline : sortie non relue, aucune mémoire entre les exécutions, aucune application de la terminologie. Le chemin pour sortir de cette configuration est décrit dans quand les traductions IA cassent.
• L'agent rédige, une personne relit le diff. Meilleur dans l'esprit, faible en pratique : un relecteur de pull request voit douze fichiers de langue et peut en juger un ou deux. La relecture est réelle pour les langues que le relecteur lit et du théâtre pour le reste.
• L'agent rédige à travers un système de gestion de traduction. L'agent continue de rédiger, mais la terminologie, la mémoire des décisions passées, la file de relecture et l'historique vivent dans le système, et l'agent y lit et y écrit. C'est le schéma que décrit la suite de ce billet.

Le schéma agent-in-the-loop : ce qu'il faut garder

Quel que soit l'outillage, le schéma a cinq règles.

1. La terminologie et la voix viennent du système, pas du prompt. Avant que l'agent ne rédige une chaîne, il récupère le glossaire du projet (termes préférés, autorisés et interdits par langue) et le guide de style (ton, registre, public). Les instructions disent « consulte ceci », pas « voici quatre cents termes ».
2. Réutiliser avant d'inventer. Une recherche dans la mémoire de traduction sur des chaînes sources similaires vient en premier. Une correspondance à score élevé est réutilisée, et c'est ainsi que la douzième version reste cohérente avec la première.
3. La provenance est déclarée, pas déduite. La sortie de l'agent est poussée comme sortie IA, ce qui la place dans la file de relecture au lieu de la production. La modification d'une personne est poussée comme la modification d'une personne. Une fois les deux dans le même fichier sans marqueur, la distinction est perdue pour de bon.
4. La relecture se fait par segment, par quelqu'un qui lit la langue, et elle est consignée. Pas une approbation de pull request, pas un sondage sur deux langues : un relecteur confirme ou modifie chaque valeur dans un éditeur qui montre la source, le contexte et le glossaire, et la décision est écrite dans l'historique avec son nom et l'heure.
5. Les contrôles s'exécutent sur le corpus après la fusion, pas seulement sur le diff avant. Cohérence, placeholders, nombres, balises : les contrôles qui comparent à la langue entière doivent s'exécuter là où se trouve la langue entière.

Ce que cela ne résout pas

• Quelqu'un doit encore lire le polonais. Le schéma rend la relecture peu coûteuse et ciblée ; il ne la fait pas disparaître. La quality estimation peut laisser passer les ébauches sûres et retenir les douteuses, mais la décision sur une chaîne douteuse est un travail humain.
• Le texte source est lui aussi écrit par l'agent. Les agents écrivent l'anglais autant que l'allemand, et les chaînes anglaises dérivent en terminologie exactement comme les traductions. Un lint des termes interdits sur les nouvelles chaînes sources en attrape une partie ; un rédacteur attrape le reste.
• Les chaînes à risque restent une question de politique. Quelles chaînes exigent une personne quelle que soit la confiance, quels contenus relèvent de la divulgation d'intérêt public, et qui assume la responsabilité éditoriale d'une publication sont des décisions qu'un outil consigne mais ne prend pas.
• Les petits projets peuvent se passer de tout cela. Deux langues que l'équipe lit, aucun revenu ni conformité sur le texte : laissez l'agent éditer les fichiers. Le signal pour changer, c'est la première langue que personne dans l'équipe ne lit.

Comment cela fonctionne dans Locize

Locize expose la partie système du schéma aux agents via son serveur MCP, accessible à https://mcp.locize.app depuis Claude, Cursor, GitHub Copilot et d'autres clients MCP, avec 26 outils au total. Les boucles de traduction pilotées par des agents (trouver les clés manquantes, récupérer la source, pousser des ébauches, lire la file de relecture) représentent une part visible et en croissance régulière du trafic de ce serveur.

• Du contexte avant l'ébauche. get_glossary renvoie les termes préférés, autorisés et interdits par langue ; get_styleguide renvoie le ton, le registre, le public et les règles d'usage ; search_translation_memory retrouve les traductions antérieures de chaînes sources similaires, exactes et approximatives ; get_screenshot_context montre où apparaît une clé ambiguë. Les quatre sont en lecture seule, et le billet sur les outils de contexte les passe en revue.
• Les ébauches arrivent en relecture, pas en production. report_missing_keys crée de nouvelles clés sans écraser les existantes (et déclenche la traduction automatique là où elle est activée). update_translations accepte une quality de AI pour les textes générés par l'agent ou HT pour le texte d'une personne ; les valeurs IA sont marquées à relire selon la règle du projet (toujours, ou seulement lorsque le score de quality estimation est sous le seuil), et find_missing_translations ainsi que get_translations avec needsReviewOnly permettent à l'agent de lire la file qu'il vient de remplir.
• Une personne décide, et l'historique dit qui. Les relecteurs confirment, modifient ou refusent dans l'éditeur ; le workflow de relecture consigne chaque décision, et l'export de provenance décrit dans le guide du workflow article 50 l'emballe en CSV et JSON.

La file « needs review » dans l'éditeur Locize : valeurs marquées et propositions en attente, confirmées valeur par valeur par un relecteur

• Des valeurs par défaut, pour que personne n'ait à retenir les règles. Le dépôt public locize-agents contient des fichiers de conventions (CLAUDE.md, AGENTS.md, .cursorrules) qui font qu'un agent récupère le glossaire, le guide de style et la mémoire avant de traduire, et vérifie les pull requests à la recherche de termes interdits. Pour les projets pas encore connectés, npx i18next-cli init --agent-note (i18next-cli 1.73 ou plus récent) ajoute une courte note d'internationalisation à AGENTS.md, pour que la prochaine session d'agent sache où vivent les fichiers de langue, quelles commandes lancer, et qu'elle doit demander avant de brancher un service de traduction.

L'agent garde sa vitesse. Ce qui change, c'est que ses ébauches arrivent quelque part où il y a une mémoire, un relecteur et une trace. Si votre agent traduit déjà, créez un projet, connectez le serveur MCP, et laissez la prochaine pull request rédiger à travers lui ; la file de relecture vous montrera ce que les précédentes auraient livré.

Questions fréquentes

Les agents de code IA peuvent-ils traduire une application ? Oui, et pour un changement isolé souvent bien : avec la base de code en contexte, un agent voit le composant, les types des placeholders, le texte voisin et l'historique git. Ce qu'il ne conserve pas dans le temps, c'est la cohérence entre les versions, une trace de qui a approuvé quoi, la terminologie décidée en dehors de la session en cours, et des contrôles qualité sur l'ensemble du corpus. L'agent est un bon rédacteur d'ébauches ; les ébauches ont besoin d'un système derrière elles.

Que se passe-t-il quand un agent de code édite directement les fichiers de traduction ? Rien de visible dans la pull request. D'une pull request à l'autre, le même concept est rendu différemment, le registre bascule entre les écrans, les formes de pluriel des langues qui en ont plus de deux sont devinées de façon incohérente, et la seule trace d'une décision est un commit signé par un bot. Les contrôles qui comparent une traduction à sa source et au reste de la langue ne s'exécutent pas sur un diff, donc les défauts s'accumulent sans être remarqués.

Qu'est-ce que le schéma agent-in-the-loop pour la traduction ? L'agent reste le rédacteur des ébauches mais rédige à travers le système de gestion de traduction : il récupère le glossaire, le guide de style et les entrées correspondantes de la mémoire de traduction avant d'écrire, signale les nouvelles clés et pousse ses traductions déclarées comme sortie IA, ce qui les place dans la file de relecture ; une personne qui lit la langue confirme ou modifie chaque valeur, et la décision est consignée.

Le règlement européen sur l'IA s'applique-t-il aux traductions rédigées par un agent de code ? L'article 50 s'applique depuis le 2 août 2026. Selon les lignes directrices finales de la Commission du 20 juillet 2026, une traduction IA fidèle est exemptée du marquage lisible par machine ; l'obligation de divulgation visible ne couvre que les textes publiés pour informer le public sur des questions d'intérêt public et tombe en cas de relecture humaine documentée sous une personne assumant la responsabilité éditoriale. Une étape de relecture consignée est la voie de l'exemption. Ceci n'est pas un conseil juridique.

Comment faire en sorte que mon agent de code utilise le glossaire et le guide de style ? Donnez-lui des outils plutôt que des documents : via le serveur MCP de Locize, il appelle get_glossary, get_styleguide et search_translation_memory avant de rédiger, et get_screenshot_context pour les chaînes ambiguës ; les fichiers de conventions du dépôt locize-agents en font le comportement par défaut. Pour les projets pas encore connectés, i18next-cli init --agent-note laisse une note dans AGENTS.md pour que la prochaine session d'agent connaisse la configuration et demande avant de brancher quoi que ce soit.