Pilote automatique

Cette page s’adresse à toute personne qui lance des traductions, dans l’interface ou par l’API d’automatisation, et aux administrateurs qui règlent le comportement de Libris quand quelque chose tourne mal. Elle explique ce qui se passe entre « Traduire » et le livre fini, comment Libris se remet des échecs, ce que signifie « conservé en original », où chaque décision automatique est consignée, et comment désactiver le pilote automatique.

Avec le pilote automatique, un livre va de sa source à un résultat exportable. Chaque point où une personne devait décider (un passage refusé, une réponse invalide du modèle, une remarque de relecture, un terme de glossaire proposé, une panne du provider) est tranché par Libris ou par le modèle, dans des limites fixes, et consigné avec sa raison. Seule l’indisponibilité du modèle arrête la progression ; les réponses invalides laissent des points visibles dans le rapport. Vous pouvez corriger un passage à tout moment.

Quand il s’applique

Le pilote automatique est activé par défaut. Il s’applique à tout travail qui porte sur un livre entier :

• un import lancé avec son pipeline, dans l’assistant d’import ;
• une requête de l’API d’automatisation ;
• les actions Analyser et Traduire sur un livre entier.

Le travail ciblé reste sous votre contrôle et garde son comportement habituel : traduire un chapitre ou un passage, relancer une sélection depuis Bilan & récupération, ou appliquer des propositions acceptées.

L’utilisation du pilote par un livre se décide dans cet ordre :

1. le lancement lui-même ("autopilot": false dans POST /api/projects/{id}/jobs) ;
2. le choix propre au livre : onglet Réglages du livre › Pilote automatique (Activé, Désactivé : les décisions attendent une personne ou Réglage de l’installation) ;
3. le choix de l’installation : Paramètres › Pilote automatique › Lancer les livres en pilote automatique, ou la variable d’environnement AUTOPILOT_ENABLED (voir la configuration).

Les étapes d’un livre

1. Import. La source (EPUB, chapitres texte, Markdown, HTML, DOCX ou requête JSON) est découpée en passages, l’unité de chaque appel au modèle. Voir l’architecture (en anglais).

2. Analyse. Libris lit chaque passage pour construire les résumés de chapitres, les personnages, les relations et un état narratif, puis les consolide dans la Book Bible. Par défaut, les passages sont analysés côte à côte, puis chacun est réconcilié avec ce que les passages précédents ont établi (analyse parallèle (en anglais)) ; la traduction commence une fois tout le volume analysé. Sous le pilote automatique, un passage dont l’analyse est refusée ou revient sans cesse invalide est sauté pour l’instant, de même qu’un lot de Book Bible en échec ; les deux sont consignés. Un chapitre dont un lot a échoué reste à consolider (en mode parallèle aussi : une synthèse ou une fusion abandonnée ne compte plus sa section comme consolidée). Avant la traduction, le travail redemande les passages et les lots abandonnés, ainsi que les passages arrivés entre-temps — une fois sur son propre provider, puis une fois sur chacun de ses providers de secours (analysis_catch_up dans le journal des décisions). Ensuite, les termes de glossaire proposés, les liens d’identité de la série et la Book Bible sont tranchés (voir Décisions de mémoire) ; la Book Bible n’est validée que si aucune section ne reste à consolider. Enfin, quand la fiche de style du volume laisse des champs ouverts, un appel propose leurs valeurs à partir du livre (style_proposal, une fois par volume) et celles qui sont sûres sont appliquées (voir Décisions de mémoire). Sous autopilot, si l’analyse reste incomplète après ces nouvelles tentatives, le journal le signale et la traduction continue. Le rapport final indique le nombre d’analyses manquantes. Hors autopilot, les contrôles analysis_incomplete et analysis_unusable continuent de bloquer la traduction. Une traduction lancée seule (bouton Traduire, action groupée, MCP, API) analyse d’abord les passages qui n’en ont pas — chapitres ajoutés depuis l’analyse, copie pour une autre langue prise pendant l’analyse de l’original — avant d’en traduire un seul.

