Construire des tableaux de bord dynamiques au service de l’open data et de la collectivité : l’exemple d’Issy-les-Moulineaux

En 2012, la ville d’Issy-les-Moulineaux s’est lancée dans l’open data en ouvrant un portail. Progressivement, des jeux de données ont été publiés et la ville souhaite aujourd’hui maximiser leur utilisation par les citoyens, les entreprises du territoires et ses agents (ainsi que ceux des autres administrations).

Une des pistes pour faciliter et inciter à l’usage de ses données, a émergé en 2019. L’idée a été proposée par la Direction des Finances et portée par la Municipalité : construire et publier des tableaux de bord sur l’activité des services, qui s’alimentent à partir de données provenant du portail open data. La direction a soutenu l’initiative en la dotant d’un budget.

Dans la plupart des administrations, les différents services maintiennent des tableaux de suivis de leur activité. Sous la forme de fichiers Excel ou de rapports annuels, ils sont partagés à la hiérarchie, et certaines données font l’objet d’indicateurs partagés entre différents services.

Problème : ces tableaux et rapports sont dans des structurations et des formats différents selon les services. Chaque année, les indicateurs sont à recalculer, les données doivent alimenter d’autres tableaux, et donc le travail de mise à jour prend du temps. Les rapports qui en sont issus sont textuels, pourtant les élus ont besoin de chiffres clés, et les services de graphiques pour avoir un aperçu des activités clés de la mairie.

La ville d’Issy-les-Moulineaux s’est alors engagée dans un travail structurant, en lançant un premier projet de standardisation de données, avec comme objectif concret de construire des tableaux de bord partagés et actualisés automatiquement. Le but : doter d’outils d’aide à la décision les décideurs administratifs et politiques, faciliter la remontée des données, éviter les doublons de saisies, et surtout, faciliter la compréhension des données publiques par les élus, les agents et les citoyens, pour qu’ils accèdent en toute simplicité à des indicateurs plus ou moins détaillés sur les services de la ville (ambition déployée par la SEM Issy Média, par la mise en oeuvre de la stratégie open data de la ville et ses efforts de vulgarisation auprès du grand public). Depuis novembre 2020, le tableau de bord est publié à l’adresse suivante : https://data.issy.com/pages/tableaux-de-bord-issy/.

Mais de quelles données parle-t-on pour ces tableaux de bord ?

Sept services pilotes ont été identifiés pour participer à ces premiers tableaux de bord :

• Education
• Finances
• Petite Enfance
• Démocratie Locale
• Etat Civil
• Ville Numérique
• Direction de la Jeunesse.

Les données d’entrée sont variées : effectifs scolaires, coût des repas dans les cantines, dette publique, manifestations culturelles… C’est cette variété de données qui permettra de publier des tableaux de bord et des data visualisations qui reflètent l’activité de la municipalité.

L’objet de cet article est de détailler la méthodologie employée et les différentes difficultés rencontrées pour permettre à d’autres administrations de comprendre quelles sont les étapes nécessaires pour un tel projet en se concentrant sur les aspects de formatage des données.

Prérequis

Commençons par les atouts qui ont facilité le projet :

Premièrement, la ville d’Issy-les-Moulineaux est l’une des villes pionnières de l’open data, avec un portail de données ouvertes depuis 2012. Une grande partie des agents manipule des données, et certains d’entre-eux sont habilités à publier et éditer directement des jeux de données. Une culture des données, et surtout une culture de l’ouverture et du partage de l’information étaient déjà présentes au sein de la mairie.

Deuxième atout : pour ce projet, la consigne donnée aux services était claire : toute donnée est “bonne candidate” à ce stade. Cela laisse ainsi la possibilité de récupérer des données qui ne sont pas standardisées, et permet de ne pas éliminer des sources intéressantes (tableaux de suivi complexes, fichiers et rapports dans des formats difficilement exploitables).

Méthodologie : de l’idéation avec les services au formatage des données

Réunion de lancement

C’est lors de cette réunion, à laquelle tous les agents qui contribuaient au projet ont été invités. Les objectifs ont été détaillés concrètement, et il a été donné pour consigne de ne pas se censurer sur les données à exploiter.

Ateliers avec les services

L’étape suivante, qui a été l’une des plus importantes, consistait en l’animation de sept ateliers avec les services pilotes.

Un premier temps était dédié à une courte formation, rappelant les principes de l’open data et des formats de jeux de données pour qu’ils soient exploitables (par des outils de tableaux de bord notamment). Objectif : mettre à niveau les personnes qui fournissent les données, afin de faciliter le partage des données, dans des formats les plus exploitables possibles (bases de données, fichiers Excel).

