Architecture du système d’information

La définition de l’architecture du système d’information a consisté en une traduction des pre-miers choix éditoriaux posés par la chercheuse, lesquels ont ensuite été confrontés à la rédac-tion d’Alter Échos, en vue de les adapter à leurs besoins et exigences éditoriales.

L’application automatisée s’est appuyée sur deux modes de collecte des données : en temps réel, s’agissant de générer un bulletin d’information mis à jour à chaque nouveau chargement de la page par l’utilisateur ; et en différé, s’agissant de l’enregistrement des moyennes fixes des taux de polluants, en vue de nourrir une analyse relative à leur évolution dans le temps. Quatre formats de pages ont été définis au cours de cette étape (Figure 3.7) :

— (1) une page "Bulletin du jour", page d’accueil de l’application web ;

— (2) une page relative aux informations de contexte, en vue d’expliquer et de documenter le projet ;

— (3) un tableau de bord présentant une analyse statistique évoluant dans le temps, au fur et à mesure des enregistrements ;

FIGURE3.7 – Première version de l’arborescence de l’application "Bxl’air bot"

Dans la perspective d’une information servicielle, il a été prévu qu’un flux RSS soit également généré de manière automatique – il enregistrait, dans un format structuré, la mise à jour des informations publiées en page d’accueil du site, sur une base horaire – en vue d’alimenter, de manière automatique, un compte Twitter dédié qui donne de la visibilité au projet²⁸.

FIGURE3.8 – Modélisation du flux de données de "Bxl’air bot"

Dans cette architecture, trois types de données ont été prises en compte. Elles ont donné lieu à une première modélisation des flux de données (Figure 3.8) :

— les données relatives aux mesures des différents types de polluants (particules fines, dioxyde d’azote et ozone) publiées sur le site de CELINE ;

— les données relatives à l’indice de qualité de l’air et au niveau d’alerte, diffusées en temps réel sur le site de Bruxelles Environnement et sur celui de CELINE ;

— les données relatives aux observations météorologiques – un facteur influençant la for-mation de certains polluants, comme l’ozone – publiées en temps réel sur le site inter-net de l’Institut Royal Météorologique (IRM). Toutefois, les données de l’IRM n’étaient

pas encore officiellement libérées au moment de la conception de l’application. Deux autres alternatives avaient alors envisagées : les prévisions de l’institut météorologique néerlandais et celles de l’institut météorologique finlandais, accessibles en open data. Toutefois, les prévisions ne correspondent pas forcément aux observations. Dans un souci de précision, il a été décidé de s’appuyer sur les observations diffusées sur le site de l’IRM, compte tenu d’un cadre légal favorable à une libre réutilisation des données produites par les autorités publiques²⁹.

Les modes de narration ont été envisagés de manière complémentaire, l’objet étant de per-mettre une analyse des données qui soit accessible dans une forme textuelle (génération au-tomatique de textes en langage naturel) et graphique (évolution des taux de polluants dans le temps et analyses statistiques). À ce stade de la conception, il était prévu que le textes pré-sentent une synthèse des observations en cours (temps réel) et des observations en matière de dépassement, par type de polluant, des normes européennes et des recommandations de l’OMS. Sur le plan du processus de génération automatique de textes, le traitement des données s’est appuyé sur un système à base de règles ("si... alors... ou si... alors.... ou...") et les textes gé-nérés le sont à partir de gabarits de texte (ou templates) définis en amont.

Les graphiques avaient pour objet de proposer une représentation de l’évolution des données dans le temps. La visualisation de données a été ici envisagée comme un outil de commu-nication de données abstraites par l’utilisation d’une interface visuelle interactive (Manovich 2011). Mais il s’agissait surtout de présenter des données quantitatives, de telle sorte à ce que l’on puisse y percevoir "des tendances ou des anomalies, une constance ou une variation, que

d’autres formes de présentation, textes et tableaux, ne permettent pas" (Friendly 2008). Cette

présentation s’appuyait sur l’usage de statistiques descriptives – nombre de jours de dépasse-ments des normes et recommandations, valeurs maximales par type de polluant, moyennes observées par station de mesure –, dans un tableau de bord pouvant être consultés de manière dynamique.

Définition des standards

Les standards techniques ont été définis en tenant compte d’un travail général de conception de l’application et des bonnes pratiques dans ce domaine. Le parti pris a été de travailler à partir de frameworks³⁰, qui consistent en des espaces de travail modulaires où sont propo-sés des composants prêts à l’emploi. Ceux-ci étaient de deux types : graphiques (pour la réa-lisation d’une interface modulable en fonction de la taille de l’écran de l’utilisateur et pour la

29 Loi du 4 mai 2016, publiée au Moniteur Belge le 3 juin 2016, qui consiste en une transposition de la directive 2013/37/UE du Parlement européen et du Conseil du 26 juin 2013 concernant la réutilisation des

informations du secteur public, source : http://tiny.cc/loi_open_data.

30 "Un framework est un espace de travail modulaire qui consiste en une collection de fichiers (...) et de

conventions permettant le développement rapide d’applications. Il fournit suffisamment de briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application aboutie et facile à maintenir. Ces composants sont organisés pour être utilisés en interaction les uns avec les autres", définition proposée par

TechnoSciences.net, consulté le 10/07/2017, URL :

génération de visualisations de données interactives), et techniques (pour la récupération au-tomatique des données – ou parsing – à intervalles réguliers). Sans entrer dans des détails trop techniques, précisons que le langage de développement sur lequel s’appuyait l’application web automatisée est le PHP³¹, car il permet d’interagir avec une base de données via le langage de requête MySQL³², dans des délais d’exécution rapides. La structure de la base de données re-flétait le type de données agrégées en fonction de leur source. Elle comportait quatre tables : air (indice de la qualité de l’air et niveau d’alerte), polluants (mesures moyennes des différents polluants atmosphériques mesurés en région bruxelloise et en Belgique, pour établir des com-paraisons), stations (mesures réalisées dans les dix stations bruxelloises en activité au moment de l’expérience), météo (observations météorologiques).