Votre SaaS est-il lisible par les agents IA ? llms.txt, MCP et données structurées

---

title: "Votre SaaS est-il lisible par les agents IA ? llms.txt, MCP et données structurées" seoTitle: "SaaS lisible par les agents IA : llms.txt et MCP" description: "Les offres GEO se vendent désormais 2 500 € par mois aux éditeurs de SaaS. Voici ce qui rend réellement un produit lisible par les agents, ce qui ne sert à rien, et l'ordre dans lequel s'y prendre." seoDescription: "Ce qui rend vraiment un SaaS lisible par ChatGPT, Perplexity et les agents : rendu serveur, robots.txt, llms.txt, données structurées et MCP." date: "2026-09-26" author: "Équipe Raicode" tags: ["saas", "SEO", "IA", "Next.js"] category: "SaaS & MVP" keywords: ["llms.txt", "SaaS visibilité IA", "GEO SaaS", "agents IA site web", "MCP site web", "données structurées SaaS", "OAI-SearchBot", "PerplexityBot", "robots.txt IA", "être cité par ChatGPT", "agent ready", "Next.js rendu serveur SEO"]

Un éditeur de SaaS B2B regarde ses inscriptions du trimestre et repère une ligne qui n'existait pas il y a un an : quelques dizaines de comptes créés depuis un referrer chatgpt.com. Peu de volume, mais un taux d'activation deux fois supérieur à celui de l'acquisition payante. La semaine suivante, une agence propose une offre « SEO & GEO » à 2 500 € HT par mois sur douze mois, avec un argument bien tourné : le référencement d'un SaaS ne bloque pas sur le contenu, il bloque dans le code. La question qui se pose au CTO n'est pas de savoir si le canal existe — les logs le prouvent — mais ce qu'il faut réellement changer dans le produit, et si ça vaut 30 000 € par an.

La réponse courte : l'argument de l'agence est exact, mais ce qui bloque dans le code se répare une fois, en quelques jours, et n'a rien à voir avec un abonnement mensuel. Le reste — les fichiers de découverte, les protocoles d'agents — coûte quelques heures et rapporte de façon très inégale. Cet article trie ce qui produit un effet mesurable de ce qui relève du bingo de conformité, en s'appuyant sur ce que nous avons déployé sur notre propre site et sur ce que les scanners publics en mesurent.

Trois questions différentes, qu'on confond en permanence

« Être visible pour les IA » recouvre trois problèmes qui n'ont ni les mêmes solutions ni le même retour.

Être lu. Un crawler d'IA récupère vos pages et les indexe. C'est le prérequis absolu, c'est là que 90 % des SaaS échouent, et c'est un problème de rendu, pas de contenu.

Être cité. Le modèle choisit votre page comme source quand il répond à une question. Cela dépend du contenu, de la structure, de la réputation du domaine — c'est la continuité du SEO, avec des critères voisins mais pas identiques.

Être utilisé. Un agent ne se contente plus de lire votre page : il appelle vos fonctions, cherche dans votre documentation, ouvre un devis. C'est un sujet d'intégration, pas de référencement, et c'est le seul des trois qui touche à l'architecture du produit.

Les offres packagées vendent les trois sous un même nom. Dans les faits, la première question se règle en quelques jours par une modification de rendu, la deuxième est un travail de contenu continu, et la troisième est un chantier produit qu'aucune agence de référencement ne saura livrer.

Ce que le crawler voit vraiment de votre application

Voici le test à faire avant toute discussion budgétaire. Depuis un terminal, récupérez une page publique de votre produit sans exécuter de JavaScript :

curl -sL https://votre-saas.fr/fonctionnalites/facturation | wc -c
curl -sL https://votre-saas.fr/fonctionnalites/facturation | grep -c "facturation"

Si le HTML brut fait 3 Ko et ne contient aucun de vos mots-clés, vous avez la réponse. Une application rendue intégralement côté client renvoie une coquille vide : une div racine et un bundle JavaScript. Googlebot sait exécuter ce bundle depuis des années, avec un délai et un coût, et c'est ce qui a permis aux SPA de survivre au référencement classique. Les crawlers des moteurs génératifs, eux, ne le font pas, ou de façon très partielle. OAI-SearchBot, PerplexityBot et les crawlers de recherche d'Anthropic récupèrent du HTML et s'en tiennent là.

