Seedance 2.0 "Not Eligible" : causes et solutions efficaces

Si Seedance 2.0 appose sans cesse la mention "Not eligible" sur votre image de référence, vous ne subissez pas de limitation de débit et vous n’avez pas dépassé une limite cachée. Vous déclenchez un contrôle de contenu que ByteDance applique au niveau du modèle. Ses deux motifs documentés sont les visages de personnes réelles et la propriété intellectuelle protégée^[1]. Les interfaces peuvent présenter cette règle différemment, ce qui rend parfois l’erreur peu claire.

Cet article rassemble ce qui est réellement consigné : les règles d’éligibilité et les codes d’erreur de ByteDance, les contrôles effectués par les interfaces, les détails du modèle et du fournisseur à vérifier, et les voies légitimes qui fonctionnent lorsque votre projet implique de vraies personnes.

En bref

• "Not eligible" désigne la détection des visages et de la propriété intellectuelle. L’interface de Higgsfield explique elle-même l’échec par "This image contains faces or IP and cannot be used" et rembourse les crédits^[2][3].
• La règle vient de ByteDance, pas de la plateforme. La documentation officielle de l’API précise que les modèles Seedance 2.0 "do not support direct upload of reference images or videos containing real human faces"^[1].
• Il n’existe aucun interrupteur pour la modération. L’API officielle de Seedance 2.0 n’expose aucun paramètre de sécurité ; les entrées comme les sorties sont contrôlées^[1][4].
• Si le comportement semble changer, vérifiez le modèle exact. Dreamina applique la restriction sur les visages réels à Seedance 2.0 et 2.0 Fast, mais pas à l’ancien Seedance 1.5 Pro^[5] ; les politiques publiées peuvent aussi varier selon le modèle^[2].
• Des voies légitimes existent : ByteDance documente trois parcours d’exemption, dont un canal d’importation avec consentement vérifié^[6], et l’offre Seedance de reAPI compatible avec les visages est précisément conçue pour ce flux de travail.
• Ne tentez pas de neutraliser le contrôle. La politique d’utilisation acceptable interdit le contournement des filtres de sécurité^[8], et le processus documenté contrôle également les sorties^[6].

Ce que signifie réellement "not eligible"

Higgsfield est l’endroit où la plupart des utilisateurs rencontrent cette erreur, commençons donc par là. La plateforme soumet chaque référence à un contrôle de contenu comportant trois états, dont les libellés sont sans ambiguïté : "Checking content…", "Eligible", "Not eligible". En cas d’échec, l’interface en donne la raison : "This image contains faces or IP and cannot be used" ou, pour les générations, "This generation may involve protected IP or likeness rights"^[2]. Le pipeline comporte même une étape dédiée à la détection de propriété intellectuelle. Les requêtes signalées ne sont pas facturées ; la documentation de Higgsfield confirme que les crédits sont automatiquement restitués^[3].

L’erreur n’a donc rien à voir avec la qualité ou le format de l’image, ni avec l’état de votre compte. C’est un verdict sur le contenu : le système estime que votre référence contient le visage d’une personne réelle ou un élément protégé appartenant à un tiers.

La règle sous-jacente : ni visage réel ni propriété intellectuelle protégée

La source principale est la documentation de l’API de ByteDance, qui l’énonce clairement : les modèles de la série Seedance 2.0 "do not support direct upload of reference images or videos containing real human faces"^[1]. Le catalogue des codes d’erreur est tout aussi explicite. InputImageSensitiveContentDetected.PrivacyInformation signifie que l’entrée "may contain real person" ; la variante .PolicyViolation signale un contenu qui "may be related to copyright restrictions"^[4].

Le produit grand public suit la même logique. Lorsque CapCut a déployé Seedance 2.0 dans Dreamina à l’échelle mondiale, son communiqué a indiqué que le lancement était "restricting certain capabilities… including the ability to make videos from images or videos that contain real faces", avec une technologie "designed to block the unauthorized generation of intellectual property" et un filigrane invisible sur les résultats^[5]. Dans le sélecteur de modèles de Dreamina, Seedance 2.0 porte la mention catégorique "Real human faces are not supported".

La raison n’a rien de mystérieux non plus : le lancement de Seedance 2.0 s’est heurté à des litiges de droits d’auteur avec les studios suffisamment graves pour que ByteDance suspende le déploiement mondial pendant un mois^[7]. La responsabilité liée aux deepfakes, ajoutée aux litiges de propriété intellectuelle, conduit à un filtre strict aux frontières du modèle.

