Script maison pour mesurer la visibilité IA

Un script et un instrument de mesure ne sont pas la même chose, même lorsqu'ils partagent les mêmes lignes de code. Le premier répond à une question un jour donné. Le second doit répondre à la même question, dans les mêmes conditions, dans six mois, et de préférence après le départ de celui qui l'a écrit.

La nuance est rarement faite au moment où l'objection surgit. Elle vient en général du développeur maison, et elle est fondée : les quatre assistants que consultent les acheteurs, ChatGPT, Claude, Gemini et Perplexity, disposent d'API publiques, boucler sur une liste de questions n'a rien de sorcier, et une PME qui rémunère déjà un informaticien peut légitimement se demander pourquoi elle paierait un abonnement pour ce qui ressemble à un après-midi de travail.

Disons-le d'emblée : la version minimale tient effectivement en un après-midi. Ce qui suit la décrit dans l'ordre où il convient de la construire, en commençant par ce qu'un comité regardera en premier, la volumétrie, et en terminant par ce qu'il ne regarde presque jamais : qui la fera tourner l'an prochain.

Avant le code, la multiplication

Le volume d'appels se calcule avant d'ouvrir un éditeur, et c'est le chiffre qu'il faudra défendre lorsque la dépense passera en comité. Vingt questions, quatre assistants, cinq langues, trois répétitions par question : 20 × 4 × 5 × 3 = 1 200 appels par passage. À raison de deux passages par mois, 2 400 appels mensuels, avant d'avoir ajouté le moindre marché.

Les trois répétitions ne sont pas un luxe. La même question envoyée deux fois peut renvoyer deux listes de fournisseurs différentes sans que rien ait changé dans le monde. Un appel isolé est une anecdote ; ce qui porte l'information, c'est la fréquence à laquelle votre nom revient sur plusieurs appels, puis cette même fréquence relevée quinze jours plus tard dans des conditions identiques. Rogner sur les répétitions pour tenir l'enveloppe revient à payer moins cher un chiffre qui ne veut rien dire.

Chaque appel se facture en jetons, et la recherche web s'ajoute à la note chez au moins deux fournisseurs : Anthropic facture chaque recherche, Google chaque requête de recherche que ses modèles Gemini 3 exécutent. Les tarifs en vigueur figurent sur la page de prix de chacun. La multiplication se fait mieux avant la première facture qu'après.

Étape 1 : passer par la porte officielle, et tout garder

Le point décisif est la recherche d'informations. Un appel d'API nu répond à partir de ce que le modèle a absorbé pendant son entraînement, ce qui n'a pas grand-chose à voir avec une réponse construite après lecture du web du jour. Partout où l'API propose un outil de recherche, il faut l'activer.

OpenAI : l'API Responses propose un outil web_search, qui renvoie les sources consultées.
Anthropic : l'API de Claude dispose de son propre outil de recherche web, facturé à la recherche.
Google : l'API Gemini permet d'ancrer les réponses dans la recherche Google grâce à l'outil google_search.
Perplexity : les modèles Sonar cherchent sur le web par construction et renvoient citations et résultats de recherche. Il n'y a rien à activer.

Dans les trois premiers cas, le modèle décide encore, question par question, si une recherche en vaut la peine. Activer l'outil accorde une permission ; cela ne donne pas un ordre.

Reste à stocker, et la tentation est d'inscrire oui ou non dans un tableur puis de jeter le texte. Il faut y résister. Pour chaque appel, conservez la réponse intégrale, la date et l'heure, la question telle qu'envoyée, la langue, l'identifiant de modèle renvoyé par l'API et tout ce que le fournisseur a transmis sur ses sources : annotations de citation, adresses consultées, résultats de recherche. Dans six mois, vous voudrez passer un meilleur détecteur sur les anciennes réponses. Encore faut-il les avoir.

Étape 2 : des questions d'acheteur, dans sa langue, puis figées

Vingt questions suffisent pour commencer. Ce doivent être celles que pose quelqu'un qui ne connaît pas encore votre nom : qui fournit tel composant selon telle norme, quel logiciel gère tel processus pour une entreprise de telle taille, quelles alternatives existent au leader évident. Une question qui contient votre marque ne sert à rien ici, un modèle trouvant toujours quelque chose à dire d'un nom qu'on lui tend.

Elles se rédigent dans la langue de l'acheteur, et non en français assorti d'une traduction collée dessous. Un ingénieur achats allemand ne formule pas sa demande comme votre plaquette, et le modèle puise dans un autre corpus pour lui répondre. Maintenir la version allemande et la version espagnole d'une même question réellement équivalentes, à mesure que la liste s'allonge, suppose d'ailleurs quelqu'un qui lit les deux langues et que la chose préoccupe.

Puis la liste se fige. Reformuler une question entre deux passages, c'est changer d'instrument, et toutes les comparaisons ultérieures en héritent.

Étape 3 : reconnaître la marque, là où l'après-midi déborde

