YADRO a remplacé Smartcat par Weblate, Dify et Qwen, divisant par six le coût par mot

Quand la facture du service de traduction augmente au même rythme que le volume de documentation, une idée finit tôt ou tard par s’imposer : pourquoi ne pas tout héberger en interne ? C’est exactement ce qu’a fait l’équipe de documentation technique de YADRO. Smartcat facturait chaque mot importé, même s’il avait déjà été traduit, puis est devenu encore plus cher après sa transformation en « plateforme d’IA ». L’équipe a construit son propre système de localisation et l’a baptisé « Tolmach ».

Les composants du système

Le nouvel outil devait répondre à trois exigences : toutes les données devaient rester sur les serveurs de l’entreprise, le fonctionnement avec les LLM devait être configurable avec souplesse, et une interface web ou une architecture client-serveur devait être disponible. Parmi les solutions open source candidates, Zing et Weblate sont arrivés en finale. Zing, créé par Evernote, a été écarté : ses développeurs ont annoncé qu’ils ne le maintenaient plus et recherchaient un nouveau mainteneur, faute de quoi le projet serait fermé. Weblate, lui, est toujours actif, dispose d’une communauté et d’un support professionnel payant, ainsi que d’une API et d’une intégration aux systèmes de gestion de versions.

Le deuxième composant est Serge. Il récupère les fichiers sources dans Git, utilise des parseurs pour extraire les chaînes à traduire — DITA, fichiers de configuration et code source — puis les rassemble dans des fichiers PO, le standard du secteur de la localisation. Une fois la traduction terminée, le processus s’exécute dans l’autre sens : les chaînes finalisées sont réintégrées aux sources et renvoyées dans le dépôt. Les développeurs restent dans Git, tandis que les traducteurs n’ont pas à comprendre les formats de fichiers.

Où intervient le LLM

Dify, une plateforme permettant de construire des applications basées sur des LLM, se trouve entre Weblate et le modèle. Le pipeline est simple : texte, modèle, post-traitement, réponse. La traduction est assurée par le modèle de raisonnement Qwen3.6-35B-A3B sur le propre cluster d’inférence de l’entreprise. Lorsqu’un réviseur ouvre l’onglet Automatic suggestion, Weblate envoie la chaîne à Dify et la réponse arrive en environ 0,63 seconde. La connexion a été configurée au moyen de fichiers de configuration Docker. L’importation des fichiers PO dans Weblate a dû être automatisée par un script utilisant l’API REST, car les commandes intégrées n’ont pas fonctionné.

Deux techniques pratiques méritent l’attention. Premièrement, un long prompt comportant une dizaine d’interdictions peut être remplacé par une sortie structurée. Les auteurs ont défini un schéma JSON ne contenant qu’un champ, russian_translation, et le modèle a cessé d’ajouter des formules comme « bien sûr, voici votre traduction ». Le prompt système a ainsi été réduit à une seule phrase. Deuxièmement, tout ce qui peut être fait dans le code doit l’être dans le code. Le modèle produit obstinément la lettre « ё », bien qu’elle ne soit pas utilisée dans la documentation, et tenter de l’en empêcher dans le prompt dégradait la qualité de la traduction elle-même. La solution tient en deux lignes de remplacement lors du post-traitement.

Combien cela coûte et où se trouve le piège

Le calcul repose sur une carte graphique coûtant 5 millions de roubles, une durée de vie de 5 ans et un taux d’utilisation de 30–40 %. Un segment d’un seul mot coûte 0,40 ₽ ; pour un segment de 250 mots, le coût est d’environ 0,0048 ₽ par mot. Smartcat facture environ 2,5 ₽, soit un écart de l’ordre de six fois dans le scénario le moins favorable au modèle local. Mais ce calcul n’inclut ni le serveur, ni l’électricité, ni les salaires des ingénieurs, ni les autres dépenses d’exploitation : les économies réelles sont donc plus modestes.

La qualité n’est pas parfaite non plus. Le modèle peut halluciner, enfreindre la terminologie et casser la mise en forme. Comme le traitement s’effectue segment par segment, les traductions ne sont pas toujours cohérentes. Une relecture finale par un rédacteur technique reste donc indispensable.

Ce qu’il faut en retenir

Si vous gérez beaucoup de documentation et que les données ne peuvent pas quitter l’entreprise, l’association de Git, Serge, Weblate et Dify constitue une architecture viable. La sortie structurée à la place de longs prompts et le déplacement des règles déterministes dans le code sont également utiles dans n’importe quel autre pipeline LLM. En revanche, l’affirmation « six fois moins cher » doit être considérée avec prudence : calculez votre coût total de possession, y compris les ressources humaines et l’exploitation. L’auteur promet un guide de déploiement complet dans une deuxième partie.