Page 03 / 08 · Chaîne de traitement

Six étapes, aucune intervention manuelle

Entre l’entrée et le système cible se trouvent six étapes. Chacune transmet son état à la suivante, chacune laisse une entrée de journal — et aucune ne demande d’intervention. Ce qui échoue ne bloque pas le reste du lot.

01

Examiner l’entrée et réserver les documents

Le flux examine le canal d’entrée et prend au maximum cinq documents par passage. Chacun est réservé pendant 60 secondes via un Blob Lease — c’est le régulateur automatique du trafic : deux exécutions parallèles ne saisissent jamais le même document, et si une exécution s’arrête, le document se libère de lui-même à l’expiration.

Taille du lot 5 Lease 60 s, prolongeable réservé → ignoré, pas interrompu
02

Classer, séparer, étiqueter CLASSIFIER

Seules les premières pages sont envoyées au classificateur. Pour chaque sous-document reconnu, ses pages sont écrites comme PDF distinct dans le conteneur de sortie — dans un chemin composé du nom du classificateur et du type de document — et enrichies de deux métadonnées : la catégorie reconnue et sa confiance. En cas de succès, la source est libérée et supprimée ; le lease est prolongé activement pendant ce temps, car la classification peut durer plus longtemps que sa limite.

Chemin de dépôt
<Dossier de sortie> / <Modèle de classificateur> / <Type de document> / <Fichier>.pdf
Métadonnées Blob
AnalysedCategory = type de document · CategoryConfidence = 0.00–1.00
03

Trouver le modèle RECOGNIZER

L’extraction trouve son modèle elle-même : à partir du chemin de dépôt, elle lit le nom du classificateur, et à partir des métadonnées Blob, le type de document — puis choisit exactement le modèle de reconnaissance configuré pour cette combinaison. Cette prise en charge est le véritable point de transfert entre les modules et fait l’objet de la page 06. Ce qui se passe lorsqu’aucun modèle n’existe pour le type de document reconnu est expliqué sur Modèle manquant.

04

Analyser et mapper vers les champs cibles

Le document est envoyé au moteur du modèle — extraction de champs entraînée classiquement ou analyseur autorisé par NexoGraph Document Processing. Les champs et cellules de tableau sont mappés vers les noms de champs cibles configurés et enregistrés comme jeu de résultats ; le JSON brut et l’original vont dans le conteneur d’analyse. Un hash de contenu par document sert de frein à la redondance : si le même contenu réapparaît, le résultat enregistré est réutilisé au lieu d’être analysé à nouveau.

Document Intelligence NexoGraph Document Processing Déduplication par hash de contenu
05

Distribuer à toutes les cibles

Le résultat est envoyé simultanément à tous les adaptateurs de point de terminaison enregistrés — gestion documentaire et autant de cibles REST que souhaité, à égalité. Les cibles non configurées signalent proprement « ignoré », les erreurs attendues signalent « échoué » ; aucune ne fait basculer le flux. Chaque adaptateur écrit sa propre étape de journal.

06

Clore — ou laisser de manière répétable

Le document et le JSON d’analyse vont dans final/ — mais seulement si aucune cible marquée comme obligatoire n’a échoué. Sinon, tout reste en place et peut être rejoué via POST /RetryEndpoint sans nouvelle analyse. La décision de dépôt est prise par le flux, pas par un adaptateur individuel.

Ce qui n’arrête pas le flux
check_circle
Un document défectueux reçoit un état final de journal — le lot continue.
check_circle
Un document déjà réservé est ignoré, pas traité comme une erreur.
check_circle
Un lot vide reste visible : il est consigné comme une entrée de journal distincte, au lieu de se terminer sans commentaire.
check_circle
Même une panne du journal n’arrête pas le traitement — elle est consignée, pas escaladée.