C'est ici que le calendrier dérape. Une recherche littérale de la raison sociale manquera plus de mentions qu'on ne l'imagine et en trouvera qui n'en sont pas. Le modèle peut omettre la forme juridique ou en employer une autre, nommer le produit plutôt que la société, réduire un nom en deux mots au premier, qui se trouve être un nom commun, le translittérer, le décliner dans une langue à cas, lui ajouter un trait d'union. Un mot courant dans votre nom produit de faux positifs. Un groupe plus grand au nom voisin en produit de pires.

Il faut donc une liste de variantes par marque et par langue, et le même travail pour vos concurrents, puisque savoir qui est cité à votre place fait au moins la moitié de l'intérêt de l'exercice. Certaines équipes confient le tri à un second appel de modèle. Cela fonctionne jusqu'à un certain point, mais ajoute une étape probabiliste à une mesure qui en comporte déjà une : un échantillon de ses verdicts doit être relu par un humain.

Le script de l'alternant

Reste la question que le code ne pose pas : qui s'en occupe. Dans bien des PME françaises, elle reçoit une réponse que chacun reconnaîtra sans qu'il soit besoin d'en raconter une. Le stagiaire ou l'alternant, parce qu'il a du temps, de la curiosité, et un tuteur qui voit là un bon sujet de mémoire.

Le schéma est connu. Le script tourne sur un poste ou un petit serveur dont la DSI ignore l'existence ; la clé d'API est rattachée à un compte ouvert pour l'occasion ; la documentation tient dans la tête de son auteur. Puis le contrat arrive à son terme, ce qu'un contrat d'apprentissage fait immanquablement, sa durée étant fixée d'avance, de six mois à trois ans dans le cas général. Personne n'a failli. Le dispositif perd simplement son unique propriétaire.

Ce genre d'outil tombe rarement en panne avec fracas. Il se périme. Une clé expire, un analyseur bute sur une réponse dont le format a changé, et le graphique continue d'afficher le dernier bon chiffre pendant un trimestre. Surtout, les modèles sont retirés selon des calendriers publiés : OpenAI tient une page des dépréciations qui liste les versions et leur date de retrait. Quand le modèle appelé disparaît, le script s'arrête, et son remplaçant répond autrement. C'est une rupture de série. Elle doit être consignée, faute de quoi le mouvement suivant sera attribué à la mauvaise cause, par quelqu'un qui n'était pas là.

Confier l'entretien à un prestataire ou à une ESN reste possible. On signe alors un contrat de maintenance, avec son devis et sa ligne budgétaire, et l'on a quitté le « faire » sans tout à fait l'avouer.

Faire ou faire faire

Pour une entreprise qui dispose d'un développeur disponible, d'un marché et d'une langue, faire est une décision parfaitement saine. Le jeu de questions reste petit, les variantes de marque se comptent sur les doigts, et le savoir sur la fabrication des chiffres reste dans la maison, ce qui a du prix.

L'équilibre se déplace quand la matrice grossit : davantage de langues, davantage de marchés, des concurrents dans chacun, et un historique qui doit survivre au retrait des modèles. C'est cet entretien qu'un outil comme PSentry a vocation à absorber. Il interroge les quatre assistants par leurs API officielles, deux fois par mois, par langue et par marché, et passe à des modèles plus récents à mesure que les fournisseurs retirent les anciens. Que cela justifie un abonnement est une question sur le temps de vos équipes, non sur la difficulté du premier script.

Ce que demande ensuite le développeur maison

Par quel assistant commencer ?

Perplexity, parce que ses modèles Sonar s'appuient par construction sur la recherche web et renvoient avec chaque réponse une liste de citations et des résultats de recherche structurés. Aucun outil à configurer.

Suffit-il de demander à un modèle si la marque est citée ?

En seconde lecture, oui. En lecture unique, cela remplace une règle de détection que l'on peut relire par un jugement que l'on ne peut pas relire, et qui varie d'un appel à l'autre comme tout le reste. La liste de variantes d'abord, le modèle ensuite pour les cas ambigus.

Combien de passages avant que les chiffres parlent ?

Il n'existe pas de seuil universel. Un critère praticable consiste à vérifier si l'ajout de répétitions modifie encore la proportion obtenue sur une question. Celles où vous n'êtes cité qu'une fois sur deux en réclament davantage que celles où vous l'êtes toujours, ou jamais. Et une tendance exige plusieurs passages, pas deux.

Le script relève-t-il du RGPD ?

Les questions, si elles portent sur des produits et des fournisseurs, ne contiennent en principe aucune donnée personnelle. Les réponses, elles, peuvent nommer un dirigeant, un fondateur ou un commercial. Or la CNIL rappelle qu'une donnée personnelle est toute information se rapportant à une personne physique identifiée ou identifiable, un nom suffisant à identifier. Archiver les réponses brutes, comme recommandé plus haut, peut donc revenir à conserver des données personnelles sans l'avoir cherché. Nous ne sommes pas juristes : la question se pose à votre délégué à la protection des données, ou à qui suit la conformité dans l'entreprise, avant le premier passage plutôt qu'après.