Notes de version et journal des modifications

Les notes de version sont l’enregistrement daté et de première main d’un changement produit : ce qui a été livré, qui cela concerne, ce qui se comporte différemment et ce que l’utilisateur doit faire ensuite. Un journal des modifications est la collection chronologique de ces entrées. Le format est un outil de fidélisation avant d’être un actif de trafic ; les clients l’utilisent pour planifier leur travail et éviter les surprises.

La règle directrice est la conséquence avant la célébration. Une version peut être excitante pour l’équipe, mais le lecteur a d’abord besoin de savoir si son flux de travail, son intégration, ses données, ses autorisations, son prix ou sa compatibilité ont changé. Énoncez cette conséquence en langage clair, puis expliquez la capacité. Dans le système des types de contenu SEO , les notes de version sont un contenu de support à l’étape de fidélisation ; leur valeur vient d’enregistrements permanents qui ne sont jamais silencieusement réécrits.

Questions auxquelles elles répondent

Une entrée complète de notes de version répond aux questions qu’un utilisateur actuel se pose après avoir vu un changement produit ou rencontré un comportement inconnu :

• Qu’est-ce qui a changé, et à quelle date de version ou version cela a-t-il changé ?
• Le changement est-il disponible maintenant, déployé progressivement, en version bêta, ou limité par forfait, région, plateforme ou type de compte ?
• Qui est concerné, y compris les administrateurs, les utilisateurs finaux, les développeurs, les partenaires ou une intégration définie ?
• Quel était l’ancien comportement, et qu’est-ce qui est différent maintenant ?
• L’utilisateur doit-il migrer, mettre à jour ses paramètres, réautoriser l’accès, reformer ses collègues ou ne rien faire ?
• Le changement est-il cassant, obsolète, réversible, sensible à la sécurité ou susceptible de modifier les données stockées ?
• Où se trouvent les instructions mises à jour, la référence technique, les limitations connues et le chemin de support ?
• Comment un lecteur peut-il vérifier que le nouveau comportement est actif dans son compte ?

Ne faites pas déduire l’impact aux lecteurs par des étiquettes telles que « amélioré », « mis à jour » ou « simplifié ». « Les exportations sont améliorées » est promotionnel mais invérifiable. « Les exportations CSV incluent désormais les filtres de pays et de modèle appliqués dans deux nouvelles colonnes ; les colonnes existantes et l’ordre restent inchangés » définit le changement observable et sa limite de compatibilité.

Quand utiliser ce type de contenu

Utilisez les notes de version lorsqu’un événement a été livré ou a un état de disponibilité ferme et crée une différence visible par l’utilisateur qui mérite d’être préservée dans l’historique du produit. L’intention de recherche est généralement navigationnelle ou informationnelle : les lecteurs recherchent un produit plus « notes de version », un numéro de version, une fonctionnalité modifiée, une obsolescence ou une étiquette d’interface inconnue. N’utilisez pas le format comme un backlog de promesses, un fil d’annonces générales ou un substitut à la documentation de tâches.

Un changement n’a pas besoin d’une nouvelle interface pour être admissible. Le comportement API, la rétention, les calculs, l’authentification, les formats, les limites, les valeurs par défaut, la facturation et l’accessibilité peuvent tous nécessiter une entrée. Une refonte interne sans conséquence observable n’en nécessite pas.

Meilleur pour ces types d’entreprises

Le classement reflète la nécessité de maintenir un contrat public daté avec les utilisateurs existants.

1. SaaS . La meilleure adéquation car les interfaces livrées en continu, les API, les autorisations, les intégrations et les limites de forfait peuvent changer entre les visites des clients. Les entrées doivent inclure l’état du déploiement, les forfaits concernés, l’impact sur l’administrateur et les liens vers la documentation.
2. Marketplaces . Grande valeur car une seule version peut affecter différemment les acheteurs, les vendeurs, les modérateurs, les bénéficiaires de paiements ou les partenaires. Segmentez l’impact et évitez de présenter un changement propre à un participant comme universel.
3. Ecommerce . Utile pour les changements de compte, de paiement, d’abonnement, de retours, de fidélité, de livraison et d’outils marchands. Séparez l’impact client en boutique de l’impact opérateur ou intégration, surtout autour des paiements et des statuts de commande.
4. Fabricants et fournisseurs industriels . Important pour le firmware, les logiciels de contrôle, les équipements connectés, les portails techniques et les révisions de spécifications. La version, la compatibilité des modèles, les limites de sécurité et la disponibilité du retour en arrière doivent être explicites.
5. Finance, fintech et assurance . Utile mais nécessite une révision approfondie car les changements de calcul, d’éligibilité, de divulgation, d’authentification et de traitement des données peuvent avoir des conséquences réglementaires. Enregistrez la juridiction, l’approbation, la date d’effet et le comportement remplacé.
6. Services B2B . Utile de manière sélective lorsque le service inclut une plateforme maintenue, une méthodologie, un ensemble de données, un portail client ou un livrable standard. Les actualités d’entreprise ordinaires appartiennent ailleurs, sauf si elles modifient le contrat client ou le flux de travail.

