Claude par lots : chaque résultat dans le bon dossier

Quatre demandes partent dans un traitement IA nocturne. Au matin, le lot est terminé et son fichier contient quatre lignes. L’import semble complet, mais le montant de 900 euros appartient au troisième dossier et se retrouve sur le premier. Le total global reste juste : cette erreur de rattachement peut donc survivre à un contrôle comptable superficiel.

La réception doit couvrir l’identité de chaque demande, son résultat technique et son admissibilité métier. Un lot terminé n’est pas un lot entièrement réussi. Une réponse produite n’est pas automatiquement complète, fidèle ou encore applicable au dossier qui l’attend. Ces distinctions doivent précéder tout transfert vers le système d’information.

Nous prenons le cas de Claude Message Batches, dont les résultats ne sont pas garantis dans l’ordre d’envoi. Quatre demandes fictives, deux montants et des échecs contrôlés rendent le problème reproductible. Le programme local vérifie les vingt-quatre permutations du fichier ; il n’appelle aucun modèle et ne mesure aucune précision d’extraction.

Notre accompagnement en IA et automatisation relie les sorties du modèle aux étapes du processus. L’intégration de l’IA au système d’information doit conserver cette chaîne de preuves afin qu’un gain de débit ne transforme pas une réponse plausible en donnée attribuée au mauvais objet métier.

Pour qui un traitement IA par lots devient utile

Choisir des demandes indépendantes qui peuvent attendre

Le lot convient à une préparation documentaire, une classification ou une évaluation dont les résultats ne sont pas exigés pendant une conversation immédiate. Chaque demande doit posséder son propre contexte et sa destination. Le volume n’est pas suffisant pour justifier le choix : l’équipe doit aussi accepter l’attente et disposer d’un circuit pour les résultats non exploitables.

Un service qui doit confirmer immédiatement une disponibilité ou répondre dans une interface synchrone a besoin d’un autre contrat de délai. De même, si le résultat B dépend du résultat A, leur présence dans un même fichier ne crée pas cette dépendance. L’orchestration doit organiser les étapes et leurs validations explicitement.

Qualifier la sortie avant de parler de productivité

Pour notre recette, l’IA prépare un montant proposé à la revue d’un gestionnaire. Elle ne crée ni facture ni paiement. Cette limite permet de séparer production d’une candidature, contrôle de ses preuves et décision métier. Le même rapprochement d’identités restera nécessaire si une automatisation plus poussée est autorisée ultérieurement.

Le coût utile inclut préparation des pièces, appels, réception, vérification et reprise humaine. Une baisse du coût technique par requête peut être annulée par des dossiers croisés ou difficiles à retrouver. Le pilote doit donc compter les dossiers correctement reçus et les reprises, pas seulement les requêtes qui quittent la file.

Distinguer fin du lot et résultat de chaque demande

Lire l’état collectif sans en déduire quatre réussites

La référence des objets Message Batch distingue l’état de traitement du lot et les compteurs de demandes. La fin peut réunir des demandes réussies, en erreur, annulées ou expirées. Le statut ended indique donc une fin de traitement, pas l’acceptation métier de toutes les entrées.

Dans le cas fictif, deux demandes réussissent techniquement, une est en erreur et une expire. Les quatre objets ont une issue, mais seuls deux peuvent devenir candidats à la revue de contenu. L’écran opérateur doit montrer cette répartition : un grand indicateur « terminé » seul masque le travail restant.

Prévoir l’annulation partielle et les limites de délai

La documentation du traitement par lots décrit des demandes traitées indépendamment, un traitement asynchrone et une expiration après vingt-quatre heures si le traitement n’a pas abouti. Une annulation passe par un état intermédiaire et peut laisser des résultats déjà produits. Elle ne signifie pas que rien ne s’est passé.

L’exploitation doit donc recevoir les résultats disponibles avant de décider de la suite. Elle conserve les demandes annulées séparément des erreurs et des expirations. Une reprise doit rester une nouvelle décision, avec motif et périmètre, plutôt qu’un renvoi automatique de l’ensemble du fichier initial.