Autrement dit : un SaaS en React sans rendu serveur est invisible pour ces moteurs, quelle que soit la qualité de son contenu, et aucune quantité de fichiers de découverte n'y changera quoi que ce soit. C'est ce que l'agence appelle « le SEO bloque dans le code », et elle a raison.

La correction dépend de votre stack. Sur Next.js en App Router, il s'agit de sortir les pages publiques — accueil, pages fonctionnalités, tarifs, documentation, blog, pages de comparaison — du périmètre 'use client' et de les rendre côté serveur. Les vues authentifiées peuvent rester intégralement côté client : personne n'indexe votre tableau de bord. Sur une SPA Vite ou Create React App, la solution honnête est de sortir le site public de l'application : un site statique ou rendu serveur distinct, sur le même domaine, qui porte tout le contenu indexable. C'est typiquement la dette qu'on découvre quand un MVP a grandi sans que personne n'ait distingué le produit du site, et c'est un des premiers arbitrages que nous posons sur un développement de MVP SaaS : ce qui est public et rendu côté serveur d'un côté, ce qui est applicatif et authentifié de l'autre, dès le premier sprint plutôt qu'au bout d'un an.

Comptez de trois jours à trois semaines selon l'état du code. C'est ponctuel, c'est mesurable, et c'est la dépense qui compte.

robots.txt : l'arbitrage que tout le monde rate

Deuxième cause de non-citation, bien plus fréquente qu'on ne le croit : le site a bloqué les robots d'IA sans distinguer ce qu'ils font.

Les grands fournisseurs utilisent des agents distincts pour des usages distincts. Chez OpenAI, GPTBot collecte pour l'entraînement, OAI-SearchBot alimente l'index de recherche, ChatGPT-User récupère une page à la demande quand un utilisateur pose une question. Chez Google, Google-Extended contrôle l'usage pour les modèles génératifs, sans affecter l'indexation par Googlebot. Anthropic sépare de la même façon crawl d'entraînement, crawl de recherche et récupération à la demande.

Une équipe qui a décidé en 2025 de « ne pas nourrir les IA » a très souvent posé un Disallow: / sur la moitié de ces agents, dont ceux qui alimentent la recherche. Le résultat est exactement celui qu'elle ne voulait pas : le contenu n'est pas moins utilisé pour l'entraînement — ce n'est pas comme ça que ça se joue — mais le produit a disparu des réponses. Le bon arbitrage, dans la quasi-totalité des cas pour un SaaS, est d'autoriser la recherche et la récupération à la demande, et de refuser l'entraînement si c'est votre position.

Les Content Signals, apparus dans le sillage de l'initiative de Cloudflare fin 2025, permettent d'exprimer cette nuance dans le robots.txt lui-même : une déclaration qui sépare l'usage search, l'usage ai-input (la citation en réponse) et l'usage ai-train. Leur portée juridique est incertaine et leur respect dépend de la bonne volonté des opérateurs, mais elles coûtent trois lignes et documentent une intention. Sur notre propre site, ces deux contrôles — règles nommées pour douze agents d'IA et Content Signals — sont les seuls du chapitre « accès des robots » à être validés par les scanners publics, et ce sont les deux qui comptent.

llms.txt : ce que c'est, et ce que ça vaut aujourd'hui

llms.txt est un fichier Markdown à la racine du domaine, proposé fin 2024 par Jeremy Howard. Il résume ce qu'est le site, liste les ressources importantes avec leur URL et une phrase de description, et existe souvent en deux versions : un sommaire court et un llms-full.txt qui contient le contenu complet.

Il faut être précis sur son statut, parce que c'est le cœur de l'argumentaire des offres GEO. À ce jour, aucun des grands fournisseurs de modèles n'a confirmé publiquement s'en servir pour alimenter la recherche ou la citation, et plusieurs voix du côté de Google ont explicitement indiqué le contraire. Ce n'est pas un standard adopté, c'est une convention émergente, poussée surtout par les éditeurs d'outils pour développeurs.

