Sommaire :

• Synthèse
• Introduction
• Retour sur la construction d’un système de données
• L’apport des différentes natures de données dans la façon de concevoir les modèles
• Un tour d’horizon des principales natures de données par rapport à leur finalité de gestion et leur cycle de vie
• Les natures de données du domaine de la connaissance de l’univers de la problématique à traiter (métier)

Synthèse

Les données touchent de plus en plus de domaines (métier, problématique à traiter).

Les moyens technologiques pour les gérer sont de plus en plus riches (bases de données, systèmes transactionnels, statistiques, systèmes décisionnels, big data, data science, IA, solutions de data management, data cloud…).

Leur place dans les systèmes d’information est de plus en plus critiques (données sensibles, données personnelles).

Le tout aboutit à un variété très large de données.

Pour maîtriser cette variété, concevoir des systèmes de données de qualité, les acteurs en lien avec les données cherchent à qualifier les données au travers de différentes catégories ou natures de données : données référentielles, données transactionnelles, données personnelles, données agrégées, données décisionnelles, données historisées, données comportementales, données sensibles, données ouvertes…

La liste peut être très longue.

Dans cette liste on distingue deux grands plans :

– Les données représentant le domaine de la problématique à traiter (la connaissance du domaine, de son activité), orientée selon une finalité d’entreprise,

– Et les données vues par rapport à la façon dont elles vont être prises en charge par le système de données en termes de gestion et support de leur cycle de vie.

Ces deux plans sont poreux. Des données transactionnelles sont vues à la fois en vision du domaine de la problématique à traiter (une transaction monétique par exemple) et à la fois en vision implémentation de leur cycle (capacité à maintenir l’intégrité de la transaction, son caractère ACID).

Lorsqu’on conçoit un système de données, l’état de l’art distingue trois modèles de conception : le modèle conceptuel (ou sémantique), le modèle logique et le modèle physique.

Chacun de ces modèles à un rôle bien défini.

Les catégories ou natures de données vont se retrouver dans chaque modèle.

Par exemple, les données devant être historisées ou encore les données référentielles, vont se retrouver dans chaque modèle. Le tout devant être aligné pour la bonne qualité du système de données.

Elles vont servir de guide pour élaborer ces modèles.

Deux postures sont pratiquées par les concepteurs :

– une posture d’élicitation et d’enrichissement, analyse des données de représentation du domaine de la problématique à traiter. Dans cette posture, des catégories et natures de données vont émerger en fonction de la finalité visée.

– une posture d’ingénierie des données. Dans cette posture, il va être fait appel à des catégories et natures de données connues, portées par des systèmes de gestion de données et support au cycle de vie des données.

Ces deux postures se rencontrent, les données identifiées en analyse du domaine, vont avoir leur cycle de vie géré dans un système de données.

Par exemple des données comportementales identifiées pour un système marketing vont devoir être historisées.

Classiquement dans ces postures, les catégories interviennent dans les deux sens. On va chercher si dans la problématique à traiter telle catégorie est en jeu et réciproquement, on va chercher si telle catégorie peut enrichir la résolution de la problématique.

L’article s’attarde sur les principales catégories ou natures de données du plan de l’ingénierie des données : données transactionnelles, données référentielles, données opérationnelles, données événementielles, données décisionnelles, données historisées, données synthétiques, données d’observation, données de trace, données sensibles, données individuelles / agrégées, données corrompues, données géographiques, données temporelles.

L’idée pratique est de balayer systématiquement ces catégories lorsque l’on pratique la conception d’un système de données.

D’autres catégories sont simplement citées tant la variété des données est grande.

Introduction

Lorsque des acteurs parlent de données, rapidement on en vient à les qualifier sous différents angles pour mieux les appréhender.

On va qualifier les données suivant leurs caractéristiques, leurs propriétés, leur type, leur valeur, un angle fonctionnel, une finalité, etc.

Cela abouti à une liste qui peut être très longue de natures de données : données structurées, données référentielles, données transactionnelles, données personnelles, données agrégées, données ouvertes, données géographiques, données analytiques, données synthétiques…

