Journal des mises à jour : montrer ce qui a changé et quand

Un journal des mises à jour est un enregistrement daté des modifications substantielles d’une page : ce qui a changé, pourquoi, et si la réponse, la recommandation ou les preuves ont évolué.

Journal des mises à jour

27 août 2026 — Tarification et recommandation mises à jour
Remplacement du forfait Starter abandonné par le forfait Essentials actuel, mise à jour du tableau comparatif et modification de la recommandation pour les équipes ayant besoin d’exports d’audit. Les sources ont été revérifiées par rapport à la documentation des forfaits du fournisseur.

12 mai 2026 — Preuves actualisées ; conclusion inchangée
Remplacement de deux références de fonctionnalités obsolètes et vérification des limites des forfaits restants. L’option recommandée n’a pas changé.

Chaque date est liée à un événement vérifiable. Un simple « Mis à jour le 27 août 2026 » reste inexpliqué ; le journal expose la portée et la conséquence du travail.

Pourquoi cet élément est important

Les lecteurs ne traitent pas tous les changements de la même manière. Corriger un titre mal orthographié n’équivaut pas à inverser une recommandation, remplacer un jeu de données ou corriger une instruction dangereuse. Une seule date de mise à jour réduit ces événements au même signal. Sur les pages utilisées pour dépenser de l’argent, suivre une procédure, interpréter une recherche ou comprendre une politique, les lecteurs ont besoin de savoir si la section de référence a changé.

Un journal des mises à jour préserve l’historique sans obliger les lecteurs à comparer des copies mises en cache. Il répond à quatre questions : La page a-t-elle été maintenue ? Le changement m’a-t-il affecté ? Une erreur a-t-elle été corrigée ouvertement ? La conclusion est-elle toujours étayée ? Des réponses claires créent une responsabilité et empêchent une fraîcheur trompeuse issue d’une date avancée sans travail significatif.

Rapportez la conséquence, pas l’activité. « Liens mis à jour » décrit une action. « Remplacement de la source retirée pour le total du marché 2024 ; la valeur et la conclusion sont inchangées » indique aux lecteurs ce qui reste fiable. Si une conclusion a changé, dites-le clairement.

L’extractabilité machine signifie que le logiciel peut séparer chaque événement en une date, un type, un résumé, un détail, une section affectée et une référence de preuve. Des champs stables permettent aux audits de trouver les corrections, aux agents d’expliquer les recommandations modifiées et aux migrations de préserver l’historique. Une prose incohérente force le logiciel à deviner où les événements commencent et se terminent.

La finalité typée de l’élément prime donc sur une frise chronologique ou une liste à puces visuellement similaire. Suivez les règles d’écriture des éléments : lorsque le contenu enregistre les révisions de la page actuelle, encodez-le comme un journal des mises à jour. Le moteur de rendu peut utiliser une liste, des cartes ou une archive extensible, mais les champs canoniques des événements doivent survivre à chaque présentation.

Quand l’utiliser

Utilisez un journal des mises à jour lorsque les lecteurs peuvent avoir besoin de comparer la page actuelle et antérieure. Les déclencheurs incluent une recommandation modifiée, un fait corrigé, une méthode révisée, un jeu de données remplacé, un calcul modifié, une nouvelle version, une éligibilité changée, un modèle de prix mis à jour, des instructions modifiées ou une option archivée.

L’élément est le plus précieux lorsque l’autorité s’accumule au fil du temps. Une recherche peut recevoir un dénominateur corrigé ; une documentation peut prendre en charge une nouvelle interface ; un explicatif réglementaire peut distinguer un amendement d’une clarification éditoriale. Une réécriture silencieuse détruirait l’historique dont un lecteur de retour a besoin.

Utilisez une entrée de révision avec parcimonie lorsqu’une révision cadrée n’a trouvé aucun changement. Étiquetez-la « Révisé », nommez ce qui a été vérifié et dites que la conclusion est inchangée. Cela convient aux statistiques volatiles, aux prix, aux capacités des produits ou aux règles ; ce n’est pas une permission de fabriquer de l’activité.

