Avant de déplacer une donnée, nommez son propriétaire

En 1 minute

Lorsqu'une entreprise réunit ses données en un seul endroit, la technologie ne remplace pas l'accord sur qui répond de chaque ensemble de données. Si un chiffre est faux, qui le corrige, dans quel système et avec quelle priorité convenue ? La pratique du secteur demande trois choses avant de charger une donnée : un propriétaire nommément désigné, un accord écrit entre celui qui produit la donnée et celui qui l'utilise, et quelques règles de qualité vérifiables à chaque chargement. Tout n'exige pas la même rigueur : avec une seule source et un usage limité, vous pouvez commencer léger.

Imaginez une entreprise de distribution de taille moyenne. Elle est fictive, mais elle ressemble à beaucoup d'autres. Elle vend par trois canaux, facture dans un système, tient son stock dans un autre et ses recouvrements dans un troisième. À chaque fin de mois, la Finance et le Commercial arrivent à la réunion avec un chiffre différent de ventes nettes.

La direction décide de régler cela une bonne fois : réunir toutes les données sur une plateforme, avec des tableaux de bord pour chaque service. Le projet démarre bien. Au bout de trois mois, les données arrivent, les tableaux de bord sont beaux et la réunion… est la même qu'avant. Désormais, on discute devant un écran plus grand.

Que s'est-il passé ? Personne n'a posé une question simple avant de déplacer la première donnée : qui en répond ?

Cet article s'adresse à celui qui va approuver — ou a déjà approuvé — un projet pour réunir les données de son entreprise. Il défend une idée : avant de déplacer une donnée, on nomme son propriétaire, on écrit ce qu'elle promet et on décide comment elle se vérifie. La technologie vient après.

Pourquoi les données sans propriétaire se dégradent

Une donnée de ventes est produite par un service (celui qui facture), transformée par d'autres (celui qui rapproche, celui qui monte le rapport) et utilisée par beaucoup. Quand quelque chose ne va pas, chacun peut désigner le suivant. Si personne n'est responsable du fait que cette donnée soit correcte, l'erreur est corrigée à la main dans le rapport, chaque mois, et la suivante réapparaît.

Le secteur nomme ce problème depuis des années. Zhamak Dehghani, dans le texte qui a donné naissance à l'idée de data mesh, propose de répartir la responsabilité des données entre « people who are closest to the data » et de traiter chaque ensemble de données comme un produit, ses utilisateurs étant traités comme des clients [1]. Il n'est pas nécessaire d'adopter toute cette approche pour en retenir l'essentiel : une donnée partagée a besoin de quelqu'un qui en réponde, comme un produit a besoin de quelqu'un qui répond de sa qualité.

Trois choses à définir avant de charger

1. Un propriétaire nommément désigné, pas un service

« C'est la Finance qui le regarde » n'est pas un propriétaire. Un propriétaire est une personne désignée par son nom, dans le service qui produit la donnée ou dans celui qui la comprend le mieux, avec trois responsabilités :

• Dire ce que signifie la donnée. Qu'est-ce qu'une « vente nette » : avec ou sans retours ? Avec ou sans avoirs ? À la date de facture ou à la date d'encaissement ?
• Approuver les changements. Si le système source change une règle, le propriétaire décide si la définition change aussi et prévient ceux qui utilisent la donnée.
• Répondre quand les chiffres ne concordent pas. Quand une vérification échoue, quelqu'un doit répondre, dans un délai convenu.

Le cadre de qualité des données du gouvernement du Royaume-Uni confie au propriétaire de la donnée des décisions comme archiver ou détruire une donnée qui n'est plus utilisée, et demande que l'information sur sa qualité soit conservée avec la donnée [3]. C'est un guide public, non une norme pour votre entreprise, mais le principe vaut tout autant : les décisions sur une donnée ont un responsable.

2. Un accord écrit entre celui qui produit et celui qui utilise

La deuxième étape consiste à mettre par écrit ce que promet cet ensemble de données. Le secteur l'appelle contrat de données : un accord entre celui qui produit la donnée et celui qui la consomme. Le standard ouvert pour ces contrats, l'Open Data Contract Standard (projet Bitol, au sein de la fondation LF AI & Data), les organise en sections : les fondamentaux, la structure des données, les règles de qualité et les canaux de support, entre autres [2].

Pour un comité, un format technique n'est pas nécessaire. Il suffit que l'accord réponde, sur une page :

• Ce qu'il contient : quels champs, avec quelle signification et dans quelle unité.
• À quelle fréquence il arrive : à la clôture de la journée, toutes les heures, au fil de l'eau.
• Quelle qualité il promet : les règles de la section suivante.
• Qui est prévenu quand quelque chose change ou échoue, et sous quel délai cela est traité.

L'accord protège les deux côtés. Celui qui utilise la donnée sait à quoi s'attendre ; celui qui la produit sait ce qu'il ne peut pas changer sans prévenir.

3. Quelques règles de qualité vérifiées à chaque chargement

La qualité ne se déclare pas ; elle se vérifie. Le cadre britannique utilise six dimensions définies par DAMA UK : complétude, unicité, cohérence, actualité, validité et exactitude [3]. Son exemple est utile : 300 élèves, 294 numéros de téléphone d'urgence saisis ; le champ est complet à 98 %, mais cela ne dit pas que les numéros sont corrects. Complet n'est pas la même chose que correct.

Transposées à une entreprise, les premières règles sont souvent simples :