On va s’intéresser à ces différentes natures de données :

• En montrant que les distinctions faites des données ont une utilité et non sont pas neutres,
• En illustrant sur quelques membres de cette liste, à quoi cela correspond.

Pour au final se rendre compte que dans cet exercice de qualification, se cache les racines de la conception d’un système de données.

Retour sur la construction d’un système de données

Une données n’est jamais définie en l’air.

Sa définition s’inscrit dans une ou plusieurs finalités issues d’univers de problématiques qu’un système de données doit couvrir. Une finalité constitue un but, conformément à une loi et à une intention humaine.

Ces finalités orientent la façon dont vont naître les données, mais aussi tout leur cycle de vie (traitements, transformation, destruction…).

La démarche de conception d’un système de données (au sens large), consiste en partant d’une finalité, d’identifier les données concernées et de concevoir une implémentation numérique de ces données.

La conception d’un tel système passe par une succession de modèles pour arriver dans l’univers numérique.

Chaque modèle répond à un but de conception de plus en plus opérationnel des données (le dernier modèle correspond aux données actives dans un système numérique).

L’état de l’art, distingue trois grands modèles, un modèle conceptuel, un modèle logique puis pour finir un modèle physique.

1) Le modèle conceptuel, en fonction des finalités, va s’intéresser à la définition des données (concept, domaine de valeur), à leur place dans un espace sémantique (relations avec d’autres données), à identifier les contraintes et les règles de gestion que les données devront respecter tout au long de leur cycle de vie.

2) Le modèle logique va s’intéresser à traduire les éléments du modèle conceptuel en unités logiques qui vont définir la façon dont le cycle de vie des données doit être couvert et conditionner l’implémentation physique (la dernière étape). Ce modèle fait le pont entre le modèle conceptuel (agnostique techniquement) et le modèle physique (celui des capacités et choix techniques disponibles). Dans le modèle conceptuel on s’attache à la définition des données, des transactions… On ne s’attache pas à déterminer comment seront implémentées (mémorisées) les données, ni la façon dont seront assurées les transactions. Cela s’entreprend au niveau du modèle logique.

Celui-ci assure le découplage entre le monde conceptuel métier et le monde physique (technologique et organisationnel), qui vivent à des rythmes différents.

