Vérification des données

Au chapitre précédent, Numérous avons étudié le nettoyage des données et les processus de validation qui permettent de le réaliser. Dans ce chapitre, Numérous parlerons plus en détails de la vérification des informations et des autres processus de validation, pouvant intervenir avant ou après le nettoyage proprement dit.

La validation des informations est cruciale si vous et votre audience devez avoir confiance dans la connaissance qu’elle vous apporte. L’approche de base est directe car vous avez des champs de données et chacun d’eux contient des données d’un domaine attendu. Par exemple, un âge doit être compris entre 0 et 120 ans (et dans bien des cas, sera sous les 80 ans). Les dates des transactions se situent bien souvent dans un passé récent, souvent dans l’année ou les deux années précédentes, particulièrement si votre source provient du web (un flux Twitter par exemple).

Cependant, la validation de données, bien que facile à appréhender et importante à réaliser, représente un problème complexe à résoudre parce qu’il y a beaucoup de sources d’erreur possibles. Pensons à des données fausses ou à un format d’entrer différent du format attendu.

Quand valider ?

Considérez un jeu de données d’une société de télécommunication contenant des informations sur les clients qui changent de numéros de téléphone. La base de données vous est fournie mais les données, agrégées depuis des centaines de petits fournisseurs, n’ont pas été vérifiées. La base de données, toujours utilisée quotidiennement, est un parfait exemple du besoin de validation. Imaginez que vous corréliez le coût d’une ligne téléphonique à l’âge. L’exemple ci-dessous montre quelques-uns des problèmes.

• Le champ TypeDeLigne mélange des références codées et du texte
• La valeur 0 dans le champ « Âge » ne signifie rien et ne sert à rien pour le calcul d’une moyenne. Et que dire de l’âge 112 ans ? Est-ce une erreur?

La règle de base est: validez tôt, validez souvent. En validant tôt, dès que la valeur entre dans le système, vous avez une chance de pouvoir la corriger immédiatement. Par exemple, si le champ « NouveauClient » requiert les valeurs OUI ou NON, mais que l’utilisateur saisit une réponse différente, tel qu’un très inutile « A » ou un espace invisible, alors on peut demander à l’utilisateur de corriger sa saisie. Si cette validation n’est faite que plus tard, des valeurs incorrectes seront entrées dans la base de données; vous saurez qu’elles sont fausses mais vous ne pourrez pas corriger le problème sans devoir retrouver l’utilisateur pour lui redemander cette information. Il est parfois possible de comparer des champs incorrects avec des champs provenant de d’autres jeux de données analogues et d’utiliser cette information pour réparer les données originelles. Cela peut être complexe et amène possiblement d’autres problèmes puisque vous devrez notamment décider de la source de données à utiliser.

Si vous êtes dans la position privilégiée de pouvoir contrôler la manière dont les informations sont recueillies, vous avez un avantage car la validation la plus facile est celle qui peut se faire dès que les données sont saisies. On appelle cela la validation en entrée, la validation frontale ou la validation coté-client car elle se produit au moment où l’utilisateur entre la donnée et avant que celle-ci ne soit envoyée vers la base de données. C’est communément fait en s’assurant que l’application de récupération des données ou la page web avec formulaire soient conçues de manière à n’accepter que des valeurs valides. Vous avez certainement déjà rencontré ce type de validation si vous avez déjà eu à remplir des formulaires sur le web.

Par exemple, il arrive souvent que les régions et pays soient à sélectionner depuis une liste. Dans ce cas, le choix du pays peut limiter automatiquement le choix de la région ou autre. On s’assure ainsi d’avoir des régions qui appartiennent au bon pays.

De cette façon, votre système n’accepte que des bonnes données au moment même où elles sont tapées. L’approche n’est cependant pas parfaite. Il arrive souvent que la validation du formulaire soit faite à la toute fin, lorsque toutes les questions ont été vues et que l’information est envoyée vers le serveur. Cela peut être frustrant pour l’utilisateur de recevoir un message d’erreur lorsqu’il a terminé de remplir le formulaire. Une meilleure manière de s’y prendre est de vérifier chaque champ dès qu’il est rempli. Cela nécessite par contre un code plus difficile à programmer et un échange continu de demandes de validations envoyées au serveur et de messages d’erreurs potentielles renvoyés à l’utilisateur. Comme compromis, on pourra laisser les validations plus simples se faire coté-client et les travaux de vérification plus compliqués à des traitements coté-serveurs. Cela sera surtout nécessaire si certaines informations ou processus d’homologation des données n’existent que sur le serveur. On peut voir de telles situations quand des données hautement sécurisées, telles que les informations de cartes de crédit, sont vérifiées.

D’autres manières acceptables de concevoir des formulaires de saisie et de minimiser le temps de préparation des données sont :