3. Traduction. Chaque passage est traduit, puis amélioré selon le niveau de qualité du livre (voir ci-dessous). Plusieurs passages d’un livre sont traduits en même temps, dans la limite de la capacité du provider et du réglage Passages traités en même temps du livre. Sous le pilote automatique, un plan de contexte facultatif qui échoue revient au contexte standard. Une relecture, une révision ou un polissage essaie les providers de secours puis conserve la traduction disponible si les réponses restent invalides. Une traduction en échec est confiée à l’échelle de récupération.

4. Tours de convergence. Au plus AUTOPILOT_MAX_ROUNDS tours (3 par défaut), chacun composé de :

   1. l’échelle de récupération pour chaque passage en échec ou non traduit ;
   2. au premier tour, en qualité haute ou maximale, une vérification de cohérence globale sur tout le livre ;
   3. la revue finale : le livre entier au premier tour (seulement les nouveaux chapitres quand le travail prend la suite d’un volume), puis seulement les passages encore ouverts et ceux récupérés pendant le tour ;
   4. l’arbitrage IA de tout ce qui reste ouvert.

   Chaque étape effectue ses tentatives avant la suivante. La boucle s’arrête dès qu’aucun passage n’est en échec ou ouvert ; après le dernier tour, les points encore ouverts restent visibles et sont signalés dans le rapport.

5. Clôture. Les passages impossibles à traduire gardent leur texte original et sont listés dans le rapport. Les points encore ouverts restent à vérifier dans le rapport final.

6. Export. Le livre peut être exporté (EPUB, texte, Markdown…) depuis l’interface, ou la requête de l’API construit son résultat et son rapport (voir le guide de l’API).

Les passages qu’une personne a corrigés ou validés ne sont jamais modifiés par aucune de ces étapes, même tant qu’ils sont encore marqués « à vérifier ». Le tour et la phase sont enregistrés au fil du travail : un travail mis en pause ou interrompu reprend là où il s’était arrêté, sans refaire ce qui est réglé.

Ce que fait chaque niveau de qualité

En qualité maximale, le polissage suit immédiatement la traduction : la relecture lit le texte poli et sa révision peut rétablir un sens que le polissage a changé. Un paragraphe poli qui a perdu plus d’un quart de ses mots (paragraphes de quatre mots ou plus) garde son texte précédent, et un polissage qui ajoute une erreur des contrôles automatiques (terme verrouillé perdu, texte resté dans l’écriture de la source) est refusé en entier. Chaque refus figure au journal des décisions (étape translation, polishing, rejected). Un passage dont la relecture avait déjà commencé lors de la mise à jour vers cet ordre est terminé sans polissage ; il n’est pas poli puis relu une seconde fois.

En qualité haute et maximale, le Mode de relecture du livre peut être Relecture et révision en un appel (REVIEW_MODE=fused pour l’installation) : un seul appel au modèle renvoie les problèmes et, si nécessaire, le texte corrigé, au lieu de deux appels. Cela ne s’applique qu’à la première relecture d’une traduction machine ; si l’appel ne tient pas dans la fenêtre du modèle ou échoue sans cesse, Libris revient aux deux appels séparés et consigne pourquoi.

L’échelle de récupération

Un passage que la traduction a abandonné gravit ces échelons, du moins coûteux au plus coûteux, jusqu’à ce que l’un d’eux fonctionne :

1. Nouvel essai informé. Le même provider est interrogé à nouveau, en lui disant pourquoi la réponse précédente a échoué.
2. Réparation par lots. Un passage de plusieurs paragraphes est traduit par groupes de quatre paragraphes, puis réassemblé.
3. Découpage en phrases. Chaque paragraphe est coupé aux limites de phrases, traduit morceau par morceau, puis réassemblé.
4. Contexte réduit. Seulement le passage, ses règles obligatoires (instructions, consigne du travail, fiche de style, glossaire verrouillé, identités confirmées, conventions de série) et une mémoire compacte de ce que le passage nomme (une fiche minimale de chaque personnage, avec ce qu’un lecteur a décidé, et le glossaire non verrouillé), sans voisins, contexte du livre ni mémoire récupérée. Sur une fenêtre étroite, la mémoire cède la première.
5. Le modèle supérieur. Le provider d’escalade du volume, sinon de sa série, sinon de l’installation : un nouvel essai informé, puis le découpage en phrases.
6. Providers de secours. Sur chaque provider de secours : un nouvel essai informé, puis le découpage en phrases. Un provider déjà sollicité en tant que modèle supérieur ne l’est pas à nouveau — cela ne ferait que dépenser deux fois.
7. Dernier recours. Une traduction existante est conservée. À défaut, quand des réponses n’ont été refusées que pour leurs termes verrouillés du glossaire, celle qui en manque le moins est conservée, soumise au contrôle de fidélité, marquée à vérifier et signalée (recovery_kept_translation) : un terme absent ne bloque pas le livre. Dans tous les autres cas, le texte original est gardé avec la liste des tentatives et signalé dans le rapport. Le travail poursuit les étapes suivantes.

