Schema.org pour le SaaS B2B : le minimum viable en JSON-LD
Les cinq types de schema dont toute entreprise SaaS B2B a besoin, avec des snippets JSON-LD prêts à coller : Organization, Service, FAQPage, BreadcrumbList et Article.
Pour une entreprise SaaS B2B, cinq types de schema valent plus que tous les autres réunis : Organization, Service, FAQPage, BreadcrumbList et Article. Implémentés en JSON-LD, avec des @id stables et des liens entre eux, ils constituent le minimum viable pour commencer à être citable par l'IA. Cet article donne le snippet de chacun, prêt à adapter.
L'essentiel
JSON-LD est la bonne sérialisation en 2026
cinq types couvrent 80 % du gain : Organization, Service, FAQPage, BreadcrumbList, Article
des @id stables transforment des entités isolées en graphe
valider sur validator.schema.org et dans le Rich Results Test
un schema hors sujet est pire que pas de schema du tout
Pourquoi le schema compte pour le GEO
Schema.org est le vocabulaire standard des données structurées. En HTML, décrire quelque chose comme une organisation est implicite (par des balises comme header, des classes CSS, le contexte). Dans le schema, c'est explicite : @type: Organization.
Pour les moteurs traditionnels, le schema ouvre l'accès aux résultats enrichis (étoiles, FAQ dépliée, fil d'Ariane visible). Pour les LLM, le schema est le seul moyen fiable de savoir, sans ambiguïté, ce qu'est chaque chose. Quand ChatGPT cite « Acme est un cabinet de conseil en cybersécurité à Lisbonne », il déduit trois choses (ce que c'est, ce que cela fait, où), et le schema réduit la marge d'erreur.
Les cinq types, un par onglet
La fondation. Une entité Organization par entreprise, avec un @id stable, référencée par toutes les autres entités comme provider, author, publisher.
Trois champs critiques : sameAs (liens vers des profils externes cohérents : LinkedIn, GitHub, Wikipédia s'il existe), knowsAbout (3 à 10 sujets qui affirment l'expertise de l'entreprise) et contactPoint avec availableLanguage.
Un Service par service proposé. Il se rattache à l'Organization par provider :
Pour un SaaS B2B à tarification variable, AggregateOffer avec lowPrice signale le point d'entrée sans s'engager sur une grille tarifaire exposée. Cela fonctionne bien pour « à partir de X EUR » sans révéler le plafond.
Un bloc de questions et réponses au format structuré. Les modèles d'IA préfèrent citer ce format parce qu'il est trivial à extraire :
{
"@context": "https://schema.org",
"@type": "FAQPage",
"@id": "https://acme.com/#faq",
"isPartOf": { "@id": "https://acme.com/#website" },
"mainEntity": [
{
"@type": "Question",
"name": "Acme s'intègre-t-il à un ERP ?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Oui. Intégration native avec SAP B1, Primavera et PHC."
}
}
]
}
Règle empirique : 5 à 10 questions par FAQPage. Au-delà, c'est du bruit. Les questions doivent correspondre aux requêtes réelles des clients, pas à des requêtes inventées par l'équipe marketing.
Petit mais important. Il aide les crawlers à comprendre la hiérarchie de vos pages. Il produit un résultat visible dans les SERP de Google et donne des indices structurels aux LLM :
Chaque article de blog devrait porter BlogPosting (plus précis qu'Article) avec les champs critiques :
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://acme.com/blog/integrate-sap#article",
"headline": "Comment intégrer Acme à SAP B1 en 30 minutes",
"description": "Guide technique d'intégration via API REST.",
"image": "https://acme.com/og-image.png",
"datePublished": "2026-05-01",
"dateModified": "2026-05-01",
"author": { "@id": "https://acme.com/#organization" },
"publisher": { "@id": "https://acme.com/#organization" },
"mainEntityOfPage": {
"@id": "https://acme.com/blog/integrate-sap#webpage"
},
"articleSection": "Intégrations",
"inLanguage": "fr"
}
Trois détails que beaucoup de sites ratent : mainEntityOfPage doit pointer vers une WebPage réellement émise (pas vers un @id qui n'existe jamais). articleSection aide les LLM à catégoriser. author et publisher référencent l'Organization par @id au lieu de dupliquer les données.
L'idée de @graph (et pourquoi elle compte)
Si vous avez plusieurs entités sur la même page, vous pouvez les regrouper dans un @graph au lieu de disperser plusieurs blocs de script application/ld+json :
L'avantage : moins de parsing, un contexte partagé, des liens explicites par @id. Pour les LLM, un graphe cohérent est nettement plus lisible que cinq scripts isolés.
Comment les cinq se relient par @id
Type
@id
Relié à
Organization
#organization
Référencé par les autres comme provider, author, publisher
Rich Results Test, indique quelle partie de votre schema est éligible aux résultats enrichis de Google.
Inspection manuelle dans les DevTools : copier le JSON, le parser, confirmer que les @id sont reliés.
Les erreurs que nous voyons souvent
Entités dupliquées. Organization redéclarée sur chaque page au lieu d'être référencée par @id.
@id absent. Le schema fonctionne, mais les LLM traitent chaque bloc comme une entité indépendante.
FAQPage aux questions fabriquées. L'équipe invente des questions pensées pour le SEO au lieu de reprendre les vraies. Résultat : tout perd sa crédibilité.
Article sans dateModified. Les modèles préfèrent citer des contenus récents ; sans dateModified, ils n'ont aucun signal de mise à jour.
Questions fréquentes
JSON-LD. C'est le seul que Google recommande explicitement, le plus propre à maintenir (il sépare le balisage sémantique du HTML de présentation), et celui que les LLM extraient avec la plus grande fidélité. Microdata et RDFa restent pris en charge pour compatibilité, mais ne valent pas la peine pour démarrer en 2026.
Les deux fonctionnent, la spécification n'impose rien. Dans l'App Router de Next.js, le schéma habituel consiste à l'injecter avec un composant JsonLd dans le return de la page (dans le body, avant le contenu). Sur les sites statiques, le head est plus propre. Dans les deux cas, une balise script par bloc sémantique évite la duplication.
Ce n'est pas obligatoire, mais c'est la différence entre un ensemble d'entités isolées et un graphe cohérent. Avec des @id stables (comme https://example.com/#organization), vous pouvez référencer la même entité depuis plusieurs pages sans la dupliquer. Les moteurs et les LLM préfèrent nettement les graphes reliés.
Un schema hors sujet ou inventé est pire que pas de schema du tout. Chaque type doit correspondre à quelque chose de réel sur la page. Baliser une page de tarifs comme Recipe est tout simplement faux ; la baliser comme AggregateOffer a du sens. Règle : si vous ne pouvez pas justifier sa présence, retirez-le.
Diego MoraesCTO
Ouvrir dans ChatGPT
Ouvrir dans Claude