Génération de vidéos IA en masse : des centaines de clips sans casse

La première fois que vous lancez trois cents générations vidéo depuis un script, quelque chose casse vers le job quarante. Un fournisseur renvoie un 429, votre boucle réessaie aussitôt, les retries se percutent entre eux, et à la fin du run vous avez 280 fichiers, quelques doublons payés deux fois et une douzaine de jobs dont les liens de sortie ont déjà expiré. Les modèles n'y sont pour rien ; la panne vient du fait d'avoir traité un lot comme une simple boucle for.

Voici la plomberie qui permet de laisser tourner une génération vidéo IA en masse sans surveillance : chiffrer le lot à l'avance, mettre en file dans les limites de concurrence, réessayer sans payer deux fois, rapprocher les remboursements et nommer les sorties pour les retrouver le mois suivant.

Trois limites qui fixent la vitesse d'un lot

Les API de génération limitent le débit sur trois axes distincts, que la documentation de Leonardo.Ai définit très clairement :

• La concurrence est le nombre de jobs de génération traités en parallèle.
• La limite de file (pending) est le nombre de requêtes qui peuvent attendre quand tous les emplacements concurrents sont occupés.
• La limite de débit de l'API est le nombre de requêtes que vous pouvez envoyer sur une fenêtre de temps donnée, quel que soit leur contenu.

La concurrence ne plafonne pas le nombre total de requêtes : le surplus attend dans la file, si elle a de la place. La concurrence fixe votre débit de production ; la limite de débit fixe la fréquence à laquelle vous pouvez soumettre et interroger.

À quoi ressemblent les valeurs par défaut

Elles sont basses, et en général définies par organisation plutôt que par clé :

• fal : les nouveaux comptes démarrent à 2 requêtes concurrentes, puis montent avec les factures payées des quatre dernières semaines jusqu'à 40 en libre-service. Les requêtes en IN_QUEUE ne comptent pas dans la limite ; seules celles en IN_PROGRESS comptent.
• Vidu : jusqu'à 5 tâches concurrentes par organisation, et la limite s'applique à l'organisation, pas à la clé API.
• LTX : selon sa page sur les limites de débit, 2 générations simultanées par défaut, les requêtes au-delà recevant un 429 avec un en-tête Retry-After.
• Replicate : 600 requêtes par minute pour créer des prédictions et 3 000 par minute pour les autres endpoints, avec de courtes rafales tolérées avant le throttling.

Avec une concurrence de 2, un run de 300 clips occupe toute une soirée, quelle que soit la vitesse de votre code. Traitez-le comme un job de fond, avec un manifeste et une ligne d'arrivée.

Chiffrez le lot avant de lancer

Avec une tarification à l'appel, le coût d'un lot est un produit de nombres que vous connaissez déjà. La formule pour votre runbook :

Coût du lot = clips x secondes par clip x prix par seconde + images x prix par image + (caractères / 450) x prix par tranche de 450 caractères de voix.

D'après les prix publics d'Aitachyon au moment de la rédaction (la liste complète est sur la page des modèles avec le prix de chaque appel), voici ce que coûtent des lots réalistes de bout en bout, avec des clips de 5 secondes :

• 20 hooks sur Hailuo 02 à $0.085/s : 20 x 5 x $0.085 = $8.50.
• Les mêmes 20 hooks sur Kling v3 : $16.00 en silencieux à $0.16/s, ou $32.00 avec audio natif à $0.32/s.
• Les mêmes 20 hooks sur Seedance 2.5 : $20.00 en 480p ($0.20/s) ou $44.00 en 720p ($0.44/s).
• 50 visuels produit sur Seedream 4.0 à $0.057 l'image : $2.85. Sur FLUX.2 [pro] à $0.057 à $0.086 : $2.85 à $4.30. Sur Nano Banana à $0.13 : $6.50.
• Une semaine de shorts, sept vidéos composées chacune de trois clips Hailuo 02 de 5 secondes et d'environ 900 caractères de voix off ElevenLabs ($0.043 à $0.086 par 450 caractères) : par short, 15 x $0.085 = $1.275 pour la vidéo et $0.086 à $0.172 pour la voix, soit environ $9.53 à $10.13 pour la semaine.
• 300 clips : 1 500 secondes de vidéo. Cela fait $127.50 sur Hailuo 02 et $480.00 sur Kling v3 avec audio.

