yuruyi-ling/douyin-image-check

Pré-audit des images principales des produits Douyin

Objectif : avant que le vendeur ne télécharge l'image principale, identifier ce qui sera rejeté, limité en trafic ou sanctionné par Douyin e-commerce, expliquer clairement les motifs, et fournir une formulation directement remplaçable.

Il y a deux prérequis à toujours garder à l'esprit, et à faire savoir à l'utilisateur dans le rapport :

• C'est un pré-audit, pas un audit officiel de la plateforme. La plateforme juge en fonction du contexte global de la promotion, des paramètres réels du produit et des preuves que le vendeur peut fournir. Une même phrase peut être conforme avec un rapport de test, mais non conforme sans. Par conséquent, de nombreuses conclusions dépendent de la situation réelle de l'utilisateur : il faut demander des précisions ou les indiquer clairement.
• Les règles ont une date. Les règles de cette compétence sont compilées au 2026-11-07 (voir rules-updated dans le frontmatter). Les règles de Douyin sont fréquemment mises à jour. En cas de doute, ou si l'utilisateur a une question, se référer à la dernière version originale sur le centre d'apprentissage Douyin e-commerce, lien dans references/sources.md.

Fichiers de règles

Lire selon les besoins, ne pas tous les importer en une fois :

Fichier	Quand le lire
references/main-image-rules.md	À lire à chaque fois. Spécifications des images principales, exigences de la première image, éléments visuels interdits
references/claim-rules.md	À lire à chaque fois. Infractions textuelles : promesses d'effet, superlatifs, promotions nécessitant des preuves, prix, incitation à des tiers externes
references/cases.md	À lire à chaque fois. Cas de rejet confirmés, utilisés comme référence directe pour des formulations similaires
references/private-cases.md	Lire si le fichier existe. Cas de rejet personnalisés de l'utilisateur, conservés localement uniquement
references/category-security-camera.md	À lire si le produit est une caméra de sécurité, un équipement de surveillance
references/category-template.md	À lire si vous devez organiser les règles pour une nouvelle catégorie
references/sources.md	À lire si vous devez fournir des liens vers les règles officielles ou si l'utilisateur demande « quelle est la base »

Actuellement, seules les règles spécifiques à la catégorie « sécurité et surveillance » sont incluses. Pour les autres catégories, utilisez d'abord les règles générales et indiquez dans le rapport « les règles spécifiques à cette catégorie ne sont pas encore incluses ». Recommandez à l'utilisateur de consulter les « normes de gestion sectorielles » de sa catégorie dans le centre d'apprentissage. Si vous avez accès à Internet, vous pouvez proposer de compiler un nouveau fichier de règles pour cette catégorie.

Processus d'inspection

1. Déterminer l'objet de l'inspection

Recherchez ces informations dans la conversation. Si elles manquent, utilisez des valeurs par défaut sans interrompre l'inspection :

• Catégorie : déterminez-la à partir de l'image. Si impossible, demandez une clarification tout en procédant à l'inspection avec les règles générales.
• Numéro d'image : si l'utilisateur ne le précise pas, suivez l'ordre de réception. La 1ère image est inspectée selon les standards de la première image, qui sont les plus stricts.
• Paramètres réels du produit : par exemple, résolution et nombre de pixels, capacité de la batterie, présence de panneaux solaires, configuration des différentes SKU, politique de flux et de stockage dans le cloud, existence de rapports de test. De nombreuses allégations promotionnelles sont conformes ou non selon qu'elles correspondent à la réalité. Si l'utilisateur ne les a pas fournies, marquez les problèmes associés avec 🟡 et listez-les dans la section « à confirmer avec vous » en fin de rapport.
• S'agit-il de l'image originale ? Les images collées dans une conversation peuvent être compressées, recadrées ou converties. Les conclusions sur la taille, les proportions ou le format, si elles ne sont pas basées sur l'image originale, seront rétrogradées en ⚪, avec un rappel de se fier à l'image originale téléchargée sur Douyin Shop.

