L’IA vous cite : que pouvez-vous vraiment mesurer ?

Une capture d'écran circule dans votre équipe. On y voit le nom de votre boutique, dans la réponse d'un assistant conversationnel. Quelqu'un écrit : « Ça y est, on est dans l'IA. » La même semaine, vos visites augmentent. Faut-il fêter quelque chose ? Avant de répondre, posons une question plus précise : que prouve exactement cette capture, et que ne prouve-t-elle pas ?

Vous écoutez une série éducative de Verity Score pour les marchands Shopify. Au fil des épisodes, nous avons vérifié des voies d'accès, des fiches, des prix, des réponses, des guides et des sources externes. Il est temps de parler de mesure. Pas pour vous promettre un tableau de bord magique, mais pour séparer ce que vos observations démontrent de ce qu'elles suggèrent seulement.

Le cas de cet épisode est inventé, sans boutique, capture ni chiffre réels. Une petite marque de sacs a passé un mois à corriger ses fiches. Un lundi, une personne de l'équipe pose à ChatGPT la question : « Quel sac à dos choisir pour aller au travail avec un ordinateur ? » La boutique apparaît dans la réponse. Capture. Le mardi, une autre personne pose la même question, depuis son propre compte. La boutique n'apparaît pas. Le mercredi, quelqu'un la pose en anglais. Un autre produit de la marque est cité. Et dans le rapport de la boutique, les sessions de la semaine sont plus nombreuses que celles de la semaine précédente.

L'équipe a trois réponses et un rapport. La tentation est double. D'un côté, conclure que les corrections ont « marché », puisque la boutique est apparue et que les visites montent. De l'autre, s'inquiéter du mardi, comme si la boutique avait « disparu ». Les deux conclusions reposent sur la même erreur : traiter chaque observation comme une mesure générale.

Regardons de plus près. Les trois réponses n'ont pas été obtenues dans les mêmes conditions. Deux comptes différents, deux langues, des historiques de conversation que personne n'a notés. Personne n'a noté l'heure, ni si la personne était connectée. Quant au rapport, personne ne sait d'où viennent les sessions supplémentaires.

Même la capture du lundi est incomplète. Elle a été recadrée pour ne garder que le passage flatteur. On n'y voit plus la question entière, ni les autres produits proposés, ni les sources éventuellement citées. Ce qui reste est une image vraie, mais privée de ce qui permettrait de la comprendre.

Commençons par les réponses. L'aide d'OpenAI sur les achats dans ChatGPT, consultée le vingt-deux octobre deux mille vingt-six, indique que la sélection de produits tient compte de la question, du contexte et de métadonnées, et que tous les produits disponibles ne sont pas nécessairement montrés. Le contexte fait donc partie de la réponse. Une capture prouve qu'une réponse donnée, dans un contexte donné, à un moment donné, contenait ce que l'on voit. Elle ne prouve pas que la boutique apparaît à chaque fois, ni pour tout le monde, ni qu'elle apparaîtra demain. Le mardi ne prouve pas davantage une disparition.

Pour comparer des observations, il faut donc les rendre comparables. C'est l'objet d'un protocole, et ce que je vais décrire est une méthode éditoriale, pas une norme. Vous fixez une liste courte de questions, formulées une fois pour toutes. Vous notez, à chaque essai, la date et l'heure, le service utilisé, la langue, le pays si vous le connaissez, l'état de connexion, et si la conversation partait de zéro. Vous répétez les mêmes questions à intervalles réguliers. Et vous conservez tout, y compris les absences et les réponses qui vous déplaisent.

Que faire des variations ? Les conserver. Si la boutique apparaît dans certains essais et pas dans d'autres, c'est l'observation. Vous pouvez la décrire, par exemple « présente dans tant d'essais sur tant, pour cette question, dans ces conditions ». Ce décompte décrit votre échantillon. Il ne dit rien de ce que voient les autres personnes, dans leurs propres contextes.

Une précision utile. Une réponse obtenue par une interface de programmation, ou par un autre produit du même éditeur, ne doit pas être présumée équivalente à ce qu’une personne voit dans son application. Les conditions diffèrent. Si vous utilisez ce type d'accès, notez-le comme une source distincte, et ne mélangez pas les résultats.

