Méthodologie de mesure de la recherche IA

TL;DR — Un résultat de recherche IA est un échantillon, pas un classement. Enregistrez la question exacte, l’endroit où elle a été posée, le modèle ou produit qui a répondu, la date d’exécution et les liens apparus. Répétez le même test plusieurs fois. Excluez les échecs du dénominateur et ne traitez pas une visite de robot, une mention de marque, une citation, un clic et une conversion comme un seul événement.

La fiche d’observation compte plus que le score

Un « score de visibilité IA » est difficile à interpréter si vous ignorez ce qui a été testé. Le même prompt peut produire des réponses différentes selon la date, le modèle, le pays, le compte ou la répétition. Une fiche utile commence donc par l’observation :

• le prompt exact et sa version ;
• le produit, l’API ou la surface officielle de reporting ;
• le modèle demandé et le modèle résolu, lorsqu’ils sont connus ;
• la récupération Web activée, désactivée ou indisponible ;
• le pays, la langue, l’appareil et l’état du compte lorsqu’ils sont pertinents ;
• la date, le groupe d’échantillon et le numéro de répétition ;
• la réponse ou le hash de preuve autorisé ;
• chaque mention et citation observée ;
• le passage qui semble étayer chaque citation, lorsqu’il est exposé ;
• les versions de l’extraction et de la méthodologie.

Si une exécution a échoué, a été refusée ou n’a pas exposé la donnée demandée, conservez cette fiche. Étiquetez-la non évaluée au lieu de la transformer en zéro.

Cinq événements à garder séparés

1. Récupéré : un robot vérifié ou un agent dirigé par l’utilisateur a demandé une URL.
2. Sélectionné ou récupéré : la page est entrée dans un ensemble de récupération observable.
3. Mentionné : la réponse a nommé l’entité.
4. Cité : la réponse a exposé une URL source.
5. Visité ou converti : une personne a suivi un lien et réalisé une action mesurée.

Un journal serveur peut prouver le premier événement lorsque le demandeur est correctement vérifié. Il ne peut normalement pas prouver les quatre autres. Une capture de réponse peut prouver une mention ou une citation visible, mais elle ne révèle pas toutes les sources que le système a récupérées ou utilisées en interne.

Répéter avant de recommander un changement

Exécutez des prompts compatibles au moins trois fois avant d’appliquer une étiquette de stabilité ; cinq répétitions constituent une meilleure valeur par défaut. Présentez le résultat comme une fraction exacte — par exemple 3/5 réponses éligibles citaient la page — plutôt que simplement « 60 % visible ».

Lorsqu’une citation apparaît une fois puis disparaît deux fois, l’interprétation initiale correcte est la variabilité. Ce n’est pas automatiquement un problème d’indexation ni une pénalité.

Essayez le laboratoire de preuves de recherche IA avec son paquet d’exemple inclus pour voir comment séparer les dénominateurs éligibles, la persistance des citations, la couverture des passages et les conflits factuels.

TL;DR — Utilisez un contrat d’observation en ajout seulement et un registre de prompts versionné. Ne comparez que des panels compatibles par prompt, surface, récupération, langue et méthode. Rapportez les résultats binaires avec N et un intervalle d’incertitude. Conservez les preuves brutes séparément des classifieurs dérivés et des corrections humaines. Le cadre de gestion des risques IA du NIST fournit un cadre de gouvernance complémentaire pour cette conservation. Évaluez les interventions avec des contrôles lorsque c’est possible, mais traitez même les résultats observationnels contrôlés comme directionnels.

L’enveloppe d’observation

L’observation canonique devrait contenir quatre couches :

Acquisition

Consignez explicitement le type de source :

• produit grand public ;
• API de modèle propriétaire ;
• API propriétaire avec recherche Web ;
• fournisseur tiers ;
• rapport officiel destiné aux webmasters ;
• journal serveur vérifié ;
• fichier envoyé par l’utilisateur.

Un appel d’API propriétaire avec recherche est une preuve utile de cette exécution d’API. Ce n’est pas une mesure directe d’un produit grand public au nom similaire. Conservez cette frontière dans le stockage, les libellés de l’interface, les exports et les agrégations.

Contexte expérimental

Stockez un identifiant de prompt stable, une version de prompt immuable, son hash, la surface, le mode de récupération, la langue, le pays, l’appareil, l’état du compte, le groupe d’échantillon et le numéro de l’échantillon. Utilisez un panel de référence figé pour les tendances et un panel exploratoire séparé pour découvrir de nouveaux motifs de prompts.

Lorsqu’un prompt change, créez une nouvelle version. Ne modifiez pas les observations historiques pour les faire paraître compatibles.

Preuves

Conservez les preuves de réponse brutes ou hachées, les URL citées et récupérées normalisées, les portées de mentions, les positions de citation lorsqu’elles sont exposées, les requêtes d’ancrage lorsqu’elles sont exposées et les passages ou hash de passages associés. Normalisez les paramètres de suivi et les fragments d’URL sans supprimer l’URL d’origine.

Pour les citations, une fiche source utile contient :

raw URL → normalized URL → observed canonical or redirect successor
        → answer citation position → supporting passage → observed HTTP status