Il est également le support de communication non technique d’une vue de l’architecture qui va être définie, auprès des sponsors et des métiers (l’exemple du viaduc de Millau comme analogie – le modèle conceptuel : mettre en place une solution de continuité de l’A75 en éliminant le point noir de la traversée de Millau, le modèle logique : choix d’un viaduc au-dessus du Tarn selon un tracé (voir les études préliminaires, avec l’option tunnel envisagée – https://fr.wikipedia.org/wiki/Viaduc_de_Millau ), le modèle physique : choix d’édification, hauteur des pylônes, techniques de construction, matériaux…). NB : les propriétés du monde numérique permettent des qualités des modèles différentes du monde physique (par exemple en évolutivité). Les choix du viaduc de Millau sont figés, alors que des choix dans le monde numérique peuvent évoluer.

Sauter ce modèle (ce qui arrive dans une mauvaise conception), amène le risque de dégrader le système de données : dépendance vis-à-vis des choix techniques (portabilité difficile, dépendance éditeur), désalignements (construction d’une structure de données non adaptée aux besoins d’accès aux données, au format de stockage retenu), niveaux de service dégradés (performance, sécurité…), faible capacité d’évolution (couplage fort, abstractions absentes, gestion des relations sans classe de relation). Ce modèle est aussi le lieu de choix structurant de type construction selon une logique décisionnelle, data centric, data mesh par exemple (cf. https://www.datassence.fr/2023/06/02/data-centric-data-driven-data-hub-data-warehouse-data-lake-data-fabric-data-mesh-sauriez-vous-situer-ces-differents-paradigmes-data/ ). Sur l’intérêt du modèle logique voir aussi –  https://www.praxeme.org/thesaurus/aspect-logique/#:~:text=L’aspect%20logique%20se%20pose,vivent%20selon%20des%20rythmes%20diff%C3%A9rents.

3) Enfin le modèle physique est celui des choix technologiques et organisationnels [1] permettant d’implémenter les unités logiques définies dans l’étape précédente.

En synthèse, le modèle conceptuel s’intéresse à ce qui porte le sens des données (leurs définitions, leurs règles, leurs liens, leurs usages), le modèle logique  s’intéresse à ce qui va permettre de manipuler/gérer les données (leur cycle de vie, la façon dont sont organisées les données et leur gestion), enfin le modèle physique s’intéresse à l’implémentation des données et des fonctions supports à leur cycle de vie.

Schéma contenu et responsabilité des différents modèles

La démarche de conception n’est pas que séquentielle en partant du modèle conceptuel vers le modèle physique et en passant par le modèle logique. Elle consiste en une succession de d’allers-retours entre la conception des modèles (on parle de négociation entre modèle). Par exemple l’univers technique peut être contraint et amener à revoir une unité logique, jusqu’à parfois remettre en cause la faisabilité d’un besoin (conceptuel) tiré de l’univers de la problématique. Et réciproquement une capacité technique peut faire émerger un nouveau besoin, de nouvelles données à prendre en compte (à l’exemple de l’IA comme capacité qui amène à considérer de nouvelles formes de données). La qualité de la démarche se traduit par la qualité d’alignement entre les trois modèles (c’est-à-dire avec le minium de pertes, de ruptures, frictions entre modèles : continuité sémantique, respect de normes, continuité de l’existant…). Cela signifie par exemple que le modèle conceptuel va bien entendu être naturellement issus d’une analyse de l’univers de la problématique à traiter, mais également du résultat des négociations (arbitrages) avec le modèle logique, c’est-à-dire la prise en compte des choix de ce modèle. Souvent cette négociation est occultée, le modèle conceptuel est construit, puis fournit en entrée à l’étape suivante pour produire le modèle logique et n’est pas remis en cause. C’est une erreur qui conduit à une mauvaise qualité du système de données.

La démarche s’applique majoritairement à plusieurs données en même temps du domaine d’un problème à traiter, mais elle reste valide même si on ne traite qu’une seule donnée.

NB : les modèles sont des produits, dont la conception repose sur des principes fondamentaux (procédés), le tout s’inscrivant dans une démarche (un processus) de conception [2]. Remarque : la démarche agile est un type de processus (elle n’est pas la seule), mais elle est souvent mal appliquée par la minimisation (voire l’absence) des parties négociations entre modèles.

Schéma générique de la démarche de construction d’un système de données

NB : ces modèles relatifs à l’univers du problématique à traiter (une finalité, un domaine métier…) doivent s’inscrire dans une vision plus large d’architecture d’entreprise (respect de normes-réglementations, politiques de données d’entreprise, standards). On parle de passage à l’échelle des données et de leur gestion.

---

[1] Composants techniques et composants organisationnels (une part de la traduction du modèle logique peut reposer sur des tâches manuelles – exemple du rôle de data steward).

[2] Réf PRO3 – Praxeme – https://www.praxeme.org/thesaurus/schema-pro3/  – à voir aussi ces notions autour de l’approche DDD Domain Driven Design

L’apport des différentes natures de données dans la façon de concevoir les modèles

Tout au long de la démarche de modélisation et pour la faciliter (maîtriser la complexité), on va chercher à qualifier les données. Cette qualification va permettre de regrouper les données par nature en fonction de buts, problématiques à traiter, c’est-à-dire de finalités.

Ces natures de données sont transverses et support (pivot). Elles se retrouvent dans chaque modèle. Elles doivent avoir un sens conceptuel, logique et physique. Elles doivent parler à tous les acteurs de l’univers de la problématique (acteurs métier), à ceux de l’univers techniques (acteurs IT), en passant par des acteurs data (exemple un data scientist). Elles sont support à leur analyse, à leur choix de conception et le lieu des négociations entre modèles.

On distingue deux grands plans de qualification des données :

– des natures de données  qui relèvent de la connaissance du domaine et de son activité (organisation, opérations…),

– et des natures de données qui relèvent de la maîtrise des données (au sens gestion), de leur cycles de vie.

Ces deux plans sont classiques dans le monde de la conception logicielle. Le premier est porté par les analystes (analystes métier, data analyst). Le second est porté par les ingénieurs logiciels ou ici plus précisément les data engineers.

Les natures des données de ces deux plans s’articulent, s’alignent, se recouvrent et se complètent. Les natures de données du domaine de connaissance vont devoir être gérées en faisant appel à des qualifications du domaine de la maîtrise des données.

La frontière entre les deux plans est poreuse. Par exemple les données transactionnelles peuvent aussi bien être abordées par le plan de l’univers de la problématique à traiter que par le plan de la maîtrise des données.

Un même ensemble de données peut relever de plusieurs qualifications, natures de données.

L’exercice de conception du système de données va consister à utiliser ces deux plans pour construire les modèles vus dans le § précédent.

Schéma générique de contributions des natures de données à la conception des modèles

Comment la qualification des besoins en maîtrise des données contribue à l’effort de modélisation et au final au système de données ?

1) Les données du plan métier vont être projetée sur les différentes natures de données de maîtrise des données (ces données doivent-elles être historisées, quelles sont les données référentielles, ces données relèvent-t-elles de transactions, y-a-t-il des données événementielles à prendre en compte, telles données sont-elles sensibles et de quelle façon, a-t-on besoin de données synthétiques ?…)

2) Le résultat de cette projection va être décliné dans les trois modèles en s’assurant du meilleur alignement possible. Par exemple les données référentielles sont identifiées dans le modèle conceptuel (les acteurs métier doivent maîtriser ce que couvre cet aspect référentiel dans « leurs » données). Elles sont identifiées comme unité logique à part à gérer (avec un cycle de gestion à part). Et le choix de la façon de les implémenter est traduit dans le modèle physique (s’accoster à un référentiel existant, créer un référentiel de toute pièce).