Passons maintenant au trafic. Ici, la documentation Shopify apporte trois repères. Premier repère : les rapports d'acquisition portent sur les visiteurs et les sessions de la boutique en ligne. Ils ne montrent ni les ventes converties, ni le nombre de commandes. Le rapport des ventes par référent est un rapport distinct. Autrement dit, une hausse de sessions n'est pas une hausse de ventes, et l'inverse non plus.

Deuxième repère : Shopify classe les sessions entre humains et robots, avec une classification qu'elle décrit comme prudente, pas comme une identification parfaite. Un filtre est disponible dans les rapports compatibles. Pour comparer deux périodes, il faut donc utiliser les mêmes filtres, et le noter.

Troisième repère, très concret pour cet automne : la documentation signale un changement de la mesure des sessions entre le vingt et un et le vingt-trois septembre deux mille vingt-six. Si votre courbe change autour de ces dates, ne l'interprétez pas comme une performance. Comparez des périodes mesurées de la même façon, ou signalez la rupture.

Côté Google, sa documentation sur les fonctionnalités d'intelligence artificielle précise que leur performance est comprise dans le trafic Web de la Search Console. Ce n'est pas une mesure isolée de ces fonctionnalités, et encore moins une mesure universelle de votre présence dans les assistants.

Reste l'attribution. Ce que vos rapports peuvent rattacher à une origine dépend de votre configuration. Vérifiez, dans votre propre outil, comment l'origine des visites et le consentement des visiteurs sont traités. Nous ne le décrivons pas ici, et une partie des visites peut rester sans origine connue.

Revenons à l'équipe. Que peut-elle dire honnêtement ? Que la boutique est apparue dans une réponse, le lundi, dans un contexte non documenté. Que les sessions de la semaine sont plus nombreuses, sans savoir si elles sont humaines, d'où elles viennent, ni si elles ont produit des commandes. Et que les corrections de fiches ont eu lieu le mois précédent. Trois faits, rapprochés dans le temps. Aucun ne démontre que les corrections ont causé l'apparition, ni que l'apparition a causé les visites. Une coïncidence dans le temps n'est pas une cause.

Est-ce décevant ? Non. C'est la condition pour apprendre quelque chose de fiable. Un protocole stable ne prouvera pas non plus de causalité. Mais il permettra de voir si une observation se répète, et d’éviter d’attribuer une variation isolée à votre intervention.

Un dernier outil rend le tout plus lisible : un journal des modifications. Chaque fois que l'équipe corrige une fiche, une politique ou un guide, elle note la date et ce qui a changé. Ce journal ne prouvera pas qu'une correction a produit un effet. Mais quand une observation évoluera, l'équipe saura ce qui avait changé avant, et pourra formuler une hypothèse honnête plutôt qu'une victoire.

L'équipe décide de tenir deux documents séparés, et de ne jamais fusionner leurs conclusions sans prudence. C'est votre action de la semaine.

Le premier document est un journal d'observations. Une ligne par essai : la question exacte, la date et l'heure, le service, le contexte, c'est-à-dire la langue, le pays, l'état de connexion et l'historique, puis ce que la réponse contenait, et les sources qu'elle citait le cas échéant. Commencez avec trois questions, issues de votre relevé du premier épisode. Notez les absences comme des résultats. Choisissez un rythme de répétition que vous pourrez tenir, par exemple une fois par semaine. C'est une proposition, pas une norme : l’important est de garder un rythme défini et de documenter les conditions, aussi constantes que possible, sans supposer le modèle inchangé.

Le second document est un tableau de trafic. Une ligne par période : les dates, le rapport utilisé, le filtre humain ou robot appliqué, les sessions, et, dans une colonne séparée, les commandes issues du rapport des ventes par référent. Ajoutez une colonne pour les changements de mesure connus, et une autre pour les inconnues. Quand une origine est inconnue, écrivez « inconnue ». Ne la répartissez pas selon votre intuition.

Ces deux documents se lisent côte à côte. Ils ne se multiplient pas entre eux pour produire un chiffre d'affaires dû à l'IA. Le modèle complet est dans la fiche de l'épisode.

Vous savez maintenant ce qu'une capture prouve, ce qu'un rapport de sessions mesure, et pourquoi leur rapprochement ne démontre aucune cause. Il reste à décider quoi faire, alors que la certitude ne viendra pas. Comment prioriser sans attendre une preuve impossible ? Ce sera le sujet du dernier épisode de cette saison.

Les sources et leurs dates de consultation figurent dans les notes. Cet épisode est lu par une voix de synthèse.