À retenir : il n’existe aucun bouton. Les paramètres de l’API officielle ne comportent aucun réglage de modération ; le contrôle s’applique aux entrées comme aux sorties. La politique d’utilisation acceptable que vous acceptez interdit de représenter "a person (living or dead)'s voice or likeness without appropriate consent" ainsi que toute tentative de contournement des filtres de sécurité^[8].

Pourquoi un même flux peut sembler incohérent

Avant de renvoyer la même ressource, vérifiez deux différences documentées.

Des modèles différents, des règles différentes. Dans Dreamina, la mention "real faces not supported" apparaît pour Seedance 2.0 et 2.0 Fast, mais pas pour l’ancien Seedance 1.5 Pro^[5]. Si un flux fonctionnait auparavant, vérifiez le modèle et la version réellement sélectionnés.

Les politiques publiées varient selon le modèle. La page de confiance de Higgsfield précise que la modération "is applied at the model level" et que les "content policies may vary depending on the model being used"^[2]. Comparez le modèle exact et les règles publiées par le fournisseur au lieu de supposer que deux modes aux noms proches sont équivalents.

Une autre confusion mérite d’être dissipée : l’expression "visual restriction" n’est pas définie dans les documents ByteDance ou CapCut cités ici. Appuyez-vous sur la restriction documentée concernant les visages et la propriété intellectuelle plutôt que de traiter cette expression comme une autre erreur technique.

Les voies légitimes qui fonctionnent

Commencez par la distinction essentielle : votre sujet est-il une personne réelle, ou le détecteur se trompe-t-il sur un personnage synthétique ?

Si votre personnage est synthétique mais reste signalé, vérifiez d’abord le modèle et le mode d’entrée exacts. Dreamina documente la restriction sur les visages réels pour Seedance 2.0 et 2.0 Fast, mais pas pour Seedance 1.5 Pro^[5], tandis que Higgsfield indique que les politiques de contenu varient selon le modèle^[2]. Ces différences publiées offrent une base plus fiable pour acheminer la ressource que des tentatives répétées de modifier le contrôle.

Si votre sujet est une personne réelle, la solution repose sur une infrastructure de consentement, pas sur des astuces. La documentation de ByteDance décrit trois canaux d’exemption : un contenu que la plateforme a elle-même généré pour votre compte au cours des 30 derniers jours peut être considéré comme une entrée fiable ; une bibliothèque d’avatars virtuels prédéfinis ; et une voie vérifiée où l’identité et l’autorisation d’une personne réelle sont confirmées, après quoi son contenu est référencé au moyen d’un identifiant de ressource dédié^[6]. Cette dernière option est la réponse officielle à la question « comment créer des vidéos de moi-même ? ».

Sur reAPI, l’offre Seedance 2.0 compatible avec les visages est conçue pour les flux de référence impliquant de vraies personnes lorsque vous disposez de leur consentement et des droits nécessaires. Son tarif est supérieur à celui de l’offre standard, avec la même facturation à la seconde et le même changement de modèle en une ligne. Les générations échouées sont automatiquement remboursées : un refus inattendu ne vous coûte donc que du temps.

Ce qu’il ne faut pas faire : masquer un visage ou tenter autrement de neutraliser le contrôle. Les conditions d’utilisation acceptable interdisent le contournement des filtres de sécurité^[8], et le processus documenté contrôle également les sorties^[6]. Construisez votre flux sur les voies autorisées et l’erreur cessera d’en faire partie.

Questions fréquentes

Que signifie "not eligible" dans Seedance 2.0 ?

La référence que vous avez importée a échoué au contrôle des visages humains réels ou de la propriété intellectuelle protégée. L’interface de Higgsfield le dit explicitement : "This image contains faces or IP and cannot be used"^[2]. ByteDance documente la règle d’entrée sous-jacente dans sa propre documentation d’API^[1].

Pourquoi Seedance 2.0 bloque-t-il mon personnage généré par IA ?

La documentation publiée n’explique pas les décisions individuelles du classificateur. Confirmez que la ressource est synthétique, puis vérifiez le modèle exact et la politique du fournisseur : Dreamina documente des restrictions différentes pour Seedance 2.0 et l’ancien Seedance 1.5 Pro^[5], et Higgsfield précise que les politiques de contenu peuvent varier selon le modèle^[2].

Qu’est-ce que la "visual restriction" de Seedance 2.0 ?

Une expression non officielle qui n’est pas définie dans les documents ByteDance ou CapCut cités ici. Utilisez plutôt la restriction documentée : aucun visage réel ni aucune propriété intellectuelle protégée dans le contenu de référence^[1][5].

