Ecrit avec amour par :
En 2026, la recherche de restaurant a definitivement quitte le seul territoire de Google. Elle transite desormais par le Mode IA de Google, par ChatGPT et Perplexity, par les AI Overviews qui s'affichent en tete des resultats, et par des mecaniques de commerce agentique naissantes comme Ask Maps ou la reservation via LLM. Tous ces canaux ont un point commun : ils lisent en profondeur les informations que vous publiez, bien au-dela de ce qu'un utilisateur voit a l'ecran.
Et pour lire en profondeur, ils s'appuient sur une brique fondamentale, souvent invisible pour le restaurateur : les donnees structurees Schema.org. Ces etiquettes techniques permettent aux moteurs et aux IA de comprendre precisement ce qu'est votre contenu : un restaurant, un menu, un plat, un avis, un evenement. Sans elles, votre etablissement reste une page parmi d'autres. Avec elles, il devient une entite comprehensible, categorisable, exploitable.
Le sujet parait technique et opaque, et il l'est en partie. Mais le pilotage, lui, ne l'est pas. Cet article vous explique en langage clair ce que sont les donnees structurees, pourquoi elles pesent plus lourd en 2026, quels sont les 5 types de balisage a connaitre pour un restaurant, qui les pose concretement, et comment verifier que tout est bien en place, sans avoir a lire une ligne de code.
Schema.org est un vocabulaire commun maintenu depuis 2011 par Google, Microsoft, Yahoo et Yandex pour aider les moteurs a comprendre precisement ce que contient une page. Concretement, ce sont des etiquettes invisibles ajoutees dans le code d'un site ou d'une fiche pour dire : "cet element est un restaurant", "ce bloc est un plat", "ce chiffre est une note d'avis", "cette date est une horaire d'ouverture".
L'analogie la plus utile est celle du code-barres. Sur un produit en rayon, l'humain voit une boite en carton avec une image de cereales. Le systeme de caisse, lui, lit le code-barres et sait instantanement : marque, format, prix, categorie, allergenes. Sans code-barres, la caisse doit deviner. Sans donnees structurees, Google et les IA doivent deviner ce qu'est votre page, a partir du texte visible et du contexte. Avec, ils lisent directement l'information qualifiee.
Ce vocabulaire compte plus de 800 types (Restaurant, Recipe, Event, Person, LocalBusiness...) et des milliers de proprietes associees. Pour un restaurant, une petite dizaine de types suffit a couvrir 95% des cas d'usage. Bonne nouvelle : la majorite de ces informations est deja demandee par votre fiche Google, et Google la traduit automatiquement en donnees structurees exploitables par son propre algorithme et par les IA qui s'appuient sur son ecosysteme.
Signal a garder en tete : sans donnees structurees, votre fiche et votre site sont un catalogue sans etiquettes. L'utilisateur voit les produits, mais les moteurs et les IA ne savent pas les ranger, les comparer, ni les recommander avec certitude. En 2026, c'est ce qui separe un restaurant "trouvable" d'un restaurant "recommandable".
Jusqu'aux annees 2022-2023, les donnees structurees etaient un levier SEO utile mais optionnel : elles donnaient acces a quelques rich results (etoiles d'avis dans les resultats, plage horaire, prix), et amelioraient marginalement la comprehension algorithmique. Depuis, plusieurs bascules simultanees ont change leur poids relatif.
Le Mode IA de Google, deploye en France courant 2026, s'appuie sur un faisceau de sources structurees (fiche Google, site web, plateformes d'avis, partenaires de reservation) pour repondre en une seule fois a des requetes complexes du type "meilleur restaurant italien ouvert dimanche soir pres de Bastille avec option vegetarienne". Pour repondre, l'IA doit croiser des informations tres precises : type de cuisine, horaires, quartier, presence d'options vegetariennes. Chacune est une propriete Schema.org.
Le commerce agentique, encore emergent en 2026, prolonge cette logique. Quand un utilisateur delegue a ChatGPT ou a Ask Maps la reservation d'une table, l'agent doit lire de facon fiable la carte, la disponibilite, le mode de reservation, la politique d'annulation. Les LLMs n'inventent pas ces informations, ils les extraient. Sans balisage clair, l'agent hesite, propose autre chose, ou echoue.
Enfin les AI Overviews et GEO (Generative Engine Optimization) recompensent tout ce qui simplifie la vie du modele. Les modeles type ChatGPT ou Gemini ont acces a un faisceau de sources structurees sans qu'on connaisse le poids exact accorde a chacune, mais un constat se stabilise : plus les informations sont balisees, moins le modele hesite, et plus il est susceptible de les inclure dans ses reponses. Google le documente d'ailleurs explicitement pour les Local Business, en detaillant les proprietes attendues pour maximiser la visibilite.
Formule autrement : ce qui etait un bonus jusqu'en 2023 est devenu une hygiene minimale en 2026. Pas parce que Google a change ses regles du jour au lendemain, mais parce que les moteurs et les IA se sont mis a exploiter en profondeur ce qui n'etait auparavant qu'un signal complementaire.
Il existe plus de 800 types dans le vocabulaire Schema.org. Pour un restaurant, cinq suffisent a couvrir la quasi-totalite des cas d'usage. Chacun a un role different, se place sur un support different (fiche Google, site web, ou les deux), et n'est pas pose par la meme personne.
👉 Restaurant. C'est le type coeur, une specialisation du type LocalBusiness qui decrit votre etablissement en tant que restaurant. Il porte le nom, l'adresse, les horaires, le type de cuisine servie, la gamme de prix, les moyens de contact. Support : site web principalement. Pose par : votre developpeur ou votre CMS si celui-ci le genere automatiquement.
👉 LocalBusiness. Le type parent qui ancre la nature "commerce local" de votre etablissement. Il porte les informations d'adresse, de zone de service, de coordonnees GPS, d'accessibilite. Sur un site de restaurant, LocalBusiness et Restaurant se combinent souvent. Support : site web. Pose par : votre developpeur ou votre CMS.
👉 MenuItem. Chaque plat de votre carte, structure : nom, description, prix, allergenes, regime alimentaire (vegetarien, vegan, sans gluten). Sur votre fiche Google, la section menu est deja structuree nativement des lors que vous remplissez les champs prevus. Sur votre site, il faut poser le balisage sur chaque plat de la carte. Support : site web et fiche Google. Pose par : vous sur la fiche (via l'interface Google Business Profile), un developpeur pour le site.
👉 Review et AggregateRating. Le balisage qui rend les avis lisibles par les moteurs et les IA : note globale, nombre total d'avis, avis unitaires avec date et texte. Sur votre fiche Google, ce balisage est genere automatiquement : Google structure lui-meme les avis qu'il collecte. Sur des plateformes tierces (agregateurs), ce balisage est pose par la plateforme. Support : fiche Google (natif) et site si vous integrez un widget d'avis. Pose par : Google en automatique, ou l'agregateur.
👉 Event et FAQPage. Deux types complementaires souvent negliges. Event permet de valoriser vos evenements ponctuels : brunch dominical, soiree a theme, concert. FAQPage structure les questions frequentes de vos clients (parking, allergenes, groupes acceptes). Support : site web principalement. Pose par : vous via le CMS si celui-ci le permet, sinon un developpeur.
Ce qui se degage de ce panorama : les deux types les plus "rentables" pour un restaurateur non-developpeur sont ceux poses via la fiche Google (Review, MenuItem, une partie de Restaurant). Le reste demande une intervention sur le site, souvent une ligne du budget "refonte" ou "SEO" qu'un developpeur pose en une fois. Le levier prioritaire est donc du cote de la fiche, la ou vous pouvez agir sans dependre de personne.
Voici la nouvelle qui merite d'etre repetee : votre fiche Google Business Profile est deja, en grande partie, une source de donnees structurees Schema.org, entierement geree par Google. Chaque champ que vous remplissez (nom, adresse, horaires, categorie principale, categories secondaires, attributs, menu, photos, questions/reponses) est traduit en propriete Schema par les systemes Google et rendu exploitable par ses propres algorithmes, par les AI Overviews et par les LLMs qui interrogent son ecosysteme.
Cela signifie deux choses. La premiere : vous n'avez pas a coder. Vous n'avez pas a comprendre le JSON-LD. Vous n'avez meme pas a savoir qu'il existe. Google fait le travail de traduction. La seconde : cela ne fonctionne que si vous remplissez rigoureusement chaque champ disponible. Une fiche a moitie complete, c'est un balisage a moitie exploitable, et donc un signal degrade pour les moteurs et les IA.
Les champs les plus souvent negliges sur les fiches restaurateur, selon les retours terrain :
👉 Categorie principale et categories secondaires. La categorie principale determine sur quelles requetes votre fiche est susceptible d'apparaitre. Les categories secondaires elargissent l'eventail sans diluer le signal principal.
👉 Attributs. Options de service, accessibilite, ambiance, options de repas, regimes alimentaires proposes. Ces attributs sont l'equivalent des proprietes Schema.org les plus fines, celles qui permettent aux IA de repondre aux requetes qualifiees.
👉 Menu structure. La section menu accepte des plats avec nom, description, prix, categorie. Une fois remplis, ces champs sont exploites nativement par la recherche Google et sont susceptibles d'etre reutilises par les IA lorsqu'elles decrivent votre carte.
👉 Questions et reponses. La section Q&R publique alimente naturellement une logique FAQPage, avec les benefices associes en visibilite.
👉 Zone de service et adresse precise. Une adresse coherente au format postal francais et une zone de service correcte donnent au signal LocalBusiness sa force geographique maximale.
C'est precisement ce travail de completude systematique, sur la fiche puis sur le site, que des plateformes comme Dokaa centralisent pour les restaurateurs qui n'ont pas envie de le gerer champ par champ, ni de dependre d'un developpeur pour chaque modification. Le principe est simple : traiter la fiche Google comme la premiere source de donnees structurees a exploiter, avant meme le site.
Si vous devez retenir une seule regle de tout cet article : remplissez tous les champs disponibles de votre fiche Google, sans exception, avec la meme rigueur que vous mettriez dans un balisage technique. Chaque champ vide est une propriete Schema.org manquante. Chaque champ rempli est un signal supplementaire adresse aux moteurs et aux IA de 2026.
Une fois le principe compris, reste la partie diagnostic. Voici la sequence en 4 etapes pour savoir ou vous en etes, sans avoir besoin de connaissances techniques particulieres.
👉 Etape 1 : ouvrir votre fiche Google et lister les champs vides ou incomplets. Passez en revue chaque section (informations, categories, attributs, menu, horaires, photos, questions). Comptez ce qui est vide, ce qui est partiellement rempli, ce qui merite un enrichissement (photos de moins de 60 jours, menu a jour, attributs coches). Chaque champ vide est une propriete Schema qui manque a l'appel.
👉 Etape 2 : tester votre site avec le Rich Results Test de Google. C'est l'outil officiel gratuit, disponible sur search.google.com/test/rich-results. Collez l'URL de la page d'accueil de votre restaurant : l'outil vous dira quels types de balisage sont detectes et lesquels manquent. C'est la reference pour discuter avec votre developpeur ou votre agence.
👉 Etape 3 : verifier la coherence entre la fiche et le site. Nom exact, adresse au meme format, telephone, horaires, categorie principale. Une incoherence entre les deux sources affaiblit la confiance des moteurs. Ce point de coherence est cle en 2026 pour toute la chaine de signaux de classement local.
👉 Etape 4 : documenter et repasser regulierement. La fiche Google bouge, les attributs s'enrichissent, votre carte evolue, vos horaires changent. Un rappel trimestriel dans votre calendrier suffit a maintenir l'ensemble a jour.
Pour les restaurateurs qui veulent gagner du temps sur ce diagnostic, Dokaa propose un audit gratuit de votre fiche Google qui identifie precisement les champs vides, les incoherences avec les autres sources en ligne, et les zones ou l'enrichissement aurait le plus fort impact sur votre visibilite. Aucun engagement, aucune installation, un rapport a plat qui sert de point de depart concret.
Le sujet parait complexe et il l'est, dans sa profondeur technique. Un developpeur qui pose du JSON-LD sur un site restaurant manipule un vocabulaire riche, des imbrications de types, des tests de validation. Cette partie merite d'etre confiee a un professionnel. C'est incontournable, et c'est bien.
La bonne nouvelle, c'est que 80% du benefice, pour un restaurant, se joue sur une brique que vous controlez sans developpeur : votre fiche Google Business Profile. Chaque champ rempli, chaque attribut coche, chaque plat structure dans le menu est une propriete Schema.org activee dans l'ecosysteme qui alimente Google, les AI Overviews et les LLMs de 2026. C'est une hygiene, plus qu'une technique.
C'est precisement ce travail de completude systematique et de coherence entre la fiche, le site et les autres sources en ligne que Dokaa centralise pour les restaurateurs. Si vous voulez voir ou vous en etes, l'audit gratuit dont on parlait plus haut est un bon point de depart. Aucun engagement, aucune installation, et vous repartez avec une photo concrete de ce qui merite d'etre corrige en priorite pour parler proprement aux moteurs et aux IA de 2026.