Les échelons 5 et 6 sont dans cet ordre à dessein. Une réponse impossible à analyser, un refus, une traduction qui perd ses paragraphes : c’est un modèle qui échoue à faire le travail, et la réponse à cela est un meilleur modèle. Un provider qui ne répond pas du tout est en panne, et la réponse à cela est un autre provider. Prendre un remplaçant quand le premier modèle n’est simplement pas assez bon pour ce passage ne fait que produire le même échec ailleurs.

Chaque réponse passe par les vérifications habituelles (mêmes paragraphes, marqueurs intacts, glossaire verrouillé respecté). Chaque étape est bornée (un appel, ou un par groupe), et chaque résultat est consigné.

Conservé en original

« Conservé en original » (source_retained) apparaît quand tous les essais de traduction échouent ou quand une personne le choisit. Le texte source remplace alors la traduction :

• le passage porte un avertissement avec la raison, et apparaît dans l’onglet Pilote automatique du livre sous Passages conservés en original ;
• les rapports et résultats de l’API le comptent comme résiduel ;
• les exports écrivent son texte source.

Le pilote automatique conserve l’original si aucun modèle ne produit une traduction valide. Ce passage reste visible et peut être corrigé plus tard sans bloquer la suite du livre.

Resté dans la langue source

Un paragraphe de plus de cinq mots que le modèle rend mot pour mot dans la langue source (le contrôle unchanged), ou un texte resté dans l’écriture de la source (untranslated), est enregistré tel quel : un nom, une citation ou une ligne gardée en original à dessein sont légitimes, et la traduction n’est jamais refusée pour cela. Il n’est pas compté comme traduit pour autant. Tant que son alerte est ouverte et que le texte la mérite encore, l’arbitrage ne peut pas la clore sans changer le texte, et le passage est un résiduel comme un passage conservé en original : listé sous Passages conservés en original avec la raison du contrôle, compté par les rapports et les résultats de l’API (completed_with_residuals), et son chapitre n’est pas complete dans les exports texte. Traduire le passage, résoudre son alerte ou valider le passage règle la question.

Le modèle supérieur

Le provider réservé aux cas difficiles, et à eux seuls :

• un passage qui revient à l’arbitrage IA : un tour précédent du même travail l’a déjà arbitré et il a de nouveau des points ouverts (une réponse jamais valide, une erreur que son texte porte encore, une remarque sur sa correction). Son arbitrage suivant est confié au modèle supérieur ; un premier arbitrage revient toujours au modèle du livre ;
• un passage qu’aucun échelon de l’échelle de récupération n’a pu traduire avec le modèle du livre ;
• un passage sur lequel le modèle du livre a échoué cinq fois dans le travail (refus, réponses jamais valides, erreurs ; un appel interrompu par une pause ne compte pas) : ses appels suivants vont au modèle supérieur, deux au plus, puis le passage revient au modèle du livre. Les passages voisins ne le quittent jamais.

Aucune étape du livre ne bascule sur lui : traduction, analyse et relecture restent sur le modèle du livre, quoi qu’il échoue, si bien que le prix du modèle supérieur n’est payé que là où le modèle du livre a renoncé. Chaque recours est consigné (type escalation, action upgraded, avec le passage). Si le modèle supérieur est en panne, le passage revient au modèle du livre. Il est lu sur le volume (Réglages › Pilote automatique › Modèle supérieur), sinon sur sa série (Paramètres de la série › Quand un modèle échoue), sinon sur l’installation (Paramètres › Pilote automatique, AUTOPILOT_ESCALATION_PROVIDER) ; le changer vaut dès le passage suivant. Ce n’est jamais le provider déjà utilisé, et le désigner aussi comme provider de secours ne le fait pas essayer deux fois.