Puis-je désactiver la modération de contenu de Seedance 2.0 ?

Non. L’API officielle ne comporte aucun paramètre de modération, le contrôle s’applique aux entrées et aux sorties, et la politique d’utilisation acceptable interdit de le contourner^[4][8].

Quelle plateforme impose le moins de restrictions à Seedance ?

Il n’existe pas de réponse unique et fiable pour tous les modèles. ByteDance documente la restriction d’entrée de Seedance 2.0 au niveau de l’API^[1], tandis que Higgsfield indique que les politiques de contenu peuvent varier selon le modèle^[2]. Comparez le modèle exact et les règles publiées par le fournisseur ; pour travailler avec une personne réelle, utilisez le canal documenté fondé sur le consentement^[6].

Les générations refusées pour "not eligible" sont-elles facturées ?

En général, non. Higgsfield rembourse automatiquement les requêtes signalées^[3], et les tâches échouées sont également remboursées automatiquement sur reAPI.

Pourquoi les célébrités sont-elles bloquées, même dans les images stylisées ?

Les sources publiées ne décrivent aucun mécanisme distinct de reconnaissance des célébrités. Elles indiquent seulement qu’une génération peut impliquer des droits liés à la propriété intellectuelle ou à l’image^[2], et que Seedance emploie une technologie destinée à bloquer la génération non autorisée de propriété intellectuelle^[5].

Comment créer des vidéos Seedance 2.0 avec mon propre visage ?

En passant par la voie du consentement vérifié : la documentation de ByteDance décrit la vérification de l’identité et de l’autorisation, après quoi votre contenu est référencé par un canal de ressources dédié^[6]. L’offre de reAPI compatible avec les visages prend en charge les flux de référence impliquant de vraies personnes pour les utilisateurs de l’API qui détiennent le consentement du sujet.

Concevoir avec les règles, pas contre elles

La documentation décrit l’erreur "not eligible" comme l’effet d’une règle de modèle sur les visages et la propriété intellectuelle, mise en place dans un contexte de surveillance accrue des droits d’auteur. La combattre gaspille du temps et enfreint les conditions ; la comprendre transforme l’erreur en décision de routage. Pour un sujet synthétique, vérifiez le modèle et le mode d’entrée exacts ; pour une personne réelle, utilisez les canaux de consentement. L’offre Seedance 2.0 de reAPI compatible avec les visages transforme cette voie autorisée en appel d’API.

Références

1. BytePlus (ByteDance). ModelArk — règles d’entrée de Seedance 2.0 ("do not support direct upload of reference images or videos containing real human faces"). Consulté en juillet 2026 sur docs.byteplus.com/en/docs/ModelArk/1520757
2. Higgsfield. Page de confiance et sécurité et textes de l’interface de production ("Not eligible", "contains faces or IP"). Consulté en juillet 2026 sur higgsfield.ai/trust
3. Higgsfield. FAQ de la documentation de l’API — les requêtes signalées ne sont pas facturées. Consulté en juillet 2026 sur docs.higgsfield.ai/docs/help/faq
4. BytePlus (ByteDance). ModelArk — codes d’erreur de modération du contenu (PrivacyInformation, PolicyViolation). Consulté en juillet 2026 sur docs.byteplus.com/en/docs/ModelArk/1299023
5. Salle de presse de CapCut. Déploiement mondial de Dreamina Seedance 2.0 — restrictions sur les visages et la propriété intellectuelle, filigrane invisible. Consulté en juillet 2026 sur capcut.com/newsroom/dreamina-seedance-2
6. BytePlus (ByteDance). ModelArk — exemptions pour les entrées fiables et canal de ressources avec consentement vérifié. Consulté en juillet 2026 sur docs.byteplus.com/en/docs/ModelArk/2291680
7. Reuters. ByteDance suspend le lancement d’un modèle d’IA vidéo après des litiges de droits d’auteur. Consulté en juillet 2026 sur reuters.com/technology/bytedance-suspends-launch-video-ai-model
8. BytePlus. Politique d’utilisation acceptable de l’IA générative. Consulté en juillet 2026 sur docs.byteplus.com/en/docs/legal/acceptable_use_policy_byteplus_genai

Pour aller plus loin

• reAPI. Qu’est-ce que Seedance 2.0 et comment l’utiliser (guide 2026). reapi.ai/blog/what-is-seedance-2-0-and-how-to-use-it
• reAPI. Documentation de l’API Seedance 2.0. reapi.ai/docs/seedance-2-0
• CapCut. Règles de la communauté Dreamina. capcut.com/clause/dreamina-community-guidelines