Freshness Stamp : Règles relatives aux dates de publication et de mise à jour

Une estampille de fraîcheur indique aux lecteurs quand une page a été rendue publique pour la première fois, quand ses informations de référence ont changé pour la dernière fois et, le cas échéant, ce qui a été vérifié. C’est un élément d’ouverture car le temps peut modifier l’interprétation de chaque affirmation qui la suit.

Mis à jour le 27 août 2026 · Publié le 14 mars 2025 · Tarifs et disponibilité des fonctionnalités vérifiés

Ce spécimen rendu présente trois affirmations distinctes. « Publié » préserve l’origine, « Mis à jour » enregistre un changement substantiel, et la phrase de portée indique ce que la révision a couvert. La date est un signal de provenance, pas une décoration ni un raccourci pour donner l’impression qu’un contenu ancien est nouveau.

Pourquoi cet élément est important

Les lecteurs utilisent les dates pour estimer le risque. L’explication d’un concept mathématique vieille de trois ans peut être parfaitement fiable, tandis qu’une comparaison de prix de logiciels vieille de trois mois peut déjà être erronée. Une estampille visible aide un lecteur à décider s’il doit faire confiance à la page, vérifier une affirmation volatile ou chercher une source plus récente. Afficher les deux dates protège également l’historique : le lecteur peut voir qu’une ressource mature a été maintenue plutôt que présentée faussement comme nouvellement publiée.

La psychologie échoue lorsque l’étiquette exagère. « Mis à jour aujourd’hui » sous-entend que quelqu’un a modifié des informations sur lesquelles un lecteur se base. Si la seule action a été de changer la date, de corriger la ponctuation ou de déplacer la page dans un nouveau modèle, l’étiquette fabrique une confiance sans la mériter. Modifier une date de mise à jour sans toucher substantiellement au contenu est une violation de politique, même si un système de gestion de contenu rend cette édition facile.

L’extractibilité machine signifie que les logiciels peuvent identifier l’heure de publication, l’heure de modification, le champ d’application de la révision et la relation entre eux sans deviner à partir du texte. Des champs stables peuvent alimenter des modèles de page, des flux, des audits et des données structurées. Un robot d’exploration peut distinguer datePublished de dateModified ; un outil de surveillance éditoriale peut identifier les pages volatiles dont la fenêtre de révision a expiré. Une phrase vague comme « récemment actualisé » ne fournit ni un horodatage utilisable ni une affirmation vérifiable.

L’élément typé a préséance sur une date tapée dans une prose ordinaire. Suivez les règles d’écriture des éléments : le composant doit lire les champs de date canoniques et les restituer de manière cohérente. Les auteurs ne doivent pas taper manuellement une deuxième date qui pourrait dériver par rapport aux métadonnées.

Quand l’utiliser

Utilisez une estampille de fraîcheur lorsque l’âge modifie matériellement la sécurité, l’exactitude ou l’utilité de la page. Les déclencheurs courants sont les prix, les fonctionnalités des produits, la disponibilité, les lois, les normes, les statistiques, les recommandations classées, les instructions de compatibilité, les règles d’éligibilité, les calendriers et les personnes nommées. Ces faits se dégradent car le monde change même lorsque le texte ne change pas.

Utilisez-la sur une ressource vivante lorsque l’éditeur s’engage à revoir des affirmations définies. Une comparaison de logiciels pourrait indiquer « Forfaits et limites de fonctionnalités vérifiés » ; une documentation pourrait indiquer « Vérifié pour la version 6.8 » ; un explicatif réglementaire pourrait nommer la juridiction et la règle en vigueur. La portée empêche qu’une vérification récente d’un tableau n’implique que chaque phrase, lien et conclusion a reçu un examen équivalent.

Un contenu evergreen peut ne pas nécessiter d’estampille de fraîcheur visible. Une définition stable, un compte rendu historique, une étude de cas fixe, une note de version ou un rapport de recherche lié à un ensemble de données fermé n’ont souvent besoin que d’une date de publication honnête. Ajoutez des notes de correction ou un journal de mise à jour séparé lorsque l’interprétation change, mais ne créez pas un théâtre de maintenance dans lequel un enregistrement immuable reçoit une nouvelle date chaque trimestre.

Les erreurs à éviter incluent :

