Mesurer et décider

Comment mesurer la visibilité d’une marque dans les IA ?

Publié le · Mis à jour le · Par Qui est prems

Sommaire

Pour mesurer la visibilité d’une marque dans les IA, on pose à plusieurs moteurs (ChatGPT, Gemini, Claude, Perplexity) des questions d’acheteur qui ne nomment pas la marque, plusieurs fois chacune, dans des conditions fixées et datées. On compte ensuite les réponses qui recommandent la marque pour le besoin posé, extrait recopié à l’appui, et on rapporte ce nombre aux réponses valides du même périmètre. Le résultat décrit une présence observée, pas une note de qualité.

Les définitions de base sont dans qu’est-ce que la visibilité IA d’une marque et SEO et GEO : quelles différences pour une marque.

Les composants d’un protocole de mesure

Chaque composant se fixe avant la collecte et se publie avec le résultat.

ComposantCe qu’on fixePourquoi
Moteurs et modèlesAssistants interrogés, modèle exactUn autre modèle peut répondre autrement
SurfaceAPI ou applicationRéponses parfois différentes
Recherche webCoupée, forcée ou laissée au modèleSans elle, le modèle répond de mémoire
QuestionsTexte exact, langue, aucun nom de marqueUn nom soufflé fausse la mesure
PassagesAppels par question et par moteurLes réponses varient
ComptageRecommandation prouvée par un extraitUne mention n’est pas un conseil
CouvertureRéponses attendues et validesLe dénominateur du résultat
Dates et versionPériode de collecte, version du protocoleComparer à protocole égal

Définir le périmètre

Moteurs, modèles et surfaces

Derrière chaque assistant tourne un modèle précis, que l’éditeur remplace au fil des versions : on le note comme la date. La surface compte autant. L’application grand public et l’API ne donnent pas forcément la même réponse : Anthropic précise que les mises à jour du message système des applications Claude ne s’appliquent pas à l’API. L’application est plus proche de l’écran d’un client ; l’API permet de fixer question, modèle et paramètres, et de refaire la collecte à l’identique.

Recherche web : qui décide ?

Sans recherche, un modèle répond à partir de son entraînement ; avec, il peut lire des pages récentes et les citer. OpenAI, Google, Anthropic et Perplexity proposent chacun un outil de recherche web dans leur API, et leurs documentations décrivent le même principe : l’outil activé, le modèle décide lui-même s’il cherche, selon la question. Claude, par exemple, répond sans chercher quand la question relève de connaissances stables.

Ce choix se règle : OpenAI permet de rendre la recherche obligatoire, Anthropic de l’orienter par un message système. Couper, forcer ou laisser faire donnent trois protocoles distincts. Chaque API signale les recherches effectuées et les sources citées : on peut ainsi compter, par moteur, les réponses produites avec recherche.

Choisir questions et moteurs

Des questions d’acheteur, sans le nom de la marque

Une question de mesure décrit un besoin (usage, budget, occasion, contrainte) comme le formulerait quelqu’un qui ne connaît pas la marque. Si elle contient le nom, elle mesure surtout la capacité du moteur à reprendre un nom soufflé. Son texte est figé, et le même panel sert pour la marque et ses concurrents, ce qui permet la comparaison avec les concurrents. Côté moteurs, on retient ceux qu’utilise sa clientèle et on lit chaque moteur à part avant d’additionner. Pour un premier test sur un seul assistant : comment savoir si ChatGPT recommande ma marque.

Exemple : question neutre ou question biaisée

Exemple fictif. Une maison de thé veut savoir si les IA la conseillent comme cadeau.

  • Question neutre : « Quel thé vert offrir à un amateur pour moins de 40 euros ? »
  • Question biaisée : « Le thé vert de la Maison X est-il un bon cadeau ? »

La première laisse le moteur choisir ; la seconde lui impose la marque. Même neutre, un panel n’est pas un échantillon des questions réellement posées aux assistants : le résultat ne vaut que pour les besoins testés. La méthode pour écrire, équilibrer et figer ces questions est détaillée dans construire un panel de questions neutres.

