La traduction automatique offre une excellente première version. Pour une grande partie des contenus, c’est largement suffisant. Mais certains contenus demandent davantage avant publication : un texte source d’abord nettoyé de ses fautes, un traducteur humain dans la boucle, un rendu qui se lise comme s’il avait été écrit par un natif, une vérification que le sens a bien survécu à l’aller-retour.
Vous pourriez assembler ces étapes vous-même : lancer la traduction, passer un correcteur grammatical, envoyer le résultat à un relecteur, attendre son retour, retraduire pour vérifier une dérive, puis réconcilier les écarts. Traduire, c’est la partie facile. Ce qui est difficile, c’est d’orchestrer les temps d’attente, l’ordre d’exécution et les échecs entre toutes ces étapes — et le plus compliqué de tout, c’est encore le relecteur qui met deux jours à répondre.
Le pipeline, c’est justement cet enchaînement d’étapes, déjà prêt à l’emploi. Chaque étape est une surcouche optionnelle autour de l’étape centrale de traduction, activée sur le moteur de localisation (ou redéfinie pour chaque requête), puis exécutée dans la tâche asynchrone durable qui gère déjà les tentatives et l’isolation des échecs. Vous choisissez les étapes ; la plateforme les exécute dans l’ordre et consigne ce qui s’est passé. Au final, c’est l’idée clé que ce système vous laisse : entourez l’étape de traduction avec exactement les étapes dont vous avez besoin.
API asynchrone uniquement
Les étapes du pipeline s’appliquent uniquement aux tâches créées via l’API de localisation asynchrone. Le point de terminaison synchrone /localize exécute l’étape centrale de traduction, et rien d’autre — toute configuration de pipeline sur le moteur est ignorée. Une étape de relecture humaine exige un workflow capable de se mettre en pause pendant deux jours ; un simple appel requête/réponse n’a nulle part où placer cette attente. Le pipeline vit là où la tâche est durable.
Sur cette page
- Pourquoi un pipeline
- Vue d’ensemble des étapes
- Ce qu’une étape en échec change pour la tâche
- Pour aller plus loin
Pourquoi un pipeline#
Une traduction brute ne fait aucune distinction selon le type de contenu qu’elle traduit. Un texte juridique doit rester fidèlement collé à la source. Un texte marketing doit se lire comme s’il avait été écrit par un natif, pas comme une traduction. Un texte source généré par les utilisateurs a intérêt à être nettoyé de ses fautes avant qu’une seule erreur ne contamine toutes les langues cibles. Un contenu réglementé, lui, exige la validation d’un humain qualifié.
Ce sont des besoins différents, et le pipeline permet à un même moteur de tous les couvrir en combinant des étapes, au lieu d’imposer un comportement unique. N’activez rien, et vous obtenez une traduction simple. Activez une étape de relecture humaine, et la tâche se met en pause pour votre équipe. Activez l’étape de reformulation, et la sortie est retravaillée pour sonner comme un texte rédigé par un natif. Chaque page d’étape ci-dessous précise le type de contenu auquel elle s’adresse — et, tout aussi clairement, celui auquel elle ne s’adresse pas, pour éviter d’activer une étape qui irait à l’encontre de votre objectif.
Vous configurez les valeurs par défaut une seule fois dans l’onglet Pipeline du moteur, ou vous les redéfinissez pour un envoi unique avec un objet pipelineConfig dans la requête ; les étapes omises héritent du réglage du moteur. Le fonctionnement de ces deux niveaux est expliqué dans Configurer le pipeline.
Vue d’ensemble des étapes#
Le pipeline enveloppe l’étape centrale de localisation. Vous pouvez activer n’importe quelle combinaison d’étapes, dans cet ordre fixe. Les étapes désactivées sont entièrement ignorées. Chaque étape dispose de sa propre page avec son comportement complet, son mode d’échec et l’appel permettant de l’activer.
Édition IA pré-localisation
Optionnel. Un agent IA nettoie la charge utile source — fautes de frappe, grammaire, orthographe — avant toute traduction, pour éviter qu’une seule erreur dans la source ne se propage à toutes les langues cibles. Non critique. Voir Édition IA pré-localisation.
Localisation principale
S’exécute toujours. Votre moteur applique sa configuration du modèle, son glossaire, sa voix de marque et ses instructions pour produire la traduction. C’est la seule étape que vous ne pouvez pas désactiver — tout le reste s’articule autour d’elle.
Relecture humaine post-localisation
Optionnel. Un humain relit la traduction : votre propre équipe dans le tableau de bord (relecture interne) ou un traducteur professionnel chez un prestataire externe (relecture externe). La tâche se met en pause en attendant leur résultat via une attente pilotée par événements, de sorte qu’une relecture longue ne consomme aucune ressource de calcul pendant l’attente. Voir Human review.
Évaluation IA post-localisation
Optionnel, et ne s’exécute qu’une fois qu’une relecture humaine a produit un résultat. Un agent IA réconcilie les modifications humaines avec le glossaire, la voix de marque et les instructions de votre moteur. Ce n’est pas la même chose que les évaluateurs IA, qui notent la qualité sans modifier le texte. Voir AI review.
Reformulation pour un texte naturel
Optionnel. Un agent IA réécrit la traduction pour qu’elle se lise comme un texte idiomatique rédigé par un natif dans la langue cible, tout en préservant le sens, les placeholders et les balises. Non critique. À réserver aux textes marketing ; à éviter là où la fidélité littérale prime. Voir Rephrase for natural copy.
Vérification par retraduction
Optionnel. La sortie est retraduite vers la source, une IA la compare à l’original, et la dérive est signalée comme minor, major ou critical — les problèmes majeurs et critiques sont corrigés automatiquement. Une technique classique d’assurance qualité humaine, automatisée. Voir Back-translation check.
Ce qu’une étape en échec change pour la tâche#
L’objection la plus évidente face à un pipeline en six étapes est simple : chaque étape ajoutée est une source de panne potentielle. Est-ce que les activer rend la tâche plus susceptible d’échouer ? Non. Un échec dans une étape non critique ne fait pas échouer la tâche. La pré-édition et la reformulation sont non critiques : si l’une des deux échoue, la dernière bonne sortie est conservée telle quelle et la tâche continue. La tâche passe en état d’avertissement au lieu de casser, et chaque étape activée laisse une trace que vous pouvez consulter pour voir exactement ce qui a été exécuté.
C’est toute la logique du pipeline : entourez l’étape de traduction avec exactement les étapes dont vous avez besoin, exécutez-les dans une tâche qui gère déjà les échecs, puis consultez un enregistrement pour chaque étape. La manière dont une tâche dégradée se signale, ainsi que la surface d’inspection par étape, sont détaillées dans Observe pipeline runs. Les pages ci-dessous présentent les étapes elles-mêmes : commencez par celle qui correspond au contenu que vous traduisez.
