Comment travailler avec des traducteurs freelances

La plupart des problèmes imputés à la qualité du traducteur sont en réalité des problèmes d’organisation. Un professionnel compétent, à qui l’on donne une simple liste de chaînes, aucun contexte et aucun moyen de poser des questions, produira un travail médiocre — et vous en conclurez que vous avez fait le mauvais recrutement.

Cette page traite des aspects qui sont sous votre contrôle.

Freelances ou agence#

Les deux fonctionnent. Le compromis se joue entre coordination et continuité.

Un freelance avec qui vous travaillez directement apprend votre produit. Après six mois, il connaît votre terminologie, votre ton et les chaînes qui présentent un risque. Il pose de meilleures questions. Il coûte moins cher au mot. Vous gérez la recherche, la contractualisation, le briefing, la planification et les relances — multipliés par chaque langue.

Une agence absorbe tout cela, garantit la disponibilité, et gère les langues que vous n’avez aucun moyen de sourcer vous-même. Elle coûte plus cher, et fait généralement tourner les traducteurs, si bien que la connaissance du produit s’accumule dans son processus plutôt que dans une personne — quand elle s’accumule.

Une répartition courante et sensée : des freelances pour vos deux ou trois marchés principaux, là où la qualité compte le plus, une agence pour la longue traîne.

Ce qu’il faut vérifier dans les deux cas, c’est la continuité. Demandez directement à une agence si vous obtenez les mêmes traducteurs dans le temps. Cela change considérablement la valeur du service.

Les trouver#

Le signal que vous recherchez, c’est quelqu’un qui traduit du logiciel, pas quelqu’un qui traduit. Ce sont des compétences différentes — la traduction de logiciel implique de travailler avec des placeholders, des limites de caractères, des fragments sans phrases autour d’eux, et une tolérance à l’ambiguïté que la traduction de documents n’exige pas.

Posez aux candidats les questions suivantes :

• Dans quels outils de localisation avez-vous travaillé ? Une bonne connaissance d’un TMS, quel qu’il soit, signifie que le workflow ne sera pas l’obstacle.
• Que faites-vous quand une chaîne est ambiguë ? La réponse que vous voulez entendre, c’est « je demande ». Une réponse décrivant comment ils déduisent le sens à partir du nom de la clé est un signal d’alerte.
• Avez-vous déjà travaillé avec des placeholders et des formes plurielles ? Si la question nécessite une explication, ils apprendront sur votre produit.

Payez pour un petit test rémunéré, sur de vraies chaînes de votre produit, incluant quelques-unes délibérément ambiguës. Ce que vous recherchez n’est pas seulement la qualité de la traduction — c’est s’ils ont signalé les chaînes ambiguës. Ce seul comportement prédit la majeure partie de la valeur que vous obtiendrez.

Le briefing#

Le brief est ce qui déterminera l’essentiel du résultat, et ce n’est généralement qu’un paragraphe dans un e-mail.

Un brief utile couvre :

• Ce que fait le produit, en quelques phrases. Étonnamment souvent omis.
• Qui sont les utilisateurs. Particuliers ou professionnels ; le registre en découle.
• Le ton et la formalité. Adresse formelle ou informelle, décidée une fois pour toutes. Chaque langue avec une distinction T-V a besoin de cette réponse.
• La base terminologique, y compris les termes qui ne doivent jamais être traduits.
• Que faire en cas de blocage — où poser la question, et la garantie que poser une question est bienvenu plutôt que perçu comme une nuisance.
• Les contraintes — limites de caractères, règles de placeholders, et le fait que le balisage doit survivre.

Donnez-leur ensuite accès au produit. Un traducteur qui a utilisé la chose qu’il traduit produit un travail nettement meilleur, et un compte gratuit ne vous coûte rien.

Accès et permissions#

Accordez le rôle le plus restrictif qui leur permette de travailler sans avoir à vous attendre. Bloquer un traducteur sur une permission est un coût lent et silencieux.

Les rôles de WebTranslateIt correspondent directement à cela :

Le schéma qui fonctionne pour une équipe de freelances est un Language Coordinator par langue, avec des Translators sous sa responsabilité si le volume nécessite plus d’une personne. Le coordinateur devient la personne responsable de la qualité de cette langue, ce qui est exactement ce que vous voulez, et que vous ne pouvez pas obtenir en supervisant une langue que vous ne lisez pas.

Pour une équipe permanente répartie sur plusieurs projets, regroupez les personnes en une team, et assignez cette team aux projets, plutôt que d’ajouter des individus à chaque projet. Cela réduit l’arrivée et le départ d’une personne à une seule action, ce qui compte plus qu’il n’y paraît quand quelqu’un s’en va.

Rémunérer#

