Pourquoi les annonces HTML5 générées à partir de flux sont refusées par Google Ads, DV360 et Ad Manager

Google Ads plafonne une création display HTML5 importée à 600 KB et à 40 fichiers dans l'archive ZIP, selon la spécification de Google pour les annonces display importées. Display & ; Video 360 autorise jusqu'à 100 fichiers, mais plafonne à 5 MB le poids total téléchargé par le navigateur lors de la diffusion de l'annonce, et limite une même création à 25 cookies et 100 appels HTTP externes, d'après les consignes de DV360 relatives aux créations HTML5. Aucun de ces chiffres n'est secret. Ils sont publiés sur les pages de spécifications de chaque plateforme. Une chaîne de production de créations alimentée par des flux s'y heurte pourtant en permanence, car le ZIP qu'un moteur de templates assemble à partir de quelques milliers de SKU ne se comporte en rien comme celui qu'un designer construit à la main. Ce guide s'adresse à la personne en charge du contrôle qualité des créations sur un compte catalogue : il présente les raisons précises pour lesquelles les annonces HTML5 générées à partir des données d'un flux produits sont refusées par Google Ads, DV360 et Google Ad Manager, et la correction de chacune, afin que vous les détectiez avant la plateforme.

Pourquoi le HTML5 généré à partir de flux échoue plus souvent à la validation que les créations faites à la main

Un designer qui construit une bannière à la main intègre la photo du produit directement dans le ZIP, écrit un seul clickTag et vérifie une fois le nombre de fichiers. Un moteur de templates qui génère la même bannière pour 4 000 SKU répète chaque décision 4 000 fois, et une erreur sans conséquence pour n=1 se démultiplie à grande échelle.

Quatre schémas expliquent l'essentiel des refus. Premièrement, le template référence généralement les images produits par l'URL image_link issue directement du flux, parce que c'est le champ dont dispose déjà le flux, au lieu de télécharger et d'intégrer le fichier, comme l'exige le format ZIP. Deuxièmement, un template qui attribue à chaque état de badge (en stock, en promotion, meilleure vente, stock faible) son propre fichier image multiplie le nombre de fichiers de l'archive avant même l'ajout d'une seule photo produit. Troisièmement, la minification du code pour accélérer la diffusion supprime des métadonnées et obscurcit les variables, y compris la balise meta ad.size exacte et la variable clickTag que les plateformes publicitaires lisent par leur nom. Quatrièmement, chaque outil de la chaîne — la couche d'automatisation créative, la balise d'analytics, le pixel du réseau publicitaire — ajoute son propre script ou cookie, et personne ne teste l'annonce assemblée par rapport au plafond cumulé de la plateforme avant qu'elle ne soit déjà en cours de validation.

Les limites techniques, plateforme par plateforme

Voici les chiffres réellement appliqués. Lorsqu'une plateforme n'a pas publié de limite stricte, nous le précisons au lieu de faire des suppositions.

Sources : spécifications Google Ads des annonces display importées, dépannage des éléments HTML5 des campagnes pour applications Google Ads, consignes DV360 relatives aux créations HTML5, consignes HTML5 de Google Ad Manager.

Cinq causes de refus récurrentes sur toutes les plateformes, et la correction de chacune

1. Des URL d'images absolues au lieu d'éléments intégrés

Le template récupère image_link directement dans le flux et l'écrit tel quel dans le code :

<img src="https://cdn.example.com/feed/sku-4471-a.jpg">

Le validateur d'éléments HTML5 de Google renvoie une erreur spécifique à ce cas pour les bundles d'interstitiels des campagnes pour applications : « Votre annonce HTML5 tente de référencer un élément externe à votre fichier .ZIP. Seules les références à des fichiers internes sont autorisées. » La même règle s'applique, avec un message d'erreur moins explicite, au display standard et à DV360.

Correction : au moment de la génération, récupérez le fichier vers lequel pointe l'URL image_link, réencodez-le dans le ZIP sous un chemin relatif, et référencez ce chemin à la place :

<img src="assets/sku-4471-a.jpg">

2. Un nombre de fichiers qui explose à cause des badges et icônes par variante

Un template comportant six états de badge sur huit formats de création représente 48 fichiers avant l'ajout d'une seule photo produit — déjà au-delà du plafond de 40 fichiers de Google Ads pour le display standard. Sur un catalogue comptant des centaines de promotions actives, c'est la raison la plus fréquente pour laquelle un export par lots échoue alors que le même template avait passé le contrôle qualité sur un jeu de test de cinq produits.

