Menu PDF ou menu numérique : un PDF derrière un QR code reste un PDF

Le scan fonctionne. La carte, non.

Un client s'assoit, lève son téléphone, le pointe vers le petit carré noir et blanc collé sur la table, et l'appareil photo fait son travail. Le scan n'est presque jamais le problème. Ce qui arrive ensuite l'est souvent, car derrière un très grand nombre de menus QR code en Europe se cache un menu PDF : un fichier d'impression précédé d'une adresse web.

Ce que l'autocollant sur la table promet vraiment

L'autocollant promet une carte numérique. Quelque chose d'à jour, lisible sur l'appareil que le client tient déjà, et modifiable par l'établissement le jour même. Un QR code dynamique peut tenir cette promesse, puisqu'il pointe vers une adresse que l'exploitant contrôle encore ; un code statique, avec l'emplacement du fichier gravé dedans, ne le peut pas. Ajoutez par-dessus un ou deux raccourcisseurs de liens et le client traverse une chaîne de redirections avant qu'un seul mot de la carte ne s'affiche.

Ce que le client reçoit réellement

Ce qui s'affiche est un document conçu pour le papier : un fichier en mise en page d'impression qui ne se recompose pas, si bien que le client finit par faire le travail de mise en page au bout des doigts. Il est catalogué avec les documents bureautiques, parce que c'est exactement ce qu'il est.

L'autocollant sur la table promet une carte numérique. Le PDF qui se cache derrière livre un fichier d'impression précédé d'une adresse web — terminé, figé, et composé pour un format de page que personne ne tient en main.

Trois choses qu'un fichier ne fera jamais et qu'une page fait d'emblée

Un fichier ne change plus après publication ; quelqu'un doit exporter et téléverser un remplaçant. Il ne s'adapte pas au lecteur, qu'il s'agisse d'un texte plus grand, d'un lecteur d'écran ou d'une deuxième langue. Et il n'apprend rien à l'établissement sur ce qui a été ouvert. Une page fait les trois sans qu'on le lui demande. Cette césure — fichier statique contre page web vivante — traverse la vitesse, la mise en page, l'accessibilité, la langue, les allergènes et le travail quotidien qui consiste à tenir la carte à jour.

Un fichier et une page, côte à côte

Retirez l'habillage de marque et l'argument se réduit à un fait structurel : un fichier statique contre une page web vivante. Un menu PDF était terminé à l'instant où il a été exporté. Une page de menu HTML responsive est assemblée à chaque ouverture, à partir de données que l'établissement contrôle encore.

Ce entre quoi vous choisissez réellement

Ce que chaque format peut faire pour le client

L'écart s'ouvre au premier geste et ne se referme jamais vraiment : une page responsive se recompose à la largeur qu'on lui donne, un fichier non. La langue fonctionne de la même façon. Une page de menu multilingue peut basculer à la demande ; un menu PDF exige un fichier distinct, et un QR code distinct, pour chaque langue que l'établissement veut servir.

Ce que chaque format peut faire pour l'exploitant

Ici, la différence se mesure en temps. Une mise à jour de prix en temps réel sur une page est une modification de champ qui atteint le scan suivant. Le même changement dans un PDF suppose de réexporter, de téléverser à nouveau et d'espérer que rien n'a bougé dans la mise en page. L'enjeu est plus lourd pour les allergènes, car le droit européen de l'information alimentaire fait peser l'obligation de déclaration sur l'exploitant et non sur le document. Une déclaration d'allergènes tenue sous forme de données structurées voyage avec le plat. Dans un PDF, c'est une ligne de texte qu'il faut penser à modifier. Une page renvoie aussi de l'information — vues de plats, sessions, répartition des langues —, là où un fichier ne renvoie rien.

Là où les deux se recoupent, et là où ils divergent

Les deux formats se scannent, et les deux survivent à une connexion faible. Le recoupement s'arrête au moment où la carte doit changer.

Vitesse : ce qui se joue dans les cinq premières secondes à table

