Site internet pour restaurant : ce qui convertit vraiment en 2026

Un site de restaurant qui convertit tient sur trois actions visibles sans scroller : réserver une table, consulter la carte, appeler. Tout le reste, la présence sur les plateformes de livraison, les avis Google, le balisage schema.org, vient soutenir ces trois actions. Rien ne les remplace. J’ai vu trop de restaurateurs investir dans une galerie photo léchée ou une intégration Instagram avant même d’avoir un bouton de réservation qui fonctionne correctement sur mobile, alors que c’est l’inverse qui rapporte.

La France compte environ 102 000 entreprises de restauration traditionnelle recensées par l’INSEE sous le code NAF 56.10A, et une grande partie d’entre elles gèrent encore leur présence en ligne à coups de PDF scanné et de profil Instagram sans site propre. Dans ma pratique de développeur web freelance, je vois deux erreurs revenir sans arrêt chez les restaurateurs qui me contactent : sous-investir dans le site au profit des plateformes de livraison, ou sur-payer une solution de réservation sans jamais avoir calculé ce qu’elle coûte réellement sur un an. Voici comment je structure un site de restaurant, avec les chiffres qui doivent guider chaque décision.

Les trois actions qui doivent tenir sans scroller

Sur mobile, en 2026, un client qui cherche un restaurant tape rarement le nom exact. Il tape “restaurant italien Paris 11” ou “brasserie ouverte dimanche soir près de moi”, clique sur un résultat, et décide en moins de dix secondes s’il reste sur la page ou repart vers le résultat suivant. Ce que je place systématiquement au-dessus de la ligne de flottaison, dans cet ordre précis :

Un bouton de réservation qui ouvre un vrai calendrier de créneaux disponibles, pas un simple lien mailto: ou un numéro de téléphone planqué en bas de page. Le client veut voir tout de suite s’il y a une table à 20h ce soir, pas envoyer un message et attendre une réponse.

La carte, en texte lisible, pas en PDF scanné. Un PDF photographié au téléphone n’est ni indexable par Google, ni lisible sur un petit écran, ni accessible pour un lecteur d’écran. C’est l’erreur la plus fréquente que je corrige sur les sites de restaurant existants.

Un numéro de téléphone cliquable avec un lien tel: correctement implémenté, affiché dans l’en-tête sur chaque page, pas uniquement sur une page contact séparée. J’utilise exactement le même principe sur les sites de service d’urgence que j’ai livrés, comme urgenceserrures.fr ou plombiersidf.fr : un client pressé ne va pas chercher un numéro sur trois pages, il repart vers le résultat suivant.

TheFork ou un système de réservation propre : le calcul qui tranche

C’est la première décision économique à trancher, et elle se calcule, elle ne se devine pas. TheFork facture selon un modèle mixte : un abonnement mensuel (environ 29 euros par mois pour l’offre Visibilité, jusqu’à 139 euros pour l’offre Performance) plus une commission par couvert réservé via la plateforme, autour de 2,60 euros en moyenne en France selon les chiffres compilés par Brewbook, avec des variations entre 1 et 5 euros selon la négociation.

Un restaurant qui reçoit 300 réservations par mois via TheFork, avec un abonnement à 89 euros, paie environ 869 euros par mois rien qu’en frais de réservation, soit plus de 10 000 euros par an. En échange, il capte une audience qui ne le connaît pas encore et qui compare plusieurs établissements sur l’application.

Un système de réservation intégré au site (formulaire avec gestion de créneaux, ou widget tiers comme Zenchef facturé en abonnement fixe) coûte un développement one-shot puis, selon l’outil choisi, un abonnement mensuel sans commission par couvert. Il ne génère aucun trafic nouveau : il ne fait que convertir les visiteurs déjà arrivés sur le site, via Google, les réseaux sociaux ou le bouche-à-oreille.

