Pipelines de traduction : de l'extraction au déploiement continu

Un pipeline de traduction est le trajet automatisé que le texte de votre produit emprunte depuis la base de code vers des traducteurs professionnels, puis de retour en production, à chaque version, sans feuille de calcul ni fil d'e-mails pour porter le travail à la main. C'est la couche d'infrastructure du développement de logiciels multilingues : la partie qui décide si une nouvelle fonctionnalité sort dans toutes les langues prises en charge dès le premier jour, ou attend des semaines une tournée de traduction manuelle pendant que tous les marchés hors de votre langue d'origine prennent du retard.

Nous avons d'abord construit cette architecture de pipeline côté prestataire. Chez BeTranslated, l'entreprise de traduction dont Globaprom est issue, nous avons coordonné des centaines de linguistes professionnels sur des dizaines de paires de langues, sous des délais clients fixes, pendant plus de vingt ans. Ce qui suit est cette expérience, étape par étape : l'extraction, le passage au TMS, l'arbitrage entre traduction humaine et automatique, la relecture en contexte, puis la fusion et le déploiement continus.

Attraper chaque nouvelle chaîne à chaque version

L'extraction est la première étape, et personne n'a besoin de penser à la lancer. Un script ou un plugin de build parcourt la base de code à chaque commit ou version, repère chaque chaîne visible par l'utilisateur et la compare au dernier ensemble connu. Les nouvelles chaînes sont marquées nouvelles. Les chaînes modifiées sont marquées modifiées, pas renvoyées en silence comme s'il s'agissait de contenu neuf que personne n'avait traduit. Les chaînes supprimées sortent du périmètre, si bien que les traducteurs ne passent jamais de temps sur un texte qui ne sera plus livré.

La mécanique varie selon la pile. Les projets React et Vue extraient généralement depuis des fichiers de ressources i18next ou FormatJS. Les applications rendues côté serveur puisent dans des fichiers gettext .po ou des bundles de ressources Java. Les sites statiques extraient depuis le front matter et le contenu Markdown. Chaque configuration dépend de la même règle issue de la couche i18n (en anglais) : les chaînes vivent dans des fichiers de ressources sous des clés stables, jamais assemblées à partir de fragments dans la logique applicative. Un pipeline ne peut extraire que ce que l'architecture a déjà externalisé. Sautez ce socle (voir l'i18n expliquée aux non-ingénieurs) et il n'y a rien de propre à extraire, seulement des chaînes enfouies dans le code qu'un script ne peut pas toucher sans risque.

La panne que cette étape prévient est familière à quiconque a géré du contenu multilingue à l'ancienne. Un développeur livre une fonctionnalité, la chaîne française apparaît, et chaque autre langue dérive en silence jusqu'à ce que quelqu'un se souvienne de demander un lot de traduction. L'extraction automatisée supprime le « se souvenir ». Dès qu'une chaîne existe dans la langue source, elle existe dans la file d'attente de toutes les autres.

Mémoire de traduction et glossaires terminologiques au passage vers le TMS

Les chaînes extraites atterrissent dans un système de gestion de traduction (en anglais) (TMS), la plateforme qui achemine le contenu vers les traducteurs, suit le statut par langue et applique les deux mécanismes qui rendent la traduction répétée à la fois abordable et cohérente.

La mémoire de traduction est une base de données de chaque segment déjà traduit, confrontée au nouveau contenu phrase par phrase. Une nouvelle chaîne qui correspond exactement à une traduction stockée est réutilisée pour un coût faible ou nul. Une chaîne proche mais non identique (une « correspondance partielle », ou fuzzy match) est proposée au traducteur avec le pourcentage d'écart affiché, pour qu'il corrige au lieu de retaper depuis une page blanche. Sur des années de contenu produit, la mémoire de traduction se capitalise : chaînes d'interface récurrentes, textes juridiques standards et noms de produits répétés cessent de coûter quoi que ce soit à retraduire.

Les glossaires terminologiques règlent un autre problème : la cohérence. Un produit français avec des dizaines de contributeurs et des centaines de chaînes accumulera sinon trois mots néerlandais différents pour le même bouton, parce que trois traducteurs ont chacun fait un choix raisonnable trois jours différents. Un glossaire verrouille le terme approuvé, sa catégorie grammaticale, son contexte et les termes à éviter, pour que chaque traducteur, humain ou machine, rende « panier » de la même façon sur chaque écran. Nous entretenons les glossaires clients comme nous les avons entretenus pour nos clients de traduction pendant deux décennies : relus par quelqu'un qui connaît le produit, pas générés une fois au lancement puis laissés à l'abandon.

