Google a mis à jour sa documentation sur le rich result SoftwareApplication le 8 septembre 2026. Si tu vends un outil SaaS, il y a de bonnes chances que ta page pricing loupe au moins une des trois conditions requises pour en profiter — et deux réflexes très répandus chez les éditeurs SaaS aggravent le problème : cacher son prix derrière un formulaire "Contacte-nous" pour mieux qualifier les leads, et injecter le balisage schema via Google Tag Manager plutôt que dans le HTML servi au premier chargement.
SoftwareApplication ou Product : lequel balise ta page pricing
Google propose deux familles de structured data pour un produit vendu en ligne. Product cible la vente au détail : un objet ou un abonnement générique avec un Offer imbriqué. SoftwareApplication est le type dédié aux logiciels. Il ajoute deux propriétés qu'aucun Product ne porte nativement — applicationCategory et operatingSystem — et débloque un rich result propre qui affiche note, prix et catégorie sous ton lien dans les résultats Google.
Réponse directe : pour un SaaS B2B vendu en self-service (pas distribué via un store mobile), c'est SoftwareApplication qu'il faut poser sur la page pricing ou la page produit. Product reste pertinent pour de l'e-commerce classique, ou en complément si tu vends aussi des add-ons facturés à l'unité.
Les trois conditions obligatoires — et celle qui bloque presque tout le monde
D'après la documentation Google, trois éléments sont requis pour l'éligibilité au rich result, pas juste recommandés :
| Propriété | Exigence | Piège courant |
|---|---|---|
name | Le nom de l'application | Rarement un problème |
offers.price | Un prix chiffré, 0 pour un plan gratuit, priceCurrency pour un plan payant | Prix caché derrière "Contacte-nous" = rien à déclarer |
aggregateRating OU review | Au moins une note moyenne ou un avis individuel | Zéro avis affiché = zéro schema valide possible |
Le piège numéro un : si ta stratégie commerciale consiste à masquer le prix pour forcer un appel de qualification, tu n'as tout simplement rien à mettre dans offers.price. Pas de contournement propre — un prix fictif ou une fourchette mal sourcée viole les règles de contenu de Google et expose au retrait du rich result sur tout le domaine, pas juste sur la page fautive.
Le piège numéro deux, moins connu : aggregateRating n'est valide que si elle respecte les mêmes règles qu'un Review classique (voir notre guide sur Review et AggregateRating) — pas d'auto-notation de ta propre marque, pas d'avis fabriqués. Sans avis clients réels quelque part (Trustpilot, G2, ou une page avis correctement balisée sur ton propre site), tu ne peux légitimement remplir ni aggregateRating ni review.
Mini cas : une page pricing qui passe de zéro à éligible
Prends un SaaS fictif à trois plans (19 €, 49 € et 99 €/mois), sans avis affichés nulle part sur le site. Passée dans le Rich Results Test, la page pricing échoue immédiatement : aucun aggregateRating, aucun review, condition obligatoire non remplie. Après ajout d'un aggregateRating sourcé sur 34 avis Trustpilot réels (note moyenne 4,6/5) et d'un operatingSystem fixé à "Web", le test passe. Le rich result met généralement entre 5 et 15 jours à apparaître après le prochain passage de Googlebot — le délai d'indexation classique, rien d'accéléré par le schema lui-même.
applicationCategory et operatingSystem : les deux propriétés qui lèvent l'ambiguïté
Ces deux propriétés sont recommandées, pas obligatoires, mais elles évitent que Google classe mal ton outil. applicationCategory doit venir de la liste fermée de Google (BusinessApplication, DeveloperApplication, SecurityApplication, etc.) — un SaaS qui invente sa propre catégorie ("ProductivityTool") ne se fait pas rejeter, il perd simplement l'information, qui n'est alors pas exploitée. operatingSystem accepte des valeurs comme "Web", "Windows, macOS" ou "iOS, Android" selon les plateformes réellement supportées — mentir ici (déclarer une compatibilité mobile qui n'existe pas) tombe sous le coup des règles générales sur les données structurées trompeuses.
Exemple minimal pour un SaaS web B2B :
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "TonOutil",
"applicationCategory": "BusinessApplication",
"operatingSystem": "Web",
"offers": {
"@type": "Offer",
"price": "49",
"priceCurrency": "EUR"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"ratingCount": "34"
}
}
Est-ce que ça sert à quelque chose pour les citations IA ?
Imagine deux pages pricing strictement identiques dans leur contenu visible — mêmes plans, mêmes textes, même mise en page. L'une porte un balisage SoftwareApplication complet, l'autre aucun schema. Est-ce que ça change quoi que ce soit à laquelle des deux ChatGPT ou Perplexity vont citer ? Une analyse Ahrefs publiée en 2026 a testé précisément ce type de question, et la réponse est nette : le schema n'a pas d'effet démontré sur la façon dont les moteurs IA génèrent leurs réponses, et la plupart d'entre eux strippent purement et simplement les données structurées pendant le traitement. Sur ce seul critère, nos deux pages fictives auraient des chances de citation comparables.
Ce qui complique le tableau : SE Ranking a mesuré qu'environ 71 % des pages citées par ChatGPT et 65 % de celles citées par Google AI Mode contiennent effectivement du structured data. Le chiffre est réel, mais il raconte une histoire différente de celle qu'on voudrait y lire — ces pages ont probablement d'autres qualités qui expliquent leur citation (autorité, fraîcheur, structure éditoriale claire), et le schema n'en est qu'un symptôme parmi d'autres, pas la cause. Sur la corrélation avec un type de schema précis, SE Ranking elle-même ne relève qu'un lien qualifié de "très faible".
Là où SoftwareApplication a un effet direct et vérifiable, c'est sur Google Search classique (le rich result lui-même) et sur la lisibilité machine de ta page pour n'importe quel crawler, IA compris — à une condition technique non négociable : le schema doit être présent dans le HTML servi au premier chargement, pas injecté après coup via Google Tag Manager ou un script client. Les crawlers IA comme GPTBot ou ClaudeBot n'exécutent pas systématiquement le JavaScript ; un schema posé uniquement côté client leur est tout simplement invisible. On détaille ce piège de rendu dans notre guide JavaScript SEO et rendu SSR/CSR.
Quand ne PAS poser SoftwareApplication
Trois cas où ce n'est pas le bon choix. D'abord, si tu n'as aucun avis client réel et pas de plan pour en collecter rapidement : mieux vaut ne rien déclarer que de fabriquer un aggregateRating, qui expose à une action manuelle sur tout le domaine. Ensuite, si ton produit est un service accompagné (agence, conseil, implémentation sur-mesure) plutôt qu'un logiciel en libre-service : Service ou Organization correspondent mieux à la réalité de l'offre, et un faux SoftwareApplication sur une prestation de service est un cas classique de données structurées non représentatives du contenu réel. Enfin, si ta page pricing n'affiche jamais de prix chiffré par choix commercial assumé : pose le schema minimal viable (name, applicationCategory) sans offers plutôt que d'inventer un prix, et accepte de ne pas être éligible au rich result complet tant que cette stratégie reste en place.
À retenir
SoftwareApplicationexige trois choses non négociables :name,offers.pricechiffré, etaggregateRatingoureview- Un prix caché derrière "Contacte-nous" ou l'absence totale d'avis rend le rich result inatteignable, il n'y a pas de raccourci propre
applicationCategoryetoperatingSystemsont recommandés, pas obligatoires, mais lèvent l'ambiguïté pour Google comme pour les crawlers IA- Le schema doit vivre dans le HTML servi au premier chargement — un balisage posé via GTM seul est invisible pour GPTBot et ClaudeBot
- Le schema n'a pas d'effet démontré et direct sur la citation par les IA génératives, mais il reste corrélé (71 % des pages citées par ChatGPT en contiennent) et il sécurise ton rich result Google classique
FAQ
Faut-il utiliser SoftwareApplication ou Product pour une page pricing SaaS ?
SoftwareApplication, dans la quasi-totalité des cas d'un SaaS B2B vendu en self-service. Product reste pertinent pour de l'e-commerce classique ou des add-ons facturés à l'unité.
Peut-on déclarer un prix "à partir de X €" dans offers.price ?
Techniquement oui via priceSpecification avec une fourchette, mais le prix doit rester exact et vérifiable sur la page. Un prix d'appel qui ne correspond à aucun plan réellement disponible viole les règles de contenu de Google.
AggregateRating sans aucun avis client, c'est possible ?
Non. AggregateRating doit reposer sur des avis réels et vérifiables, sur ton site ou une plateforme tierce (Trustpilot, G2, Capterra). Sans avis, le schema minimal viable n'inclut ni aggregateRating ni review, et le rich result complet n'est pas atteignable.
Le rich result SoftwareApplication apparaît en combien de temps ?
Comme pour toute donnée structurée, ça suit le cycle d'indexation classique de Google : généralement entre 5 et 15 jours après le prochain passage de Googlebot sur la page, une fois le schema valide en place.
Envie de savoir si ta page pricing est bien balisée avant d'aller plus loin ? Lance l'audit gratuit SeAudit pour ton score /100, ou passe au rapport complet pour un diagnostic technique détaillé.