Il faut retenir que les natures de données de maîtrise du cycle de vie des données sont :

– un accélérateur dans la conception des modèles de données, on ne réinvente pas la roue,

– un enrichisseur, en balayant les différentes natures de données, on peut faire apparaître de nouvelles « idées » métier, de nouvelles façon de penser le système de données,

– un facteur qualité dans la conception du système de données, en évitant de découvrir en fin de cycle de conception des contraintes que mettent à mal les besoins métier, dès le départ, on cherche l’alignement entre le modèle métier et le modèle physique en passant par le modèle logique.

Au-delà de la définition d’une donnée, sa nature se caractérise par des capacités, des propriétés, des contraintes de gestion en lien avec son cycle de vie, des scénarios à la fois techniques et organisationnels d’implémentation. Ces éléments permettent d’effectuer les choix de modélisation.

Illustration sur des données historisées, des données événementielles et des données référentielles.

Dans un système faisant appel à la connaissance d’établissements de santé, les utilisateurs ne dispose que de la vision à date courante des établissements. Ils ne disposent pas de l’état des établissements dans le temps suite à des événements (fermeture, ouverture, déménagement, fusion, split…), ni de l’évolution des caractéristiques de l’établissement dans le temps (catégorie de l’établissement, capacité…).

En l’absence de ces données, les statisticiens ont beaucoup de difficulté à produire des analyses comparatives année par année de la situation.

Dans le modèle conceptuel, l’entité établissement est identifiée, ainsi que ses caractéristiques (statut, catégorie, capacité…). Dans ce modèle des événements sont identifiés (type de l’événement, date d’effet…).

Dans le modèle logique, on va s’attacher à structurer la vision conceptuel pour l’adapter à une future implémentation. Avec par exemple le choix de représentation des relations (par une classe dédiée, la mise en place des clés-identifiants primaires-secondaires), l’identification des données de contexte (métadonnées), la mise aux normes des données (adresse, du domaine métier – par exemple HL7 FHIR dans la santé).