Les cas limites nécessitent un traitement différent :

• Une date de publication ou de modification : utilisez une mention de fraîcheur pour exposer les dates canoniques de la page. La mention et le journal peuvent fonctionner ensemble, mais l’un ne peut pas remplacer l’autre.
• L’historique des versions d’un produit ou une chronologie de projet : ceux-ci décrivent les changements dans le sujet. Un journal des mises à jour enregistre les modifications éditoriales de la page actuelle.
• Le résultat du contrôle de version : les messages de commit incluent du bruit d’implémentation, des identifiants internes et des détails sensibles à la sécurité. Ce ne sont pas des enregistrements éditoriaux destinés aux lecteurs.
• Une liste de sources : un bloc de sources prouve d’où proviennent les affirmations. Le journal des mises à jour indique quand et pourquoi ces sources ou affirmations ont changé.
• Maintenance mineure : ne consignez pas l’orthographe, la ponctuation, le formatage, la compression d’images, les analyses, les paramètres de suivi ou une migration de modèle, sauf si le changement a altéré le sens ou l’accessibilité.

Une page sans révision substantielle nécessite une date de publication, pas un panneau vide ou un historique fictif.

Où le placer

Placez le journal complet après la réponse, les preuves, les conclusions et les sources, mais avant le contenu connexe, la capture de la newsletter ou l’appel à l’action de clôture. Les lecteurs ont d’abord besoin de la page actuelle, puis de son historique. Sur les pages de recherche, de statistiques et de politique, le journal suit généralement les sources ou la méthodologie.

Si le dernier changement affecte la façon dont la page doit être lue, ajoutez « Voir ce qui a changé » à côté de la date principale et créez un lien vers le journal complet. Ne dupliquez pas l’entrée à cet endroit. Une correction affectant la sécurité, l’argent, l’éligibilité ou la conclusion nécessite également un avis près de l’affirmation corrigée.

Le journal peut partager une zone de maintenance avec la paternité lorsque les deux restent distincts. Il ne peut pas être placé à côté d’un bouton d’achat, d’une offre à durée limitée, d’un compte à rebours, d’une évaluation, d’un témoignage ou d’un badge promotionnel ; cela transformerait l’historique en urgence ou en approbation implicite. Ne le fusionnez pas dans le bloc de sources : la raison pour laquelle une source a changé est un historique éditorial, pas une citation.

Conservez un seul journal canonique. Une barre latérale peut y renvoyer, pas le dupliquer. Après cinq entrées, affichez les trois à cinq plus récentes et exposez le reste via « Voir les mises à jour antérieures ». Conservez l’historique complet sur la page ou dans une archive stable et gouvernée.

Anatomie

1. Titre de l’élément : Utilise « Journal des mises à jour », « Historique des révisions » ou un libellé approuvé plus restreint qui reste clair en dehors du design de la page.
2. Date de l’événement : Affiche une date calendaire absolue et expose la même valeur qu’un horodatage machine ISO 8601.
3. Type d’événement : Distingue updated (mis à jour), corrected (corrigé), reviewed (révisé), method-changed (méthode modifiée) et archived (archivé) sans recourir à la couleur.
4. Résumé : Nomme l’objet modifié et le résultat en une ligne concise.
5. Détail : Explique l’ancien état, le nouvel état et la raison lorsque ces faits aident le lecteur à interpréter la page.
6. Section affectée : Renvoie éventuellement à l’en-tête ou à la figure stable modifiée, en utilisant un fragment qui ne sera pas réaffecté.
7. Conséquence : Indique si la réponse, la conclusion, la recommandation, l’éligibilité ou les instructions ont changé.
8. Référence de preuve : Pointe éventuellement vers un identifiant de source déjà défini dans le bloc de sources de la page.
9. Contrôle d’archive : Révèle les entrées antérieures sans les supprimer du document ou de l’arbre d’accessibilité.

Les entrées doivent rester compréhensibles sans mise en forme. Les icônes, lignes et couleurs ne portent jamais le type ou la conséquence à elles seules.

