Organisation, modélisation et interopérabilité des données

Structurer les données à travers les modèles conceptuels, logiques et physiques, tout en garantissant leur cohérence et leur qualité. La leçon traite des datawarehouses, datalakes, API, XML, formats ouverts et dictionnaires de données.

Objectifs de la leçon

Dans cette leçon, l’objectif est de maîtriser les concepts, outils et techniques permettant d’organiser, exploiter et sécuriser les données de l’organisation, plus particulièrement en apprenant à concevoir l’organisation des données et assurer leur interopérabilité afin de structurer et organiser les données dans le système d’information.

Cette leçon s’inscrit dans la continuité des leçons précédentes sur l’urbanisation du système d’information, la gouvernance des SI et la gestion des connaissances. Ici, on se concentre sur un point central : la donnée. Sans donnée bien structurée, il n’y a ni pilotage fiable, ni automatisation robuste, ni interopérabilité durable entre applications.

1. Pourquoi l’organisation des données est-elle un enjeu stratégique ?

Dans une organisation, la donnée n’est pas un simple sous-produit des opérations. Elle constitue une ressource informationnelle qui alimente :

les processus métiers ;
le contrôle de gestion ;
la comptabilité et le reporting ;
la relation client ;
la conformité ;
la prise de décision.

Une donnée mal organisée produit rapidement des effets négatifs :

doublons ;
incohérences entre applications ;
erreurs de traitement ;
difficultés de consolidation ;
pertes de temps dans les rapprochements ;
baisse de confiance dans les tableaux de bord.

Exemple simple

Une entreprise possède :

un logiciel commercial ;
un progiciel de gestion intégré (ERP) ;
un outil de paie ;
un logiciel de comptabilité ;
un outil de gestion de la relation client (CRM).

Si le client « Dupont Industrie » est enregistré sous cinq formes différentes :

DUPONT IND.
Dupont Industrie SAS
DUPONT INDUSTRIE
Client 4587
Dupont Indus

alors les analyses de chiffre d’affaires, d’encours, de relance ou de rentabilité client deviennent fragiles.

Pourquoi ? Parce qu’une organisation ne maîtrise pas seulement ses logiciels ; elle doit maîtriser la structure de ses données, leur qualité, leur circulation et leur interopérabilité.

2. Les notions fondamentales : donnée, information, organisation des données

2.1 La donnée

Une donnée est un élément brut décrivant un fait, un objet, un événement ou une relation.

Exemples :

un numéro de facture ;
une date de commande ;
un code article ;
un montant HT ;
un identifiant client.

2.2 L’information

L’information résulte de l’interprétation de données organisées dans un contexte donné.

Exemple :

donnée : montant de vente de 12 000 € ;
information : « le chiffre d’affaires du client X progresse de 15 % sur le trimestre ».

2.3 L’organisation des données

Concevoir l’organisation des données consiste à définir :

quelles données doivent exister ;
comment elles sont nommées ;
comment elles sont structurées ;
où elles sont stockées ;
comment elles circulent ;
qui les produit et qui les utilise ;
selon quelles règles de qualité, de cohérence et d’accès.

Autrement dit, il ne suffit pas de stocker des données. Il faut les modéliser, les ordonner, les rendre exploitables et interopérables.

3. Structurer les données dans le système d’information

Structurer et organiser les données dans le système d’information suppose de répondre à quatre questions :

Quelles entités faut-il représenter ?
Quelles relations existent entre elles ?
Dans quel format les données sont-elles stockées ?
Comment les systèmes échangent-ils ces données ?

3.1 Les principales entités métier

Dans un SI, les données s’organisent souvent autour d’objets métier, par exemple :

client ;
fournisseur ;
produit ;
commande ;
facture ;
salarié ;
immobilisation ;
centre de coût.

Chaque entité possède des attributs.

Exemple pour l’entité client :

identifiant client ;
raison sociale ;
SIREN ;
adresse ;
catégorie ;
mode de règlement ;
plafond d’encours.

3.2 Les relations entre entités

Les données ne prennent sens qu’au travers de leurs relations.

Exemples :

un client passe plusieurs commandes ;
une commande contient plusieurs lignes ;
une facture est rattachée à une commande ;
un produit appartient à une famille.