Providers de secours et pannes

Quand un provider cesse de répondre, Libris parcourt une chaîne de providers, dans cet ordre :

1. le provider qu’utilise le travail ;
2. le provider du livre ;
3. les providers de secours propres au livre (Réglages du livre › Pilote automatique › Providers de secours) ;
4. les providers de secours de l’installation (Paramètres › Pilote automatique, ou AUTOPILOT_FALLBACK_PROVIDERS, noms ou identifiants séparés par des virgules).

Une panne est d’abord attendue comme d’habitude, avec des délais croissants (voir Paramètres › Reprise automatique dans la configuration), au plus AUTOPILOT_OUTAGE_MAX_RETRIES fois (5) et AUTOPILOT_OUTAGE_MAX_WAIT_SECONDS au total (3600). Ensuite, ou immédiatement quand le provider refuse ses identifiants, le travail passe au provider suivant de la chaîne et le consigne. Le réglage de provider propre au livre n’est pas modifié.

Quand aucun provider de la chaîne ne répond, le travail se termine en échec avec la raison (stop_reason = providers_exhausted) : il n’attend jamais indéfiniment.

La même chaîne sert aux budgets de coût, avec ou sans le pilote automatique : quand la dépense d’un livre ou d’un jeton d’API atteint le seuil de bascule (BUDGET_SWITCH_THRESHOLD, 90 % par défaut), le travail passe au premier provider de la chaîne qui est moins cher que le sien (comparé sur un appel type de 14 000 jetons en entrée et 1 000 en sortie) et le consigne (étape budget, action fallback_provider, stop_reason = budget_fallback). S’il n’y a aucun provider moins cher au seuil, le travail se met en pause (stop_reason = budget_exceeded, action paused) ; un travail qui a déjà basculé une fois continue avec son nouveau provider jusqu’au plafond. Au plafond lui-même, seul un provider sans prix peut continuer ; sinon le travail se met en pause et reprend une fois le budget relevé.

Arbitrage IA

Les points ouverts sont ce qu’une personne arbitrait auparavant : les remarques des relecteurs, les doutes du modèle (incertitudes), les remarques de cohérence globale, les avertissements des vérifications automatiques, et tout autre problème non résolu sur le passage.

• Un seul appel au modèle par passage tranche tous ses points à la fois, et seuls les passages ayant des points ouverts sont envoyés, chacun avec sa gravité et, s’il en a un, son paragraphe. Le modèle renvoie une décision pour chaque point et uniquement les paragraphes qu’il modifie.
• Une remarque que rien n’étaye n’est pas envoyée : celle qui nomme un paragraphe que le passage n’a pas, celle qui cite, à l’appui d’un remplacement, des mots introuvables dans le passage, ou celle dont le remplacement est le texte déjà en place (« ? » remplacé par « ? »). Elle est close et inscrite au journal des décisions avec son motif, dans chaque relecture aussi (la relecture, le juge qualité, la relecture finale, le contrôle de cohérence). Une remarque sans remplacement reste un avertissement. Le modèle marque lui-même un point qu’il rejette parce que le contexte contredit son raisonnement.
• Une réponse n’est retenue que si elle tranche chaque point une fois, si chaque correction acceptée modifie le paragraphe qu’elle vise (seul un doute peut être tranché tel quel), si elle ne réécrit aucun paragraphe qu’aucun point accepté ne vise (sauf si l’un porte sur tout le passage), si aucun paragraphe corrigé n’a perdu plus de 40 % de son texte ni n’est devenu une consigne (« Remplacer X par Y »), et si le texte obtenu passe les mêmes vérifications qu’une traduction. Un terme verrouillé du glossaire ne fait refuser la réponse que si la correction le perd : un terme que le texte n’avait déjà pas ne fait pas refuser la correction d’un autre point.
• Une réponse qui ne remplit pas ces conditions après ses essais, comme un appel qui échoue (un refus, une erreur), ne tranche rien : les points restent ouverts pour le tour suivant, et le dernier tour les solde.
• Après l’arbitrage, les vérifications automatiques s’exécutent à nouveau sur le nouveau texte ; un avertissement déjà tranché n’est pas levé une seconde fois, mais une erreur que le texte porte encore (un terme verrouillé absent, un texte resté dans l’écriture de la source) l’est, tout comme un paragraphe encore identique à la source : écarter cette alerte ne tranche rien sur un texte qui n’a jamais été traduit.