Cette chaîne empêche les redirections, paramètres, copies syndiquées et migrations de gonfler le nombre de sources. La documentation Google sur la canonisation décrit les signaux associés à la consolidation des URL et leurs limites.

Interprétation

Chaque mention, sentiment, entité, fait et motif de perte extrait devrait inclure :

• la version du classifieur ou de l’extracteur ;
• l’état observé, dérivé, inféré ou non évalué ;
• la confiance et sa justification ;
• toute correction humaine ultérieure.

Une correction ne supprime pas la classification originale. Elle devient une fixture de calibration pour évaluer la version suivante du classifieur.

Comparaisons compatibles

Avant de calculer une tendance, exigez des valeurs compatibles pour :

• l’identifiant et la version du prompt ;
• la surface ;
• le mode de récupération ;
• la langue ;
• les versions de la méthodologie et de l’extracteur.

Annotez la série ou interrompez-la lorsque le modèle résolu ou le checkpoint change. Sinon, une mise à jour du fournisseur peut ressembler à un changement de performance du contenu.

Pour un résultat binaire, rapportez le numérateur, le dénominateur éligible, l’estimation ponctuelle et un intervalle d’incertitude. Excluez les refus, les échecs du fournisseur et les preuves indisponibles du dénominateur, mais continuez à afficher leur nombre dans la qualité des exécutions.

Exemples de plateformes publiques

Ces exemples montrent pourquoi les contrats propres à chaque source comptent ; ils ne demandent pas de forcer les plateformes dans un classement commun :

• La description publique par Google de son rapport d’IA générative dans Search Console liste les impressions, pages, pays, appareils et dates. Stockez-les comme champs de visibilité documentés ; ne les transformez pas en citations ni en rang de réponse. Le rapport a été annoncé comme un déploiement limité en juin 2026. Annonce officielle
• La description publique par Microsoft de l’AI Performance dans Bing Webmaster Tools inclut l’activité de citation, les pages citées et des requêtes d’ancrage échantillonnées. Microsoft précise explicitement que ces citations n’indiquent ni placement, ni autorité, ni rang, ni rôle d’une page dans une réponse. Annonce officielle

L’adaptateur de chaque source doit conserver ces sémantiques et marquer comme indisponibles les champs non documentés.

Expériences de changement de contenu

Créez une fiche d’intervention avant de juger une modification :

• hypothèse ;
• URL touchées et URL de contrôle ;
• identifiants de prompts ;
• heure de déploiement ;
• heure de réexploration observée ;
• métrique attendue ;
• fenêtres avant et après.

Un résultat avant/après non contrôlé est directionnel. Un panel de contrôle compatible permet une lecture en différences-de-différences, mais le résultat reste observationnel sauf si l’affectation et les conditions externes justifient un langage causal plus fort.

Exigez que le résultat persiste sur plusieurs exécutions avant de le convertir en recommandation de contenu. La recommandation doit renvoyer aux observations qui l’ont produite.

Suivi des faits et des contradictions

Tenez un registre de faits vérifié par un humain avec l’entité, le prédicat, la valeur attendue, les variantes acceptables, la source principale, les dates de validité, la sensibilité et la dernière vérification humaine. Comparez les affirmations observées dans les réponses à ce registre.

Lorsque les modèles divergent, rapportez conflit observé. Ne désignez pas de gagnant avant d’avoir confronté les valeurs aux preuves actuelles. Les faits tarifaires, juridiques, médicaux, financiers et de sécurité méritent des fenêtres de vérification plus courtes et des contrôles plus stricts.

Preuves issues des robots

Les contrôles des robots diffèrent selon le but de la demande. OpenAI, Anthropic et Perplexity documentent des rôles séparés pour le développement des modèles, la recherche ou l’indexation et la récupération dirigée par l’utilisateur. Vérifiez l’identité avec une liste d’adresses IP publiée par l’opérateur, un DNS inverse documenté ou un autre mécanisme officiel lorsqu’il existe ; un simple agent utilisateur ne prouve pas l’identité.

• Documentation des robots OpenAI
• Documentation des robots Anthropic
• Documentation des robots Perplexity

Même une demande vérifiée ne prouve que cette demande. Ne la transformez pas en preuve d’utilisation dans une réponse, de citation, de trafic ou de conversion. La documentation des robots OpenAI, les recommandations Anthropic et la documentation des robots Perplexity décrivent les frontières propres à chaque fournisseur pour l’identité et l’accès.

Anti-patterns

• Un score universel qui masque les désaccords entre surfaces.
• Une seule exécution de prompt présentée comme une part de voix.
• Traiter une preuve indisponible comme un zéro.
• Comparer la sortie d’une API à celle d’un produit grand public comme s’il s’agissait du même système.
• Appeler les citations un « rang ».
• Appeler une citation en 404 une hallucination avant d’avoir vérifié les redirections et migrations.
• Réécrire les prompts, observations ou corrections historiques.
• Appliquer rétroactivement un changement de classifieur sans conserver sa version.
• Affirmer qu’une modification de contenu a causé une hausse sans expérience adaptée.
• Recommander llms.txt, un balisage IA spécial ou de minuscules segments comme exigences Google universelles. Les recommandations actuelles de Google indiquent qu’ils ne sont pas nécessaires pour ses fonctionnalités Search génératives. Recommandations officielles

Journal des modifications