En vous lançant dans l'analyse de vos données, il vous faudra les nettoyer de toute erreur. Sinon, le code que vous écrirez pour faire de beaux graphiques (ou autres) plantera. Pire, vos analyses pourront contenir des erreurs si votre échantillon contient des erreurs.
Tous les data analysts ou data scientists vous le diront : on passe malheureusement la majeure partie du temps à nettoyer les données plus qu'à les analyser... c'est frustrant, car le nettoyage n'est vraiment pas la partie la plus captivante !
Donc comme ça, notre jeu de données contient des erreurs ?
En fait, tout dépend de la source de vos données. Prenons deux exemples de sources parmi d'autres : les saisies "à la main" effectuées par des humains, et les capteurs.
Si les données ont été saisies par un humain, alors il y a de fortes chances pour que des erreurs se soient glissées dans la saisie. Par exemple, lorsque quelqu'un tape dans un tableur les résultats d'un sondage rempli sur papier, ou encore lorsqu'un site web contient un formulaire dans lequel l'internaute saisit de fausses données.
Si les données proviennent de capteurs (le système de géolocalisation de votre téléphone, le capteur de vitesse de votre véhicule, la machine qui valide votre billet à l'entrée du bus, etc.), alors il se peut que le capteur se dégrade au cours du temps et ne soit plus étalonné (un thermomètre qui indique 23°C alors que la température réelle est de 25°C) ou bien qu'il ne fonctionne plus (il n'envoie plus de données).
Identifiez les différents types d'erreurs
Prenons l'exemple d'un échantillon de personnes, décrites par plusieurs variables :
Prénom | Date de naissance | Pays | Taille | |
Leila | leila@example.com | 23/01/1990 | France | 1,49 m |
Samuel | samuel_329@example.com | 20/09/2001 |
| 1,67 m |
Radia | choupipoune@supermail.eu | 12 sept. 1984 | Côte d'ivoire | 153 cm |
Marc | marco23@example.com, mc23@supermail.eu | 10/02/1978 | France | 1,65 m |
Heri | helloworld@supermail.eu | 05/03/2008 | Madagascar | 1,34 m |
Hanna | hanna2019@supermail.eu | 01/01/1970 | 24 | 3,45 m |
samuël | samuel_329@example.com |
| Bénin | 1,45 m |
Bon... vous voyez que cet échantillon n'est pas vraiment... propre, n'est-ce pas ?
Tout d'abord, il y a des cases vides pour les variables Pays et Date de naissance. On appelle cela les valeurs manquantes.
Si vous regardez dans la colonne Pays, il y a une case qui contient
24
. Or, 24 n'est absolument pas un pays ! Il s'agit ici d'une erreur lexicale.Ensuite, vous avez peut-être vu qu'un
153 cm
s'est glissé dans la colonne Taille. C'est un problème car toutes les autres valeurs sont données en mètres, et pas en centimètres ! C'est une erreur d'irrégularité, car la variable Taille n'est pas représentée de manière régulière.Marc a 2 adresses e-mail. Ce n'est pas forcément problématique, mais si vous oubliez cela et que vous codez un programme d'analyse en faisant la supposition qu'une personne n'a qu'un seul e-mail, votre programme plantera probablement ! Si vous faites effectivement cette supposition, alors il y aura une erreur de formatage, car
marco23@example.com, mc23@supermail.eu
ne respecte pas le format voulu.Regardez la variable Date de naissance. Il y a également une erreur de formatage : la date de naissance de Radia n'est pas du même format que les autres dates.
Samuel est présent sur 2 lignes. Comment être sûr qu'il s'agit bien du même Samuel ? Par son adresse e-mail, bien sûr ! Il s'agit d'un doublon. De plus, sur les 2 lignes de Samuel, les tailles sont différentes : 1,67 m et 1,45 m, ça c'est une erreur de contradiction.
Hanna mesure 3,45 m. Cette taille est très différente des tailles usuelles des êtres humains : c'est une valeur qualifiée d'outlier, ou valeur extrême, en français.
Gérez les différentes erreurs
Je préfère vous le dire tout de suite, dès que vous devrez nettoyer un jeu de données, il n'y a pas de règle toute faite. Tous les traitements que vous ferez seront en fonction de l'utilisation que vous aurez de vos données. Deux data analysts ne nettoieront pas un même jeu de données de la même manière s'ils ont des objectifs différents !
Pas de règle donc, mais je peux vous donner quelques pistes :
Concernant les valeurs manquantes, c'est l'objet du chapitre suivant. ;)
Pour le pays invalide, il est possible de fixer à l'avance une liste des pays autorisés, puis de supprimer les valeurs qui ne sont pas dans cette liste (ici,
24
n'y sera pas). Une telle liste est souvent appelée dictionnaire.Pour les erreurs d'irrégularité, c'est plus compliqué ! On peut par exemple fixer un format fixe (ici : un nombre décimal suivi du caractère "m"), et supprimer les valeurs qui ne suivent pas ce format. Mais on peut faire mieux, et détecter d'abord dans quelle unité est exprimée la valeur (mètres ou centimètres), puis tout convertir en une même unité.
Pour l'erreur de formatage de la double adresse e-mail, tout dépend de ce que vous souhaitez faire. Si vous n'analyserez pas les e-mails dans votre analyse future, alors pas besoin de corriger l'erreur. Si par contre vous souhaitez connaître la proportion du nombre de personnes dont l'adresse finit par
@example.com
, par@supermail.eu
, etc., alors vous pouvez choisir entre :Prendre la première adresse e-mail, et oublier la seconde.
Garder l'ensemble des adresses e-mail.
Passons à la variable Date de naissance. Aaaaaaah les dates ! :'( Croyez-moi, elles vous donneront toujours du fil à retordre ! Eh oui, il existe d'innombrables formats de date, et chaque pays a sa propre habitude quand il s'agit d'écrire une date (ex. : les Français et les Nord-Américains n'utilisent pas les mêmes formats). En plus de cela, il faut ajouter les problèmes des fuseaux horaires ! Dans notre cas, la plus simple des solutions consiste à supprimer les dates qui ne sont pas au format
jour/mois/année
.Pour le doublon, vous verrez cela dans le chapitre suivant.
Pour l'outlier, c'est également dans le chapitre suivant ! ;)
Cependant, si les erreurs sont nombreuses et de même nature, autant créer un programme informatique qui corrigera les erreurs.
Par exemple, si 60 % des tailles sont données en mètres, 35 % en centimètres et 5 % dans d'autres unités, alors il y a 35 % d'erreurs qui sont de même nature (35 % des valeurs sont en centimètres au lieu de mètres). Autant donc coder quelques lignes de code qui convertiront les centimètres en mètres. Si vous êtes motivé et que le jeu en vaut la chandelle, attaquez-vous aussi aux 5 % restants, mais cela vous prendra beaucoup de temps !
En résumé
Lorsqu'une valeur au sein d'un jeu de données n'est pas renseignée, on parle de valeur manquante.
Une valeur peut également être incohérente par rapport au format ou par rapport à la façon dont la variable a été construite. On parle alors d'erreur lexicale, d'erreur de formatage ou encore d'erreur d'irrégularité.
Certaines valeurs peuvent apparaître en double dans notre jeu de données : ce sont des doublons.
Une valeur extrême, ou outlier, est une valeur bien trop importante ou bien trop faible par rapport à l'ensemble des valeurs d'une variable.
Naturellement, chaque type d'erreur devra être traité spécifiquement, et nous verrons différentes façons de faire cela dans le chapitre suivant !