Un client scanne, jette un œil à l'écran, et soit il commence à lire, soit il pose le téléphone face contre table et attend un serveur. C'est dans cette courte fenêtre qu'un menu PDF et une page de menu HTML responsive cessent de se comporter comme deux versions de la même chose. L'un doit arriver en entier avant de montrer quoi que ce soit ; l'autre peut afficher les premières entrées pendant que le reste voyage encore.

Les seuils publiés par Google, et pourquoi ils décrivent votre salle

La documentation Core Web Vitals de Google considère le Largest Contentful Paint (LCP) comme bon lorsqu'il survient dans les 2,5 secondes suivant le début du chargement de la page, mesuré au 75e centile des chargements. La même documentation fixe l'Interaction to Next Paint (INP) à 200 millisecondes ou moins et le Cumulative Layout Shift (CLS) à 0,1 ou moins, toujours au 75e centile. Google précise aussi que ces métriques sont mesurées séparément pour mobile et ordinateur : une carte ouverte presque exclusivement sur téléphone est donc jugée sur ses données de terrain mobiles, et non sur la vivacité avec laquelle elle s'ouvre sur le portable du bureau.

Ces chiffres ont été écrits pour la recherche, mais ils se lisent comme des seuils de service. Deux secondes et demie, c'est à peu près la patience de quelqu'un qui tient un téléphone à table pendant qu'un serveur approche.

Pourquoi un fichier prêt à imprimer est lourd par construction

Un PDF de carte prêt à imprimer embarque des polices et des images en résolution d'impression, parce que c'est ce dont un imprimeur a besoin. À côté d'une page web qui charge d'abord le texte et fait venir les images progressivement, il est lourd par construction. Rien n'est cassé : le fichier fait simplement le travail pour lequel il a été conçu, sur un appareil pour lequel il ne l'a pas été. Sur le Wi-Fi saturé d'un établissement, le poids du fichier se transforme directement en temps de chargement en données mobiles, et ce retard tombe sur le premier plat lisible.

La chaîne de redirections que personne n'a imprimée sur l'autocollant

L'autocollant porte une seule URL, mais le téléphone emprunte souvent un chemin plus long. Scénario typique : le code imprimé pointe vers un raccourcisseur de liens, qui redirige vers un dossier de stockage cloud, qui redirige encore vers une visionneuse. Chaque saut coûte une résolution et un aller-retour. Les chaînes de redirections et les raccourcisseurs de liens sont invisibles sur le chevalet de table, et ils sont entièrement imputés à l'UX mobile de la carte.

UX mobile : le client ne devrait pas avoir à faire la mise en page

Une carte se lit dans les quelques minutes qui séparent l'installation de la commande, sur un téléphone tenu d'une main, souvent à une table où trois autres personnes discutent. Tout ce qui touche à l'UX mobile d'une carte découle de ce contexte, et non de l'allure du document sur l'écran d'un graphiste.

Des proportions A4 sur un écran de cinq pouces

Les recommandations de Google sur l'ergonomie mobile publiées sur web.dev énoncent le mécanisme sans détour : un PDF en mise en page d'impression ne recompose pas son texte, donc une mise en page conçue pour une feuille A4 conserve des proportions A4 sur un écran de cinq pouces. Le recomposition du texte sur petits écrans est précisément ce qu'un navigateur fait d'une page de menu HTML responsive, en recoupant les lignes à la largeur de l'appareil. Un PDF transmet ce travail au client, qui l'exécute au pincement : agrandir, lire deux ou trois plats, faire glisser latéralement pour atteindre la colonne des prix, dézoomer pour retrouver la catégorie suivante. Le client compose en réalité la page à la main, une fois par service.

Chercher, filtrer, sauter : la navigation qu'un fichier ne peut pas offrir

Une page peut être interrogée ; un fichier ne peut qu'être fait défiler. Des ancres de catégories, un champ de recherche, un filtre qui réduit une longue liste à ce que quelqu'un peut réellement manger ce soir — ce sont des composants ordinaires d'une page web, impossibles dans un export à plat. La même structure porte plus loin : des titres sémantiques donnent à un lecteur d'écran quelque chose à parcourir plutôt qu'un bloc indifférencié, et une page peut déclarer son sens de lecture par langue. Un PDF conserve ce que le graphiste a exporté, y compris les erreurs.

Lumière tamisée, une seule main, une table pleine

