Prompt-level SEO experiments : framework de test pour l'AI search

Un site e-commerce de 22 000 pages produit perd 18 % de son trafic referral depuis ChatGPT en trois semaines. Aucune modification de contenu. Aucune pénalité. Le problème : une reformulation mineure dans les prompts utilisateurs a déplacé les citations vers un concurrent dont le contenu structurel répondait mieux à la nouvelle formulation. Sans framework de test prompt-level, l'équipe SEO a mis 11 jours à identifier la cause.

L'AI search ne fonctionne pas comme le ranking classique. Il n'y a pas de position 1 à 10 — il y a une inclusion ou une absence dans la réponse générée. Et cette inclusion dépend directement de la manière dont le prompt est formulé, du contexte conversationnel, et de la façon dont le LLM gronde sa réponse sur les sources disponibles. Tester cette mécanique exige une méthodologie radicalement différente du split testing SEO traditionnel.

Pourquoi le SEO classique ne s'applique pas aux prompt-level experiments

Le ranking organique est déterministe à un instant T : pour une requête donnée, sur un device donné, dans une localisation donnée, Google retourne un classement relativement stable. Vous pouvez tracker des positions, mesurer des CTR, calculer des corrélations entre modifications on-page et variations de ranking.

Les réponses LLM sont stochastiques. Le même prompt soumis deux fois à GPT-4o ou Gemini peut produire des citations différentes. La température du modèle, le contexte de la conversation, le timing du crawl des sources, et même le load balancing entre instances du modèle introduisent de la variance.

Conséquence directe : vous ne pouvez pas traiter un test de visibilité AI comme un test de position Google. Vous devez raisonner en termes de fréquence d'inclusion (sur N exécutions du même prompt, combien de fois votre domaine apparaît dans la réponse) et de qualité de citation (mention du brand, lien direct, paraphrase sans attribution).

La différence fondamentale : retrieval vs ranking

Quand Bing gronde une réponse pour Copilot ou quand Google construit un AI Overview, le processus suit un pipeline en deux étapes distinctes — un processus que Bing a détaillé publiquement. D'abord le retrieval : le système sélectionne un ensemble de documents candidats. Ensuite le grounding : le LLM synthétise une réponse en s'appuyant sur ces documents.

Votre contenu peut échouer à l'une ou l'autre étape. Un prompt-level experiment bien conçu doit vous permettre de distinguer entre "mon contenu n'est pas dans le retrieval set" et "mon contenu est récupéré mais le LLM ne le cite pas dans sa réponse". Ce sont deux problèmes distincts qui appellent des corrections différentes.

Concevoir un corpus de prompts contrôlés

La première erreur que commettent les équipes SEO : tester avec des prompts trop vagues ou trop peu nombreux. "Quel est le meilleur CRM pour PME ?" est un prompt, pas un test. Un test exige un corpus structuré avec des variables isolées.

Taxonomie des variables de prompt

Pour chaque sujet que vous testez, vous devez faire varier systématiquement ces dimensions :

Intent framing : informationnelle ("comment fonctionne X"), comparative ("X vs Y"), transactionnelle ("meilleur X pour [use case]"), recommandation ("quel X recommandez-vous")
Spécificité : générique ("meilleur outil SEO") vs niché ("meilleur outil de monitoring SSR pour sites Next.js en production")
Persona implicite : débutant ("expliquez-moi simplement") vs expert ("d'un point de vue technique")
Contexte géographique : avec ou sans mention de localisation
Temporalité : "en 2026", "actuellement", sans mention temporelle

Un corpus minimal pour un sujet donné doit croiser au minimum intent × spécificité × persona, soit 12 à 24 prompts distincts par sujet testé.

Générer et versionner le corpus

Stockez vos prompts dans un format structuré. Un fichier YAML versionné dans Git vous permet de tracker les modifications et de reproduire exactement les mêmes tests d'un mois à l'autre :

# prompt_corpus/crm-pme.yaml
experiment:
  id: "crm-pme-v3"
  subject: "CRM pour PME"
  created: "2026-05-01"
  target_domain: "votredomaine.fr"