Canal de réservation	Coût typique	Apporte du trafic nouveau
TheFork	~2,60 €/couvert + 29 à 139 €/mois d’abonnement	Oui
Widget de réservation propre au site	Développement one-shot + abonnement fixe sans commission	Non
Formulaire simple sur le site	Développement one-shot, zéro coût récurrent	Non

Le bon arbitrage dépend de votre taux de remplissage. Un restaurant qui affiche complet la plupart des soirs a intérêt à faire baisser la part TheFork au profit de son propre site, où chaque réservation ne coûte rien de plus. Un restaurant qui ouvre depuis moins d’un an, sans base de clients fidèles, a intérêt à garder TheFork le temps de construire sa notoriété locale.

Livraison : le piège des plateformes qui mangent la marge

Même logique côté livraison, avec des montants qui pèsent davantage. Prenons un exemple chiffré simple : un restaurant qui traite 150 commandes de livraison par mois, à un ticket moyen de 28 euros, génère 4 200 euros de chiffre d’affaires mensuel sur ce canal. Sur la formule standard Uber Eats, avec livraison assurée par la plateforme, la commission tourne autour de 30% HT selon les grilles tarifaires 2026 compilées par Fooderise, soit environ 1 260 euros prélevés chaque mois. Sur un an, cela représente plus de 15 000 euros qui ne reviennent jamais au restaurant, quel que soit le volume de travail en cuisine.

Les alternatives réduisent la ponction sans l’éliminer. En mode auto-livraison (le restaurant assure lui-même la livraison), Uber Eats descend autour de 15% HT. En click-and-collect pur, sans aucune livraison, la commission tombe à 12-15% chez Uber Eats et 14-18% chez Deliveroo. C’est précisément ce créneau, le click-and-collect, que je pousse à intégrer directement sur le site du restaurant, avec un simple formulaire de commande à récupérer sur place : zéro commission, et le client final paie directement l’établissement.

L’idée reçue à démonter ici, c’est qu’un restaurant doit être visible sur toutes les plateformes pour exister. C’est faux au-delà d’un certain seuil de notoriété. Une fois qu’un restaurant a construit une base de clients réguliers, chaque commande qui passe par une plateforme de livraison plutôt que par un appel direct ou le site du restaurant est une commande sur laquelle la marge a été rognée d’un tiers, pour un service que le client aurait souvent été prêt à obtenir directement.

La carte doit vivre sur le site, pas dans un PDF scanné

Une carte au format PDF non structuré pose trois problèmes concrets. Elle n’est pas indexable correctement par Google, donc elle ne fait remonter aucune requête de type “restaurant qui sert [plat] à [ville]”. Elle charge lentement sur mobile en 3G ou 4G dégradée, ce qui aggrave le Largest Contentful Paint au moment précis où le client compare plusieurs établissements. Et elle n’est jamais mise à jour, parce que rouvrir le fichier source pour changer un prix ou un plat du jour demande un outil que le restaurateur n’a souvent plus sous la main.

La solution que j’installe : une carte en HTML structuré, balisée avec schema.org/Menu et schema.org/MenuItem, que le restaurateur peut modifier lui-même via un CMS léger sans toucher au code. Le balisage Menu permet à Google d’afficher directement certains plats et prix dans les résultats de recherche, ce qui augmente la probabilité de clic avant même que le visiteur arrive sur le site. Pour un restaurant qui change sa carte chaque saison ou propose un menu du jour quotidien, un CMS headless léger justifie pleinement son coût, contrairement à un site vitrine classique qui publie un contenu par trimestre.

La fiche Google Business Profile et la performance : le duo qui capte la recherche near me

Google Business Profile permet désormais de connecter un système de réservation et un partenaire de commande directement au profil, pour que le client réserve ou commande sans jamais quitter la recherche Google. C’est un canal gratuit, à condition que les informations (horaires, menu, zone, lien de réservation) restent strictement synchronisées avec le site. J’ai vu des profils où l’adresse ou les horaires affichés divergeaient du site, ce qui brouille la confiance et fait perdre des réservations à des clients qui appellent en dehors des heures réelles d’ouverture.