Le même lot varie d'environ un à quatre selon les modèles, donc le choix du modèle pèse plus à grand volume. Un schéma courant : générer toutes les variantes sur un modèle moins cher, choisir les gagnantes, puis refaire uniquement celles-là sur le modèle qui donne le rendu ou l'audio natif voulu. Le détail des prix d'API modèle par modèle expose les compromis.

Deux lignes que l'on oublie. Les retries : avec une mauvaise logique de retry, un run de 300 clips en facture bien plus de 300. Et le taux de conservation : si vous gardez un clip sur cinq, un clip utilisable coûte cinq fois le prix de l'appel. La question en amont est de savoir combien de publicités faire réellement tourner.

Le manifeste de jobs : nommez chaque job avant de le soumettre

L'habitude la plus utile en génération de masse consiste à écrire tout le lot dans un fichier manifeste avant l'envoi de la moindre requête. Il consigne ce qui doit exister, ce qui a été soumis, ce qui est terminé et ce que ça a coûté. Quand le script plante au job 140, vous reprenez depuis le manifeste au lieu de deviner.

Une ligne de manifeste qui survit à un crash

1. job_key : un identifiant déterministe construit à partir de la campagne, du plan, du modèle et de la variante, par exemple spring-launch_hook-07_kling3_v2.
2. modèle et paramètres : slug du modèle, durée, résolution, audio activé ou non, seed si le modèle en accepte un.
3. prompt : le texte exact envoyé, pour pouvoir reproduire un gagnant.
4. estimated_cost : issu de la formule ci-dessus.
5. status : planned, submitted, running, done, failed.
6. provider_id : l'identifiant de requête ou de job renvoyé par l'API à la soumission.
7. output_ref et local_path : l'emplacement du fichier une fois récupéré.
8. actual_cost et attempts : renseignés à la fin du job.

Additionnez estimated_cost et refusez de démarrer au-dessus du budget. Ce contrôle attrape la faute de frappe qui transforme 30 clips en 300.

Idempotence : la règle qui évite la double facturation

Le moment dangereux, c'est un timeout réseau à la soumission : vous ne savez pas si le job a été créé, et un retry à l'aveugle peut le facturer deux fois. Stripe documente la défense standard pour les POST payants : le serveur conserve le code de statut et le corps de la première requête pour chaque clé d'idempotence, erreurs 500 comprises, et renvoie ce même résultat aux répétitions. Les clés peuvent faire jusqu'à 255 caractères, être purgées au bout d'au moins 24 heures, et réutiliser une clé avec d'autres paramètres renvoie une erreur.

Beaucoup d'API de génération ne documentent pas l'idempotence ; la page de fiabilité de fal ne traite pas explicitement les garanties d'idempotence. Quand le fournisseur n'offre pas de clé, votre manifeste sert de couche d'idempotence : avant de resoumettre un job dont la soumission a expiré, cherchez-le côté fournisseur et ne resoumettez qu'après avoir confirmé qu'il n'existe pas.

Mettez le travail en file, plafonnez ce qui tourne

Les API vidéo sont asynchrones : on soumet, on reçoit un identifiant, on revient chercher le résultat. La file de fal renvoie un request_id à conserver pour les vérifications de statut ultérieures et fait passer chaque requête par IN_QUEUE, IN_PROGRESS puis COMPLETED. Le guide vidéo d'OpenAI reprenait la même forme, avec les statuts queued, in_progress, completed et failed.

Le schéma qui évite les rejets en série, d'après la documentation de LTX, est une file locale qui limite les jobs actifs à la concurrence autorisée. En pratique :

