Lorsque vous souhaitez créer un projet d’automatisation basé sur des données, plusieurs points sont à régler en amont avant de s’engager dans le design du processus. Comme il s’agit d’un défi à la fois technique et journalistique, une méthodologie d’évaluation vise à répondre à ces deux challenges.
Ce cadre de travail a été testé dans une application web qui fournit des informations en temps réel sur la qualité de l’air à Bruxelles, laquelle a été développée pour un projet d’enquête plus large sur le sujet. Parce qu’il est plus important de prévenir que de guérir et que tout projet de datajournalisme doit être alimenté par des données précises et fiables, voici quelques moyens simples de vous assurer que les données répondront à vos besoins journalistiques. Les plus gros problèmes ne seront pas à attendre du côté du processus de génération mais bien du côté de celui des données. En préalable, il s’agira de se poser la question de la pertinence journalistique de la démarche et de sa valeur ajoutée.
Indicateurs de qualité
D’un point de vue technique, il s’agit d’évaluer la qualité des données de manière formelle. Le but est de garantir que les données puissent être automatisées une fois collectées. Vous devez vous assurer que vous avez le droit d’utiliser les données et qu’il n’y a pas de problèmes d’encodage, pas de surcharge HTML (si les données sont collectées sur le web), pas de doublons, pas de valeurs manquantes et un étiquetage explicite sans incohérence orthographique. Si les standards ou normes ne sont pas utilisés dans le jeu de données récolter, il s’agira de le corriger. Si des métadonnées existent, dans de nombreux cas, elles permettront d’aider à comprendre les données (à la fois sur le plan des valeurs et sur celui de l’étiquetage).
D’un point de vue journalistique, il faudra se demander s’il s’agit d’une source primaire (pour répondre au critère de fiabilité de la source), et si l’ensemble de données est approprié et complet. La précision et l’exactitude sont deux autres critères à respecter. L’indicateur de «complétude» pourrait être le plus difficile à évaluer, en raison de la valeur NULL qui peut être interprétée de plusieurs manières : les données existent mais ne sont pas connues, les données ne sont pas pertinentes pour la variable, les données sont pertinentes mais inexistantes est égal à zéro.
Ces évaluations peuvent être facilement réalisées en répondant par oui ou par non. Mais il faudra creuser davantage en se demandant, par exemple, quelle est la relation entre le fournisseur de données et la source primaire des données si ce n’est pas celle-ci qui les diffuse (indicateurs de fiabilité et de véracité), et si les données sont compatibles avec l’automatisation tout en considérant les problèmes détectés et les moyens de les résoudre.
Cycle de vie des données et connaissance du domaine d’application
Lorsque les données sont fournies en temps réel, ce cadre peut être complété par la compréhension du cycle de vie des données : les données résultant d’observations empiriques évoluent avec le temps et la manière dont elles évolueront dépendra du domaine d’application. Par exemple, les données sur la qualité de l’air deviennent une moyenne fixe seulement après 24 heures.
Qu’elles soient collectées en temps réel ou non, n’oubliez pas de les enregistrer : l’historique des valeurs peut donner lieu à une bonne histoire. Et si la qualité des données est épouvantable, cela peut aussi en dire plus sur leur gestion par le producteur de données (une bonne histoire pourrait aussi être cachée derrière).
