L’architecture pour la gestion des flux de données envisagée dans TERRA FORMA s’appuie sur un cloud (serveur de données TERRA FORMA, situé actuellement à Clermont-Ferrand) qui reçoit des flux de données brutes ou décodées issus de serveurs de communication LoRaWAN (serveur local – sur site de déploiement, ou serveur national TERRA FORMA, situé à Toulouse), de la plateforme centrale multiprotocole ou directement d’autres serveurs opérés (IoT satellitaires, 4-5G...). La technologie du cloud repose sur les lacs de données.

A terme l’enjeu pour le serveur de donnée TERRA FORMA se porte sur son intégration dans le paysage national (interfaçage et interopérabilité) défini par :

• les SI locaux (OSU, SNO, ZA...) qui supportent l’expertise pour la validation et qualification des données,
• les pôles de données (THEIA/OZCAR, PNDB...) et unités de services dédiés à la gestion de la donnée (BBEES, CDS...) qui supportent des services d’aide aux producteurs de données pour la FAIRisation des données,
• et enfin les IR numériques (DATA TERRA, ...) qui centralisent expertise et services de plus haut niveau (Environnement Virtuel de Recherche, Intelligence Artificielle...) à l’échelle globale.

Le serveur de donnée TERRA FORMA traite des données de bas niveau (données brutes et intermédiaires) et des données avec un fort potentiel de mobilisation (données dites chaudes). Au fur et à mesure de leur exploitation et traitement (données tièdes puis froides lorsqu’elles sont archivées), ces données intègrent les composantes existantes de ce paysage des structures de la donnée.

Le serveur de donnée TERRA FORMA s’appuie sur les expériences de NeoCampus avec le projet Econnect sur le territoire Toulousain, et le projet ConnecSenS avec le CEBA (Cloud Environnemental au Bénéfice de l’Auvergne).

Les tâches à venir se portent donc sur :

• la proposition d’une structuration des trames/décodage ; le choix du format des métadonnées alignées avec les termes du thesaurus THEIA/OZCAR ;
• le choix pour réaliser la qualification (où, quand, par qui, niveau) à décider en concertation avec les utilisateurs ;
• et enfin l’ouverture du système par des API (dédiée aux objets de l’IoT (exemple du standard OGC SensorThings), ou de domaine généraliste (ex. openEO) ou généraliste (ex. AWS S3)) et par le format (Standard (ex : csv, netCDF) ou optimisé cloud (ex : parquet, geoParquet, zarr…)).

Enfin, la montée en puissance de la fairisation des données s’appuiera sur des outils complémentaires et incontournables tels que le catalogue des instruments TERRA FORMA et les BDD de gestion et suivi des capteurs in situ.