1. Chargez toutes les lignes planifiées du manifeste dans une file locale.
2. Démarrez un pool de workers dimensionné sur votre limite de concurrence. Si le fournisseur ne compte que les jobs en cours, comme fal, vous pouvez soumettre en avance dans sa file ; fal indique que les requêtes en file ne sont jamais abandonnées à cause des limites de concurrence, sauf expiration d'un start_timeout.
3. Chaque worker soumet un job, consigne aussitôt l'identifiant fournisseur dans le manifeste, puis attend la fin.
4. À la fin, le worker télécharge la sortie, écrit la ligne et prend le job suivant.
5. Placez en tête les jobs dont vous avez besoin, et marquez les variantes en masse en basse priorité quand c'est possible ; fal accepte pour cela priority réglé sur low.

Webhooks ou polling

Préférez les webhooks quand vous pouvez en recevoir. Replicate envoie des POST HTTP quand les prédictions sont créées, mises à jour et terminées, et fal accepte un webhook_url à la soumission et y poste l'identifiant de requête, le statut et la sortie à la fin. Rendez le handler idempotent : la même fin peut arriver plusieurs fois, donc retrouvez le job par son identifiant et ne faites rien si la ligne est déjà à done.

Si vous faites du polling, faites-le lentement. OpenAI suggérait toutes les 10 à 20 secondes, avec un backoff exponentiel si besoin. Interroger 300 jobs chaque seconde épuise votre limite de débit générale (celle de Replicate est de 3 000 requêtes par minute hors création) et vous fait throttler sur les appels qui comptent.

Des retries qui ne multiplient pas la facture

Réessayer après un délai fixe synchronise vos workers : ils se réveillent ensemble et se percutent de nouveau. AWS l'a mesuré dans son étude sur l'exponential backoff et le jitter. Avec 100 clients en compétition, le full jitter a réduit de plus de moitié le nombre total d'appels par rapport à un backoff exponentiel sans jitter, lequel était si long qu'il a été retiré du graphique des temps d'exécution.

La formule du full jitter :

sleep = random(0, min(cap, base x 2^attempt))

Avec base = 1 seconde et cap = 60 secondes, la tentative 3 attend une durée aléatoire entre 0 et 8 secondes. Les recommandations de fal pour les clients HTTP bruts suivent la même forme, avec un backoff de 1 s, 2 s, 4 s, 8 s, et son SDK réessaie jusqu'à 10 fois.

Une règle de décision pour les retries

Toutes les erreurs ne méritent pas un retry :

1. 429 avec en-tête Retry-After : attendez exactement cette durée, plus un peu de jitter. Le message de throttling de Replicate indique quand la limite est réinitialisée, autour de 30 secondes.
2. 429 sans en-tête, ou concurrent_requests_limit chez fal (fal ajoute aussi X-Fal-needs-retry: 1) : backoff en full jitter, et retirez un worker si cela se répète.
3. 503, 504 ou erreur de connexion : réessayez avec backoff. Ce sont les erreurs que la file de fal rejoue automatiquement, avec le 429.
4. Timeout à la soumission : ne resoumettez pas avant d'avoir vérifié si le job existe (voir l'idempotence plus haut).
5. Erreurs 4xx de validation ou de contenu : ne réessayez pas. Marquez la ligne failed avec le message, corrigez le prompt ou les paramètres, et remettez-la en file comme nouvelle variante.
6. Job terminé avec le statut failed : réessayez une fois avec les mêmes paramètres. Si cela échoue encore, considérez que le problème vient du prompt et passez à la suite.

Plafonnez les tentatives par job (trois est un bon défaut) et le total des retries par run. Quand un dixième des jobs est en retry, quelque chose cloche en amont : mettez le run en pause.

Échecs, remboursements et rapprochement

À grand volume, certains rendus échouent, et la question est de savoir qui paie. fal indique que les requêtes en échec qui renvoient un 5xx ne sont pas facturées. Sur Aitachyon, un rendu en échec est remboursé automatiquement, au centime près, et chaque job est détaillé avec le modèle utilisé et son coût. Quelle que soit la politique de votre fournisseur, rapprochez les comptes après chaque run au lieu de lui faire confiance.