Côté performance, les seuils Google Core Web Vitals restent identiques à ceux de tout site marketing : LCP sous 2,5 secondes, INP sous 200 millisecondes, CLS sous 0,1, mesurés au 75e percentile du trafic réel selon web.dev. Pour un restaurant, ce n’est pas un détail technique abstrait : un client qui cherche une table un vendredi soir, sur 4G, entre deux stations de métro, abandonne une page qui met plus de trois secondes à afficher la carte et le bouton de réservation. Sur les sites que je construis en Astro, ces seuils sont atteints par construction, sans plugin de cache à ajouter après coup.

Ce que la loi impose vraiment sur un site de restaurant

Les mentions légales sont obligatoires sur tout site professionnel accessible au public, en application de la loi LCEN du 21 juin 2004. Elles doivent identifier l’éditeur avec son SIRET, exactement comme je l’affiche moi-même en pied de page de mes propres livraisons (899 453 401 00015). Sur un site de restaurant qui prend des réservations en ligne, deux points juridiques s’ajoutent à cette base.

D’abord, le formulaire de réservation collecte des données personnelles (nom, téléphone, email, parfois allergies alimentaires) qui relèvent du RGPD, indépendamment de la question des cookies. La base légale est l’exécution du contrat de réservation, ce qui dispense d’un consentement séparé pour cet usage précis, mais impose une politique de confidentialité claire sur la durée de conservation et l’absence de partage à des tiers non nécessaires.

Ensuite, côté cookies, la doctrine de la CNIL exempte de bandeau les outils de mesure d’audience qui remplissent quatre conditions cumulatives : finalité strictement statistique, pas de recoupement avec d’autres traitements, aucune transmission à des tiers, aucun suivi cross-site. Plausible ou Matomo bien configurés permettent donc de se passer de bandeau cookies sur la partie navigation du site, ce qui réduit la friction au moment précis où le client s’apprête à cliquer sur “réserver”.

Ce qu’il faut retenir

Un site de restaurant qui convertit en 2026 repose sur trois actions visibles sans scroller (réserver, voir la carte, appeler), une carte en HTML structuré plutôt qu’en PDF scanné, et un arbitrage chiffré entre présence sur les plateformes (TheFork, Uber Eats, Deliveroo) et canaux directs sans commission. La commission moyenne sur une commande livrée tourne autour de 30% chez Uber Eats et Deliveroo en formule complète : chaque commande poussée vers le site ou l’appel direct plutôt que vers la plateforme est une commande où le restaurant garde l’intégralité de sa marge. Le design vient après ces fondations, jamais avant.

Ce qu’il faut retenir

• Placez réservation, carte et téléphone cliquable au-dessus de la ligne de flottaison, sur mobile comme sur desktop
• Remplacez toute carte en PDF scanné par du HTML structuré balisé schema.org/Menu, indexable par Google et modifiable sans développeur
• TheFork coûte environ 2,60 euros par couvert plus un abonnement mensuel : rentable pour capter une audience nouvelle, coûteux une fois la clientèle fidélisée
• La commission livraison tourne autour de 30% HT en formule complète chez Uber Eats et Deliveroo, contre 12 à 18% en click-and-collect pur
• Synchronisez en permanence horaires, adresse et menu entre le site et la fiche Google Business Profile pour ne pas perdre de réservations
• Les Core Web Vitals (LCP < 2,5 s, INP < 200 ms, CLS < 0,1) pèsent directement sur le taux d’abandon d’un client qui cherche une table en mobilité
• Le formulaire de réservation relève du RGPD par l’exécution du contrat, indépendamment de l’exemption CNIL sur les cookies de mesure d’audience