Translation QA : ce qui casse vraiment dans les traductions, et comment le détecter automatiquement

La Translation QA (assurance qualité des traductions) est la pratique consistant à vérifier les contenus traduits avant qu'ils n'atteignent les utilisateurs. Elle comporte deux couches : la couche mécanique, tout ce qui peut être comparé objectivement entre un texte source et sa traduction (placeholders, balises HTML, nombres, ponctuation, espaces, cohérence terminologique), et la couche de jugement, savoir si la traduction dit vraiment la bonne chose sur le bon ton. La première couche peut être automatisée complètement. La seconde non, et faire comme si, c'est ainsi que des versions cassées partent en production.

Ce billet traite de la première couche : ce qui casse vraiment dans les données réelles de traduction, pourquoi la relecture manuelle continue de le manquer, et ce que les contrôles linguistiques automatiques peuvent y faire, et ne peuvent pas.

Ce qui casse vraiment dans les traductions

Demandez à quelqu'un à quoi ressemble une erreur de traduction et il décrira un contresens : une phrase qui dit la mauvaise chose. Regardez dans les données réelles de traduction de produits logiciels et vous trouverez quelque chose de moins glamour. Les défauts qui atteignent la production sont très majoritairement structurels, et ils se regroupent en une petite taxonomie.

Placeholders et balisage

La classe la plus dommageable. Un placeholder d'interpolation comme {{count}} qu'un traducteur (ou une machine) a renommé, traduit ou perdu ne s'affiche pas comme un texte légèrement faux : il s'affiche littéralement comme {{Anzahl}} à l'écran, ou fait planter le formateur. Même chose pour les balises HTML et de composants : les marqueurs <0>…</0> de react-i18next, un <strong> qui a perdu sa balise fermante, un lien disparu dans une langue. Une balise cassée s'affiche généralement comme du texte brut, précisément pour les utilisateurs qui lisent cette langue, et pour personne au bureau.

Nombres

Un nombre présent dans la source et absent de la traduction (« 30 jours » traduit par « jours ») change le sens silencieusement. La subtilité : les nombres changent légitimement de forme selon les locales. Formats de chiffres locaux, chiffres arabes orientaux et pleine chasse, conversions 12h/24h (« 9pm » devient « 21 Uhr ») sont tous corrects. Un contrôle utile doit les traiter comme égaux et signaler quand même la quantité réellement manquante.

Ponctuation, casse, parenthèses

Un deux-points final perdu casse un libellé que l'interface concatène avec une valeur. Un point d'interrogation disparu transforme une demande de confirmation en affirmation. L'espagnol attend le ¿ inversé quand la phrase se termine par un point d'interrogation. Les parenthèses forment leur propre catégorie : une traduction dont le nombre de () diffère de la source, ou une parenthèse non fermée que la source n'a pas, est le plus souvent une valeur tronquée ou à moitié éditée. Et la casse de la première lettre diffère légitimement entre langues (l'allemand met les noms en majuscule ; les fragments de titres varient selon la langue) : une comparaison naïve produit du bruit au lieu de constats.

Espaces

Invisibles et donc populaires : des espaces doublées à l'intérieur d'une valeur, ou des espaces de début et de fin qui diffèrent de la source. Les espaces finales comptent dès que votre application concatène des fragments traduits. La typographie française ajoute sa nuance : une espace insécable avant la ponctuation est du français correct et ne doit pas être comptée comme un doublon.

Répétitions

« Le le » arrive dans toutes les langues, généralement comme reste d'une édition. Le piège : certains redoublements sont grammaticalement corrects, comme les constructions réflexives françaises (« nous nous retrouvons ») ou des suites d'articles en allemand. Un contrôle qui l'ignore inonde les relecteurs de faux positifs jusqu'à ce qu'ils le désactivent.

Terminologie incohérente

Le défaut le plus silencieux, et dans nos données le plus répandu : la même valeur source traduite différemment selon les clés. Un bouton « Save » dit « Speichern », un autre « Sparen ». Un terme est rarement mal traduit partout, mais il l'est souvent quelque part, et c'est dans ces désaccords que se cachent les contresens. Ce n'est pas un contrôle par valeur ; il lui faut le corpus entier d'une langue.