Exemples de conception

Les variantes reflètent la densité d’information et le risque éditorial.

Ligne compacte du dernier changement

Utilisez une ligne compacte pour une révision simple unique. Incluez la date, le type, le résumé et la conséquence. Utilisez la liste standard lorsque l’explication dépasse deux phrases.

Liste de révisions standard

Utilisez une liste des plus récentes en premier pour deux à cinq entrées, avec le même ordre des champs tout au long.

Variante axée sur les corrections

Pour une erreur matérielle, étiquetez « Correction », montrez les états incorrect et corrigé, indiquez l’impact et créez un lien vers la section affectée. Mettez l’accent sans langage alarmiste.

Changement de méthode ou de version

Lorsqu’un jeu de données, une formule, une version de produit, une juridiction ou une méthode change, montrez les anciennes et nouvelles versions. Indiquez quand les résultats antérieurs ne sont plus comparables.

Archive extensible

Après cinq entrées, étiquetez l’archive avec son nombre d’entrées et sa plage de dates. Préservez les en-têtes et la structure de la liste ; ne faites pas de JavaScript le seul moyen d’accéder à l’enregistrement.

Fenêtre étroite

Empilez la date, le type, le résumé et le détail. Ne tronquez jamais les dates et ne cachez pas le texte de conséquence sur mobile.

Paramètres

Les champs parents contrôlent la collection ; les champs d’éléments répétés décrivent chaque événement.

Les entrées sont des éléments répétés, pas un champ HTML unique. Le premier en-tête du parent correspond à title ; le premier en-tête de chaque élément correspond à summary et le corps restant correspond à detail. Les dates, types, impacts, références et versions restent des attributs.

impact est requis pour que les lecteurs n’aient pas à déduire si la réponse a bougé. Utilisez not-applicable uniquement lorsque le matériel n’a pas de conclusion. Une révision sans modification utilise type=reviewed et impact=unchanged.

Syntaxe et exemples de code

Toutes les représentations préservent les mêmes champs. Les identifiants de source font référence au bloc de sources canonique.

Directive Markdown portable

:::update-log{order=newest-first visibleItems=3}
## Journal des mises à jour

::item{date="2026-08-27" type=updated impact=changed affectedSection="plans" evidenceRef="vendor-plans"}
### Tarification et recommandation mises à jour

Remplacement du forfait Starter abandonné par Essentials et mise à jour du comparatif. Les équipes ayant besoin d'exports d'audit reçoivent désormais une recommandation différente.
::

:::

Contrat de shortcode Hugo

{{< update-log title="Journal des mises à jour" order="newest-first" visibleItems="3" >}}
  {{< update-log-item date="2026-08-27" type="updated" impact="changed" affectedSection="plans" evidenceRef="vendor-plans" >}}
  ## Tarification et recommandation mises à jour
  Remplacement du forfait Starter abandonné par Essentials et mise à jour du comparatif. Les équipes ayant besoin d'exports d'audit reçoivent désormais une recommandation différente.
  {{< /update-log-item >}}
{{< /update-log >}}

Il s’agit d’un contrat d’adaptateur, pas d’un shortcode existant. Chaque paramètre est nommé.

Blocs WordPress

<!-- wp:amicited/update-log {"title":"Journal des mises à jour","order":"newest-first","visibleItems":3} -->
<!-- wp:amicited/update-log-item {"date":"2026-08-27","type":"updated","impact":"changed","affectedSection":"plans","evidenceRef":["vendor-plans"]} -->
<h3>Tarification et recommandation mises à jour</h3>
<p>Remplacement du forfait Starter abandonné par Essentials et mise à jour du comparatif. Les équipes ayant besoin d'exports d'audit reçoivent désormais une recommandation différente.</p>
<!-- /wp:amicited/update-log-item -->
<!-- /wp:amicited/update-log -->

WordPress devrait exposer des contrôles structurés pour la date, le type, l’impact, la section et les preuves.

Exemples