Le deuxième temps de l’atelier était consacré au recensement des données disponibles dans le service. Quels sont les tableaux de suivis qui sont déjà partagés entre les agents et avec la hiérarchie ? Quels indicateurs sont utilisés pour mesurer la performance ? Quel est l’historique de ces données, et existe-t-il des problèmes de qualité ?

Enfin, un temps de prototypage du tableau de bord a quant à lui permis de donner une première idée des indicateurs à construire et afficher en priorité.

Objectif : identifier les données les plus intéressantes à utiliser pour les tableaux de bord, et “déminer” les différentes contraints à prévoir (formats difficilement exploitables, données incomplètes, données à contextualiser ou à documenter…).

Collecte des données

Suite à l’atelier, des jeux de données ont été identifiés et un dossier partagé a été mis à disposition des services pour y verser un maximum de fichiers. Aucune contrainte n’a été donnée quant à la nature et à l’agencement des données.

Pour suivre l’avancement de cette collecte de donnée et s’assurer que les tableaux de bord pourront être réalisés, nous avons utilisé Airtable afin de lister toutes les données à collecter et à traiter, permettant de retrouver les sources de données et les fichiers qui ont été ou seront formatés en vue des tableaux de bord.

Formatage des données

Une étape cruciale consiste à transformer les données pour les rendre exploitables. Rappelons que 80% du travail d’un data scientist ou d’un analyste de données consiste à nettoyer et transformer des données.

La collecte des différents fichiers de la part des services nous a permis d’obtenir des tableaux riches en information, mais très disparates en termes de format et de structuration. Voici un exemple (fictif) de tableau collecté.

À partir de cet exemple, nous allons décrire les différentes pratiques “à ne pas faire” pour rendre ce tableau lisible par les ordinateurs, et exploitable en vue d’un tableau de bord. Cet exemple s’appuie sur la présentation de Christophe Libert de la région Ile-de-France sur les bonnes pratiques sur Excel.

À ne pas faire n°1 : une première ligne qui ne correspond pas à un champ précis.

À ne pas faire n°2 : mettre en forme les cellules

Même s’il est usuel et pratique de mettre en forme des tableaux de suivi, lorsqu’il s’agit de constituer un fichier exploitable, la mise en forme n’est pas prise en compte par les logiciels. Seules les données brutes et leur structuration comptent.

À ne pas faire n°3 : insérer deux données de nature différente (ou deux objets) sur une même ligne.

Chaque ligne doit renvoyer vers une donnée de même nature. On ne peut pas afficher un total ou une information sur un contexte général sur une même ligne. Autrement, le logiciel qui exploitera le tableau en déduira qu’il s’agit de cette école en particulier.

À ne pas faire n°4 : fusionner des cellules

Comme évoqué dans le point précédent, vu qu’une ligne doit traiter d’un seul objet, on ne peut pas fusionner des cellules.

À ne pas faire n°5 : séparer les tableaux dans des onglets différents ou dans une même feuille

Différencier les années dans des onglets (feuilles Excel) différents est une pratique courante pour faciliter la lisibilité des tableaux, mais ce ne sera pas lisible dans un CSV qui ne récupère qu’une seule feuille. De même, puisqu’une ligne = un même objet et une colonne = un même champ, séparer deux tableaux est à éviter.

À ne pas faire n°6 : afficher des totaux ou des informations génériques, ou des données qui n’ont pas de lien avec ce jeu de données précis.

En revanche, si des analyses ou des interprétations globales ou partielles sont déjà faites, il est tout à fait possible de les garder dans une deuxième feuille, qui ne sera pas exportée dans le CSV.

Alors à quoi ressemble un CSV de qualité ?
Il s’agit d’un fichier qui a été “mis à plat”, c’est à dire qu’il faut présumer que la machine qui le lira est bête, et qu’il est nécessaire de dupliquer ou répéter chaque objet lorsqu’il a des caractéristiques différentes. Hadley Wickham, statisticien néo-zélandais et directeur scientifique de RStudio, a ainsi défini le principe de tidy data pour désigner des données facilement exploitables par les machines :

Chaque variable doit avoir sa propre colonne, chaque observation doit avoir sa propre ligne, et chaque valeur doit avoir sa propre cellule :

Source

Lorsqu’un objet présente une caractéristique différente d’une année à une autre, on le duplique :

C’est pour cela qu’un CSV de qualité doit représenter les données de la manière la plus fine possible : autant de lignes que possible, pour décrire une évolution ou des différences.

Pour cet exemple, voici le CSV complet qui devrait être créé :

Pour cet exemple, nous n’avions pas la donnée sur le nombre d’élèves par classes, mais si elle existait, il faudrait ajouter autant de lignes que de classes, selon les années, selon les écoles.

Intégrer les données

