DocuTranslate : traduire des documents entiers en gardant la mise en forme, sauf en PDF

Le problème : traduire un fichier, pas du texte collé

Traduire un paragraphe dans une interface de chat est trivial. Traduire un mémoire de 80 pages avec ses tableaux, un epub chapitré ou un fichier de sous-titres horodaté ne l'est pas : il faut découper, envoyer, récupérer, replacer, et ne rien casser au passage. DocuTranslate prend ce relais. Le dépôt décrit un outil local qui accepte pdf, docx, xlsx, md, txt, json, epub, srt et ass, envoie le contenu textuel à un modèle de langage et réécrit la sortie dans un fichier du même type. Le public visé est identifiable : chercheurs qui traduisent des articles, traducteurs de romans, équipes qui doivent localiser des sous-titres ou des fichiers de ressources JSON. La contrainte commune à ces cas est le volume et la structure, pas la conversation.

Ce que devient un fichier entre l'entrée et la sortie

Le mécanisme dépend du format. Pour docx et xlsx, le README annonce une conservation de la mise en forme d'origine, ce qui suppose une manipulation du document au niveau de ses composants plutôt qu'une conversion en texte brut. Pour json, la traduction est ciblée : on indique les valeurs à traduire par des chemins en syntaxe jsonpath-ng, donc les clés et les valeurs non listées restent intactes. C'est la partie la plus solide du projet, parce qu'elle évite de confier au modèle des décisions qui relèvent de la structure. Le PDF suit un chemin différent et moins favorable : il est d'abord converti en markdown, puis traduit. Le README le dit sans détour, cette étape fait perdre la mise en page d'origine, et il renvoie les utilisateurs exigeants sur ce point à leurs propres conclusions. Pour les articles scientifiques, le parsing passe par mineru, déployable en ligne ou localement, afin de reconnaître tableaux, formules et code. Un glossaire peut être généré automatiquement pour aligner la terminologie d'un document à l'autre. Le tout est asynchrone, avec un nombre de requêtes concurrentes paramétrable, et peut servir plusieurs utilisateurs sur un réseau local.

Installation : pip, uv, git ou image Docker

Quatre voies sont documentées. La plus courte : pip install docutranslate, puis docutranslate -i pour lancer l'interface. Avec uv, il faut d'abord uv init, puis uv add docutranslate, et l'exécution se fait par uv run --no-dev docutranslate -i. Depuis les sources : git clone du dépôt, puis uv sync --no-dev dans le dossier. Enfin Docker, avec docker run -d -p 8010:8010 xunbu/docutranslate:latest. Le service écoute par défaut sur le port 8010, l'interface est à http://127.0.0.1:8010 et la documentation Swagger à /docs. Pour un accès depuis le réseau local, l'option --host 0.0.0.0 est requise, et --cors active les en-têtes correspondants. Le port se change avec -p. Une variante --with-mcp démarre l'interface avec un point de terminaison MCP partageant la file d'attente et le port. Le mode serveur MCP s'obtient avec docutranslate --mcp, en stdio par défaut, ou avec --transport sse et --transport streamable-http. Les paquets portables Windows et Mac annoncés font moins de 40 Mo, ce qui laisse penser que les dépendances lourdes ne sont pas embarquées.

Configuration par variables d'environnement

Trois variables sont obligatoires : DOCUTRANSLATE_API_KEY, DOCUTRANSLATE_BASE_URL et DOCUTRANSLATE_MODEL_ID. Les autres ont des valeurs par défaut : DOCUTRANSLATE_TO_LANG vaut Chinese si rien n'est précisé, DOCUTRANSLATE_CONCURRENT vaut 10, DOCUTRANSLATE_CONVERT_ENGINE choisit le moteur de conversion PDF et DOCUTRANSLATE_MINERU_TOKEN fournit le jeton MinerU. Le README donne un exemple complet de configuration uvx, qui lance le serveur MCP sans installation préalable via uvx --from docutranslate[mcp] docutranslate --mcp. Deux points méritent attention. D'abord, la langue cible par défaut étant le chinois, une configuration minimale produit une traduction vers le chinois sans que rien ne le signale. Ensuite, DOCUTRANSLATE_CONVERT_ENGINE et DOCUTRANSLATE_MINERU_TOKEN ne sont pas détaillés dans le tableau : la documentation ne précise ni les valeurs acceptées ni ce qui se passe si le moteur est mal renseigné. C'est le principal trou de la documentation d'installation.