Bonne entrée de mise à jour

18 juillet 2026 — Calcul corrigé
Correction du dénominateur du taux de conversion, passant de toutes les sessions aux sessions de produits éligibles dans le tableau « Performances des canaux ». Les valeurs pour la recherche organique sont passées de 3,1 % à 2,4 % ; le classement des canaux et la conclusion de l’article n’ont pas changé. Les décomptes de sessions sous-jacents n’ont pas été affectés.

Cette entrée fonctionne car elle nomme l’erreur, les anciennes et nouvelles définitions, la section affectée, la conséquence numérique et le statut de la conclusion. Les lecteurs peuvent juger si un travail antérieur nécessite une révision.

Mauvaise entrée de mise à jour

Été 2026 — Entièrement actualisé !
Nous avons révisé cette page et apporté plusieurs améliorations pour que vous puissiez avoir confiance que tout est à jour.

Cette entrée échoue car la date est vague, « entièrement » exagère la portée, « plusieurs améliorations » cache les faits et « confiance » exige une conclusion non méritée. Si le travail était cosmétique, supprimez l’entrée. S’il était substantiel, nommez chaque changement pertinent pour la décision.

Balisage schéma et accessibilité

Un journal des mises à jour n’a pas de type Schema.org autonome. Il reste un contenu au sein de l’Article, TechArticle ou Report englobant. L’événement substantiel le plus récent peut alimenter dateModified ; une révision sans changement ne le doit pas. Ne remplacez jamais datePublished.

N’encodez pas les entrées comme CreativeWork, Event, HowToStep ou ItemList ; ces types impliquent des significations que le journal n’a pas. Utilisez du HTML prévisible : une section étiquetée, des éléments de liste, des en-têtes, <time datetime="2026-08-27">27 août 2026</time> et des fragments stables.

Utilisez un élément de liste par événement ; le CSS peut tracer une frise chronologique sans changer l’ordre. Indiquez que les entrées sont classées des plus récentes aux plus anciennes. Affichez le type en texte, pas seulement en couleur ou icônes, et utilisez des liens descriptifs.

Une archive nécessite une divulgation native étiquetée avec son nombre ou sa plage. Toutes les entrées doivent être accessibles au clavier et aux lecteurs d’écran. N’utilisez pas de région ARIA live. Préservez l’ordre des en-têtes et les dates localisées.

Placez un avis de correction près de l’affirmation concernée et enregistrez-le dans le journal. Le premier protège les lecteurs immédiats ; le second préserve l’historique.

Règles d’écriture

Commencez par l’objet modifié et un verbe précis : « Règle d’éligibilité clarifiée », « Jeu de données remplacé » ou « Formule corrigée ». Limitez les résumés à 4–14 mots et les détails à 25–90 mots. Utilisez une phrase pour le changement et la raison, une autre pour l’impact. Utilisez des dates absolues localisées et un affichage des plus récentes en premier.

Expliquez la raison avant le résultat. « Le fournisseur a abandonné Starter, donc nous l’avons remplacé par Essentials et réévalué la recommandation » enregistre la cause ; « Nous avons amélioré notre comparatif » enregistre une opinion. Utilisez le passé neutre.

Chaque entrée matérielle devrait répondre à ces questions :

• Quel fait, instruction, méthode, source, portée ou conclusion spécifique a changé ?
• Pourquoi le changement était-il nécessaire ?
• Où sur la page cela s’est-il produit ?
• La réponse principale, la recommandation ou la conclusion a-t-elle changé ?
• Le lecteur doit-il refaire une décision ou une action basée sur la version antérieure ?

Créez une entrée par événement éditorial, pas par frappe. Regroupez les modifications connexes d’une même révision ; séparez les travaux sans lien, les impacts différents ou les dates différentes. Affichez trois à cinq entrées et conservez l’historique matériel.