Faut-il le faire quand même ? Oui, pour deux raisons qui n'ont rien à voir avec la promesse commerciale. D'abord, le coût est dérisoire : notre llms.txt fait 2,5 Ko, le llms-full.txt 8 Ko, tous deux générés depuis les mêmes sources que le site, donc jamais périmés. Ensuite, l'exercice est utile en soi : écrire en quinze lignes ce que fait votre produit, pour qui, avec quelles offres et à quels prix, sans marketing, révèle immédiatement si votre positionnement est clair. Beaucoup d'équipes découvrent à ce moment-là qu'elles n'ont pas de phrase courte pour décrire ce qu'elles vendent.

Ce qu'il ne faut pas faire : payer un abonnement mensuel pour un fichier statique de 2 Ko. Si une offre met llms.txt en tête de ses livrables, c'est un signal sur l'offre, pas sur le fichier. Et si le fichier est écrit à la main puis jamais mis à jour, il deviendra faux en trois mois — la seule version défendable est générée.

Données structurées et Markdown : rendre le contenu extractible

C'est la couche qui reste la mieux documentée et la plus fiable, parce qu'elle sert à la fois la recherche classique et les moteurs génératifs. Pour un SaaS, trois types de schema.org font le travail : Organization sur toutes les pages, SoftwareApplication sur la page produit avec l'offers correspondant à votre grille tarifaire, et FAQPage sur les pages qui répondent à de vraies questions. Le principe général et les pièges de balisage sont détaillés dans notre guide sur les données structurées et Schema.org ; ce qui change pour un SaaS, c'est que le prix doit y figurer. Une réponse générative qui compare trois outils reprend les tarifs qu'elle trouve balisés, et laisse de côté celui qui affiche « à partir de » dans une image.

Un mécanisme moins connu mérite l'attention : la négociation de contenu. Un agent qui envoie l'en-tête Accept: text/markdown reçoit la version Markdown de la page au lieu du HTML — sans navigation, sans scripts, sans bandeau de cookies. Pour un modèle, c'est la différence entre 4 000 tokens de balises et 900 tokens de texte utile. L'implémentation est simple si votre contenu vient déjà de fichiers Markdown ou MDX : une route qui renvoie la source, et le bon en-tête Vary. C'est aussi ce qui vous donne une version propre de votre documentation à passer à n'importe quel assistant, ce qui a de la valeur en interne même sans aucun crawler.

MCP : quand la lisibilité devient une intégration

Les trois couches précédentes servent à être lu et cité. La quatrième change de nature : elle rend le produit appelable.

Un serveur MCP exposé en HTTP sur votre domaine permet à un client compatible d'appeler vos fonctions plutôt que de lire vos pages. Sur raicode.tech, /mcp expose quatre outils — chercher dans les articles, lire un article, lister les offres, demander un devis — en JSON-RPC 2.0. Une carte de serveur à /.well-known/mcp/server-card.json permet la découverte automatique, un catalogue /.well-known/ai-catalog.json décrit les six ressources agentiques du site avec des exemples de requêtes, et deux outils WebMCP s'enregistrent via navigator.modelContext quand le navigateur le propose. Le scanner public isitagentready.com nous place au niveau 4 sur 5 : onze contrôles validés, avec l'authentification OAuth et la carte d'agent A2A comme seuls écarts restants vers le niveau 5.

Ce que ce protocole règle et ce qu'il ne règle pas mérite d'être compris avant de s'y lancer — nous l'avons détaillé dans ce que MCP change vraiment. Pour le sujet qui nous occupe, deux constats. D'un côté, la maturité est réelle côté spécification et adoption par les clients : ce n'est plus un pari. De l'autre, l'effet sur l'acquisition est aujourd'hui marginal — très peu d'utilisateurs finaux arrivent sur un produit par un appel MCP. L'intérêt est ailleurs : dans les usages internes, dans l'intégration à l'écosystème de vos clients, et dans le fait d'avoir traité une fois pour toutes la question « comment un programme consomme nos données ». Si votre produit a une API, exposer un sous-ensemble en MCP représente quelques jours. Si votre produit n'a pas d'API, commencez par l'API.