La revue finale

La revue finale réexamine les passages traduits avec le contexte complet du livre, après la vérification de cohérence :

1. Elle réévalue le texte actuel (une remarque antérieure a peut-être déjà été corrigée).
2. Si un problème ou un doute subsiste, elle demande une version corrigée complète, en conservant les identifiants, les marqueurs et les termes verrouillés.
3. Elle vérifie cette correction par un second appel au modèle et par les vérifications automatiques.
4. Elle applique la correction quand elle laisse le passage en meilleur état : aucune nouvelle erreur des vérifications automatiques, et moins d’erreurs, ou autant d’erreurs et moins d’autres remarques. Ce que la seconde lecture signale encore reste sur le passage, toujours à vérifier. Une correction qui n’est pas meilleure est abandonnée et le texte reste tel qu’il était.

Chaque passage a droit à au plus un cycle de correction par revue. Les passages corrigés ou validés par une personne, et les passages conservés en original, ne sont jamais revus. Un refus ou une réponse invalide sur un passage déclenche un essai sur les providers de secours ; si toutes leurs réponses sont invalides, le passage reste non vérifié et le travail poursuit l’arbitrage. Quand la revue elle-même a répondu mais que sa correction échoue, le verdict est gardé : ses points restent ouverts sur le passage pour l’arbitrage, l’échec est journalisé, et la revue n’est pas repayée ailleurs. Un passage résolu quitte la file sans être marqué « validé par une personne ».

Sous le pilote automatique, la revue finale fait partie de chaque tour. Sans lui, une traduction du livre entier l’exécute une fois à la fin, et Journal des relectures › Lancer la revue IA l’exécute à la demande sur les passages encore à vérifier. FINAL_REVIEW_ENABLED=false désactive la revue automatique (le bouton fonctionne toujours), et une requête de l’API peut la sauter avec final_review: false.

Prendre la suite d’un volume

Quand de nouveaux chapitres sont ajoutés à un volume déjà traduit (un webnovel envoyé au fil du temps, par un import dans un volume existant ou par l’API d’automatisation), le travail ne couvre que les chapitres nouveaux ou remplacés et tout chapitre auquel il manque encore une traduction : la vérification de cohérence globale n’échantillonne que leurs occurrences, et la revue finale ne lit que leurs passages. Les chapitres déjà livrés ne sont ni retraduits ni revus ; ils fournissent leur contexte aux nouveaux.

Recherche web facultative (SearXNG)

Quand un administrateur configure une instance SearXNG (Paramètres › SearXNG, voir la configuration), la revue finale peut vérifier un terme ou une référence sur le web quand le modèle le demande :

• au plus deux recherches par passage, chacune d’au plus 200 caractères, trois résultats chacune, 15 secondes par appel ;
• les résultats (URL, titre, extrait) sont traités comme des indices non fiables, jamais comme des instructions, et aucune page de résultat n’est téléchargée ;
• les sources et l’explication sont conservées dans les événements du livre, et le contexte envoyé au modèle est visible dans les traces de requêtes ;
• une recherche qui échoue ne vaut pas confirmation.

Les termes recherchés sont envoyés à SearXNG et éventuellement à ses moteurs en amont : ne l’activez que si c’est acceptable pour vos livres, et uniquement vers une instance que vous contrôlez. L’instance SearXNG doit autoriser le format JSON (search.formats doit inclure json dans son settings.yml). Sans SearXNG, la revue s’appuie sur le livre, sa mémoire et le glossaire.

Décisions de mémoire

Sans aucun appel au modèle, à partir d’éléments déjà présents dans la base de données :

