Faut-il vraiment imposer l'anglais dans les données structurées pour les jours de la semaine ?

Pourquoi cette exception au principe de cohérence texte-markup ?

Google rappelle une règle fondamentale : vos données structurées doivent refléter ce que voit l'utilisateur. Si votre page affiche "15 rue de la Paix", votre markup LocalBusiness doit contenir exactement cette adresse, pas une traduction ou une variante.

Mais les jours de la semaine font exception. Le champ day-of-week exige des valeurs en anglais selon schema.org — même si votre site français affiche "Ouvert du lundi au vendredi".

Quels champs sont concernés par cette règle ?

Concrètement, cette contrainte touche les propriétés OpeningHoursSpecification utilisées dans LocalBusiness, Organization, ou Place. Le champ dayOfWeek attend des valeurs normalisées : Monday, Tuesday, Wednesday, etc.

Un site e-commerce japonais affichant 月曜日 (lundi en japonais) devra quand même encoder "Monday" dans son markup. Cette normalisation permet à Google de traiter uniformément les horaires indépendamment de la langue du site.

Schema.org impose-t-il vraiment l'anglais partout ?

Non, et c'est là que ça devient intéressant. Schema.org utilise des énumérations strictes pour certains champs — les jours de la semaine, mais aussi les méthodes de paiement (PaymentMethod), les devises, les codes pays.

Pour ces valeurs énumérées, schema.org impose des identifiants standardisés en anglais. Pour tout le reste (noms, descriptions, adresses), vous utilisez votre langue naturelle.

• Principe général : les données structurées reflètent le contenu visible par l'utilisateur
• Exception : les champs day-of-week utilisent obligatoirement les noms anglais (Monday, Tuesday, etc.)
• Raison : schema.org définit ces valeurs comme une énumération standardisée
• Impact : aucune pénalité si vous affichez "lundi" aux utilisateurs mais encodez "Monday" dans le markup
• Champs similaires : PaymentMethod, Currency, Country suivent la même logique de normalisation

Cette exigence est-elle vraiment appliquée par Google ?

Oui, et c'est vérifiable dans Search Console. Les erreurs de validation remontent explicitement quand vous utilisez des jours traduits dans dayOfWeek. Google rejette "lundi" ou "Montag" — il attend strictement les valeurs anglaises.

Par contre — et c'est là que le bât blesse — aucune communication claire n'indique si cela impacte votre éligibilité aux rich snippets horaires. [A vérifier] sur un échantillon significatif de sites multilingues mal configurés : perdent-ils réellement leur affichage enrichi ?

Le principe de cohérence reste-t-il valable ailleurs ?

Absolument. Cette exception ne doit pas faire oublier la règle d'or : pour 99% de vos propriétés structurées, ce que vous marquez doit correspondre à ce que vous montrez.

Un LocalBusiness français qui affiche "Boulangerie Dupont" ne doit pas encoder "Dupont Bakery" sous prétexte de cibler un public anglophone. Google détecte ces incohérences et peut ignorer votre markup, voire appliquer une action manuelle pour spam structuré.

Que faire pour les langues s'écrivant avec des alphabets non-latins ?

Même combat. Un site russe, chinois ou arabe doit encoder "Monday" dans dayOfWeek, même si l'interface affiche понедельник, 星期一 ou الاثنين.

C'est contre-intuitif pour les développeurs qui localisent leurs applications, mais schema.org fonctionne comme un protocole de communication machine, pas comme une interface utilisateur. L'anglais sert de lingua franca pour les moteurs de recherche.

Comment encoder correctement les horaires d'ouverture ?

Utilisez la structure OpeningHoursSpecification avec dayOfWeek en anglais, même si votre contenu visible est traduit. Exemple pour un site français :

Votre page affiche : "Ouvert du lundi au vendredi, 9h-18h"
Votre markup encode : "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]

• Vérifier dans le code source que dayOfWeek contient bien Monday, Tuesday, etc. (jamais lundi, Montag, lunedì)
• Tester votre markup avec le validateur de données structurées de Google
• Contrôler dans Search Console (Améliorations > Entreprises locales) l'absence d'erreurs de validation
• Auditer les plugins et CMS : certains traduisent automatiquement ces valeurs (erreur fréquente)
• Appliquer la même logique pour PaymentMethod ("CreditCard" pas "Carte bancaire") et Currency ("EUR" pas "€")
• Documenter cette exception pour vos équipes dev et traduction — c'est contre-intuitif

Quels outils permettent de détecter ces erreurs ?

Le validateur de schéma de Google (Rich Results Test) signale explicitement les valeurs non conformes. Search Console remonte également ces erreurs dans la section dédiée aux entreprises locales.

Pour un audit global, des outils comme Schema Markup Validator ou Screaming Frog permettent de scanner l'ensemble de vos pages et identifier les incohérences entre langues. Privilégiez une vérification manuelle sur vos templates clés avant déploiement.

Faut-il corriger en urgence si vous utilisez des jours traduits ?

Ça dépend de votre dépendance aux rich snippets horaires. Si vous êtes un commerce local comptant sur l'affichage enrichi dans les SERP, corrigez rapidement. La perte de ces snippets impacte directement votre CTR.

Pour un site e-commerce B2B où les horaires sont secondaires, la priorité est moindre — mais planifiez quand même la correction. Google peut durcir sa position à tout moment.