Balisage dangereux

Le prolongement sécurité du même problème : les valeurs de traduction sont du contenu que votre application rend. Une valeur contenant <script>, un gestionnaire onclick= ou une URL javascript: n'est pas un problème de qualité, c'est un vecteur d'injection, car les comptes de traducteurs et les clés API en écriture font partie de votre surface d'attaque, que vous les voyiez ainsi ou non.

À quel point est-ce fréquent ?

Mesuré sur les projets Locize en août 2026 : environ 2,3% des segments traduits déclenchent au moins un des contrôles mécaniques ci-dessus, avec en tête les espaces, la ponctuation finale et les écarts de nombres. La cohérence entre clés va plus loin encore : environ 3,9% des segments ont au moins une clé sœur traduisant différemment la même valeur source, et 87% des projets échantillonnés contiennent au moins un tel désaccord.

Un segment sur quarante paraît peu, jusqu'à ce qu'on le multiplie par un produit de vingt mille segments en huit langues. Et cela se concentre exactement dans le contenu modifié récemment, celui que votre prochaine version livre.

Comment les équipes font de la Translation QA aujourd'hui

La plupart des équipes qui prennent la qualité de traduction au sérieux combinent plusieurs de ces approches :

• Une passe de relecture humaine par langue, par un second traducteur, un collègue du marché cible ou une session LQA d'agence. C'est le bon outil pour le sens et le ton, et le mauvais pour les placeholders : les humains survolent le détail mécanique, et un relecteur qui vérifie le nombre de parenthèses sur 4 000 chaînes cesse d'être un linguiste pour devenir une regex très coûteuse.
• Des sondages dans des tableurs : exporter, filtrer, jeter un œil. Cela attrape ce qu'on regarde par hasard, le jour où on le regarde.
• Des scripts maison en CI : un dépôt de regex écrites un après-midi, qui attrape les interpolations manquantes dans un format de fichier, dans les langues auxquelles l'auteur a pensé. Utile, non maintenu, et aveugle à tout ce qui traverse les clés (la cohérence) et à tout ce qui est propre à une langue (le ¿, l'espace insécable, la majuscule des noms allemands).
• Guides de style et glossaires en documents : la terminologie correcte vit dans un PDF que les relecteurs sont censés mémoriser pendant que le corpus réel dérive.

Le motif commun aux quatre : la couche mécanique est contrôlée occasionnellement et partiellement, par des personnes ou des scripts conçus pour autre chose. Les défauts, eux, entrent en continu, avec chaque nouvelle clé, chaque lot traduit par machine et chaque correction rapide tapée directement dans un fichier.

Ce que changent les contrôles linguistiques automatiques

Un contrôle automatique exécute la comparaison pour laquelle un relecteur n'a jamais été bon, sur chaque valeur, dans chaque langue, à chaque modification. Les exigences qui séparent une implémentation utile d'un générateur de bruit :

1. Conscience de la locale. Chaque contrôle ci-dessus a des exceptions légitimes par langue. Un vérificateur qui signale la majuscule des noms allemands comme erreur de casse, ou les espaces insécables françaises comme doublons, apprend aux relecteurs à l'ignorer en une semaine.
2. Portée corpus. Les défauts de cohérence sont invisibles au niveau d'une valeur isolée. Le contrôle doit comparer à travers toutes les clés d'une langue.
3. Continu par défaut. Une passe de QA qu'il faut penser à lancer est un tableur avec une meilleure interface. Les contrôles appartiennent au chemin d'enregistrement et à l'éditeur, avec les constats attachés à la clé, pas dans un rapport que personne ne rouvre.
4. Une échappatoire par constat. Parfois la différence est voulue : le même mot source a vraiment besoin de deux traductions dans deux contextes. Si ignorer un constat n'est pas une action ciblée en un clic, les équipes désactivent le contrôle entier à la place.
5. Une frontière nette avec le jugement humain. Les contrôles répondent à « est-ce structurellement cohérent avec la source et le corpus ? ». Ils ne répondent pas à « est-ce une bonne traduction ? ». Cela reste du travail de relecture, appuyé par les glossaires et les guides de style, et pour les traductions générées par machine par la Quality Estimation, qui note ce que les contrôles ne peuvent pas comparer.