Checklist de rapprochement après le run

• Comptez les lignes par statut. Planned moins done moins failed doit donner zéro ; le reste est bloqué et demande une vérification de statut.
• Additionnez actual_cost et comparez-le à estimated_cost. Un écart de plus de quelques pourcents signale en général des soumissions en double, ou un modèle ou une durée différents du plan.
• Associez chaque job facturé à une ligne du manifeste. Une facturation sans ligne est un doublon causé par un retry.
• Vérifiez que chaque job en échec affiche son remboursement ou une facturation nulle, et que chaque ligne done a un fichier local de la durée attendue.
• Consignez la sélection : quelles sorties vous avez gardées. Ce ratio alimente le budget du prochain lot.

Avec un script, cela prend quelques minutes, et cela se transpose directement à la production de 50 variantes UGC par semaine, où cela garde la dépense hebdomadaire stable.

Récupérez les fichiers avant qu'ils disparaissent

Les sorties hébergées par le fournisseur sont temporaires. Replicate supprime au bout d'une heure les fichiers de sortie des prédictions créées par API et vous demande d'en garder une copie ; les prédictions lancées depuis l'interface web conservent leurs fichiers, si bien qu'un workflow qui marchait à la main peut perdre des fichiers une fois scripté. Les URL de téléchargement vidéo d'OpenAI étaient valides au plus 1 heure après la génération.

Lancez le run la nuit, téléchargez le matin, et vous obtenez des liens morts. Téléchargez dans le handler de fin, à l'étape qui marque la ligne done.

Une convention de nommage où l'on peut chercher

Renommez chaque fichier au téléchargement avec sa job key, par exemple spring-launch_hook-07_kling3_v2.mp4, et gardez la référence du fournisseur dans le manifeste. Aitachyon donne à chaque fichier généré une ref stable (img_, scn_, vo_ et ainsi de suite) que le code peut récupérer à tout moment avec GET /api/generations/{ref} ; la ref est donc la poignée durable et le fichier local votre copie de travail. Avec les deux dans le manifeste, une question comme « quel prompt a produit le hook qui a gagné en mars » se résume à un grep.

La dépendance au fournisseur est aussi un risque de lot

Le guide d'OpenAI précise désormais que les modèles Sora 2 et l'API Videos ont été arrêtés le 24 septembre 2026. Les pipelines branchés sur cet endpoint ont dû être réécrits. Avec le modèle conservé comme paramètre du manifeste, une fin de vie se règle par un changement de config.

Contrôle des coûts par clé, et lots pilotés par un agent

Un script bogué avec un solde illimité est la combinaison coûteuse. Replicate applique des limites de plus en plus strictes à mesure que le crédit baisse et recommande de garder le solde au-dessus de $20 avec recharge automatique, tandis que les comptes sans moyen de paiement sont limités à 1 requête par seconde. Vos propres garde-fous doivent s'y ajouter :

Garde-fous de dépense pour les runs sans surveillance

1. Une clé API par pipeline. Le job nocturne de shorts, le script de variantes publicitaires et votre session d'agent ont chacun leur clé, ce qui rend la dépense attribuable. Sur Aitachyon, chaque clé a sa propre dépense, une alerte quand elle dépense anormalement vite et une révocation en un clic.
2. Un plafond prépayé. Un solde prépayé est un plafond dur par construction. Le solde d'Aitachyon n'expire jamais, donc recharger pour un gros run ne crée pas de pression à consommer avant échéance. La comparaison entre crédits et paiement à l'appel passe en revue les endroits où chaque modèle perd de l'argent.
3. Un contrôle de budget dans le code. Le total du manifeste, vérifié avant le run puis tous les 50 jobs par rapport à la dépense réelle.
4. Un coupe-circuit. Si l'alerte par clé se déclenche, révoquez la clé. Les workers échouent vite sur les erreurs d'authentification, ce qui est le comportement voulu.

Le même lot, piloté par un agent