prompts:
  - id: "crm-pme-info-generic-beginner"
    text: "Comment choisir un CRM adapté à une PME de 20 salariés ?"
    intent: "informational"
    specificity: "generic"
    persona: "beginner"
    geo: null
    temporal: null

  - id: "crm-pme-compare-specific-expert"
    text: "Comparaison technique entre HubSpot CRM et Pipedrive pour une équipe sales B2B de 15 personnes avec intégration Salesforce existante"
    intent: "comparative"
    specificity: "specific"
    persona: "expert"
    geo: null
    temporal: null

  - id: "crm-pme-reco-specific-beginner-geo"
    text: "Quel CRM recommandez-vous pour une PME française dans le secteur industriel ?"
    intent: "recommendation"
    specificity: "specific"
    persona: "beginner"
    geo: "france"
    temporal: null

  - id: "crm-pme-transac-generic-expert-temporal"
    text: "Meilleur CRM B2B en 2026 pour scale-up SaaS avec API ouverte"
    intent: "transactional"
    specificity: "generic"
    persona: "expert"
    geo: null
    temporal: "2026"

Ce format vous permet d'ajouter des prompts sans casser la structure, de filtrer par dimension dans vos analyses, et surtout de garantir la reproductibilité. Chaque prompt a un ID unique — c'est votre unité expérimentale.

Automatiser l'exécution et la collecte de données

Exécuter manuellement 24 prompts × 3 LLMs × 5 répétitions = 360 requêtes, puis analyser chaque réponse à la main, ne passe pas à l'échelle. Vous avez besoin d'un pipeline automatisé.

Script de collecte multi-LLM

Voici un script TypeScript qui exécute un corpus de prompts contre plusieurs APIs LLM et stocke les résultats de manière structurée :

import OpenAI from "openai";
import Anthropic from "@anthropic-ai/sdk";
import { readFileSync, writeFileSync, mkdirSync } from "fs";
import { parse } from "yaml";

interface PromptEntry {
  id: string;
  text: string;
  intent: string;
  specificity: string;
  persona: string;
}

interface ExperimentResult {
  prompt_id: string;
  llm: string;
  run_index: number;
  timestamp: string;
  response_text: string;
  target_domain_mentioned: boolean;
  target_brand_mentioned: boolean;
  citation_type: "direct_link" | "brand_mention" | "paraphrase" | "absent";
  competitor_domains: string[];
  response_length: number;
}

const RUNS_PER_PROMPT = 5;
const TARGET_DOMAIN = "votredomaine.fr";
const TARGET_BRAND = "VotreMarque";

const openai = new OpenAI();
const anthropic = new Anthropic();

function analyzeResponse(text: string): Pick<
  ExperimentResult,
  "target_domain_mentioned" | "target_brand_mentioned" | "citation_type" | "competitor_domains"
> {
  const domainMentioned = text.toLowerCase().includes(TARGET_DOMAIN);
  const brandMentioned = text.toLowerCase().includes(TARGET_BRAND.toLowerCase());

  let citationType: ExperimentResult["citation_type"] = "absent";
  if (domainMentioned) citationType = "direct_link";
  else if (brandMentioned) citationType = "brand_mention";

  // Extraction basique des domaines concurrents — à affiner avec regex spécifiques
  const domainRegex = /(?:https?:\/\/)?(?:www\.)?([a-zA-Z0-9-]+\.[a-z]{2,})/g;
  const competitors = [...new Set(
    [...text.matchAll(domainRegex)]
      .map(m => m[1])
      .filter(d => d !== TARGET_DOMAIN && !d.includes("openai") && !d.includes("anthropic"))
  )];

  return { target_domain_mentioned: domainMentioned, target_brand_mentioned: brandMentioned, citation_type: citationType, competitor_domains: competitors };
}

