Schema Event : structurer vos pages d'événements

Le balisage Event est l'implémentation du type Event de schema.org, glissée en JSON-LD dans une page qui décrit un événement précis : un webinaire, une conférence, un concert, une session de formation. Il permet à un moteur de recherche, un assistant vocal ou un agrégateur d'extraire directement les faits essentiels — le nom, la date de début et de fin, le lieu, le prix, la disponibilité des places — sans avoir à deviner ces informations en lisant le texte de la page.

Ce n'est pas un détail cosmétique : c'est ce qui détermine si la page peut apparaître sous forme de résultat enrichi, et si tout ce qui la lit de manière automatisée comprend correctement de quoi il s'agit. La plupart des implémentations mises en ligne réussissent la partie facile — indiquer une date — et se trompent ensuite sur plusieurs points précis : le fuseau horaire, la distinction entre un lieu physique et une session en ligne, et surtout ce que devient la page une fois l'événement passé. C'est ce dernier point, en particulier, qui distingue une implémentation qui tient dans la durée d'une implémentation qui se dégrade en silence.

Ce que le balisage Event rend lisible

Sans balisage, un moteur qui veut savoir quand commence un atelier ou combien coûte une place doit interpréter une phrase rédigée pour un humain — l'atelier débute à 14h et coûte 90 euros — et cette interprétation reste fragile : formulation ambiguë, prix mentionné plusieurs fois sur la page, date écrite en toutes lettres. Le balisage Event transforme ces faits en données structurées directement rattachées à la page, sans passer par une lecture du texte courant.

Concrètement, les propriétés qui portent l'essentiel de cette information sont peu nombreuses, mais chacune a un rôle précis.

• name — l'intitulé exact de l'événement, pas un slogan
• startDate et endDate — le moment précis où il commence et se termine
• location — l'endroit, physique ou virtuel, où il se déroule
• offers — le prix, la devise et la disponibilité des places
• eventAttendanceMode — s'il se déroule en présentiel, en ligne ou dans les deux

À qui ce balisage s'adresse réellement

Ce balisage sert dès qu'une page décrit un événement daté auquel on peut assister ou s'inscrire : une salle qui publie sa programmation, un organisateur de conférence ou de salon professionnel, un centre de formation qui planifie des sessions, ou toute structure qui anime des webinaires ou des ateliers réguliers. Le point commun est toujours le même : la page correspond à une occurrence précise, avec une date, pas à un sujet général.

À l'inverse, un article de blog qui liste les événements à venir dans le secteur n'a pas vocation à porter ce balisage : il ne décrit pas un événement unique, il en évoque plusieurs. Réserver Event aux pages qui correspondent réellement à une occurrence datée évite de diluer le signal sur des pages qui n'en ont pas besoin.

Dates et fuseau horaire : la précision qui compte

startDate et endDate doivent être exprimés au format ISO 8601 avec un décalage horaire explicite, pas seulement une date et une heure locale. La différence semble mineure tant que le public reste local, mais elle cesse de l'être dès qu'un agrégateur, un assistant ou un visiteur situé dans un autre fuseau tente de calculer l'heure réelle de l'événement : sans le décalage, quatorze heures est une information incomplète, pas une donnée exploitable.

C'est précisément le point que la plupart des implémentations manquent en premier : on renseigne l'heure telle qu'elle apparaît sur l'invitation, sans jamais préciser par rapport à quel fuseau elle est exprimée. Le résultat fonctionne pour un public local et devient faux, ou simplement inutilisable, pour tout le reste.

Lieu physique, lieu virtuel : l'erreur la plus fréquente

Pour un événement en présentiel, location doit être un Place avec une adresse réelle — rue, ville, code postal. Pour un événement en ligne, schema.org prévoit un type distinct, VirtualLocation, qui porte une url : celle où l'on rejoint la session, pas une adresse postale. C'est précisément ce point que beaucoup de sites ratent.

Le cas typique : un webinaire ou une formation à distance conserve le balisage Place hérité des événements physiques de la même organisation, avec l'adresse du siège social en guise de lieu. Ce n'est pas une simplification sans conséquence, c'est une information fausse — personne ne se rend au siège pour suivre le webinaire. Un événement mixte, avec une partie du public sur place et une autre à distance, doit porter les deux types de lieu, et eventAttendanceMode doit refléter cette réalité, présentiel, en ligne, ou les deux.

