Un éditeur de plugin WordPress nous a confié la traduction de sa documentation technique, environ 150 pages, de l’anglais vers le français, en s’appuyant sur l’API GPT-4 pour accélérer un travail jusque-là entièrement manuel. Le texte source contenait un vocabulaire précis, propre à l’écosystème WordPress et au métier de ce plugin de gestion de formulaires.
Les premiers résultats, sur le plan de la fluidité, étaient impeccables. C’est en confrontant la traduction à un relecteur technique que les problèmes de fond sont apparus, des erreurs discrètes mais réelles de terminologie.
Le symptôme : une traduction fluide mais imprécise
Le mot anglais « hook » a été tantôt traduit par « crochet », tantôt laissé tel quel, tantôt rendu par « point d’ancrage », selon les pages, sans cohérence. Le terme « shortcode », pourtant un concept technique précis de WordPress, a parfois été traduit par « code court », une expression qui n’existe dans aucune documentation française sérieuse du sujet. Sur les cent premières pages traduites, notre relecteur technique a identifié 23 termes mal ou incohéremment traduits.
Le diagnostic : un modèle généraliste sans glossaire
Un LLM généraliste traduit selon les usages statistiquement les plus fréquents qu’il a rencontrés à l’entraînement, sans connaître les conventions terminologiques propres à un écosystème technique restreint comme celui de WordPress. Il ne sait pas que la communauté française préserve systématiquement les termes « hook », « shortcode » ou « custom post type » en anglais, alors qu’elle traduit « plugin » par « extension » dans la documentation officielle.
- Aucune mémoire des choix terminologiques déjà faits d’une page à l’autre
- Aucun accès au glossaire officiel de la documentation WordPress francophone
- Une tendance à traduire trop littéralement certains termes techniques établis
Le correctif : injecter un dictionnaire métier dans le prompt
Nous avons constitué, avec l’équipe éditoriale du client, un glossaire d’une cinquantaine de termes avec leur traduction imposée, en s’appuyant notamment sur les conventions déjà utilisées par le Codex et le Manuel WordPress francophone. Ce glossaire est désormais injecté systématiquement dans chaque prompt de traduction.
$prompt = "Traduis ce texte technique de l'anglais vers le français. "
. "Respecte STRICTEMENT le glossaire suivant, ne traduis jamais "
. "ces termes autrement que de la façon indiquée :\n"
. "hook => hook (ne pas traduire)\n"
. "shortcode => shortcode (ne pas traduire)\n"
. "custom post type => type de contenu personnalisé\n"
. "plugin => extension\n"
. "hook callback => fonction de rappel\n\n"
. "Texte à traduire :\n" . $texte_source;
Sur les cinquante pages suivantes traitées avec ce prompt enrichi, le nombre d’erreurs de terminologie relevées par le relecteur est tombé à 4, essentiellement des cas non couverts par le glossaire initial, qui a depuis été complété.
Ce que le glossaire ne résout pas
Un dictionnaire de termes isolés ne garantit pas la cohérence syntaxique d’ensemble ni le ton attendu d’une documentation technique. Le relecteur a également dû reformuler plusieurs phrases traduites trop littéralement, grammaticalement correctes mais peu naturelles pour un lecteur francophone habitué au style de la documentation WordPress. La traduction automatique reste un accélérateur, pas un substitut à l’expertise du domaine.
Un glossaire métier bien construit corrige plus d’erreurs de traduction technique qu’un modèle plus puissant utilisé sans lui.
En résumé
Un LLM généraliste traduit avec fluidité mais sans connaissance native du jargon propre à un écosystème technique restreint. Injecter un glossaire de termes imposés dans le prompt corrige une grande partie des erreurs de terminologie observées, mais ne dispense jamais d’une relecture par un expert du domaine avant publication d’une documentation destinée à des développeurs.