Une mauvaise définition des relations entraîne :

des redondances ;
des anomalies de mise à jour ;
des difficultés de restitution ;
des contradictions entre systèmes.

3.3 Les règles de structuration

Une bonne structuration impose notamment :

l’unicité des identifiants ;
la cohérence des formats ;
la stabilité des référentiels ;
la définition de règles de validation ;
la traçabilité des modifications.

4. La modélisation des données : conceptuel, logique, physique

La modélisation des données est le cœur de l’organisation des données. Elle permet de passer d’une vision métier à une implémentation exploitable dans le SI.

4.1 Le modèle conceptuel de données

Le modèle conceptuel de données (MCD) décrit les données indépendamment de toute contrainte technique. Il répond à la question : de quoi l’organisation a-t-elle besoin pour représenter son activité ?

Il met en évidence :

les entités ;
les attributs ;
les associations ;
les cardinalités.

Exemple

Dans une activité de vente :

Client
Commande
Produit
Facture

Relations :

un client passe de 0 à n commandes ;
une commande concerne 1 client ;
une commande contient de 1 à n produits ;
une facture correspond à 1 commande.

Pourquoi le MCD est-il utile ?

Parce qu’il permet de dialoguer avec les métiers sans entrer immédiatement dans des choix techniques. Il sécurise la compréhension commune.

4.2 Le modèle logique de données

Le modèle logique de données (MLD) traduit le modèle conceptuel dans une structure compatible avec un type de base de données.

On y précise notamment :

les tables ;
les clés primaires ;
les clés étrangères ;
les types de relations.

Exemple :

table CLIENT ;
table COMMANDE ;
table LIGNE_COMMANDE ;
table PRODUIT.

Le MLD formalise la manière dont les données seront organisées pour être exploitées par le système.

4.3 Le modèle physique de données

Le modèle physique de données (MPD) correspond à l’implémentation concrète dans un environnement technique donné.

Il précise :

les types de champs ;
les longueurs ;
les index ;
les contraintes d’intégrité ;
les modalités de stockage.

Exemple :

CLIENT_ID : entier ;
SIREN : caractère(9) ;
DATE_COMMANDE : date ;
MONTANT_HT : décimal(15,2).

4.4 Différence entre les trois niveaux

Conceptuel : vision métier ;
Logique : traduction structurée ;
Physique : implémentation technique.

4.5 Pourquoi cette progression est indispensable

Si l’on passe directement au niveau physique, on risque :

de reproduire l’existant sans recul ;
d’intégrer des incohérences métier ;
de rendre les échanges inter-applicatifs difficiles ;
de créer un SI rigide.

La modélisation permet donc de maîtriser les concepts, outils et techniques au lieu de subir les contraintes techniques.

5. La qualité des données : condition de l’exploitation

Organiser les données ne suffit pas ; il faut aussi garantir leur qualité.

5.1 Les dimensions de la qualité des données

On retient généralement :

exactitude : la donnée est correcte ;
complétude : la donnée n’est pas incomplète ;
cohérence : la donnée ne contredit pas une autre source ;
unicité : absence de doublons ;
actualité : la donnée est à jour ;
traçabilité : on sait d’où elle vient et qui l’a modifiée.

5.2 Exemple d’impact

Si le code TVA d’un article est erroné dans le référentiel produit, les conséquences peuvent être :

erreurs de facturation ;
erreurs comptables ;
erreurs de déclaration ;
retraitements manuels coûteux.

5.3 Comment améliorer la qualité des données

Méthode progressive :

identifier les données critiques ;
définir des règles de gestion ;
standardiser les formats ;
mettre en place des contrôles à la saisie ;
dédoublonner ;
attribuer des responsabilités ;
suivre des indicateurs de qualité.

6. Le dictionnaire de données : outil de référence

Le dictionnaire de données est un document ou un référentiel qui recense et décrit les données utilisées dans le SI.

Il précise, pour chaque donnée :

son nom ;
sa définition ;
son format ;
son unité ;
sa source ;
ses règles de calcul ;
ses règles de contrôle ;
son propriétaire ou responsable.

