# Traitement par lots* Traitez plusieurs requêtes API de manière asynchrone avec un seul chargement de fichier. L’API Batch Jobs vous permet d’effectuer des opérations en masse sur les ressources Stripe. Au lieu d’effectuer des appels API individuels pour chaque opération - ce qui peut entraîner des limites de taux - vous pouvez importer un fichier contenant l’ensemble de vos opérations et laisser Stripe les traiter de manière asynchrone. Utilisez cette API pour des migrations ponctuelles, des mises à jour en masse ou toute opération nécessitant le traitement d’un grand nombre de ressources. ## Quand utiliser le traitement par lots* Le traitement par lots* fonctionne bien pour : - **Migrations groupées** : transférez des quantités importantes d’abonnements vers de nouveaux modes de facturation. - **Mises à jour en masse** : mettez à jour plusieurs comptes ou abonnements en même temps. Le traitement par lots ne fonctionne pas bien pour : - Opérations nécessitant une réponse synchrone immédiate. - Traitement en temps réel avec des exigences de délais serrés. - Un seul appel asynchrone. Pour effectuer un traitement par lots, procédez comme suit : 1. [Créez une tâche par lots](https://docs.stripe.com/batch-api.md#create-a-batch-job) et spécifiez l’endpoint API cible. 1. [Téléchargez le fichier d’entrée](https://docs.stripe.com/batch-api.md#upload-the-input-file) avec vos requêtes par lots. 1. [Suivre l’état du traitement](https://docs.stripe.com/batch-api.md#monitor-job-status) via des webhooks ou des sondages. 1. [Téléchargez les résultats](https://docs.stripe.com/batch-api.md#download-the-results). ## Endpoints pris en charge L’API Batch Jobs prend en charge les endpoints suivants. Chaque traitement par lots cible un seul endpoint, et toutes les requêtes du lot vont vers cet endpoint. | Endpoint | Chemin | | -------------------------------------------------------------------------------------- | ------------------------------------ | | [Modifier un client](https://docs.stripe.com/api/customers/update.md) | POST `/v1/customers/:id` | | [Créer un code promotionnel](https://docs.stripe.com/api/promotion_codes/create.md) | POST `/v1/promotion_codes` | | [Modifier un code promotionnel](https://docs.stripe.com/api/promotion_codes/update.md) | POST `/v1/promotion_codes/:id` | | [Migrer un abonnement](https://docs.stripe.com/api/subscriptions/migrate.md) | POST `/v1/subscriptions/:id/migrate` | | [Modifier un abonnement](https://docs.stripe.com/api/subscriptions/update.md) | POST `/v1/subscriptions/:id` | ## Limites Vérifiez les limites suivantes : - Les fichiers par lots sont limités à 5 Go. Si vous devez traiter un fichier plus volumineux pour un volume plus élevé de requêtes, fractionnez-le en plusieurs lots. - Le traitement par lots* prend uniquement en charge les fichiers JSONL (JSON délimité par des sauts de ligne). Le traitement par lots n’accepte pas les formats CSV ou autres. - Les requêtes d’un lot peuvent uniquement utiliser `POST` ou `DELETE`. Le traitement par lots* ne prend pas en charge `GET`. - Toutes les requêtes d’un lot doivent cibler le même endpoint API. - Le traitement par lots* ne garantit pas l’ordre de traitement des requêtes. - La durée maximale du traitement par lots* est de 24 heures. Les traitements dépassant cette limite passent à l’état `timeout`, avec des résultats partiels disponibles. - Les résultats sont téléchargeables pendant 7 jours après la fin du traitement. - L’URL de téléchargement expire 5 minutes après la création de la tâche. Passé ce délai, la tâche passe à l’état `upload_timeout` et vous devez en créer un nouveau. - Chargez le fichier avec une requête directe HTTP `PUT` à l’URL présignée. ## Créer un traitement par lots Pour commencer, créez un traitement par lots en envoyant une requête `POST` à `/v2/core/batch_jobs`. Spécifiez l’endpoint cible et les éventuelles options de traitement : ```bash curl https://api.stripe.com/v2/core/batch_jobs \ -u <>: \ -H "Content-Type: application/json" \ -H "Stripe-Version: 2026-03-25.preview" \ -d '{ "endpoint": { "path": "/v1/subscriptions/:id/migrate", "http_method": "post" }, "maximum_rps": 10, "skip_validation": false }' ``` Le type de contenu de cette requête est un fichier JSON. Celui-ci renvoie un objet de traitement par lots avec un état `ready_for_upload`. L’URL du chargement et son délai d’expiration se trouvent dans le champ `status_details` : ```json { "id": "batchv2_AbCdEfGhIjKlMnOpQrStUvWxYz", "object": "v2.core.batch_job", "created": "2026-03-09T20:55:31.000Z", "maximum_rps": 10, "skip_validation": false, "status": "ready_for_upload", "status_details": { "ready_for_upload": { "upload_url": { "expires_at": "2026-03-09T21:00:31.000Z", "url": "https://stripeusercontent.com/files/upload/..." } } } } ``` L’objet `status_details` varie en fonction de l’état actuel. Lorsque le job est à l’état `ready_for_upload`, il contient l’URL de téléchargement pré-signée ainsi que son horodatage d’expiration. ### Paramètres | Paramètre | Obligatoire | Description | | -------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `endpoint.path` | Oui | L’endpoint API à cibler (par exemple, `/v1/Subscriptions/:id/migrate`). Consultez la section [Endpoints pris en charge](https://docs.stripe.com/batch-api.md#supported-endpoints). | | `endpoint.http_method` | Oui | La méthode HTTP pour l’endpoint. Actuellement, seul `post` est pris en charge. | | `maximum_rps` | Non | Maximum de requêtes traitées par seconde (1 à 100). Par défaut, 10. | | `skip_validation` | Non | Défini sur `true` pour ignorer la validation du fichier d’entrée et commencer immédiatement le traitement. Sa valeur par défaut est `false`. | | `notification_suppression` | Non | Contrôle si les webhooks des opérations API sous-jacentes sont livrés. Définissez `{"scope": "all"}` pour supprimer les webhooks au niveau de l’opération. Les événements au niveau du lot sont toujours livrés quel que soit ce paramètre. Par défaut, `{"scope": "none"}`. | | `metadata` | Non | Paires clé-valeur pour votre suivi interne. Les métadonnées sont incluses dans les événements de traitement par lots, y compris les événements d’échec. | ## Charger le fichier d’entrée Après avoir créé le traitement par lots, chargez votre fichier d’entrée dans l’URL dans `status_details.ready_for_upload.upload_url.url`. Utilisez une requête `PUT` avec le contenu du fichier : ```bash curl {UPLOAD_URL} \ -X PUT \ -T input.jsonl \ -H "Content-Type: application/jsonlines" ``` Le fichier d’entrée de cette requête doit être un fichier JSONL, et le type de contenu doit être un `application/octet-stream`. Une fois le chargement terminé, Stripe commence automatiquement le traitement. Il n’y a pas d’étape `start` distincte. L’URL de chargement expire 5 minutes après la création du traitement par lots. Vérifiez le champ `expires_at` pour connaître la date limite exacte. Si l’URL expire avant que vous ne chargiez le fichier, l’état du traitement passe à `upload_timeout`, et vous devez créer un nouveau traitement par lots. Générez le fichier d’entrée avant de créer le traitement par lots pour pouvoir le charger rapidement. ### Format du fichier d’entrée Le fichier doit être encodé en UTF-8 et utiliser le format JSONL (JSON délimité par des sauts de ligne, un objet par ligne). Chaque ligne représente une requête API unique à l’endpoint cible. Le format CSV et les autres formats ne sont pas pris en charge. Chaque objet JSON prend en charge les champs suivants : | Champ | Obligatoire | Description | | ------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `id` | Oui | Un identifiant unique pour corréler cette requête avec son résultat. Les identifiants des paramètres du chemin d’accès et les identifiants de l’endpoint doivent correspondre, bien que l’utilisateur soit libre de choisir comment les nommer : doivent correspondre à `/^[A-Za-z0-9_-]+$/`. | | `path_params` | Conditionnel | Paramètres du chemin d’accès pour l’endpoint. Obligatoire lorsque le chemin d’accès de l’endpoint inclut des emplacements réservés (par exemple, `:id`). Les clés dans `path_params` doivent correspondre exactement aux emplacements réservés dans le chemin d’accès de l’endpoint. | | `params` | Non | Paramètres du corps de la requête pour l’appel à l’API. Des variations peuvent se produire sur la base de la méthode de l’API. | | `context` | Non | Un ID de compte Stripe. Utilisez-le pour exécuter la requête sur un compte spécifique, par exemple un compte connecté. | ### Exemple de fichier d’entrée #### Méthode API - POST /v1/customers/:id Pour le endpoint `POST /v1/customers/:id` : ```json {"id": "req_001", "path_params": {"id": "cus_1AbCdEfGhIjKlMn"}, "params": {"name": "Jenny Rosen", "email": "jenny@example.com"}} {"id": "req_002", "path_params": {"id": "cus_2BcDeFgHiJkLmNo"}, "params": {"name": "John Smith", "metadata": {"tier": "premium"}}} {"id": "req_003", "context": "acct_1234567890", "path_params": {"id": "cus_3CdEfGhIjKlMnOp"}, "params": {"description": "Updated by batch"}} ``` #### Méthode API - POST /v1/subscriptions/:id/migrate Pour le endpoint `POST /v1/Subscriptions/:id/migrate` : ```json {"id": "req_001", "path_params": {"id": "sub_1AbCdEfGhIjKlMn"}, "params": {"billing_cycle_anchor": "unchanged", "proration_behavior": "none"}} {"id": "req_002", "path_params": {"id": "sub_2BcDeFgHiJkLmNo"}, "params": {"billing_cycle_anchor": "unchanged", "proration_behavior": "create_prorations"}} ``` #### Méthode API - POST /v1/subscriptions/:id Pour le endpoint `POST /v1/subscriptions/:id` : ```json {"id": "req_001", "path_params": {"id": "sub_1AbCdEfGhIjKlMn"}, "params": {"description": "Updated subscription description"}} {"id": "req_002", "path_params": {"id": "sub_2BcDeFgHiJkLmNo"}, "params": {"metadata": {"migration_batch": "v2"}}} {"id": "req_003", "path_params": {"id": "sub_3CdEfGhIjKlMnOp"}, "params": {"cancel_at_period_end": true}} ``` #### Méthode API - POST /v1/promotion_codes Pour le endpoint `POST /v1/promotion_codes` : ```json {"id": "req_001", "params": {"coupon": "25OFF", "code": "SUMMER25"}} {"id": "req_002", "params": {"coupon": "50OFF", "code": "WINTER50", "max_redemptions": 100}} ``` #### Méthode API - POST /v1/promotion_codes/:id Pour le endpoint `POST /v1/promotion_codes/:id` : ```json {"id": "req_001", "path_params": {"id": "promo_1AbCdEfGhIjKlMn"}, "params": {"active": false}} {"id": "req_002", "path_params": {"id": "promo_2BcDeFgHiJkLmNo"}, "params": {"metadata": {"tier": "premium"}}} ``` Chaque `id` doit être unique dans le fichier. Stripe l’utilise pour corréler les requêtes avec les résultats, car le fichier des résultats n’est pas ordonné de la même manière que le fichier d’entrée. ## Suivre l’état du traitement Vous pouvez suivre votre traitement par lots en interrogeant l’endpoint de récupération ou en écoutant les [événements webhook](https://docs.stripe.com/batch-api.md#webhook-events). Nous vous recommandons d’utiliser des événements webhook pour les intégrations en production. ### Sondage pour état ```bash curl https://api.stripe.com/v2/core/batch_jobs/{BATCH_JOB_ID} \ -u <>: \ -H "Stripe-Version: 2026-03-25.preview" ``` Le type de contenu de cette requête est un fichier json. Pendant que la tâche est en cours d’exécution, `status_details` inclut des décomptes de progression en temps réel : ```json { "status": "in_progress", "status_details": { "in_progress": { "success_count": "1", "failure_count": "0" } } } ``` Pendant la phase `validating`, `status_details` inclut un champ `validated_count` qui indique le nombre de lignes validées par Stripe jusqu’à présent. Les appels à l’API Batch Job apparaissent dans les logs de requêtes Stripe Dashboard ou Workbench. Les appels à l’API sous-jacents n’apparaissent pas dans les logs de requêtes. Utilisez l’endpoint de récupération ou les événements webhook pour suivre la progression. Pour déboguer les échecs de requêtes individuelles, consultez le fichier de résultats. ### Cycle de vie du traitement Une fois que vous avez chargé le fichier d’entrée, le traitement par lots passe par les états suivants : | État | Description | | ------------------ | -------------------------------------------------------------------------------------------------- | | `ready_for_upload` | Le traitement par lots lot a été créé et attend le fichier d’entrée. | | `validating` | Le fichier d’entrée a été chargé et Stripe le valide. Ignoré lorsque `skip_validation` est `true`. | | `in_progress` | La validation a réussi (ou a été ignorée) et Stripe traite les requêtes. | | `complete` | Toutes les demandes ont été traitées. Les résultats sont téléchargeables. | | `cancelling` | Une annulation a été demandée. Stripe finalise les requêtes en cours. | ### États Terminal | État | Description | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `validation_failed` | Le fichier d’entrée contient des erreurs. Aucune requête n’a été traitée. Vérifiez les détails de l’erreur dans l’objet du traitement par lots. Cela ne s’applique que lorsque `skip_validation: false`. | | `batch_failed` | Une erreur inattendue s’est produite lors du traitement. | | `cancelled` | Le traitement par lots a été annulé. Des résultats partiels peuvent être disponibles. | | `upload_timeout` | L’URL de chargement a expiré avant le chargement du fichier. Créez un nouveau traitement par lots. | | `timeout` | Le traitement par lots a dépassé la durée maximale de traitement de 24 heures. Des résultats partiels peuvent être disponibles. | ### Validation Lorsque `skip_validation` est `false` (par défaut), Stripe valide l’intégralité du fichier de saisie avant de traiter toute requête. Cette validation détecte les erreurs telles que : - JSON non valide dans une ligne. - Champs `ID` manquants ou non valides. - Dupliquer les ID. - `path_params` requis manquants pour l’endpoint cible. - Paramètres non valides. Si la validation échoue, l’état passe à `validation_failed`, et Stripe ne tente aucune requête. L’objet traitement par lots inclut des détails de la première erreur qu’il rencontre. Lorsque `skip_validation` est `true`, la tâche passe directement de `ready_for_upload` à `in_progress` après le chargement. Les erreurs dans les requêtes individuelles apparaissent dans le fichier des résultats au lieu de bloquer l’ensemble du lot. ## Télécharger les résultats Lorsque le traitement par lots atteint l’état `complete`, le champ `status_details` inclut un récapitulatif des réussites et des échecs, ainsi qu’une URL de téléchargement présignée pour le fichier de sortie : ```json { "id": "batchv2_AbCdEfGhIjKlMnOpQrStUvWxYz", "object": "v2.core.batch_job", "created": "2026-03-09T20:55:31.000Z", "maximum_rps": 10, "skip_validation": true, "status": "complete", "status_details": { "complete": { "success_count": "2", "failure_count": "0", "output_file": { "content_type": "application/jsonlines", "size": "8514", "download_url": { "expires_at": "2026-03-09T22:05:31.000Z", "url": "https://stripeusercontent.com/files/download/..." } } } } } ``` Téléchargez le fichier en utilisant l’URL dans `status_details.complete.output_file.download_url.url`. Stripe fournit un fichier de sortie lorsque le traitement par lots atteint l’un des états suivants : - `complete` - `cancelled` - `timeout` - `validation_failed` Pour savoir quand l’URL de téléchargement expire, vérifiez le champ `expires_at` correspondant à la date limite. Le fichier des résultats contient les requêtes réussies et échouées dans un seul fichier. Pour trouver les échecs, filtrez les lignes dont `status` n’est pas `200`. ### Format du fichier des résultats Le fichier de sortie utilise le format JSONL (un objet JSON par ligne). Chaque ligne contient les champs suivants : | Champ | Description | | ---------- | --------------------------------------------------------------------------------------------------------- | | `id` | L’ID de requête du fichier d’entrée. Utilisez-le pour corréler les résultats avec les requêtes. | | `response` | L’objet API response complet. Contient la ressource en cas de réussite, ou un objet error en cas d’échec. | | `status` | Le code d’état HTTP sous forme de nombre entier (par exemple, `200`, `402`). | ### Exemple de fichier de résultats Les requêtes réussies renvoient la ressource API complète dans le champ `response` : ```json {"id": "req_001", "response": {"id": "sub_1AbCdEfGhIjKlMn", "object": "subscription", "status": "active", "billing_cycle_anchor": 1710021331, "current_period_end": 1712613331, "current_period_start": 1710021331}, "status": 200} {"id": "req_002", "response": {"id": "sub_2BcDeFgHiJkLmNo", "object": "subscription", "status": "active", "billing_cycle_anchor": 1710021331, "current_period_end": 1712613331, "current_period_start": 1710021331}, "status": 200} ``` Les requêtes échouées renvoient un objet error : ```json {"id": "req_003", "response": {"error": {"message": "This subscription cannot be migrated because it is not active. Current status is canceled.", "type": "invalid_request_error", "code": "resource_invalid_state"}}, "status": 400} ``` Les résultats ne sont pas renvoyés dans la même commande que le fichier de saisie. Utilisez le champ `id` pour faire correspondre chaque résultat à sa requête correspondante. ## Annuler un traitement par lots Vous pouvez annuler un traitement par lots qui n’est pas encore terminé en envoyant une requête `POST` : ```bash curl https://api.stripe.com/v2/core/batch_jobs/{BATCH_JOB_ID}/cancel \ -u <>: \ -X POST \ -H "Stripe-Version: 2026-03-25.preview" ``` L’annulation est asynchrone. La tâche par lots passe d’abord à l’état `cancelling` pendant que les requêtes en cours se terminent, puis à l’état `cancelled`. Les résultats partiels des requêtes traitées avant l’annulation sont disponibles dans le fichier de résultats. ## Événements webhook Les traitements par lots* émettent des événements légers v2 pour chaque transition du cycle de vie. Pour recevoir ces événements, vous devez configurer une [destination d’événement v2](https://docs.stripe.com/event-destinations.md). Les événements de traitements par lots nécessitent des destinations d’événement v2. Ils ne sont pas envoyés aux endpoints webhook v1. Les événements suivants sont disponibles : | Type d’événement | Description | | ------------------------------------- | ----------------------------------------------------------------- | | `v2.core.batch_job.created` | Un traitement par lots a été créé. | | `v2.core.batch_job.ready_for_upload` | Le traitement par lots est prêt pour le chargement de fichiers. | | `v2.core.batch_job.validating` | Chargement du fichier terminé, validation en cours. | | `v2.core.batch_job.validation_failed` | La validation du fichier d’entrée a échoué. | | `v2.core.batch_job.completed` | Toutes les requêtes ont été traitées. | | `v2.core.batch_job.batch_failed` | Le traitement par lots a échoué de manière inattendue. | | `v2.core.batch_job.canceled` | Le traitement par lots a été annulé. | | `v2.core.batch_job.timeout` | Le traitement par lots a dépassé la durée maximale de traitement. | | `v2.core.batch_job.upload_timeout` | L’URL de chargement a expiré avant le chargement du fichier. | | `v2.core.batch_job.updated` | L’état ou la progression du traitement par lots a changé. | Tous les événements du traitement par lots incluent les métadonnées que vous avez fournies lors de la création du traitement. Utilisez-les pour corréler les événements avec vos systèmes internes. Lorsque `notification_suppression` est défini sur `{"scope": "all"}`, les webhooks des opérations API sous-jacentes (par exemple, les événements de mise à jour d’abonnement) sont supprimés. Les événements de niveau lot listés ci-dessus sont toujours livrés quel que soit ce paramètre. ## Erreurs courantes ### URL de chargement expirée Si vous ne chargez pas le fichier d’entrée avant l’horodatage `expires_at` (5 minutes après la création du traitement), le traitement par lots passe à l’état `upload_timeout`. Créez un nouveau traitement par lots et chargez rapidement le fichier. Générez votre fichier d’entrée avant de créer le traitement par lots pour éviter cela. ### État de ressource non valide Les requêtes individuelles peuvent échouer si la ressource cible n’est pas dans l’état attendu. Par exemple, lors de l’utilisation de `/v1/Subscriptions/:id/migrate` : - **L’abonnement n’est pas actif** : l’abonnement doit être à l’état `active` avant de pouvoir être migré. Les abonnements annulés ou incomplets renvoient une erreur `400` avec le code `resource_invalid_state`. - **Abonnement déjà migré** : toute tentative de migration d’un abonnement déjà migré renvoie une erreur. Ces erreurs par requête apparaissent dans le fichier des résultats avec un code d’état non `200`. Le traitement par lots lui-même s’achève néanmoins avec succès (le traitement par lots se poursuit en cas d’échec de lignes individuelles). ### Incohérences des paramètres du chemin d’accès Les clés de `path_params` doivent correspondre exactement aux emplacements réservés du chemin d’accès endpoint. Par exemple, si votre chemin d’accès endpoint est `/v1/Subscriptions/:id/migrate`, vos `path_params` doivent utiliser `{"id": "sub_..."}`. Une incohérence entre le nom de l’espace réservé et la clé entraîne une erreur de validation ou un état `400` dans le fichier des résultats. ### Charger le type de contenu La requête `PUT` de chargement doit utiliser `Content-Type: application/octet-stream`. Les autres types de contenu sont rejetés. ### Erreurs de format de fichier Lorsque `skip_validation` est `false`, ces erreurs font échouer l’ensemble du lot avec l’état `validation_failed` : - Lignes non valides JSON - Champ `id` manquant sur une ligne - Valeurs d’`id` en double sur plusieurs lignes - Identifiants contenant des caractères en dehors de `A-Za-z0-9_-` Lorsque `skip_validation` est `true`, les erreurs de format au niveau du fichier peuvent entraîner l’échec de lignes individuelles plutôt que le blocage de l’ensemble du lot. ### Expiration du traitement par lots Les traitements par lots* de plus de 24 heures passent à l’état `timeout`. Les résultats partiels des requêtes traitées avant l’expiration sont disponibles dans le fichier des résultats. ## Bonnes pratiques* ### Choisissez le bon `maximum_rps` Le paramètre `maximum_rps` contrôle la vitesse à laquelle Stripe traite les requêtes dans votre lot. Le traitement par lots utilise un pool limite d’appels distinct de vos requêtes API principales, les traitements par lots n’affectent donc pas le trafic API habituel de votre compte. - **Valeurs inférieures** : 1 à 10 conviennent aux opérations groupées non urgentes. - **Valeurs supérieures** : 50 à 100 traitent les lots plus rapidement et sont adaptées à des opérations indépendantes sur différentes ressources. ### Utiliser la validation pour les opérations critiques Gardez `skip_validation` défini sur `false` (par défaut) pour les opérations pour lesquelles un traitement partiel poserait des problèmes. La validation permet de s’assurer que l’ensemble de votre fichier est bien formé avant toute exécution de requêtes. Définissez `skip_validation` sur `true` lorsque vous avez déjà validé vos données saisies et souhaitez un démarrage plus rapide du traitement, ou lorsque le traitement de résultats partiels est acceptable. ### Fractionner les charges de travail importantes Si votre fichier d’entrée dépasse 5 Go, répartissez la charge de travail sur plusieurs traitements par lots. Vous pouvez exécuter plusieurs traitements par lots simultanément. ### Vérifier l’état des ressources avant de les regrouper Confirmez que toutes les ressources cibles sont dans l’état requis avant de soumettre un lot. Par exemple, les abonnements doivent être actifs avant de pouvoir être migrés avec `/v1/Subscriptions/:id/migrate`. Les traitements par lots exécutent directement l’opération cible et ne changent pas d’état de ressource comme condition préalable. ### Gérer les erreurs dans les résultats Vérifiez toujours le champ `status` dans chaque ligne de résultat. Les requêtes individuelles d’un traitement par lots peuvent échouer, par exemple en raison de fonds insuffisants ou de paramètres non valides. Concevez votre intégration de manière à filtrer le fichier de résultats pour les statuts autres que `200`, et à gérer les échecs en conséquence. ### Préparer votre fichier avant de créer le traitement L’URL de chargement expire 5 minutes après la création du traitement par lots. Générez et validez votre fichier d’entrée avant d’appeler l’endpoint create. Si vous devez préparer les données dynamiquement, effectuez d’abord toute la récupération des données et la génération du fichier, puis créez le traitement par lots et chargez immédiatement.