La donnée a besoin d’un propriétaire opérationnel, pas seulement d’un dictionnaire

Trois définitions du client, aucune personne capable de trancher

Cette perspective rétrospective sur 2019 est écrite et publiée en 2026. Le groupe, les noms et les chiffres qui suivent sont fictifs. Ils permettent d’examiner la responsabilité des données dans un programme CRM et ERP, sans exposer de mission réelle de CYTIZEN. Les références apparues après 2019 sont explicitement utilisées comme éclairage actuel.

Lucie, directrice commerciale, compte 12 400 clients actifs dans le CRM. La finance en trouve 10 900 dans l’ERP et la direction générale reçoit un tableau à 11 600. Chaque équipe possède une définition raisonnable : opportunité ouverte, facture récente ou contrat en cours. Le programme data propose un dictionnaire commun. Le débat se déplace vers la formulation des mots alors que personne ne sait quelle décision l’indicateur doit aider à prendre.

Un propriétaire de données n’est pas seulement le gardien d’une définition. Il doit pouvoir convenir d’un usage, faire appliquer la règle à la création, organiser la correction et traiter les exceptions. Il ne possède pas toutes les données au sens juridique du terme. Sa responsabilité opérationnelle s’inscrit dans les mandats métier, sécurité, protection des données et système.

Partir de la décision que la donnée doit servir

Pour préparer le plan commercial, Lucie veut identifier les comptes avec lesquels l’entreprise peut encore travailler et ceux qui demandent une action de réactivation. La finance veut mesurer des clients ayant généré du chiffre d’affaires sur une période. Ces besoins ne requièrent pas forcément le même indicateur. Chercher un unique nombre « vrai » peut effacer des usages légitimes.

Le programme distingue donc client commercial actif, client facturé et compte contractuellement actif. Chaque mesure précise population, période, événements et exclusions. Un prospect n’est pas transformé en client facturé pour satisfaire le reporting. Les rapprochements servent à expliquer les écarts, pas à imposer un chiffre qui ne répond plus à aucune décision.

La direction générale choisit la mesure utile à son tableau et demande une passerelle entre les populations. Le propriétaire métier accepte cette règle. L’IT indique où sont créés les événements et comment les identifiants relient les systèmes. Le dictionnaire devient une conséquence du choix d’usage, et non un atelier abstrait qui précède toute responsabilité.

Décomposer propriétaire, gestionnaire et opérateur

Le propriétaire répond de la règle et de son adéquation à l’usage. Le gestionnaire de données anime les contrôles, qualifie les défauts et organise les corrections. L’opérateur crée ou modifie les informations suivant les règles. Une même personne peut porter plusieurs fonctions dans une petite équipe, mais les décisions restent distinguées.

Lucie est propriétaire de la définition commerciale ; la finance possède la mesure de facturation. Les équipes conviennent d’un identifiant de correspondance et d’un traitement des cas litigieux. Le responsable CRM peut mettre en œuvre le contrôle, mais ne décide pas seul qu’un client sans facture récente doit disparaître du portefeuille. Le responsable ERP peut expliquer le flux sans devenir le propriétaire de la politique commerciale.

Le sponsor intervient quand un arbitrage traverse les deux directions. Il valide une règle de priorité ou deux mesures explicitement différentes. Sans ce mandat, le gestionnaire de données reçoit les anomalies mais n’a aucun pouvoir de fermer le désaccord. Le programme doit prévoir un délai de décision et un interlocuteur de remplacement, afin qu’un défaut important ne reste pas suspendu au départ d’un expert.

Une fiche de donnée critique remplie

Le défaut a une cause de création, pas seulement une ligne fausse

Le programme rapproche un échantillon de comptes. Un client est créé dans l’ERP à partir d’un formulaire, puis dans le CRM à partir d’un courriel. Le nom diffère légèrement ; aucun identifiant commun n’est transmis. Deux équipes corrigent leurs écrans, mais la nouvelle commande recrée la divergence. Le nettoyage n’a traité que le symptôme.

L’équipe suit la création : qui reçoit le besoin, quelles données sont disponibles, quelle vérification est demandée et quel système attribue l’identifiant ? Elle propose une règle de création unique ou une correspondance contrôlée. Les métiers valident l’impact sur leurs délais et exceptions. Une intégration peut être nécessaire, mais le programme ne suppose pas qu’elle résoudra une définition métier contradictoire.

La correction des données existantes est organisée séparément du changement de processus. Les cas ambigus sont examinés par des personnes habilitées ; une fusion automatique ne doit pas réunir deux entités simplement parce que leurs noms se ressemblent. Les décisions de rapprochement sont traçables, et un échantillon est contrôlé après propagation dans les rapports.

Définir des contrôles qui déclenchent une action

Une règle de qualité contient condition, population, fréquence, responsable et traitement. « Données fiables » n’est pas un contrôle. « Compte facturé sans identifiant de correspondance CRM, recherché chaque semaine » en est un. Le contrôle précise les exclusions pour que l’équipe ne perde pas son temps à expliquer régulièrement des cas autorisés.

Le taux de complétude est nombre de comptes pertinents avec le champ attendu divisé par nombre de comptes pertinents. La cohérence examine des relations : contrat actif avec date de fin passée, commande liée à un compte fermé, correction non propagée. L’unicité utilise une règle de comparaison définie ; elle ne se réduit pas à compter des noms identiques.

