Fraîcheur : dater, réviser, prouver. Ce que les moteurs et les IA attendent d'un contenu à jour

Un lecteur qui pose une question à un assistant en 2026 veut une réponse valable en 2026. Les moteurs, classiques comme génératifs, le savent et tiennent compte de la date d'un contenu, en particulier sur les sujets où les faits changent : réglementation, prix, versions, chiffres de marché. Beaucoup d'éditeurs en ont tiré une mauvaise habitude, celle de changer la date d'un article sans en changer une ligne. Cette pratique est repérable et contre-productive. Voici ce que les moteurs lisent réellement, comment ils le vérifient, et comment un média qui publie beaucoup organise ses mises à jour.

Ce que Google lit, et où

Google documente, dans sa page sur les données structurées Article, deux propriétés issues de schema.org : datePublished et dateModified. La seconde doit indiquer la date de la dernière modification substantielle du contenu, et Google demande, dans ses consignes sur les dates, qu'elle corresponde à la date visible sur la page. Le sitemap transporte un troisième signal, lastmod, que Google utilise pour décider ce qu'il recharge en priorité, à condition qu'il soit fiable, comme l'explique la page sur la construction d'un sitemap.

Le point important est la cohérence. Google compare ce que disent les données structurées, la date affichée, le lastmod du sitemap et, s'ils existent, les en-têtes HTTP de dernière modification. Quand ces sources se contredisent, il cesse de leur faire confiance et se rabat sur sa propre observation : a-t-il vu le contenu changer entre deux passages ? Un site dont le sitemap annonce tous les jours une modification de toutes les pages, sans qu'aucune ne change, apprend à Google que son lastmod ne veut rien dire. Nous avons documenté ce cas dans « Un sitemap avec des dates identiques ne sert à rien ».

Ce que les moteurs génératifs font des dates

Un moteur génératif qui répond avec des sources cherche des passages pertinents, puis les pondère. Sur une question dont la réponse dépend du temps, il privilégie des passages datés récemment, et il lit la date là où elle est disponible : dans les données structurées, dans le texte, dans l'URL parfois. Google indique dans sa page sur les fonctionnalités d'IA dans la recherche que ses réponses générées s'appuient sur les mêmes signaux que la recherche classique, sans balisage particulier ; la fraîcheur en fait partie.

Il y a une conséquence que les éditeurs sous-estiment : un moteur génératif cite volontiers le passage qui contient lui-même sa date. « Depuis le 2 août 2026, l'article 50 s'applique » est un passage datable et citable. « Récemment, la réglementation a changé » ne l'est pas, et il vieillit mal. Écrire les dates dans le texte, en toutes lettres, est une pratique de fraîcheur autant qu'une pratique de citabilité, dans la logique que nous décrivions dans « Réponse d'abord, nuance ensuite ».

Pourquoi le faux signal coûte plus qu'il ne rapporte

Redater un article sans le modifier produit trois effets, tous négatifs.

1. La perte de confiance dans les signaux. Le moteur observe que la date change et que le contenu ne change pas. Le risque est qu'il apprenne que les dates de ce site sont du bruit et cesse d'en tenir compte, y compris pour les vraies mises à jour. Aucun moteur ne documente ce comportement : c'est une déduction, pas une mesure. Les deux effets se suivent d'ailleurs dans le temps plutôt qu'ils ne coexistent. Le moteur recharge d'abord sur la foi des dates annoncées, et c'est le constat répété d'un contenu inchangé qui le conduit ensuite à s'en défier.
2. Le gaspillage du budget de crawl. Chaque page annoncée modifiée est rechargée. Sur un média de cinq cents articles, annoncer chaque jour cinq cents modifications fictives, c'est demander cinq cents rechargements pour rien, au détriment des pages réellement nouvelles.
3. Le risque de contradiction. Un article « mis à jour en septembre 2026 » qui cite un tarif de 2024 ou une version logicielle abandonnée est immédiatement décrédibilisé par un lecteur attentif, et un moteur génératif peut afficher la date qu'il trouve dans le passage qu'il cite.