Intention de recherche

La demande de notes de version est souvent de faible volume et de haute spécificité. Les requêtes incluent un nom de produit avec « journal des modifications », « dernière version », « ce qui a changé », « nouveau tableau de bord », une version d’API, une erreur introduite après une mise à jour ou une date d’obsolescence. L’utilisateur ne demande pas un argumentaire produit général. Il veut un horodatage faisant autorité et suffisamment de détails pour prendre une décision.

La forme utile du résultat commence par produit + version ou date + changement + impact. Placez ces faits dans le titre, le résumé d’ouverture, les titres et les métadonnées sans forcer chaque entrée mineure sur sa propre URL indexable. Des ancres stables permettent aux équipes de support et aux réponses IA de citer une entrée ; des pages dédiées sont justifiées lorsqu’une version comporte un travail de migration substantiel, une demande distinctive ou plusieurs changements connexes.

Les notes de version sont un signal de fraîcheur sous-estimé car elles exposent les changements réels au rythme où ils se produisent. Cela ne justifie pas de modifier les dates pour paraître actif. La date d’entrée, la documentation actuelle, le comportement du produit et les conseils de migration doivent concorder.

Structure de la page

Les fourchettes de mots fixent l’emphase, pas des quotas. Conservez le même ordre des champs pour que les lecteurs puissent parcourir aussi bien les petites corrections que les versions cassantes.

Regroupez les changements avec des étiquettes stables telles que Ajouté, Modifié, Corrigé, Obsolète, Supprimé, Sécurité, mais ne laissez jamais une étiquette remplacer l’explication. « Corrigé : exportations » n’est pas un enregistrement utile. Chaque élément doit nommer le symptôme ou la limitation antérieure, le nouvel état observable, le périmètre concerné et toute action requise.

Éléments requis

La position fait partie du contrôle des risques : un avertissement de migration affiché après la célébration de la fonctionnalité arrive trop tard.

Frontmatter et données structurées

Suivez la spécification du frontmatter . Cette page du playbook utilise entity = "post-type-release-notes". Un journal des modifications produit doit utiliser une valeur stable produit-et-flux telle que entity = "atlas-cloud-release-notes" ; une version individuelle peut utiliser entity = "atlas-cloud-2026-08". N’utilisez pas un slogan de campagne ou un titre de version modifiable comme identifiant.

Utilisez schemaType = "Article" pour une page de notes de version individuelle. Si le site expose un index en tant qu’entité distincte, CollectionPage peut décrire cet index tandis que chaque entrée importante reste un élément daté visible. Ajoutez FAQPage uniquement lorsque la FAQ est visible et prise en charge par l’implémentation. N’utilisez pas HowTo simplement parce que les instructions de migration contiennent des étapes, et ne marquez pas un produit comme nouvellement publié lorsque la page n’a corrigé qu’un libellé.

Stockez la date de version séparément des dates de publication et de modification. Les champs recommandés incluent product, stream, version, status, releasedAt, platforms, plans, regions, affected roles, breakingChange, actionRequired, deprecationDate, owner, canonical URL et documentation targets. Pour un déploiement progressif, conservez une date de version et indiquez la fenêtre dans le texte visible.

Exemple complet

L’exemple fictif ci-dessous illustre une version importante. Il place la conséquence de migration avant le résumé de la fonctionnalité et utilise une URL de version stable.

+++
title = "Atlas Cloud 4.8 Release Notes — 27 August 2026"
seoTitle = "Atlas Cloud 4.8 Release Notes: Export API Migration"
entity = "atlas-cloud-4-8"
keywords = [ "Atlas Cloud 4.8", "Atlas release notes", "export API v2", "Atlas changelog", "export migration", "Atlas product updates" ]
description = "Atlas Cloud 4.8 adds saved export views and API v2, explains the v1 deprecation deadline, and gives administrators a tested migration and validation path."
type = "academy"
date = "2026-08-27 10:00:00"
schemaType = "Article"
product = "Atlas Cloud"
version = "4.8"
releaseStatus = "rolling-out"
releasedAt = "2026-08-27"
platforms = [ "web", "API" ]
affectedRoles = [ "workspace administrator", "integration owner" ]
breakingChange = true
deprecationDate = "2026-10-15"
+++

# Notes de version Atlas Cloud 4.8