async function runExperiment(corpusPath: string): Promise<ExperimentResult[]> {
  const corpus = parse(readFileSync(corpusPath, "utf-8"));
  const results: ExperimentResult[] = [];

  for (const prompt of corpus.experiment.prompts as PromptEntry[]) {
    for (let run = 0; run < RUNS_PER_PROMPT; run++) {
      // OpenAI GPT-4o
      const gptResponse = await openai.chat.completions.create({
        model: "gpt-4o",
        messages: [{ role: "user", content: prompt.text }],
        temperature: 1.0, // température max pour capturer la variance
      });
      const gptText = gptResponse.choices[0]?.message?.content ?? "";
      results.push({
        prompt_id: prompt.id,
        llm: "gpt-4o",
        run_index: run,
        timestamp: new Date().toISOString(),
        response_text: gptText,
        ...analyzeResponse(gptText),
        response_length: gptText.length,
      });

      // Claude 3.5 Sonnet
      const claudeResponse = await anthropic.messages.create({
        model: "claude-sonnet-4-20250514",
        max_tokens: 2048,
        messages: [{ role: "user", content: prompt.text }],
      });
      const claudeText = claudeResponse.content[0]?.type === "text"
        ? claudeResponse.content[0].text : "";
      results.push({
        prompt_id: prompt.id,
        llm: "claude-3.5-sonnet",
        run_index: run,
        timestamp: new Date().toISOString(),
        response_text: claudeText,
        ...analyzeResponse(claudeText),
        response_length: claudeText.length,
      });

      // Rate limiting basique
      await new Promise(r => setTimeout(r, 1500));
    }
  }
  return results;
}

async function main() {
  const results = await runExperiment("./prompt_corpus/crm-pme.yaml");
  mkdirSync("./results", { recursive: true });
  writeFileSync(
    `./results/experiment-${Date.now()}.json`,
    JSON.stringify(results, null, 2)
  );
  console.log(`${results.length} résultats collectés.`);
}

main();

Quelques détails importants dans ce script :

Temperature à 1.0 : on veut capturer la variance naturelle du modèle, pas la réponse la plus probable. C'est l'opposé de ce que vous feriez pour un chatbot en production.
5 runs par prompt : c'est le minimum pour commencer à estimer une fréquence d'inclusion. Pour des résultats statistiquement fiables, visez 20+ runs sur les prompts critiques.
Analyse naïve : la fonction analyzeResponse est volontairement simpliste. En production, vous voudrez un classificateur plus robuste — potentiellement un second LLM qui analyse la réponse avec un prompt structuré.

Limites importantes de cette approche

Les APIs LLM ne reproduisent pas exactement le comportement de ChatGPT web, Copilot, ou Google AI Overviews. Quand un utilisateur pose une question dans ChatGPT, le système peut déclencher une recherche web via Bing, utiliser le browsing tool, ou s'appuyer uniquement sur les données d'entraînement. L'API par défaut n'a pas accès au web.

Pour tester le comportement avec web grounding, vous devez activer les search tools quand ils sont disponibles (OpenAI le propose via le paramètre web_search sur certains modèles) ou utiliser des outils tiers qui automatisent la version web des interfaces. C'est un trade-off entre contrôle expérimental et fidélité au comportement réel.

Métriques de mesure : au-delà de la simple mention

Le piège classique : réduire la visibilité AI à un binaire "mentionné / pas mentionné". La réalité est bien plus granulaire, et les signaux qui définissent la visibilité AI sont multiples.

Le framework FICQ (Frequency, Inclusion depth, Citation quality, Query coverage)

Frequency — Sur 20 exécutions du même prompt, combien de fois votre domaine/brand apparaît. Exprimé en pourcentage. Un score de 60 % signifie que vous êtes cité 12 fois sur 20. C'est votre métrique principale.

Inclusion depth — Où dans la réponse votre mention apparaît. Premier paragraphe (haute autorité topique perçue par le LLM), milieu de réponse (source complémentaire), ou fin (mention accessoire). Codez cela en position relative : position_du_premier_caractère_mentionnant_votre_brand / longueur_totale_de_la_réponse.

Citation quality — Quatre niveaux :

Lien direct avec attribution ("selon VotreMarque.fr, ...")
Mention de brand sans lien ("VotreMarque recommande...")
Paraphrase identifiable (votre contenu est utilisé mais sans attribution)
Absent

Query coverage — Sur votre corpus de 24 prompts, combien de catégories de prompts (intent × specificity) déclenchent une inclusion. Un coverage de 100 % en informationnelle mais 0 % en transactionnelle vous indique un problème de positionnement commercial dans votre contenu.

