Vous avez envoyé vos sources et le job est en cours. L'ID du moteur a été renvoyé dans le 202, et sa configuration est en train de se compléter. Cette page répond à la question qui détermine si vous ferez confiance au résultat : qu'est-ce qui, exactement, est en train de se remplir ?
« Une IA a configuré mon moteur » est le genre de phrase qui met un ingénieur sur ses gardes — et c'est le bon réflexe. Cela peut évoquer une boîte noire impossible à inspecter. Cela peut évoquer des enregistrements éparpillés entre différentes langues, sans visibilité claire. Cela peut aussi vouloir dire que l'agent a lu une source peu riche, n'a presque rien trouvé et n'a créé presque rien, discrètement. Cette page est donc concrète sur ces trois points : l'agent produit trois types de configuration, chacun est associé à vos langues selon une règle prévisible, et le job renvoie un récapitulatif qui nomme chaque enregistrement créé. Le résultat, ce sont des enregistrements ordinaires que vous pouvez lire et modifier — pas un verdict que vous devez accepter sur parole.
Vous découvrez le provisioning asynchrone ? Commencez par la Vue d'ensemble de l'API de provisioning asynchrone pour bien comprendre le fonctionnement, puis par Types de sources pour savoir ce qui fait qu'une source mérite d'être envoyée. Cette page s'intéresse à ce qui en ressort.
Sur cette page
- Les trois composants
- Comment chacun est associé à une langue
- Le récapitulatif de sortie
- Interpréter un récapitulatif léger
- Étapes suivantes
Les trois composants#
L'agent lit tout — pages explorées comme contenu brut — et crée trois types de configuration du moteur. Il ne s'agit pas d'un nouveau format réservé au provisioning. Ce sont exactement les mêmes primitives que vous créeriez autrement à la main dans un moteur, c'est pourquoi tout ce que l'agent crée reste modifiable ensuite dans le tableau de bord, exactement comme ce que vous auriez créé vous-même.
| Composant | Ce qu'il repère | Exemple |
|---|---|---|
| Voix de marque | Ton, style, niveau de formalité, conventions rédactionnelles | « Utilisez un allemand formel (forme de politesse Sie). Gardez des phrases concises et directes. » |
| Entrées de glossaire | Noms de produits, termes techniques, traductions propres à la marque, termes non traduisibles | « Acme » → non traduisible, « workspace » → « Arbeitsbereich » (de) |
| Instructions | Règles de formatage, conventions culturelles, consignes propres au domaine | « Formatez toujours les dates en JJ.MM.AAAA dans les traductions allemandes. » |
Ce sont ces trois éléments qui font qu'une traduction sonne comme votre produit plutôt que comme un rendu générique : le niveau de formalité choisi, les noms que vous ne traduisez jamais, le format de date que vous utilisez systématiquement. Le rôle de l'agent est de repérer ces décisions partout où elles sont formulées dans vos sources et de les consigner sous forme d'enregistrements.
Il faut énoncer clairement une conséquence, car elle fixe la limite de ce que vous pouvez attendre en retour : l'agent extrait ce qui est explicitement dit, pas ce qui est implicite. Une source qui formule une règle clairement produit un enregistrement ; une source qui se contente d'illustrer un bon ton sans nommer la règle produit peu de choses. C'est une propriété des sources, pas du moteur — Types de sources explique comment choisir des sources qui formulent leurs règles noir sur blanc.
Comment chacun est associé à une langue#
La configuration d'un moteur de localisation est indexée par langue cible. Un enregistrement ne décrit donc pas seulement quelle est la règle, mais aussi où elle s'applique. L'agent assigne à chaque enregistrement une langue selon une règle prévisible, et le joker * est l'élément à bien comprendre avant de lire le résultat.
- Les voix de marque et les instructions utilisent
*lorsqu'elles s'appliquent à toutes les langues. Une règle de ton comme « gardez des phrases concises et directes » n'est pas propre à l'allemand ; c'est la manière dont votre produit s'exprime dans toutes les langues. L'agent lui attribue donc la langue cible*, et elle s'applique à toutes les langues vers lesquelles le moteur traduit. Une règle réellement spécifique à une langue (« utilisez la forme de politesse Sie en allemand ») est attribuée à cette langue à la place. - Les entrées de glossaire sont créées par paire de langues, car une traduction se fait toujours d'une langue vers une autre langue précise — « workspace » → « Arbeitsbereich » est un fait propre à l'allemand, et à lui seul.
- Les termes non traduisibles font exception et utilisent
*. Un nom de marque que vous ne traduisez jamais — « Acme » — est non traduisible dans toutes les langues ; il est donc enregistré une seule fois avec*au lieu d'être ressaisi pour chaque paire de langues.
Ainsi, lorsque vous voyez * dans un enregistrement créé par le job, il ne s'agit ni d'un placeholder ni d'un manque. Cela signifie « ceci s'applique partout » — une règle de ton globale, une instruction globale ou un terme qui n'est jamais traduit dans aucune langue. Un code de langue précis signifie l'inverse : cette règle s'applique uniquement à cette langue.
Pourquoi le joker est une fonctionnalité, pas une valeur par défaut à remplacer
Une lecture sceptique de * pourrait être : « l'agent n'a pas pris la peine de déterminer à quelle langue cela correspond ». C'est l'inverse. Une voix de marque ou un terme non traduisible valable dans toutes les langues doit être global — le rattacher à une seule langue voudrait dire qu'il cesserait discrètement de s'appliquer aux autres. Le joker est la façon dont la configuration dit « ceci est vrai quelle que soit la langue », ce qui correspond exactement à ce qu'est, le plus souvent, une règle de ton ou un nom de marque.
Le récapitulatif de sortie#
Lorsque le job se termine, il renvoie un récapitulatif qui liste tout ce que l'agent a créé. C'est le reçu : chaque enregistrement, compté et identifié, plus la liste de tout ce qui a échoué.
{
"brandVoices": {
"count": 3,
"ids": ["bv_A1b2C3d4", "bv_B2c3D4e5", "bv_C3d4E5f6"]
},
"glossaryItems": {
"count": 12,
"ids": ["gi_A1b2C3d4", "gi_B2c3D4e5", "..."]
},
"instructions": {
"count": 5,
"ids": ["ins_A1b2C3d4", "ins_B2c3D4e5", "..."]
},
"errors": []
}Chaque composant indique un count ainsi que les ids des enregistrements créés — bv_ pour les voix de marque, gi_ pour les entrées de glossaire, ins_ pour les instructions. Ce ne sont pas de vagues accusés de réception : ce sont les identifiants de vrais enregistrements dans le moteur. Vous pouvez prendre n'importe quel gi_ de cette liste, l'ouvrir dans le tableau de bord et lire ou modifier exactement ce que l'agent a extrait. Le récapitulatif vous fait passer de « l'IA a fait quelque chose » à « voici les vingt choses précises qu'elle a faites » — toute la différence entre une boîte noire et des enregistrements ordinaires que vous pouvez lire et modifier.
Le récapitulatif vous parvient par le canal que vous avez configuré lors de la création du job : dans la charge utile du webhook reçue par votre URL de rappel une fois le traitement terminé, où il apparaît dans le champ summary. Si vous suivez le job via le WebSocket, il s'agit d'un flux de suivi en direct — il diffuse la progression de l'exploration et de la configuration, pas cet objet de récapitulatif. Le récapitulatif arrive avec le webhook de fin ; le WebSocket vous indique simplement quand aller le consulter.
L'échec d'un élément ne fait pas échouer le job.
Si un seul enregistrement ne peut pas être créé, cela ne fait pas tomber le reste. L'échec est consigné dans le tableau errors, les enregistrements créés avec succès sont quand même appliqués au moteur, et le job se termine malgré tout. Vous obtenez un moteur partiellement configuré, avec une liste précise de ce qu'il faut revoir — pas un moteur vide et une trace de pile. Le job échoue dans son ensemble lorsque l'exécution ne produit rien d'exploitable — par exemple, si toutes les sources échouent à l'exploration ; ce cas d'échec, ainsi que sa charge utile provisioning.failed, sont documentés dans Livraison des webhooks.
Interpréter un récapitulatif léger#
Le récapitulatif vous indique non seulement ce qui a été créé, mais aussi, par ses volumes, si l'exécution en valait la peine. Un count de 0 pour un composant n'est pas une erreur — le récapitulatif est bien formé et le moteur existe — mais c'est une information utile. Trois voix de marque et douze entrées de glossaire, c'est un moteur configuré. Zéro partout et un tableau errors vide, c'est un moteur revenu presque vierge, et l'agent vous indique qu'il a trouvé peu de règles à extraire.
Quand cela arrive, la cause est presque toujours en amont : les sources formulaient peu de règles concrètes que l'agent pouvait en extraire. C'est dans le récapitulatif que vous vous en apercevez ; c'est dans Types de sources que vous corrigez le tir. L'attente la plus juste pour une première exécution est la suivante : le reçu ne reflète que ce que vos sources ont réellement dit — un récapitulatif riche suppose des sources riches, et un récapitulatif léger signifie qu'il y avait peu à trouver.
C'est pourquoi le récapitulatif compte autant que le moteur : il vous permet de vérifier la configuration au lieu de la présumer. Regardez les volumes, ouvrez quelques enregistrements à partir de leurs identifiants, vérifiez que l'agent a bien capté ce que vous attendiez — des enregistrements ordinaires que vous pouvez lire et modifier, avec un reçu qui vous indique précisément quoi contrôler.