Peu de lumière, un téléphone à mi-luminosité, une table de quatre : dans ce scénario typique, la différence entre une page et un fichier se mesure au nombre de gestes qui séparent un client d'un prix. Il y a une deuxième raison de s'en soucier. Avec l'indexation mobile-first, la vue téléphone est aussi celle que voit la recherche.

L'accessibilité est devenue une surface juridique, pas un supplément d'âme

Pendant des années, une carte difficile à lire relevait du défaut de service. Dans l'UE, elle est aussi devenue une question de conformité, et la réponse dépend moins du QR code que de ce qui se trouve derrière.

Ce que couvre l'Acte européen sur l'accessibilité, et depuis quand

La directive (UE) 2019/882, connue sous le nom d'Acte européen sur l'accessibilité, s'applique depuis le 28 juin 2025 aux produits et services couverts mis sur le marché de l'UE, selon le texte publié sur EUR-Lex. L'étalon technique est la norme EN 301 549, la norme européenne harmonisée qui reprend les critères de succès WCAG 2.1 niveau AA pour les contenus et services numériques. Le public concerné n'a rien de marginal : Eurostat indique qu'en 2024, 23,9 % des personnes de 16 ans et plus dans l'UE présentaient un handicap (limitation d'activité) — soit, d'après les chiffres de population d'Eurostat, environ 90 millions de personnes.

Pourquoi un PDF non balisé échoue face à un lecteur d'écran

Un menu PDF exporté depuis un fichier de création est, structurellement, un ensemble d'instructions de tracé. Tant que personne ne l'a balisé, il n'y a ni hiérarchie de titres, ni sémantique de liste, ni ordre de lecture fiable : un lecteur d'écran peut donc annoncer deux colonnes entrelacées, énoncer des prix détachés des plats auxquels ils appartiennent, ou ne rien trouver du tout si la page a été aplatie en image. Une page de menu HTML responsive est bâtie à partir des éléments que les technologies d'assistance attendent — c'est pourquoi lecteurs d'écran et titres sémantiques figurent ensemble dans toutes les grilles d'audit.

Agrandissement du texte, contraste et zones tactiles sur une vraie page

Un fichier à mise en page fixe se redimensionne en bloc : agrandissez les caractères et les lignes débordent de l'écran, imposant un défilement horizontal. Une page, elle, se recompose. Les règles de contraste et de taille des zones tactiles sont en outre testables sur une page et pratiquement incorrigibles dans un document exporté sans rouvrir la création d'origine.

Qui est exempté, et pourquoi l'exemption est plus étroite qu'il n'y paraît

Le texte exempte les microentreprises — moins de 10 salariés et un chiffre d'affaires annuel ou un total de bilan n'excédant pas 2 millions d'EUR — de ses obligations en matière de services. Un café indépendant isolé entre souvent dans cette case. Un petit groupe, une activité de restauration hôtelière (F&B) ou un établissement intégré à une société plus grande, en général non — et l'exemption porte sur l'obligation juridique, pas sur le client qui ne peut pas lire la carte.

Langues : une page, de nombreux clients

L'Europe a enregistré 747 millions d'arrivées de touristes internationaux en 2024, selon le Baromètre du tourisme mondial d'UN Tourism — 1 % au-dessus des niveaux de 2019 et 5 % au-dessus de 2023 — et Eurostat a compté cette année-là plus de 3 milliards de nuitées dans les hébergements touristiques de l'UE, une première, en hausse de 2,7 % sur 2023. Près d'une gare, d'une plage ou d'une cathédrale, le client de la table six lit souvent la carte dans une langue que la cuisine ne parle pas.

Pourquoi quatre fichiers PDF font quatre problèmes de maintenance

Une carte multilingue bâtie sur des PDF, ce sont quatre documents, quatre cycles d'export et le plus souvent quatre QR codes sur la table. Changez un prix et la modification doit être faite quatre fois, dans quatre mises en page. Oubliez-en une — scénario typique — et la version allemande affiche discrètement le prix d'un plat que la version italienne ne vend plus. Sur une page de menu HTML responsive, la langue est un sélecteur au-dessus d'un seul jeu de données : une modification se propage partout.

Garder le nom du plat, expliquer le plat

L'enquête « Can't Read, Won't Buy » de CSA Research, menée auprès de 8 709 consommateurs dans 29 pays, a montré que 76 % des acheteurs en ligne préfèrent acheter des produits dont l'information est dans leur propre langue et que 40 % n'achèteront jamais sur un site rédigé dans une autre langue ; chez les répondants sans compétence en anglais, ce chiffre monte à 89 %. La règle n'est pas de tout traduire. Gardez le nom propre du plat — c'est ce que le client commande et ce que le serveur entend — et traduisez la description en dessous.

Ce que la traduction automatique peut toucher, et ce qu'elle ne doit pas toucher

La traduction automatique relue par un humain est raisonnable pour les descriptions et les intitulés de rubriques. Elle n'est pas adaptée aux allergènes, où un mot erroné relève de la sécurité et non du style. Les écritures de droite à gauche et le texte bidirectionnel — une version arabe à côté de chiffres latins — forment une mise en page qu'un PDF figé ne sait pas recomposer ; un menu QR code rendu sous forme de page peut définir le sens de lecture par langue et laisser les prix tranquilles.

Allergènes : le champ qui ne doit jamais être périmé

De tout ce qui figure sur une carte, la ligne des allergènes est le seul endroit où un fichier périmé cesse d'être un simple désagrément. Un prix affiché un euro trop bas coûte un euro à la maison. Une déclaration d'allergènes qui décrit la recette du mois dernier peut envoyer un client à l'hôpital.

Ce que le règlement (UE) n° 1169/2011 exige d'un restaurant

Le règlement (UE) n° 1169/2011 est applicable depuis le 13 décembre 2014 et, comme l'expose la Commission européenne dans sa législation sur l'information des consommateurs sur les denrées alimentaires, il oblige les exploitants du secteur alimentaire à déclarer 14 allergènes déterminés dans chaque plat, y compris pour les denrées non préemballées servies dans les restaurants, cafés et cantines. L'obligation ne s'arrête pas là. Pour les denrées non préemballées, le règlement et les lignes directrices des autorités nationales compétentes qui s'y appuient exigent que l'information sur les allergènes soit fournie par écrit au point de présentation : sur la carte, sur un tableau ou sur un document d'accompagnement. Une indication orale du serveur ne suffit pas.

Un PDF peut porter cette forme écrite. Ce qu'il ne peut pas faire, c'est garantir que la forme écrite entre les mains du client est bien la version en vigueur.

Les allergènes comme données structurées, pas comme note de bas de page

Dans un PDF, les allergènes survivent le plus souvent sous forme d'une rangée de pictogrammes ou d'une légende numérotée en pied de page, dans un corps assez petit pour que l'information soit techniquement présente et pratiquement inutilisable — et invisible pour un lecteur d'écran. Sur une page de menu HTML responsive, chaque plat est un enregistrement, et les allergènes qui s'y rattachent sont un champ de cet enregistrement. Un champ peut être filtré, lu à voix haute, traduit avec le reste de la page et corrigé à un seul endroit.

Pourquoi le changement de recette et le changement de carte doivent être le même geste

Les cuisines changent de fournisseur en milieu de semaine. Scénario typique : la vinaigrette habituelle est indisponible, le produit de remplacement contient de la moutarde, et le plat est servi pendant trois jours avant que quelqu'un ne réexporte le fichier. Sur une page, la modification qui produit une mise à jour de prix en temps réel réécrit aussi le champ des allergènes. Un geste, un enregistrement, en ligne dès le scan suivant. L'écart se creuse dès que la déclaration d'allergènes est traitée comme un document à rééditer plutôt que comme des données à modifier.

La journée de l'exploitant : un prix qui change, un plat épuisé, une nouvelle saison

Une carte n'est pas un document qu'on termine une fois pour toutes. Les fournisseurs augmentent leurs prix, des plats s'épuisent en plein service, et la carte doit tourner quand la saison tourne. La question n'est pas de savoir si la carte change, mais quelle part de la soirée de l'exploitant chaque changement consomme.

La boucle PDF : graphiste, export, téléversement, revérifier chaque lien

Modifier un menu PDF suppose le plus souvent de revenir au fichier de mise en page d'origine, qui se trouve souvent chez le graphiste qui l'a construit. Quelqu'un ajuste le chiffre, réexporte, vérifie que rien n'a bougé, téléverse le nouveau fichier, puis contrôle que chaque QR code sur chaque table, ainsi que le lien sur la page de réservation et dans la fiche de l'agrégateur, pointe désormais vers la nouvelle version et non vers l'ancienne. Cette chaîne doit être reparcourue pour un seul prix corrigé.

La boucle page : un champ, un enregistrement

Un menu numérique inverse la séquence. Une mise à jour de prix en temps réel, c'est un champ modifié sur un téléphone puis enregistré ; le client suivant qui scanne voit le nouveau chiffre. Marquer un plat épuisé — ce que la cuisine appelle « 86 » — est une bascule qui grise le plat pour le reste du service et le rétablit le lendemain. La gestion saisonnière de la carte devient affaire de publication d'éléments préparés, et non de réédition de maquettes.

Le coût caché de la version que personne n'a remplacée

L'échec coûteux, c'est rarement la modification elle-même. C'est la copie qu'on n'a jamais échangée : l'ancien fichier encore en cache sur un téléphone, le lien dans un annuaire qui n'appartient à personne, l'encart imprimé posé au bar. Avec un fichier, l'exactitude dépend de la traque de chaque copie. Avec une page, il n'y a qu'une seule copie à corriger.

Ce que la carte vous dit, et ce qu'elle dit à Google

Un menu PDF est un objet clos. Il est récupéré, ouvert à table, puis ne dit plus rien à la cuisine. Une page de menu HTML responsive laisse une trace : quel plat a été ouvert, dans quelle langue, quel soir. Selon le rapport State of the Restaurant Industry 2021 de la National Restaurant Association, 50 % des exploitants de restaurants avec service à table déclaraient avoir ajouté un accès numérique à la carte par QR code depuis mars 2020 : beaucoup d'établissements font donc déjà scanner sans rien en recueillir.

Des vues par plat, pas des téléchargements par fichier

Un hébergement de fichiers statiques peut indiquer combien de fois un document a été demandé. C'est un chiffre unique, et il couvre toute la carte d'un coup : les entrées que personne ne lit et le plat dont le chef est le plus fier y sont indiscernables. Les statistiques de carte sur un menu numérique travaillent au niveau de l'article — vues de plats, sessions par service, ordre d'ouverture des catégories. Dans un scénario typique, un plat à forte marge se trouve bas sur une longue page et est rarement ouvert ; le correctif est un changement de position, pas une nouvelle recette. Avec un menu PDF, ce motif est invisible, car le fichier ne révèle rien de ce qui s'est passé une fois ouvert.

La répartition des langues comme signal de planning

Le choix de langue est une donnée d'exploitation avant d'être une donnée marketing. Si une large part des sessions d'un mois bascule vers une seule langue, c'est un argument sur qui devrait être en salle ce mois-là, sur les brochures de fournisseurs qu'il vaut la peine de traduire et sur le menu qui mérite une deuxième version. Un menu QR code qui enregistre la répartition des langues transforme une intuition sur la salle en quelque chose sur quoi bâtir un planning.

Lire les données sans enfreindre les règles de confidentialité

Les données utiles d'une carte sont agrégées et maigres : des compteurs de vues d'articles, de sessions, de langues. Elles n'exigent ni noms, ni comptes, ni suivi intersites, ce qui les tient loin des obligations les plus lourdes du droit européen de la protection des données. Les exploitants doivent malgré tout vérifier ce que leur plateforme dépose dans le navigateur, et si un consentement est requis avant l'exécution de statistiques non essentielles.

Indexé ne veut pas dire utile

Google Search Central recense l'Adobe Portable Document Format (.pdf) parmi les types de fichiers encodés indexables, aux côtés des documents Word, Excel et PowerPoint. Un menu PDF peut donc être indexé. Mais la même documentation n'offre aucune recommandation sur l'ergonomie mobile, les données structurées ou les résultats enrichis pour les PDF ; elle les traite comme de simples documents binaires.

Ce que voit un robot mobile-first

Avec l'indexation mobile-first, Google utilise la version mobile du contenu d'un site, explorée avec l'agent smartphone, pour l'indexation et le classement. Une page conçue pour être lue sur téléphone est évaluée selon ses propres termes. Un document conçu pour le A4, non.

Données structurées, versions linguistiques et liens internes

Une page de carte HTML peut porter un balisage menu et restaurant, déclarer ses versions linguistiques et renvoyer vers les pages de réservation, d'adresse et de contact. Un PDF ne porte rien de tout cela, et ne mène nulle part.

Les deux objections honnêtes : signal faible, et l'imprimé dont vous avez encore besoin

Pourquoi la table du sous-sol est le vrai test

Deux objections au remplacement d'un menu PDF par une page hébergée méritent une réponse franche. La première tient à la connectivité. Un fichier, une fois téléchargé, reste sur le téléphone ; une page, selon le récit habituel, a besoin du réseau à chaque fois. L'endroit où trancher n'est pas la terrasse avec quatre barres de réseau, mais la salle en sous-sol aux murs épais, la table de cour à la limite de portée du routeur, ou une salle comble un samedi où tout le monde partage un seul point d'accès.

Mise en cache, images légères et un repli imprimé

L'objection est réelle, mais elle vaut aussi pour le fichier : le poids en résolution d'impression décrit plus haut est précisément ce qu'une connexion saturée gère le plus mal, et un téléchargement qui doit arriver en entier ne peut pas montrer le premier plat tôt. Une page légère peut atteindre l'objectif LCP sur une connexion ordinaire ; un fichier lourd, généralement non. La mise en cache hors ligne de la carte, un poids d'images contenu et quelques cartes plastifiées derrière le bar comblent ce qui reste d'écart.

Une seule source de vérité, plusieurs rendus

La seconde objection, c'est l'imprimé, et elle cesse d'en être une dès que l'architecture est juste. Le même enregistrement qui alimente le menu QR code peut produire un export PDF prêt à imprimer en sortie : prix identiques, allergènes identiques, même plat de saison, composé pour le A4 plutôt que pour l'UX mobile. Ce qui échoue, c'est la disposition inverse, dans laquelle le document est la référence et le menu numérique une copie qui vieillit en silence entre deux retirages.

Banquets, cartes des vins et dépôts sur les agrégateurs

Beaucoup de supports doivent encore exister sur papier ou sous forme de fichier. Une proposition de banquet part par e-mail chez un client entreprise. Une longue carte des vins est plus agréable à tenir qu'à faire défiler. Un agrégateur voudra peut-être la carte en dépôt dans un format figé. Il faut bien quelque chose en vitrine pour les passants. Rien de tout cela ne plaide pour abandonner la page ; cela plaide pour produire chaque support à partir des mêmes données.

Quand un PDF reste la réponse honnête

Un petit établissement à la carte courte qui change rarement, à la gestion des allergènes simple et à la clientèle largement locale n'est pas mal servi par un document. Le propos ici concerne les établissements dont la carte bouge.

Migrer sans réimprimer un seul QR code

La plupart des exploitants supposent qu'abandonner un PDF signifie de nouveaux chevalets, de nouveaux autocollants, de nouveaux adhésifs de vitrine. Le plus souvent, non. Tout dépend de ce que le motif imprimé encode réellement.

Posséder le domaine vers lequel le code pointe

Un QR code statique stocke la destination à l'intérieur du motif : changer où il mène impose de réimprimer. Un QR code dynamique stocke une adresse courte qui se résout vers ce que le propriétaire définit ensuite, et c'est là tout le poids pratique de la distinction QR code dynamique contre QR code statique. Idéalement, cette adresse courte se trouve sur un domaine que l'établissement contrôle. Le raccourcisseur d'un tiers ajoute les sauts décrits plus haut, et laisse l'établissement incapable de réparer un lien cassé si le prestataire disparaît.

Une check-list de deux semaines pour un petit établissement

À titre d'exemple, un bistrot de trente couverts consacre la première semaine à construire et relire la page, et la seconde à rediriger, à tester en salle chaque menu QR code imprimé et à former l'équipe avant de retirer l'ancien fichier.

Questions fréquentes