Atlas Cloud 4.8 a commencé à être déployé le 27 août 2026. Il ajoute des vues d'exportation sauvegardées et l'API Export v2. Les membres de l'espace de travail peuvent utiliser les vues sauvegardées sans modifier les exportations existantes. Les propriétaires d'intégration utilisant l'API v1 doivent migrer avant le 15 octobre 2026 ; après cette date, les requêtes d'exportation v1 renverront une réponse de version non supportée.

## Action requise : migrer l'API Export v1

**Qui est concerné :** les intégrations qui envoient des requêtes à `/api/v1/exports`. Les exportations du tableau de bord et les clients API v2 ne sont pas concernés.

**Ce qui change :** la v2 nécessite une valeur `format` explicite et retourne l'identifiant du job d'exportation dans `data.id`. Les colonnes du fichier ne changent pas, sauf si une vue sauvegardée sélectionne un ensemble de champs différent.

**Date limite :** effectuez la migration et la validation avant le 15 octobre 2026. Les requêtes v1 existantes continuent de fonctionner jusque-là.

1. Créez une requête test sur le endpoint v2 avec les mêmes filtres qu'une requête v1 actuelle.
2. Ajoutez la valeur `format` requise et lisez l'identifiant du job depuis `data.id`.
3. Comparez le nombre de lignes, l'ensemble de champs, le fuseau horaire et un enregistrement connu entre les anciens et nouveaux fichiers.
4. Mettez à jour la production seulement après que la comparaison réussit. Conservez la configuration précédente disponible jusqu'à ce que la première exportation de production planifiée réussisse.

Si le test ne correspond pas, laissez l'intégration de production sur v1 et envoyez au support l'ID de requête anonymisé, l'horodatage, le fuseau horaire et l'incohérence de champ. N'incluez pas de jeton d'accès.

## Ajouté : vues d'exportation sauvegardées

Les administrateurs d'espace de travail peuvent enregistrer un ensemble nommé de champs, filtres, tris et format de fichier. Les membres disposant de l'autorisation d'exportation peuvent réutiliser la vue ; sauvegarder une vue n'accorde pas l'accès à des enregistrements qu'ils ne pouvaient pas déjà voir.

Pour vérifier la disponibilité, ouvrez **Exports → Views** et cherchez **Save current view**. Le contrôle peut prendre jusqu'à trois jours pour apparaître pendant le déploiement. Il est inclus dans les forfaits Standard et Entreprise dans toutes les régions.

## Corrigé : libellés des filtres de pays dans les fichiers CSV

Les exportations CSV utilisent désormais le nom de pays visible dans la colonne de résumé du filtre au lieu de la valeur interne à deux lettres. Cela modifie uniquement le libellé du résumé ; les enregistrements filtrés et les colonnes de données existantes sont inchangés.

## Limitations connues

Les vues sauvegardées ne peuvent pas encore être transférées entre espaces de travail. Un champ supprimé est retiré de la vue lors de sa prochaine exécution, et l'historique des exportations enregistre cette omission.

## Ressources mises à jour

- Guide de migration API Export v2
- Référence API Export
- Documentation sur les autorisations d'exportation
- Dépannage des exportations

L’exemple nomme une limite de compatibilité testée, distingue le déploiement de la date de version et donne aux lecteurs un moyen de vérifier l’accès.

Galerie de designs

Conservez les mêmes faits de version dans chaque variante de mise en page afin que la révision du design teste la hiérarchie, et non différentes décisions éditoriales.

Liste de contrôle qualité

Une note de version est prête seulement lorsque chaque affirmation applicable est vraie :

• Le titre et l’ouverture identifient le produit, la date ou version, le changement principal et le public concerné.
• La disponibilité est précise : livré, en cours de déploiement avec une fenêtre, bêta, optionnel, limité par forfait, limité par région, reporté ou retiré.
• Chaque entrée explique le comportement observable avant et après plutôt que de se reposer sur « amélioré », « optimisé » ou « corrigé ».
• Les étiquettes Ajouté, Modifié, Corrigé, Obsolète, Supprimé et Sécurité sont appliquées de manière cohérente.
• Les changements cassants apparaissent avant les avantages promotionnels et indiquent le périmètre concerné, la date limite, le mode de défaillance, le remplacement, la migration, la validation, la voie de retour en arrière ou de support.
• Les dates distinguent la version, la publication, la modification substantielle, l’obsolescence et la suppression.
• Les identifiants de version, les noms de endpoints, les libellés de menu, les forfaits, les régions et le périmètre des plateformes ont été vérifiés par rapport à l’état livré.
• Le lecteur peut savoir si une action est requise et comment confirmer son achèvement.
• La documentation actuelle reflète le nouveau comportement et renvoie à la version pertinente là où l’historique compte.
• Les captures d’écran ont une date ou version de capture et un équivalent textuel pour les contrôles ou états qu’elles montrent.
• Les archives fournissent des URL ou ancres stables, un parcours du plus récent au plus ancien et un moyen d’atteindre les entrées plus anciennes.
• Les réponses FAQ du frontmatter et les réponses FAQ visibles correspondent exactement, et les analyses distinguent la navigation de la migration ou de l’action produit.

