NËBB

Quel problème NËBB résout-il ?

Bargny et Diamniadio/Sébikotane concentrent une part de l'industrie lourde sénégalaise. Les habitants constatent la pollution ; personne ne la mesure. Les stations de référence coûtent des dizaines de milliers d'euros pièce — on ne couvre pas un territoire avec ça.

La sortie est le capteur bas coût. Mais un capteur bas coût dérive : température, humidité et vieillissement décalent ses mesures. Publier ses valeurs brutes, c'est publier du faux avec l'autorité d'un chiffre.

Quelles contraintes techniques cela impose-t-il ?

Le cœur du projet n'est donc pas la collecte, c'est la confiance dans la donnée. Quatre modèles répondent chacun à une facette :

Calibration par Random Forest. Le capteur bas coût est apprivoisé en apprenant l'écart entre ses mesures et celles d'une référence, conditionné par la température et l'humidité. Le modèle corrige la dérive au lieu de la subir.

Prévision PM2.5 par LSTM et Prophet. Le LSTM est en PyTorch, décliné en version complète et version allégée selon la puissance disponible. Deux approches en parallèle — réseau récurrent et décomposition saisonnière — parce qu'une alerte de pollution sert à anticiper, pas à constater. La prévision est publiée avec une bande de confiance à 95 % : une alerte sans incertitude affichée est une alerte qu'on finit par ignorer.

Détection d'anomalies par Isolation Forest. Non supervisée, parce qu'on ne dispose pas d'exemples étiquetés de capteur défaillant. Elle sépare le pic de pollution réel du capteur qui décroche.

Interpolation spatiale par kriging. Une douzaine de capteurs ne couvre pas un territoire. Le kriging produit une carte de chaleur continue et sa variance — on sait donc où la carte est fiable et où elle extrapole.

Comment NËBB est-il architecturé ?

Dix services conteneurisés, répartis en trois fichiers Docker Compose — infrastructure, application, pipeline — pour qu'on puisse relancer les traitements sans toucher à la base ni au broker.

Ingestion MQTT via Mosquitto, dont les certificats sont générés par script : le canal entre capteurs et plateforme est authentifié des deux côtés.

Trois magasins, chacun pour ce qu'il fait bien. InfluxDB 2.7 pour les séries temporelles, avec des tâches Flux qui sous-échantillonnent à l'heure et au jour, calculent l'indice de qualité de l'air quotidien et surveillent la fraîcheur des données. PostgreSQL 16 avec PostGIS et pgvector pour le géospatial, le métier et la recherche vectorielle. Redis 7.2 pour le cache et les compteurs d'alerte.

L'API FastAPI expose onze routeurs — capteurs, IQA, prédictions, alertes, carte, rapports, export, pipeline, administration. Trois middlewares tournent devant : journal d'audit, identifiant de requête et en-têtes de sécurité.

Le pipeline est orchestré par Prefect 3, avec APScheduler pour le déclenchement périodique. Sept flux : ingénierie de caractéristiques, prédictions, kriging, réentraînement, supervision et traitement du langage sur les signalements citoyens. Rien ne tourne dans le cycle de requête.

Dix-neuf écrans côté React : dashboard citoyen, carte, grille de capteurs, comparaison de zones, mais aussi détail de modèle, détail de flux, détail de worker et journaux — un vrai centre de supervision, pas un tableau de bord.

Sécurité de production dès la conception : JWT, RBAC, limitation de débit, TOTP pour le second facteur, mTLS sur le canal MQTT. Une plateforme qui publie des données sanitaires est une cible : si la donnée peut être falsifiée, l'outil devient dangereux.

Un simulateur de capteurs complète le dispositif : la chaîne entière se teste sans matériel déployé.

Quel a été mon rôle sur NËBB ?

Chef d'un groupe de six, réunissant trois filières — IA & Big Data, Télécoms, Sécurité des Systèmes d'Information. J'ai porté les modèles et l'architecture backend, et surtout le travail d'interface entre des personnes qui ne parlaient pas le même vocabulaire technique.

Qu'est-ce que NËBB m'a appris ?

La partie difficile n'était aucun des quatre modèles pris isolément. C'était de décider ce qu'on publie quand on n'est pas sûr. Afficher une valeur fausse avec assurance cause plus de tort que ne rien afficher : toute l'architecture découle de cette contrainte-là.