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 sont documentés dans les propres règles d’API de l’entreprise : les visages de personnes réelles et la propriété intellectuelle protégée^[1]. Aucune plateforme ne peut le désactiver, et la plupart ne le documentent même pas, ce qui donne à l’erreur un caractère aléatoire.

Cet article rassemble ce qui est réellement consigné : les règles d’éligibilité et les codes d’erreur de ByteDance, les véritables contrôles effectués par les interfaces des plateformes, les raisons pour lesquelles un même visage passe un jour puis échoue le lendemain, 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], et l’équipe de Higgsfield a déclaré publiquement que la détection "is on Seedance 2.0's side"^[4].
• 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 systématiquement contrôlées^[1][5].
• Le fait que « cela fonctionne parfois » a des explications banales : l’ancien Seedance 1.5 Pro n’est pas soumis à la même restriction sur les visages dans Dreamina^[6], les plateformes ajoutent leurs propres filtres et la détection repose sur un seuil, si bien que les images limites changent de verdict d’un essai à l’autre.
• Des voies légitimes existent : ByteDance documente trois parcours d’exemption, dont un canal d’importation avec consentement vérifié^[7], et l’offre Seedance de reAPI compatible avec les visages est précisément conçue pour ce flux de travail.
• Les astuces de contournement qui circulent sur Reddit enfreignent la politique d’utilisation acceptable que vous avez acceptée, et le modèle contrôle de toute façon les sorties une seconde fois^[5].

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.

Et ce verdict ne vient pas de Higgsfield. Lorsque des utilisateurs s’en sont plaints sur Reddit, l’équipe de Higgsfield a répondu directement : "The face detection you're running into is on Seedance 2.0's side, not something Higgsfield controls"^[4]. Toutes les plateformes qui proposent Seedance 2.0 héritent de cette règle.

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"^[5].

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^[6]. 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^[8]. 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é^[9].

Pourquoi la même image passe un jour et échoue le lendemain

Cette incohérence a trois causes documentées ou observables, et aucune ne relève de la chance.

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^[6]. Si un flux « fonctionnait auparavant », il utilisait peut-être un autre modèle ; certaines plateformes changent aussi la version de leur backend sans l’annoncer.

Les plateformes superposent leurs propres filtres. 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]. Les plateformes ajoutent en outre leurs propres contrôles et seuils à ceux de ByteDance. Une même image peut donc recevoir des verdicts différents selon la plateforme.

La détection est probabiliste. Les tests de la communauté révèlent le cas limite le plus frustrant : des visages stylisés, voire entièrement générés par IA, sont régulièrement identifiés comme des personnes « réelles », et les images proches du seuil changent de verdict entre deux tentatives^[10]. Un classificateur à seuil devient instable à proximité de ce seuil. Les ressemblances avec des célébrités semblent passer par une couche de reconnaissance supplémentaire que les astuces de composition ne modifient pas, ce qui correspond à la notion de "protected likeness" employée dans l’interface de Higgsfield^[2].

Une autre confusion mérite d’être dissipée : l’expression "visual restriction" n’a de définition officielle dans aucun document publié par ByteDance ou CapCut. Elle circule dans des articles SEO tiers et désigne, en pratique, la restriction sur les visages et la propriété intellectuelle décrite plus haut. Par ailleurs, Dreamina emploie aussi "not eligible" dans un message de limite d’âge sans rapport avec le contrôle des images.

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é, il s’agit d’un faux positif. Les solutions légitimes relèvent de la composition : évitez les gros plans serrés de type photo d’identité comme référence ; privilégiez des scènes plus larges où le visage occupe moins de place dans le cadre ; et, si la plateforme propose un mode première image en plus d’un mode de référence universel, introduisez le personnage dans la première image, traitée comme le contexte de la scène plutôt que comme une référence faciale. Ces choix modifient ce que voit le classificateur ; ils ne contournent pas une détection correcte.

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é^[7]. 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 : utiliser les grilles superposées et autres astuces de masquage des visages qui circulent sur Reddit. Elles enfreignent les conditions d’utilisation acceptable que vous avez acceptées^[9], le contrôle de sortie analyse de nouveau le résultat dans tous les cas^[7], et les plateformes remboursent les tentatives signalées précisément parce qu’elles s’attendent à ce que le filtre les intercepte. 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]. Le contrôle vient des règles du modèle de ByteDance, et non de la plateforme^[1][4].

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

À cause d’un faux positif. Le détecteur facial estime s’il s’agit d’une personne réelle ; les visages synthétiques photoréalistes se situent près de son seuil et sont donc souvent signalés de manière incohérente^[10]. Pour des sujets réellement synthétiques, un cadrage plus large et un placement dans la première image règlent généralement le problème.

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

Une expression non officielle qui n’est définie dans aucune documentation de ByteDance ou de CapCut. En pratique, elle désigne la restriction documentée : aucun visage réel ni aucune propriété intellectuelle protégée dans le contenu de référence^[1][6].

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^[5][9].

Quelle plateforme impose le moins de restrictions à Seedance ?

Les règles relatives aux visages et à la propriété intellectuelle accompagnent le modèle ; aucune plateforme n’y échappe donc^[4]. Les plateformes ne diffèrent que par les filtres supplémentaires qu’elles ajoutent et par la clarté avec laquelle elles affichent l’erreur. Le véritable levier n’est pas de changer de plateforme, mais d’utiliser les canaux fondés sur le consentement pour travailler avec des personnes réelles^[7].

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 ?

La protection de l’apparence semble fonctionner comme une couche de reconnaissance supplémentaire au-delà de la détection faciale générique, conformément à la formulation "protected IP or likeness rights" des interfaces des plateformes^[2]. Les changements de composition ne l’affectent pas, par conception.

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é^[7]. 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

Chaque histoire de "not eligible" suit le même schéma : un filtre au niveau du modèle, documenté par ByteDance et hérité par toutes les plateformes, qui fait exactement ce que son propriétaire souhaite après une crise liée aux droits d’auteur. Le combattre gaspille des crédits et enfreint les conditions ; le comprendre transforme l’erreur en décision de routage. Les sujets synthétiques appellent des ajustements de composition, les personnes réelles passent par les canaux de consentement, et l’offre Seedance 2.0 de reAPI compatible avec les visages transforme la voie autorisée en appel d’API. Voilà toute la méthode pour éliminer les erreurs not eligible de Seedance 2.0 de votre pipeline.

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. Équipe de Higgsfield (compte officiel). Réponse sur Reddit : "The face detection… is on Seedance 2.0's side." Consulté en juillet 2026 sur reddit.com/r/HiggsfieldAI/comments/1sq1hms
5. 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
6. 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
7. 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
8. 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
9. 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
10. r/Seedance_AI (communauté). La détection des visages bloque même le contenu généré par IA — fil de discussion. Consulté en juillet 2026 sur reddit.com/r/Seedance_AI/comments/1sfp3ag

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