Structure tarifaire. Le tarif au mot source est la norme pour le volume. Le tarif horaire convient à la review, à la relecture et aux petits travaux ponctuels. La tarification à la chaîne existe et a tendance à pénaliser les chaînes courtes, qui constituent la majeure partie d’une UI.

Remises liées à la mémoire de traduction. La pratique standard est un barème dégressif — tarif plein pour le texte nouveau, réduit pour les correspondances approximatives, symbolique ou nul pour les correspondances exactes. Convenez-en par écrit avant la première facture. Presque tous les litiges à ce sujet viennent du fait que la question n’a jamais été soulevée.

Minimums de facturation. Un traducteur à qui l’on demande de traiter onze nouvelles chaînes un mardi passe plus de temps à changer de contexte qu’à traduire. Un minimum raisonnable par lot, ou un regroupement hebdomadaire du travail, évite que cela ne devienne une irritation récurrente.

Payez rapidement. Les freelances se parlent entre eux, et la fiabilité est un véritable avantage concurrentiel sur un marché où elle n’est pas la norme.

Juger la qualité sans parler la langue#

Vous ne pouvez pas l’évaluer directement. Vous pouvez construire un processus qui fait remonter les problèmes :

Une relecture séparée pour les premiers lots. Un second traducteur qui relit les premiers milliers de mots vous en apprend beaucoup — sur la traduction, et sur la pertinence de votre brief. Réduisez la fréquence une fois que c’est constamment propre.

La validation mécanique. La QA de localisation détecte les placeholders, les catégories de pluriel et la longueur. Ce sont les erreurs qui cassent le produit, et ce ne sont pas des questions d’appréciation.

Observez les questions. Un traducteur qui ne pose aucune question est en train de deviner. Un traducteur qui pose deux ou trois bonnes questions par lot fait le travail correctement. C’est le signal le plus fiable dont dispose un manager qui ne lit pas la langue.

Demandez à un utilisateur ou un collègue natif de passer vingt minutes dans l’application. Pas une revue formelle — juste « est-ce que ça se lit comme un produit ou comme une traduction ? ». Cela détecte des problèmes de ton qu’aucune checklist ne trouve.

Suivez les reprises. Un volume de corrections en hausse est un signal. La question à se poser ensuite est de savoir s’il pointe vers le traducteur, vers votre texte source, ou vers un changement de terminologie.

Les garder#

Les bons traducteurs de logiciels sont rares, et le coût de remplacer l’un d’eux est plus élevé qu’il n’y paraît — la connaissance du produit s’en va avec lui.

Répondez vite aux questions ; un traducteur bloqué est inactif et payé. Donnez un flux de travail régulier plutôt que des pics imprévisibles. Envoyez du feedback dans les deux sens, y compris quand quelque chose a été bien fait. Dites-leur ce qui a changé dans le produit avant qu’ils ne le découvrent dans les chaînes. Et quand un relecteur écrase leur choix, expliquez pourquoi — les corrections silencieuses sont la façon dont on perd quelqu’un de compétent.

Passer à plusieurs traducteurs par langue#

À un moment donné, une langue a besoin de deux personnes, et le problème de coordination change de nature.

Le réflexe est de découper par fichier. C’est le mauvais découpage — la même terminologie apparaît dans plusieurs fichiers, et deux personnes travaillant sur des fichiers différents divergent sans jamais voir le travail de l’autre.

De meilleurs découpages, à peu près dans l’ordre de préférence :

Par domaine fonctionnel, avec une base terminologique partagée. Deux traducteurs travaillant sur des parties différentes du produit puisent toujours dans un seul vocabulaire, et la mémoire de traduction fait automatiquement remonter les décisions de l’un à l’autre.

Traducteur plus relecteur. L’un écrit, l’autre relit. Plus lent au mot et nettement plus cohérent, ce qui est le bon compromis pour une surface petite et très visible.

Par type de contenu. Les chaînes d’interface à la personne qui connaît le produit ; la documentation et l’aide à qui est disponible. Les compétences sont réellement différentes.

Quel que soit le découpage utilisé, gardez un seul Language Coordinator responsable de la langue dans son ensemble. Deux pairs avec une autorité égale et aucun arbitre produisent deux styles, et l’incohérence vous est invisible.

Les erreurs les plus courantes#

• Aucun contexte. Les captures d’écran et les commentaires de développeur sont la solution, et leur absence est le plus grand levier de qualité que la plupart des équipes n’ont pas encore actionné.
• Aucune base terminologique, si bien que la terminologie dérive et que personne ne peut dire quel était le bon mot.
• Des lots trop serrés. Onze chaînes un mardi, seize un jeudi.
• Aucun responsable désigné par langue. La qualité doit être le travail de quelqu’un.
• Traiter les questions comme une friction. Elles sont le signe que le mécanisme fonctionne correctement.
• Envoyer des tableurs. Dérive de versions, pas de mémoire, pas de validation, pas d’historique.