Une fois que l’on dispose de données formatées, elles sont prêtes à intégrer les outils qui vont générer les data visualisations. Dans le cas d’Issy-les-Moulineaux, les données sont d’abord intégrées sur le portail open data (via la solution OpenDataSoft), et c’est sur ce portail que les data visualisations se “branchent” pour récupérer les données.

Pour ajouter un fichier dans le portail, un jeu de données doit être créé et alimenté par une source (généralement un fichier CSV). Une fois le fichier ajouté, il est nécessaire de compléter les métadonnées (thème des données, informations diverses dans la fiche information du jeu de données). Divers traitements peuvent être nécessaires pour faciliter les data visualisations et l’utilisation des données en général. Par exemple : décrire les champs et le modèle de données, lorsque certains termes sont techniques.

Désormais, et c’est essentiel : le jeu de données devient une source authentique. C’est à dire que c’est le fichier qui est actualisé en premier (par exemple chaque mois ou chaque année, lorsqu’on dispose de nouvelles données), et qui alimente les tableaux de bord et tous les indicateurs, y compris dans les autres services.

De ce fait, il devient nécessaire de définir des garanties autour de ce jeu de données : fréquence de mise à jour, référents ou responsables, exigences de qualité, procédures de back-up ou d’historique, etc…

Les responsables du jeu de données auront pour mission de le mettre à jour, de sorte à ce que les tableaux de bord qui s’alimentent sur ces données soient actualisés automatiquement.

Construire les visualisations

Pour réaliser des visualisations de données, il existe différentes solutions proposées, soit par des prestataires externes qui réalisent les tableaux de bord de A à Z, soit à partir d’outils en ligne. Data wrapper est une solution simple d’utilisation et qui s’alimente à partir de données en ligne.

Pour déterminer les types de visualisations souhaitables pour les données, le Dataviz Project répertorie un ensemble de possibilités, de la plus classique (histogramme simple) à la plus originale ou complexe (attention aux excès d’esthétisme, qui font parfois perdre de la clarté aux dataviz).

Pour en savoir plus : consultez notre support de formation sur les 3 qualités d’une visualisation de données.

Difficultés rencontrées

Des données manquantes pour réaliser les visualisations

Lors de l’atelier de lancement avec les services, des pages de tableaux de bord ont été prototypées pour définir des priorités dans les données à sélectionner et visualiser.

C’est sur cette base que les services ont été sollicités sur les données à fournir pour pouvoir réaliser les dataviz. Néanmoins, une partie des données présélectionnées lors de l’atelier étaient soit indisponibles, soit dans des formats inexploitables, soit manquaient d’historique. Le travail s’est donc concentré sur les jeux de données disponibles, et pourra se poursuivre dans un second temps lorsque l’ensemble des données sera prêt et formaté.

De nombreuses données à traduire pour les rendre compréhensibles

Pour rendre les tableaux de bord lisibles par le plus grand nombre, il est nécessaire de travailler d’abord sur la littératie des données (les rendre compréhensibles). Mais les tableaux récupérés auprès des services, puisqu’ils sont destinés à un usage interne dans leur grande majorité, contiennent souvent des acronymes, des abréviations, et des termes spécifiques aux métiers (termes financiers à expliciter, éléments de langage administratif, etc…). Une partie du temps a donc été réservée à cette “traduction”, essentielle pour préfigurer les tableaux de bord.

Un volume de données à formater important

Pour construire les 7 tableaux de bord, il a fallu formater toutes les données qui les alimentent (cf méthodologie). Parfois il a suffit d’inverser lignes et colonnes, d’autre fois un travail plus conséquent a été nécessaire. Par exemple, certaines données, séparées en différentes feuilles Excel, ont dû être rassemblées, et dans certains cas comportaient des unités de mesures différentes selon les années. Le travail de formatage (comme indiqué dans la méthodologie) a été nécessaire pour la quasi-totalité des données, soit 43 jeux de données à construire pour alimenter les tableaux de bord sur les sept services pilotes.

Un nombre d’indicateurs qui a évolué à la hausse durant projet

A l’origine du projet, il était prévu de créer des tableaux de bord avec trois visualisation par thème, mais ce nombre a rapidement été dépassé suite aux différents échanges avec les services, compte tenu de la richesse des données transmises. L’objectif étant de présenter l’activité des services de manière précise, il a fallu choisir davantage de visualisations et donc de données.

Réplicabilité et mise à jour

Cet exemple est applicable à tous les tableaux existants. Pour permettre la création de tableaux de bord de manière évolutive, trois éléments essentiels sont nécessaires :

Prévoir dès l’origine des fichiers les plus fins possibles

