La traduction est juste, les termes du glossaire sont bons, et pourtant elle sonne encore comme une traduction. La reformulation est l’étape du pipeline qui comble ce dernier écart : un agent IA retravaille le résultat actuel pour qu’il se lise comme un texte naturel dans la langue cible, tout en préservant le sens, les placeholders et les balises.
Cette page présente l’étape rephrase à elle seule : ce qu’elle réécrit, ce qu’elle laisse intact, ce qui se passe quand l’exécution échoue, et la seule décision qu’elle vous demande de prendre : l’activer ou la laisser de côté. Vous découvrez le pipeline ? Commencez par la Vue d'ensemble du pipeline de localisation asynchrone pour comprendre comment les étapes s’articulent. La reformulation est réservée à l’asynchrone : elle s’exécute pour les tâches créées via l’API de localisation asynchrone, jamais pour l’appel synchrone /localize.
Ce qu’elle fait#
Une traduction littérale peut reprendre dans la langue cible les tournures de la source : grammaticalement correctes, mais manifestement traduites. L’étape de reformulation retravaille le meilleur résultat disponible pour qu’il se lise comme un texte rédigé naturellement dans la langue cible : fluide et idiomatique, en privilégiant un équivalent idiomatique plutôt qu’un rendu mot à mot. Elle préserve le sens et l’intention d’origine, et applique le glossaire, la voix de marque et les instructions de votre moteur : la même configuration que celle qui a produit la traduction pilote aussi la réécriture.
Elle s’exécute après les étapes d’amélioration par l’IA et par l’humain, sur le résultat qui lui parvient. Elle fonctionne donc de la même façon, que la relecture humaine et la post-édition par IA soient activées ou non : dans tous les cas, elle retravaille la meilleure version disponible à ce stade. Lorsque la vérification par rétrotraduction est également activée, elle vérifie le résultat reformulé, et non celui d’avant reformulation.
Une passe littérale vous garde au plus près de la formulation source ; la reformulation rapproche le texte de la manière dont un natif l’écrirait. Les deux ne sont donc pas interchangeables : le choix dépend de la décision ci-dessous.
Vos placeholders et balises restent intacts#
La question évidente face à une étape dont le rôle est de réécrire du texte, c’est de savoir si elle touchera aussi aux éléments qui ne relèvent pas de la prose. La réponse est non. La reformulation conserve les placeholders, les variables, les balises et la mise en forme exactement en l’état : elle réécrit les mots qui les entourent, pas les tokens dont dépend votre application.
Ainsi, une chaîne comme celle-ci conserve chaque interpolation et chaque balise, et seul le texte lisible par l’humain change :
Source (en): "Hi {firstName}, you have <b>{count}</b> new messages."
Translated (de): "Hallo {firstName}, du hast <b>{count}</b> neue Nachrichten."
After rephrase (de):"Hey {firstName}, <b>{count}</b> neue Nachrichten warten auf dich."{firstName}, {count} et les balises <b> sont identiques dans les trois versions. Le texte se lit plus naturellement en allemand ; la structure dont dépend le runtime, elle, ne change pas.
Si elle échoue, la tâche continue#
La reformulation est une étape non critique. Une réécriture par IA peut échouer ou expirer — et dans ce cas, la traduction que vous avez déjà payée n’est pas perdue. Le résultat précédent est repris tel quel et la tâche continue. Vous ne mettez pas en jeu une traduction juste pour un simple passage de style.
L’échec de la reformulation ne fait pas échouer la tâche. Il apparaît dans l’enregistrement d’étape avec status: failed, la tâche se termine avec le statut completed_with_warnings, et la traduction d’avant reformulation est celle qui arrive dans outputData :
{
"id": "ljb_C3d4E5f6G7h8I9j0",
"status": "completed_with_warnings",
"outputData": {
"greeting": "Hallo {firstName}, du hast <b>{count}</b> neue Nachrichten."
},
"warnings": [
{ "step": "rephrase", "message": "<the failure reason for this step>" }
],
"steps": [
{ "stepId": "localize", "type": "action", "status": "completed" },
{ "stepId": "rephrase", "type": "action", "status": "failed" }
]
}La traduction de a bien été livrée. Le texte exact de message est ici donné à titre d’exemple ; ce qui ne change pas, c’est la structure : une entrée warnings[] avec step et message, l’étape rephrase enregistrée comme failed, et le résultat d’avant reformulation conservé dans outputData. Consultez le champ step pour voir que le texte n’a pas été retravaillé lors de cette exécution, afin de pouvoir relancer cette langue si une formulation naturelle est importante pour elle. Voir Observe pipeline runs pour la structure complète de steps[] et warnings, et la façon dont les échecs non critiques sont agrégés dans completed_with_warnings.
Non critique signifie best-effort, par conception
Activer la reformulation ne peut pas réduire la fiabilité d’une tâche. Dans le pire des cas, vous obtenez la traduction que vous auriez livrée sans cette étape, avec un avertissement en plus. C’est ce qui vous permet de l’activer largement et de considérer le texte retravaillé comme une amélioration, et non comme une dépendance.
Quand l’activer, quand la laisser de côté#
La reformulation optimise une seule chose : faire lire le texte comme un original rédigé par un natif. C’est exactement ce qu’il faut pour certains contenus, et exactement ce qu’il ne faut pas pour d’autres ; c’est donc un choix à faire contenu par contenu, pas un réglage global par défaut.
Activez-la pour les contenus marketing, les landing pages, les descriptions produit et l’onboarding — partout où il est plus important que le texte se lise comme un original natif que de rester proche de la formulation source.
Laissez-la de côté pour les contenus techniques et juridiques, où la fidélité littérale est prioritaire. La reformulation réécrit le texte pour qu’il sonne naturellement ; dans une clause contractuelle, une Référence API ou une chaîne liée à la conformité, une formulation plus proche de la source reste le choix le plus sûr. Pour ce type de contenu, laissez la reformulation désactivée et conservez le résultat de l’étape de localisation principale.
Une formulation naturelle implique un compromis, pas un gain automatique
La reformulation éloigne volontairement le texte de la formulation source. C’est précisément l’intérêt pour le marketing, et le risque pour tout contenu dont la formulation exacte a une portée juridique ou technique. Si vous hésitez sur la catégorie d’un payload donné, laissez la reformulation de côté pour celui-ci : le littéral est l’option la plus sûre par défaut.
L’activer#
La reformulation se configure comme toutes les autres étapes — avec une valeur par défaut au niveau du moteur, plus une surcharge facultative par requête — ; tous les détails se trouvent donc sur Configure the pipeline. En version courte : activez-la dans l’onglet Pipeline du moteur pour l’appliquer à chaque tâche, ou définissez-la pour un envoi unique avec pipelineConfig :
{
"sourceLocale": "en",
"targetLocales": ["de", "fr"],
"data": { "headline": "Ship global products faster." },
"pipelineConfig": {
"rephrase": { "enabled": true }
}
}Les étapes que vous omettez héritent de la configuration du moteur — la surcharge ci-dessus active donc la reformulation pour cet envoi sans toucher aux autres étapes. C’est ce qui vous permet de laisser la reformulation désactivée au niveau du moteur pour les contenus littéraux, et de l’activer requête par requête pour les contenus marketing qui en ont besoin.