Les décisions qu’une personne a déjà prises ne sont jamais remises en cause. Un lien rejeté par le pilote automatique n’est pas proposé de nouveau quand la série est actualisée. La fiche de style est la seule ligne qui repose sur une réponse du modèle : la proposition demandée une fois à la fin de l’analyse (étape analysis, type style_sheet dans le journal des décisions) ; elle n’est pas redemandée pour le même volume, sauf par Proposer à partir du livre dans sa fiche de style.

Le journal des décisions et le rapport

Chaque décision est consignée avec son étape, son type, son action, sa raison, le provider et le modèle en cause, ainsi que le travail et le passage concernés. Dans l’interface, l’onglet Pilote automatique du livre affiche :

• le tour et la phase en cours pendant l’exécution d’un travail, et l’éventuel provider de secours utilisé ;
• le Rapport final de la dernière exécution : résultat, Tours de convergence, Passages conservés en original (chacun avec sa raison et des liens vers le passage et ses décisions), et le nombre de décisions consignées ;
• le Journal des décisions, les plus récentes d’abord, filtrable par étape et par passage.

Les mêmes données sont disponibles via GET /api/projects/{id}/autopilot?limit=50&offset=0 (filtres facultatifs job_id, segment_id, stage ; limit jusqu’à 500). La réponse indique si le pilote automatique est activé pour le livre, les limites en vigueur, le dernier rapport (avec son job_id, son status et son finished_at) et les décisions, les plus récentes d’abord.

Le rapport enregistré sur le travail ressemble à ceci :

{
  "outcome": "completed",
  "rounds": 2,
  "residuals": [],
  "reason": null,
  "quality": {"scored": 411, "average": 91.4, "minimum": 40, "to_review": 6, "review_below": 70,
              "bands": {"good": 380, "fair": 25, "weak": 5, "poor": 1}, "histogram": [0, 0, 0, 0, 1, 2, 3, 10, 35, 360]}
}

blocked indique que les tours bornés sont épuisés alors qu’un passage reste dans la langue d’origine, qu’un point bloquant reste ouvert ou qu’un contrôle n’a pas conclu : le livre n’est pas prêt à exporter, et source_passages, unresolved_passages et unverified_checks en donnent les nombres exacts. Un point est bloquant quand c’est une erreur d’un contrôle automatique (texte resté dans la langue d’origine), ou une erreur du relecteur qui change ce que dit le livre (contresens, omission, ajout, texte non traduit, terme verrouillé) que l’arbitre a retenue et dont la correction n’a pas pu être appliquée. Tout le reste (style, registre, grammaire, point qu’aucun arbitre n’a confirmé) est un point de détail : il est corrigé dans le tour qui le trouve, ne vaut jamais un tour de plus, et ce qu’il en reste est clos sur le texte actuel et listé dans residual_points. La catégorie est lue quel que soit le nom que lui donne le relecteur (Mistraduction, sens, contresens sont un contresens, terminologie est la terminologie), et une erreur dans une catégorie que Libris ne connaît pas est bloquante, avec une ligne au journal, au lieu d’être exportée comme un détail. Une erreur retenue ne bloque pas non plus dans un cas : quand le contrôle de fidélité a refusé la réécriture de ce même paragraphe par l’arbitre lors de deux tours distincts, en citant chaque fois la source en faveur du texte en place, et qu’aucun autre motif n’a jamais écarté la correction, le point est contesté et non établi. Il est clos sur le texte en place et listé dans residual_points avec "motive": "contested_by_fidelity" ("open_points" pour les autres). Un seul refus de ce genre, ou un refus mêlé à un autre motif, bloque toujours. Un terme verrouillé du glossaire encore absent du texte est une erreur qui vaut au passage tous les tours restants, et ne bloque plus le livre une fois ces tours épuisés : aucune réponse ne l’a satisfait, le passage est donc clos sur son texte et listé dans residual_points avec "motive": "locked_term_unmet" et le terme (source → traduction attendue). Son alerte reste ouverte dans la page Qualité tant que le texte n’a pas le terme ou que vous n’avez pas modifié le verrou. À partir de sa deuxième lecture d’un passage, la relecture ne garde un point nouveau que sur un paragraphe dont le texte a changé. completed_with_residuals indique seulement de tels points de détail, une analyse, une section ou une décision de série manquante. Une requête de l’API se termine toujours en completed_with_residuals dans ces deux cas. Seule une indisponibilité du modèle peut interrompre la progression automatique des étapes. Un rapport blocked est recompté à chaque lecture : une fois les passages listés corrigés ou validés, la fiche du livre affiche le nouveau résultat et le menu Exporter propose de nouveau l’EPUB traduit, sans nouveau passage. quality résume les scores de qualité des passages (en anglais) une fois l’exécution réglée : les étapes de récupération et les arbitrages rejetés ou reportés abaissent le score (une correction appliquée, non) d’un passage, si bien que l’onglet Qualité du livre liste en premier les passages qui ont donné le plus de mal au pilote automatique.

