Donnez 300 publicités concurrentes à un modèle, il vous répondra par quatre adjectifs : faites plutôt ceci

Vous récupérez trois cents accroches de concurrents dans une bibliothèque publicitaire publique. Votre objectif : comprendre ce qu’ils cherchent réellement à vendre. Le réflexe le plus courant consiste à tout coller dans une fenêtre de chat et à demander : « résume les arguments de vente de ces publicités ». La réponse tombe vite : bon rapport qualité-prix, priorité à l’expérience utilisateur, sentiment d’urgence, tonalité émotionnelle positive. Quatre lignes que vous auriez pu écrire sans lire une seule annonce.

Le problème ne vient pas des données. Les bibliothèques publicitaires et creative centers des plateformes sont publics, vous pouvez les consulter avec votre propre compte, sans rien contourner. Le problème tient à la question posée. Vous demandez une analyse agrégée ; le modèle vous renvoie donc une réponse agrégée. Réduire trois cents publicités à quatre adjectifs, c’est appliquer un taux de compression tel que toute l’information utile disparaît. Il ne reste que des banalités à la fois vraies et inutilisables.

Pour tirer quelque chose d’exploitable d’une analyse massive de textes publicitaires, il faut d’abord définir ce qu’est un résultat exploitable. « Met en avant le rapport qualité-prix » ne permet rien de concret. En revanche, « promesse d’économies, preuve chiffrée et limite temporelle, une combinaison présente dans 40 % de cet échantillon et ciblant les publics sensibles au prix » vous indique directement quels paramètres régler pour votre prochain asset. Pour arriver à ce second niveau de lecture, une seule passe ne suffit pas : il faut découper le travail en deux étapes.

Pourquoi demander un résumé des arguments de vente produit toujours du flou

L’échec de l’approche en une seule étape est structurel ; il ne vient pas d’un prompt mal rédigé.

Vous demandez simultanément au modèle deux tâches de nature très différente : extraire l’information de chaque publicité, puis classer cette information. L’extraction est déterministe. Quelle promesse l’annonce formule-t-elle ? Apporte-t-elle une preuve ? Les réponses sont en grande partie univoques. La classification, elle, suppose un jugement : quelles promesses appartiennent à la même catégorie, et où placer la frontière entre deux catégories ? En tassant ces deux opérations dans un seul appel, le modèle prend le raccourci : il saute l’extraction annonce par annonce, se fait une impression générale d’un mur de texte et produit une collection d’adjectifs positifs qu’il pense devoir vous servir.

L’approche en une passe ne laisse en outre aucune trace intermédiaire. Vous obtenez « met en avant le rapport qualité-prix », mais sans pouvoir remonter aux annonces à l’origine de ce constat, connaître leur part dans l’échantillon ou vérifier l’existence de contre-exemples. Relancez l’analyse sur un autre lot, la conclusion changera. Une analyse sans produit intermédiaire ne peut être ni auditée ni améliorée.

La bonne méthode : extraire les champs, puis les regrouper

La méthode efficace repose sur deux étapes séparées par une couche de données structurées.

Première étape : extraire, pour chaque texte pris isolément, des champs définis dans un schéma fixe. Il faut au minimum quatre dimensions : la promesse centrale, le type de preuve, le mécanisme d’urgence et l’audience implicite. Cette étape traite une publicité à la fois et renvoie du JSON strict, sans texte explicatif.

You will receive one ad headline. Break it apart along the fixed fields below.
Output JSON only, no explanation.

<copy>
{{one piece of copy}}
</copy>

Fields and allowed values (pick only from the given enum; when unsure pick
unknown; do not invent values):

- promise: [save money, save time, look better, get healthier, make money,
  learn a skill, belong, identity, unknown]
- evidence: [testimonial, data/numbers, authority, before/after, demo,
  none, unknown]
- urgency: [time limit, scarcity, price-rise warning, fear of missing out,
  none, unknown]
- audience: a short phrase, inferred from the wording, for who it's talking to
  (e.g. "night owls", "moms with kids", "junior designers")

Output:
{"promise":"...","evidence":"...","urgency":"...","audience":"..."}

Après extraction sur trois cents annonces, vous avez trois cents enregistrements structurés plutôt que trois cents blocs de texte. À ce stade, « résumer les arguments de vente » cesse d’être une tâche sémantique floue : c’est devenu un jeu de données que vous pouvez compter, regrouper et représenter sous forme de distribution.

La deuxième étape consiste à regrouper les champs, non les textes d’origine. Regrouper le texte brut vous ramènerait à la même brume de similarité sémantique. Avec les champs, le regroupement s’appuie sur quelques dimensions discrètes dont les frontières sont explicites.

Le prompt de regroupement doit exiger un contre-exemple

