Data quality : désigner un responsable de chaque donnée critique

13 novembre 2026

Illustration originale — Data quality : désigner un responsable de chaque donnée critique

Une clôture mensuelle approche. Dans ce scénario illustratif, le directeur financier refuse le chiffre d’affaires consolidé : deux filiales n’appliquent pas la même règle, un correctif ERP a modifié un statut et personne ne sait qui peut trancher. La DSI garantit les traitements ; le métier, la saisie. Pourtant, personne n’assume la définition finale. Une donnée critique existe sans responsable identifiable.

Une donnée sans propriétaire devient une décision sans auteur

La mauvaise qualité ne naît pas seulement d’une saisie erronée. Elle prospère lorsque plusieurs acteurs disposent chacun d’une part de responsabilité, mais qu’aucun ne possède l’autorité nécessaire pour décider. L’équipe applicative maintient le champ, la finance utilise l’indicateur, le contrôle interne vérifie le processus. Dès qu’une incohérence apparaît, chacun examine son périmètre et renvoie l’anomalie au suivant.

Le DSI doit casser cette dilution. Pour chaque donnée critique, il faut distinguer le responsable de son sens, celui de sa production, celui du système qui la porte et celui qui contrôle sa qualité. Le propriétaire métier ne remplace ni l’administrateur de données ni l’exploitant IT. Il arbitre la définition, les usages autorisés, les seuils acceptables et les priorités de correction. Sans cette autorité explicite, la qualité reste une intention collective, donc une obligation pratique pour personne.

Commencer par les décisions que l’erreur compromet

Recenser tous les champs de l’entreprise serait interminable et inutile. La première décision consiste à identifier les éléments dont l’erreur, l’absence, le retard ou la divulgation produirait un impact significatif. Le point de départ n’est pas la base de données, mais la décision ou le processus exposé : payer un fournisseur, déclarer un résultat, livrer un produit conforme, ouvrir un accès, facturer un client ou rappeler un lot.

Pour chaque processus, le dirigeant IT réunit métier, risques, sécurité et responsables applicatifs. Il pose quatre questions : quelle donnée déclenche la décision, qui en fixe la définition, quel système fait foi, et quelle conséquence résulte d’une erreur ? Il obtient une liste courte et défendable. Un numéro de compte bancaire fournisseur, une identité, un statut réglementaire ou un montant reconnu n’appellent pas la même vigilance qu’un commentaire facultatif. La criticité doit être validée par le métier, pas déduite uniquement de l’architecture.

Nommer une personne, pas un comité abstrait

Le choix le plus sensible concerne l’owner. Désigner « la direction financière » ou « le comité data » ne suffit pas. Il faut une fonction nominativement attribuée, avec un suppléant et un mandat documenté. Cette personne n’effectue pas toutes les corrections ; elle assume le choix final dans un cadre défini. Elle peut déléguer l’analyse ou consulter le RSSI, mais pas l’arbitrage sur le sens de la donnée.

Le mandat doit préciser cinq responsabilités : approuver la définition, désigner la source de référence, accepter les règles de contrôle, arbitrer les conflits d’usage et décider du traitement des écarts majeurs. Une matrice de responsabilités adaptée aux décisions complète utilement le dispositif : exécution, autorité, consultation, information, recommandation et contrôle. Le DSI reste responsable de la cohérence des systèmes et des mécanismes de contrôle ; il ne doit pas devenir propriétaire métier par défaut pour combler chaque vide organisationnel.

Rendre la responsabilité exécutable dans les systèmes

Une nomination dans une charte ne corrige aucune donnée. Chaque élément critique doit disposer d’une fiche opérationnelle : définition compréhensible, source officielle, systèmes consommateurs, règle de calcul, fréquence attendue, contrôles, seuils, procédure d’escalade et historique des décisions. Cette fiche doit être reliée aux flux réels, notamment aux interfaces ERP et aux exports manuels qui recréent parfois leur propre vérité.

La démarche avance ensuite par étapes. Premièrement, mesurer l’état initial sans masquer les écarts. Deuxièmement, traiter les causes récurrentes avant d’accumuler des corrections ponctuelles. Troisièmement, placer le contrôle au plus près de la création ou de la modification. Quatrièmement, organiser l’escalade vers l’owner lorsque deux règles métier s’opposent. Enfin, vérifier qu’une correction se propage jusqu’aux usages aval. Une valeur juste dans le référentiel mais obsolète dans le reporting reste une donnée défaillante.

Piloter peu d’indicateurs, mais leur donner une conséquence

Le tableau de bord doit servir à décider, pas à décorer un comité. Quelques indicateurs suffisent : taux de complétude, conformité au format, cohérence entre sources, fraîcheur, nombre d’écarts critiques ouverts, délai de résolution et récurrence après correction. Leur pertinence dépend du contexte. Une donnée peut être complète et pourtant fausse ; un taux moyen satisfaisant peut masquer une anomalie rare mais grave.

Chaque seuil doit donc déclencher une action connue. Un dépassement peut suspendre un flux, imposer une validation manuelle, ouvrir une analyse de cause ou provoquer un arbitrage métier. Le RSSI ajoutera les incidents d’intégrité et les accès incompatibles avec la sensibilité. Le DSI examinera aussi la dette de correction : anomalies anciennes, règles non implémentées, interfaces non supervisées. La tendance importe davantage qu’une photographie flatteuse ; la répétition d’un défaut révèle souvent une responsabilité mal placée.

Arbitrer entre vitesse, contrôle et responsabilité réelle

Les erreurs fréquentes sont prévisibles : lancer un grand nettoyage sans owner, acheter un outil de catalogue avant de décider qui tranche, confondre propriétaire de l’application et propriétaire de la donnée, ou imposer des contrôles si lourds que les équipes recréent des fichiers parallèles. À l’inverse, rechercher une qualité parfaite partout immobilise les projets et dilue l’effort consacré aux données véritablement critiques.

L’arbitrage final du dirigeant IT consiste à accepter un niveau de contrôle proportionné à l’impact, tout en refusant l’anonymat décisionnel. Il peut tolérer une imperfection documentée sur une donnée secondaire ; il ne doit pas accepter qu’une donnée critique reste sans définition, sans source ou sans autorité. Cette discipline rejoint l’approche de gouvernance exposée dans Révolution Numérique ! : relier technologie, responsabilités et décisions concrètes plutôt que traiter la donnée comme un chantier isolé. La réussite se constate lorsqu’un écart survient : l’organisation sait qui décide, sur quelles preuves, dans quel délai et avec quelle trace.