Dans le modèle physique, les choix d’implémentation sont effectués pour aboutir au modèle physiques de données (par exemple les tables, les index dans une cible d’un système relationnel).

A partir de ce premier niveau de modélisation, on va balayer les natures possibles des données à considérer. On identifie ici, qu’une partie des données seront des données de nature référentielles, dont certaines seront de nature événementielles et qui pour partie devront être historisées. Cette projection de natures de données sur les données métier, va amener à faire évoluer chaque modèle.

Dans le modèle conceptuel, les données jugées de référence, événementielles et historisées sont bien identifiées (le métier comprend ces distinctions en toute connaissance de cause).

Dans le modèle logique, des unités logiques de gestion de données référentielles, événementielles et historisées sont identifiées (avec la description des fonctions impactant le cycle de vie des données).

Enfin dans le modèle physique, les choix d’implémentation sont affinés : doit-on séparer dans des tables différentes, les données actives, des données historisées ? Doit-on implémenter la construction des événements dans la ½ interface d’alimentation avec un système tiers, ou prendre en charge une part de l’enregistrement des événements par saisie manuelle ? Quelles sont les données de référence qui doivent être exposées et de quelle façon pour l’accostage de systèmes tiers (par API, par export…)…

Des allers-retours sont effectués entre les modèles, des arbitrages sont fait (par exemple toutes les données ne sont pas forcément utiles à historiser). Le but est d’avoir à la fin le meilleure alignement entre les trois modèles et ne pas découvrir trop tard par exemple au moment de l’implémentation que certains événements sont à historiser.

NB : autre exemple illustratif sur lequel on peut appliquer la démarche, l’exemple des données classées sensibles, avec le cas emblématique des coordonnées bancaires qui devront être gérées à part pour des raisons de sécurité.

Dans la suite de cet article, on se propose de parcourir les principales catégories rencontrées dans la maitrise des données.

Un tour d’horizon des principales natures de données par rapport à leur finalité de gestion et leur cycle de vie

Ce tour d’horizon est partiel. Il parcourt les principales natures de données que l’on peut rencontrer dans le cadre du système d’information d’une organisation.

1) Données transactionnelles

Unité logique dont la vocation est de s’assurer qu’un ensemble d’opérations (CRUD) sur les données d’objets conduit à mettre à disposition des données uniquement représentatives d’états valides des objets de l’univers fonctionnel représenté.

Finalité : (opération) passage d’un ensemble de données (support à une transaction) d’un état A à un état B en garantissant la cohérence, c’est-à-dire le respect des états (à un instant T on ne peut pas avoir accès à des données qui représentent un état impossible).

Exemple : un paiement, un virement, une réservation, la suppression de l’enregistrement d’une personne…

Pour un virement, Etat A (compte de départ 100 euros, compté d’arrivée 50 euros) – transaction de virement de 20 euros = opérations de retrait de 20 euros du compte de départ et d’alimentation de 20 euros du compte d’arrivée – Etat B (compte de départ 80 euros, compte d’arrivée 70 euros). Pas d’autres états possibles (par exemple où seule l’opération de retrait aurait été exécutée).

NB : une transaction peut être longue (sur plusieurs mois, exemple – règles juridiques sur le paiement et la possibilité de rétractation ou de paiement fractionné dans le temps).

Repose sur des fonctions de gestion de données (persistance) : ACIDité (atomicité – rollback, cohérence – règles fonctionnelles, isolation – commit de validation, durabilité – permanence des états)

2) Données référentielles

Unité logique référentielle dont la vocation est d’assurer qu’un ensemble d’opérations (CRUD) sur des données conduit à bien associer ces données à des objets de référence de l’univers fonctionnel représenté.

A distinguer : la naissance des données d’identité et de l’identifiant de référence (caractérise la naissance de l’objet de référence) et la naissance des données que l’on doit associer à cet objet de référence (pour le caractériser ou pour y faire référence – relation).

