Schéma SoftwareApplication : le prix et la note qui décident de l'affichage

Le schéma SoftwareApplication n'est éligible au résultat enrichi « application » de Google que s'il contient trois éléments : name, offers.price, et soit aggregateRating, soit review. Une page peut déclarer le nom et la catégorie, omettre les deux autres, et passer tous les validateurs de syntaxe. Valide ne veut pas dire éligible. La documentation Google sur les applications, lue le 2026-10-25, traite un prix ou une note manquants comme une condition non remplie, pas comme un avertissement.

Ce que le schéma SoftwareApplication exige vraiment

Trois propriétés font le travail. Deux sont facultatives dans schema.org et obligatoires pour Google, ce qui explique pourquoi tant de pages s'arrêtent à une ligne du but.

C'est la note qui bloque le plus de projets. Un aggregateRating exige ratingValue et ratingCount ; un review unique exige un auteur et une note. Les règles Google sur les extraits d'avis sont nettes : ne regroupez pas des avis ou des notes venus d'autres sites, et n'incluez pas de faux avis ni d'avis rémunérés non divulgués. La note doit porter sur votre produit et venir de personnes qui l'ont utilisé.

applicationCategory prend une valeur dans la liste prise en charge par Google. BusinessApplication, DeveloperApplication et DesignApplication en font partie ; WebApplication est un type, pas une catégorie. Copiez une valeur de la documentation plutôt que d'inventer une étiquette qui sonne bien.

Un résultat d'application, c'est un nom, un prix et une note. S'il en manque un, Google n'a rien à afficher.

Quel type choisir : WebApplication, SoftwareApplication ou Product

Un produit qui tourne dans le navigateur est en général une WebApplication, une application de bureau ou mobile à installer est une SoftwareApplication, et un article vendu depuis un catalogue est un Product. Google accepte les trois ; l'erreur consiste à empiler deux types sur la même page avec deux prix différents.

Une exception documentée mérite d'être connue avant le choix : Google n'affiche pas de résultat enrichi pour une application qui ne porte que le type VideoGame. Il faut ajouter un second type, par exemple MobileApplication. Le cas est étroit, mais c'est exactement le genre de détail qui laisse un balisage correct sans aucun effet visible.

Si votre page vend déjà une offre avec un prix et une disponibilité, lisez d'abord comment rédiger une landing page produit et décidez quel type possède le prix sur cette page. Ne marquez pas les deux avec des chiffres différents.

Le livrable : un bloc à copier

Voici le plus petit bloc éligible pour un produit web avec une offre gratuite. Remplacez les quatre valeurs, gardez la structure.

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Example",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "ratingCount": "128"
  }
}

L'offre gratuite est le piège classique : offers.price reste obligatoire quand la réponse est zéro, donc écrivez "price": "0" au lieu de supprimer l'objet offer. Pour une offre payante, mettez le prix d'entrée réel et conservez priceCurrency. Pour une application à télécharger, remplacez @type par SoftwareApplication et indiquez les plateformes concernées.

Les valeurs doivent venir de la même fiche que votre description produit pour tous les canaux, pour que le prix et le nom ne divergent pas d'une page à l'autre.

N'ajoutez aggregateRating que si la page affiche cette note aux visiteurs. Les règles générales de Google imposent que le balisage décrive le contenu visible ; une note qui n'existe que dans une balise script est une déclaration trompeuse. Les règles sur les avis ajoutent que les notes agrégées doivent venir d'avis réels, pas d'un autre site.

Le livrable : la vérification en huit lignes

Faites-les dans l'ordre. Les quatre premières arrêtent un bloc qui ne peut pas fonctionner ; les quatre suivantes arrêtent un bloc qui fonctionne mais décrit la mauvaise page.

Le bloc a sa place dans le modèle de page, à côté du titre et de la description, pour qu'il ne dérive pas quand quelqu'un modifie le corps. Les valeurs doivent venir de la même source que l'affichage : une note écrite à la main est le premier champ qui vieillit mal.

