Analytics Legends La plateforme de connaissance SAP Analytics
Module d'académie

Stratégie des données historiques

Schéma d'architecture du module « Stratégie des données historiques » — Analytics Legends Academy, module M071

À jour au 2026-08-16

Décider la disposition de l'historique par tier d'accès (chaud 2-3 ans pleine granularité · tiède 3-7 ans agrégé · froid statutaire archivé) avant le cutover — pas en migrant tout à pleine granularité. Quatre options : migration complète (chaud seulement), agréger-et-migrer (tiède 80/20), archiver vers NLS/object store (froid), sunset legacy lecture seule avec date ferme. La rétention est une donnée légale (impôt DE 10 ans AO; le RGPD interdit la sur-rétention) — faire signer la matrice par le juridique d'abord. « Avons-nous besoin de 12 ans de granularité quotidienne ? » est la question d'argent; agréger en mensuel réduit le stockage tiède ~10×. Faire économiser le client est la justification de tarif durable.

Ce que vous apprendrez

  • Classifier l'historique BW/4HANA en tiers d'accès chaud / tiède / froid et choisir la disposition correcte (migration complète · agréger-et-migrer · archivage NLS/object store · sunset legacy en lecture seule) pour chaque tier
  • Construire une matrice de rétention réconciliant la rétention statutaire (par ex. enregistrements fiscaux allemands 10 ans sous §147 AO, enregistrements commerciaux sous §257 HGB) avec la limitation de finalité du RGPD, validée par le juridique/finance avant toute décision d'archivage ou de suppression
  • Remettre en question une rétention inutile à pleine granularité (par ex. 12 ans d'historique quotidien) avec une alternative d'agrégation mensuelle et chiffrer l'économie de stockage obtenue
  • Fixer une date de sunset ferme pour un système legacy de repli en lecture seule et l'intégrer dans le plan de vague de décommissionnement (module compagnon M068)

Aperçu du module

La stratégie de données historiques répond à la question que toute migration BW finit par rencontrer : que faisons-nous des 8 à 15 ans d'historique qui vivent dans le système que nous nous apprêtons à retirer ? La mauvaise réponse (tout migrer, à pleine granularité, dans la nouvelle plateforme coûteuse) double silencieusement la facture de stockage et ralentit chaque requête. La réponse senior est une décision de tiering délibérée et consciente de la rétention, prise avant le cutover.

Partir du pattern d'accès, pas du volume de données. L'historique se divise en trois tiers d'accès : (1) chaud — les 2-3 derniers exercices, requêté constamment, nécessite la pleine granularité dans la plateforme active; (2) tiède — 3 à 7 ans en arrière, requêté occasionnellement (audit, tendance année sur année), tolérable à granularité agrégée ou avec une latence plus élevée; (3) froid — au-delà de l'usage minimum statutaire, presque jamais requêté mais légalement à conserver. La plupart des organisations portent les trois au coût du tier chaud parce que personne n'a tranché le tiering.

Module complet réservé aux abonnés. Le module complet ajoute : le cadre de décision · le cas guidé de bout en bout · la grille de KPI · les anti-patterns · les blocs de code · le contrôle de connaissances · les schémas.

Ouvrir dans l'application →