Finalité : faire qu’un ensemble de finalités (usages, buts et opérations associées) soit coordonnés autour d’objets de référence, afin de permettre des opérations nécessitant un appui référentiel ou des opérations de niveau transverse (mobilisant les différentes finalités) et s’appuyant sur ces objets.

Exemple : consolidation de données de différentes finalités (vue 360° personne physique),

Repose sur les principes qui portent un référentiel de données (centralité, stabilité, qualité, unité de sens, interopérabilité)

-> centralité -> unicité sur un périmètre défini (absence de doublons) – autorité/opposabilité (cf. processus de gestion dédié), stabilité -> naissance sous maîtrise d’un processus de gestion dédié (découplé des processus de production – cf. données opérationnelles), qualité – naissance sous contrôle de règles qualité en fonction de la finalité du référentiel, unité de sens – respect de la définition – cf. le concept impliqué dans la définition de la donnée, interopérabilité – associée à un identifiant

3) Données opérationnelles

Unité logique formée de données parties prenantes des pré et post conditions de tâches d’un processus opérationnel.

NB : recoupe l’idée de données administratives obtenues lors d’une opération de gestion, dont la naissance est liée à des « événements » administratifs (ou traitements automatiques liés). Elles servent fondamentalement de support à des processus opérationnels. Exemples : clôture d’une offre d’emploi, immatriculation d’une entreprise.

NB bis : peut comporter des données transactionnelles et référentielles.

Finalité : faire qu’un processus opérationnel puisse se dérouler au travers du déclenchement successifs de tâches qui pour s’exécuter attendent des données en entrée (précondition) et qui pour se terminer doivent avoir produit un certain nombre de données (postcondition), le tout permettant l’avancement du processus dans le temps.

Repose sur l’identification des données contributives aux pré et post conditions d’exécution des tâches (opérationnelles) d’un processus.

4) Données événementielles

Unité logique de données permettant d’enregistrer les événements amenant un changement d’état sur un objet donné.

Finalité : constat d’événements liés au changement d’état d’un objet (stock en dessous d’un certain seuil, commande traitée, calcul en fin de mois, fusion de deux organisations…) et déclencheurs d’opérations sur des objets (déclenchement d’une livraison par exemple).

NB : peut rejoindre, l’idée de données historisées, dans le sens où l’enregistrement de la succession d’événements sur un objet, permet de reconstituer l’évolution de son état dans le temps.

5) Données décisionnelles

Unité logique basée sur des indicateurs (mesures, agrégats, ratio…insights) calculés à partir de faits (données opérationnelles, données transactionnelles, données d’observation…) et projetées sur des dimensions d’analyse (dont une part fournie par les données référentielles)

NB : comprend les données agrégées, les données de scoring/classement. Couvre les données statistiques.

Finalité : fournir des résultats analytiques support à un processus de décision.

Repose sur le calcul d’indicateurs élémentaires et agrégés (et plus largement de mise en œuvre de calculs dans le cadre de la data science, calculs analytiques : descriptifs, prédictifs, prescriptifs).

6) Données historisées

Unité logique permettant de conserver les changements de valeur dans le temps (avec une date de mise à jour). Peut amener à gérer une date d’effet en plus de la date de mise à jour.

Finalité : permet de reconstituer la valeur de données dans le passé (à une date T). Permet également de définir à partir d’une date (fixée réglementairement par exemple), que telle valeur est devenue active (exemple dans la gestion de taux, possibilité de définir que tel taux est effectif à partir de telle date).

Différentes façons de stocker l’historique sont possibles : instances à date, table historique dédiée (données, valeur avant, valeur après, dates).

Voir aussi données événementielles.

7) Données synthétiques

Unité logique permettant de produire des données dites synthétiques, c’est-à-dire n’ayant pas de rapport unitaire avec une réalité donnée (dans le sens telles données ne correspondent pas aux caractéristiques de tel objet de la réalité et ni ne permettent de reconstituer un objet de cette réalité). Pour certains besoins, le rapport à la réalité est au niveau de l’échantillon couvert par les données synthétiques. Celui-ci doit avoir une représentation statistiques (par exemple) représentatives du monde réel.