1. Collez l'URL de la page dans le Rich Results Test et vérifiez que « Software app » est détecté.
2. Lisez les erreurs avant les avertissements. Une propriété obligatoire manquante est une erreur ; une propriété recommandée manquante n'en est pas une.
3. Ouvrez la même URL dans l'inspection d'URL et vérifiez que le HTML rendu contient bien le bloc.
4. Surveillez le rapport sur les données structurées dans Search Console les jours suivants. Il dit ce que Google a trouvé, pas ce que vous vouliez.

Pourquoi un balisage valide n'affiche quand même rien

Les échecs prennent quatre formes, et aucune n'est une erreur de syntaxe. Le bloc s'analyse, la page s'indexe, le résultat n'apparaît jamais.

La quatrième ligne est la plus silencieuse. Une équipe balise souvent l'annonce de lancement parce que c'est la page qu'elle modifie, alors que la page produit, celle qui décrit réellement l'application, ne porte rien. Google évalue la page où se trouve le bloc. Si le résultat doit apparaître sur la page produit, le bloc doit y être.

Un autre échec arrive plus tôt : le JSON lui-même est cassé, une virgule en trop ou un guillemet manquant. Le test affiche alors une erreur d'analyse, et Search Console range ces cas dans le rapport sur les données structurées illisibles. Inutile de deviner.

Ce que nous ne savons pas, et quand s'arrêter

Nous ne savons pas à quelle fréquence Google choisit d'afficher le résultat d'application quand une page est éligible. Google ne publie pas de taux d'affichage, ne garantit pas qu'une fonctionnalité utilisant des données structurées apparaisse, et nous ne l'avons pas mesuré assez longtemps sur nos propres pages pour avancer un chiffre. L'éligibilité est ce que vous contrôlez ; l'affichage ne l'est pas.

Il existe aussi un cas où la réponse honnête est d'attendre. Si le produit n'a pas encore de notes réelles, n'inventez pas un chiffre et n'en copiez pas un depuis un site d'avis. Publiez le nom, la catégorie et le prix, puis ajoutez la note quand de vrais utilisateurs en auront laissé une. Une note absente coûte le résultat enrichi ; une note fabriquée coûte le balisage, la page et la confiance pour laquelle elle a été écrite.

Arrêtez-vous quand le test liste l'application sans erreur et que la page visible correspond au bloc. Le reste est une question de mesure, pas de balisage : c'est du côté analyse des recherches et de l'IA que ce suivi se fait, pas dans le code source.

Questions fréquentes

À quoi sert le schéma SoftwareApplication ?

C'est un balisage schema.org qui décrit un produit logiciel sur une page : nom, catégorie, plateformes, prix et note. Google s'en sert pour décider si la page peut afficher un résultat d'application avec un nom, un prix et des étoiles.

Google prend-il encore en charge ce balisage ?

Oui. La documentation Google sur les applications était toujours en ligne et datait sa dernière mise à jour du 2026-09-08 lors de notre lecture du 2026-10-25, et le résultat d'application y figure toujours. Contrairement à FAQ et HowTo, cette fonctionnalité n'a pas été retirée.

Le balisage d'application affiche-t-il des étoiles ?

Seulement s'il porte une note ou un avis. Avec un nom et un prix mais aucune note, la page ne remplit pas les conditions obligatoires. Avec une note inventée, le problème passe de l'affichage à la conformité aux règles.

Faut-il écrire SoftwareApplication et Product ensemble ?

Non. Choisissez le type qui correspond à ce que la page vend et laissez-lui le prix. Deux types avec deux prix différents sur la même page donnent deux faits contradictoires à Google, et aucun moyen de savoir lequel a été lu.

Pourquoi le Rich Results Test ne trouve-t-il rien ?

Souvent parce que le JSON-LD est ajouté en JavaScript après le HTML que le test voit d'abord, ou parce que l'URL testée n'est pas celle qui porte le bloc. Rendez le bloc côté serveur et testez l'URL exacte censée se classer, pas la page d'accueil.