Erreurs courantes

Rédiger un texte de campagne au lieu d’un enregistrement. « Nous sommes ravis de transformer votre flux de travail » retarde le fait. Commencez par le comportement livré, le public, la disponibilité et l’action ; placez la narration dans une annonce de lancement séparée.

Enterrer les changements cassants. Une date limite de migration en dessous des captures d’écran et des avantages crée des échecs évitables. Placez l’avertissement en premier et rendez-le compréhensible de manière indépendante.

Appeler un déploiement un lancement partout. Si seulement certains comptes y ont accès, dites déploiement et donnez la fenêtre prévue. Les utilisateurs perdent confiance lorsque les instructions décrivent un contrôle qu’ils ne peuvent pas encore voir.

Utiliser « corrections de bugs et améliorations ». Cela cache le comportement affecté et empêche les utilisateurs de reconnaître que leur problème a été résolu. Nommez le symptôme, le périmètre et le nouvel état, sauf si la divulgation de sécurité exige de la retenue.

Modifier les dates pour la fraîcheur. Une correction typographique ne rend pas une ancienne version nouvelle. Préservez releasedAt, enregistrez une correction substantielle séparément et utilisez lastmod seulement lorsque l’enregistrement visible a changé de manière significative.

Dupliquer les instructions actuelles. Une longue procédure de configuration dérivera à deux endroits. Résumez l’étape modifiée dans la note de version et laissez la documentation tenue à jour gérer l’intégralité du flux de travail actuel.

Liens internes

De bons liens internes font du journal des modifications la couche historique de la connaissance produit. Liez depuis la documentation actuelle lorsqu’une transition explique un comportement modifié. Liez depuis la version vers la documentation exacte, la migration, le dépannage, la politique ou le guide de compatibilité là où l’utilisateur en a besoin.

Utilisez un enregistrement canonique pour chaque changement important. Un article de lancement, une page fonctionnalité ou une réponse de support peut le citer ; aucun ne doit le copier. La navigation dans les archives doit connecter les versions adjacentes et l’index. Pour les obsolescences, liez l’ancienne entrée à son remplacement et le guide de migration vers l’avis.

Comment mesurer les résultats

Mesurez si les utilisateurs découvrent le bon enregistrement, comprennent l’impact, effectuent l’action requise et ont besoin de moins de clarification. Les vues brutes ne sont pas l’objectif : une petite correction peut servir son objectif avec peu de trafic.

Utilisez le suivi des prompts pour les requêtes produit-plus-version, les noms de fonctionnalités modifiées, les dates d’obsolescence et les formulations « dernière mise à jour ». Utilisez l’intelligence des sources et citations pour inspecter si les réponses IA citent l’entrée canonique et préservent la disponibilité, le périmètre concerné, la date limite et l’action requise. Le Cockpit AmICited peut placer la visibilité liée aux versions et les URLs citées à côté de l’activité organique d’atterrissage et de certains événements produit.

Avant de publier, enregistrez le public concerné, la fenêtre de déploiement, le volume de support, la référence de migration, les requêtes et prompts cibles, et l’événement qui prouve le succès. Passez en revue :

• impressions et visites pour les requêtes produit, version, fonctionnalité, obsolescence et journal des modifications ;
• citations IA qui reproduisent la date de version correcte, le statut, la limite de compatibilité et l’action ;
• vues d’ancre ou de page par entrée plutôt que les seules vues de l’index du journal des modifications ;
• clics vers la documentation mise à jour, la migration, le dépannage ou les chemins de vérification ;
• démarrages de migration, validations terminées et utilisation existante restante lorsque la télémétrie respectueuse de la vie privée existe ;
• contacts de support causés par un périmètre flou, un accès au déploiement manquant ou un comportement non documenté ;
• réponses obsolètes après une correction, un retrait, une version de remplacement ou un changement de date limite.

Suivez comment nous mesurons les résultats pour séparer la découverte, la citation, l’engagement, l’achèvement de tâche, la fidélisation et les résultats commerciaux. Annotez les lancements, incidents, campagnes et migrations obligatoires avant d’interpréter les mouvements. Un pic de trafic peut indiquer une confusion, et une réponse citée est nocive si elle omet la date limite du changement cassant.

FAQ

Questions fréquemment posées