Coût

Le rapport de la dernière exécution (GET /api/projects/{id}/autopilot) et le rapport d’achèvement d’une requête d’automatisation contiennent cost : l’estimation faite au démarrage du travail comparée à son coût réel, avec le budget du livre et les bascules de budget (voir la référence de l’API).

Le pilote automatique ne dépense des appels que là où quelque chose ne va pas. L’échelle de récupération ne concerne que les passages en échec ; l’arbitrage fait un appel par passage ayant des points ouverts ; les tours suivants ne relisent que les passages encore ouverts ou tout juste récupérés. Les décisions de mémoire ne font aucun appel.

Réglages

Les administrateurs règlent le comportement de l’installation dans Paramètres › Pilote automatique. Les valeurs qui y sont enregistrées s’appliquent dès la décision suivante, sans redémarrage, et l’emportent sur les variables d’environnement jusqu’à ce que vous choisissiez Revenir aux valeurs de l’environnement (voir les réglages modifiés dans l’interface).

La couverture minimale de l’analyse avant de traduire (ANALYSIS_MIN_COVERAGE, 1) ne figure pas sur cet écran : elle se règle uniquement par sa variable d’environnement (voir la configuration).

Chaque livre peut remplacer l’interrupteur marche/arrêt et ajouter ses propres providers de secours dans son onglet Réglages. Les mêmes réglages du livre sont disponibles sous config.autopilot et config.fallback_provider_ids dans PUT /api/projects/{id}.

Sans le pilote automatique

Désactivez le pilote automatique pour un livre (ou pour l’installation) quand vous voulez prendre les décisions vous-même. Le pipeline se comporte alors ainsi :