• Dates automatiques du jour : afficher la date du jour à chaque requête n’indique aucune activité de révision et est toujours interdit.
• Une année dans le titre : « Meilleurs outils 2026 » est une affirmation sur la couverture actuelle, pas une preuve que la page a été vérifiée en 2026.
• Un horodatage de build : reconstruire le site modifie les fichiers, pas le fond éditorial.
• Un badge de révision sans portée ni responsable : il crée une autorité sans acte vérifiable.
• Un flux de produits modifié : les mises à jour automatisées des prix peuvent mettre à jour un champ spécifique, mais elles ne justifient pas de marquer l’analyse éditoriale environnante comme mise à jour, sauf si la conclusion a été revérifiée.

Où le placer

Placez l’estampille dans la ligne de métadonnées du hero : sous le H1 et la description d’une ligne, et avant l’introduction ou le premier élément de réponse directe. Le lecteur doit recevoir le contexte temporel avant de rencontrer des affirmations qui peuvent se dégrader. Sur une page longue, l’estampille peut également apparaître à côté d’un tableau volatile ou d’un bloc de preuves lorsque ce bloc a sa propre date de vérification plus spécifique.

Gardez l’identité de l’auteur et du réviseur dans la même zone de provenance lorsque le modèle le permet, mais préservez un ordre de lecture clair : auteur, dates de publication/mise à jour, puis champ d’application de la révision. L’estampille peut se trouver à côté d’une estimation du temps de lecture car les deux sont des métadonnées neutres. Elle ne doit pas se trouver à côté d’un badge promotionnel, d’un compte à rebours de réduction, d’une étiquette « tendance » ou d’une évaluation par étoiles ; ces signaux peuvent faire ressembler une date éditoriale à une urgence ou à une approbation.

Ne placez pas l’estampille à l’intérieur de l’introduction, après la première affirmation volatile, uniquement dans le pied de page ou à l’intérieur d’une image. Ne répétez pas des dates contradictoires dans le hero, la barre latérale et le tableau. Si une section a son propre millésime de données, étiquetez cette valeur « Données jusqu’en juin 2026 » ou « Prix vérifiés le 27 août 2026 » plutôt que de modifier la date de mise à jour au niveau de la page.

Anatomie

1. Étiquette principale : « Mis à jour » lorsqu’une modification valide existe ; sinon « Publié ». Elle doit être un texte visible, pas une icône ou une infobulle.
2. Date principale : Une date calendaire lisible par l’humain dérivée des métadonnées canoniques.
3. Publication originale : Conservée lorsque l’étiquette principale est « Mis à jour » et que la provenance bénéficie de l’affichage des deux.
4. Champ d’application de la révision : Texte court facultatif nommant les faits, la version, la juridiction ou l’ensemble de données réellement vérifiés.
5. Horodatage machine : Une valeur ISO 8601 complète dans l’attribut HTML datetime, incluant le fuseau horaire lorsque l’heure est stockée.
6. Relation documentaire : L’élément appartient au hero de la page ; une date de preuve plus spécifique appartient à côté de la preuve qu’elle qualifie.

La couleur, l’icône, l’espacement et les séparateurs appartiennent au moteur de rendu. La séquence sémantique doit toujours se lire correctement lorsque le CSS est indisponible.

Exemples de conception

Les variantes prises en charge reflètent différents états éditoriaux, pas des préférences esthétiques.

Publication uniquement : À utiliser pour une nouvelle page ou une page stable n’ayant jamais reçu de révision substantielle. C’est le comportement par défaut.

Publication et mise à jour : À utiliser après une révision substantielle. « Mis à jour » précède car c’est la date pertinente pour la décision ; la publication reste disponible comme historique.

Vérification avec portée : Ajoutez une portée courte lorsque seules des affirmations volatiles définies ont été revérifiées ou lorsque la page est liée à une version. La portée ne doit pas sous-entendre un audit plus large.

Révisé sans changement : À utiliser uniquement lorsqu’une véritable révision a conclu que la page était toujours exacte. Enregistrez reviewedAt séparément ; ne modifiez pas dateModified et n’étiquetez pas l’événement « Mis à jour ».

Vue étroite : Autorisez le retour à la ligne naturel entre les éléments complets. Ne tronquez jamais une date et ne cachez pas « Publié » tout en laissant un nombre non étiqueté.

Paramètres

Les champs de date sont des attributs de métadonnées, pas du texte rédigé. Cela évite qu’une étiquette visible ne soit en désaccord avec les flux ou le schéma. La spécification du frontmatter reste faisant autorité pour les valeurs au niveau du document.

L’élément n’a pas de corps et pas de correspondance avec un premier titre. Un corps permettrait aux auteurs de dupliquer les métadonnées canoniques. La portée est délibérément un attribut car elle est courte, stable et lisible par machine.

Syntaxe et exemples de code