6.1 Pourquoi est-il essentiel ?

Parce qu’il évite les ambiguïtés.

Exemple : le terme « chiffre d’affaires » peut désigner selon les services :

le CA facturé ;
le CA livré ;
le CA encaissé ;
le CA net de remises ;
le CA HT ou TTC.

Sans dictionnaire de données, les tableaux de bord peuvent comparer des indicateurs qui ne reposent pas sur la même définition.

6.2 Exemple simplifié de fiche de dictionnaire

Nom de la donnée : Date de facture
Définition : date d’émission de la facture client
Format : JJ/MM/AAAA
Source : module facturation ERP
Contrôle : obligatoire, non postérieure à la date du jour
Usage : comptabilité, recouvrement, reporting commercial

6.3 Intérêt pour l’interopérabilité

Le dictionnaire de données facilite les échanges entre applications, car il impose un langage commun.

7. L’interopérabilité : faire dialoguer les systèmes

Assurer l’interopérabilité signifie permettre à des systèmes différents d’échanger et d’utiliser des données de manière cohérente.

Ce n’est pas seulement une question technique. C’est aussi une question :

d’organisation ;
de gouvernance ;
de normalisation ;
de compréhension commune.

7.1 Les formes d’interopérabilité

On peut distinguer :

interopérabilité technique : capacité à transmettre les données ;
interopérabilité syntaxique : format d’échange commun ;
interopérabilité sémantique : même signification des données ;
interopérabilité organisationnelle : coordination des processus et responsabilités.

7.2 Exemple concret

Un site e-commerce transmet une commande à l’ERP.

Pour que l’échange soit réellement interopérable, il faut :

un canal d’échange ;
un format commun ;
une structure de message ;
une définition partagée des champs ;
des règles de contrôle.

Si le champ « montant » est TTC dans un système et HT dans l’autre, l’échange fonctionne techniquement mais échoue sémantiquement.

8. Les normes et standards d’interopérabilité

Le programme vise les normes et standards d’interopérabilité comme XML, API et formats ouverts.

8.1 XML

Le XML (eXtensible Markup Language) est un langage de balisage permettant de structurer des données dans un format textuel lisible et hiérarchisé.

Exemple simplifié

<commande>
  <numero>C2025-001</numero>
  <client>Dupont Industrie</client>
  <montantHT>12000.00</montantHT>
</commande>

Pourquoi XML est utile

structure explicite ;
facilité d’échange ;
lisibilité ;
standard largement reconnu.

Limite

XML peut être verbeux et plus lourd que d’autres formats, mais ici l’important est de comprendre sa logique de structuration et son rôle dans l’interopérabilité.

8.2 API

Une API (Application Programming Interface, interface de programmation d’application) permet à une application d’accéder aux fonctions ou aux données d’une autre application selon des règles définies.

Rôle d’une API

Une API permet par exemple :

à un CRM d’interroger l’ERP ;
à un site web de créer une commande dans le SI ;
à un outil décisionnel de récupérer des données opérationnelles.

Pourquoi les API sont stratégiques

Parce qu’elles évitent les ressaisies et permettent des échanges plus automatisés, plus rapides et plus robustes.

Points d’attention

Pour être utile, une API doit reposer sur :

des données bien définies ;
des règles d’accès ;
des formats cohérents ;
une documentation claire.

8.3 Les formats ouverts

Un format ouvert est un format dont les spécifications sont publiques et utilisables sans dépendance excessive à un fournisseur.

L’intérêt est double :

favoriser l’échange entre systèmes ;
limiter l’enfermement technologique.

8.4 Pourquoi les standards comptent autant

Sans standard, chaque application développe sa propre logique. Cela entraîne :

des interfaces spécifiques coûteuses ;
des conversions multiples ;
une maintenance complexe ;
un risque accru d’erreur.

L’interopérabilité suppose donc une discipline de normalisation.

9. Architectures orientées données : datawarehouse et datalake

Le programme mentionne les architectures orientées données, notamment le datawarehouse et le datalake.

9.1 Le datawarehouse

Le datawarehouse est un entrepôt de données structuré, conçu pour l’analyse et l’aide à la décision.

Il se caractérise par :

