Batch processing : définition, avantages et erreurs partielles
Le batch processing consiste à traiter un groupe de demandes sans attendre une réponse interactive pour chaque élément. La documentation OpenAI présente son Batch API comme un moyen d’envoyer des groupes de requêtes asynchrones avec un délai de traitement annoncé et des limites séparées. C’est utile quand la latence immédiate n’est pas prioritaire.
Quand l’utiliser
Import massif, enrichissement de catalogue, résumé de centaines de textes, génération de rapports nocturnes. Si l’utilisateur attend devant l’écran, le batch est souvent mauvais. Si le résultat peut arriver plus tard, il devient pertinent.
Erreur partielle
Un batch peut réussir à 92 % et échouer à 8 %. Il faut donc compter items envoyés, réussis, échoués, relançables et abandonnés. Ne résumez pas un batch par “OK” si dix lignes sont en erreur.
File et reprise
Une queue synchronisée, comme celle documentée par Python, sert à organiser des travaux entre producteurs et consommateurs. En automatisation, le principe est le même : déposer des tâches, traiter, marquer le résultat, puis reprendre les échecs.
Bon format de sortie
Chaque item doit garder son identifiant source. Sans cela, vous ne pouvez pas relier une erreur au bon client, produit ou article.
Découpage des lots
Un gros lot unique est pratique à lancer mais difficile à reprendre. Préférez des lots raisonnables avec un identifiant de job, un fichier d’entrée et un fichier de sortie. Si le fournisseur impose une limite de taille, découpez avant l’envoi plutôt que de découvrir le rejet après trente minutes de préparation.
Reporting minimal
À la fin, produisez un résumé exploitable : total soumis, total terminé, erreurs temporaires, erreurs définitives, coût estimé si disponible, prochain lot à relancer. Le batch devient dangereux quand il tourne en arrière-plan sans tableau de bord ni propriétaire clair.
Batch ou temps réel ?
Choisissez le batch quand le volume compte plus que la réponse immédiate. Choisissez le temps réel quand l’utilisateur attend une confirmation, par exemple paiement, connexion ou action dans une interface. Mélanger les deux sans le dire crée de mauvaises attentes : l’utilisateur croit que c’est terminé alors que le job est seulement en file.
Un résultat par demande, pas seulement par fichier
Supposons un catalogue de vingt produits : dix-neuf descriptions sont produites et une entrée dépasse la limite acceptée. Le lot est terminé techniquement, mais le catalogue ne l’est pas. Conservez l’identifiant de chaque produit et associez-lui soit un résultat, soit une erreur explicite. L’ordre d’arrivée des résultats ne doit pas servir de clé de rapprochement.
Figer les entrées permet de savoir quelle version a été traitée. Si un prix change pendant le calcul, une réponse tardive ne doit pas écraser la nouvelle fiche sans contrôle. Une relance porte sur les éléments échoués et conserve leur identité métier ; soumettre de nouveau tout le lot peut multiplier les coûts et les effets.
Batch, file et parallélisme
Ces notions sont différentes : le batch décrit un traitement groupé, la file organise les travaux en attente et le parallélisme exécute plusieurs travaux simultanément. Un lot peut être traité séquentiellement. Une réduction de tarif ou un délai de disponibilité relève du contrat d’un service précis, pas de la définition du batch.