Traduction automatique vs traduction humaine

Le débat est généralement posé comme une question de qualité, ce qui explique pourquoi il ne se résout jamais. Le cadrage productif est par type de contenu : certaines chaînes ne devraient jamais être traduites par une machine, d’autres ne devraient jamais être traduites par un humain parce que personne ne les lira jamais, et l’essentiel du volume se situe entre les deux, là où la bonne réponse est la traduction automatique avec relecture humaine.

Ce que chacune fait vraiment bien#

La traduction automatique est rapide, pratiquement gratuite à la marge, disponible instantanément dans une centaine de langues, et parfaitement cohérente — elle fera la même erreur à chaque fois, ce qui la rend au moins repérable. Elle gère bien la prose longue avec un contexte interne.

La traduction humaine comprend le contexte, le registre et l’intention. Elle sait que le « workspace » de votre produit est un nom précis et non la description d’un bureau. Elle peut décider qu’une traduction littérale d’un titre marketing est techniquement correcte et commercialement inutile. Elle pose des questions quand une chaîne est ambiguë — ce qui vaut plus que ça n’en a l’air, car cette question révèle généralement un problème de copy source qui affecte chaque langue.

Où la traduction automatique échoue, spécifiquement dans le logiciel#

La critique générique de la TA parle de nuance et d’idiome. Dans la localisation logicielle, les échecs sont plus précis et plus mécaniques.

Les chaînes courtes n’ont pas de contexte. C’est le problème majeur. Open, Close, Save, Back, Share — un modèle voit un seul mot et doit deviner s’il s’agit d’un verbe sur un bouton ou d’un adjectif décrivant un état. Dans la plupart des langues cibles, ce sont des mots différents, et il en choisira un au hasard. Les chaînes d’interface sont majoritairement courtes.

Les placeholders sont massacrés. %{count} devient %{compte}, {{name}} se voit ajouter des espaces, %1$s perd son index. Voir la fiche des formats de placeholder pour les syntaxes à risque.

La structure plurielle n’est pas préservée. Un moteur traditionnel traduit une chaîne, pas un ensemble de formes. Donnez-lui l’anglais one/other et vous obtenez deux chaînes traduites, ce qui est faux pour le polonais et franchement faux pour l’arabe.

La terminologie dérive. Rien ne contraint le modèle à respecter votre glossaire, si bien que le nom central de votre produit se retrouve traduit de trois façons différentes sur un seul écran.

Le genre et la formalité sont devinés. Les langues avec une adresse formelle et informelle imposent un choix à chaque phrase. Un modèle sans instruction choisit de façon incohérente, et l’interface se lit comme si elle avait été écrite par plusieurs personnes qui ne se seraient jamais rencontrées.

Où elle fonctionne bien#

Il est important d’être honnête sur ce point, car un refus systématique fait perdre de l’argent réel :

• Le contenu long — documentation, articles de centre d’aide, notes de version. Assez de contexte environnant pour que le modèle désambiguïse, et faible coût d’une phrase légèrement maladroite.
• Le contenu à fort volume et à faible valeur — contenu généré par les utilisateurs, catalogues produits avec des milliers de descriptions quasi identiques, matériel archivé.
• Les langues que vous ne prendriez sinon pas en charge du tout. Un vietnamien imparfait vaut mieux qu’aucun vietnamien pour un utilisateur qui reçoit actuellement de l’anglais.
• Les premiers jets destinés à la post-édition. L’usage pratique le plus important. Un humain qui édite une sortie machine correcte est nettement plus rapide qu’un humain qui traduit à partir de rien.
• Le texte à usage interne qui doit être compris plutôt que soigné.

Un tableau de décision#

Le principe : inversement proportionnel à la brièveté et à la visibilité de la chaîne. Un bouton de quatre mots vu par chaque utilisateur à chaque session mérite un humain. Un article d’assistance de 2 000 mots vu par 40 personnes par mois n’en a pas besoin.

Les modèles d’IA ont changé le calcul, d’une façon précise#

Les nouveaux moteurs basés sur l’IA ne sont pas nettement plus fluides que la bonne TA neuronale pour les paires de langues courantes. Là où ils diffèrent, spécifiquement pour le logiciel, c’est qu’on peut leur indiquer la structure et leur donner des instructions sur l’intention.