Finalité : entraînement des moteurs de calculs IA, ne pouvant pas être entraînés sur des données réelles (non suffisantes, non disponibles), mise au point de traitements de données, de moteurs de calculs de données ne pouvant pas être testés sur des données réelles (problème de confidentialité, de manque de données représentatives). La naissance de ces données s’effectue à partir d’un « modèle » de données réelles (définition et distribution des valeurs) ou d’un modèle théorique.

NB : peut couvrir les données de simulation

Voir aussi : https://www.datassence.fr/category/donnees-synthetiques/ et https://fr.wikipedia.org/wiki/Donn%C3%A9e_synth%C3%A9tique

8) Données d’observation

Unité logique permettant recueillir des données issues d’une posture d’observation. Le champ d’observation est défini à l’avance, les données obtenues par capture ou par enquête sont issues d’un processus et protocole de collecte défini. On fixe les unités / objets à observer, les variables à observer (données), les principes de catégorisation (nomenclatures). Les données obtenues sont une représentation figée à un instant T (le temps de l’observation).

NB : les données d’observation se distingue des données opérationnelles dans le sens où ses dernières sont un produit dérivé (secondaire) d’un processus alors que pour l’observation elles sont une finalité.

NB bis : dans un processus, données opérationnelles et données d’observation cohabitent.

Finalité : recueillir les données permettant de caractériser un objet au sens large (objet physique, objet conceptuel, phénomène, sujet d’enquête…), dans le but de l’étudier, de l’interroger, d’en réaliser une copie numérique (jumeau numérique), de réaliser des analyses statistiques, de data science sur des ensembles d’objets.

NB : couvre les données scientifiques (dans la logique d’observation – versus données de simulation d’un phénomène par exemple) et les données d’enquête (exemple en statistiques). Pour les données d’observation scientifiques se référer à l’ouvrage de Christine L Borgman – Qu’est-ce que le travail scientifique des données ? – https://books.openedition.org/oep/14692

9) Données de trace

Unité logique permettant de conserver la numérique (en données) qui matérialise un contact, une interaction avec un environnement numérique. Par interaction on entend l’usage d’un système numérique (un site web, une application, une interface-un écran, l’appel à un objet connecté)

Finalité : idée de suivi des actions d’un utilisateur (humain ou non) des systèmes numériques. On va tracer au travers de données ses interactions pour ensuite les exploiter. L’exemple le plus connu est bien entendu celui du tracking publicitaire où les traces de nos visites de sites web, qui vont conditionner les publicités qui vont nous être proposées. Le choix du terme de trace n’est pas neutre. Il traduit l’idée que ces données peuvent être interprétées pour analyser des comportements (ce que sous-tend l’idée de trace, traçage).

Dans le cadre numérique, la naissance des données de trace relève d’une posture d’observation intentionnelle (processus et modèle de traçage [1]), définie par les concepteurs des systèmes de trace.

Pour l’utilisateur, ce n’est pas le cas. La façon de naître des données lui est « cachée ». Il génère ces données sans le savoir. Il n’en a pas la décision, la maîtrise [2]. La naissance des traces de son point de vue n’est pas intentionnelle (mais il peut y avoir une idée de consentement).

NB : peut se recouvrir avec l’idée de données historisées.

10) Données sensibles (logique de compliance)

Unité logique permettant de reconnaître comme sensible certaines données et de les gérer en tenant compte de cette spécificité (les mettre à part pour les sécuriser par exemple, ou encore les contrôler par un processus et des règles dédiées). Par sensible on entend concernées par des risques, des enjeux, des contraintes réglementaires.

Finalité : permettre d’exercer les différentes règles de compliance applicables aux données (cf. politiques de données).

11) Données individuelles-unitaires / agrégées

Unité logique de production de données agrégées comme « somme » de données individuelles.

