Filtrage de Seedance 2.5 : diagnostiquer un refus

Pourquoi une requête Seedance 2.5 a-t-elle échoué ? Il faut d'abord déterminer si l'API a refusé la charge utile avant de créer une tâche, ou si une tâche asynchrone a ensuite échoué lors d'un contrôle de sécurité. La réponse contient déjà les éléments nécessaires pour distinguer ces deux cas.

Ce guide s'appuie sur des données observables : route exacte, champs de la requête, état de la tâche, code d'erreur et consommation facturée. Il ne transpose pas le comportement d'un hébergeur à un autre et ne présente pas une route moins restrictive comme un modèle sans filtre.

TL;DR

• Commencez par vérifier si une tâche a été créée, pas par mesurer le délai. Un 400 synchrone signifie que la validation a échoué avant la création de la tâche. Si une tâche se termine ensuite par failed, examinez ses champs error et usage.^[2][3]
• content_filter: false ne veut pas dire « sans filtre ». Sur reAPI, ce réglage sélectionne le canal Flexible, sans modifier le prix ni désactiver les règles de sécurité en amont.^[2]
• L'erreur 80006 ne nomme pas l'étape de modération. Elle peut concerner le prompt, une image ou une vidéo de référence, ou encore la sortie générée.^[3]
• Lisez la facture finale. Le champ usage.credits d'une tâche échouée indique si la réservation a été entièrement remboursée ou si des frais après génération ont été conservés.^[3][4]
• Limites du modèle à retenir : Seedance 2.5 peut générer jusqu'à 30 secondes en une passe et accepter jusqu'à 30 images, 10 vidéos et 10 pistes audio de référence.^[1]

Pourquoi les détails de la route comptent

Deux services peuvent valider et acheminer différemment le même modèle. Sur reAPI, content_filter est explicitement un paramètre de routage, pas un paramètre du modèle en amont. Sa valeur par défaut est true ; un appel direct à l'API peut utiliser false pour sélectionner le canal Flexible, moins restrictif, mais la modération reste active.^[2]

Quatre étapes observables permettent de situer le problème :

1. Validation synchrone de la requête. Un champ incorrect ou un média non pris en charge provoque une erreur HTTP avant la création d'une tâche.
2. Sélection de la route. Une requête valide suit le canal choisi par des paramètres propres au modèle, dont content_filter.
3. Exécution asynchrone. La tâche passe par processing avant d'atteindre completed ou failed.
4. Échec de sécurité. Le code 80006 peut correspondre au refus du prompt, d'une référence ou de la sortie générée ; ce code générique ne précise pas quel contrôle a réagi.^[3]

Il s'agit d'étapes visibles dans l'API, pas d'une affirmation sur l'architecture interne de tous les hébergeurs.

Cinq vérifications pour localiser l'échec

Ces vérifications utilisent uniquement les champs exposés par l'API. Aucun prompt volontairement interdit n'est nécessaire.

Vérification 1 : la soumission a-t-elle créé une tâche ?

Enregistrez le statut HTTP et le corps de la réponse au POST. Un 400 synchrone accompagné d'une erreur 2xxxx signale un problème de validation : corrigez le champ ou le format indiqué. Si la réponse contient un ID de tâche, la soumission a réussi et la suite du diagnostic se trouve dans l'enregistrement de cette tâche.^[2][3]

Le temps écoulé apporte du contexte, mais ne prouve pas quel composant interne a pris la décision.

Vérification 2 : consigner la route et ses paramètres

Conservez le point de terminaison, l'identifiant exact du modèle, la charge utile complète et la valeur de content_filter. Sur reAPI, l'absence de ce champ équivaut à true ; false sélectionne le canal Flexible. Sans cette valeur, vous risquez de comparer deux routes différentes.^[2]

Vérification 3 : valider le contrat des références

Utilisez uniquement des médias que vous possédez ou êtes autorisé à traiter. Chaque URL doit être publique en HTTP(S), le format réel doit être pris en charge et le nombre d'images, de vidéos et de pistes audio doit respecter les limites documentées. Un média non compatible renvoie un 400 synchrone ; ce n'est pas un refus de modération du modèle.^[2]

Vérification 4 : examiner l'erreur de la tâche finale

Interrogez GET /api/v1/tasks/{id} jusqu'à l'état completed ou failed. En cas d'échec, notez error.code, error.message, l'ID de tâche et la requête d'origine. Le code 80006 confirme un échec lié à la politique de contenu, mais ne dit pas si le déclencheur était le prompt, une référence ou la sortie générée.^[3][4]

Vérification 5 : lire la consommation facturée

Lisez usage.credits sur la même tâche finale. Zéro signifie que la réservation a été remboursée ; une valeur positive correspond à des frais après génération documentés comme conservés. Ne déduisez pas la facture du seul message d'erreur.^[3][4]

