# Quelques mots sur l'organisation
### Service Information, Développement Durable et Évaluation Environnementale (IDDÉE)
* Un service traditionnellement positionné sur la donnée (SIG, stats, SGBDR) et au service des autres
* Des compétences en programmation depuis plusieurs années (python, R, php, java, javascript, basic, etc.)
* Mais pas de *datascientist* de formation
Un agent initié au ML grâce au réseau [SPYRALES 🔗](https://www.spyrales.fr/) piloté par le MEFR
Deux stagiaires IMT Nord Europe
* programmation python, y compris applications web métier en django
* IMT Nord Europe, ex Institut Mines Télécom Lille Douai, fusion École des Mines de Douai / Lille Télécom
# Des développements ML à quelle échelle ?
Des développement à l'échelle des Hauts-de-France (ou du bassin Artois-Picardie), mais systématiquement compatibles avec un déploiement dans d'autres régions.
*(Un des projets présentés dans cette présentation est d'ailleurs en cours de déploiement en Normandie.)*
**MAIS ** *(retour d'expérience 😉)* besoin de créer un processus de "nettoyage" des données local **impliquant le service métier**.
Notamment, quatres écueils ** *data* ** rencontrés :
* moissonnage des données (scraping, maintenance chronophage)
* fiabilisation des données (**historique** compris 👿)
* latence/complexité des mises à jour (synchro bases métier / sources moissonnables)
* exhaustivité des clefs étrangères (SIREN, NAF, etc.)
(Avis très personnel 😇 : ML "métier" recquiert un référent "nettoyage des données" désigné dans le service métier ad hoc)
* Moissonnage des données : application GIDAF (cf. description plus loin dans la présentation), "scrapable" localement car droits accordés localement -> maintenance complexe locale, même quand développement applicatif global
* Fiabilisation des données : ML nécessite bcp de données pour s'entraîner ; si service métier refuse de remonter 3 ans en arrière pour faire corriger des données (à tort ou à raison), met en péril le processus d'apprentissage automatisé
* La latence est particulièrement problématique si données récupérées par scraping (processus d'aspiration doit être parfait !) ; autre possibilité : retraiter les données localement (qui ? comment ? engage responsabilité Etat ?)
#Temporalité ⌛
* L'apprentissage automatisé est un sujet très récent pour nous
* Pas d'historique sur le sujet *(des modèles déjà utilisés pour la prévision des crues, mais issus du développement d'organismes de recherche)*
* Des besoins émergeants :
* algorithmes traditionnels pas assez efficaces pour détecter des anomalies,
* comblement de données avec des moyennes trop rudimentaire,
* repérage d'articles de presse très chronophage.
* Réseau spyrales encore très récent (2020 ?) - formation agent DREAL HdF au ML fin 2020 / début 2021
* Hébergement de deux stagiaires IMT Lille Douai printemps/été 2021
*Retour d'expérience : niveau M1 vraisemblablement un peu juste pour lancer de l'IA, même s'il est certain que les conditions d'encadrement n'ont pas simplifié la tâche à nos stagiaires*
# Les outils (langage python 🐍)
### écosystèmes pandas 🐼 / scikit-learn
Mention spéciale à certaines librairies qui démocratisent très largement le machine learning (il y en a bien sûr d'autres, mais celles-ci sont celles qu'on a testées pour l'instant 😉):
* analyse exploratoire des données (EDA) :
* [**pandas_profiling** 🔗](https://github.com/pandas-profiling/pandas-profiling) [✨](./images/0070.00436/profiling_report_0070.00436_nettoye.html)
* auto ML :
* [**dabl** 🔗](https://dabl.github.io/dev/) *(en phase de développement très actif)* : un bon compromis temps/résultat
👍 : rapide (focus sur les algo les plus simples et les plus rapides), compatible toutes plateformes
👎 : pour la régression, pas possible de choisir des algorithmes plus complexes *(provisoire ?)*
* [**AutoSklearn** 🔗](https://automl.github.io/auto-sklearn/master/) : pour davantage de précision si on a du temps devant soi
👍 : performant (prend la durée d'exécution en argument), complet (notamment sur le pre-processing)
👎 : des blocages intempestifs (liés au multiprocessing ?), **limité à linux**
# Quelles techniques de Machine Learning en DREAL ?
(*Spoiler alert* : tous les développements sont encore en test, certains ont échoué...)
* **clusterisation** : regrouper les données pour travailler par paquets homogènes
* **réduction de dimensions** : pour simplifier les jeux de données
* **régression** : pour prédire des valeurs en s'appuyant sur d'autres données
* **détection d'anomalies** : pour identifier des erreurs ou des fraudes
* **topic-modeling** (NLP, à l'étude) : pour identifier le sujet d'articles (cf. présentation du précédent datadrink 😉)
#Les projets concernés par le ML
Les projets (dépôts GitLab ministériels en liens) :
* Système d'information sur les rejets aqueux :
* [*passerelle Vers'eau ➡️ Triton/IRE* 🔗](https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-hdf/sen_dbap/autosurveillance-stations)
* [**Industries au regard de l'environnement (IRE)** 🔗](https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-hdf/ppc/IRE) - [accès aux livrables en ligne : 📰](http://www.hauts-de-france.developpement-durable.gouv.fr/?Publication-de-l-industrie-au-regard-de-l-environnement)
* [*passerelle IRE ➡️ Triton* 🔗](https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-hdf/sen_dbap/alimentation_triton_icpe)
* [**Triton** (en développement) 🔗](https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-hdf/sen_dbap/triton)
------
* [**Abaques** (prévision des crues) 🔗](https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-hdf/pr-vision-des-crues/abaques)
------
* [*(ADOC, Application pour la veille DOCumentaire, en projet - NLP)* 🔗](https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-hdf/ppc/ADOC)
# Projet n°1 - rejets aqueux
### *Industries au Regard de l'Environnement, Triton & passerelles associées*
Les enjeux du système
Connaissance
Combler les trous de la raquette 🎾 en croisant les bases
Les établissements ayant "oublié" de déclarer sous GEREP ou dont les émissions sont inférieures aux seuils réglementaires
Fiabiliser
Croiser les données pour fiabiliser la publication de l'IRE
Contrôle
Contrôle des déclarations GEREP
Lesquelles sont remontées à la commission européenne
Bilans SDAGE
Extension de l'IRE à tous polluants pour faciliter et améliorer le rapportage SDAGE
Cerise 🍒 sur le gâteau 🧁, ça n'était pas prévu au départ !
Visualisation
Photographie à l'instant t de l'état des masses d'eau
S'affranchir des considérations statistiques "classiques" (notions de "percentile 90")
Diagnostic
Explicabilité de la dégradation de l'état
Identifier la contribution (en flux) propre à chaque pollueur, prendre en compte l'effet cumulé
Temporalité
Prendre en compte la saisonnalité (des cours d'eau, des rejets)
Descendre à un pas de temps fin pour visualiser les pics au lieu d'une approche (traditionnelle) par bilans annuels
Simuler
Ajouter/adapter des pollueurs
Aide à la décision : instruction de dossier, priorisation des mises en conformité.
IRE & Triton - Schéma actuel simplifié (malheureusement, si 😱...)
Désolé pour le reformatage du graphe entre les deux diapos, c'est la librairie (mermaid.js) qui repositionne automatiquement 😳...
# Clusterisation ICPE : retour d'expérience
Echec quasi total... Pourquoi ?
* Clusterisation par code NAF : champ trop incomplet (dans le temps !) pour clusteriser par ce biais (pas toujours les codes SIREN non plus...)
* Clusterisation des émissions journalières : trop de diversité dans les polluants suivis (même entre entreprises du même domaine)
* Clusterisation des émissions annuelles : trop de lacunes dans les champs dès lors qu'on prend le problème de manière transversale (rejets aqueux, déchets)
Une lueur d'espoir tout de même : les stations d'épuration urbaines.
(Leurs émissions étant plus homogènes.)
Crédits : GIPHY
# Régressions ICPE : retour d'expérience
* Bilan du stage mitigé 🤔 (pas de métrique permettant de juger de la performance de l'algorithme produit, par ailleurs assez complexe avec une passerelle vers R).
* D'autres tests montrent des résultats encourageants 👍 et qui ont un réel impact sur les données produites.
**Retour d'expérience :**
* intérêt à diversifier les librairies autoML (d'autres librairies sont encore à tester : FLAML, AutoKeras...) :
* *dabl* arrive parfois à un résultat correct très vite (alors qu'*AutoSklearn* semble aller systématiquement jusqu'au bout du délai maximum) ;
* pour autant, *AutoSklearn* trouve parfois des modèles tout à fait convaincants là où *dabl* échoue complètement.
* un point de vigilance : *garbage in, garbage out* (encore...).
**Besoin à court terme :** intégrer la validation (manuelle ?) / persistance des modèles utilisés dans un pipeline applicatif.
Nota : cet exercice réinterroge la stratégie d'autosurveillance des entreprises
###Régressions - ex d'une ICPE
# Détection d'anomalies : retour d'expérience
###(stage en cours d'évaluation)
* Situation pré-ML : un algorithme "classique" basé sur la cote Z pour identifier les années à problème. Approche pas toujours efficace et "mono-substances".
* Proposition de la stagiaire 🤔 : algorithme de clusterisation (DBSCAN) qui signale la présence d'un point isolé ou de plusieurs clusters
# Projet n°2 - Abaques pour la prévision des crues
*(L'EDA est une production à part, qui permet notamment d'expliquer les échecs de modélisation sur certaines stations.)*
Il y a une bonne part d'aléatoire dans le processus de sélection des modèles (très peu de données, surtout dans les classes minoritaires qui nous intéressent).
L'important n'est pas tant d'avoir une bonne précision, qu'une bonne précision **dans les classes minoritaires** :
les abaques PNG générées permettent de visualiser ces erreurs facilement, ce qui permet à un humain de reprendre les abaques XLSX reprises dans des modèles ultérieurs.