Correction : regroupez les états de badge dans un seul spritesheet ou dans un <symbol> SVG inline référencé par une classe CSS, afin que le nombre de fichiers reste constant quel que soit le nombre d'états de badge ou de formats utilisés par la campagne.

3. Balise meta ad.size manquante ou supprimée

Les étapes de minification conçues pour la vitesse, et non pour la conformité ad tech, suppriment ou réorganisent fréquemment le contenu du <head>, y compris la balise meta de dimensions que les plateformes lisent par son nom exact. Le message d'erreur du validateur de Google Ads dans ce cas est le suivant : « Il manque un fichier .HTML principal à votre annonce HTML5. Les fichiers .HTML principaux incluent une balise de taille d'annonce. » Google Ad Manager exige la même information sous la forme <meta name="ad.size" content="width=300,height=250">.

Correction : effectuez la vérification de la balise meta après la minification, et non avant, et intégrez-la comme contrôle automatique dans la chaîne d'export plutôt que comme vérification ponctuelle manuelle.

4. clickTag codé en dur, manquant ou minifié au point d'être méconnaissable

Un minificateur transforme un gestionnaire de clic lisible en quelque chose comme var a=b(3). Les consignes de DV360 indiquent explicitement que le click tag « doit être facile à lire pour l'ad server » et demandent aux équipes de ne pas le faire passer par un minificateur de code ; Ad Manager exige la même variable, déclarée exactement sous le nom clickTag, dans le head.

Correction : déclarez-la une seule fois, non minifiée, et excluez cette ligne de l'étape de minification : var clickTag = "https://example.com/product/4471";. Ne codez jamais l'URL de destination en dur ailleurs dans le code — Ad Manager ne peut pas attribuer les clics qu'il ne voit pas passer par la variable.

5. Plafond de cookies et d'appels HTTP dépassé par l'empilement des balises de suivi

DV360 plafonne strictement une création à 25 cookies et 100 appels HTTP externes. Chaque balise prise individuellement — un pixel de retargeting, une requête de police web, un appel GA4, le snippet de suivi de la plateforme d'automatisation créative — est conforme. Empilées sur une même annonce assemblée, elles ne le sont plus, et le dépassement n'apparaît que lorsque quelqu'un teste le bundle final plutôt que le template.

Correction : faites passer le suivi par un seul conteneur de gestionnaire de balises par annonce au lieu d'ajouter les pixels un par un, chargez les polices localement plutôt que via une requête externe, et testez le décompte sur un véritable export rendu — et non sur le template —, car les tests au niveau du template sous-estiment les chiffres.

Check-list avant la mise en ligne d'un lot de créations HTML5 générées à partir de flux

• Chaque référence à un élément dans le code est relative à la racine du ZIP, et non une URL absolue pointant vers le CDN du flux.
• Le nombre de fichiers est vérifié sur le ZIP assemblé propre à chaque produit — et non sur le template — et reste sous le plafond de la plateforme cible.
• La balise meta ad.size (ou son équivalent DV360/Ad Manager) est présente et non minifiée après l'étape de génération, et pas seulement avant.
• La variable clickTag est déclarée une seule fois, non minifiée, et constitue la seule destination de clic du fichier.
• Le nombre cumulé de cookies et d'appels HTTP externes est testé sur l'annonce rendue, par rapport au plafond 25/100 de DV360, et non estimé balise par balise.
• Le poids total téléchargé est mesuré à froid, après compression, par rapport à la limite réelle de la plateforme — 600 KB pour le display standard de Google Ads, 5 MB au total pour DV360.

Ce que ce guide ne couvre pas

Il s'agit d'une couche de conformité technique, et non d'une stratégie créative complète. Ce guide ne couvre pas les annonces catalogue dynamiques sociales et natives — emplacements Meta et Instagram, annonces catalogue TikTok — construites à partir du même flux, car elles reposent sur des éléments image et vidéo gérés par le gestionnaire d'annonces catalogue de chaque plateforme, et non sur l'import d'un ZIP HTML5. Pour ce besoin précis, des outils spécialisés conviennent réellement mieux qu'une chaîne HTML5 généraliste : Confect est spécifiquement conçu autour des templates d'annonces catalogue Meta et Google avec une synchronisation horaire des produits, et Hunch est conçu autour des créations dynamiques sociales et vidéo, y compris des variantes hyperlocalisées. Aucun des deux ne produit de bannières display HTML5 conformes aux spécifications IAB, ce qui est précisément le manque que comble ce guide, mais dans leur propre domaine, ils méritent d'être évalués pour ce qu'ils sont.