Règles données à titre d'illustration ; celles de votre entreprise, c'est chaque propriétaire qui les définit.

Comme point de départ, choisissez les règles qui couvrent les risques les plus importants de cette donnée — enregistrements manquants, doublons, écarts par rapport à la source —, convenez du moment où elles sont vérifiées et de qui traite un échec, et faites en sorte que le résultat soit vu par celui qui utilise la donnée avant qu'il ne l'utilise.

Quand tout cela est nécessaire et quand il ne l'est pas

Nommer des propriétaires et rédiger des accords coûte du temps à des personnes occupées. Ce n'est pas utile dans tous les cas.

Vous pouvez commencer léger si :

• Vos rapports proviennent d'un seul système, avec un usage limité et un responsable identifié.
• Il s'agit d'une analyse ponctuelle, que personne ne répétera ni n'utilisera pour décider d'une question d'argent.
• Il s'agit d'une expérimentation avec des données de test, sans effet sur l'exploitation.

Même dans ces cas, et davantage s'il y a des données personnelles ou une obligation réglementaire, mettez par écrit ce que signifie la donnée, qui en répond et qui peut la voir.

Il vaut mieux le faire avant de charger si :

• Le même chiffre est construit à partir de données de deux systèmes ou plus.
• Deux services arrivent déjà à la réunion avec des chiffres différents pour la même chose.
• La donnée alimente une décision d'argent, un rapport à une autorité ou un modèle d'IA.
• De nouvelles sources entreront chaque année : chacune multiplie les manières de se tromper.

Ce que nous avons écarté, et pourquoi

• « D'abord on charge tout, ensuite on verra. » C'est la tentation la plus courante, parce qu'elle donne l'impression d'avancer. Le problème est que la gouvernance ajoutée après coup, sur des données déjà utilisées, se négocie avec des services qui ont déjà construit des rapports sur des définitions différentes.
• « Que la DSI soit le seul propriétaire de la donnée. » La DSI peut répondre de l'exploitation, de la sécurité et des accès, mais il ne lui revient pas de décider si un retour se déduit le mois de la vente ou celui de l'avoir. Cette signification, son usage et sa qualité relèvent du métier. Mettez les deux rôles par écrit, ainsi que qui tranche quand ils ne concordent pas.
• « Un comité des données décide de tout. » Un comité aide à résoudre les conflits entre services, mais si chaque changement attend sa séance mensuelle, les gens retournent au tableur. Le propriétaire décide des changements dans son périmètre ; si un changement touche une définition partagée, les accès, la confidentialité ou un autre service, le comité le tranche, avec un responsable et une date.
• « Acheter un outil de catalogue règle la gouvernance. » Un outil conserve les définitions ; il ne les rédige pas et ne les fait pas respecter. Sans propriétaires, le catalogue se remplit de champs sans description.

Cinq questions pour votre prochain comité

1. Qui, nommément, répond de chacun des cinq chiffres les plus discutés en réunion ?
2. Est-il écrit ce que signifie chacun, et son propriétaire l'a-t-il approuvé ?
3. Quelles règles sont vérifiées à chaque chargement, et qui voit le résultat avant l'utilisation du chiffre ?
4. Quand une règle échoue, qui est prévenu et sous quel délai est-ce traité ?
5. Si le système source change une règle, qui l'apprend avant que le rapport ne devienne faux ?

Si la plupart des réponses sont « personne » ou « ça dépend », le projet de données n'est pas encore prêt à grandir.

Par où commencer cette semaine

Prenez les trois ensembles de données derrière les chiffres les plus discutés — les factures, les paiements, le stock, peu importe — et remplissez une fiche pour chacun :

• Propriétaire : nom et service ; et, à part, qui l'exploite à la DSI.
• Qui l'utilise : quels services et pour quelles décisions.
• Ce qu'il promet : ce qu'il contient et à quelle fréquence il arrive.
• Règles : comment on sait qu'il est complet, sans doublons et rapproché de sa source.
• Accès : qui peut le voir.
• Alerte : qui est prévenu quand les chiffres ne concordent pas, et avec quelle priorité c'est traité.

Si une case reste vide, c'est la première tâche, avant d'acheter ou de construire quoi que ce soit.

Ce que fait Hábil

Chez Hábil, nous construisons sur mesure les systèmes et les intégrations qui font circuler les données de votre entreprise, et nous exploitons la plateforme où ces données sont réunies.

Si votre entreprise a besoin d'une seule version de ses chiffres, la proposition se trouve dans Hábil Lake. Nous choisissons ensemble les trois à cinq questions qui vous coûtent le plus aujourd'hui. Pour chacune, nous mettons par écrit de quel système vient chaque donnée, comment elle se calcule et à quoi elle est rapprochée. Chaque chargement est comparé au système source — comptages, sommes, totaux par date — et le résultat reste visible, comme un feu tricolore : ça concorde ou ça ne concorde pas. Chaque table a sa description, son système source et le registre des tables dont elle provient, et les accès se donnent par rôle.

La conversation peut commencer avec vos trois fiches, même à moitié remplies : quelles données, qui les produit et où les chiffres se séparent. Avec cela, nous voyons ensemble par où il convient de commencer. Écrivez-nous sur WhatsApp ; pour protéger vos informations, ne partagez pas par ce canal de données sur vos clients ni sur vos systèmes : nous conviendrons dans la conversation du canal adapté au cas.

Demandez votre première conversation, sans frais.

Consultées le 13 novembre 2026. Chaque référence indique sa fiabilité : élevée (source primaire lue).