Le point décisif du prompt n’est pas « regroupe ces données ». C’est l’obligation faite au modèle de produire un contre-exemple.

Below are N ad headlines already extracted into structured records.
The categories are frozen. Do not add categories.

<records>
{{JSON array, each with promise/evidence/urgency/audience}}
</records>

Output three things in order:

1. Combination clustering
   Group by (promise x evidence x urgency), and give each group's record
   count and one representative sample.

2. Counterexample check
   For the top 3 groups by record count, pick one record per group whose
   audience clearly departs from the group's mainstream, and explain why it
   got grouped there. Is it really the same selling point, or did step one
   extract a field wrong?

3. Gaps
   Which combinations that should be common don't appear even once in this
   batch? Are those gaps "nobody's doing it" or "my sample didn't cover it"?

C’est la deuxième partie qui donne toute sa valeur au prompt. Un modèle cherche naturellement à vous satisfaire. Si vous ne le contraignez pas, chaque cluster qu’il produira semblera suspectement cohérent. Lui demander d’extraire d’un groupe qu’il vient de former une annonce qui cadre mal l’oblige à continuer la vérification au-delà du moment où il se considère arrivé à une réponse. Soit il révèle une frontière de classification trop large, soit il montre qu’un champ a été mal extrait lors de la première étape.

Cette pratique, qui consiste à demander au modèle de mettre à l’épreuve son propre travail, ne se limite pas à l’analyse publicitaire. En rétro-ingénierie de code, on parle de section de contre-preuves : lorsqu’un modèle reconnaît une famille d’algorithmes, on ne le croit pas sur parole ; on lui demande « en quoi cela diffère-t-il de l’implémentation standard ? ». Le principe est le même. C’est aussi ce qui limite la tendance du modèle à vous donner raison lorsqu’il s’agit de traiter du code obfusqué ou d’identifier l’empreinte d’algorithmes. Pour le regroupement de textes publicitaires, le contrôle par contre-exemple joue ce rôle.

Un modèle différent pour chaque étape

Les deux étapes demandent des capacités opposées. Utiliser le même modèle pour tout revient donc à gaspiller des ressources :

L’écart de coût d’un ordre de grandeur vient précisément de cette répartition. L’extraction des champs est la seule étape qui augmente linéairement avec le volume : trois cents publicités impliquent trois cents appels, mille publicités en impliquent mille. Le regroupement ne s’exécute qu’une fois par lot. Placez le niveau de raisonnement le plus coûteux sur le regroupement, exécuté une ou deux fois, et le niveau le moins cher sur l’extraction, exécutée des centaines de fois : la facture totale peut alors être divisée par dix. Faites l’inverse — niveau coûteux pour l’extraction, niveau économique pour le regroupement — et vous obtenez le gaspillage le plus fréquent que j’observe : l’extraction n’a pas besoin d’autant de raisonnement, tandis que le regroupement échoue précisément là où le modèle bon marché est le plus faible.

Pour mesurer les économies possibles avec ce déclassement de modèle, ne me croyez pas sur parole : faites un essai.

1. Prenez 20 à 30 publicités parmi celles que vous avez déjà collectées.

2. Extrayez les champs : passez le même lot dans claude-sonnet-5 et claude-opus-5, puis comparez les quatre champs enregistrement par enregistrement afin de mesurer leur concordance.

3. Regroupez : utilisez les mêmes enregistrements extraits avec les deux niveaux de modèle et examinez deux points. Le contrôle des contre-exemples interroge-t-il vraiment les groupes ou se contente-t-il de reformuler le cas candidat ? Les lacunes débouchent-elles sur une action concrète ?

4. La décision devient évidente : si la concordance est élevée lors de l’extraction, basculez cette étape vers le niveau économique pour réduire les coûts ; si ce niveau ne produit pas de contre-exemple utile au regroupement, cette étape doit rester sur le niveau de raisonnement.

Premier piège : laisser le modèle inventer ses catégories

Le piège le plus simple consiste à ne pas fournir d’enum lors de l’extraction et à laisser le modèle créer ses propres catégories.

Sur un premier lot, cela paraît fonctionner. Le modèle propose des catégories plausibles. Le problème apparaît avec le deuxième lot : les mêmes types de textes donnent lieu à d’autres noms de catégories, un niveau de granularité différent, des frontières déplacées. Vous essayez de comparer les deux lots pour observer une tendance et découvrez qu’ils ne s’alignent plus. Le « discount » du premier lot équivaut-il au « save money » du second ? Personne ne peut le dire. Dès que les catégories dérivent d’un lot à l’autre, toute comparaison inter-lots devient artificielle.