Dans le cas pédagogique, 40 comptes sur 2 000 n’ont pas de correspondance, soit 2 %. Le gestionnaire classe ces défauts par cause et impact. Une seule anomalie qui bloque une facture critique peut justifier une action immédiate avant les 39 autres. La mesure globale aide à prioriser, mais ne remplace pas la lecture du risque et du dossier.

Éviter la correction locale qui rend le reporting plus joli

La direction commerciale veut corriger le tableau du comité avant vendredi. Elle peut annoter la mesure et produire un rapprochement temporaire. Elle ne devrait pas modifier silencieusement le reporting pour faire disparaître l’écart, sans corriger la source. Sinon chaque mois recréera la même conversation et le chiffre cessera d’être explicable.

Le propriétaire choisit une référence publiée avec ses limites. Les écarts sont présentés avec leur cause, leur ordre de grandeur et le travail nécessaire pour les fermer. Si un retraitement temporaire est indispensable, sa formule, sa version et sa date de fin sont documentées. Une autre personne doit pouvoir reproduire le calcul sans consulter le collègue qui l’a inventé.

Le programme conserve les changements de définition. Un chiffre passant de 11 600 à 12 100 peut refléter une amélioration de qualité, un nouvel usage ou une activité réelle. Comparer ces valeurs sans note ferait croire à une croissance qui n’existe pas. L’historique devient un outil d’interprétation, pas un embarras à supprimer.

La donnée entre dans la recette métier et dans le run

Une migration traite les doublons, champs manquants et correspondances. La recette vérifie également ce qui se passera après : création d’un client, changement de nom, fermeture, nouvelle relation entre comptes et correction d’erreur. Les contrôles sont exécutés avec les équipes qui exploiteront le processus, et pas uniquement avec l’équipe de conversion.

Le support connaît le propriétaire de la règle et le gestionnaire chargé du défaut. Le ticket contient identifiant, valeur observée, valeur attendue, source, impact et date. Une capture seule peut montrer une erreur, mais ne dit pas quel système doit être corrigé. La procédure précise qui peut modifier et comment le résultat sera contrôlé dans les systèmes dépendants.

La fin du projet ne signifie pas la fin de l’amélioration. Le propriétaire revoit les causes récurrentes, les nouvelles utilisations et les changements de flux. Si le nombre de corrections manuelles ne diminue pas après un nouveau contrôle, l’équipe vérifie que le mécanisme agit réellement à la création. Un contrôle qui détecte sans empêcher ni traiter reste une file d’attente supplémentaire.

Adapter la responsabilité à la nature de la donnée

En pharma, une donnée peut participer à la traçabilité d’un lot, d’un équipement ou d’une opération qualité. Les règles de correction doivent tenir compte des exigences applicables et des procédures approuvées. Un propriétaire commercial ne décide pas du traitement d’une donnée de qualité au seul motif qu’elle est visible dans son reporting.

Dans la finance, l’usage comptable peut imposer une définition et des contrôles spécifiques. Les mesures commerciales restent utiles, mais leurs différences avec les comptes doivent être explicables. Dans l’industrie, une référence article ou équipement peut relier ERP, maintenance et systèmes de site. Une valeur apparemment secondaire peut déterminer si une intervention ou un ordre est exécutable.

Dans la relation client, la donnée personnelle exige aussi des responsabilités de protection, des droits d’accès et une conservation appropriée. Nommer un propriétaire opérationnel ne remplace pas ces fonctions. Le programme relie usage, création, correction et exigences, au lieu d’installer une autorité générique sur tout ce qui porte le mot données.

Le premier résultat est une décision reproductible

Pour commencer, choisir une donnée qui bloque un usage réel. Faire décrire cinq cas nominalement corrects et cinq défauts. Nommer l’autorité sur la règle, le gestionnaire des corrections et le système où l’événement naît. Remplir la fiche, exécuter un contrôle et faire corriger un défaut jusqu’à sa propagation.

Lucie peut alors expliquer pourquoi son nombre diffère de celui de la finance. Elle sait quels comptes doivent être réactivés et quels écarts restent non résolus. Le dictionnaire est toujours utile, mais il porte maintenant un mandat, un processus et des preuves. La donnée n’a pas seulement reçu un nom ; elle a obtenu des personnes capables d’en décider et d’en assurer la qualité dans le travail quotidien.

Sources et méthode

Ces références officielles actuelles éclairent les dimensions de qualité, les responsabilités et la mesure. Le framework publié en 2020 et le modèle de propriété consulté en 2026 sont des repères postérieurs à 2019, explicitement distincts de l’année étudiée. Le récit, la fiche, les exemples de contrôle et les seuils sont originaux. Ils ne remplacent ni les règles comptables ni l’analyse de protection des données.

• GOV.UK — Government Data Quality Framework, publié en 2020, repère complémentaire actuel
• GOV.UK — Data ownership model, référence actuelle consultée en 2026
• GOV.UK — How to set performance metrics for your service

Liens vérifiés le 4 octobre 2026. Les scénarios et seuils proposés dans ce dossier sont pédagogiques ; ils ne décrivent pas une mission client ni un résultat obtenu par CYTIZEN.