Écrire pour les moteurs et pour les IA : graphe schema.org, llms.txt et fiches de référence

Une page de sfeir.com a au moins quatre lecteurs : la personne qui la lit, le robot de Google, ceux des assistants d'IA, et le chat du site lui-même. Cet article décrit ce que nous faisons pour les trois derniers, et ce que nous avons décidé de ne pas attendre. Il ne propose pas une liste d'astuces de « GEO » (generative engine optimization, l'optimisation pour les moteurs génératifs). Notre réponse : chaque notion est définie une fois, dans une fiche ; chaque page porte un seul graphe schema.org, vérifié au build ; le fichier llms.txt est publié parce qu'il ne coûte rien, sans qu'on en attende d'effet. L'article s'adresse aux équipes éditoriales et techniques qui tiennent un site de contenu.

Une notion, une fiche, une définition

La base de connaissances du site compte 363 fiches au 13 novembre 2026 : 126 concepts, 126 technologies, 10 méthodologies, 101 personnes. 313 sont indexables. Chaque fiche s'ouvre sur une phrase de définition. Celle du Forward Deployed Engineer dit : « Un Forward Deployed Engineer (FDE) est un ingénieur logiciel que son employeur envoie chez le client pour livrer un système d'IA en production. » C'est la définition de référence : la page de la fiche, le chat et les données structurées la reprennent telle quelle, et le lien automatique y renvoie.

La fiche porte aussi ce qu'un moteur ou un modèle cherche pour lever une ambiguïté :

• des alias (« FDE », « Forward Deployed Engineers », « AI FDE »…), qui servent au lien automatique et à la recherche du chat ;
• la forme longue d'un acronyme quand le corpus la donne (« Retrieval-Augmented Generation » pour RAG), posée à la main, jamais devinée ;
• des sections structurées, et une FAQ quand les questions sont réelles ;
• des sources : 277 fiches en portent, 2 053 au total, vérifiées en source primaire.

Le titre suit un gabarit par collection, en 60 caractères au plus : « X : définition et enjeux » pour un concept, « X : ce que c'est, à quoi ça sert » pour une technologie, « X : principes et mise en œuvre » pour une méthode. Le lecteur et le moteur savent avant le clic ce que la page contient.

Le lien automatique fait le reste. Sur les pages de la base, la première mention d'une notion pointe vers sa fiche. Dans les articles, seules 62 notions sans ambiguïté sont liées automatiquement : un alias qui est aussi un mot courant lierait n'importe quoi. La construction de cette base est racontée dans l'article sur la base de connaissances du site.

Un graphe par page, des renvois qui se referment

Chaque page porte un seul bloc JSON-LD : un graphe (@graph) dont les nœuds se désignent par leur identifiant (@id). L'organisation SFEIR et le site figurent sur toutes les pages, sous le même identifiant. Une fiche de concept devient un DefinedTerm, rangé dans un glossaire (DefinedTermSet) ; une technologie, une SoftwareApplication ; une méthode, un HowTo quand elle décrit des étapes ; une personne, une Person. Les formations sont des Course, les offres d'emploi des JobPosting, les agences des LocalBusiness.

Le lien le plus utile est about : il dit de quoi parle un article. Il se calcule : une fiche déclare les articles qui la traitent (relatedArticles), et le build inverse cette relation. 305 fiches déclarent au moins un article. Un article qu'aucune fiche ne cite n'a donc pas de about : le build le signale, sans bloquer.

Le build bloque en revanche ce qui rendrait le graphe faux : un identifiant qui ne renvoie à aucun nœud de la page, deux blocs JSON-LD sur une même page, une URL du plan du site marquée noindex. Chaque renvoi est refermé dans le même graphe, au besoin par un nœud réduit à son identité : type, identifiant, nom, URL.

Google indique se servir des données structurées pour comprendre le contenu d'une page¹. Nous en attendons une chose : qu'un lecteur automatique comprenne, sans deviner, que cet article parle de cette notion, définie à cette adresse, publiée par SFEIR. Aucun gain de position n'est garanti.

llms.txt : publié, sans en attendre d'effet

Le fichier llms.txt est une proposition de Jeremy Howard, publiée le 3 septembre 2024 : un fichier Markdown placé à la racine du site, qui présente ses pages aux modèles de langage². Celui de sfeir.com est généré au build. Il liste les offres, les expertises, les secteurs, une section sur le FDE écrite à la main, chaque fiche indexable, puis tous les articles, du plus récent au plus ancien : 742 entrées, environ 236 Ko.

Nous le publions parce qu'il ne coûte rien dans une chaîne de build déjà en place. Le 17 juin 2025, John Mueller, de Google, écrivait qu'aucun système d'IA n'utilisait llms.txt ; la documentation de Google Search sur les fonctions d'IA générative indique aujourd'hui que Google Search ne s'en sert pas³. Une étude d'Ahrefs publiée le 15 juin 2026 porte sur 137 210 domaines : environ 38 000 servent un fichier llms.txt en Markdown, sans que l'étude vérifie sa conformité à la spécification, et 97 % de ces fichiers n'ont reçu aucune requête en mai 2026⁴.

Laisser entrer les robots, sauf là où ils n'ont rien à faire

Le fichier robots.txt autorise tout, sauf deux familles d'adresses : l'API du chat, et les liens qui portent une question (?q=). Un lien de la forme /?q=… pose la première question du chat. Un robot qui exécute le JavaScript afficherait alors, sous www.sfeir.com, un texte écrit par n'importe qui. Ces adresses restent donc hors de l'exploration. Pour un visiteur, une question venue d'un lien que SFEIR n'a pas écrit s'affiche de toute façon en citation, signalée comme telle.

Les robots des assistants sont nommés un par un : ceux d'OpenAI, d'Anthropic et de Perplexity, ainsi que Google-Extended, Applebot-Extended et le robot de Common Crawl. Leurs blocs n'ouvrent rien de plus, la règle générale les autorise déjà. Ils répètent les deux exclusions, parce qu'un robot nommé dans son propre bloc n'obéit plus au bloc général⁵. Sans cette répétition, ces robots exploreraient les liens de questions. Le choix de fond est délibéré : les contenus de SFEIR sont ouverts aux moteurs de réponse comme à l'entraînement des modèles.

Des dates qui disent vrai

Un moteur juge la fraîcheur d'une page à ses dates ; elles doivent être exactes. Dans le plan du site, la date de modification d'une page est celle du dernier commit de son fichier source, jamais celle du build. Le pipeline clone donc le dépôt avec tout son historique : sur un clone partiel, toutes les pages auraient déclaré la date du jour. Un article ne reçoit une date de mise à jour (« Mis à jour le », dateModified) que pour une révision de fond.

Les titres suivent la même règle : jamais de compteur qui bouge seul (étoiles GitHub, téléchargements, valorisation). Le chiffre va dans le corps, daté dans sa phrase. Un chiffre tiré d'une publication datée reste bienvenu dans un titre : « DORA 2025 : 90 % utilisent l'IA » restera vrai. Le build signale les titres suspects.

Être cité ne fait pas venir

Une réponse d'assistant peut citer une page sans que personne ne clique. En juillet 2025, le Pew Research Center a observé que les utilisateurs de Google qui voyaient un résumé d'IA cliquaient sur un résultat classique lors de 8 % des visites, contre 15 % sans résumé ; les liens cités dans le résumé recueillaient 1 % des visites⁶. Google conteste la méthode de l'étude⁷.

Nous en tirons deux conséquences. Être lisible par les assistants est nécessaire, et ne suffit pas : la page qui compte reste celle qui répond à un acheteur, un candidat ou un partenaire, et le mène à l'étape suivante. Et le site devient lui-même un lieu où poser sa question : la conversation de l'accueil lit la même base, les mêmes fiches, le même catalogue que les robots. Son fonctionnement est décrit dans l'article sur l'architecture du site conversationnel.

Ce que nous ne savons pas encore

Nous ne publions pas de mesure du trafic venu des assistants : nous n'avons pas de chiffre assez propre pour le montrer. Les données structurées ne garantissent aucun résultat enrichi. llms.txt peut ne jamais être lu. L'effet certain tient au site lui-même : une notion définie une fois reste la même sur toutes les pages, et dans les réponses du chat.

Ce que ça change, selon votre rôle

Équipe éditoriale. Écrivez la définition une fois, dans une fiche, et liez-la. Formulez les titres dans les mots d'une recherche, sans compteur. Datez chaque fait mouvant dans sa phrase.

CTO. Un seul graphe par page, des identifiants stables, des renvois refermés : faites-en des contrôles de build, pas des recommandations. Générez llms.txt et le plan du site à partir des mêmes données que les pages. Pour aller plus loin sur les graphes, lisez notre article sur les knowledge graphs comme mémoire des agents.

DSI. La base de connaissances sert quatre lecteurs à la fois : vos visiteurs, les moteurs, les assistants et votre propre chat. C'est l'argument le plus solide pour financer sa tenue dans la durée.

Cet article fait partie d'une série sur la construction de sfeir.com, qui commence par l'histoire du site, du CMS à la conversation.