Si les données sont collectées tous les mois, ou tous les jours, pourquoi ne partager qu’une agrégation par année ? Les logiciels (et les tableaux de bord) qui exploiteront les données journalières ou mensuelles auront toujours la possibilité de trier ou agréger par année. L’inverse est impossible : il est donc nécessaire de fournir des CSV avec la plus forte granularité possible.

Si des tableaux d’origine comportent un grand nombre d’informations (par exemple les effectifs des écoles et les prix de la restauration scolaire), il se peut que les données soient trop variées pour faire l’objet d’un seul CSV. Dans ce cas, il sera nécessaire de produire deux ou trois tableaux pour bien séparer les données, que l’on pourra toujours recroiser par la suite, à partir d’une variable commune (l’année par exemple).

Penser les indicateurs sur le long terme

S’il arrive que des données et des indicateurs doivent radicalement changer (un type de subvention qui disparaît, ou un logiciel métier qui évolue), il est recommandé de penser la structuration d’un jeu de données sur la durée. Dans la mesure du possible, les valeurs qui seront mises à jour d’années en années devront décrire un même phénomène, et de la même façon. Objectif : éviter des écarts brusques de valeur, qui ne décrivent pas un phénomène réel mais un changement dans la méthode de collecte, une modification de l’indicateur ou l’impact d’un changement administratif.

Mettre à jour les données régulièrement

Pour qu’un tableau de bord ou un outil de suivi soit utilisé, les données devraient être mises à jour dès qu’elles sont disponibles et validées. Soit les services alimentent directement le jeu de données de manière régulière (tous les ans pour une grande partie des données), soit un automatisme est créé : un logiciel métier envoie automatiquement les nouvelles données à la suite du jeu de données. De cette manière, les erreurs sont moins fréquentes, tout comme les oublis de mise à jour, et évitent les frustrations liées à un tableau de bord obsolète, que l’on ne consultera pas la fois suivante.

Enjeux de transformation et résultats souhaités

Construire des tableaux de bord évolutifs est un projet qui peut sembler technique, ou destiné à une cible réduite, mais c’est justement tout l’inverse : il s’agit d’un réel vecteur de changement de méthode et de partage de l’information, qui bénéficie à toute la collectivité et à ses administrés.

Premièrement, construire des tableaux de bord et des outils de suivi induit un important partage d’informations entre les services. D’une part les tableaux de bord permettent aux agents de comprendre les données grâce à des visualisations intuitives, et d’autre part les données qui servent à les générer pourront être partagées. Ces données, une fois dans un format CSV, pourront plus facilement être croisées dans l’objectif de faire des analyses transversales sur les différentes compétences de l’administration.

Deuxièmement, le fait de travailler sur cet ensemble de données et de les retraiter permet de mettre en lumière des questions de structuration, de qualité et de manières de collecter la donnée. En étant exploitées par des tableaux de bord, les données sont vérifiées et restructurées : une occasion d’établir des règles quant à leur production et leur gestion, pour en garantir leur qualité et leur mise à jour. Un principe nommé “eat your own dog food” ou “mangez votre propre pâté” consiste à utiliser ses propres données, de sorte à ce que les tableaux de bord ne soient pas uniquement destinés aux citoyens, mais aussi aux services eux-mêmes. Et comme les services connaissent parfaitement leurs données, si une erreur se glisse dans l’une des data visualisations, elle sera rapidement corrigée directement dans les données brutes. Et de ce fait, puisque le jeu de données brute concerné est devenu la source unique, cette correction d’erreur profitera à tous les services qui utilisent ces données.

Troisièmement, si les tableaux de bord peuvent être d’abord destinés à l’interne de la collectivité, il n’y a pas de raison de ne pas envisager leur ouverture à tous les publics. Une fois que les données sont structurées et vérifiées, et que les data visualisations sont suffisamment expliquées, les tableaux de bord peuvent être un excellent moyen d’informer les citoyens sur l’activité de leur collectivité, grâce à des données variées, précises et actualisées. L’un des résultats que l’on peut espérer grâce à ce partage d’information, c’est que les services soient moins sollicités par e-mail ou par téléphone par les habitants (et les chargés d’études dans les observatoires et les autres administrations), car ils auront accès à la donnée directement en ligne.

Quatrièmement, ce travail sur la donnée est une étape significative vers l’émergence d’une culture des données au sein de l’administration. Les agents qui contribuent au projet acquièrent ou renforcent des compétences en matière de structuration et de gouvernance des données. Ils sont aussi amenés à utiliser ces tableaux de bord à l’avenir en prenant de plus en plus en compte la donnée comme outil d’aide à la décision.

Curieux du résultat de ce travail de mise en qualité ? Les tableaux de bord d’Issy-les-Moulineaux sont disponibles ici.