Notre serveur fermait la porte aux IA
Le site publie un fichier robots.txt qui invite nommément les robots des IA à venir lire nos pages. C'est cohérent avec ce que nous faisons : nos méthodes sont en accès libre, et nous voulons qu'elles soient lues, y compris par des machines.
En préparant le relevé promis, nous avons voulu vérifier une chose élémentaire : est-ce que ces robots arrivent seulement à entrer ? Nous avons donc demandé la page d'accueil en nous présentant successivement comme chacun d'eux.
Sept d'entre eux reçoivent un refus. Pas une page, pas une erreur de contenu : un code 429, celui qui signifie « trop de requêtes, revenez plus tard ». Dès la première. Les navigateurs ordinaires, eux, reçoivent la page normalement, comme les robots des moteurs de recherche classiques.
Nous avons cru à un artefact de notre réseau. Nous avons donc refait le test depuis une seconde connexion, par un opérateur mobile, sur une adresse qui n'avait jamais touché le site. Première requête, en navigateur : la page. Deuxième requête, sept secondes plus tard, en se présentant comme un robot d'IA : refus. Le filtrage ne suit pas l'adresse, il suit l'identité déclarée. L'hypothèse de l'artefact est morte là.
Ce n'est pas nous qui l'avons installé, et il n'existe aucun réglage côté client pour le désactiver : nous avons parcouru l'espace d'administration de l'hébergement, il n'y a ni interrupteur, ni option, ni fichier de configuration qui porte sur ce point. C'est une protection posée en amont, par défaut. Un ticket est ouvert.
Nous avons passé des semaines à travailler la clarté de nos pages pour les IA : données structurées, fichier llms.txt, définitions autonomes, licence explicite. Tout cela suppose qu'un robot puisse lire la page. Personne, dans aucune méthode GEO que nous avons lue, la nôtre comprise, ne commence par vérifier que la porte est ouverte.
C'est désormais la première étape de notre protocole, avant toute mesure : interroger le site en se présentant comme chacun des robots d'IA, et lire le code de réponse. Cinq minutes. Sans cela, on mesure une absence de citations en croyant qu'elle vient du contenu.
La deuxième panne n'existait pas
Le même jour, un outil automatisé nous signalait que notre plan de site répondait une erreur d'authentification. Le fichier est public, il n'y a aucun mot de passe dessus depuis l'ouverture. Nous avions donc, sur le papier, deux pannes de serveur le même matin.
La vérification a pris dix minutes et elle donne une règle utile. Depuis le poste, l'adresse répond normalement, pour tous les agents testés. Depuis l'outil automatisé, la même adresse refuse. Et la même adresse, avec un paramètre inutile ajouté à la fin, répond normalement : le vrai fichier, le vrai contenu.
Une réponse conservée en mémoire, classée par adresse exacte, datant de la période où le site était encore protégé par mot de passe. Le serveur n'y était pour rien. Aucune purge à demander, aucun ticket à ouvrir.
D'où la règle, que nous appelons entre nous celle des deux instruments : un incident constaté par un seul outil n'est pas un incident, c'est une observation. Il faut un second instrument, indépendant du premier, avant de conclure. Le premier cas de cet épisode a tenu cette épreuve, le second ne l'a pas tenue. C'est toute la différence entre un ticket légitime et une heure perdue chez un hébergeur.
Nous avons publié un article faux, et corrigé le jour même
L'épisode 5 racontait notre test du « commente pour recevoir » : nous avions joué le jeu, en client, et nous n'avions rien reçu. Nous en avions tiré un article, publié sur ce site, intitulé trois tests, zéro livraison.
Ce titre était faux. En reprenant le dossier, le décompte réel n'était pas de trois publications mais de treize, et la conclusion « zéro livraison » ne tenait plus : plusieurs envois nous étaient parvenus, certains après relance, un après que nous avons dû réclamer.
Nous avons refait la mesure entièrement, publication par publication, en relevant les compteurs à la même heure, et en ouvrant une par une les pages de destination. Le résultat est plus intéressant que l'ancien, et surtout il est vrai. L'article a été réécrit et remis en ligne à la même adresse dans la journée.
Nous le racontons ici pour trois raisons. Parce qu'un journal de construction qui ne publierait que les réussites ne servirait à rien. Parce que la faute est instructive : nous avions écrit une conclusion à partir d'un échantillon partiel, sans revenir aux sources avant de publier. Et parce que la correction s'est faite le jour de la découverte, sans attendre une fenêtre de communication confortable.
Deux défauts de plus sont sortis dans la même passe, et ils méritent d'être dits parce qu'ils sont invisibles à l'œil : l'illustration de cet article pesait sept octets, un fichier vide en ligne depuis la veille, et l'image d'aperçu social n'existait pas. Partagé sur un réseau, l'article serait sorti sans visuel. Aucun de ces deux points ne se voit en lisant la page : ils se voient en interrogeant le serveur fichier par fichier.
Le relevé de visibilité, ce qu'on peut déjà en dire
La moitié du protocole est exécutée : six sessions vierges, en interrogation directe et en recherche web. La seconde moitié, le panel dans le navigateur sur les autres moteurs, attend la réouverture décrite plus haut. Mesurer une visibilité pendant que la porte est fermée produirait un chiffre exact et sans signification.
Ce que la première moitié montre déjà : la découvrabilité est à zéro, y compris sur notre nom exact, et aucune mention de nous n'existe ailleurs que sur notre propre site. En revanche, quand un moteur atteint le site, il le décrit correctement, licence et statut non marchand compris.
Nous devons aussi une correction à l'épisode 5. Nous y écrivions qu'un moteur « invente » notre métier. C'est inexact, et la nuance compte. Interrogés directement, tous les moteurs testés répondent qu'ils ne nous connaissent pas, et l'un d'eux écrit même que toute description plus précise serait inventée. La description fausse que nous avions relevée venait d'un outil de suivi qui les interroge dans un gabarit imposant de décrire une marque. Ce n'est pas le moteur qui invente, c'est la question qui ne lui laisse pas le droit de ne pas savoir. À retenir avant de conclure quoi que ce soit d'un tableau de bord de visibilité IA, le nôtre compris.
Le reste, en bref
Le glossaire passe à cinquante entrées, et chacune porte désormais ses données structurées : onze n'en avaient aucune. Deux termes ont reçu leur page complète, agent IA et lead magnet, choisis sur les volumes de recherche réels et non sur ce que nous avions envie d'écrire.
Un défaut d'ergonomie corrigé, et il durait depuis l'ouverture. Cliquer sur un lien vers un terme du glossaire chargeait la page sans ouvrir le bloc, et plaçait le terme hors de l'écran, sous la barre de navigation. Le lecteur atterrissait devant le contenu du terme suivant. Vingt lignes de correction, et un test sur les trois façons d'arriver sur une ancre.
Une règle de travail posée, après une confusion de notre fait : valider un texte n'est pas dire de le mettre en ligne. Les deux gestes sont désormais distincts et écrits, parce que c'est exactement ce qui a produit l'article faux publié trop tôt.
Accès des robots d'IA : sept refusés sur quatorze agents testés, vérifié depuis deux connexions indépendantes. Réouverture demandée, non obtenue à la date de ces mesures.
Citations dans les réponses des IA : zéro, y compris sur la requête de marque exacte. Relevé partiel, seconde moitié suspendue à la réouverture.
Glossaire : 54 entrées, 54 fiches de données structurées, 10 pages complètes, au 5 août. Le chantier a avancé entre les faits racontés ici et la publication : à la date des mesures ci-dessus, le glossaire comptait 50 entrées et 2 pages.
Corrections publiées : un article réécrit à la même adresse, une illustration vide remplacée, une image d'aperçu créée.
Trafic : 25 sessions et 204 pages vues sur deux jours, les 3 et 4 août, pour 8 personnes distinctes et 38 pages différentes consultées. Durée d'engagement moyenne : 10 minutes 33 par personne. Zéro événement clé. Deux précisions qui comptent plus que les chiffres. Les 1er et 2 août n'ont rien collecté du tout, c'est la panne racontée dans l'épisode précédent : ce relevé est donc le premier complet depuis la remise en service. Et une bonne part de ces huit personnes, c'est nous, en train de recetter le site. Le chiffre honnête n'est pas 8 visiteurs, c'est 8 moins nos propres passages, et nous ne savons pas encore les séparer proprement. Ce sera le premier travail du prochain relevé.
Ce que nous retenons
Trois choses, et la première nous gêne encore.
Un site peut faire exactement l'inverse de ce qu'il enseigne sans que personne ne s'en aperçoive, parce que le défaut est dans une couche que personne ne regarde. Un incident vu par un seul instrument n'est pas un incident. Et une erreur publiée se corrige le jour où on la découvre, pas le jour où cela nous arrange.
Il n'y a rien de flatteur dans cet épisode. C'est à peu près la seule raison pour laquelle il valait la peine d'être écrit.
MarkenTIQ · 5 août 2026