Subtitle Translator : traduire une saison entière sans que le modèle touche aux timecodes

Le problème : le modèle réécrit ce qu'il ne devrait pas voir

Coller un fichier de sous-titres dans un traducteur généraliste produit deux dégâts prévisibles. Le premier est que le modèle reçoit les timecodes en même temps que le texte et les reformate à sa façon. Le second est qu'on traduit un fichier à la fois. Subtitle Translator attaque les deux frontalement. Le README résume la méthode en une phrase : le timing est retiré localement et seul le dialogue part vers le moteur, ce qui rend le calendrier physiquement intouchable. Le public visé est donc celui qui manipule des lots : une saison complète, une série de conférences, un corpus de clips sous-titrés. Pas l'utilisateur qui traduit un fichier isolé de temps en temps, pour qui un éditeur classique suffit.

Ce qui part réellement vers le moteur

L'architecture repose sur une séparation structurelle documentée : les timecodes, les numéros de cue, les en-têtes ASS et les identifiants de cue VTT sont extraits localement. Seul le texte de dialogue est transmis. Autrement dit, le modèle travaille sur une liste de lignes, pas sur le fichier. Cette contrainte explique aussi la limite de la fonction de contexte : en mode LLM, l'outil envoie les lignes environnantes avec chaque lot, avec une valeur par défaut de 20 lignes traduites en parallèle et 50 lignes de contexte par lot. Ces deux réglages sont exposés et le README prévient qu'un parallélisme trop élevé déclenche des limites de débit, et qu'un contexte plus large consomme plus de jetons. Le compromis est donc explicite plutôt que caché. Le cache, lui, vit dans IndexedDB : rafraîchir la page ne fait pas perdre les fichiers déjà traduits.

Formats, conversion et blocs ignorés

La détection automatique couvre .srt, .ass, .vtt et .lrc. Un point mérite l'attention : les blocs WebVTT NOTE, STYLE et REGION sont explicitement ignorés, donc non traduits comme du dialogue. C'est le genre de détail qui distingue un parseur écrit pour de vrais fichiers d'un parseur écrit pour la démo. La conversion de format est proposée pendant la traduction (SRT vers VTT, SRT/VTT vers ASS). Pour les sorties bilingues depuis une source SRT ou VTT, l'export ASS utilise deux styles distincts, décrits dans le README comme Default 70pt blanc et Secondary 55pt cyan, modifiables ensuite dans n'importe quel éditeur de sous-titres. La traduction vers plusieurs langues cibles en une seule passe produit un fichier par langue, avec le code de langue ajouté au nom, par exemple movie.zh.srt et movie.fr.srt.

Mise en route : interface web ou ligne de commande

Le chemin le plus court est l'interface hébergée sur tools.newzone.top. Aucune configuration n'est nécessaire pour démarrer : GTX et Edge sont présentés comme les valeurs par défaut sans configuration, chacun servant de repli à l'autre. Pour les autres moteurs, il faut ouvrir les paramètres d'API et renseigner une clé. Si vous préférez scripter, la CLI s'utilise avec yarn cli et, d'après le README, elle partage le même moteur, les mêmes parseurs et le même cache que l'application web. Un point d'infrastructure compte : certains fournisseurs sont bloqués par CORS depuis un navigateur. L'outil embarque un relais fonctionnel par défaut, et le README indique que API Settings puis Relay address permet de pointer tous les fournisseurs relayés vers votre propre déploiement du Worker de relais. C'est le seul élément qui demande une vraie décision d'exploitation.

La promesse d'une seconde par épisode

Le README annonce environ une seconde par épisode grâce à la compression par blocs et au traitement parallèle, avec une note indiquant que GTX est légèrement plus lent. C'est une affirmation de la documentation, pas une mesure que j'ai reproduite. Elle dépend entièrement du fournisseur choisi, de la latence réseau, de la taille des lots et du débit autorisé par votre clé. Le chiffre ne doit pas servir de critère d'adoption à lui seul. Le mécanisme sous-jacent (découpage en blocs, envoi parallèle, cache local) est cohérent avec cette promesse, mais la variance entre un compte gratuit limité en débit et une clé payante est trop grande pour qu'un chiffre unique soit utile.

Les limites que la documentation admet

La plus nette concerne le mode contexte : le README prévient que les modèles de moins de 70 milliards de paramètres peuvent produire une sortie désalignée, et recommande les grands modèles en ligne (Claude, GPT, DeepSeek, Gemini) pour ce mode. Cela signifie que la fonction la plus intéressante du produit, la cohérence du dialogue et des voix de personnages, dépend d'un accès à des modèles coûteux. Autre limite : les fournisseurs gratuits GTX et Edge sont décrits comme limités en débit, et DeepLX comme auto-hébergeable ou dépendant de points d'accès publics. Enfin, l'absence de serveur est un choix, pas un détail : vos clés restent dans le navigateur, ce qui est un avantage de confidentialité, mais aussi une contrainte, puisque toute traduction dépend d'un appel direct depuis le navigateur ou via votre relais. Si votre organisation interdit les appels sortants depuis un poste client, l'outil n'est pas le bon choix sans le relais auto-hébergé.

Face à un script maison appelant une API de traduction

L'alternative évidente pour un lot de sous-titres est un script personnel qui lit le fichier, en extrait le texte et appelle une API. La différence n'est pas le moteur : c'est la couche de format. Un script maison doit gérer lui-même les numéros de cue, les en-têtes ASS, les blocs NOTE et STYLE du WebVTT, la réinsertion du timing, la sortie bilingue et le cache. Subtitle Translator fournit cette couche et la partage entre l'interface web et la CLI. L'inverse est aussi vrai : si vous avez besoin d'un traitement que les parseurs ne couvrent pas, par exemple une transformation du texte avant traduction, le script maison reste plus direct, car vous ne dépendez pas des options exposées par l'outil.

Coût de maintenance et licence

Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation et la modification, y compris en contexte commercial, à condition de conserver la notice de licence. Ce n'est pas un avis juridique : faites relire la notice par qui de droit si vous redistribuez. Le rythme de publication est soutenu, avec v3.2.0 le 9 septembre 2026, v3.1.1 le 1er septembre 2026 et v3.1.0 le 23 août 2026, sur un projet TypeScript non archivé. Une cadence aussi rapprochée signifie que les détails d'interface et les valeurs par défaut peuvent bouger entre deux versions, et qu'un déploiement épinglé à une version précise est plus sûr qu'un déploiement qui suit la branche main. Le coût réel d'exploitation se situe ailleurs : dans les jetons consommés par le mode contexte et dans la maintenance du relais si vous l'auto-hébergez.

Conclusion éditoriale

Subtitle Translator convient à qui traduit des volumes importants de sous-titres et veut garder la main sur ses clés API, à condition d'accepter un outil 100 % navigateur ou une CLI. Il ne convient pas si vous exigez une garantie contractuelle de qualité ou si vous ne pouvez pas faire tourner un relais pour les fournisseurs bloqués par CORS. Avant d'adopter, vérifiez deux points précis : le comportement de l'extraction locale sur vos fichiers .ass les plus exotiques, et la qualité de sortie de votre modèle en mode contexte, car la documentation signale elle-même que les modèles de moins de 70 milliards de paramètres peuvent produire un alignement décalé.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. rockbenben/subtitle-translator on GitHub