2. Examiner l'image et lire tout le texte

Pour chaque image, faites trois choses :

1. Spécifications : si vous pouvez exécuter des commandes, lisez les dimensions réelles en pixels et le format de fichier de l'image, avec n'importe quel outil. Sinon, passez et mentionnez dans le rapport « spécifications de l'image originale non lues ».
2. Composition visuelle : où se trouve le sujet du produit, quelle taille occupe-t-il, est-ce une photo réelle, un rendu 3D ou une image IA ? Y a-t-il des codes QR, filigranes, bordures, boutons de lecture, personnages, objets de comparaison de taille, cartes, logos d'autres marques ou plateformes, éléments sensibles ? Les images de démonstration d'effets et les comparaisons doivent particulièrement être vérifiées pour savoir s'il s'agit de photos réelles du produit. Les icônes aussi doivent être examinées, car elles peuvent être considérées comme des allégations (par exemple, une caméra 4G avec une icône WiFi).
3. Texte : recopiez mot à mot tout le texte visible sur l'image, par zone (coin supérieur gauche, centre, côté droit, bande inférieure…), y compris les indices, petits caractères et légendes à côté des icônes. Si un caractère est illisible, écrivez « [illisible] ». Ne devinez pas : un seul caractère mal deviné peut inverser la conclusion.

3. Vérifier chaque point par rapport aux règles

• Chaque phrase de texte est comparée à claim-rules.md et au fichier de catégorie.
• La composition et les spécifications de chaque image sont comparées à main-image-rules.md.
• Correspondance texte-image : vérifiez si les slogans ne contredisent pas les illustrations, les étapes ou les tableaux de paramètres sur la même image. Par exemple, si le texte en grand dit « installation sans perçage », mais que les étapes d'installation montrent l'utilisation de vis et de chevilles pour fixer un support.
• Vérification inter-images : le même argument de vente est-il cohérent entre les différentes images ? La configuration montrée sur l'image principale (par exemple « double caméra », « avec panneau solaire », « 8000mAh ») est-elle disponible pour chaque SKU ? Si la SKU la moins chère ne l'a pas, c'est une « triche sur la SKU à bas prix » relevant des infractions de prix.
• Comparaison avec des cas : pour les formulations similaires à celles déjà rejetées dans cases.md et private-cases.md, traitez-les comme 🔴 et notez « similaire au cas XXX ».

4. Classification

Classez en fonction de la « solidité de la preuve », et non de la « gravité du problème » :

• 🔴 Infraction certaine, si au moins un critère est rempli :
  • Le texte original ou des exemples officiels interdisent explicitement un mot, une formulation ou un visuel.
  • Promesse absolue ou garantie sans condition concernant un effet, une performance ou un service. Les « règles détaillées sur la [publicité mensongère] des commerçants » 4.2 interdisent explicitement ce type, par exemple « jamais à court d'énergie », « aucun angle mort », « reconnaissance à 100% ».
  • Les illustrations, étapes ou paramètres de l'image prouvent déjà que cette affirmation n'est pas vraie.
  • La formulation est identique à des cas de rejet confirmés.
• 🟡 Risque potentiel : la règle ne le mentionne pas directement, mais cela relève du même type de risque ; ou la conformité dépend de la capacité de l'utilisateur à fournir des preuves (rapport de test, numéro de brevet, licence, paramètres cohérents). Précisez « peut être conservé avec des preuves, sinon à modifier en 🔴 ».
• ⚪ Possible erreur de jugement : cas où vous n'êtes pas sûr, y compris les caractères illisibles, les termes génériques du secteur pouvant être pris à tort, les mots figurant uniquement sur des listes non officielles en ligne, ou les conclusions basées sur des images non originales.

Si une même phrase enfreint plusieurs règles, fusionnez-la en une seule ligne et mentionnez toutes les bases. Pour ne pas paraître exhaustif, n'allez pas qualifier des descriptions normales de problèmes : trop de faux positifs amèneront l'utilisateur à ignorer les modifications réellement nécessaires.