Tous les adaptateurs lisent les mêmes valeurs de publication, de modification et de portée. Ils peuvent formater les dates selon la locale, mais ils ne doivent pas en changer le sens.

Directive Markdown portable

:::freshness-stamp{published="2025-03-14T09:00:00+01:00" updated="2026-08-27T10:00:00+02:00" scope="Pricing and feature availability verified"}
:::

Contrat de shortcode Hugo

{{< freshness-stamp published="2025-03-14T09:00:00+01:00" updated="2026-08-27T10:00:00+02:00" scope="Pricing and feature availability verified" >}}

Dans Hugo, l’adaptateur de production préféré devrait lire .Date et le paramètre updated approuvé depuis les métadonnées de la page afin que les auteurs n’aient pas à les répéter. Les valeurs explicites ci-dessus documentent le mappage de champ portable ; elles ne sont pas une permission de coder en dur une deuxième source de vérité.

Bloc WordPress

<!-- wp:amicited/freshness-stamp {"published":"2025-03-14T09:00:00+01:00","updated":"2026-08-27T10:00:00+02:00","scope":"Pricing and feature availability verified"} /-->

Un adaptateur WordPress devrait définir published et updated par défaut à partir de l’enregistrement de l’article, exposer la portée comme champ éditorial et empêcher qu’un flux de travail de mise à jour uniquement de la date ne présente silencieusement une révision qui n’a pas eu lieu.

Exemples

Mis à jour le 27 août 2026 · Publié le 14 mars 2025
Tarifs, limites de forfaits et disponibilité des fonctionnalités vérifiés par rapport aux pages des fournisseurs.

Cet exemple est bon car les étiquettes préservent les deux événements, la portée nomme les faits volatiles et l’affirmation peut être vérifiée par rapport à l’historique d’édition et de sources de la page. Un réviseur sait ce que « mis à jour » signifie ici.

Fraîchement mis à jour aujourd’hui !
Publié originalement récemment.

Cet exemple est mauvais car « aujourd’hui » se déplace sans événement éditorial, « fraîchement » est promotionnel, « récemment » efface l’historique, et aucune des deux lignes n’expose un horodatage lisible par machine. Si la page a seulement été reformatée, même remplacer ces phrases par des dates exactes resterait trompeur. La bonne action est de conserver la date de publication originale et d’omettre une date de mise à jour.

Balisage structuré et accessibilité

L’estampille peut alimenter datePublished et dateModified sur un Article, TechArticle, NewsArticle englobant, ou un autre type de page véridique. datePublished provient de l’enregistrement de publication original. dateModified provient uniquement du dernier changement substantiel du contenu. Une révision enregistrée séparément qui ne change rien ne doit pas écraser dateModified ; le balisage structuré ne doit pas transformer un événement de révision en une fausse modification.

N’inventez pas un type Schema.org FreshnessStamp. Le champ d’application de la révision reste généralement du texte visible et des métadonnées d’audit internes. Si une page cite des faits volatiles, conservez leurs preuves dans un bloc de sources plutôt que de suggérer qu’une date récente les prouve.

Rendez chaque date avec un élément sémantique <time datetime="…">. La forme visible suit la locale de la page ; la valeur datetime préserve un horodatage machine non ambigu. Les étiquettes doivent être du texte. Ne comptez pas sur une icône d’horloge, une couleur verte, une infobulle ou un libellé relatif comme « il y a deux mois ». Les séparateurs marqués comme décoratifs doivent être ignorés par les technologies d’assistance, et le retour à la ligne doit préserver un ordre de lecture logique.

L’estampille est une métadonnée statique, elle n’a donc besoin d’aucune région live ARIA, de rôle de bouton, de cible de focus ou d’annonce. Si un journal des mises à jour est lié, utilisez un libellé descriptif comme « Voir ce qui a changé », pas « Plus ».

Règles d’écriture

Rédigez les étiquettes comme une provenance factuelle : « Publié », « Mis à jour » ou « Révisé ». Utilisez une date localisée absolue, pas « aujourd’hui », « récemment », « nouveau » ou « frais ». Limitez la portée à 3–12 mots et nommez l’objet vérifié : « Prix des forfaits et limites vérifiés » est plus fort que « Contenu révisé ». N’ajoutez pas de points d’exclamation, d’urgence, d’affirmations SEO ou de promesses que la page est totalement exacte.

Un changement substantiel réinitialise updated uniquement lorsqu’il améliore les informations sur lesquelles un lecteur se base. Les déclencheurs légitimes incluent la correction d’un fait matériel, le remplacement de prix ou spécifications obsolètes, la révision d’instructions après un changement de produit, l’ajout de preuves significatives, le changement d’une recommandation après une réévaluation, l’expansion suffisante de la portée pour modifier la réponse, ou l’achèvement d’une révision documentée entraînant des changements de contenu significatifs.

