Data engineering · Suivi-évaluation humanitaire

Chaîne de données MEAL, du terrain au tableau de bord

Conception et exploitation d'une chaîne complète collecte → base de données → pilotage décisionnel → cartographie pour une ONG intervenant au Sahel, en auto-hébergement conteneurisé, sécurisé et à faible coût.

RôleConception, déploiement & administration (bout en bout)

DomaineSuivi-Évaluation-Redevabilité-Apprentissage (MEAL)

ContexteONG humanitaire (identité anonymisée)

DockerPostgreSQLApache Superset ODK CentralXLSFormRedis CeleryNginx · TLSLeaflet PythonSQL

Vue d'ensemble

Une architecture, quatre briques, un seul serveur maîtrisé

Tous les services sont conteneurisés sous Docker et servis derrière un reverse-proxy Nginx unique qui termine le chiffrement HTTPS/TLS (certificats Let's Encrypt renouvelés automatiquement) et maintient les bases hors d'atteinte publique. Deux sources alimentent la couche décisionnelle : la collecte terrain (ODK Central) et la base de programme (PostgreSQL managée dans le cloud). Le décisionnel lit la donnée en direct ; seule la carte est produite par lot.

Fig. 1 — Schéma d'architecture, vue d'ensemble. Le trait signal marque le choix central : Superset interroge la base en lecture seule et en temps réel, sans copie intermédiaire.

Brique 1 · Décisionnel

Apache Superset & mise en cache

Superset est déployé en plusieurs conteneurs : un serveur web Gunicorn sert l'interface, un worker Celery exécute les requêtes longues et les exports, un planificateur (Beat) orchestre les tâches, une PostgreSQL dédiée aux métadonnées stocke les définitions de dashboards et de jeux de données, et un Redis sert de cache de résultats et de file de messages.

À l'affichage d'un graphique, Superset consulte d'abord le cache Redis ; en cas d'absence seulement, il émet la requête SQL vers la base source puis met le résultat en cache. Un tableau déjà consulté se réaffiche sans réinterroger la base.

Fig. 2 — Superset & cache. Le chemin d'une consultation : cache d'abord, requête SQL seulement en cas d'absence, puis remise en cache.

Brique 2 · Connexion à la donnée

Lecture directe plutôt qu'un ETL planifié

Les jeux de données sont des datasets virtuels, des vues SQL non matérialisées définies dans Superset. Choix d'architecture assumé : pas de pipeline ETL ni de requêtes planifiées recopiant la donnée. À chaque rendu, le moteur (SQLAlchemy + psycopg2) interroge la base en direct via un pooler de connexions, avec un rôle strictement en lecture seule et une sécurité au niveau des lignes (RLS) côté base.

Fig. 3 — Schéma comparatif. La différence tient à un saut : la lecture directe supprime l'entrepôt intermédiaire et le décalage des données.

Brique 3 · Collecte terrain

ODK Central & validation XLSForm

La collecte est auto-hébergée : API backend, saisie web Enketo, base PostgreSQL, service de conversion pyXForm. La collecte mobile se fait hors-ligne via ODK Collect avec synchronisation différée. Les formulaires sont conçus en XLSForm puis compilés en XForm.

La validation est déclarative et multi-niveaux, portée par les colonnes du XLSForm et appliquée à la saisie puis revérifiée côté serveur :

type — typage (entier, date, sélection, géopoint…)
required — réponses obligatoires
constraint — bornes & cohérence (+ message)
relevant — sauts / affichage conditionnel
calculation — champs calculés
choice_filter — listes en cascade

Fig. 4 — Collecte & validation. Les règles du XLSForm sont appliquées à la saisie (Collect/Enketo) et revérifiées à la réception serveur.

Brique 4 · Cartographie

Carte dynamique, générée par lot

À la différence des tableaux de bord (en direct), la carte est pré-générée par une tâche planifiée hebdomadaire. Un script Python réconcilie les activités de la base de programme avec les limites administratives officielles (matching géographique tolérant aux variantes de saisie, point-in-polygon), puis publie des fichiers statiques. La bibliothèque Leaflet est embarquée dans le fichier (aucune dépendance CDN) : affichage garanti et usage hors-ligne.

Fig. 5 — Génération cartographique. Traitement par lot, hebdomadaire ; la date de mise à jour est affichée dans l'en-tête de la carte.

Fig. 6 — Maquette de l'interface (schématique). Filtres combinables et, au clic sur une commune, la liste des projets avec leurs activités phares. Libellés fictifs.

Exploitation

Continuité & sécurité

Redémarrage automatique des conteneurs
Supervision de disponibilité en temps réel
Watchdog du reverse-proxy
Sauvegardes compressées à rétention glissante
TLS renouvelé automatiquement (Let's Encrypt)
Accès en lecture seule + RLS côté base

Résultat. Une source unique de vérité du terrain au tableau de bord, des indicateurs consultables en continu, une cartographie partageable qui favorise la synergie inter-projets. Le tout en auto-hébergement maîtrisé et à coût réduit.

Compétences démontrées

Ce que ce projet met en œuvre

Conteneurisation Docker multi-services
Administration PostgreSQL & SQL analytique
BI self-service (Superset)
Intégration base ↔ décisionnel sécurisée
Conception & validation de formulaires (XLSForm/ODK)
Géomatique légère (Leaflet, point-in-polygon)
Automatisation (cron, Python)
Reverse-proxy & TLS
Culture MEAL (indicateurs, redevabilité)

Étude de cas anonymisée — schémas d'architecture et maquette fournis à titre illustratif, sans données personnelles ni identifiants d'organisation. Détails techniques complémentaires disponibles sur demande.