Notions de base pour travailler avec des données

Il y a au moins trois choses essentielles à savoir avant de commencer un projet de data :

les demandes de données doivent commencer par une liste de questions auxquelles vous souhaitez répondre ;
bien souvent, les données sont désordonnées et doivent être nettoyées ;
les données peuvent comporter des éléments non documentés.

Données désordonnées

Définir les questions auxquelles on souhaite répondre

Par bien des aspects, travailler avec des données, c’est un peu comme interroger une source de chair et d’os. Vous lui posez des questions et vous essayez de la faire parler. Mais de même qu’une source peut seulement donner les informations qu’elle détient, une base de données ne peut apporter que les réponses qu’elle contient. Vous devez donc toujours réfléchir soigneusement aux questions auxquelles vous souhaitez répondre avant même d’acquérir vos données. En gros, vous devez travailler à l’envers. Commencez par lister les questions auxquelles vous souhaitez répondre dans votre article ; déterminez ensuite les données que vous devez obtenir et analyser pour ce faire.

Admettons par exemple que vouliez écrire un article sur les tendances de la criminalité dans votre ville, et que vouliez notamment déterminer à quelles heures de la journée et quels jours de la semaine divers types de crimes sont les plus susceptibles de se produire, ainsi que les quartiers qui sont les plus touchés par certains types de crimes.

Votre demande de données doit alors inclure la date et l’heure de chaque crime, le type de crime (meurtre, vol, cambriolage, etc.) ainsi que l’adresse où le crime s’est produit. Les variables minimales pour répondre à ces questions sont donc la date, l’heure, la catégorie du crime et l’adresse.

Mais sachez qu’il y a de nombreuses questions potentiellement intéressantes auxquelles ces quatre variables ne sont pas en mesure de répondre, comme l’origine ou le sexe de la victime, la valeur totale des biens dérobés ou les policiers procédant au plus d’arrestations. Par ailleurs, il se peut que vous ne puissiez obtenir des informations que pour une certaine période, par exemple les trois dernières années, ce qui ne vous permettra pas d’étudier l’évolution de la criminalité à plus long terme. Ces questions peuvent sortir du cadre prévu de votre article, et ce n’est pas grave. Mais vous ne pouvez pas soudainement décider en plein milieu de votre analyse qu’il vous manque des données pour répondre à telle ou telle question.

L’une des leçons à retenir de cet exemple, c’est qu’il est souvent préférable de demander toutes les variables et les entrées de la base de données, plutôt que seulement celles qui répondent à l’angle que vous avez choisi. (Et d’ailleurs, il peut coûter moins cher d’obtenir toutes les données si l’organisme concerné est obligé d’écrire un bout de code pour en extraire une partie.) Vous pourrez toujours trier les données vous-même, et en ayant accès à la base de données complète, vous pourrez répondre aux nouvelles questions qui surviennent au cours de votre enquête ou même produire de nouvelles idées pour d’autres articles. Il se peut que des lois sur la protection de la vie privée ou d’autres règlementations interdisent de divulguer certaines variables, comme l’identité des victimes ou le nom d’informateurs anonymes. Mais une base de données expurgée vaut mieux que rien du tout, du moment que vous comprenez à quelles questions elle peut et ne peut pas répondre.

Nettoyer des données désordonnées

L’un des plus gros problèmes qui se posent avec les bases de données, c’est que vous utilisez à des fins d’analyse des données qui ont été bien souvent recueillies pour des raisons bureaucratiques. En effet, les besoins auxquels répondent ces données et la précision nécessaire pour les satisfaire ne correspondant pas forcément aux vôtres.

Par exemple, une fonction essentielle pour une base de données d’un système de justice pénale est de s’assurer que l’accusé est extrait de la prison le jour de son audition et amené devant le juge. Il importe peu que la date de naissance de l’accusé soit correcte ou que son adresse soit bien épelée. Le système peut tout de même utiliser cette entrée imparfaite pour amener l’accusé devant le tribunal à l’heure prévue.

Mais ces erreurs peuvent fausser les tentatives du datajournaliste de déterminer les tendances de la base de données. Par conséquent, la première grosse opération à entreprendre quand vous obtenez une nouvelle base de données consiste à déterminer son niveau de désordre et à la nettoyer. Pour évaluer rapidement l’hétérogénéité d’une base de données, vous pouvez créer des tableaux de fréquence des variables catégoriques, celles qui devraient présenter relativement peu de variations. Avec Excel, par exemple, vous pouvez utiliser la fonction Filtrer ou Tableau croisé dynamique sur chaque variable catégorique.

Prenez la variable « sexe », un exemple facile. Vous constaterez peut-être que votre champ Sexe contient un mélange de valeurs telles que : Masculin, Féminin, M, F, 1, 0, MASCULIN, FEMININ, etc., voire diverses coquilles. Pour effectuer une analyse par sexe, vous devez standardiser les entrées – décider d’utiliser M et F, par exemple, et remplacer toutes les variations. On retrouve souvent ce genre de problème dans les données de financement des campagnes politiques, où le champ Profession peut lister d’innombrables variations pour le même métier; là encore, il faut uniformiser les champs pour réduire la liste des possibilités.