Construire le manifeste qui connaît les dossiers

Attribuer les identifiants depuis le système appelant

Avant l’envoi, le service construit un registre associant l’identifiant de requête, le dossier, la révision documentaire, la tâche et les paramètres utiles. Cet objet reste sous son contrôle. Le modèle n’a pas à choisir le dossier de destination en écrivant son nom dans une réponse ; le rapprochement s’appuie sur l’identité fournie à l’envoi.

Notre manifeste local associe r01 à D101, révision 3, référence DEV-11 ; r02 à D102, révision 1 ; r03 à D103, révision 2 ; r04 à D104, révision 4. Les identifiants sont fictifs et opaques. Il n’est pas nécessaire d’inscrire un nom de client ou un contenu documentaire dans une clé technique de corrélation.

Conserver le lot et la version du contrat

La clé d’import doit également identifier le lot reçu. Un même identifiant court peut exister dans une autre opération locale ; un fichier rattaché au mauvais lot ne doit pas traverser le contrôleur. Le registre conserve aussi le modèle demandé, le prompt, le schéma de sortie et leurs versions afin de pouvoir comprendre les conditions de production du résultat. Cette trace d’inférence conserve les paramètres nécessaires à la comparaison, tandis que les permissions de lecture et de promotion restent définies par les services applicatifs.

La traçabilité rapproche l’intention, les paramètres envoyés et l’identifiant distant retourné. Elle ne doit pas conserver les secrets d’authentification dans les journaux. Pour un usage multi-tenant, le contexte d’organisation et les droits sur les pièces restent imposés par l’application, indépendamment de ce que le contenu de la réponse affirme.

Rapprocher les résultats par identité, jamais par position

Appliquer le contrat custom_id

La référence de récupération des résultats indique un flux JSONL : chaque ligne porte le résultat d’une demande. L’ordre peut différer de celui des requêtes. Le champ custom_id sert à retrouver la demande correspondante ; la première ligne ne doit pas être attribuée au premier dossier par convention.

Le rapprochement exige une recherche dans le manifeste, puis un contrôle d’unicité. Une clé inconnue ou répétée bloque la réception du lot dans notre politique locale. Le programme ne garde pas silencieusement la dernière occurrence, car cela effacerait précisément l’anomalie qui rend le fichier indécidable.

Cas concret : ajouter une seconde occurrence de r03 donne cinq lignes pour quatre demandes, même si les deux occurrences portent 900 euros. Dès le premier doublon, la réception renvoie unknown_or_duplicate_id et ne promeut aucun candidat. Accepter les deux parce que leurs montants concordent empêcherait de détecter le même défaut lorsque leurs valeurs divergent.

Montrer pourquoi un total correct reste insuffisant

Le fichier fictif présente d’abord r03 avec 900 euros, puis r01 avec 120 euros, puis l’expiration de r04 et l’erreur de r02. Le résultat attendu est donc D103 à 900 euros et D101 à 120 euros. En associant les deux réussites à une liste de dossiers triée D101, D103, l’import inverse les montants.

La somme reste 1 020 euros dans les deux cas. Un rapprochement uniquement global ne détecte pas l’inversion. Paradoxalement, obtenir le bon total peut conforter une mauvaise affectation. La preuve doit conserver la relation entre résultat et dossier, puis vérifier la valeur au sein de cette relation.

Recevoir le fichier entier avant de le promouvoir

Comparer identifiants attendus, lignes reçues et compteurs

Un téléchargement interrompu peut produire un fichier dont les premières lignes sont parfaitement lisibles. Le parseur doit vérifier la fin de lecture, puis comparer les identifiants reçus à ceux du manifeste. Quatre demandes attendues et trois résultats valides ne constituent pas un lot reçu. Le manque doit être explicite et empêcher la promotion selon la politique choisie.

Par exemple, si le fichier contient r03, r01 et r04 mais pas r02, alors le contrôleur reçoit trois identifiants sur quatre attendus et refuse la réception par missing_id. Le seuil de complétude est ici de 4 sur 4, y compris les demandes en échec. Une ligne d’erreur est un résultat à recevoir, pas une ligne facultative que l’import peut oublier.

