Définissez quelles étapes du pipeline s’exécutent sur deux couches : une configuration par défaut sur le moteur, et un remplacement facultatif sur une requête donnée.
Vous avez déjà décidé quelles étapes vous voulez autour de l’étape centrale de traduction. Il reste alors deux questions : où cette décision doit-elle vivre, et que faire lorsqu’une tâche a besoin d’un pipeline différent des autres ? La réponse tient en deux couches. Le moteur porte la configuration par défaut dont héritent toutes les tâches asynchrones. Un objet pipelineConfig sur une soumission donnée remplace cette valeur par défaut pour cette seule soumission. Les étapes que vous laissez hors du remplacement héritent du moteur, si bien qu’une requête n’indique que ce qui change.
Vous découvrez le pipeline ? Commencez par la Vue d'ensemble du pipeline pour comprendre le rôle de chaque étape. Cette page explique comment les activer et les remplacer, pas ce qu’elles font une fois activées.
Tâches asynchrones uniquement
La configuration du pipeline s’applique aux tâches créées via l’API de localisation asynchrone. Le point de terminaison synchrone /localize n’exécute que l’étape centrale de traduction et ignore entièrement les paramètres du pipeline, quelle que soit la couche.
Valeurs par défaut au niveau du moteur#
Ouvrez l’onglet Pipeline du moteur dans le tableau de bord et activez ou désactivez chaque étape indépendamment. Cette configuration devient la valeur par défaut du moteur : chaque tâche asynchrone qui y est routée s’exécute avec ces étapes, sauf si une requête les remplace. Définissez-la une fois, et vous n’avez pas à redéclarer le pipeline à chaque appel.
Chaque étape a son propre interrupteur. Vous pouvez activer n’importe quelle combinaison : aucune, toutes, ou tout ce qu’il y a entre les deux :
- Retouche IA pré-localisation – nettoie la source avant la traduction.
- Relecture humaine post-localisation – achemine vers une relecture interne ou externe. Vous choisissez le mode, le niveau et le délai d’attente dans le même panneau.
- Évaluation IA post-localisation – reste désactivée tant que la relecture humaine n’est pas activée ; elle réconcilie les modifications humaines avec les règles de votre moteur.
- Reformulation pour un rendu naturel – réécrit le texte pour qu’il sonne comme s’il avait été rédigé par un natif. Indépendante des autres étapes.
- Vérification par rétrotraduction – vérifie que le sens a bien survécu à l’aller-retour. Indépendante des autres étapes.
La localisation centrale n’est pas un interrupteur : elle s’exécute toujours. Les autres étapes s’articulent autour d’elle.
C’est cette valeur par défaut dont hérite chaque tâche ; la configuration du moteur est donc la structure dans laquelle vient se fusionner un remplacement pipelineConfig. Chaque étape correspond à une clé :
{
"preEdit": { "enabled": true },
"humanEdit": {
"enabled": true,
"provider": "internal",
"tier": "standard",
"timeoutHours": 48
},
"postEdit": { "enabled": false },
"rephrase": { "enabled": false },
"backTranslation": { "enabled": true }
}| Clé | Champs | Défini sur la page de l’étape |
|---|---|---|
preEdit | enabled | Retouche IA pré-localisation |
humanEdit | enabled, provider (internal | gengo), tier (standard | pro), timeoutHours | Relecture humaine |
postEdit | enabled | évaluation IA |
rephrase | enabled | Reformulation pour un rendu naturel |
backTranslation | enabled | Vérification par rétrotraduction |
Le rôle de chaque champ — quel fournisseur de relecture, quel niveau, combien de temps attendre — est documenté sur la page dédiée à l’étape concernée. Cette page explique où vit la configuration et comment les deux couches se combinent.
Remplacement par requête#
La plupart des tâches devraient s’exécuter avec la configuration par défaut du moteur. L’exception, c’est une soumission donnée qui a besoin d’un pipeline différent : un lot ponctuel de contenus marketing qui veut l’étape de reformulation que votre moteur laisse habituellement désactivée, ou une charge utile juridique qui devrait au contraire l’ignorer. Modifier le moteur pour traiter un seul lot changerait aussi toutes les autres tâches.
Vous transmettez donc uniquement la différence dans la requête. Ajoutez un objet pipelineConfig au corps de POST /jobs/localization, et il remplace la valeur par défaut du moteur pour cette seule soumission. Rien ne change sur le moteur ; la tâche suivante sans remplacement revient à la configuration par défaut.
{
"sourceLocale": "en",
"targetLocales": ["de", "fr"],
"data": { "headline": "Ship in every language." },
"pipelineConfig": {
"rephrase": { "enabled": true },
"backTranslation": { "enabled": false }
}
}Voici la règle d’héritage, et c’est elle qui permet de garder le remplacement léger : une étape que vous mentionnez est remplacée ; une étape que vous omettez hérite de la valeur par défaut du moteur. La requête ci-dessus active rephrase et désactive backTranslation pour cette seule tâche. preEdit, humanEdit et postEdit ne sont pas mentionnés ; ils s’exécutent donc exactement comme ils sont configurés sur le moteur. Vous n’indiquez que ce qui change.
Inclure une étape, c’est la spécifier en entier
Le remplacement se fait par étape, pas par champ. Chaque étape que vous incluez doit être l’objet complet de cette étape — vous ne pouvez pas envoyer humanEdit: { "tier": "pro" } pour ne modifier que le niveau tout en héritant du reste. Incluez l’étape entière pour la remplacer, ou omettez-la pour hériter de la valeur par défaut du moteur. Il n’existe pas de fusion partielle à l’intérieur d’un même objet d’étape.
Deux autres points importants sur ce que le remplacement ne fait pas, car c’est précisément là que l’on pourrait croire qu’il peut tout faire :
- Il modifie cette soumission uniquement. Il n’écrit rien en retour sur le moteur ; ce n’est donc pas la bonne manière d’apporter une modification de configuration durable — pour cela, utilisez l’onglet Pipeline. Utilisez le remplacement pour un besoin ponctuel ; utilisez l’onglet pour définir la nouvelle norme.
- Il n’assouplit pas les propres règles d’exécution d’une étape. Évaluation IA post-localisation ne s’exécute que lorsqu’une relecture humaine a produit un résultat ; activer
postEditne change donc rien sur une tâche qui n’a aucune étape humaine à réconcilier — quelle que soit la couche où vous l’avez activée.
Confirmer ce qui s’est exécuté#
La configuration détermine quelles étapes doivent s’exécuter ; l’enregistrement de la tâche, lui, vous indique lesquelles l’ont réellement été. La tâche contient un tableau steps[], et c’est ce tableau qui vous permet de confirmer qu’un remplacement par requête a bien été pris en compte — pas seulement qu’il a été envoyé.
L’interprétation de ces enregistrements — le stepId de chaque étape, ce que signifie une étape skipped, où apparaissent les échecs non critiques — est expliquée sur une page dédiée.
Étapes suivantes#
Vous pouvez définir la configuration par défaut sur le moteur et la remplacer dans une requête. À partir d’ici, soumettez une tâche avec un remplacement, ou consultez les étapes pour confirmer lesquelles se sont exécutées.
