Vous mettez en place un moteur de localisation. Un bon moteur de traduction n’est pas un moteur vide : c’est un moteur qui embarque votre voix de marque, votre glossaire et vos règles, pour que chaque traduction sonne comme votre produit et n’écorche jamais un terme déjà validé.
En général, cette matière existe avant même le moteur. Elle vit dans une page de directives de marque, un guide de style, une fiche terminologique, ou quelques paragraphes de règles qu’un traducteur a reçus un jour. Construire le moteur à la main, c’est tout relire puis tout ressaisir sous forme d’enregistrements de voix de marque, de glossaire et de règles, un par un — un travail fastidieux, facile à lancer et tout aussi facile à laisser en plan.
L’API de provisionnement asynchrone comble ce manque : pointez-la vers ce que vous avez déjà. En une seule requête POST, vous envoyez des liens et du texte brut, récupérez immédiatement un ID de moteur, puis un agent IA parcourt les sources, extrait les voix de marque, les entrées de glossaire et les règles, et applique chaque élément au nouveau moteur au fil de ses découvertes. Le moteur est utilisable dès l’instant où vous obtenez l’ID — la configuration se remplit à mesure que la tâche avance.
Sur cette page
Le problème#
La qualité d’un moteur de localisation dépend entièrement de sa configuration. Le choix du modèle vous donne une traduction ; ce sont les voix de marque, les entrées de glossaire et les règles qui font en sorte que cette traduction reflète déjà la façon dont votre produit s’exprime — le niveau de formalité que vous avez choisi, les noms de produit que vous ne traduisez jamais, le format de date que vous utilisez toujours. Ce sont les mêmes éléments de base que vous créeriez sinon à la main : voix de marque, entrées de glossaire et règles sur un moteur.
Le hic, c'est que tout cela existe déjà quelque part. Une équipe qui a lancé un produit dans une langue dispose déjà d'une page de directives de marque, d'un guide de style, d'un glossaire de termes que les agents du support ne doivent jamais traduire. Pour configurer le moteur à la main, vous lisez ces documents et les retranscrivez en enregistrements, décision par décision, langue par langue. C'est lent, et la partie la plus lente est aussi la moins intéressante : recopier dans un autre format des connaissances déjà consignées.
Le provisionnement supprime cette étape. Vous confiez à la plateforme les documents eux-mêmes — sous forme d’URL à parcourir ou de texte brut — et un agent IA se charge de les lire et de les transcrire. Il crée pour vous les enregistrements de voix de marque, de glossaire et de règles sur un vrai moteur, en appliquant chaque élément dès qu’il l’identifie. Vous faites ensuite la relecture et les ajustements dans le tableau de bord, exactement comme pour tout ce que vous auriez créé vous-même. Le point de départ, c’est un moteur configuré, pas un moteur vierge.
Le provisionnement configure un moteur ; il ne traduit pas.
Cette API crée et configure le moteur. Pour traduire avec ce moteur une fois qu'il existe, utilisez l'API de localisation asynchrone pour plusieurs langues à la fois, ou le point de terminaison Localize synchrone pour une seule paire de langues. Le provisionnement est l'étape de configuration qui permet à ces appels d'embarquer votre voix de marque et votre glossaire dès la première traduction.
Fonctionnement#
Trois étapes, et seule la première a lieu dans votre requête. Les deux autres s'exécutent sur la plateforme, à leur propre rythme — c'est pourquoi l'appel renvoie immédiatement et que le moteur est utilisable avant même la fin du traitement.
Soumettez vos sources
Envoyez en POST un nom pour le nouveau moteur et un tableau de sources — URL à parcourir, texte brut à analyser, ou les deux — vers /jobs/provisioning. L'API crée immédiatement le moteur et renvoie 202 avec l'identifiant du moteur (eng_) et l'identifiant de la tâche (pjb_). Votre application peut continuer son exécution ; rien dans la réponse n'attend l'extraction. Consultez Créer une tâche de provisionnement pour la structure complète de la requête et de la réponse, et Types de sources pour savoir ce qui fait qu'une source mérite d'être soumise.
L'agent IA parcourt et extrait
Les sources liées sont parcourues en parallèle puis converties en texte ; le contenu brut est lu directement. Un agent IA analyse ensuite l’ensemble et en extrait trois types de configuration — voix de marque, entrées de glossaire et règles — en appliquant chaque élément au moteur dès qu’il l’identifie. Une source impossible à parcourir, ou un élément isolé qui ne peut pas être créé, n’empêche pas le reste d’avancer. Ce que l’IA extrait présente les trois composants et la manière dont ils s’appliquent aux langues.
Le moteur est prêt
Une fois l'extraction terminée, le moteur est entièrement configuré et prêt à traduire via l'API de localisation. La plateforme signale la fin du traitement — avec un récapitulatif de tout ce qui a été créé — à votre URL de webhook, ou en direct via la WebSocket de la tâche si vous souhaitez afficher la progression pendant son exécution.
L'identifiant du moteur est utilisable immédiatement.
L'identifiant eng_ dans 202 correspond à un vrai moteur dès l'instant où vous le recevez. Vous pouvez l'enregistrer, y faire référence et l'utiliser pour traduire immédiatement — la configuration s'applique pendant l'exécution de la tâche, si bien qu'une traduction lancée tôt s'appuie sur moins d'enregistrements extraits qu'une traduction effectuée après la fin de la tâche. Vous n'avez jamais à attendre la fin du provisionnement pour commencer à utiliser le moteur.
Authentification
Chaque requête — REST comme WebSocket — s'authentifie via votre en-tête X-API-Key. Les clés sont limitées à l'organisation et donnent accès à tous les moteurs de l'organisation. Consultez Authentification pour le détail, et Clés API pour en créer une.
Ce que vous obtenez en retour#
Un lecteur sceptique se pose déjà les deux questions qui déterminent si l'on peut s'y fier en production : que se passe-t-il si une source est mauvaise, et est-ce une boîte noire que je ne peux pas corriger ?
Rien n’est caché. Le provisionnement ne renvoie pas un blob propriétaire — il crée des enregistrements standard de voix de marque, de glossaire et de règles sur un vrai moteur, exactement les mêmes objets que vous créeriez à la main, tous modifiables ensuite dans le tableau de bord. Une fois la tâche terminée, elle renvoie un récapitulatif qui liste chaque enregistrement créé et chaque échec rencontré, pour vous permettre de vérifier la configuration au lieu de partir du principe qu’elle est correcte. Ce que l’IA extrait détaille ce récapitulatif et explique comment un élément en échec est isolé dans une liste errors pendant que le reste du moteur continue à se configurer.
Les sources sont elles aussi facultatives. Soumettez un nom sans sources et vous obtenez un moteur vierge avec la configuration par défaut, que vous pouvez paramétrer vous-même — Créer une tâche de provisionnement couvre aussi ce cas, ainsi que le format de réponse 202. Le provisionnement permet d'éviter la configuration manuelle ; ce n'est pas un prérequis pour disposer d'un moteur.
Des pages génériques produisent une configuration générique.
La qualité de la configuration dépend directement de ce que vous soumettez : des directives de marque et des listes terminologiques donnent à l'agent de la matière concrète à extraire ; une page d'accueil marketing, elle, n'apporte presque rien. Types de sources explique vers quoi le pointer.
Voilà le marché proposé par le provisionnement : une seule requête et une courte attente en échange de l'étape la plus fastidieuse, celle qui consiste à retranscrire une connaissance déjà écrite — pointez-le vers ce que vous avez déjà, et partez d'un moteur configuré. Les pages ci-dessous détaillent les différentes parties de cette promesse.