La solution est de séparer la définition des catégories de leur utilisation. Commencez par employer le niveau à contexte long pour lire un vaste lot d’échantillons en une seule passe — des centaines à la fois, ce qui correspond exactement à son rôle — et induire un ensemble d’enums à la fois complet et cohérent en matière de granularité. Vérifiez-le ensuite manuellement et figez-le. À partir de là, l’extraction ne peut choisir que dans cet enum immuable, avec unknown comme valeur fourre-tout ; elle ne doit jamais inventer une catégorie à la volée. La ligne du prompt d’extraction « pick only from the given enum, do not invent » traduit concrètement cette contrainte.

En une phrase : vous définissez les catégories ; le modèle se contente de remplir les cases.

Deuxième piège : confondre fréquence et efficacité

Une fois les champs extraits et regroupés, vous aurez spontanément tendance à trier par nombre d’enregistrements et à traiter l’argument de vente le plus fréquent comme le plus efficace. C’est une erreur discrète, mais fondamentale.

Une fréquence élevée signifie seulement que tout le monde écrit de cette façon. Elle ne prouve pas que cette façon d’écrire fonctionne. L’effet d’imitation existe bel et bien en publicité : une annonce performe, puis, en l’espace d’une semaine, tout le secteur s’engouffre dans la brèche et des dizaines d’accroches identiques apparaissent du jour au lendemain dans le creative center. Votre décompte intègre alors tous ces imitateurs et conclut que cet argument de vente est le plus répandu, alors que ces publicités peuvent échouer collectivement sans que personne ne soit encore passé à autre chose. La fréquence mesure le conformisme, pas l’effet.

Pour dissocier fréquence et efficacité, il faut rattacher des données de performance à chaque enregistrement. Chaque asset d’une bibliothèque publicitaire publique comporte des champs comme le nombre de lectures, les mentions J’aime, le CTR ou d’autres indicateurs de ce type. Ce qu’il faut réellement classer est « la part d’une combinaison donnée d’arguments de vente qui atteint un percentile de performance élevé », et non le simple nombre d’enregistrements. La façon d’interpréter la rétention seconde par seconde et les percentiles de CTR pour en tirer un signal utile fait l’objet d’un autre article. Retenez ici un point : le tableau des fréquences et le tableau des effets doivent rester deux tableaux distincts. Dès que vous les fusionnez, la conclusion est faussée.

À cette étape, le rôle du modèle est l’attribution, pas le tri. Donnez au niveau de raisonnement intermédiaire une combinaison très fréquente accompagnée de sa distribution de performance, puis demandez-lui : « cette fréquence est-elle élevée parce que cela fonctionne, ou parce que les annonceurs s’imitent ? ». Il doit trancher à partir des chiffres. Une erreur d’attribution coûte peu, puisque vous validez de toute façon le résultat final avec les données de performance réelles.

Troisième piège : n’analyser que les gagnants

Le troisième piège est enfoui dans la source de données, au point de passer facilement inaperçu : les bibliothèques publicitaires et creative centers vous montrent par défaut les campagnes qui ont bien tourné. Des rubriques comme « hot ads » ou « Top Ads » regroupent, en pratique, des survivantes déjà filtrées par la plateforme selon leurs performances.

Vous regroupez un ensemble de gagnantes, identifiez « les caractéristiques communes des publicités qui réussissent », puis vous les copiez. C’est un cas d’école de biais du survivant : les annonces qui ont échoué peuvent très bien présenter exactement les mêmes caractéristiques. Imaginons que 90 % des gagnantes utilisent une « limite temporelle » ; vous en déduisez que les limites temporelles fonctionnent. Mais si 90 % des annonces ratées les utilisent également, cette caractéristique n’a aucun pouvoir discriminant. C’est simplement une norme du secteur, sans rapport avec la réussite ou l’échec.

La solution consiste à donner un groupe de contrôle aux gagnantes. Une bibliothèque publicitaire publique permet généralement de filtrer par secteur, objectif marketing et fenêtre temporelle. Appliquez les mêmes filtres pour retrouver les assets qui ont généré des impressions mais affichent un engagement clairement faible ; extrayez et regroupez-les à leur tour, puis comparez-les au groupe des gagnantes. Ce qui compte n’est pas « ce que les gagnantes ont », mais l’ensemble différentiel : « ce que les gagnantes ont et que les perdantes n’ont pas ». Seule une caractéristique présente dans cet écart mérite d’être intégrée à votre prochain asset.

Vous n’obtiendrez pas un échantillon complet de perdantes, et ce n’est pas grave. Même un petit groupe de contrôle peu performant est bien plus crédible qu’une conclusion tirée des seules Top Ads.

Le livrable final : une table de variables, pas un résumé

Une fois les deux étapes menées correctement et les trois pièges évités, le résultat final ne doit pas être un paragraphe du type « les concurrents de cet échantillon mettent en avant XX ». Vous retomberiez dans le flou initial. Le bon livrable est une table de variables :