Le format d'échange sous la plupart des plateformes TMS est XLIFF, le XML Localization Interchange File Format, ratifié comme standard OASIS précisément pour transporter le contenu traduisible, son contexte et son statut d'un outil à l'autre sans perdre aucun des trois. Un TMS incapable d'importer et d'exporter du XLIFF proprement se battra contre votre base de code à chaque passage de relais, pas seulement au premier.

Choisir humain, machine ou MTPE selon le type de contenu

Toutes les chaînes ne méritent pas la même méthode de traduction. Les traiter à l'identique gaspille l'argent ou la qualité, et souvent les deux à la fois.

La traduction humaine mérite son coût partout où une erreur coûte cher : clauses contractuelles, pages de prix, mentions légales, textes d'onboarding qui façonnent une première impression, et toute chaîne sur un écran de paiement ou de consentement. Un linguiste chevronné attrape l'ambiguïté qu'une machine rend avec assurance, et de travers.

La post-édition de traduction automatique (MTPE) occupe le milieu. Un moteur de traduction automatique produit un premier jet, et un traducteur professionnel le relit et le corrige face au texte source plutôt que de partir d'une page blanche. La norme ISO 18587:2017 fixe les exigences formelles de ce processus et les compétences du post-éditeur, ce qui compte parce que « MTPE » s'emploie de façon lâche dans les argumentaires commerciaux ; la norme définit ce qu'une post-édition complète doit réellement vérifier avant livraison. La MTPE convient aux volumes qu'un budget purement humain ne peut pas suivre : descriptions de produits de longue traîne, archives de support et données de catalogue comptant des milliers d'entrées quasi identiques.

La traduction automatique brute, sans relecture, doit rester cantonnée à la tranche de contenu la plus étroite : des outils internes que personne ne voit hors de l'entreprise, ou des textes explicitement signalés comme générés par machine pour que le lecteur sache à quoi s'en tenir. Nous la recommandons rarement pour quoi que ce soit en contact client sans au moins une passe humaine légère, parce qu'un texte fluide et faux avec assurance est plus dur à repérer pour un lecteur qu'une coquille évidente.

Cette décision fonctionne mieux sous forme de carte par type de contenu, convenue une fois par projet plutôt que débattue pour chaque chaîne. Nous inscrivons cette carte directement dans les règles de routage du TMS à la mise en place, pour que le nouveau contenu atterrisse automatiquement sur le bon bureau, sans réunion de tri.

Pourquoi la relecture en contexte attrape ce que les feuilles de calcul manquent

Une chaîne traduite correctement en isolation peut rester fausse à l'écran. Le mot « Commande » désigne un achat sur une boutique et une instruction dans un outil technique, et le néerlandais tranche entre bestelling et opdracht : deux mots sans rapport, pour une seule ligne de tableur qui n'en dit rien. « Solde », « Note » et « Support » posent le même piège, et un traducteur qui ne voit que la colonne source joue à pile ou face. La longueur est le deuxième échec récurrent : un libellé qui tient au millimètre dans son bouton en français déborde une fois rendu en allemand, et le W3C chiffre l'expansion des chaînes d'interface courtes jusqu'à 300 % à la traduction depuis l'anglais (W3C, Text size in translation).

La relecture en contexte comble cet écart. Les plateformes TMS modernes affichent un aperçu réel ou simulé de l'écran concerné, si bien que les traducteurs voient le bouton, les libellés voisins et la largeur disponible pendant qu'ils travaillent, pas un numéro de ligne à côté d'un identifiant de chaîne. Certaines configurations vont plus loin et attachent à chaque chaîne qui en a besoin des captures d'écran prises automatiquement sur un environnement de préproduction.

Nous traitons cette étape comme obligatoire plutôt qu'optionnelle, parce que l'écart de défauts est assez grand pour compter. Un traducteur sans contexte devine, et chaque supposition est un pile ou face joué contre le sens réel de votre produit. Un traducteur en contexte pose moins de questions de clarification et produit moins de correctifs post-lancement, parce qu'il traduit le produit qu'il a sous les yeux au lieu d'une liste de mots posée à côté.

Fusion et déploiement continus contre l'ancienne « phase de traduction »

L'ancien modèle traitait la traduction comme une phase : construire le produit en français, geler les chaînes, envoyer un lot aux traducteurs, attendre, puis livrer toutes les langues d'un coup, en général des semaines après la version française. Chaque mise à jour suivante répétait le même cycle gel-attente, si bien que vos utilisateurs néerlandophones, allemands ou espagnols restaient en permanence à la traîne, rattrapant une version déjà sortie et déjà dépassée.

