🧑‍🤝‍🧑Équipe CRaTT

Raya Berova (DMRG) : raya.berova@insee.fr
Thomas Faria (SSPLab) : thomas.faria@insee.fr
Clément Guillo (DIRAG) : clement.guillo@insee.fr

🧭 Timeline du projet

MARS 2022

Clément Guillo prend un stagiaire de Master et se lance sur le sujet des images satellites.

NOVEMBRE 2022

Clément Guillo initie le projet Images Satellites avec Tom Seimandi et Thomas Faria au SSPLab.
Ils trouvent comme cas d’usage l’aide à l’enquête cartographique dans les DROM pour mieux diriger les agents recenseurs lors des collectes ⟶ Début du projet !

MARS 2023

Stages de fin d’études :
    Judith Nabec sur les images Sentinel2 (DG),
    Raya Berova sur les images Pléïades (DIRAG puis DG).

SEPTEMBRE 2023

Raya Berova intègre l’équipe, avec 0.2 ETP sur le projet.
Travail de mise au propre du code : prise en main facile, respect des bonnes pratiques et reproductibilité.
Entraînement d’un nouveau modèle très performant, qui remplace l’ancien U-Net : le SegFormer.
Le modèle prédit uniquement le bâti sur images Pléïades, entraîné sur la couche bâti de la BDTOPO.

DÉCEMBRE 2023

Mise en place du GeoServer puis de l’application web CRaTT pour afficher dynamiquement les images et les prédictions. Permet un contrôle visuel facile pour l’équipe et de diffuser les travaux à l’Insee.
Création du package Astrovision pour faciliter la lecture et la manipulation des images satellites.

MARS 2024

Stagiaire de Master sur le traitement des prédictions du modèle
⟶ mise en forme des prédictions, nettoyage et statistiques.

MAI 2024

Séminaire DIRAG : rencontre des équipes.
    Guadeloupe : présentation du projet à la DIRAG.
    Guyane : discussions des cas d’usages et réalisation de l’enquête cartographique sur le terrain.
    Visite de quartiers et de bidonvilles.

SEPTEMBRE 2024

Départ de Tom Seimandi.

DÉCEMBRE 2024

Meeting WP7 : rencontre avec l’IGN et présentation de COSIA
⟶ entraînement d’un modèle multiclasse grâce aux annotations de COSIA. Modèle plus performant que le modèle binaire BDTOPO, il est actuellement utilisé pour produire les prédictions.
Participation active lors des GT DOM Résil : est-ce que le projet peut aider à estimer le nombre de logements à Mayotte ?

FÉVRIER 2025

Prise de contact avec Pascal Rivière et Loup Wolff pour savoir si CRaTT peut aider au recensement exhaustif de Mayotte 2026 et estimer les zones les plus touchées par le cyclone Chido.

MARS 2025

Hackathon Eurostat à Bruxelles sur les données satellites : 6ième place sur 27 équipes (Clément, Raya et Damien Babet du SSM Agriculture)
⟶ reproduction du projet de A à Z en 3 jours en utilisant des images Sentinel2 et les annotations CLCPlus sur les pays de l’UE.
Présentation du projet à NTTS (Thomas).

ÉTÉ 2025

Séminaire de la DMCSI sur les images satellites.
Départ de Thomas Faria et Clément Guillo.
Travail de documentation.
Passation pour préparer l’arrivée de Meilame et Cédric SSPLab.

SUITE

JMS avec la DMTR : utilisation des images satellites pour améliorer le repérage des logements à Mayotte.
Déplacement à Varsovie pour le WP7.
La suite est à déterminer.

📦 Structure du projet

Ce projet structuré en 7 dépôts Git open source, hébergés sur GitHub, et organisés au sein de l’équipe Satellite Images de l’organisation InseeFrLab.

📁 Les différents dépôts

1️⃣ Astrovision : Package utilitaire pour le traitement d’images satellites

Pour manipuler des données géospatiales, la bibliothèque incontournable est GDAL. Afin de faciliter son usage en Python, des wrappers comme Rasterio sont couramment utilisés. Rasterio offre une interface efficace pour travailler avec des données raster.

Dans notre projet, nous avons développé un package complémentaire, Astrovision, qui centralise un ensemble de fonctions utilitaires : découpage d’images, gestion des métadonnées, visualisation, etc. Ce package n’est pas strictement indispensable, cela a été aussi pour nous d’apprendre à déployer un package python. Le projet pourrait fonctionner en s’appuyant exclusivement sur Rasterio, avec quelques adaptations.