Pourquoi le code 80006 n'identifie pas le déclencheur

Le contrat d'erreurs public regroupe plusieurs résultats de sécurité sous un même code de workflow. Le prompt, une image de référence, une vidéo de référence ou la sortie générée peuvent déclencher 80006.^[3] Ce code ne prouve ni qu'un hébergeur a réécrit le prompt, ni qu'il utilise un classificateur facial particulier, ni qu'un seuil a changé.

Ne renvoyez pas la même charge utile sans modification. Commencez par revoir les formulations sensibles et chaque média de référence. Si le modèle le permet et que vous appelez directement l'API, content_filter: false sert à tester la route moins restrictive ; il ne désactive toujours pas les contrôles de sécurité.^[2][3]

Faits vérifiables sur la route et ses paramètres

La route est asynchrone. Envoyez la requête à POST /api/v1/videos/generations, conservez l'ID retourné, puis interrogez GET /api/v1/tasks/{id}. L'interrogation ne consomme pas de crédits.^[2][4]

content_filter contrôle une route propre au modèle. Il vaut true par défaut sur la route Seedance 2.5 de reAPI. La valeur false change de canal, pas de tarif, et une tâche peut toujours échouer sur cette route.^[2]

La liste actuelle des résolutions reAPI est 480p, 720p ou 1080p. Vérifiez le fichier obtenu avant de vous fier à une étiquette de résolution plus large chez un revendeur.^[2]

Les limites de référence sont explicites. Le modèle accepte jusqu'à 30 images, 10 vidéos et 10 pistes audio. ByteDance décrit la même capacité de référence multimodale dans son annonce de lancement.^[1][2]

FAQ

Seedance 2.5 est-il sans censure ?

Non. Sur reAPI, content_filter: false sélectionne une route moins restrictive. La documentation précise qu'il ne désactive pas la modération et que les règles en amont peuvent toujours faire échouer la tâche.^[2][3]

Pourquoi le même prompt passe-t-il sur un site et échoue-t-il sur un autre ?

Les résultats ne sont comparables qu'après vérification du point de terminaison, de l'ID exact du modèle, de la charge utile, des références et des réglages de routage. Notez ces valeurs, puis comparez le statut HTTP, l'erreur de tâche et la consommation facturée au lieu de deviner le filtre interne.

Pourquoi mon personnage généré a-t-il été refusé comme une personne réelle ?

Le code générique 80006 ne permet pas de le savoir. Il indique seulement que le prompt, les références ou la sortie générée ont déclenché un contrôle de sécurité. Examinez ces trois entrées avant de modifier le prompt.^[3]

Pourquoi un prompt qui fonctionnait la semaine dernière échoue-t-il maintenant ?

Reproduisez la requête avec l'ID du modèle, la route, la charge utile et les références enregistrés. Comparez ensuite la nouvelle réponse HTTP et l'erreur de tâche à l'ancien relevé. Sans ces données, le changement de résultat ne permet pas d'identifier ce qui a changé.

Quelles résolutions Seedance 2.5 prend-il en charge ?

La route reAPI actuelle accepte 480p, 720p et 1080p. Vérifiez le fichier retourné avant de bâtir un contrat de livraison sur une simple étiquette de résolution.^[2]

Quelle durée peut atteindre une vidéo Seedance 2.5 en une passe ?

Jusqu'à 30 secondes.^[1]

Puis-je utiliser le visage d'une personne réelle comme référence ?

Le contrat de requête reAPI autorise ce type de référence et l'examine automatiquement, mais l'acceptation du fichier ne vous accorde ni consentement ni droit à l'image. N'utilisez que des médias que vous êtes autorisé à traiter.^[2]

Lire un refus au lieu de le deviner

Un refus est un point de données concernant une charge utile et une route précises. Conservez la réponse au POST, l'ID de tâche, le modèle exact, les paramètres de routage, l'erreur finale et usage.credits. Ces données séparent la validation de l'échec asynchrone et révèlent le coût final sans spéculer sur une couche de modération interne.

Références

1. ByteDance Seed. One-take Creation, Flexible Referencing: Introducing Seedance 2.5. Published 31 July 2026, retrieved August 2026 from seed.bytedance.com/en/blog/one-take-creation-flexible-referencing-introducing-seedance-2-5
2. reAPI. Seedance 2.5 API — route, request parameters, reference limits, content_filter, task flow, and refund behavior. Retrieved August 2026 from reapi.ai/docs/seedance-2-5
3. reAPI. API errors — validation codes and 80006 content-policy handling. Retrieved August 2026 from reapi.ai/docs/api/errors
4. reAPI. Tasks API — status, settled usage, polling, and output contract. Retrieved August 2026 from reapi.ai/docs/api/tasks