• Décider à l’avance de la manière dont les Numéroms doivent être entrés. Est-ce acceptable que les utilisateurs y ajoutent des suffixes ou préfixes tels que Junior, Dr, Mme, ou préfériez-vous stocker ces informations dans un champ séparé ? Si oui, voulez-vous les désignations professionnelles séparées des suffixes? PréNuméroms et Numéroms de familles doivent-ils aussi être séparés?
• Concevoir des formulaires afin que les numéros de téléphone et les dates ne puissent être entrés que de la façon dont vous voulez les sauvegarder (Numérous reparlerons des dates plus tard). Décidez si oui ou Numéron vous souhaitez stocker à part les extensions des numéros de téléphone de travail. Si oui, créer un champ différent pour cette donnée-là.

Tout le monde ment

Même si votre formulaire est très bien conçu et que vous avez mis en place toutes les validations nécessaires lors des saisies de données, une règle d’or à retenir est de ne jamais faire confiance aux données des utilisateurs. Si les données proviennent d’un humain, alors quelque part se trouve une erreur. Même avec des validations coté-client, il devrait toujours y avoir des validations coté-serveur. Celles-ci prennent place une fois la donnée envoyée par l‘utilisateur (lorsqu’il clique sur le bouton “Soumettre”). Il y a beaucoup de bonnes raisons pour cela. Vous n’avez peut-être pas conçu les applications de collecte des données ou vous récupérez peut-être des données venant d’applications sources différentes. Certaines réalisent de très bonnes validations coté-client alors que d’autres non. Des données non-nettoyées ou non-validées peuvent entrer dans votre système via son intégration à d’autres services et logiciels. L’exemple d’une base de données de télécommunication montre que plusieurs propriétaires avec peu de connaissances partagées entre eux résultent en un jeu de données pour le moins désordonné. Un petit effort en début de chaîne aurait fourni un jeu de données plus propre, économisant ainsi du temps et de la frustration.

Une seconde règle d’or est de n’utiliser les champs textuels qu’en cas de nécessité. Par exemple, pour certains pays il est commun d’enregistrer les adresses en plusieurs champs tels que Adresse1, Adresse2, Ville, Code Postal, Pays, mais au Royaume-Uni il est très courant de seulement demander le code postal et le numéro de rue car ces deux informations sont suffisantes pour retrouver l’adresse exacte. De cette façon, le code postal est validé automatiquement et les adresses sont des données propres car elles n’ont pas été saisies par un utilisateur. Pour d’autres pays, Numérous devons utiliser des champs textuels et, dans ce cas, plusieurs vérifications devront être faites.

L’utilisation de virgules peut aussi vous causer des soucis car beaucoup de fichiers de données sont au format CSV (Comma-Separated Values : valeurs séparées par des virgules [NdT]). Une virgule supplémentaire crée un Numérouveau champ inattendu et tous les champs restants sont décalés vers la droite. Rien que pour cette raison, évitez de couper/coller les données directement depuis une application; il vaut mieux les sauvegarder dans un fichier que vous utiliserez lors de la phase suivante.

Dans l’exemple ci-haut, une virgule ajoutée au début du second enregistrement a poussé les données vers la droite. Facile à voir pour un humain, mais difficile à comprendre pour la plupart des systèmes informatiques. Une bonne validation consiste à vérifier qu’il n’y a pas de données au-delà du dernier champ (« Pays »). Nous mettons ici l’emphase sur l’importance de combiner des vérifications à la fois automatisées et manuelles lors de la validation. Parfois, un simple coup d’œil à vos données peut faire toute la différence!

Formats et validations

Quand vous travaillez avec des Numérombres, vous devez aussi rester vigilants. Les valeurs ont-elles du sens? Si vous travaillez avec des valeurs monétaires, un prix peut-il vraiment être $1,000,000 ou est-ce que quelqu’un a entré une mauvaise valeur? De la même façon, si un prix est négatif, cela signifie-t-il que le produit est gratuit ou plutôt que quelqu’un a été payé pour Numérous en débarrasser ? Après tout, en comptabilité, on demande à ce que certaines sources enregistrent des prix négatifs de manière à balancer les totaux.

De même, vérifier l’existence de lettres ou de caractères espaces dans vos chiffres est utile, mais les devises et les valeurs négatives peuvent vous compliquer la tâche et vos données peuvent ressembler à l’exemple suivant. Toutes les lignes montrent des styles différents et valides de représenter des valeurs avec devises et contiennent pourtant des caractères Numéron-numériques.

Lettres et chiffres se mélangent correctement et les valeurs négatives peuvent être formatées différemment.