La documentation des évaluateurs de qualité de Google consacre plusieurs pages à la notion de contenu à jour, et distingue explicitement les sujets où la date compte de ceux où elle ne compte pas. Un guide sur la pose d'une toiture n'a pas besoin d'être réécrit chaque mois ; une page sur les aides à la rénovation, si.

À quoi ressemble une vraie révision

Une révision qui justifie une nouvelle date de modification change quelque chose qu'un lecteur pourrait remarquer : un chiffre remplacé par un chiffre plus récent, une section ajoutée sur un fait nouveau, une recommandation retirée parce qu'elle ne tient plus, une source remplacée par une source à jour. Corriger une coquille, changer une image ou reformuler un titre n'est pas une révision, et ne doit pas modifier dateModified.

La règle est simple à tenir sur dix articles et impossible à tenir de mémoire sur cinq cents. C'est là que l'organisation compte.

Organiser la révision à l'échelle

Un média qui publie plusieurs contenus par semaine accumule en un an quelques centaines d'articles dont une partie contient des faits périssables. Leur révision reste tenable sans mobiliser une équipe à plein temps, à condition de l'outiller.

Le référentiel. Si les faits, les chiffres et les positions viennent d'une base de référence commune plutôt que de chaque article, mettre à jour un fait dans la base permet de retrouver tous les articles qui l'utilisent. Un tarif change : on sait quels articles le citent. Une échéance réglementaire est repoussée : on sait quels articles l'annonçaient. Sans référentiel, cette recherche se fait à la main, et elle ne se fait pas.

Le marquage des faits périssables. À la rédaction, chaque affirmation datée ou chiffrée est identifiée comme telle, avec sa source et sa date de validité présumée. Une revue mensuelle liste les affirmations dont la validité est dépassée, et l'éditeur décide, pour chacune, de la vérifier, de la corriger ou de la retirer. C'est un travail de quelques heures par mois, et il porte sur les passages que les moteurs relisent le plus.

La mesure. Les logs disent quelles pages les robots relisent après une modification, et la Search Console dit lesquelles perdent des impressions. Une page qui décroche sur une requête dont la réponse a changé est une candidate à la révision avant même que le référentiel ne la signale. Nous avons décrit cette lecture dans « Lire un access log en 30 minutes ».

Signaler la modification, sans en abuser

Une fois la révision faite, il reste à la faire connaître. Trois canaux, à utiliser ensemble et seulement pour les vraies révisions : la mise à jour de dateModified dans les données structurées et de la date visible sur la page ; la mise à jour du lastmod de cette URL, et de celle-là seulement, dans le sitemap ; et, pour les moteurs qui le prennent en charge, un signalement direct via IndexNow, qui prévient Bing et les moteurs partenaires qu'une URL a changé, sans attendre leur prochain passage.

Le serveur ajoute un dernier signal, souvent oublié : les en-têtes Last-Modified et ETag, et le respect des requêtes conditionnelles. Un robot qui demande « cette page a-t-elle changé depuis ma dernière visite ? » et reçoit une réponse honnête, oui ou non, cesse de recharger à l'aveugle, et concentre ses passages sur ce qui bouge réellement.

La fraîcheur est un actif, pas un réglage

Un média dont les dates sont fiables est un média que les moteurs relisent quand il le demande, et qu'ils citent avec la bonne date. Un média qui redate tout ne gagne rien à court terme et perd, à moyen terme, la seule chose qui compte : la confiance des moteurs dans ses signaux. La différence entre les deux se joue dans l'organisation, un référentiel commun, une revue régulière des faits périssables, une mesure de ce que les robots relisent. C'est une des raisons pour lesquelles nous pensons qu'un média d'entreprise se construit sur une base de référence avant de se construire sur des articles.