• Les valeurs prises par chaque dimension : promesse, preuve, urgence et audience.

• Les combinaisons déjà validées comme efficaces, présentes dans l’ensemble différentiel et élevées dans le percentile de performance.

• Les combinaisons que personne n’a encore testées, révélées dans la section consacrée aux lacunes.

Cette table peut alimenter directement une tâche de génération. Les combinaisons validées comme efficaces servent à produire des variantes à grande échelle ; les combinaisons vierges deviennent des sondes peu coûteuses. Les variables liées au texte alimentent un modèle textuel pour écrire des scripts, tandis que les variables visuelles et de ton alimentent des modèles d’image et de vidéo pour produire les assets. La chaîne se referme ainsi entre les textes concurrents et votre propre spot final. Cette table de variables est précisément ce qu’exploite l’étape de brief dans le pipeline créatif.

Le regroupement ne sert pas à produire un joli graphique de classification. Il sert à produire cette table qui pilote le prochain lot de production.

Une seule clé pour les quatre niveaux de modèle

Le flux décrit ici mobilise quatre niveaux : un niveau économique et fortement concurrent pour l’extraction, un niveau à contexte long pour définir les catégories, un niveau de raisonnement pour le regroupement et un niveau de raisonnement intermédiaire pour l’attribution. Ils proviennent de plusieurs fournisseurs, avec des SDK, des systèmes d’authentification et des formats d’erreurs différents. Connecter votre client à plusieurs interfaces uniquement pour changer de modèle entre les étapes n’en vaut pas la peine. C’est la vraie raison pour laquelle la plupart des équipes finissent par utiliser un seul modèle pour tout — et retombent dans le gaspillage décrit plus haut : soit un niveau coûteux qui brûle du budget sur l’extraction, soit un niveau économique incapable de produire un contre-exemple lors du regroupement.

AIReiter uniformise cette couche : une seule clé, une seule interface compatible OpenAI, les quatre niveaux disponibles derrière, et un changement de modèle qui se fait en modifiant le champ model dans le corps de la requête.

# Extract fields: the cheap high-concurrency tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "<extraction prompt + one piece of copy>"}]
  }'

# Cluster: switch to the reasoning tier, leave the rest
#   "model": "claude-opus-5"
# Frequency attribution:
#   "model": "gpt-5.6-sol"

Si vous utilisez déjà le SDK OpenAI, pointez base_url vers https://aireiter.com/api/v1 sans rien modifier d’autre. Avec le SDK Anthropic, utilisez POST /api/v1/messages avec la même clé.

Côté tarifs, les modèles Claude bénéficient de 30 % de réduction sur le prix catalogue, et les modèles GPT sont à moitié prix. Cette remise s’applique exactement là où ce flux concentre ses coûts. L’extraction des champs est la seule étape qui augmente linéairement avec le volume : trois cents publicités nécessitent trois cents appels, mille publicités en nécessitent mille. Elle s’exécute sur le niveau Sonnet le moins cher, auquel s’ajoute la réduction de 30 %, et représente l’essentiel des économies. Le regroupement et l’attribution ne s’exécutent que quelques fois par lot ; un niveau de raisonnement y pèse donc peu. La définition des catégories utilise le Kimi K3 à contexte long, accessible avec la même clé, une fois par lot.

• Obtenir une clé API

• Essayer sans inscription : commencez par traiter manuellement quelques publicités, comparez le niveau économique et le niveau de raisonnement sur la concordance d’extraction et les contre-exemples de regroupement, puis automatisez le tout une fois la méthode validée.

Conclusion

Si l’analyse massive de textes publicitaires produit du flou, ce n’est pas parce que le modèle est insuffisant. C’est parce que vous avez compressé extraction et classification dans un seul appel.

Séparez le processus en deux : extrayez des champs structurés pour chaque publicité à partir d’un enum figé, répétez l’opération des centaines de fois sur le niveau économique, puis regroupez les champs et forcez le modèle à fournir un contre-exemple, une seule fois sur le niveau de raisonnement. Gardez les trois pièges en tête : ne laissez pas le modèle inventer ses catégories à la volée, ne confondez pas fréquence et efficacité, et donnez un groupe de contrôle aux gagnantes. Terminez avec une table de variables qui pilote le prochain lot de production, pas avec une formule comme « met en avant le rapport qualité-prix ».

Dans ce flux, le modèle remplit deux rôles distincts : un extracteur économique et un classificateur capable de remettre ses propres conclusions en cause. Utilisez-les séparément, sur les niveaux adaptés, et quelques centaines de publicités vous livreront des enseignements actionnables. Utilisez un seul modèle pour tout, et vous n’obtiendrez que des adjectifs.