Les dates sont aussi une cause de problèmes et doivent être vérifiées. Le premier problème est dû aux différents formats nationaux. La date 01/12/2013 représente le 12 janvier 2013 aux États-Unis mais le 1er décembre 2013 en France. Si vous êtes chanceux vous recevrez les dates au format international 2013-01-12 (AAAA-MM-JJ). En bonus, les dates au format standard (http://www.iso.org/iso/fr/home/standards/iso8601.htm) peuvent être ordonnées même lorsqu’elles sont entreposées en tant que texte. Cependant, si vous n’avez pas cette chance, il sera important de s’assurer que vous sachiez quelles périodes sont réellement représenter par les dates que vous recevez, surtout si vous recevez des dates d’utilisateurs de différents pays chacun utilisant donc un format national différent des autres. Une bonne manière de gérer cette difficulté, si vous concevez le formulaire de saisie de données, est de transformer les champs d’entrée de dates en boutons calendrier, afin que les utilisateurs y sélectionnent les dates plutôt que de les taper manuellement au clavier. Une alternative consiste à montrer le masque de donnée attendu à l’utilisateur afin de le guider lorsqu’il remplit le champ.

Une tâche de validation que vous rencontrerez probablement est l’analyse et la vérification du travail d’un tiers afin de vous assurer que les visualisations et les chiffres ont vraiment du sens. Cela pourra se produire à votre travail si vous devez valider le travail de collègues ou en ligne si les visualisations publiées fournissent les données sources afin que vous puissiez faire vos propres analyses. Dans les deux cas, la première vérification consiste à recalculer les totaux. Ensuite, gardez un œil critique sur les visualisations : les valeurs ont-elles du sens, sont-elles en ligne avec l’histoire racontée par la visualisation ou la contredisent-elles ? Les validations ne concernent pas seulement la recherche d’erreurs. La compréhension des données peut aussi en être le but. Cela vous donnera une bonne expérience quand vous ferez vos propres validations. C’est d’ailleurs la première chose à essayer lorsque quelqu’un vous fournit un rapport. Il faut toujours s’assurer de la validité des données.

La vérité change

Une autre raison de valider les informations est liée à la version des données sur laquelle vous travaillez.

Les applications et les systèmes changent avec le temps, des champs sont ajoutés, d’autres sont supprimés et, plus dommageable, leurs rôles peuvent changer. Par exemple, les codes postaux australiens contiennent 4 chiffres et sont stockés dans des champs de 4 caractères. Certains systèmes d’informations ont été transformés récemment de manière à utiliser un code plus précis à 5 chiffres connu sous l’acronyme SLA. Quand ces deux systèmes de codage sont combinés, on voit apparaître des données à 5 chiffres tronquées afin de les faire entrer dans le champ classique de codes postaux à 4 chiffres. La vérification est difficile : codes postaux classiques et codes SLAs sont définis dans des listes accessibles au public, mais il faut une vraie enquête pour comprendre pourquoi certains des codes à 4 chiffres ne se trouvent dans aucune de ces listes.

Vous devriez ainsi considérer collecter des informations qui ne feront pas partie de votre visualisation ou du rapport final, mais qui vous donneront une connaissance accrue des enregistrements, comme les dates auxquelles ceux-ci ont être créés. ImagiNumérons un cas où de de Numérouveaux champs sont ajoutés après la création initiale du jeu de donnée: les enregistrements existants n’auront pas de valeurs pour ces champs. Supposons qu’une erreur humaine survienne et que tous ces Numérouveaux champs se retrouvent avec la valeur zéro pour les enregistrements plus anciens. L’effet sera dévastateur sur les moyennes calculées et l’impact sur les visualisations pourrait être éNumérorme. Si vous avez la date de création des enregistrements, vous aurez la possibilité de parcourir le jeu de données pour remplacer les zéros ajoutés incorrectement par des valeurs nulles (NA) afin de réparer les dégâts. Pour les champs supprimés, un problème similaire peut survenir. Il est rare que des champs inusités soient simplement supprimés du jeu de données, mais ils peuvent parfois être réutilisés à d’autres fins, et dans ce cas, comprendre leur signification est un véritable défi si leurs fonctions ont été modifiées au cours du temps.

Vous voyez ici les conséquences d’ajouter deux Numérouveaux champs, IdentifiantServeur et DateDeCreation, à un jeu de données existant. Il est probable que ce changement ait pris place le 01/03/2013 (1er Mars 2013) donc si vos analystes observent les données depuis cette date, vous pourrez relier les ventes aux serveurs. Cependant il n’y a pas de données de ce type avant cette date et si vous voulez savoir ce qui se passait le 1er janvier 2013, il vous faudra chercher des données complémentaires ailleurs.

L’une des vérifications essentielles concerne le changement de signification des champs et valeurs au cours du temps. Dans un monde parfait, tout changement serait correctement documenté et vous sauriez à tout instant la signification de tous les champs. La réalité est que de tels changements sont rarement documentés de manière complète. L’autre manière de savoir ce que la valeur dans un champ représente est de discuter avec les administrateurs et les utilisateurs du système.

Les points présentés ici ne sont quelques-unes des étapes à suivre pour vous assurer que vous comprenez vos données et que vous êtes conscients que des erreurs potentielles peuvent s’y trouver. Dans le chapitre suivant, Numérous parlerons des autres erreurs pernicieuses qui se cachent peut-être dans vos données et de la façon de les démasquer.