Finalité : attacher des caractéristiques à une population d’objets (exemple revenu global attaché à une population), permettre la fourniture de données sans dévoiler des données individuelles (logique de secretisation), production de statistiques, de reporting consolidé.

NB : rejoint la logique de données décisionnelles.

12) Données corrompues

Production de fausses données, de données biaisées, de données à vocation d’offuscation voire d’usurpation d’identité.

NB : cette catégorie est citée ici plus dans une logique d’analyse des risques.

Finalité : corrompre un traitement numérique en lui fournissant ce type de données (voir pour plus de détail article datassence : https ://www.datassence.fr/2024/02/01/la-fausse-innocence-des-donnees/ ), usage possible également dans une logique de protection (cf. tactique du pot de miel en cybersécurité).

13) Données géographiques

Unité de traitement de la dimension géographique. Peut couvrir, la gestion d’adresses, la gestion de coordonnées géographiques (latitude, longitude ou autre carroyage Insee, DFCI…), de coordonnées de géopositionnement… Capacité à gérer différentes normes et représentation (exemple lambert II étendu ou celles de la directive européenne Inspire)

Finalité : gérer le positionnement géographique d’un objet, par ses adresses (postale, bâti, géopositionnement).

NB : est une dimension pour les données décisionnelles

14) Données temporelles

Unité logique permettant de gérer de l’horodatage, des séries temporelles et chronologiques au travers de données (une mesure par exemple).

Finalité : place dans le temps, dans une chronologie de données (majoritairement des mesures). Permet de suivre l’évolution dans le temps, de reconstituer une vision passées, et comme base pour des projections dans le futur.

NB : est une dimension pour les données décisionnelles, association possible aux données historisées.

Cette liste déjà longue peut continuer avec par exemple les distinctions suivantes :

Données qualitatives et quantitatives,

Données intermédiaires de calcul (par exemple dans l’énergie les données de consommation en kw/h avant d’être fournies valorisées financièrement en euros),

Données externes (dont l’origine ou la naissance n’est pas sous contrôle du système),

Données ouvertes/fermées (rejoint l’idée de données sensibles),

Etc.

---

[1] Qui comme tout dispositif de naissance de données, dépend de choix, de compromis. Et contrairement à ce que peuvent croire certains analystes, n’est pas naturellement/automatiquement aligné avec l’idée de trace (rappel les données ne sont pas donné !). Attention aux usages qui peuvent en être fait (frictions sur l’alignement : données de trace = trace = preuve de).

[2] Il existe des situations ou concepteur et utilisateur sont confondus. Dans ce cas le caractère intentionnel prime. Exemple du quantified self – tracer volontairement ses activités (voir aussi les exemples dans le domaine du sport).

Les natures de données du domaine de la connaissance de l’univers de la problématique à traiter (métier)

Sur ce plan, les données sont catégorisées selon des déclinaisons sectorielles. Les catégories sont issues de l’expertise, la connaissance du domaine traité. Un travail d’élicitation, d’identification des catégories est effectué avec les experts du domaine.

Quelques exemples.

En Marketing :

• Les différentes sources de données
  • Les données dites “zero party data »
  • Les données dites “first party data”
  • Les données dites “third party data”
  • Les données libres
• Les différents types de données en marketing
  • Les données démographiques
  • Les données comportementales
  • Les données psychographiques
  • Les données transactionnelles
  • Les données firmographiques (les données relatives à l’identité d’une entreprise en tant que personne morale)
  • Les données technologiques
  • Les données chronographiques
  • Les données d’intention

En B2C :

• Données identitaires
• Données démographiques
• Données transactionnelles
• Données comportementales

Dans le domaine de l’énergie :

• Données de consommation brutes (volumes, m3 pour le gaz par exemple)
• Données de consommation neutralisées de l’effet climat ou à t° de référence
• Données valorisées financièrement (en fonction du prix du kw/h)

---

Tous droits réservés – datassence.fr. Cet article a été publié originellement sur www.datassence.fr.