Un pipeline de production remplace la phase par une boucle. Les traductions approuvées reviennent du TMS par les mêmes portes de relecture et de build que le code : une pull request, des vérifications automatisées, une fusion. Avec la localisation continue, cette boucle tourne à chaque version plutôt que sur un calendrier de traduction, si bien qu'un utilisateur flamand ou japonais voit une nouvelle fonctionnalité dans la même fenêtre de sortie qu'un utilisateur français, pas un trimestre plus tard.

C'est la bascule qui sépare un logiciel multilingue qui reste à jour d'un produit traduit une fois puis laissé à la dérive. Nous avons pratiqué les deux modèles côté prestataire : l'ancien passage de relais par lots, où l'équipe d'ingénierie d'un client attendait notre calendrier de livraison, et la boucle continue, où le contenu traduit fusionne aux côtés du code parce que le pipeline le traite comme un artefact de build, pas comme un flux de travail à part géré sur sa propre horloge. Le second modèle supprime toute une catégorie de réunions de suivi « quelle langue est en retard ». La réponse est toujours la même : aucune.

Ce que vingt ans côté prestataire nous ont appris

Nous étions autrefois à l'autre bout de ce pipeline, pas dans l'entreprise qui le construit. Pendant plus de deux décennies, BeTranslated a reçu des chaînes extraites, mobilisé des centaines de linguistes indépendants sur des dizaines de paires de langues, et renvoyé les traductions finies contre le délai d'un client, pas le nôtre.

Ce point de vue nous a appris où les pipelines cassent vraiment. Les glossaires dérivent dès que personne n'en est propriétaire après la réunion de lancement. La mémoire de traduction pourrit quand une migration de TMS perd la base, et chaque chaîne se refacture alors comme neuve. Les délais glissent surtout aux points de passage plutôt que pendant la traduction elle-même, parce qu'un linguiste ne peut commencer qu'au moment où le contenu lui parvient réellement dans un format exploitable.

Construire le pipeline nous-mêmes aujourd'hui, au lieu de recevoir des fichiers à son extrémité, explique pourquoi nous concevons le passage de relais en premier : quel TMS, quel propriétaire du glossaire, quelle porte de relecture, avant qu'une seule ligne de code applicatif suppose l'existence d'une deuxième langue.

Questions fréquentes sur les pipelines de traduction

Qu'est-ce qu'un pipeline de traduction ?

Un pipeline de traduction est le système automatisé qui extrait le nouveau contenu de votre base de code, l'achemine via un système de gestion de traduction, le fait traduire par des humains ou en MTPE, le relit en contexte et le refusionne à chaque version. Aucun passage de relais manuel n'est nécessaire.

En quoi un pipeline de traduction diffère-t-il d'une phase de traduction ?

Une phase de traduction regroupe la traduction en fin de construction ou la répète en rattrapages occasionnels, et les utilisateurs attendent des semaines les nouvelles langues. Un pipeline tourne en continu : chaque version sort dans toutes les langues prises en charge à la fois, parce que la traduction est une étape de build, pas un calendrier à part.

Que signifie TMS ?

TMS signifie « translation management system », système de gestion de traduction : la plateforme qui achemine le contenu vers les traducteurs, applique la mémoire de traduction et les glossaires terminologiques, et suit le statut par langue. En logistique, les trois mêmes lettres désignent un transportation management system, un outil sans rapport.

En quoi un pipeline de traduction diffère-t-il de la localisation ?

Le pipeline est le mécanisme ; la localisation est l'adaptation plus large qu'il livre, formats, devise et visuels compris. Le pipeline déplace les mots et leur statut ; la localisation décide de tout le reste dont un marché donné a besoin par-dessus.

Traduisez-vous le contenu vous-mêmes, ou construisez-vous seulement le pipeline ?

Nous organisons la traduction plutôt que de l'exécuter comme le ferait votre équipe interne. Via le pipeline que nous construisons et notre réseau de linguistes professionnels, couvrant des dizaines de paires de langues et des centaines de traducteurs, vous disposez de traduction humaine ou de MTPE à la demande pour chaque version.

Câblez le pipeline une fois, livrez toutes les langues ensuite

Dites-nous de quelles langues votre produit a besoin et comment les nouvelles chaînes sont gérées aujourd'hui, si tant est qu'elles le soient. Nous cadrons l'extraction, le TMS, le glossaire et la porte de relecture comme une seule construction à prix fixe, pas un abonnement boulonné sur votre base de code après le lancement.

Demander un devis à prix fixe →