Billetterie, disponibilité et statut de l'événement

La propriété offers porte le prix, la devise et la disponibilité — places disponibles, complet, liste d'attente — ainsi qu'une url vers la page d'inscription ou d'achat. Ces valeurs doivent rester synchronisées avec la réalité : un événement affiché complet sur la page alors que offers indique encore des places disponibles envoie une information contradictoire.

eventStatus complète ce tableau pour les cas où l'événement ne se déroule pas comme prévu initialement : programmé par défaut, mais aussi reporté, décalé à une nouvelle date, ou annulé. Un événement annulé qui conserve un statut programmé continue d'inciter à s'inscrire à quelque chose qui n'aura pas lieu ; un événement reporté doit indiquer à la fois l'ancienne date et la nouvelle, pas seulement écraser la première.

• EventScheduled — se déroule comme annoncé
• EventPostponed — reporté, nouvelle date pas encore fixée
• EventRescheduled — reporté à une date désormais connue
• EventCancelled — n'aura pas lieu

Événements récurrents : une URL par occurrence

Pour un cours hebdomadaire ou un webinaire qui revient chaque mois, la tentation est de garder une seule URL et de réécrire silencieusement la date à chaque nouvelle session. Cette approche pose un problème structurel : une page indexée garde en mémoire une version passée, un lien partagé sur un forum ou par e-mail continue de pointer vers une information qui n'est plus la bonne, et le balisage lui-même perd toute cohérence dans le temps puisqu'il ne décrit jamais qu'une seule occurrence à la fois, celle du moment où la page a été modifiée en dernier.

L'approche qui tient dans la durée donne à chaque occurrence sa propre URL et son propre balisage Event — la session du 14 octobre et celle du 21 octobre sont deux pages distinctes, chacune avec sa date exacte — éventuellement regroupées sous une page de série qui liste les prochaines occurrences sans porter elle-même une date unique.

Le vrai problème : que devient la page après l'événement ?

Une page d'événement est correcte pendant quelques semaines, puis fausse pour toujours si personne n'y retouche. C'est le point le plus souvent négligé de ce balisage, et le plus coûteux : une date qui a servi de repère pendant la préparation de l'événement continue d'exister sur le web bien après que l'événement a eu lieu, avec un eventStatus toujours à programmé et parfois même un bouton d'inscription encore actif pour une date passée.

La bonne pratique consiste à décider, avant même de publier la première occurrence, ce qui se passera après la date. Trois options existent, et chacune a du sens selon le cas :

• conserver la page comme archive, en modifiant clairement l'introduction et le balisage pour indiquer que l'événement a eu lieu, en retirant l'offre d'achat active
• rediriger la page vers la prochaine occurrence ou vers la page de série, si l'ancienne page n'a pas de raison d'exister seule une fois la date passée
• maintenir une page de série permanente, non rattachée à une date précise, qui pointe vers chaque occurrence individuelle et absorbe le trafic au fil du temps

Valider le balisage et le garder aligné avec la page visible

Un balisage Event se valide avant mise en ligne, avec un outil comme le test de résultats enrichis ou un validateur schema.org, pour vérifier que les propriétés obligatoires sont présentes et correctement typées. Mais la validation ponctuelle ne suffit pas : le vrai risque n'est pas une erreur de syntaxe, c'est un écart qui se creuse entre le contenu visible et le JSON-LD au fil des modifications — un prix changé dans le texte de la page mais pas dans offers, une date décalée dans le paragraphe d'introduction mais pas dans startDate.

Ce genre d'écart n'est pas anodin : un balisage qui contredit ce que voit un visiteur est traité comme trompeur, pas comme une simple imprécision technique. La discipline la plus utile ici n'est donc pas de valider une fois à la mise en ligne, mais de revalider chaque fois qu'un détail de l'événement change — date, prix, statut, lieu — et de vérifier périodiquement qu'aucune page ancienne ne porte encore un balisage qui ne correspond plus à sa réalité.

Les pages d'événements à date dépassée, encore indexées comme si l'événement restait à venir, constituent l'échec le plus courant sur ce type de balisage — bien plus fréquent qu'une simple erreur de syntaxe JSON-LD, et bien plus difficile à repérer, puisque la page continue de s'afficher normalement sans qu'aucune erreur ne remonte.