Ce guide ne couvre pas non plus les tests créatifs ni la mesure des performances — savoir si un template convertit mieux qu'un autre est une discipline distincte de la question de savoir s'il passe la validation technique —, et il ne remplace pas l'examen des règles de contenu d'une plateforme. Corriger chaque point de la check-list ci-dessus évite un refus technique. Cela ne permet pas de faire valider une création qui enfreint sur le fond les règles publicitaires d'une plateforme.

Questions fréquentes

Quelle est la taille de fichier maximale d'une annonce display HTML5 dans Google Ads ?

Pour les annonces display importées standard, le fichier ZIP doit faire 600 KB ou moins et contenir au maximum 40 fichiers. Les éléments interstitiels HTML5 des campagnes pour applications suivent une spécification distincte : jusqu'à 5.2 MB et 512 fichiers, mais uniquement aux dimensions 320×480 ou 480×320.

Pourquoi DV360 mesure-t-il le poids total téléchargé plutôt que la taille du ZIP ?

Parce qu'un ZIP peut se décompresser en un ensemble de fichiers beaucoup plus volumineux une fois rendu par le navigateur. DV360 plafonne à 5 MB le poids réellement téléchargé par le navigateur du visiteur lors de la diffusion de l'annonce, ce qui reflète plus fidèlement l'impact réel sur le chargement que la taille de l'archive compressée.

Une annonce HTML5 générée à partir d'un flux peut-elle référencer des polices ou des images externes ?

En général, non. Le display standard de Google Ads n'autorise les références externes qu'à Google Fonts et à une courte liste de bibliothèques hébergées par Google (CreateJS, GSAP, jQuery) ; tout le reste, y compris chaque image produit, doit être intégré au ZIP avec un chemin relatif.

Pourquoi une annonce HTML5 réussit-elle les tests en local mais échoue-t-elle à la validation de la plateforme ?

Les tests en local portent généralement sur le code source avant minification et compression, et non sur le ZIP exact qui est importé. La minification peut supprimer la balise ad.size ou altérer la variable clickTag après la réussite du test local : les contrôles doivent donc porter sur le livrable final.

La limite de 40 fichiers s'applique-t-elle par produit ou par campagne ?

Par ZIP de création individuel. Un export par lots qui génère un ZIP par SKU doit respecter le plafond pour chacun d'eux, individuellement — la limite ne se calcule pas en moyenne sur le nombre total de fichiers d'une campagne.

Quelle est la différence entre la spécification HTML5 des campagnes pour applications et celle du display standard ?

Ce sont deux spécifications distinctes, avec des limites différentes et destinées à des inventaires différents. Les annonces display importées standard sont plafonnées à 600 KB et 40 fichiers, avec des dimensions flexibles ; les interstitiels HTML5 des campagnes pour applications autorisent jusqu'à 5.2 MB et 512 fichiers, mais uniquement dans deux dimensions fixes, portrait et paysage. Appliquer les hypothèses d'une spécification aux emplacements de l'autre est une source fréquente de bundles refusés.

Ces règles sur les fichiers et le clickTag s'appliquent-elles aux créations vidéo générées à partir du même flux ?

Non — les éléments vidéo suivent les spécifications vidéo de chaque plateforme (encodage, durée, format d'image), et non les règles de ZIP HTML5 présentées dans ce guide. Une chaîne alimentée par des flux qui produit à la fois des vidéos et du HTML5 nécessite un contrôle qualité distinct pour chacun.

Comment tester le nombre de cookies et d'appels HTTP avant l'import dans DV360 ?

Affichez la création assemblée dans un navigateur avec les outils de développement ouverts, chargez l'annonce dans un onglet isolé et comptez les cookies réellement déposés et les requêtes réellement émises dans le panneau réseau. Tester le template isolément, avant que les balises de suivi ne soient injectées lors de la génération, sous-estimera les deux.

Si maintenir cette couche de conformité à la main n'est pas une bonne utilisation du temps de votre équipe, découvrez comment le Creative Suite de Feedance génère des créations prêtes pour chaque canal directement à partir de votre flux produits — bannières statiques, vidéo et HTML5 —, en complément de l'enrichissement de flux pour les données produits sous-jacentes. Karaca a utilisé la même approche du flux à la création pour produire 10 000 créations Black Friday à ses couleurs en deux heures. Parlez-nous de votre catalogue et de votre taux de refus actuel.