Le contrôle recalcule ensuite les états depuis les lignes et les compare aux compteurs annoncés pour le lot terminé. Cette réconciliation détecte une troncature ou une mauvaise association de fichiers. Elle ne prouve pas l’authenticité d’un fichier arbitraire : sa provenance dépend toujours de la récupération maîtrisée et de la chaîne de stockage.

Conserver une zone de réception distincte de la destination métier

Les lignes sont d’abord reçues dans une zone de staging. Une fois la structure complète et les identités rapprochées, une décision peut promouvoir les candidats vers une file de revue. Cette séparation évite d’écrire les deux premières lignes dans le CRM avant de découvrir une anomalie sur la troisième.

Les entrées de la réception comprennent lot attendu, manifeste et flux ; les sorties comprennent statut de réception, anomalies et candidats identifiés. La responsabilité de la journalisation, le seuil de complétude et le repli après interruption sont écrits dans le runbook. Le choix de bloquer tout le lot est ici explicite ; une promotion partielle exigerait un contrat supplémentaire.

Contrôler la réponse après la réussite technique

Lire la raison d’arrêt avant de consommer le contenu

Anthropic distingue la réussite d’une requête de sa raison d’arrêt de génération. Une réponse peut notamment atteindre max_tokens. Le simple statut de réussite ne démontre donc pas que le contenu attendu a été entièrement produit ou qu’il est prêt à alimenter un traitement documentaire.

Notre adaptateur n’accepte comme candidat qu’un résultat dont la raison d’arrêt est end_turn, puis contrôle sa forme. Ce choix est une règle locale de cette extraction simple, sans appel d’outil. Il ne signifie pas que toutes les autres raisons sont des erreurs universelles : d’autres usages demandent une continuation ou un traitement spécifique.

Vérifier le contexte et la forme sans inventer une fidélité sémantique

La réponse candidate doit porter la référence fournisseur attendue et un montant entier en centimes. Le contrôleur refuse une référence étrangère, un booléen, une chaîne numérique ou un montant négatif. Il ne convertit pas automatiquement « 120.00 » parce que cette valeur ressemble à un prix. Le schéma de sortie doit être qualifié avant de recevoir un lot.

Ces vérifications ne démontrent pas que 120 euros figurent dans la pièce. Une hallucination peut respecter le schéma et reprendre la bonne référence. La revue des preuves documentaires, des citations ou des champs extraits reste donc une étape distincte. Aucun candidat de notre exercice ne constitue une autorisation d’écriture ERP.

Exécuter les permutations et les témoins qui doivent échouer

Un exercice local sans appel de modèle

Le programme Python de rapprochement fournit un manifeste fixe et quatre résultats rédigés pour la recette. Il emploie un format d’adaptation simplifié : raison d’arrêt et données utiles sont déjà extraites du message, et les compteurs retiennent les quatre issues terminales. Il ne prétend pas parser toute la réponse Claude ni télécharger un fichier distant.

python3 rapprocher_lot.py
45 contrôles réussis ; 24 permutations
3 témoins insuffisants détectés
Aucun modèle ni ERP appelé.

D101 : candidat, 120 EUR
D102 : erreur
D103 : candidat, 900 EUR
D104 : expiration

Les vingt-quatre permutations des quatre résultats produisent la même affectation. Le témoin par position inverse 120 et 900 euros tout en conservant 1 020 euros au total. Les autres témoins montrent qu’un lot terminé ne donne que deux candidats, et qu’une réussite arrêtée par limite de génération reste incomplète pour notre contrat.

Des refus qui expliquent la prochaine action

La recette retire une ligne, répète un identifiant, introduit une clé inconnue et mélange le lot attendu avec un autre. Elle vérifie aussi les états non terminés et les compteurs incohérents. Ces cas doivent bloquer la réception plutôt que fabriquer un dossier vide ou ignorer l’anomalie.