l’intégration de données issues de plusieurs sources ;
l’historisation ;
la structuration autour d’indicateurs et d’axes d’analyse ;
une orientation décisionnelle.

Usage typique

Construire un tableau de bord de marge par client, produit, zone géographique et période.

Avantages

données consolidées ;
définitions stabilisées ;
analyses fiables ;
bonnes performances pour le reporting.

Limites

nécessite une modélisation rigoureuse ;
moins souple pour des données très hétérogènes.

9.2 Le datalake

Le datalake est un espace de stockage accueillant de grands volumes de données de nature variée, structurées ou non structurées.

On peut y trouver :

fichiers ;
journaux d’événements ;
données issues d’applications ;
données externes ;
documents textuels.

Intérêt

souplesse ;
capacité d’absorption ;
stockage de données diverses avant exploitation.

Risque majeur

Sans gouvernance, un datalake peut devenir un marécage de données : volumineux mais peu exploitable.

9.3 Datawarehouse ou datalake ?

Le choix dépend du besoin.

Datawarehouse : priorité à la fiabilité analytique et à la structuration.
Datalake : priorité à la collecte large et à la diversité des données.

Dans la pratique, les organisations combinent souvent les deux logiques.

10. Méthode pour concevoir l’organisation des données

Voici une démarche opérationnelle, conforme à l’esprit du programme.

Étape 1 : recenser les besoins métiers

Identifier :

les processus concernés ;
les décisions à alimenter ;
les données critiques ;
les usages opérationnels et décisionnels.

Étape 2 : identifier les objets métier

Lister les principales entités :

clients ;
fournisseurs ;
produits ;
commandes ;
factures ;
écritures ;
salariés ;
projets.

Étape 3 : construire le modèle conceptuel

Définir :

entités ;
attributs ;
relations ;
cardinalités.

Étape 4 : traduire en modèle logique

Préciser :

tables ;
clés ;
relations ;
règles d’intégrité.

Étape 5 : formaliser le dictionnaire de données

Pour chaque donnée, documenter :

définition ;
format ;
source ;
usage ;
contrôle.

Étape 6 : définir les règles d’interopérabilité

Choisir :

les formats d’échange ;
les API ou interfaces ;
les référentiels communs ;
les responsabilités de mise à jour.

Étape 7 : sécuriser la qualité

Mettre en place :

contrôles de saisie ;
rapprochements ;
détection des doublons ;
indicateurs de qualité.

Étape 8 : organiser la gouvernance

Attribuer :

les rôles ;
les droits ;
les responsabilités ;
les procédures de modification des référentiels.

11. Cas pratique : structurer les données d’une entreprise de distribution

Prenons une entreprise disposant :

d’un site marchand ;
d’un ERP ;
d’un logiciel comptable ;
d’un outil de reporting.

11.1 Problèmes constatés

doublons clients ;
articles codifiés différemment selon les outils ;
écarts entre ventes commerciales et ventes comptables ;
indicateurs de marge non fiables.

11.2 Analyse

Le problème n’est pas seulement applicatif. Il est d’abord lié à l’organisation des données :

référentiels non harmonisés ;
absence de dictionnaire de données ;
échanges insuffisamment normalisés ;
définitions divergentes des indicateurs.

11.3 Solution structurée

a) Définir les référentiels maîtres

référentiel client ;
référentiel produit ;
référentiel modes de règlement ;
référentiel catégories de vente.

b) Modéliser les relations

un client passe plusieurs commandes ;
une commande contient plusieurs lignes ;
chaque ligne renvoie à un produit unique ;
chaque facture reprend une commande ou un regroupement de commandes.

c) Mettre en place un dictionnaire de données

Exemple :

CA net = ventes HT – remises – avoirs ;
date de vente = date de facturation ;
client actif = client ayant au moins une facture sur 12 mois glissants.

d) Standardiser les échanges

format XML pour certains flux ;
API pour les échanges temps réel ;
identifiants uniques partagés.

e) Alimenter un datawarehouse

Le datawarehouse consolide :

ventes ;
règlements ;
coûts d’achat ;
dimensions client, produit, canal, période.

11.4 Résultats attendus