2️⃣ Préparation des images satellites

Le dépôt satellite-images-preprocess regroupe les fonctions nécessaires à la préparation des images avant l’entraînement des modèles. Ce dépôt n’est utilisé qu’en amont d’un entraînement, et n’est donc pas utile lorsque l’on souhaite simplement réaliser de l’inférence sur de nouvelles images.

Le pipeline de preprocessing comprend les étapes suivantes :

  1. Génération automatique des labels à partir d’un jeu d’annotations.
  2. Découpage des images sources en tuiles plus petites (pour éviter les problèmes de mémoire lors de l’entraînement).
  3. Suppression des images contenant des nuages.
  4. Filtrage des images selon une région d’intérêt définie.
  5. Calcul des moyennes et écarts types des bandes spectrales pour la normalisation.
  6. Réalisation du split train/test et sauvegarde des données sur un bucket S3.
Note

Le choix de séparer ce dépôt de celui de l’entraînement est discutable, mais repose sur plusieurs objectifs :

  • Isoler les différentes étapes du pipeline.
  • Éviter de ré-exécuter inutilement le preprocessing à chaque entraînement.
  • Faciliter la modularité du projet. Ces objectifs ne sont pas forcément en contradiction avec le fait de tout centraliser dans un seul package.

3️⃣ Entraînement des modèles

L’entraînement est géré par le dépôt satellite-images-train. Il est nécessaire d’avoir à disposition des images déjà prétraitées et stockées sur le S3, ce qui peut être fait via le dépôt de preprocessing.

L’objectif de ce dépôt est d’offrir un environnement modulaire permettant d’expérimenter différentes stratégies d’entraînement et d’optimiser les hyperparamètres propre à l’entraînement (et rien d’autres !). Tous les résultats sont loggués via MLFlow.

Deux familles de modèles de segmentation sont actuellement intégrées :

Côté fonctions de perte, plusieurs variantes de l’entropie croisée sont disponibles (classique, pondérée, binaire, etc.).

4️⃣ Inférence à partir de nouvelles images

Le dépôt satellite-images-inference est dédié à l’inférence. C’est peut être le dépôt le moins “isolé” dans le sens où il contient à la fois les codes de l’API qui est utilisée pour réaliser l’inférence mais également divers scripts nécessaires que cela soit pour l’inférence, le post-processing ou bien la reception de nouvelles images à inférer.

L’API, développée avec FastAPI, est déployée sur SSPCloud. Elle propose trois endpoints principaux :

  1. GET /predict_image — Prédiction d’une image individuelle stockée sur S3.
  2. GET /predict_cluster — Prédiction sur un îlot identifié par son code (peut inclure plusieurs images).
  3. GET /predict_bbox — Prédiction sur une bounding box définie par des coordonnées GPS (peut inclure plusieurs images).

Un système de cache est en place pour éviter les redondances de calcul sur une même image.

⚠️ Limites actuelles de l’API :
  • Les prédictions en batch ne sont pas possibles directement (elles doivent être séquentielles) puisque seuls des endpoints GET sont disponibles.
  • Certaines opérations pourraient être asynchrones pour améliorer les performances.
  • L’API reproduit le preprocessing, idéalement, il faudrait wrapper tout dans un modèle MLFlow et donc créer une custom class lors de l’entrainement.

5️⃣ Application CRaTT

Le code de l’application CRaTT permettant de visualiser les résultats sur des territoires entier est disponible dans le dépôt satellite-images-webapp. L’application est construite avec Observable Framework qui permet de déployer sur un site statique tout en gardant un certain niveau d’interactivité dans les visualisations que l’on peut montrer. La manipulation des données peut se faire dans le langage de notre choix (Python, R, SQL, etc.) et les visualisation se font en JavaScript.

Le déploiement est réalisé via Github Pages et est accessible à l’adresse suivante : https://inseefrlab.github.io/satellite-images-webapp/.

6️⃣ Déploiement des applications

Pour gérer les différents déploiements de l’ensemble du projet, nous avons créer un dépôt GitOps. Il s’agit du dépôt satellite-images-cd. Il contient les manifests Kubernetes des services déployés ainsi que les templates d’ArgoCD afin d’avoir un déploiement continu.

En avril 2025, 2 services sont déployés :

  • l’API d’inférence
  • le Geoserver pour la mise à disposition des tuiles d’images

7️⃣ Documentation du projet

