OpenAQ, Sensor.Community, Grafana.
Donnez ces trois noms à un Agent : il produira facilement un plan apparemment complet — connecter les données, harmoniser les formats, afficher des graphiques. Il conviendrait à presque tout projet associant sources de données et visualisation. Ce qui détermine réellement le travail reste à préciser.
OpenAQ fournit des données de qualité de l’air quasi en temps réel et historiques, avec leurs métadonnées. Sensor.Community est un réseau de capteurs environnementaux porté par des contributeurs. Grafana sert à interroger et afficher des données. Ces capacités existantes peuvent former différents produits. API OpenAQ, Sensor.Community, Fondamentaux de Grafana
Une ancienne fiche de candidats de ToWow proposait trois voies : adaptation de données, sonde d’écarts et atlas de qualité de l’air. C’étaient des conceptions non validées, étayées par leurs sources. Nous poursuivons ici leur analyse : en quoi le choix du produit transforme-t-il le travail suivant ?
L’adaptateur livre un chemin de données reproductible
Son utilisateur dispose peut-être déjà d’une méthode d’analyse et souhaite éviter de retraiter manuellement chaque nouvelle entrée. Le premier résultat attendu est une transformation stable.
Le travail utile porte sur la correspondance des champs : représentation de la grandeur mesurée, convention temporelle, conservation de la source, traitement des champs absents. Un champ source peut ne pas avoir d’équivalent cible ; l’adaptateur doit indiquer où cette information est conservée.
Le premier livrable vérifiable peut être petit : un échantillon d’entrée, sa sortie transformée et une explication champ par champ. L’utilisateur doit pouvoir poursuivre son travail avec ce résultat, sans deviner le sens du programme de conversion.
La valeur est la réduction des raccordements répétitifs. La comparaison pertinente porte donc sur un connecteur existant ou un petit script : pour une même entrée, lequel maintient plus facilement une conversion correcte, et combien faut-il réparer quand la source change ?
La sonde d’écarts livre des observations à examiner
Son utilisateur possède déjà les données des deux côtés et cherche les différences qui méritent une enquête.
Le résultat intermédiaire peut être un tableau comparatif. Les champs suivants sont fictifs et illustrent le design ; ils ne représentent ni les formats réels des API ni des observations effectives.
| Enregistrement de la source A | Enregistrement de la source B | Conditions de correspondance | Suite |
|---|---|---|---|
| Une mesure en un lieu et un créneau | Une mesure de même nature à proximité, au même créneau | Unités identiques, lieux distants | Conserver distance et conditions d’échantillonnage, puis examiner l’écart |
| Moyenne sur une heure | Valeur instantanée d’une minute | Agrégation temporelle différente | Obtenir d’abord une même base temporelle |
| Valeur sans description de l’appareil | Valeur et informations sur l’appareil | Contexte nécessaire à l’explication manquant | Compléter les métadonnées |
Le tableau conserve une décision qu’un simple graphique ne prend pas : pourquoi comparer ces éléments. Face à un écart, on peut examiner les valeurs, mais aussi les différences de temps, de lieu, d’appareil et de traitement.
Le premier essai peut se limiter à un lieu et une courte période, en conservant enregistrements bruts, transformations et motifs des correspondances impossibles. L’objectif est qu’un utilisateur trouve des observations à examiner. S’il doit encore nettoyer toutes les données, le tableau n’a pas pris en charge le travail principal.
Grafana est ici un choix de présentation ; la définition de ce qui est comparable constitue le cœur de la sonde. Un tableau ordinaire suffit déjà à tester l’utilité de cette voie.
L’atlas livre une explication lisible seule
Son lecteur ne maintient peut-être aucun pipeline et ne souhaite pas examiner chaque anomalie. Il veut comprendre l’évolution d’un lieu sur une période.
Une image exportable doit donc emporter son contexte : lieu, période, grandeur, unité, sources et explications nécessaires. Enregistrée hors du système d’origine, elle doit rester compréhensible.
Cela transforme la visualisation. Un tableau de bord permet à l’opérateur de changer continuellement les filtres ; un atlas destiné à autrui demande à l’auteur de choisir un angle, signaler les changements intéressants et conserver un accès aux données originales. L’explication fait partie du livrable autant que l’image.
On peut commencer par un lieu et une fenêtre temporelle, puis soumettre le résultat au lecteur cible. Observer ce qu’il comprend et ses questions permet de décider s’il faut ajouter de l’interaction ou élargir la portée. Le nombre de pages ou de graphiques compte moins qu’une compréhension juste.
Choisir d’abord un résultat intermédiaire
Ces voies ne s’excluent pas, mais n’ont pas besoin de démarrer ensemble. L’adaptateur produit une conversion répétable, la sonde une correspondance examinable, l’atlas une explication autonome. Leurs premières étapes demandent des codes, données et utilisateurs différents.
Une exécution historique a ensuite produit l’inventaire de captures documentaires des trois projets : octets, lignes, titres et hachages. C’était une préparation des sources ; aucune donnée d’observation n’avait été obtenue. La prochaine validation de chaque voie doit donc commencer par des entrées réelles et des utilisateurs cibles. Les détails de cet artefact figurent dans le registre des sources.
Dans un système génératif, je souhaite des propositions aussi concrètes : quel premier livrable, pour quel utilisateur et quelle étape, et quel retour nous ferait changer de direction ? Une liste d’outils commence alors à devenir un travail que l’on peut faire avancer.