5. Proposer une modification

Les modifications doivent être directement copiables et suivre le principe de la plateforme envers les commerçants : « écrire ce que c'est ».

• Transformez les promesses en descriptions, les formulations absolues en formulations conditionnelles. Par exemple, « ne s'éteint jamais les jours de pluie » devient « batterie de 8000mAh, alimentation par batterie les jours de pluie (l'autonomie est affectée par la météo et la fréquence d'utilisation) ».
• Si vous avez des données, écrivez les données et les conditions de test ; sinon, supprimez cet argument de vente sans essayer d'en inventer un.
• Pour les affirmations nécessitant des preuves (rapport de test, brevet, licence, distinction), rappelez à l'utilisateur d'inclure ces preuves dans la page détaillée.
• L'image principale ne peut contenir que peu de texte ; les modifications doivent donc être courtes et adaptées à l'image.

Ne suggérez pas d'utiliser des homophones, des caractères chinois en pinyin, des symboles spéciaux, la décomposition de caractères, l'occultation ou des mosaïques pour contourner l'audit. Les règles de la plateforme précisent que ces méthodes de contournement aggravent les sanctions. Ne suggérez pas non plus « d'écrire la promesse en grand caractère et les restrictions en petit caractère dans un coin » : la plateforme a clairement indiqué dans les annonces de gestion de la sécurité et de la surveillance que cette pratique reste non conforme.

6. Générer le rapport

Le rapport doit être aussi court que possible. L'utilisateur envoie souvent 5 images ou plus à la fois ; il doit pouvoir tout voir d'un coup : quel que soit le nombre d'images, le rapport doit tenir en environ 15 lignes.

• Regroupez par problème, pas par image. Un même problème n'est écrit qu'une seule fois, avec indication des images où il apparaît, par exemple « (Img 1, 4) ».
• Chaque problème tient sur une ligne, format fixe : « Texte original » (N° image) → Suggestion de modification | Raison (abréviation de la règle). La raison ne dépasse pas 10 caractères.
• 🔴 Listez tous. 🟡 Maximum 5 lignes, classées par ordre d'impact : les problèmes pouvant entraîner la suspension du produit (interdictions légales, incitations à des tiers) en premier, puis la publicité mensongère, et enfin les problèmes n'affectant que la conformité ou le trafic. Fusionnez les problèmes similaires en une seule ligne, par exemple plusieurs « rapport de test nécessaire » ; s'il en reste trop, résumez par « X autres problèmes mineurs : … ».
• ⚪ Fusionnez en une seule ligne.
• Éléments à confirmer avec vous : maximum 4, choisissez ceux qui impactent le plus la conclusion, une ligne suffit.
• N'écrivez pas les éléments sans problème, la transcription complète du texte sur l'image, les spécifications de chaque image. Les caractères illisibles et les problèmes de spécifications vont dans ⚪. S'il n'y a aucun problème, écrivez simplement « Aucun problème détecté ».
• Si l'utilisateur demande le détail image par image, ligne par ligne, ou le texte intégral extrait, fournissez-le séparément ou exportez-le en CSV (voir étape 7).

Modèle :

## Pré-audit image principale : N images｜🔴 X｜🟡 X｜⚪ X

**🔴 À modifier impérativement**
1. « Surveillance sans interruption 365 jours, jamais sans courant » (Img 1, 3) → Panneau solaire + batterie 8000mAh double alimentation | Promesse absolue (Publicité mensongère 4.2)
2. ……

**🟡 Suggestion de modification**
- « Conversion efficace », « Charge rapide » (Img 1, 2) → Indiquer la puissance du panneau solaire, ou supprimer si aucune donnée | Exagération sans données (Publicité mensongère 4.2)
- 2 autres problèmes mineurs : « sans crainte de la pluie et du vent », texte trop abondant sur la première image

**⚪ Veuillez vérifier** : Img 3 « ne s'arrête jamais les jours de pluie[illisible] » probablement une faute de frappe ; les 4 images sont en WEBP, se fier aux images originales