Comment cela fonctionne dans Locize

Locize intègre cette couche nativement, active par défaut, sans configuration :

• Dix contrôles linguistiques sensibles à la locale comparent chaque traduction à sa source : ponctuation finale, casse de la première lettre, nombres, nombre de parenthèses, parenthèses non équilibrées, espaces, mots répétés, caractères spéciaux, nombre d'URL, et balises HTML ou de composants, chacun avec les exceptions par langue décrites plus haut.
• Les contrôles de cohérence travaillent à l'échelle du corpus : ils trouvent la même valeur source traduite différemment selon les clés (les clés en désaccord sont listées à côté du constat), les valeurs source dupliquées, les violations de glossaire et les incohérences de syntaxe i18n.
• La détection de balisage dangereux signale les contenus exécutant du script dans les valeurs et en bloque l'enregistrement par défaut, dans l'éditeur comme via l'API, pour qu'un compte de traducteur compromis ne puisse pas injecter <script> dans votre application via une traduction.
• Les constats apparaissent directement dans l'éditeur sur la clé, s'agrègent dans les statistiques de traduction du projet, et chaque constat peut être ignoré par clé quand la différence est voulue. Vous pouvez aussi lancer tous les contrôles sur le projet entier en une action :

Lancer tous les contrôles d'un projet dans Locize

Le sens de ce réglage par défaut est le même que celui de ce billet : la couche mécanique n'est pas l'endroit où doit aller l'attention humaine. Laissez les contrôles tenir cette ligne, donnez aux relecteurs le glossaire, le guide de style et le workflow de relecture, et investissez les humains dans la partie que les machines ne peuvent pas juger.

Si vous voulez voir ce que les contrôles trouvent dans vos propres contenus : créez un projet, importez vos fichiers de traduction existants et lancez les contrôles. Les constats sont rarement ceux que vous attendiez.

Questions fréquentes

Qu'est-ce que la Translation QA ? La Translation QA (assurance qualité des traductions) est la pratique consistant à vérifier les contenus traduits avant leur mise en production. Elle couvre la couche mécanique (placeholders, balises, nombres, ponctuation, espaces, cohérence) et la couche de jugement (sens, ton, fluidité). La première s'automatise ; la seconde demande des humains, appuyés par glossaires, guides de style et workflows de relecture.

Quelles sont les erreurs les plus fréquentes dans les traductions ? Les défauts mécaniques dominent : placeholders d'interpolation et balises HTML modifiés ou perdus, nombres divergents de la source, ponctuation finale manquante, espaces endommagées autour de valeurs concaténées, mots répétés, et le même terme traduit de façon incohérente selon les clés.

La Translation QA peut-elle être automatisée ? La couche mécanique se vérifie de façon déterministe à chaque enregistrement, dans chaque langue. La couche de jugement non : la sortie de traduction automatique peut être notée par la Quality Estimation, la relecture humaine décide. Les dispositifs qui fonctionnent combinent les deux.

Quelle est la différence entre contrôles QA et Quality Estimation (QE) ? Les contrôles QA sont des comparaisons déterministes avec la source et le corpus ; ils trouvent des défauts structurels et se reproduisent toujours. La QE est un score de modèle prédisant la qualité d'une traduction sans référence. La QE priorise l'attention de relecture pour les nouvelles traductions machine ; les contrôles QA gardent le corpus entier en continu.

Les contrôles automatiques remplacent-ils la relecture humaine ? Non. Ils suppriment le bruit mécanique pour que le temps de relecture aille au sens, à la terminologie et au ton. Un relecteur libéré du comptage de parenthèses est un meilleur linguiste, pas un linguiste au chômage.