Peut-on vraiment faire confiance à nos données ? La question peut sembler provocante, surtout à l’heure où les organisations investissent massivement dans des plateformes de BI, des projets d’IA et des démarches de transformation data-driven. Pourtant, derrière chaque indicateur, chaque visualisation, chaque modèle, se cache une réalité souvent négligée : la donnée n’est pas naturellement fiable. Elle est produite par des métiers, pour des usages précis, mais elle circule, se transforme, alimente d’autres processus, parfois sans que ses producteurs n’en aient conscience.
Un champ rempli par habitude peut devenir un critère de segmentation stratégique. Une modification locale, jugée anodine, peut provoquer une rupture globale. Et lorsqu’une anomalie survient, ce n’est pas toujours une règle qui est enfreinte… mais un comportement qui dévie.
C’est tout l’enjeu de cet article : comprendre comment une donnée devient de qualité. Poser des standards partagés. Documenter les usages. Et surtout, mettre en place les moyens de contrôle adaptés, en combinant data quality et data observability. Pour ne plus piloter à l’aveugle, et enfin donner à la donnée la fiabilité qu’on lui prête trop souvent par défaut.
Pourquoi parler de standard ?
Dans la plupart des organisations, la donnée est d’abord produite par un métier opérationnel. Ce sont les collaborateurs sur le terrain qui la créent, la saisissent, l’enrichissent… et l’utilisent souvent pour leur propre activité. Mais ils ne sont jamais les seuls à s’en servir. Une même donnée peut ensuite être mobilisée dans des reportings stratégiques, dans des analyses financières, ou encore pour alimenter d’autres systèmes comme un CRM ou une plateforme décisionnelle.
Autrement dit, une donnée créée localement peut avoir des impacts bien au-delà de son contexte initial. Et si le producteur modifie, même légèrement, sa manière de renseigner ou transmettre cette donnée sans prévenir, les conséquences peuvent être considérables. C’est exactement pour cela qu’on parle de standard. Définir un standard, ce n’est pas brider les pratiques métier : c’est au contraire s’assurer que la donnée puisse circuler, être comprise et exploitée de façon fiable, quel que soit l’usager ou le système qui la consomme.
Prenons un exemple concret. Dans une entreprise de gestion immobilière, les équipes chargées de la location de logements avaient pris l’habitude de renseigner le mot « Habitation » dans le champ « Enseigne » de leur logiciel, pour les baux résidentiels. Ce champ n’était pas obligatoire, mais il était systématiquement rempli : une pratique interne devenue réflexe, sans qu’elle ne fasse l’objet d’une consigne formelle. Un jour, un gestionnaire trouve cette saisie inutile : « Une maison n’a pas d’enseigne, pourquoi remplir ce champ ? » D’autres adoptent cette logique. Progressivement, la saisie disparaît pour les baux d’habitation.
Ce que ces équipes ignoraient, c’est que le département Commerce utilisait justement la valeur « Habitation » comme critère principal dans ses analyses Power BI, afin de distinguer les baux commerciaux des baux résidentiels. En l’absence de cette information, les filtres ne fonctionnent plus et les indicateurs calculés sont faussés. Les tableaux de bord affichent des baisses de performance inattendues. Des alertes sont envoyées. Tout laisse croire à un bug technique dans le pipeline… alors qu’il ne s’agit que d’un changement de pratique en amont, non documenté et non anticipé.
Le rôle de la gouvernance des données
C’est justement là qu’intervient la gouvernance des données. Son rôle est d’identifier les usages de chaque donnée, mettre en place des Data Owners capables de recueillir les besoins et de poser des standards nécessaires et documenter la donnée via un data catalog, pour partager la connaissance avec tous les acteurs. Concrètement, cela signifie identifier qui utilise quoi, dans quel but, et avec quelles exigences. Un standard n’est pas une norme figée. C’est un compromis négocié entre ceux qui créent la donnée et ceux qui l’exploitent. Il a pour vocation de fluidifier les échanges, pas de les brider. Mais pour que ce standard soit utile, encore faut-il qu’il soit explicite, c’est-à-dire accompagné de définitions claires. Qu’il soit accessible, via un dictionnaire ou une plateforme commune. Et qu’il soit contrôlé dans le temps, car une donnée vivante évolue au fil des pratiques.
Reprenons notre exemple du champ « Enseigne » utilisé pour les baux d’habitation. Sans gouvernance, ce changement de pratique semble anodin. Mais avec un data catalog bien renseigné, les gestionnaires auraient immédiatement vu que cette donnée était utilisée par les équipes Commerce pour identifier les baux d’habitation dans leurs rapports BI. Ce simple accès à l’information aurait pu ouvrir la porte à une discussion entre les équipes. Plusieurs options auraient pu être envisagées : choisir un autre champ plus approprié pour identifier les baux d’habitation, adapter les rapports pour ne plus dépendre de cette donnée, ou au contraire officialiser la pratique en la transformant en standard.
C’est ainsi que la gouvernance donne du sens à la saisie. Elle relie les données à leurs usages concrets, pour permettre des décisions éclairées, avant qu’un changement local ne devienne une rupture globale.
Assurer le respect de standards : Data Quality et Data Observability
Une fois les standards posés, encore faut-il s’assurer qu’ils sont respectés au quotidien. Pour sécuriser durablement la donnée, deux approches complémentaires s’imposent : la Data Quality et la Data Observability.
La Data Quality repose sur des règles explicites. On définit ce qui est acceptable, et ce qui ne l’est pas. Un montant de loyer ne peut pas être négatif. Un code client doit comporter huit caractères. Un champ obligatoire ne peut jamais rester vide. Ce sont des contrôles déterministes : la donnée est soit conforme, soit non conforme.
Quant à la Data Observability, elle ne repose pas sur des règles, mais sur l’analyse du comportement attendu de la donnée. Par exemple, un fichier qui arrive chaque matin et qui contient généralement entre 10 000 et 15 000 lignes, va soudainement en contenir seulement 2 000. Ou encore, une colonne disparaît par rapport à la veille. Rien, techniquement, n’est « faux ». Et pourtant, tout indique qu’un dysfonctionnement est en cours.
La Data Quality pose des règles. La Data Observability détecte les anomalies de comportement. Cette dernière détecte les anomalies, même quand aucune règle formelle n’a été posée. C’est précisément en combinant les deux qu’une organisation peut réellement faire confiance à sa donnée. Car l’absence d’erreur visible ne signifie pas toujours que tout va bien. Il faut aussi savoir détecter les dérives silencieuses. 
Prenons un exemple concret. Une chaîne de magasins collecte chaque jour les tickets de caisse pour suivre son chiffre d’affaires. La règle de qualité est simple : chaque ticket doit comporter un montant strictement positif. Côté observabilité, on sait que, d’ordinaire, environ 150 000 tickets sont reçus chaque jour.
Dans un premier scénario, on ne fait que de la Data Quality. Tous les tickets du jour sont conformes, tous les montants sont positifs. Aucune alerte n’est déclenchée. Pourtant, le fichier ne contient que 10 000 tickets au lieu des 150 000 habituels. La donnée semble parfaite… mais elle est incomplète. Elle passe tous les contrôles qualité, arrive jusqu’au rapport BI, et là : le chiffre d’affaires chute. L’alerte arrive trop tard, au moment où les décisions doivent être prises.
Dans un deuxième scénario, on ne fait que de la Data Observability. La plateforme détecte immédiatement une anomalie sur le volume : 10 000 tickets au lieu des 150 000 attendus. Une alerte est déclenchée immédiatement. Mais si aucun contrôle qualité n’est en place, on ne verra pas que certains tickets comportent des montants à zéro, des doublons, ou des dates incohérentes. La quantité semble correcte, mais le contenu est incorrect, donc le chiffre d’affaires est faussé sans qu’on ne le voie.
Ce qu’il faut faire, c’est les deux. La Data Quality garantit que chaque ticket est valide individuellement. La Data Observability assure que la donnée, dans son ensemble, reste cohérente avec le comportement habituel. Ensemble, elles forment un filet de sécurité robuste, capable de prévenir à la fois les erreurs visibles et les dérives invisibles. Et c’est à ce niveau d’exigence que la confiance dans la donnée peut réellement s’installer.
La qualité d’une donnée ne se décrète pas. Elle se construit, se documente et se contrôle. Cela commence par la définition d’un standard, qui réconcilie les attentes de ceux qui produisent la donnée et ceux qui la consomment. Ce standard doit ensuite être rendu visible et accessible, à travers une gouvernance claire et un data catalog partagé. Finalement, le respect de ce standard doit être garanti au quotidien, grâce à la complémentarité entre Data Quality et Data Observability. L’une contrôle les règles, et l’autre surveille le comportement. Ce n’est qu’à cette condition que la donnée peut devenir réellement fiable, réutilisable, et surtout actionnable à grande échelle.
Les experts Cenisis conseillent et accompagnent les entreprises à développer leur stratégie data grâce à un usage éclairé, maitrisé et outillé de leur patrimoine de données. Nos consultants vous accompagnent sur les enjeux Data d’aujourd’hui et de demain. Cenisis anticipe et accentue les perpétuelles évolutions des marchés, des technologies, ainsi que les nouvelles aspirations des citoyens et collaborateurs. Découvrez dès à présent notre approche.