**À confirmer avec vous** : capacité de la batterie et autonomie réelle mesurée, puissance du panneau solaire, chaque SKU est-elle bien équipée du panneau solaire ?

> Résultat du pré-audit, ne représente pas l'audit de la plateforme ; règles compilées au 2026-11-07.

Utilisez les abréviations suivantes pour les règles. Si l'utilisateur demande plus de détails, donnez le nom complet, avec le lien original dans sources.md :

Abréviation	Nom complet de la règle
Publicité mensongère 4.1 / 4.2 / 4.3	Règles détaillées sur la [publicité mensongère] des commerçants
Norme image principale	Normes de publication des images principales des produits
Infraction de prix	Règles détaillées de traitement des [infractions de prix] des commerçants
Incitation externe	Règles détaillées de traitement de l'[incitation à des tiers]
Interdiction légale	Règles détaillées de traitement de la [publication d'articles interdits/informations interdites] par la loi
Annonce sécurité	Annonce de gestion spéciale des articles de sécurité et de surveillance
Norme sectorielle	Normes de gestion sectorielles [Maison/Électroménager] ou [3C/Numérique]
Cas XXX	Cas dans cases.md ou private-cases.md

7. Exporter le détail en CSV

Exportez le CSV dans deux cas : soit pour une inspection en masse (plusieurs produits ou un dossier complet), soit si l'utilisateur souhaite voir le détail image par image ou ligne par ligne. Le rapport dans la conversation reste court, le détail complet dans le CSV permet à l'utilisateur de le modifier dans Excel et de répartir le travail :

• Nom du fichier preaudit_images_AAAAMMJJ_HHMM.csv, à enregistrer dans le dossier des images ; en cas de doute, enregistrez dans le répertoire de travail actuel. Après l'export, informez l'utilisateur du chemin complet.
• Encodage en UTF-8 avec BOM (U+FEFF) au début du fichier. Sans BOM, les caractères chinois seront illisibles dans Excel.
• Première ligne : en-tête Produit,Fichier image,N° image,Niveau,Texte ou visuel,Emplacement,Problème,Règle,Suggestion de modification
• Chaque problème occupe une ligne. Les images sans problème doivent aussi avoir une ligne avec « Conforme » dans la colonne Niveau, pour faciliter la vérification de l'exhaustivité.
• Si un champ contient une virgule, des guillemets doubles ou un saut de ligne, entourez tout le champ de guillemets doubles et doublez les guillemets doubles à l'intérieur.

Si l'environnement ne permet pas d'écrire un fichier, placez le contenu du CSV dans un bloc de code et demandez à l'utilisateur de l'enregistrer sous forme de fichier .csv.

8. Enregistrer les cas de rejet pour améliorer la précision

Lorsque l'utilisateur envoie une image principale rejetée et le motif du rejet :

1. Suivez le processus ci-dessus pour inspecter et identifier la phrase ou l'élément visuel le plus susceptible d'avoir déclenché le rejet. Les notifications de rejet ne donnent généralement qu'un exemple, sans pointer la phrase exacte, donc précisez qu'il s'agit d'une déduction.
2. Ajoutez ce cas à references/private-cases.md. Si le fichier n'existe pas, créez-le avec comme première ligne « Cas privé local, ne pas soumettre au dépôt public ». Suivez le modèle de references/cases.md. Le nom de la boutique, les liens de produits et les numéros de commande ne sont pas utiles au diagnostic, ne les notez pas.
3. Informez l'utilisateur que le cas a été enregistré et indiquez ce qui a été noté.
4. Si l'environnement ne permet pas d'écrire un fichier, présentez le cas compilé à l'utilisateur et demandez-lui de le sauvegarder lui-même.

private-cases.md est déjà inclus dans .gitignore et ne sera pas rendu public avec le dépôt. Si l'utilisateur souhaite partager un cas, rappelez-lui de supprimer d'abord les informations identifiant la boutique avant de le déplacer dans cases.md.