• Réponses invalides. Une réponse rejetée par les vérifications (paragraphes manquants, marqueurs cassés, glossaire verrouillé non respecté, JSON invalide) est redemandée avec la raison, jusqu’à trois fois ; les erreurs réseau ont droit à jusqu’à cinq tentatives. Une réponse qui n’est pas du tout du JSON est reconnue comme telle : de la prose est redemandée sous la forme du seul objet JSON, un objet coupé au budget de sortie est redemandé plus court, et une clé que Libris n’a pas demandée est simplement ignorée au lieu de faire perdre la réponse. Une traduction ou une révision qui échoue encore est alors réparée par groupes de quatre paragraphes (passages de 2 à 128 paragraphes), chaque groupe conservant son contexte, ses identifiants et ses marqueurs. Les groupes déjà réparés sont réutilisés après une interruption, et seul le résultat complet et validé remplace la traduction du passage.
• Refus. Un refus de contenu est retenté une fois ; après le second refus, le passage est marqué refusé. Un refus pendant l’analyse bloque le travail jusqu’à ce que vous interveniez.
• Passages en échec. Un passage qui échoue encore après ses tentatives garde son texte existant, est signalé en erreur (ou refusé) dans Qualité, et le travail passe au passage suivant. Dix passages en échec d’affilée arrêtent un travail lancé avec Traduire (un passage réussi remet le compteur à zéro, et la reprise aussi) ; un pipeline lancé depuis l’assistant d’import ne s’arrête pas.
• Améliorations en échec. Un polissage, une relecture ou une révision dont les réponses restent invalides après leurs tentatives et leur réparation (qui perd sans cesse un terme verrouillé, par exemple) est abandonné : la traduction valide déjà enregistrée reste, le passage se termine et porte l’avertissement « Étape non appliquée après des réponses invalides du modèle », tandis que le journal des décisions garde la raison. Une panne du provider ou un refus pendant ces étapes arrête toujours le passage comme ci-dessus.
• Récupération automatique. Un pipeline lancé depuis l’assistant d’import retente une fois de plus ses passages en échec et non traduits après la traduction. Ce qui reste ensuite vous attend.
• Bilan & récupération. Cet onglet distingue l’état du dernier travail de la couverture réelle du livre : passages traduits, manquants, conservés en original, ouverts, alertes non résolues et choix humains protégés. Filtrez les passages à récupérer (erreurs, refus, non commencés, bloqués), sélectionnez-en jusqu’à 200, choisissez un Provider de récupération puis Relancer la sélection. Le serveur vérifie la sélection et saute les passages protégés ; un autre travail sur le livre doit d’abord se terminer ou être annulé. Le provider propre au livre ne change pas.
• Les pannes de provider sont attendues avec des délais croissants aussi longtemps que nécessaire, et un provider qui refuse ses identifiants bloque le travail jusqu’à ce que vous le corrigiez et repreniez.
• Les points ouverts attendent dans le Journal des relectures. Chaque remarque de l’IA montre son doute et la correction proposée. Accepter cette proposition ne remplace que le paragraphe concerné et conserve les marqueurs EPUB ; Refuser cette proposition conserve le texte actuel. Les deux créent une correction humaine protégée ; une fois la dernière proposition d’un passage tranchée et plus rien d’ouvert, le passage quitte la file. La file reste stable pendant l’exécution des travaux, si bien que les brouillons ne sont pas perdus. La validation éditoriale finale reste une action distincte. Quand vous acceptez une suggestion libre qui n’a pas conservé les marqueurs internes, Libris demande au provider du livre une correction structurée de ce seul paragraphe, la vérifie comme une traduction (marqueurs, et glossaire verrouillé du livre, de sa série et des glossaires partagés : une réponse qui perd un terme verrouillé que le paragraphe avait est redemandée), et conserve le texte actuel si la réponse reste invalide ou si le passage a changé entre-temps. Ce texte est celui du modèle, que personne n’a encore lu : sur un passage machine, il est enregistré comme texte machine (origine accepted_proposal), que les contrôles, la revue finale et l’arbitrage examinent encore, et non comme une correction humaine protégée ; un passage que vous aviez déjà corrigé reste le vôtre. Il n’est jamais validé.
• Un passage refusé ou en échec peut être résolu dans l’éditeur de trois façons : saisir une traduction humaine ; donner une Analyse humaine (un résumé utile à la continuité) dans l’inspecteur ; ou choisir Conserver l’original pour l’export. Conserver l’original ne remplace pas une analyse manquante. Quand la synthèse de la Book Bible elle-même est refusée, valider une Book Bible humaine avec un résumé non vide permet au travail de reprendre. Un travail arrêté en analysis_unusable ou analysis_incomplete se relance de la même façon : corrigez ce qui a fait mal répondre le modèle, puis Reprendre le travail (ou relancez l’analyse). La reprise redemande ce qui avait été abandonné — les passages restés sans analyse, les lots de Book Bible en échec — et reconstruit une Book Bible qu’aucune exécution n’a réussi à écrire, chapitres déjà marqués consolidés compris ; les passages déjà analysés sont conservés, et la traduction suit une fois la mémoire en place.
• Exports. Un export EPUB normal exige une traduction complète. EPUB partiel · originaux conservés met le texte source là où la traduction manque, sous un nom de fichier distinct. Le Rapport de couverture liste les passages sans analyse, sans traduction et conservés en original ; un original conservé n’est jamais présenté comme une traduction validée.

Quand un travail s’arrête

Le worker vérifie son bail toutes les deux secondes, si bien qu’une pause ou une annulation interrompt presque aussitôt tous les appels en cours pour le livre. Chaque écriture est protégée par la révision du passage et par le détenteur du bail : une réponse tardive ne remplace jamais une correction humaine ni un état annulé. Les passages déjà terminés sont sautés à la reprise du travail, et les passages interrompus redémarrent à leur dernière étape enregistrée.

EPUBCheck s’exécute toujours au moment de l’export : une couverture complète ne certifie pas un EPUB valide, et une relecture par un modèle ne garantit pas la fidélité littéraire.