Le contrôleur examine ensuite les révisions courantes : D101 passé de la révision 3 à la révision 4 n’accepte plus automatiquement la proposition préparée sur l’ancienne pièce. Les erreurs de type et de référence donnent un motif de refus distinct. Le test ne certifie aucune gestion distribuée des droits ou des transactions ; il établit les décisions locales observées.

Préparer une reprise qui ne remplace pas les bons résultats

Créer une nouvelle tentative seulement pour les demandes qualifiées

D102 en erreur et D104 expiré ne doivent pas conduire à recalculer par défaut D101 et D103. La reprise commence par un examen du motif : paramètres invalides, délai dépassé, pièce remplacée ou génération incomplète n’appellent pas la même correction. Réenvoyer une entrée inchangée peut reproduire exactement le défaut.

Une nouvelle tentative reçoit son identifiant et conserve un lien vers la demande précédente. L’historique distingue le résultat original, la cause de reprise et la version finalement retenue. Si les deux résultats arrivent, une règle de sélection explicite choisit lequel peut être proposé à la revue ; le dernier arrivé ne gagne pas automatiquement.

Recevoir à nouveau n’est pas exécuter à nouveau

La référence de lecture d’un Message Batch prévoit la consultation de son état pour suivre sa fin de traitement. Cette lecture ne doit pas être confondue avec une nouvelle soumission au modèle, ni avec l’application du résultat dans un logiciel métier. Ces trois opérations ont des effets et des coûts différents.

En production, l’import en staging doit disposer de clés d’unicité et d’une reprise après interruption. L’étape qui écrit dans l’ERP doit avoir son propre contrat d’idempotence, d’autorisation et de preuve d’effet. Le présent exercice ne l’exécute pas : un rapprochement correct prépare cette frontière sans prétendre la remplacer.

Erreurs fréquentes dans les imports de résultats IA

Effacer les anomalies pour obtenir un tableau complet

Indexer les lignes par identifiant dans un dictionnaire sans vérifier les répétitions peut masquer un doublon. Remplacer une demande absente par un objet vide peut masquer un téléchargement incomplet. Et filtrer les erreurs avant de rapprocher les dossiers peut décaler toutes les affectations suivantes si une jointure par position subsiste.

Le signal faible est une somme correcte accompagnée de corrections manuelles sur les destinataires. Un autre est un taux de réussite différent entre le fournisseur et la file métier, sans explication par les contrôles de contenu. L’équipe doit pouvoir reconstruire chaque passage : attendu, reçu, techniquement réussi, candidat, revu et éventuellement appliqué.

Promouvoir les sorties malgré une pièce ou un contrat remplacé

Une réponse tardive peut être valide pour le contexte qui l’a produite et inutilisable aujourd’hui. Le document peut avoir changé, une demande avoir été annulée ou le schéma métier avoir évolué. Le résultat reste archivable comme observation, mais son application nécessite de vérifier l’état courant et les règles de la tâche.

Le mauvais repli consiste à réutiliser la dernière valeur disponible dès qu’une nouvelle tentative échoue. Il confond continuité du service et validité du contexte. Le mode dégradé doit plutôt exposer le dossier en attente, sa cause et l’action possible, avec une reprise humaine lorsque le délai métier ne permet plus d’attendre.

Plan d’action : livrer un import dont chaque ligne est explicable

Définir une réception sur une petite population contrôlée

Commencez avec quelques dossiers dont les pièces et les versions sont connues. Le responsable métier définit ce qu’un candidat peut préparer et ce qui nécessite une revue. Le développeur d’intégration établit le manifeste et les clés de corrélation ; l’équipe IA fixe prompt, modèle, schéma et règles de sortie. La QA prépare des résultats contradictoires avant d’élargir le volume.

Conservez deux jeux : un résultat nominal, puis des variantes qui inversent l’ordre, retirent une ligne ou changent une identité. Chaque variante possède un verdict attendu. Les observations doivent être attribuables à la version du contrôleur, afin qu’une modification de l’import ne rende pas les anciens résultats de test impossibles à interpréter.

Instrumenter les transitions et la reprise réelle