meilleure cohérence des analyses ;
réduction des retraitements manuels ;
fiabilité accrue des tableaux de bord ;
meilleure capacité de pilotage.

12. Les erreurs fréquentes à éviter

12.1 Confondre stockage et organisation

Accumuler des fichiers ou des bases ne signifie pas organiser les données.

12.2 Négliger la sémantique

Deux champs portant le même nom ne décrivent pas nécessairement la même réalité.

12.3 Laisser chaque application définir ses propres référentiels

Cela produit rapidement des divergences structurelles.

12.4 Oublier le besoin métier

La modélisation n’est pas un exercice purement technique. Elle doit servir les processus et les décisions.

12.5 Créer un datalake sans gouvernance

On stocke beaucoup, mais on exploite peu.

12.6 Multiplier les interfaces spécifiques

Sans standardisation, les coûts de maintenance explosent.

13. Comment relier organisation des données et performance du SI ?

Une bonne organisation des données améliore :

la qualité du reporting ;
la rapidité d’exécution des processus ;
la fiabilité des analyses ;
la capacité d’automatisation ;
la cohérence entre métiers et DSI ;
la sécurité globale du SI.

Elle contribue donc directement à la performance organisationnelle.

Comme vu dans les leçons précédentes sur la gouvernance des SI et l’urbanisation, la donnée est un élément structurant : elle relie applications, processus, tableaux de bord et décisions.

14. Mini-guide de lecture d’une situation professionnelle

Face à un cas d’entreprise, on peut suivre cette grille d’analyse.

14.1 Questions à se poser

Quelles sont les données critiques ?
Quels systèmes les produisent ?
Où se trouvent les doublons ?
Les définitions sont-elles homogènes ?
Existe-t-il un dictionnaire de données ?
Les échanges reposent-ils sur des standards ?
L’interopérabilité est-elle seulement technique ou aussi sémantique ?
Les données servent-elles prioritairement l’opérationnel, le décisionnel, ou les deux ?

14.2 Préconisations possibles

harmoniser les référentiels ;
modéliser les objets métier ;
formaliser un dictionnaire de données ;
définir des règles de qualité ;
standardiser les formats d’échange ;
mettre en place des API ;
distinguer clairement socle opérationnel et socle décisionnel.

15. Points à retenir

L’essentiel

Organiser, exploiter et sécuriser les données de l’organisation suppose une démarche structurée.
Concevoir l’organisation des données revient à définir les entités, attributs, relations, formats, règles et responsabilités.
La modélisation des données se décline en modèle conceptuel, modèle logique et modèle physique.
L’interopérabilité ne se limite pas à l’échange technique : elle implique aussi une cohérence syntaxique, sémantique et organisationnelle.
Les API, XML et formats ouverts facilitent les échanges, à condition que les données soient correctement définies.
Le dictionnaire de données est indispensable pour stabiliser les définitions et éviter les ambiguïtés.
Le datawarehouse sert l’analyse structurée ; le datalake permet de stocker des données variées, mais exige une gouvernance rigoureuse.
La qualité des données conditionne la fiabilité du pilotage.

Mémo final

Vocabulaire clé

Modèle conceptuel de données : représentation métier des entités et relations.
Modèle logique de données : traduction structurée en tables et relations.
Modèle physique de données : implémentation technique dans un système.
Interopérabilité : capacité de systèmes différents à échanger et exploiter des données de manière cohérente.
API : interface permettant à des applications de communiquer.
XML : format structuré d’échange de données.
Format ouvert : format public favorisant l’échange et la pérennité.
Dictionnaire de données : référentiel décrivant les données du SI.
Datawarehouse : entrepôt de données structuré pour l’analyse.
Datalake : espace de stockage de données variées, structurées ou non.

Logique générale

Comprendre le besoin métier.
Identifier les objets métier.
Modéliser les données.
Définir les référentiels.
Formaliser le dictionnaire de données.
Standardiser les échanges.
Contrôler la qualité.
Garantir l’interopérabilité.

En résumé, une organisation ne pilote bien ses activités que si elle structure correctement ses données, les documente, les fait circuler selon des standards et les rend cohérentes entre les applications. C’est à cette condition que le système d’information devient réellement un outil de performance et de décision.