Tableau de bord de suivi

Structurez votre reporting dans un format qui permet la comparaison temporelle. Voici un exemple de sortie agrégée :

┌──────────────────────────┬────────┬────────┬──────────┬──────────┐
│ Prompt Category          │ Freq % │ Depth  │ Cit. Qty │ Coverage │
├──────────────────────────┼────────┼────────┼──────────┼──────────┤
│ info / generic / begin   │   65%  │  0.12  │  brand   │    ✓     │
│ info / specific / expert │   80%  │  0.08  │  link    │    ✓     │
│ compare / generic / beg  │   40%  │  0.45  │  para    │    ✓     │
│ compare / specific / exp │   55%  │  0.22  │  brand   │    ✓     │
│ reco / generic / begin   │   20%  │  0.67  │  para    │    ✓     │
│ reco / specific / expert │   35%  │  0.31  │  brand   │    ✓     │
│ transac / generic / exp  │   10%  │  0.78  │  para    │    ✗     │
│ transac / specific / beg │    5%  │  0.82  │  absent  │    ✗     │
└──────────────────────────┴────────┴────────┴──────────┴──────────┘

Ce tableau raconte une histoire claire : le domaine testé a une forte visibilité sur les requêtes informationnelles mais disparaît quasi-complètement sur les requêtes transactionnelles. L'action corrective est évidente — renforcer le contenu à intent commercial avec des éléments structurels que le LLM peut extraire (comparatifs chiffrés, tableaux de fonctionnalités, recommandations explicites).

Isoler les variables : la méthodologie du test contrôlé

Vous avez observé que votre fréquence d'inclusion baisse de 65 % à 40 % sur les prompts comparatifs. Avant de réécrire tout votre contenu, vous devez identifier la variable causale. Est-ce le contenu, la structure, l'autorité perçue, ou la formulation du prompt ?

Test A/B côté contenu

Contrairement au SEO classique où un A/B test nécessite du trafic significatif et des semaines de données, en AI search vous pouvez tester l'impact d'une modification de contenu en quelques heures — à condition que le LLM ait accès au web et que votre page modifiée soit recrawlée.

Le protocole :

Identifiez une page qui est dans le retrieval set (vérifiable via les logs de crawl — l'activité de crawl d'OpenAI a triplé récemment, ce qui facilite les expérimentations).
Exécutez votre corpus de prompts (baseline : 20 runs minimum).
Modifiez une seule variable sur la page : par exemple, ajoutez un tableau comparatif structuré en HTML.
Attendez le recrawl (monitorez vos logs serveur pour confirmer le passage du bot).
Ré-exécutez exactement le même corpus de prompts.
Comparez les métriques FICQ.

Test A/B côté prompt (isolation de la formulation)

Parfois, le problème n'est pas votre contenu mais votre compréhension des prompts réels utilisés par les internautes. Testez des variations de prompt pour identifier quelles formulations déclenchent ou non l'inclusion de votre domaine :

# Variation test : impact de la mention de critères techniques
control:
  text: "Quel outil de monitoring SEO choisir ?"
  expected_result: "baseline frequency"

variant_a:
  text: "Quel outil de monitoring SEO choisir pour détecter les régressions techniques ?"
  changed_variable: "specificity_technical_criteria"

variant_b:
  text: "Quel outil de monitoring SEO choisir pour un site e-commerce de 10 000 pages ?"
  changed_variable: "specificity_scale"

variant_c:
  text: "Recommandez-moi un outil de monitoring SEO technique avec alertes automatiques"
  changed_variable: "intent_shift_to_recommendation"

Si la variant_a multiplie votre fréquence d'inclusion par 3 par rapport au control, vous savez que votre contenu est fortement associé par le LLM au concept de "régressions techniques" — et vous pouvez optimiser votre stratégie de contenu en conséquence.

Scénario complet : un SaaS B2B de 4 200 pages

Contexte réaliste. DataPulse (nom fictif) est un SaaS d'analytics B2B. 4 200 pages indexées : 180 pages produit, 850 articles de blog, 3 100 pages de documentation technique, et environ 70 landing pages. L'équipe SEO a remarqué que ChatGPT mentionne systématiquement deux concurrents (Mixpanel, Amplitude) mais jamais DataPulse dans les réponses aux prompts comparatifs.