Le PDF, angle mort assumé du projet

La décision de convertir le PDF en markdown avant traduction est un choix de conception, pas un accident, et elle a un coût clair. Un article à deux colonnes, une thèse avec des notes de bas de page, un contrat à mise en page réglementaire : tous ressortiront avec une structure différente de l'original. La reconnaissance des tableaux, formules et code par mineru améliore le contenu extrait, pas la géométrie de la page. Si votre besoin est de produire un PDF traduit visuellement superposable à la source, cet outil n'est pas le bon, et aucune option listée dans le README ne promet le contraire. Deuxième limite, moins visible : le projet s'appuie entièrement sur un service de modèle de langage externe. La qualité de la traduction, la vitesse et la facture dépendent du fournisseur choisi. Le README mentionne un support large de plateformes, sans garantie de comportement identique entre elles, notamment sur le respect du format de sortie attendu par le réassemblage.

Face à un pipeline de traduction maison

L'alternative la plus directe n'est pas un autre outil de traduction de documents, c'est un script personnel : extraire le texte, appeler l'API, réinjecter. Beaucoup d'équipes en ont déjà un. La différence tient à ce que DocuTranslate prend en charge et qu'un script laisse à l'auteur : la préservation du format docx et xlsx, la sélection des valeurs JSON par chemin jsonpath-ng, la génération de glossaire, la concurrence asynchrone, une interface web et une API REST, plus un serveur MCP utilisable depuis un client compatible. Un script maison reste préférable si vos formats sont peu nombreux et simples, ou si vous voulez contrôler chaque octet du résultat. L'avantage réel de DocuTranslate est le travail d'ingénierie déjà fait sur les conteneurs de fichiers, pas la qualité de traduction en elle-même, qui reste celle du modèle que vous branchez.

Coût de maintenance et portée de la licence MPL-2.0

Le rythme des versions est un indicateur utile : v1.7.7 en juin 2026, v1.7.8 en juillet, v1.7.9 en septembre de la même année. Un projet qui publie à ce rythme demande de suivre les changements avant chaque mise à jour, surtout si vous dépendez du serveur MCP, dont le README renvoie à un document séparé dans docutranslate/mcp/README.md. La licence MPL-2.0 est une licence à réciprocité par fichier : les fichiers du projet que vous modifiez et redistribuez doivent rester sous MPL-2.0, mais elle n'impose rien sur le reste de votre application. Une intégration en service interne, sans redistribution, ne déclenche pas d'obligation de publication. Ce n'est pas un avis juridique : faites relire votre cas si vous redistribuez des binaires ou des paquets modifiés.

Conclusion éditoriale

DocuTranslate convient à qui doit traduire des lots de documents structurés (docx, xlsx, epub, srt, json) avec sa propre clé d'API et accepte de faire tourner un service local. Il ne convient pas à qui attend une restitution fidèle de la mise en page PDF : le README indique explicitement que le passage en markdown la perd. Avant d'adopter, vérifiez deux points dans le dépôt : le contenu de docutranslate/mcp/README.md pour le mode serveur, et la valeur par défaut de DOCUTRANSLATE_CONVERT_ENGINE, car c'est elle qui décide si le parsing PDF passe par MinerU en ligne ou par une instance locale.

Sources officielles

1. Issues
2. License: MPL-2.0
3. README
4. Releases
5. xunbu/docutranslate on GitHub