Le contrôle par rétrotraduction détecte-t-il les erreurs ? Nous l'avons mesuré.

Ce qu'est la vérification

Après avoir traduit chaque chaîne, KAERIS effectue trois vérifications, deux déterministes et une basée sur un modèle :

• Intégrité des placeholdersUne vérification au niveau regex pour s'assurer que chaque {name}, %s, %(count)s et pluriel ICU de la source a survécu à la traduction. C'est un fait, pas un jugement.
• Intégrité des balises et du balisageLa même vérification déterministe pour le balisage en ligne (<b>, <a>, <0> et les balises auto-fermantes), de sorte qu'une balise perdue ou réordonnée soit détectée avant son déploiement.
• Dérive du sens (le juge)Chaque traduction est retraduite en sens inverse dans votre langue, de manière indépendante, par un autre modèle ; un juge compare ensuite l'original à cette rétrotraduction et signale les vrais changements de sens : une négation inversée, un nombre faux, une action contraire.

La traduction et la retraduction passent par des modèles différents : aucun modèle ne vérifie son propre travail.

Comment nous l'avons testé

Test A : intégrité des placeholders et des balises (de bout en bout, modèle réel)

20 chaînes d'interface réalistes mêlant plusieurs styles de placeholders (%{name} de Rails, %(name)s de Python, %.2f/%02d de printf, {0} de .NET, <b> HTML, <0> i18next, pluriels ICU) ont été traduites dans quatre langues aux systèmes d'écriture différents (allemand, russe, japonais et arabe) par le modèle gratuit en production à l'époque (DeepSeek V3 ; toutes les offres, gratuite comprise, ont tourné sur GPT-4o-mini à partir du 1er août 2026 et tournent sur Gemini 2.5 Flash-Lite depuis le 5 août 2026, choisi en mesurant les candidats dans ce même pipeline). Cela fait 80 traductions. Nous avons ensuite exécuté la vérification déterministe sur la sortie réelle du modèle.

Résultat : le modèle a perdu un placeholder dans 3 traductions sur 80 (~4 %). La vérification a signalé les 3 : elle compte les placeholders, elle ne devine pas.

Test B : le juge de distorsion (vérité terrain connue)

Nous avons créé 28 rétro-traductions qui changent clairement le sens (négation perdue, mauvais nombre, action opposée, requis → optionnel, et similaires) et 40 rétro-traductions qui conservent le sens mais reformulent lourdement (le cas difficile pour les faux positifs). Le juge (Gemini 2.5 Flash, indépendant du modèle direct) les a vues sans étiquettes.

• Rappel : 28/28 (100 %)Chaque erreur de sens plantée a été signalée, avec une raison précise ("négation perdue", "mauvais nombre", "sens opposé").
• Taux de faux positifs : 0/40 (0 %)Pas une seule paraphrase correctement reformulée n'a été signalée.

Ce que le benchmark a également corrigé

Ce test a révélé un vrai bug dans notre propre pipeline : sur un gros lot, l'appel au juge pouvait dépasser son délai et, l'erreur étant ignorée sans bruit, ne renvoyer aucun signalement, ce qui sous-évaluait discrètement les gros fichiers. Nous découpons désormais les appels au juge en petits sous-lots avec une nouvelle tentative, si bien que la vérification reste fiable quelle que soit la taille du fichier. La correction a été déployée avec cette page.

Limites

Ce que ces chiffres ne couvrent pas :

• Ceci est un ensemble réduit et contrôlé (148 cas), pas un échantillon du trafic en direct.
• Les 28 distorsions sont des changements de sens clairs. La dérive subtile, comme un ton décalé ou un modal atténué, est plus difficile, et 100 % ici ne signifie pas 100 % sur tout.
• Nous avons écrit les cas de test, donc la vérité terrain est connue. C'est un test équitable du juge, pas une étude sur le terrain de la qualité de la traduction.
• Un modèle direct (DeepSeek V3, le modèle gratuit à l'époque) et un modèle juge (Gemini 2.5 Flash) ; l'ensemble de distorsion est centré sur l'anglais.

Ce que la vérification vous donne : chaque signalement est un fait vérifiable (un placeholder perdu, une négation inversée), pas un score de confiance. Un meilleur modèle de traduction donne moins de signalements, pas une vérification plus faible.