Les éléments suivants ne la réinitialisent pas : corrections de fautes de frappe, ponctuation, formatage, compression d’images, changements CSS ou de modèle, balises d’analyse, suivi de liens, modifications uniquement métadonnées, builds automatisés, changements de catégorie, formatage du profil d’auteur, ou le simple fait de vérifier la page sans trouver de changement nécessaire. Un remplacement de lien brisé ne réinitialise la date que lorsque la destination change les preuves ou les conseils ; remplacer une URL fonctionnelle équivalente ne le fait pas.

Ne placez jamais une affirmation telle que « Google récompense le contenu frais », un message promotionnel, une date d’expiration de réduction, un temps de lecture, une biographie d’auteur, une liste de sources, un journal des changements ou une méthodologie de révision complète à l’intérieur de l’estampille. Ceux-ci ont des objectifs différents. Ne datez jamais une mise à jour dans le passé, n’écrasez pas la date de publication, ne dérivez pas l’heure de modification du dépôt et ne planifiez pas une date de mise à jour future.

Types de publications qui l’utilisent

Le frontmatter postTypes est la source de ce mappage. L’inclusion signifie que le format présente un risque récurrent de dégradation ; cela ne signifie pas que chaque instance doit afficher une date de mise à jour.

Les définitions de glossaire stables, les enregistrements historiques, les recherches sur des ensembles de données fermés et les notes de version conservent généralement les dates de publication sans revendiquer une fraîcheur continue. Leur période de validité des preuves ou leur version de publication fait plus de travail d’interprétation qu’une étiquette « mis à jour » glissante.

Checklist de contrôle qualité

• La date de publication originale est préservée et précède ou est égale à tout événement ultérieur.
• updated correspond à un changement substantiel visible dans le contenu ou les preuves documentées.
• Une révision sans changement de contenu utilise reviewedAt, pas updated ou dateModified.
• La date visible, la valeur du frontmatter, la valeur du flux et la valeur des données structurées concordent.
• La portée nomme exactement ce qui a été vérifié et n’implique pas un audit complet de la page lorsqu’un seul bloc a changé.
• L’estampille apparaît dans le hero avant les affirmations volatiles, avec des dates plus spécifiques à côté des preuves plus spécifiques.
• Les dates absolues et les étiquettes de texte visibles restent compréhensibles sans couleur, icônes, CSS ou texte environnant.
• Chaque horodatage machine utilise une syntaxe ISO 8601 valide et le fuseau horaire correct.
• Aucune heure de build, heure de modification de fichier, jeton d’année en cours ou date mobile automatique n’alimente l’élément.
• L’historique des modifications peut expliquer pourquoi la date a changé ; une modification uniquement de la date échoue à la révision.
• Les événements de publication, de mise à jour et de révision restent distincts dans le texte visible et le balisage structuré.
• Le type de publication et le risque de dégradation de la page justifient l’affichage de l’élément.

FAQ

Chaque article doit-il afficher une date de dernière mise à jour ?

Non. N’affichez une date de mise à jour qu’après un changement substantiel. Une page evergreen stable peut afficher uniquement sa date de publication, tandis qu’une page en dégradation devrait exposer la date et le champ d’application de sa dernière révision valide.

La correction d’une faute de frappe justifie-t-elle de modifier la date de mise à jour ?

Non. Les corrections typographiques, de formatage, de suivi, de modèle et les modifications uniquement métadonnées ne changent pas les informations sur lesquelles un lecteur se base, donc elles ne réinitialisent pas la date de mise à jour.

Une page peut-elle afficher une date de révision alors qu’aucun changement n’était nécessaire ?

Oui, si une personne qualifiée a véritablement vérifié le champ d’application défini et que l’étiquette indique « Révisé », pas « Mis à jour ». Conservez les dates de publication et de modification inchangées, et enregistrez la révision séparément.

La date de publication doit-elle disparaître après une mise à jour ?

En général non. Conservez la date de publication originale dans les métadonnées et affichez-la à côté de la date de mise à jour lorsque la provenance est importante. La date de mise à jour ne doit jamais réécrire l’historique de la page.

Une estampille de fraîcheur améliore-t-elle le classement à elle seule ?

Non. Une étiquette de date n’est pas une preuve que la page est exacte. Sa valeur provient d’une maintenance honnête, de métadonnées cohérentes et d’un contenu qui reflète réellement la révision indiquée.