Le contrat de supervision relie les entrées envoyées, les résultats reçus et les sorties proposées à la revue. Les journaux exposent les identifiants techniques nécessaires, les états et les motifs, sans copier tout le document. Le responsable d’exploitation suit l’âge des demandes, le taux d’erreur de réception et le nombre de dossiers dont la révision a changé.

Le runbook décrit un téléchargement interrompu, un fichier associé au mauvais lot, une réponse tronquée et une demande expirée. Les dépendances incluent stockage du manifeste, accès au fournisseur, parseur et file de revue. Le seuil bloquant porte ici sur toute identité inconnue ou dupliquée ; le repli garde les résultats en staging et interdit leur promotion tant que l’écart reste inexpliqué.

• Valider le pilote si chaque résultat retrouve son dossier, si les compteurs concordent et si les candidats passent les contrôles de contexte.
• Différer l’extension si le coût de reprise ou le délai réel n’est pas encore mesuré sur une population représentative.
• Refuser la livraison si une inversion d’ordre, une pièce remplacée ou un échec technique peut alimenter silencieusement le mauvais dossier.

Mesurer le travail reçu plutôt que la seule capacité d’envoi

Après le premier lot, rapprochez coût technique, dossiers candidats, dossiers relus et corrections humaines. Les quatre demandes de l’exemple ne constituent pas un échantillon de précision d’un modèle. Elles prouvent seulement que le contrôleur local distingue plusieurs états qui seraient confondus par un import naïf.

L’ouverture suivante ajoute une famille documentaire ou un contexte métier maîtrisé. Les exceptions découvertes enrichissent le jeu d’évaluation et la procédure de support. Une nouvelle version de prompt ou de modèle demande une comparaison du contenu ; une nouvelle version d’import demande aussi le rejeu des permutations et des anomalies d’identité. Le score de génération ne remplace pas la recette de la chaîne de réception.

Compléter la réception par la preuve documentaire et la preuve d’effet

Garder les champs inconnus et les reprises visibles

Le dossier sur l’extraction IA des champs absents traite la fidélité de la proposition à sa pièce. Il prolonge le rapprochement : avoir reçu le résultat de D101 ne signifie pas que tous les champs qu’il contient sont soutenus par le document de D101.

La méthode de reprise d’un workflow après panne examine la frontière suivante, lorsque l’action a pu être appliquée sans que son accusé soit conservé. Elle évite d’étendre abusivement une garantie de réception à l’exécution dans le système cible.

Lire les contrats du fournisseur et ceux de l’application séparément

Les sources Claude définissent le transport asynchrone, les identifiants, les états et les raisons d’arrêt. Le manifeste métier, les révisions, les refus de promotion et les décisions humaines appartiennent à l’application. Une intégration maintenable conserve les deux niveaux au lieu d’attribuer au fournisseur une garantie qu’il ne décrit pas.

Le choix d’un autre fournisseur exige de relire ses propres contrats. Le principe de corrélation reste utile, mais les champs, délais, états et règles de récupération ne doivent pas être copiés à l’identique. La recette doit être rejouée sur l’adaptateur effectivement livré, avec ses réponses réelles et des données autorisées.

Conclusion : un résultat n’est utile que dans le bon dossier

Un traitement IA par lots ne se termine pas lorsque son état devient terminal. Il faut encore rapprocher chaque réponse, constater les manques et distinguer la réussite technique d’une proposition utilisable. L’ordre des lignes ne peut pas tenir lieu d’identité.

Les quatre demandes fictives montrent pourquoi 1 020 euros au total ne garantit aucune bonne affectation. Les permutations, doublons, erreurs, expirations et révisions modifiées produisent des décisions différentes. Les quarante-cinq contrôles locaux préparent la recette ; ils ne mesurent ni Claude ni une écriture métier réelle.

L’intégration de l’IA au système d’information doit organiser ces transitions avec des clés stables, une réception contrôlée et des reprises compréhensibles par l’exploitation.

Dawap vous accompagne en IA et automatisation pour construire cette chaîne, depuis les demandes préparées jusqu’aux résultats recevables par vos équipes. Nous vérifions ensemble les contrats, les exceptions et les preuves nécessaires avant d’autoriser l’étape métier suivante.