De plus en plus souvent, c'est un agent de code qui écrit et lance le script. Avec un serveur MCP hébergé connecté à Claude Code ou Cursor, vous décrivez le lot (« vingt hooks de 5 secondes à partir de ces prompts sur Hailuo 02, enregistrés dans ./hooks et nommés par numéro de hook ») et l'agent soumet, attend, télécharge et rapporte chaque fichier avec son coût. Connecter Claude Code à Aitachyon tient en une commande :

claude mcp add --transport http aitachyon https://aitachyon.com/api/mcp --header "Authorization: Bearer ait_..."

Les runs d'agent demandent les mêmes garde-fous : une clé dédiée, un budget énoncé dans le prompt et le manifeste écrit sur disque au fil de l'eau. Le pas-à-pas sur la génération de vidéo depuis Claude Code via MCP montre la configuration, et une configuration d'agent qui fonctionne pour la production vidéo explique comment enchaîner scripts, clips et voix jusqu'aux pièces finies.

Checklist avant un run en masse

Copiez ceci en tête de votre script de lot ou de votre prompt d'agent :

1. Manifeste écrit, une ligne par sortie, job keys déterministes.
2. Total estimé sous le budget.
3. Une clé API dédiée avec alertes de dépense.
4. Workers plafonnés à la limite de concurrence.
5. Backoff en full jitter, Retry-After respecté, trois tentatives maximum.
6. Soumissions expirées vérifiées avant toute resoumission.
7. Handler de webhook ou polling lent, idempotent dans les deux cas.
8. Téléchargement et renommage à la fin du job.
9. Un lot test de cinq, exécuté de bout en bout.
10. Script de rapprochement prêt.

Le lot test est l'étape que l'on saute, et la moins chère : sur Hailuo 02 au moment de la rédaction, cinq clips de 5 secondes coûtent $2.13, et ils détectent le mauvais format d'image avant qu'il ne vous coûte trois cents fois plus.

FAQ

Est-ce que je paie les générations vidéo IA en échec ?

Cela dépend du fournisseur. fal ne facture pas les requêtes qui échouent avec une erreur 5xx, et Aitachyon rembourse automatiquement les rendus en échec, au centime près. Dans les deux cas, rapprochez vos frais détaillés de votre liste de jobs après chaque run, car une soumission en double issue d'un mauvais retry est un job réussi que vous avez bien payé.

Combien de temps les fichiers vidéo générés restent-ils disponibles ?

Souvent peu. Replicate supprime les fichiers de sortie de l'API au bout d'une heure, et les URL de téléchargement vidéo d'OpenAI duraient au plus une heure. Téléchargez chaque fichier dès la fin de son job et stockez-le sous votre propre nom. Sur Aitachyon, chaque sortie a aussi une ref stable que vous pouvez récupérer plus tard avec GET /api/generations/{ref}.

Combien coûte la génération de 100 courtes vidéos IA ?

Pour 100 clips de cinq secondes aux prix d'Aitachyon au moment de la rédaction, cela fait $42.50 sur Hailuo 02, $80 sur Kling v3 en silencieux et $100 sur Seedance 2.5 en 480p. Divisez par votre taux de conservation pour obtenir le coût par clip utilisable.

Sources

1. Replicate : limites de débit
2. Replicate : fichiers de sortie
3. Replicate : webhooks
4. fal : limites de concurrence
5. fal : inférence asynchrone et file
6. fal : fiabilité
7. Leonardo.Ai : guide de la concurrence, de la file et des limites de débit
8. Vidu : usage et limites
9. Stripe : requêtes idempotentes
10. AWS Architecture Blog : exponential backoff et jitter

Si vous voulez lancer ce type de lot sans ouvrir un compte séparé par modèle, Aitachyon réunit Seedance, Kling, Veo, Hailuo, les modèles d'image et la voix ElevenLabs derrière une seule clé, utilisable depuis une API HTTP ou le serveur MCP hébergé, avec chaque job détaillé, les rendus en échec remboursés et la dépense suivie par clé. Le guide de démarrage de l'API et du MCP décrit la mise en place.