Table des matières
La plupart des AI translation tools suivent le même schéma : coller du texte, obtenir une traduction. Ça fonctionne pour un e-mail rapide, mais ça s'effondre quand vous gérez des milliers de clés de traduction dans une application de production avec plusieurs langues, un glossaire de termes de marque, et une équipe qui doit examiner les changements avant leur déploiement.
Nous avons construit le système AI de Better i18n différemment. Au lieu d'une simple API de traduction, nous avons créé un agent conversationnel avec 23 outils spécialisés, une approbation Human-in-the-Loop pour chaque opération d'écriture, et une architecture conçue pour les workflows réels de gestion des traductions.
Cet article présente l'ingénierie derrière tout cela.
Pourquoi un Agent et non une API de traduction ?
Le workflow typique de révision de traduction automatique ressemble à ceci : exporter les chaînes, les envoyer à un service de traduction, récupérer les résultats, les importer, réviser manuellement, corriger les problèmes, re-exporter. C'est lent, sujet aux erreurs, et déconnecte le processus de traduction du contexte qui rend les traductions précises.
Une approche basée sur un Agent change fondamentalement le modèle. Au lieu d'opérer sur des fichiers, l'AI opère directement sur votre projet — en lisant vos clés, en comprenant votre glossaire, en vérifiant votre configuration de synchronisation, et en proposant des changements que vous approuvez en temps réel.
L'insight clé est que la gestion des traductions n'est pas une tâche unique. C'est un workflow qui implique la lecture de l'état du projet, la prise de décisions, l'exécution de changements, et la vérification des résultats. Un Agent avec plusieurs outils gère cela naturellement. Une API de traduction ne le fait pas.
L'architecture à 23 outils
L'Agent a accès à 23 outils dédiés, répartis en deux catégories avec des modèles de permissions très différents.
Outils de lecture : Autonomie totale
Dix outils donnent à l'Agent un accès en lecture à votre projet. Ceux-ci s'exécutent automatiquement sans nécessiter d'approbation, car ils ne peuvent pas modifier les données :
- getTranslations — récupère les traductions avec filtrage par clé, namespace, langue et statut
- getKeyDetails — récupère les métadonnées pour les clés individuelles, y compris les notes de contexte, les étiquettes et le statut par langue
- getLanguages — liste les langues configurées avec les pourcentages de complétion
- getProjectStats — retourne les métriques du projet : clés totales, langues, couverture de traduction
- getDoctorReport — effectue des diagnostics pour identifier les traductions manquantes, les clés non utilisées, les problèmes de formes plurielles et les incohérences terminologiques
- getSyncs et getSyncDetails — inspecte les intégrations de synchronisation GitHub/GitLab et leur activité récente
- getContentModels et getContentEntries — parcourt la structure de contenu CMS et les entrées
- createPlan — génère un plan d'exécution quand l'Agent doit coordonner plusieurs étapes
L'Agent utilise ces outils pour construire le contexte avant de proposer des changements. Quand vous demandez « traduire toutes les clés manquantes en français », l'Agent appelle d'abord getTranslations pour identifier exactement quelles clés manquent, puis appelle getProjectStats pour comprendre l'étendue, avant de générer une proposition unique et ciblée.
Outils d'écriture : Approbation Human-in-the-Loop
Onze outils peuvent modifier les données de votre projet. Chacun d'eux nécessite une approbation humaine explicite avant exécution. C'est le cœur de notre approche de la qualité de traduction AI — l'AI propose, l'humain décide.
Outils de traduction :
- proposeTranslations — génère de nouvelles traductions pour les clés manquantes dans les langues cibles
- proposeTranslationEdits — suggère des améliorations aux traductions existantes basées sur le contexte, le glossaire ou vos retours
- translateBatch — traite plusieurs clés dans plusieurs langues en une seule opération
Outils de gestion des clés :
- proposeKeys — suggère de nouvelles clés de traduction basées sur l'analyse du codebase
- proposeDeleteKeys — identifie les clés non utilisées ou dupliquées et propose leur suppression
Outils de gestion des langues :
- proposeLanguages — recommande de nouvelles langues à ajouter selon les besoins du projet
- proposeLanguageEdits — modifie les noms d'affichage des langues, les chaînes de fallback ou la configuration
Outils de publication :
- publishChanges — envoie les traductions approuvées au CDN ou déclenche un GitHub PR
Outils de gestion de contenu :
- proposeContentEntries — crée ou met à jour des entrées de contenu CMS
- proposeContentModel — suggère des changements de schéma aux modèles de contenu
- proposePublishEntries — met en file d'attente les entrées de contenu pour publication
Human-in-the-Loop : L'ingénierie du flux d'approbation
Le terme « Human-in-the-Loop » est beaucoup utilisé dans le marketing AI. Voici comment cela fonctionne réellement dans notre système.
Quand un outil d'écriture est appelé, l'Agent ne l'exécute pas directement. À la place, il génère une proposition — un diff structuré montrant exactement ce qui va changer. La proposition apparaît dans l'interface de chat comme un artefact révisable.
Pour les propositions de traduction, vous voyez :
- La chaîne source dans votre langue de base
- La traduction proposée dans la langue cible
- Les termes du glossaire qui ont été appliqués
- Le contexte de confiance (est-ce une simple étiquette UI ou une phrase marketing complexe ?)
Vous avez ensuite trois options :
- Tout approuver — accepter tous les changements proposés en un clic
- Approbation sélective — accepter certaines traductions et en rejeter d'autres
- Demander des modifications — indiquer à l'Agent ce qu'il faut corriger et il génère une proposition révisée
L'opération d'écriture n'est exécutée qu'après approbation. Ce n'est pas une boîte de dialogue « confirmer/annuler » — c'est une étape de révision authentique où vous pouvez inspecter, modifier et itérer.
Pourquoi c'est important pour la qualité de traduction AI
La révision de traduction automatique est le goulot d'étranglement dans la plupart des workflows de localisation. Les équipes soit sautent la révision (et publient des erreurs) soit révisent tout manuellement (et avancent lentement). Notre approche HITL trouve le juste milieu :
- L'AI gère les 80 % de traductions qui sont simples
- Les humains concentrent leur effort de révision sur les 20 % qui nécessitent du jugement
- Chaque traduction a une provenance claire : générée par AI, révisée par un humain, ou modifiée par un humain
- L'audit trail enregistre qui a approuvé quoi, simplifiant la conformité
Rendu progressif : Tables de traduction en streaming
Quand l'Agent génère des traductions pour un lot de clés, les résultats n'apparaissent pas tous en même temps. La table de traduction se diffuse progressivement dans l'interface de chat — chaque ligne se rend quand sa traduction est complète.
C'est un choix d'ingénierie motivé par l'expérience utilisateur. Quand vous traduisez 150 clés dans 6 langues, cela représente 900 traductions individuelles. Attendre que les 900 soient complètes avant d'afficher quoi que ce soit signifierait fixer un spinner de chargement pendant des minutes. Le rendu progressif vous permet de commencer à réviser les premiers résultats immédiatement.
L'implémentation utilise des server-sent events pour diffuser les résultats des outils vers l'interface de chat. Le frontend maintient un composant de table de traduction mutable qui ajoute des lignes à mesure qu'elles arrivent.
Gestion du contexte : Rester ancré
Les grands modèles de langage ont tendance à perdre le contexte dans les longues conversations. Nous y remédions avec trois mécanismes :
Cache de contexte de projet de 30 secondes
Quand l'Agent lit les données de votre projet, les résultats sont mis en cache pendant 30 secondes. Si l'Agent doit référencer l'état de votre projet plusieurs fois au cours d'une opération en plusieurs étapes, il accède au cache plutôt que de faire des appels API redondants. Cela réduit la latence et empêche l'Agent de voir un état incohérent lors d'un workflow complexe.
Réduction du contexte (slimToolResults)
Les réponses des outils de l'API Better i18n peuvent être volumineuses — un projet avec 2 000 clés et 12 langues génère des payloads conséquents. Le système slimToolResults supprime automatiquement les données non essentielles des réponses d'outils avant qu'elles n'entrent dans le contexte de conversation.
Par exemple, quand l'Agent appelle getTranslations, la réponse complète inclut des métadonnées comme les horodatages de création, les IDs de version et les attributions d'utilisateurs. Le passage slimToolResults conserve uniquement les données dont l'Agent a besoin : les noms de clés, les chaînes sources et les traductions. Cela réduit significativement l'utilisation des tokens et évite le débordement du context window.
Limite de 50 étapes de conversation
Chaque conversation prend en charge jusqu'à 50 étapes d'Agent (appels d'outils). C'est suffisant pour des workflows complexes — traduire un namespace entier, réviser les résultats, effectuer des modifications et publier — tout en évitant les boucles incontrôlées. Le compteur d'étapes est visible dans l'UI pour que vous sachiez toujours quelle capacité reste disponible.
Historique du chat : Architecture de stockage double
Les conversations d'Agent sont stockées à deux endroits simultanément :
- IndexedDB (local au navigateur) — fournit un chargement instantané des conversations sans latence réseau quand vous revenez au tableau de bord
- Postgres (côté serveur) — maintient un audit trail persistant et consultable de chaque interaction avec l'Agent
L'approche de stockage double résout deux exigences concurrentes. Les développeurs veulent un accès instantané aux conversations récentes (IndexedDB offre des lectures en sous-milliseconde). Les équipes ont besoin d'audit trails pour la conformité et le partage des connaissances (Postgres fournit un stockage durable et interrogeable).
Quand vous ouvrez le chat AI, les conversations se chargent depuis IndexedDB immédiatement. La copie Postgres se synchronise en arrière-plan et sert de source de vérité si le stockage local est effacé.
Workflow réel : Ajouter le coréen à une app de production
Voici un exemple concret de la façon dont l'Agent gère une vraie tâche.
Étape 1 : Vous demandez — « J'ai besoin d'ajouter le coréen au projet. Traduire tout dans les namespaces common et settings. »
Étape 2 : L'Agent lit — Il appelle getLanguages (voit que le coréen n'est pas configuré), getTranslations pour le namespace common (trouve 89 clés) et getTranslations pour le namespace settings (trouve 34 clés). Total : 123 clés à traduire.
Étape 3 : L'Agent propose l'ajout de la langue — Il appelle proposeLanguages pour ajouter le coréen (ko) au projet. Vous voyez la proposition et l'approuvez.
Étape 4 : L'Agent traduit par lots — Il appelle translateBatch pour le namespace common, puis le namespace settings. Les traductions se diffusent progressivement dans le chat. Vous voyez les traductions coréennes apparaître aux côtés des chaînes sources en anglais.
Étape 5 : Vous révisez — Vous parcourez les traductions, signalez deux qui utilisent un registre trop formel pour l'UI d'une app décontractée, et indiquez à l'Agent de les ajuster.
Étape 6 : L'Agent révise — Il appelle proposeTranslationEdits avec vos retours et génère des traductions révisées pour les deux chaînes signalées. Vous approuvez.
Étape 7 : Vous publiez — Vous demandez à l'Agent de publier, il appelle publishChanges, et les traductions coréennes sont en ligne sur le CDN.
Temps total : environ 10 minutes pour 123 traductions, révisées et publiées. Sans l'Agent, ce workflow prend généralement des heures de cycles exporter-traduire-importer-réviser.
Ce que nous avons choisi de ne pas construire
La transparence sur les limites est aussi importante que la documentation des fonctionnalités.
- Pas de moteur de traduction propriétaire — nous utilisons Google Gemini comme modèle sous-jacent. Nous ne revendiquons pas un « moteur de traduction neuronale » personnalisé ni une AI propriétaire.
- Pas de tests A/B automatisés de traductions — vous choisissez le modèle ; il n'y a pas de framework comparant les sorties de plusieurs modèles.
- Pas de Translation Memory — nous utilisons la cohérence terminologique basée sur le glossaire, pas le fuzzy matching TM. Si vous avez besoin de TM, Better i18n n'est pas le bon outil aujourd'hui.
- Pas de métriques de précision garanties — la qualité de traduction AI varie selon la paire de langues et le type de contenu. Nous recommandons une révision humaine pour tout le contenu orienté client, ce qui est exactement pourquoi le HITL est intégré dans chaque opération d'écriture.
Essayez-le
L'AI Agent est disponible sur tous les plans Better i18n. Ouvrez le tableau de bord, cliquez sur l'icône de chat et commencez par quelque chose de simple : « Montre-moi le statut des traductions pour ce projet. »
Ensuite, essayez une vraie tâche. Demandez-lui de trouver les traductions manquantes, de les générer et de vous guider à travers le processus d'approbation. L'Agent est conçu pour être exploré de façon conversationnelle — vous n'avez pas besoin de mémoriser les noms des outils ou les endpoints API.