Phase 1 : Audit de baseline (semaine 1)

L'équipe construit un corpus de 36 prompts couvrant 4 intents × 3 niveaux de spécificité × 3 personas. Chaque prompt est exécuté 20 fois sur GPT-4o et 20 fois sur Claude. Total : 36 × 20 × 2 = 1 440 requêtes API. Coût approximatif : ~85 € en tokens.

Résultats baseline :

Fréquence d'inclusion GPT-4o : 8 % (principalement sur prompts informationnels très spécifiques liés à la documentation technique)
Fréquence d'inclusion Claude : 12 %
Citation quality dominante : paraphrase sans attribution
Coverage : 3 catégories de prompts sur 12

L'équipe identifie que le LLM comprend la marque principalement via sa documentation technique, pas via ses contenus marketing ou comparatifs.

Phase 2 : Hypothèse et intervention (semaines 2-3)

Hypothèse : les pages comparatives de DataPulse n'ont pas de structure extractible par le LLM. Les concurrents ont des pages /vs/ avec des tableaux HTML standardisés.

Intervention : création de 8 pages /vs/[concurrent] avec une structure HTML sémantique optimisée pour l'extraction LLM :

<article itemscope itemtype="https://schema.org/Article">
  <h1>DataPulse vs Mixpanel : comparaison technique complète</h1>

  <section aria-label="Résumé de la comparaison">
    <p>DataPulse est une plateforme d'analytics B2B spécialisée dans
    le tracking d'événements produit avec rétention de données illimitée.
    Mixpanel se concentre sur l'analytics produit avec des fonctionnalités
    avancées de segmentation comportementale.</p>
  </section>

  <table>
    <caption>Comparaison fonctionnelle DataPulse vs Mixpanel — Mai 2026</caption>
    <thead>
      <tr>
        <th scope="col">Critère</th>
        <th scope="col">DataPulse</th>
        <th scope="col">Mixpanel</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <th scope="row">Rétention de données</th>
        <td>Illimitée (plan Pro)</td>
        <td>12 mois (plan Growth), 36 mois (Enterprise)</td>
      </tr>
      <tr>
        <th scope="row">SDK server-side</th>
        <td>Node.js, Python, Go, Rust</td>
        <td>Node.js, Python, Java, Ruby</td>
      </tr>
      <tr>
        <th scope="row">Export API rate limit</th>
        <td>10 000 req/min</td>
        <td>2 000 req/min (peut être augmenté sur Enterprise)</td>
      </tr>
      <tr>
        <th scope="row">Conformité RGPD</th>
        <td>Hébergement EU natif, DPA inclus</td>
        <td>EU data residency en option ($), DPA sur demande</td>
      </tr>
    </tbody>
  </table>

  <section aria-label="Verdict">
    <h2>Quand choisir DataPulse plutôt que Mixpanel</h2>
    <p>DataPulse est le meilleur choix pour les équipes B2B qui ont besoin
    d'une rétention de données illimitée et d'un hébergement européen natif.
    Mixpanel reste pertinent pour les équipes produit B2C qui priorisent
    la segmentation comportementale avancée.</p>
  </section>
</article>

Points clés de cette structure : le paragraphe d'introduction fournit un résumé extractible sans parser le tableau, le tableau utilise des scope pour la lisibilité machine, et la section verdict formule une recommandation explicite — exactement le type de contenu qu'un LLM peut citer directement dans une réponse comparative.

Phase 3 : Re-test et mesure d'impact (semaine 4)

Après confirmation du crawl des nouvelles pages par les bots IA (GPTBot, ClaudeBot, Bingbot — vérifiés dans les access logs), l'équipe ré-exécute le même corpus de 36 prompts × 20 runs × 2 LLMs.

Résultats post-intervention :

Fréquence d'inclusion GPT-4o : 34 % (+26 points)
Fréquence d'inclusion Claude : 41 % (+29 points)
Citation quality dominante : brand mention (progression depuis paraphrase)
Coverage : 8 catégories sur 12