La documentation que vous lisez actuellement est réaliser avec Quarto et toute contribution est la bienvenue dans le dépôt satellite-images-docs.

Le projet sur le Datalab – SSPCloud

Le namespace

Afin de pouvoir contribuer au projet il est nécessaire d’avoir accès au namespace projet-slums-detection. Pour cela, vous pouvez contacter la Diit.

Les données

Le S3 associé au projet est structuré en plusieurs dossiers.

📁 data-raw

Ce dossier contient les images satellites telles qu’on les reçoit sans modification. Seules les données de la Guyane et de Saint-Martin sont un peu différentes avec des sous dossiers brut car elles ont nécessité des ajustements préalables. En effet, pour tous les autres départements les données proviennent de l’IGN qui nous transmets les mosaïques d’images 2000x2000.

La structure du dossier est :

data-raw/<SOURCE>/<DEPARTEMENT>/<ANNEE>/*.tif

📁 data-label

Ce dossier contient les données géographiques contenant les labels que nous utilisons lors de notre entraînement et que nous considérons donc comme vraie valeur. En fonction de la source de l’annotation le format des fichiers peut différer. Pour le moment, 2 sources de données sont utilisées il s’agit de la BDTOPO et de COSIA et les données sont stockées respectivement au format Shapefile et au format Geopackage.

La structure du dossier est :

data-label/
├── BDTOPO/
│   ├── bdtopo-id2label.json
│   └── <DEPARTEMENT>/
│       └── <ANNEE>/
├── COSIA/
│   ├── cosia-id2label.json
│   └── <DEPARTEMENT>/
│       └── <ANNEE>/

📁 data-preprocessed

Le dossier data-preprocessed/ contient l’ensemble des données préparées pour l’entraînement d’un modèle. Il est organisé en deux sous-dossiers principaux, le dossier labels/ qui contient les fichiers d’étiquettes (.npy) associés à chaque tuile d’image ainsi que le dossier patchs/ contient les images (.jp2) associées portant le même nom.

La structure du dossier est donc :

data-preprocessed/
├── labels/                        # Étiquettes
│   └── <LABELER>/                 # Annotateur (ex: COSIA, BDTOPO...)
│       └── <TASK>/                # Tâche spécifique (ex: segmentation, classification...)
│           └── <SOURCE>/          # Source de données (ex: PLEIADES, SENTINEL...)
│               └── <DEPARTEMENT>/ # Département (ex: MAYOTTE, REUNION...)
│                   └── <ANNEE>/   # Année de la donnée (ex: 2023)
│                       └── <TILE-SIZE>/  # Taille des tuiles (ex: 125, 250...)
│                           ├── train/    # Jeu d'entraînement
│                           │   └── *.npy # Fichiers numpy
│                           └── test/     # Jeu de test
│                               └── *.npy # Fichiers numpy
├── patchs/                        # Images
│   └── <LABELER>/                 # Annotateur (ex: COSIA, BDTOPO...)
│       └── <TASK>/                # Tâche spécifique (ex: segmentation, classification...)
│           └── <SOURCE>/          # Source de données (ex: PLEIADES, SENTINEL...)
│               └── <DEPARTEMENT>/ # Département (ex: MAYOTTE, REUNION...)
│                   └── <ANNEE>/   # Année de la donnée (ex: 2023)
│                       └── <TILE-SIZE>/  # Taille des tuiles (ex: 125, 250...)
│                           ├── train/    # Jeu d'entraînement
│                           │   └── *.jp2 # Fichiers images jp2
│                           └── test/     # Jeu de test
│                               └── *.jp2 # Fichiers images jp2

📁 data-prediction

Le dossier data-prediction/regroupe les résultats de prédictions générées par différents modèles. Les prédictions sont disponibles au format Parquet mais également au format GeoPackage pour pouvoir les utiliser dans le Geoserver.

La structure du dossier est :

data-prediction/
└── <SOURCE>/                  # Source de données (ex: PLEIADES, SENTINEL...)
    └── <DEPARTEMENT>/          # Département (ex: MAYOTTE, REUNION...)
        └── <ANNEE>/            # Année de la donnée (ex: 2023)
            └── <MODEL-NAME>/   # Nom du modèle utilisé pour la prédiction
                └── <MODEL-VERSION>/ # Version du modèle (ex: 1, 2...)
                    ├── *.parquet    # Fichiers de prédiction au format parquet
                    └── *.gpkg       # Fichiers de prédiction au format GeoPackage

📁 cache-predictions

Le dossier cache-predictions/ contient les logits intermédiaires produits par les modèles lors du processus de prédiction afin de ne pas refaire une prédiction qui aurait déjà été réalisée. L’organisation du dossier reprend la même hiérarchie que data-prediction :

cache-predictions/
└── <SOURCE>/                  # Source de données (ex: PLEIADES, SENTINEL...)
    └── <DEPARTEMENT>/          # Département (ex: MAYOTTE, REUNION...)
        └── <ANNEE>/            # Année de la donnée (ex: 2023)
            └── <MODEL-NAME>/   # Nom du modèle utilisé pour la prédiction
                └── <MODEL-VERSION>/ # Version du modèle (ex: 1, 2...)
                    └── *.npy       # Logits prédits

📁 data-roi

Le dossier data-roi contient les contours géographique de chaque département afin de pouvoir filtrer les images efficacement que ce soit lors de l’étape de preprocessing que lors de l’étape de l’inférence. Les contours sont à la fois stockés en parquet et en geojson (un seul des deux formats pourrait suffire).

Ces données ont été construites à la main à partir de données officielles. Les contours des territoires n’étant pas sensés changer, il n’y a pas à mettre à jour ces données.

La structure du dossier est :

data-roi/
├── <DEPARTEMENT>.parquet
└── <DEPARTEMENT>.geojson

📁 cluster-geom-raw

Le dossier cluster-geom-raw contient tout l’historique des géométries d’îlots non preprocessé.

La géométrie des îlots est arrêtée chaque année au 31 octobre ; c’est cette version qui s’applique pendant le recensement de la population (RP).
Par exemple, pour l’enquête annuelle de recensement 2026, il faudra utiliser la géométrie des îlots arrêtée au 31 octobre 2025.

Dans tous les cas, il est indispensable de s’assurer que le SERN Géographie et le ST Mayotte disposent bien des mêmes référentiels d’îlots. Des ajustements exceptionnels pourraient être nécessaires compte tenu de l’urgence post-Chido.

Une fois le fichier avec les dernières géométries traité, les nouveaux fichiers parquet sont disponibles dans data-clusters.

📁 data-clusters

Le dossier data-clusters contient les contours géographique de chaque îlot pour les différents départements. Ces informations sont nécessaires lors de l’inférence pour un îlot donné ainsi que pour le déploiement de la webapp qui permet de réaliser des statistiques par îlot. Le dossier est simplement un fichier parquet partitionné :

data-clusters/
├── dep=<DEPARTEMENT>/
      └── part-0.parquet

Les services

Le projet utilise plusieurs service au sein du datalab.

  • MLFlow

MLflow est utilisé lors de la phase d’entraînement pour tracker et optimiser nos modèles. Il permet de logguer les hyperparamètres, les métriques et les artefacts générés au cours des expérimentations. MLflow joue également le rôle de Model Registry, dans lequel à chaque modèle est associé un tag tel que staging, production ou archived. Cela facilite le versionnement et la bonne gestion du cycle de vie des modèles dans le temps

  • ArgoCD

ArgoCD est déployé pour superviser et gérer automatiquement les applications présentes dans notre namespace. Il permet de surveiller en permanence l’état de déploiement des applications et détecte automatiquement toute modification des manifests dans le dépôt GitOps dédié (https://github.com/inseeFrLab/satellite-images-cd). Lorsqu’une modification est détectée, ArgoCD applique automatiquement les changements sur le cluster, garantissant une parfaite synchronisation entre le code source et l’état effectif des déploiements.

  • Argo Workflows

Argo Workflows est utilisé pour orchestrer l’exécution parallèle de scripts, ce qui optimise considérablement les temps de calcul. Les workflows sont décrits dans des fichiers YAML stockés dans les répertoires argo-workflows/ présents dans les différents dépôts. Argo Workflows est sollicité à différents stades du projet, notamment pour exécuter les étapes de preprocessing des données, l’entraînement de modèles en parallèle, ainsi que l’inférence à grande échelle.

  • Geoserver

GeoServer permet la publication et la mise à disposition de données géographiques sous forme de flux normalisés (WMS, WFS, WCS). Contrairement aux autres services mentionnés, GeoServer n’est pas directement provisionné par le Datalab, ni déployé via Helm Chart.

À ce jour, GeoServer ne peut pas accéder directement aux fichiers stockés sur un stockage objet type S3. En conséquence, toutes les images ou données que nous souhaitons exposer doivent être dupliquées dans un PVC associé au pod GeoServer…