Vous êtes en train de mettre en place un moteur de localisation. Un moteur qui traduit bien n'est pas un moteur vide : c'est un moteur qui embarque votre voix de marque, votre glossaire et vos instructions, pour que chaque traduction sonne comme votre produit et n'écorche jamais un terme déjà validé.
Cette connaissance existe souvent avant même le moteur. Elle se trouve 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 d'instructions, un à un : un travail fastidieux, facile à démarrer et tout aussi facile à laisser à moitié terminé.
L'API de provisionnement asynchrone comble ce manque : pointez-la vers ce que vous avez déjà. Vous envoyez des liens et du texte brut dans une seule requête POST, récupérez immédiatement un identifiant de moteur, puis un agent IA parcourt les sources, extrait les voix de marque, les entrées de glossaire et les instructions, et les applique au nouveau moteur à mesure qu'il les identifie. Le moteur est utilisable dès que vous recevez son identifiant : la configuration se complète pendant l'exécution de la tâche.
Sur cette page
Le problème#
La qualité d'un moteur de localisation dépend 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 instructions qui font correspondre cette traduction à la manière dont votre produit s'exprime déjà : le niveau de formalité choisi, les noms de produit que vous ne traduisez jamais, le format de date que vous utilisez systématiquement. Ce sont les mêmes primitives que vous créeriez autrement à la main : des voix de marque, des entrées de glossaire et des instructions 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 la lecture et de la transcription. Il crée pour vous les enregistrements de voix de marque, de glossaire et d'instructions sur un vrai moteur, en appliquant chacun dès qu'il l'identifie. Vous pouvez ensuite les relire et les ajuster dans le tableau de bord, exactement comme vous le feriez pour n'importe quel élément créé manuellement. 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 de type lien 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 instructions — qu'il applique au moteur à mesure qu'il les 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 ces trois composants et la manière dont ils sont associés 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 sur un vrai moteur des enregistrements standards de voix de marque, de glossaire et d'instructions, exactement les mêmes objets que vous créeriez à la main, chacun pouvant ensuite être modifié dans le tableau de bord. Lorsque la tâche se termine, elle renvoie un récapitulatif qui liste chaque enregistrement créé et chaque échec rencontré, afin que vous puissiez vérifier la configuration au lieu de simplement la supposer. 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.