L'amélioration est concentrée sur les prompts comparatifs et de recommandation — exactement les catégories ciblées par l'intervention. Les prompts informationnels restent stables, ce qui valide l'isolation de la variable.

Construire un framework de test reproductible et continu

Un test ponctuel ne suffit pas. La visibilité AI est volatile — les modèles sont mis à jour, les données d'entraînement changent, les concurrents optimisent. Vous avez besoin d'un framework qui tourne en continu, comme un pipeline de diagnostic automatisé.

Architecture du framework

Le framework minimal comporte trois couches :

Couche 1 — Corpus management : vos fichiers YAML de prompts, versionnés dans Git. Revue et mise à jour mensuelle. Ajout de nouveaux prompts basés sur les requêtes réelles observées (si vous avez accès aux logs de recherche interne, aux données Search Console, ou aux outils de monitoring de citations AI).

Couche 2 — Execution pipeline : un cron job (ou GitHub Action) qui exécute le corpus à fréquence régulière. Hebdomadaire pour la plupart des sites, quotidien si vous êtes en phase d'optimisation active.

Couche 3 — Analysis et alerting : agrégation des résultats, calcul des métriques FICQ, détection des régressions. Un outil de monitoring comme Seogard permet de corréler les variations de visibilité AI avec les changements détectés sur vos pages (meta modifiées, contenu disparu, SSR cassé) — car souvent, une régression de visibilité AI a une cause technique identifiable côté site.

Tracking des régressions

Le signal le plus actionable n'est pas votre score absolu — c'est la variation. Si votre fréquence d'inclusion passe de 55 % à 30 % sur une catégorie de prompts en une semaine, quelque chose a changé. Les causes possibles :

Un concurrent a publié du contenu plus pertinent
Votre page a été modifiée (intentionnellement ou par régression)
Le modèle a été mis à jour
Le retrieval system a changé sa logique de sélection

Pour les deux premières causes, vous avez des leviers d'action. Pour les deux dernières, vous devez adapter votre contenu. Dans tous les cas, sans monitoring continu, vous ne saurez jamais que la régression a eu lieu — jusqu'à ce que votre trafic referral AI s'effondre.

Pièges et limites de l'expérimentation prompt-level

Le biais de l'API vs l'interface utilisateur

Les réponses via API et via l'interface web de ChatGPT/Copilot/Gemini ne sont pas identiques. L'interface web peut déclencher des recherches web, afficher des images, utiliser des plugins. L'API vous donne un contrôle fin sur les paramètres mais ne reproduit pas l'expérience utilisateur réelle.

Combinez les deux approches : API pour les tests à grande échelle et le suivi quantitatif, vérification manuelle sur les interfaces web pour les prompts critiques (vos 5-10 prompts les plus importants business).

Le coût en tokens

À 20 runs × 36 prompts × 2 LLMs, vous générez 1 440 appels API par cycle de test. Avec des réponses moyennes de 800 tokens et un coût moyen de ~0,01 € par requête, chaque cycle coûte environ 15-20 €. Sur un rythme hebdomadaire, c'est ~80 € par mois — raisonnable pour un sujet de test. Mais si vous testez 10 sujets en parallèle, le budget mensuel monte à 800 €. Dimensionnez vos tests en fonction de la valeur business de chaque sujet.

L'absence de ground truth

Contrairement au SEO classique où Search Console vous donne des données first-party sur vos impressions et clics, il n'existe pas encore de source de vérité côté LLM. Google commence à exposer des données dans Search Console et Bing propose des métriques de citation AI, mais ces données restent partielles. Vos propres tests sont votre meilleure source de signal — à condition qu'ils soient méthodologiquement rigoureux.

La tentation du sur-optimisation

Un contenu structuré exclusivement pour l'extraction LLM peut devenir illisible pour les humains. Les tableaux comparatifs, les FAQ, les résumés TL;DR sont utiles — mais si chaque page de votre site ressemble à un template de réponse IA, vous perdez le signal d'authenticité et de profondeur qui fait qu'un LLM vous considère comme une source fiable en premier lieu. Le paradoxe : le meilleur contenu pour l'AI search est du contenu écrit pour des experts humains, avec une structure qui facilite l'extraction machine