Dans un monde idéal, chaque système devrait avoir les niveaux les plus élevés de contrôles de qualité intégrés, mais malheureusement, ce n’est presque jamais le cas.  Il existe un certain nombre de raisons à cela, en voici donc quelques-unes :

Avec l’explosion des échanges de données et des formats hétérogènes, la prise de conscience de l’importance de la Qualité des Données a rapidement augmentée.  Cependant, plus le système est ancien, plus la qualité des contrôles de données est faible.  Les systèmes et environnements anciens sont particulièrement sensibles.  Cela s’explique par le fait que non seulement l’importance de la qualité numérique était historiquement moindre, mais les ressources et la puissance de calcul nécessaires à une mise en œuvre appropriée de tests complets étaient également limitées.

Prenons l’exemple de la saisie d’une date dans un système informatique :

Même lorsqu’il s’agit d’un système moderne, Il est courant de trouver des incohérences tels que des dates très anciennes (sont-ils vraiment devenus clients en 1919 ?), des dates dans le futur, ou simplement des dates non valables (« Inconnu », ou l’omniprésent  » / / « ).  Il existe toutes sortes de situations qui ne sont pas difficiles à imaginer, mais qui peuvent être négligées. Qu’en est-il du séquençage, comme par exemple une marchandise expédiée avant la commande, ou d’autres situations similaires ?  Qu’en est-il du formatage de la date (J/M/A vs M/J/A vs A/M/J), ou simplement des différentes façons de la saisir (barres obliques vs points vs tirets) ?

Les sélecteurs de date constituent une approche moderne de cette problématique, mais peuvent ne pas être disponibles pour les environnements anciens.  Des questions plus difficiles peuvent être les week-ends, les jours fériés et autres, lorsque l’entreprise est fermée.

Les dates ne sont qu’un exemple, mais elles montrent bien le niveau auquel on peut enquêter sur la Qualité des données.  De nombreux éléments de données peuvent avoir des niveaux importants d’incohérence de Qualité des données dans vos systèmes, et pratiquement chaque élément de données offre une possibilité d’amélioration.  Il est également important de se rappeler que l’utilisation que vous faites de vos données évolue avec le temps.  Ce qui était relativement peu important au moment où un système a été mis en place peut devenir décisif pour vos analyses actuelles.  Lorsqu’un système a été mis en place, le fait qu’une transaction ait été enregistrée un jour de fermeture de l’entreprise n’avait peut-être pas d’importance, mais aujourd’hui, il est crucial dans le but d’identifier une fraude.

Être conscient de ce phénomène est un pas vers la prise de conscience de l’importance de la Qualité des données.

Enfin, la Qualité des données peut être coûteuse.  Non seulement il y a un coût associé à la réflexion sur la QD (et à sa mise en œuvre), mais les ressources nécessaires pour la faire appliquer peuvent être également très coûteuses.  Si un processus de production tourne deux fois plus lentement que les résultats des tests de Qualité des données, cela peut avoir des implications significatives pour l’entreprise.

C’est ici que le GIGO entre en jeu.  De mauvaises données peuvent facilement avoir des répercussions sur les résultats que vous trouvez, ou la qualité des décisions que vous prenez, sur la base de ces données.  Comme déjà évoqué, il est très difficile de prévoir à l’avance et avec exactitude quelles erreurs affecteront par la suite vos analyses et prises de décision.

Cela est particulièrement vrai à l’ère dynamique des big data dans laquelle nous nous trouvons aujourd’hui.  Peut-être que le travail de demain sera basé sur le jour de la semaine, ou l’heure de la journée.  Ces données n’auront vraisemblablement pas été testées auparavant, puisqu’il s’agit d’une nouvelle analyse.  Lorsqu’un analyste commence son travail, il peut penser à le tester lui-même (s’il dispose des bons outils), mais s’il se contente de faire confiance aux données et qu’elles sont erronées, les résultats pourraient être compromis.

Étant donné que les données d’entreprise englobent une large variété de systèmes, construits dans des environnements différents, à des moments différents et par des personnels différents, il serait un peu naïf de s’attendre à ce que chaque système ait le niveau approprié de QD de base.  Au lieu de cela, une approche puissante peut consister à tester les données à posteriori.

Tester après coup permet de vous donner l’avantage du recul.  Plutôt que d’anticiper chaque utilisation potentielle de chaque élément de données lors de la mise en œuvre d’un système, vous pouvez concevoir et exécuter de nouveaux tests de QD dès maintenant, et identifier les problèmes de qualité des données qui affectent vos analyses actuelles.  En outre, à mesure que vos besoins d’analyse changent (et par conséquent vos attentes en matière de QD), vous serez en mesure de vérifier ces nouvelles exigences, sans nécessairement recourir à la mise à jour coûteuse du logiciel source.

La réponse aux problèmes découverts variera en fonction de leur gravité.  Vous pouvez choisir d’ignorer le problème, de corriger les données ou même de mettre à jour le système source pour éviter que l’erreur ne se reproduise.  Chaque type d’erreur a un impact unique sur vos analyses, mais la prise de conscience de l’existence d’un problème constitue la première étape.