N’incluez jamais de notes confidentielles, de détails de sécurité, de vulnérabilités, de données personnelles, de blâme, de hachages de commit bruts, de tickets non expliqués, de marketing, d’urgence ou de bibliographie. Ne promettez jamais « 100 % à jour », n’effacez pas les corrections, ne réécrivez pas silencieusement les entrées et ne redatez pas un travail cosmétique.

Si une entrée nécessite une correction, préservez sa date et ajoutez un événement de correction. Les obligations de confidentialité, de sécurité ou juridiques peuvent justifier une expurgation ; indiquez que l’enregistrement a été modifié et pourquoi à un niveau approprié.

Types d’articles qui l’utilisent

Le tableau postTypes dans le frontmatter est la source de ce tableau. « Requis » signifie que l’historique des révisions substantielles fait partie du contrat de confiance du format ; « conditionnel » signifie que le journal apparaît une fois qu’un changement qualifiant se produit.

Une nouvelle page n’a besoin d’aucun journal vide. Après un changement qualifiant, préservez l’élément.

Liste de contrôle QA

• Chaque entrée visible représente un événement éditorial substantiel, pas un changement cosmétique ou automatisé.
• La date de l’événement est exacte, valide, non future et correspond à l’enregistrement éditorial approuvé.
• Le résumé nomme l’objet modifié et reste dans 4–14 mots.
• Le détail indique ce qui a changé et pourquoi avant de décrire le bénéfice.
• L’entrée identifie si la réponse, la conclusion, la recommandation, l’éligibilité ou les instructions ont changé.
• Une correction matérielle apparaît également à côté de l’affirmation concernée.
• Les fragments de section et les identifiants de preuve renvoient à des cibles stables sur la même page canonique.
• Le journal apparaît après le contenu principal et les sources mais avant les modules promotionnels de clôture.
• Le journal n’est pas visuellement fusionné avec un CTA, une offre, une évaluation, un témoignage ou un bloc de sources.
• Les dates utilisent des valeurs <time> sémantiques ; les types d’événements et les impacts ne dépendent pas de la couleur ou des icônes.
• Le contrôle d’archive est utilisable au clavier, clairement étiqueté et expose son contenu complet aux technologies d’assistance.
• Une entrée de révision uniquement ne modifie pas dateModified ; un dernier événement substantiel correspond à la date de mise à jour canonique.
• Les notes confidentielles, données personnelles, détails de sécurité, historique d’implémentation brut et langage marketing sont absents.
• Le type d’article de la page et le risque pour le lecteur justifient l’élément.

FAQ

Chaque modification de contenu doit-elle figurer dans le journal des mises à jour ?

Non. Enregistrez les modifications qui altèrent les faits, les instructions, les preuves, la portée, l’interprétation, les recommandations ou la décision d’un lecteur. Omettez l’orthographe, l’espacement, le suivi, les modèles et autres modifications non substantielles.

En quoi un journal des mises à jour diffère-t-il d’une date de dernière mise à jour ?

Une date de dernière mise à jour indique qu’un changement substantiel a eu lieu. Un journal des mises à jour précise ce qui a changé, pourquoi cela a changé et si la réponse ou la conclusion a évolué, de sorte que l’affirmation de maintenance puisse être inspectée.

La mise à jour la plus récente ou la plus ancienne doit-elle apparaître en premier ?

Affichez l’entrée la plus récente en premier pour une page maintenue, car les lecteurs ont généralement besoin du changement actuel. Préservez l’ordre chronologique dans les sorties machine et fournissez une archive clairement identifiée lorsque la liste visible est raccourcie.

Un journal des mises à jour peut-il remplacer les avis de correction ?

Non. Une erreur matérielle nécessite une correction visible près de l’affectation concernée ainsi qu’une entrée permanente dans le journal. Le journal préserve l’historique ; il ne doit pas cacher une correction en bas de page.

Les révisions sans changement doivent-elles apparaître dans le journal ?

Uniquement lorsque le statut de la révision importe aux lecteurs et que l’entrée est étiquetée « Révisé », pas « Mis à jour ». Indiquez le périmètre vérifié et qu’aucun changement substantiel n’était nécessaire ; ne modifiez pas dateModified.