Points clés
- La gestion du cycle de vie des données (DLM) est une approche gouvernée par des politiques pour contrôler les données de leur création à leur suppression, couvrant le stockage, l'utilisation, l'archivage et la suppression.
- La plupart des défaillances de DLM ne surviennent pas au niveau des outils mais au niveau des politiques : règles de rétention peu claires, absence de propriétaire des données et absence de critères d'archivage formel.
- Les données maitresses (produits, clients, fournisseurs) nécessitent des contrôles de cycle de vie plus stricts que les données opérationnelles, car elles circulent simultanément dans plusieurs systèmes.
- Une plate-forme MDM centralisée avec gouvernance intégrée, workflows d'approbation et synchronisation bidirectionnelle rend l'application du cycle de vie beaucoup plus cohérente que sa gestion système par système.
Chaque entreprise accumule les données plus vite qu'elle ne les gère. Enregistrements de ventes, contrats de fournisseurs, spécifications de produits, profils clients : chacun créé avec un objectif, beaucoup le dépassant. Les données qui étaient critiques pour l'entreprise il y a deux ans peuvent maintenant représenter un risque de conformité.
L'ampleur du problème est significative. Le marché mondial des mégadonnées devrait passer de 324,59 milliards de dollars en 2026 à 516,29 milliards de dollars d'ici 2031, sous l'effet du volume de données que les organisations génèrent désormais et de l'infrastructure nécessaire pour les gérer. Plus de données signifient plus de décisions de cycle de vie : quoi conserver, quoi retirer et qui est responsable de la décision.
C'est le problème que la gestion du cycle de vie des données existe pour résoudre.
Qu'est-ce que la gestion du cycle de vie des données ?
La gestion du cycle de vie des données (DLM) est une approche gouvernée par des politiques pour contrôler les données tout au long de leur vie utile : du moment où elles sont créées ou ingérées au moment où elles sont archivées ou supprimées. Elle couvre la manière dont les données sont stockées, qui peut y accéder, pendant combien de temps elles sont conservées et comment elles sont supprimées de manière sécurisée.
Le terme est parfois utilisé de manière interchangeable avec la gestion du cycle de vie de l'information (ILM), mais les deux diffèrent par leur portée. La DLM opère au niveau des fichiers et des enregistrements, en gérant les objets de données en fonction du type, de l'âge et des modèles d'utilisation. L'ILM gère les éléments de données individuels au sein de ces enregistrements, tels que les soldes de compte ou les coordonnées. En pratique, la plupart des organisations ont besoin des deux, mais la DLM est la base structurelle.
Un programme DLM bien géré donne aux équipes de données trois choses : un accès fiable aux données toujours pertinentes, une piste d'audit défendable à des fins de conformité, et un moyen contrôlé de retirer les données qui ne sont plus nécessaires. Au-delà de l'accès et de la conformité, une stratégie de cycle de vie des données fonctionnelle présente également un argument de coût direct : les frais de stockage pour les données que personne n'utilise, l'exposition aux violations de la part de données dont on n'a pas réalisé qu'elles existaient toujours, et les pertes d'efficacité opérationnelle des équipes travaillant sur des enregistrements obsolètes.
Les cinq étapes du cycle de vie des données
Les phases du cycle de vie des données décrites ci-dessous représentent le modèle à cinq étapes le plus largement utilisé : création, stockage, utilisation, archivage et suppression. Ces étapes du cycle de vie des données forment la base de tout programme DLM, chacune nécessitant sa propre politique de données, ses propres règles de rétention et ses propres attributions de responsabilité. Certains frameworks développent cela en six ou huit étapes en séparant le traitement du stockage et l'analyse de l'utilisation, mais la logique sous-jacente est la même.
Étape 1 : création et collecte de données
Les données entrent dans le cycle de vie par de nombreuses routes : formulaires web, systèmes ERP, capteurs IoT, saisie manuelle, importations de fichiers et flux API. Le volume et la variété rendent cette étape plus difficile à gouverner qu'il n'y paraît.
Le risque ici est l'incohérence. Lorsque différentes équipes ou systèmes créent le même type de données dans des formats différents et avec des conventions de dénomination ou des règles de validation différentes, les problèmes se multiplient en aval. Un enregistrement de produit saisi dans l'ERP sous « PROD-0012 » et dans la plate-forme de e-commerce sous « Product 12 » représente la même entité, mais aucun système ne le sait sans modélisation de données explicite.
Lors de la collecte, une bonne pratique DLM signifie établir des formats standardisés, définir la propriété des données, classer les données par sensibilité et type, et étiqueter les enregistrements avec les métadonnées nécessaires pour les gérer plus tard. Les règles de validation des données à l'ingestion détectent les erreurs avant qu'elles ne se propagent. Les décisions de modélisation des données prises ici (définitions d'entités, types de champs, relations) déterminent la façon dont les contrôles de cycle de vie pourront être appliqués plus tard. Le nettoyage des données à la source maintient l'intégrité des données élevée dès le départ. C'est beaucoup plus facile à automatiser lorsque les données entrent par un concentrateur central plutôt que directement dans chaque système en aval.
Étape 2 : stockage des données
Les décisions de stockage affectent chaque étape suivante du cycle de vie. Les données qui se retrouvent au mauvais endroit ou avec les mauvais contrôles d'accès créent des coûts et des risques de conformité qui sont difficiles à inverser.
Les données structurées vont généralement dans les bases de données relationnelles ; les données non structurées dans les magasins NoSQL, les référentiels de documents ou le stockage d'objets. Mais la question la plus importante est de savoir si l'architecture de stockage reflète les modèles d'utilisation réels. Une approche de stockage hiérarchisé fait correspondre les données aux supports en fonction de la fréquence d'accès : les données opérationnelles fréquemment utilisées restent sur un stockage rapide et coûteux ; les enregistrements rarement consultés sont déplacés vers des niveaux moins coûteux. La sauvegarde des données et la redondance des données sont indispensables à ce stade. Une seule copie n'est pas une sauvegarde. Les données non structurées sont le segment à la croissance la plus rapide, dont l'expansion est projetée à un TCAC de 13,5 % jusqu'en 2031, ce qui rend les décisions de stockage hiérarchisé et les politiques de cycle de vie pour le contenu non structuré de plus en plus importantes.
Les mesures de sécurité et de protection des données doivent être conçues ici, non pas ajoutées ultérieurement : le chiffrement au repos, les contrôles d'accès et les règles de résidence des données font tous partie d'une bonne gouvernance du stockage. C'est particulièrement important pour les organisations soumises à la RGPD, la CCPA, l'HIPAA ou des cadres de conformité réglementaire similaires.
Étape 3 : utilisation et partage des données
C'est l'étape où les données créent de la valeur. Analyses, rapports, pipelines de traitement des données, applications orientées clients : tout dépend de l'accessibilité, de l'exactitude et de l'actualité des données.
La DLM définit qui peut utiliser les données à ce stade et à quelles fins. C'est en partie une question de gouvernance (rôles, permissions, politiques d'accès) et en partie une question technique (accès API, catalogues de données, modèles d'intégration des données). Le risque d'un partage excessif est l'exposition à la conformité réglementaire ; le risque d'un partage insuffisant est que les équipes travaillent avec des copies locales obsolètes au lieu de la source d'autorité, ce qui réduit directement la disponibilité des données et l'efficacité opérationnelle.
Dans les organisations où plusieurs systèmes partagent les mêmes données maitresses, par exemple un catalogue de produits alimentant à la fois l'ERP et trois canaux de e-commerce, l'incohérence à ce stade est coûteuse. Un système est mis à jour, les autres non. Les retours s'accumulent. Le service client gère les plaintes qui ont pour origine une incohérence de données créée trois mois auparavant.
Étape 4 : archivage des données
Les données qui ne sont plus activement utilisées mais qui doivent toujours être conservées vont en archive. Cela peut être motivé par des exigences légales, des obligations d'audit ou une politique métier. Les déclencheurs exacts varient selon l'industrie : les enregistrements financiers peuvent devoir être conservés pendant sept ans ; les données médicales plus longtemps ; les données marketing souvent moins.
L'étape d'archivage est celle où de nombreux programmes DLM manquent de précision. Les organisations archivent souvent tout par défaut, ce qui annule l'objectif de coût et de conformité de l'archivage des données en premier lieu. Une bonne politique d'archivage définit des critères spécifiques : quels types de données, pendant combien de temps, dans quelles conditions d'accès, et ce qui se passe à la fin de la période de rétention.
L'archivage sans calendrier de suppression n'est que l'accumulation retardée. La responsabilité des données ne disparaît pas ; elle augmente.
Étape 5 : suppression des données
À la fin de son cycle de vie, les données sont purgées. De manière sécurisée. Avec une piste d'audit vérifiable.
Cette étape compte davantage que les organisations ne la traitent généralement. Conserver les données au-delà de leur période de rétention requise crée une exposition réglementaire en vertu de la RGPD, de la CCPA et de cadres similaires. Cela augmente également les frais de stockage, la complexité de la recherche et le rayon d'impact d'une violation de données potentielle.
La suppression doit être systématique, gouvernée par une politique et enregistrée. La suppression sécurisée signifie la destruction vérifiable : l'enregistrement est supprimé de chaque système qui le détient, y compris les sauvegardes et les magasins secondaires. La suppression manuelle sur demande, sans processus formel, est la façon dont les organisations créent l'incohérence : l'enregistrement est supprimé du CRM mais pas de l'entrepôt de données ou du pipeline de sauvegarde.
Où la DLM échoue en pratique
L'outillage pour la gestion du cycle de vie est largement disponible. Les défaillances sont presque toujours organisationnelles et procédurales.
La direction générale a remarqué le phénomène. Environ 90 % des organisations ont maintenant un responsable des données (CDO) ou un responsable des données et analyses désigné, contre seulement 12 % en 2012. Environ 38,5 % ont nommé séparément un responsable de l'IA. Ces deux rôles dépendent directement de la qualité en amont et de la discipline de cycle de vie des données d'entreprise. Mais la propriété exécutive de l'agenda des données ne se traduit pas automatiquement par des politiques de cycle de vie opérationnelles.
La plupart des entreprises n'ont pas de stratégie formelle de cycle de vie des données. Ou elles en ont une écrite à des fins de conformité que personne n'applique réellement. Ou la politique de cycle de vie existe mais ne s'applique qu'aux documents, non aux enregistrements de base de données ou aux données provenant des API. Nos clients viennent régulièrement nous voir avec ce problème : leurs données se sont accumulées dans les systèmes pendant des années, personne n'en est formellement propriétaire, et il n'y a pas de norme convenue sur ce qui est conservé, mis à jour ou supprimé.
Quelques modèles se manifestent régulièrement :
- Absence de propriété des données. Les enregistrements existent dans plusieurs systèmes sans responsable des données désigné. Lorsqu'une spécification de produit change, il est peu clair qui est responsable de la propagation de ce changement. Il est mis à jour dans un système, ignoré dans un autre.
- Rétention par défaut. Tout est conservé indéfiniment parce que supprimer des choses semble risqué. Le résultat est des années d'enregistrements obsolètes, d'entrées dupliquées et de données obsolètes traitées comme actuelles.
- Politiques de cycle de vie qui s'arrêtent à la création. Les entreprises investissent dans la qualité des données à l'ingestion, mais n'ont pas de processus équivalent pour l'archivage ou la destruction de données. Les données naissent avec un plan ; elles vivent sans.
Un rapport 2025 de l'IBM Institute for Business Value a révélé que 43 % des directeurs opérationnels considèrent la qualité des données comme leur priorité de données la plus importante, et plus d'un quart des organisations estiment des pertes annuelles dépassant 5 millions de dollars en raison d'une mauvaise qualité des données. Une grande partie de ce coût est liée au cycle de vie : des données obsolètes entraînant de mauvaises décisions, des enregistrements dupliqués générant des résultats incorrects, des données conservées qui auraient dû être supprimées et créant une exposition à la conformité et à la confidentialité.
DLM et données maitresses : un problème plus complexe
Les données maitresses (produits, clients, fournisseurs, employés, localités) posent un défi spécifique de cycle de vie que les données opérationnelles ne posent pas.
Un enregistrement de transaction de vente vit dans un système et suit un cycle de vie relativement simple. Un enregistrement de produit vit dans l'ERP, le PIM, la plate-forme de e-commerce, le portail des fournisseurs et potentiellement plusieurs autres simultanément. Lorsque ce produit atteint la fin de sa vie, son enregistrement doit être retiré de manière cohérente dans tous les systèmes. Une suppression dans un système sans mise à jour correspondante dans les autres crée des enregistrements fantômes : des données qui circulent toujours dans les pipelines de données en aval et influencent les décisions opérationnelles même si l'objet commercial sous-jacent n'existe plus.
C'est pourquoi la gestion du cycle de vie des données maitresses doit être traitée au niveau du concentrateur, non système par système. Le concentrateur maintient un enregistrement d'autorité unique pour chaque entité (effectivement un disque d'or), et tout changement de statut de cycle de vie se propage de là à tous les systèmes connectés par l'intégration des données.
Avec les fabricants gérant de grands portefeuilles de produits, la situation typique avant la centralisation ressemble à ceci : les produits sont actifs dans la vitrine de e-commerce longtemps après leur arrêt dans l'ERP, parce que les deux systèmes ne sont pas synchronisés pour les événements de cycle de vie, seulement pour la création initiale. La solution n'est pas purement technique. Elle nécessite des définitions claires du statut de cycle de vie (actif, arrêté, archivé, supprimé) qui sont appliquées de manière centralisée et propagées automatiquement à chaque système connecté.
Le problème n'est pas que les données ne peuvent pas être supprimées. C'est que la suppression doit se produire dans cinq endroits à la fois, et il n'y a pas de point de contrôle unique.
Comment une plate-forme MDM soutient la gestion du cycle de vie des données
Une plate-forme de gestion des données maitresses ne remplace pas une politique DLM, mais elle rend l'application de la politique de cycle de vie beaucoup plus cohérente dans les systèmes.
AtroCore est une plate-forme MDM open-source et d'intégration de systèmes construite autour d'une source d'autorité unique pour les données maitresses. Plusieurs de ses caractéristiques architecturales sont directement pertinentes pour la gestion du cycle de vie.
Modélisation de données centralisée.
AtroCore utilise un modèle de données flexible basé sur EAV qui permet aux organisations de définir leurs propres entités et relations. Un champ « statut du cycle de vie du produit » ou un workflow de cycle de vie complet peut être intégré directement au modèle de données et appliqué uniformément à tous les enregistrements. Il n'est pas nécessaire de répliquer cette logique séparément dans chaque système connecté.
Synchronisation bidirectionnelle en temps réel.
Les modifications apportées dans AtroCore se propagent automatiquement aux systèmes ERP, CRM et e-commerce connectés via son API REST et sa couche d'intégration. Un changement de statut de cycle de vie, par exemple marquer un produit comme arrêté, s'écoule immédiatement vers tous les systèmes en aval sans intervention manuelle. Cette automatisation comble l'écart entre l'intention de la politique et la réalité opérationnelle.
Workflows d'approbation et gouvernance.
AtroCore inclut des workflows intégrés pour l'approbation des données, les demandes de modification et les transitions de cycle de vie. Un produit ne peut pas être publié sans passer par une étape d'approbation définie. Il ne peut pas être supprimé sans une entrée de journal d'audit correspondante. Cela rend la gestion des données vérifiable plutôt que théorique.
Déduplication et validation.
Avant que les données n'entrent dans le cycle de vie, AtroCore applique les règles de validation des données et identifie les doublons. Cela réduit le volume d'enregistrements qui doivent être gérés plus tard et améliore la fiabilité des décisions de rétention.
Pour les organisations gérant des données maitresses multi-domaines complexes dans de nombreux systèmes, centraliser le contrôle du cycle de vie dans une plate-forme comme AtroCore est sensiblement plus fiable que de coordonner les mêmes politiques dans chaque système indépendamment.
Élaborer une stratégie DLM pratique
Un programme DLM fonctionnel ne nécessite pas un remplacement de plate-forme complet. Il nécessite des décisions de politique claires et la discipline pour les appliquer.
Commencez par la classification des données. Pas tout ne nécessite le même traitement. Séparez les données personnelles sensibles (avec des limites de rétention strictes et des obligations de confidentialité des données), les enregistrements réglementés (avec des périodes de rétention obligatoires), les données opérationnelles (avec une rétention basée sur l'utilisation) et les données de référence (avec un cycle de vie lié à l'objet commercial sous-jacent).
Ensuite, assignez la propriété. Chaque domaine de données a besoin d'un propriétaire responsable : une personne ou une équipe responsable de l'exactitude, de l'actualité et du retrait éventuel des données dans ce domaine. Sans propriété, les politiques sont aspirationnelles.
Définissez explicitement les périodes de rétention, par type de données et par juridiction. Documentez-les. Automatisez l'application autant que possible. Les processus de suppression manuelle dépendent de quelqu'un se souvenant de les exécuter, ce qui n'est pas une stratégie de cycle de vie des données ; c'est un espoir.
Intégrez l'archivage et la suppression au système dès le départ, non comme un ajout ultérieur. C'est beaucoup plus facile de définir une politique de rétention lors de la construction d'un modèle de données que d'en adapter une à dix ans de données accumulées. L'argument de réduction des coûts pour le faire rapidement est substantiel : moins de stockage, surface de violation plus petite, traitement plus rapide des données et analyses plus propres.
Enfin, auditez régulièrement.
Une politique DLM qui n'est pas surveillée n'est pas une politique. C'est un document.
La gestion du cycle de vie des données n'est pas un projet unique. C'est une discipline opérationnelle continue. Les organisations qui la pratiquent bien ne sont pas nécessairement celles qui ont les outils les plus sophistiqués. Ce sont celles qui traitent la gouvernance des données comme une responsabilité continue plutôt que comme une case de conformité à cocher.