Répéter et dater la collecte

Répéter à conditions identiques

Une même question, posée deux fois au même moteur, peut recevoir deux réponses différentes. OpenAI indique que les sorties de ses modèles peuvent différer d’une requête à l’autre ; Google explique que la température règle le degré d’aléa et recommande de garder les réglages par défaut sur Gemini 3. Chaque question se pose donc plusieurs fois, et le résultat s’énonce en nombre de réponses.

  1. Appels indépendants : chaque passage part d’une conversation vide.
  2. Conditions identiques : même texte, même modèle, mêmes paramètres partout.
  3. Dates et versions : période de collecte, modèles, version du protocole ; un changement de modèle se signale avant toute comparaison.

Trois passages montrent la variabilité, sans garantir ni significativité statistique ni représentativité de ce que voient les utilisateurs.

Calculer les indicateurs

Mention, recommandation, citation : ce qui compte

  • Mention : la marque apparaît, quel que soit le contexte (histoire, comparaison, critique, exclusion).
  • Recommandation : la réponse conseille la marque pour le besoin posé.
  • Citation : la réponse renvoie vers une page source.
  • Position : le rang de la marque dans une liste.

Une mesure de visibilité compte les recommandations. Chacune est prouvée par un extrait recopié mot pour mot, puis retrouvé dans le texte d’origine : chaque décision se contrôle. Une marque compte au plus une fois par réponse.

Réponses attendues et réponses valides

Les réponses attendues découlent du protocole : questions × moteurs × passages. Certaines n’aboutissent pas (refus de répondre, appel en échec, réponse tronquée ou inexploitable). Les réponses valides sont celles qui restent ; le résultat se calcule sur elles, le nombre attendu restant affiché. Numérateur et dénominateur portent sur le même périmètre : les recommandations de ChatGPT se rapportent aux réponses valides de ChatGPT, et marque et concurrents se mesurent sur les mêmes réponses.

Exemple fictif : une marque, 12 questions, 4 moteurs, 3 passages, soit 144 réponses attendues.

MoteurRéponses validesRecommandent la marque
Moteur A34 sur 3612
Moteur B36 sur 365
Moteur C35 sur 369
Moteur D35 sur 360
Ensemble140 sur 14426

Lecture : la marque est recommandée dans 26 des 140 réponses valides, et non « 26 sur 144 ». Le zéro du moteur D dit que ses réponses ne la conseillent pas pour ces questions, rien de plus.

Un exemple documenté : le protocole de Qui est prems

Qui est prems, l’Observatoire IA des marques, publie son protocole ; il sert ici d’exemple parmi d’autres choix possibles.

  • Moteurs : ChatGPT, Gemini, Claude et Perplexity, par leur API ; les modèles sont fixés et enregistrés avec chaque mesure.
  • Recherche : activée partout, le modèle décidant seul de s’en servir, sans message système qui l’y pousse ; le nombre de réponses avec recherche se lit par moteur.
  • Appels : indépendants, sans historique ni localisation explicite, paramètres par défaut (sauf la longueur maximale de réponse qu’exige l’API de Claude).
  • Questions : aucune ne nomme la marque ; chacune est posée 3 fois à chaque moteur.
  • Comptage : une recommandation pour le besoin posé, prouvée par un extrait recopié mot pour mot et vérifié ; les résultats portent sur les réponses valides, publiées avec le nombre attendu.

L’étude sur mesure (149 € HT) l’applique à une marque et 1 à 3 concurrents : 12 questions, 4 moteurs, 3 passages, soit 144 réponses attendues, et un rapport sous 4 heures. Ses réponses n’alimentent jamais un classement public. Le détail figure dans la méthodologie ; la méthode du baromètre Cognac applique la même règle de comptage.

Étude sur mesure

Mesurer votre marque dans les réponses des IA

