Voici les nouvelles données. Pourriez-vous le résumer comme Alice l’a fait l’année dernière, et m’envoyer un rapport ?

La fonction publique et les organismes publics du Royaume-Uni publient de nombreux ensembles de données. Ces ensembles de données peuvent être très utiles lors de l’expérimentation d’outils de visualisation et de présentation de données. En tant que consommateurs de données, nous constatons rarement la quantité de travail nécessaire à la préparation de ces ensembles de données, ou la manière dont ils sont utilisés pour prendre des décisions ou comprendre les tendances au sein du pays. Ce travail doit être coordonné par plusieurs personnes, chacune possédant des compétences différentes.

Tout comme les équipes, les logiciels et les données évoluent avec le temps. Les données brutes qui alimentent les ensembles de données ci-dessus, ainsi que tous les produits qui en découlent (rapports, applications, etc.), ne peuvent être collectées et traitées qu’après quelques années – et beaucoup de choses peuvent changer en quelques années. Ainsi, les équipes de ces départements ont besoin d’un moyen de générer de manière fiable ces ensembles de données et produits de données à partir de données brutes nouvellement collectées, suffisamment robuste (ou au moins flexible) pour s’adapter aux changements :

• la qualité des données,
• la structure/schéma des données brutes,
• personnel au sein de l’équipe et restructuration des départements,
• outillage logiciel,
• format ou utilisation des données de sortie.

Il est de plus en plus courant que ce type de traitement de données soit effectué par un
Pipeline analytique reproductible (RAP). Un RAP est un processus largement automatisé écrit en code. L’un des objectifs de l’utilisation des RAP ici est de réduire la quantité d’entrées manuelles et ad hoc dans le traitement des données, de sorte que lorsque vous recevez les mêmes données d’entrée, vous générez les mêmes produits en aval et que le processus fonctionne avec succès et de manière prévisible lorsque de nouvelles données sont fournies. En plaçant les décisions de traitement dans le code, les RAP rendent le traitement des données plus facilement vérifiable et plus transparent.

La fonction publique britannique et le NHS ont des lignes directrices sur leurs objectifs en matière de RAP et sur la manière de créer ces pipelines.

Or, vous ne travaillez peut-être pas pour l’une de ces institutions, et le traitement et l’analyse des données que vous effectuez peuvent ne pas être rendus publics ou soumis à un audit national. Mais si vous faites de la science des données ou du traitement de données dans le cadre de votre travail, les idées entourant les RAP peuvent vous aider à travailler plus efficacement.

Commençons par les bases :

• d’où viennent vos données ?
• où va-t-il ?
• quel est votre outil principal lorsque vous travaillez avec ?
• et qui d’autre dépend de votre travail ou en est également responsable ?

Les lignes directrices RAP pour la fonction publique britannique encouragent l’utilisation d’outils open source, le contrôle de version et l’automatisation. Quels outils devriez-vous choisir, que devriez-vous automatiser et qui doit savoir ou approuver ce que vous faites ?

Si vous avez hérité d’un classeur Excel contenant les données de l’année dernière et que vous devez traiter les données de cette année, vous n’en savez peut-être pas assez sur les processus qui ont eu lieu avant que les données de l’année dernière ne soient copiées dans la feuille de calcul ou sur les ajustements manuels effectués après leur importation (comment les valeurs manquantes ont-elles été traitées, etc.). Vous pouvez automatiser les premières étapes d’ingestion des données.

Si vous avez hérité de scripts SQL qui effectuent des requêtes de base de données et que vous devez copier-coller les valeurs résultantes dans un rapport, vous pouvez automatiser l’étape de génération du rapport.

Si vous disposez d’un ensemble d’étapes d’analyse ou de scripts qui doivent être appelés dans un ordre particulier, ou pour lesquels vous devez modifier manuellement les scripts (en corrigeant les chemins de fichiers, par exemple) pour qu’ils fonctionnent avec une nouvelle version de données brutes, vous pouvez réfléchir à la manière d’orchestrer l’exécution de ces scripts ou à la configuration du projet afin qu’il nécessite moins d’intervention manuelle pour son exécution la prochaine fois. L’édition de code et l’appel de commandes dans un environnement de programmation sont également des processus manuels.

Vous ne pourrez peut-être pas tout automatiser en même temps. Essayez donc de réaliser des gains stratégiques dans les domaines de votre flux de données qui sont les moins clairs ou qui impliquent le plus de saisie manuelle.

La poussée vers l’automatisation nécessite des compétences en programmation et un choix de langage de programmation. En science des données, cela signifie généralement SQL plus R ou Python. Le choix que vous choisirez pour un projet dépend des compétences de votre équipe et de l’infrastructure dont vous disposez. N’utilisez pas votre langage préféré, ni un langage que vous souhaitez expérimenter, si personne d’autre dans l’équipe ne peut réviser votre code ou reprendre le projet à votre place.

L’une des meilleures ressources que j’ai trouvées lors de mes recherches sur cet article de blog était le livre « Construire des pipelines analytiques reproductibles avec R » de Bruno Rodrigues. Ce livre couvre de nombreux sujets mentionnés ci-dessus : comment mettre en place un projet avec contrôle de version, comment générer des rapports automatisés, comment orchestrer ensemble plusieurs processus analytiques. C’est un livre très axé sur R, mais les idées tiennent que vous travailliez en Python ou dans un autre langage.

La reproductibilité en science des données a un pendant de longue date dans la science en général. Si vous rédigez un article scientifique, les données sur lesquelles il est basé et les étapes de traitement des données impliquées doivent être mises à disposition. Mais ils doivent être créés de manière à pouvoir être réutilisés. Si quelqu’un souhaite régénérer vos résultats et peut télécharger vos données et votre code, le code doit être écrit de manière à ce que cela soit garanti. Il ne suffit pas de publier un script sur GitHub : la version précise de tous les scripts utilisés et les données spécifiques au projet doivent être étiquetées ; l’environnement de programmation doit être aussi proche que possible (par exemple, en faisant correspondre la version de R ou de Python utilisée, en utilisant les mêmes versions de tous les packages installés) ; toutes les sources de données de support doivent être épinglées à des versions spécifiques, etc.

Pour nous cependant, les RAP visent davantage à garantir que le traitement des données est prévisible et transparent, et que les processus peuvent être réutilisés ultérieurement et avec des données mises à jour. Votre équipe devra peut-être améliorer ses compétences en programmation ou sa connaissance de votre environnement de programmation pour profiter d’une automatisation améliorée. Mais cela réduira le nombre de tâches manuelles répétitives, simplifiera l’intégration de nouveaux membres de l’équipe et facilitera la maintenance.

De plus, automatiser des choses est vraiment amusant.

Pour les mises à jour et les révisions de cet article, consultez le message original

En rapport