L'ordre des opérations, et ce qu'il coûte

Pour un SaaS qui part de zéro sur le sujet, la séquence qui maximise le retour est celle-ci, et elle se lit comme un budget :

1. Rendu serveur des pages publiques — de 3 jours à 3 semaines. Sans cette étape, aucune des suivantes ne produit quoi que ce soit.
2. Arbitrage robots.txt par agent, avec Content Signals — une demi-journée. C'est le meilleur rapport effet/effort du lot, surtout s'il y a un blocage hérité à corriger.
3. Données structurées avec les tarifs — 1 à 2 jours. Sert la SERP classique autant que les réponses génératives.
4. llms.txt généré, négociation Markdown — 1 à 2 jours. Faible certitude de gain, coût faible, bénéfice interne immédiat.
5. Contenu qui répond à de vraies questions — continu, et c'est la seule ligne récurrente légitime. Les pages qui se font citer sont celles qui répondent à une question précise avec des chiffres, des comparaisons et des limites assumées. Les principes du Generative Engine Optimization s'appliquent, avec une exigence de preuve plus élevée sur un sujet technique.
6. MCP et catalogues d'agents — quelques jours, quand une API existe déjà. Un investissement produit, pas une dépense d'acquisition.

Les points 1 à 4 représentent entre une et quatre semaines de travail ponctuel. Un abonnement à 2 500 € par mois sur douze mois représente 30 000 €. La question à poser à l'agence n'est donc pas « que livrez-vous » mais « qu'est-ce qui, dans votre offre, est récurrent ». Si la réponse est le contenu et le suivi des citations, l'offre est défendable. Si elle consiste à facturer chaque mois des fichiers de découverte posés une fois, elle ne l'est pas.

Mesurer, sinon vous ne saurez jamais

Dernier point, et c'est celui qui manque dans presque toutes les offres : la Search Console ne vous dira rien de ce canal. Les impressions dans ChatGPT ou Perplexity n'y figurent pas. Trois sources permettent de suivre l'effet réellement.

Les logs serveur filtrés par user-agent : le volume de requêtes d'OAI-SearchBot, PerplexityBot, ClaudeBot et consorts, et surtout les pages qu'ils récupèrent. Un pic après le passage au rendu serveur est le signal le plus direct que l'étape 1 a fonctionné.

Les referrers : les visites entrantes depuis chatgpt.com, perplexity.ai, claude.ai, gemini.google.com. Segmentez-les dans votre analytique comme une source à part entière et comparez leur taux d'activation aux autres canaux — c'est généralement là que la surprise est bonne, et c'est le chiffre qui justifie le budget en interne.

Le test manuel régulier : posez à trois assistants les cinq questions qui devraient mener à votre produit — « quel outil pour tel usage », « alternative à tel concurrent », « comment faire telle chose » — et notez qui est cité. Dix minutes par mois, consignées dans un tableau. C'est grossier, ce n'est pas statistiquement solide, mais c'est la seule mesure directe de la position que vous occupez dans ces réponses, et elle se dégrade vite quand un concurrent publie sérieusement.

Par où commencer cette semaine

Lancez les deux commandes curl du début sur trois de vos pages publiques. Si le HTML est vide, vous avez votre chantier et votre priorité, et le reste peut attendre. Si le HTML est plein, ouvrez votre robots.txt et vérifiez agent par agent que vous n'avez pas bloqué la recherche en croyant bloquer l'entraînement — c'est une correction d'une heure qui rouvre un canal entier. Ensuite seulement, les fichiers de découverte et le contenu.

Ce qui rend un SaaS lisible par les agents n'est pas une liste de fichiers à cocher, c'est une propriété de son architecture : le contenu public doit exister sous forme de texte, à une URL stable, sans exécution de code. Tout le reste en découle, et rien ne le remplace.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.