L’étude sur mesure pose 12 questions de votre marché à ChatGPT, Gemini, Claude et Perplexity, trois fois chacune, et compte, face à trois concurrents au plus, les réponses qui recommandent votre marque. 149 € HT.

Lire les limites du résultat

Ce qu’une mesure ne dit pas

  • Pas un verdict de qualité : une recommandation d’IA n’est pas un avis sur les produits.
  • Pas une causalité : une hausse ne prouve pas l’effet d’une action menée entre-temps, ni une source citée son rôle dans la recommandation.
  • Pas un score universel : le résultat vaut pour ces questions, ces moteurs, ces modèles et cette période.
  • Pas l’écran de chaque utilisateur : l’API peut différer de l’application.
  • Pas l’activité commerciale : ni ventes, ni parts de marché, ni volumes de recherche.

Éléments à vérifier avant de décider

  1. Le périmètre est-il écrit (moteurs, modèles, surface, recherche, langue) ?
  2. Les questions sont-elles publiées, sans nom de marque ?
  3. Le résultat donne-t-il ses réponses valides et attendues ?
  4. Chaque recommandation a-t-elle son extrait ?
  5. Dates et version du protocole sont-elles indiquées, et identiques pour toute comparaison ?

Si un point manque, le chiffre reste une indication, pas une base de décision.

Questions fréquentes

Que faut-il fixer avant de lancer une mesure ?

Le périmètre d’abord : les besoins d’acheteur à tester, les moteurs, la surface et le traitement de la recherche web. Puis les questions, qui ne nomment pas la marque, le nombre de passages et la règle de comptage. Un cadre écrit avant la première question évite d’ajuster la méthode au résultat obtenu.

Pourquoi poser chaque question plusieurs fois à chaque moteur ?

Parce qu’une même question peut recevoir des réponses différentes d’un passage à l’autre, comme l’indiquent OpenAI et Google. Une réponse isolée montre ce qu’un moteur a dit une fois, à une date. Plusieurs passages par question et par moteur donnent un résultat en nombre de réponses valides ; tant que les répétitions restent peu nombreuses, il se lit avec prudence.

Comment passer d’une mesure à une décision ?

Séparez trois niveaux. L’observation : tel moteur recommande tel concurrent dans tant de réponses valides, extraits à l’appui. L’hypothèse : une source citée y contribue peut-être, sans preuve de causalité. La décision : ce que vous choisissez de faire, puis de mesurer à nouveau avec le même protocole pour constater, sans l’attribuer, ce qui a changé.

Sources

  1. Web search, OpenAI API — consulté le — l’API d’OpenAI propose un outil de recherche web ; le modèle choisit de chercher ou non selon le contenu de la question ; la recherche est facultative en mode automatique et peut être rendue obligatoire ; la réponse signale l’appel de recherche et les URL citées.
  2. Advanced usage, OpenAI API — consulté le — les sorties ne sont pas déterministes par défaut (Chat Completions) : les sorties du modèle peuvent différer d’une requête à l’autre.
  3. Grounding with Google Search, Gemini API — consulté le — l’API Gemini propose un outil de recherche Google ; le modèle analyse la question et détermine si une recherche peut améliorer la réponse ; la réponse contient les recherches effectuées et les citations.
  4. Prompt design strategies, Gemini API — consulté le — la température règle le degré d’aléa ; Google recommande de garder les paramètres par défaut sur les modèles Gemini 3.
  5. Web search tool, Claude API — consulté le — Claude détermine quand chercher selon la question et répond sans chercher sur des connaissances stables ; un message système peut orienter ce déclenchement ; la réponse contient les recherches et les citations.
  6. System prompts, Claude — consulté le — les applications Claude utilisent un message système mis à jour régulièrement, et ces mises à jour ne s’appliquent pas à l’API.
  7. Web Search, Perplexity API — consulté le — l’API de Perplexity propose un outil de recherche web ; le modèle décide quand l’appeler selon la question et les instructions ; la réponse contient les résultats de recherche.