Concrètement, les intégrations Gemini et Mistral de WebTranslateIt :

• Traduisent toutes les formes plurielles à la fois et étendent l’ensemble selon les règles CLDR de la langue cible — l’anglais one/other devient le polonais one/few/many/other.
• Comprennent ICU MessageFormat, ne traduisant que le texte lisible par un humain tout en laissant intacts les noms de variables, les mots-clés et la structure des accolades.
• Lisent les commentaires de développeur attachés au segment, ce qui est le mécanisme permettant de résoudre le problème du Open-en-tant-que-verbe — si le commentaire dit « libellé de bouton », le modèle dispose de ce dont un humain aurait aussi eu besoin.
• Utilisent votre base terminologique, si bien que les termes du glossaire ressortent de façon cohérente.
• Acceptent des instructions au niveau du projet et de la locale fixant le ton, le registre et la formalité une fois pour toutes plutôt que chaîne par chaîne.

Cette liste est la vraie différence. Elle fait passer la TA de « génère un texte plausible qui casse le build » à « génère un texte structurellement valide qu’il faut relire pour le sens » — ce qui est un bien meilleur point de départ pour un humain.

La mémoire de traduction se situe au-dessus des deux#

Il vaut la peine de le dire clairement, car c’est souvent absent de la comparaison : la mémoire de traduction bat les deux quand elle trouve une correspondance. Une correspondance à 100 % est une traduction qu’un humain a déjà écrite et approuvée pour votre produit. Elle est plus fiable que la TA et gratuite comparée à une nouvelle traduction humaine.

Le classement raisonnable pour n’importe quel segment :

1. Correspondance exacte issue de votre propre mémoire — réutilisez-la.
2. Correspondance floue — modifiez-la.
3. Traduction automatique — post-éditez-la, si le type de contenu le justifie.
4. Humaine à partir de zéro — pour tout ce qui se situe au-dessus de la ligne dans le tableau.

La plupart des plateformes, WebTranslateIt compris, présentent les suggestions à peu près dans cet ordre, précisément pour cette raison.

Ce que la post-édition signifie vraiment#

L’entre-deux a un nom et deux niveaux reconnus, et se mettre d’accord sur celui qu’on demande évite bien des déceptions.

La post-édition légère ne corrige que ce qui affecte le sens : contresens, omissions, placeholders massacrés, terminologie erronée. Les formulations maladroites sont laissées de côté. Le résultat est exact et se lit comme si une machine l’avait écrit. Adapté à la documentation et au contenu d’aide où le lecteur veut la réponse plutôt que la prose.

La post-édition complète amène le texte au niveau qu’un traducteur humain aurait produit — exact, naturel, cohérent en registre. Plus lente, et pour la plupart des types de contenu, le coût s’approche de celui d’une traduction à partir de zéro, ce qui est précisément pourquoi la décision par type de contenu compte plus que la qualité de la TA.

L’erreur consiste à demander de la « post-édition » sans préciser laquelle, puis à être surpris soit par la facture, soit par la qualité.

Conseils pratiques#

Décidez par type de contenu, à l’avance, et écrivez-le noir sur blanc. La décision est une question de politique, pas un jugement chaîne par chaîne, et la prendre une fois pour toutes évite qu’elle soit rediscutée à chaque sprint.

Ne livrez jamais de TA brute pour les chaînes d’interface. Si le budget ne permet pas la traduction humaine de votre interface, traduisez moins de langues correctement plutôt que plus de langues mal.

Donnez à la machine ce que vous donneriez à un humain. Commentaires de développeur, captures d’écran, base terminologique, instructions de ton. Les modèles sont limités par le contexte, et la plupart des équipes n’en fournissent aucun.

Mesurez l’effort de post-édition, pas la qualité de la TA. La part de la sortie qui survit à la relecture est le chiffre qui reflète le coût. Les scores de qualité automatisés ne le font pas.

Surveillez l’erreur qui s’accumule. Une sortie machine approuvée entre dans votre mémoire de traduction, et est ensuite proposée pour toujours comme une « traduction humaine antérieure ». Gardez le contenu post-édité et la TA brute distinguables, et ne laissez pas de sortie non relue entrer dans la mémoire.