Le nettoyage de données est encore plus problématique avec les noms propres. Est-ce que « Joseph T. Smith », « Joseph Smith », « J.T. Smith », « Jos. Smith », et « Joe Smith » sont une seule et même personne ? Vous devrez peut-être vérifier d’autres variables, telles que l’adresse, la date de naissance ou d’autres données pour vous en assurer. Des outils comme Google Refine peuvent toutefois faciliter le processus de nettoyage et de standardisation.

Les données peuvent comporter des éléments non documentés

La pierre de Rosette de toute base de données est ce que l’on appelle le dictionnaire des données. En général, ce fichier (pouvant être un texte, un PDF ou même une feuille de calcul) vous dira comment les données sont formatées (texte, délimité ou à largeur fixe, Excel, dBase, etc.), quel est l’ordre des variables ainsi que le nom et le type de données de chaque variable (chaîne de caractères, nombre entier, décimal, etc.). Ces informations vous aideront à importer les données dans le logiciel d’analyse de votre choix (Excel, Access, SPSS, Fusion Tables, une version de SQL, etc.).

L’autre élément-clé d’un dictionnaire des données, c’est la définition de tous les codes utilisés par les différentes variables. Par exemple, le sexe peut être codé de sorte que « 1=Masculin » et « 0=Féminin ». Les crimes ou les diagnostics des hôpitaux peuvent également être codifiés d’une manière spécifique. Sans le dictionnaire des données, il peut être très difficile, sinon impossible d’analyser correctement ces bases de données. Et même avec le dictionnaire des données, des problèmes peuvent se poser. C’est ce qui est arrivé à des journalistes du Miami Herald en Floride il y a quelques années, alors qu’ils analysaient les peines appliquées par différents juges pour conduite en état d’ivresse. Les journalistes ont obtenu les dossiers de condamnation auprès du système judiciaire et ont analysé trois variables contenues dans le dictionnaire de données : la durée d’emprisonnement en maison d’arrêt, la durée d’emprisonnement en établissement pour peine et le montant de l’amende. Ces chiffres variaient sensiblement d’un juge à l’autre, permettant aux journalistes d’écrire un article sur la sévérité et l’indulgence de certains juges.

Mais pour chaque juge, entre un et deux pour cent des affaires ne comportaient ni peine d’emprisonnement, ni amende. Ainsi, le graphique illustrant la distribution des peines pour chaque juge incluait une quantité négligeable d’affaires « sans peine », auxquelles les journalistes n’avaient pas trop prêté attention. Quand l’article a été imprimé, les juges ont crié au scandale : le Herald les accusait d’enfreindre une loi de Floride qui exige que toute personne condamnée pour conduite en état d’ivresse écope d’une peine.

Les journalistes sont donc retournés au bureau du greffier qui avait produit les données et ont demandé ce qui avait pu causer cette erreur. Il s’est avéré que les affaires en question concernaient des personnes indigentes arrêtées pour la première fois. Elles auraient normalement dû recevoir une amende, mais comme elles n’avaient pas d’argent, les juges les avaient condamnées à des travaux d’intérêt général. Il se trouvait que la structure de la base de données avait été créée avant l’entrée en vigueur de la loi exigeant une condamnation obligatoire. Ainsi, tous les greffiers savaient que si les trois variables comportaient des zéros, cela signifiait « TIG ». Cependant, ce n’était pas indiqué dans le dictionnaire des données, et le Herald a dû publier un erratum.

La morale de cette histoire, c’est qu’il faut toujours demander à l’agence qui vous fournit les données si elles comprennent des éléments non documentés, que ce soit de nouveaux codes qui n’ont pas été inclus dans le dictionnaire des données, des modifications de la structure des fichiers ou autre chose. De même, demandez-vous systématiquement en examinant les résultats de votre analyse : « cela a-t-il un sens ? » Les reporters du Herald ont dû concevoir leur graphique en peu de temps et ils étaient tellement focalisés sur les peines moyennes appliquées par chaque juge qu’ils en ont oublié de faire attention aux quelques cas sans peine. Ils auraient dû se demander s’il était normal que tous les juges enfreignent la loi, même dans une très faible mesure.

Steve Doig, Walter Cronkite School of Journalism, Arizona State University

Données mélangées, cachées et absentes

Nous nous sommes bien amusés quand nous avons voulu accéder aux données hongroises sur les subventions de la PAC : toutes les données étaient là, mais dans un énorme document PDF, mélangées avec les données des subventions nationales. Nos programmeurs ont dû travailler pendant des heures avant que les données nous soient d’une quelconque utilité.

Nous avons également passé un moment intéressant avec les données des subventions piscicoles européennes, que les agences de paiement nationales des 27 États membres sont obligées de publier. Voici un extrait d’un article que nous avons écrit sur le sujet : « Au Royaume-Uni, par exemple, le format des données va d’outils de recherche très intuitifs en HTML à des aperçus en PDF ou même des listes de destinataires dans plusieurs formats, dissimulés dans des communiqués de presse. Tout ça au sein d’un seul État membre. Pendant ce temps, en Allemagne et en Bulgarie, on publie des listes vides. Les titres sont là, mais il n’y a pas de données. »

Brigitte Alfter, Journalismfund.eu