• Source brute : réponse JSON de l'endpoint /public/DPVigilance/v1/cartevigilance/encours. Chaque domain_id correspond à un code département (ex. "17", "2A"). Les codes non-départementaux (zones marines, outre-mer) sont filtrés.
• Niveaux d'alerte : 4 niveaux codés par max_color_id — 1 Vert (pas de vigilance), 2 Jaune, 3 Orange, 4 Rouge. Seuls les niveaux ≥ 2 sont retenus et affichés.
• 9 phénomènes suivis : Vent violent (1), Pluie-inondation (2), Orages (3), Crues (4), Neige-verglas (5), Canicule (6), Grand froid (7), Avalanches (8), Vagues-submersion (9). Pour chaque phénomène, le phenomenon_max_color_id détermine le niveau effectif.
• Périodes J+0 / J+1 : L'API distingue deux périodes (echeance: "J" et "J1"). RiskAgri affiche les deux avec une distinction visuelle dans l'interface, permettant d'anticiper les alertes du lendemain.
• Géolocalisation parcelle → département : le centroïde de chaque parcelle est testé en point-in-polygon sur le fichier departements_fr.geojson pour identifier son département, puis les alertes de ce département sont récupérées.
• Notifications : RiskAgri permet de recevoir des notifications push pour les alertes de vigilance Météo-France (vent violent, orages, crues, neige-verglas, canicule…) directement sur l'appareil utilisateur en ciblant les parcelles géographiquement concernées par le phénomène signalé.

Les alertes de vigilance sont émises au niveau départemental. Une vigilance jaune sur un département ne signifie pas que toutes les parcelles de ce département sont en danger — le risque réel dépend de la localisation précise et du contexte local. RiskAgri applique un croisement géographique pour ne retenir que les alertes du département d'appartenance de la parcelle.

• Température (°C) : valeur horaire temperature_2m à 2 m du sol. La valeur "maintenant" correspond à l'heure courante dans la série horaire. Les minima / maxima journaliers proviennent de temperature_2m_min et temperature_2m_max.
• Précipitations (mm) : cumul horaire precipitation et cumul journalier precipitation_sum. Seuils d'alerte utilisés : >15 mm/j = précipitations notables ; >40 mm/j = précipitations importantes (seuil d'alerte inondation).
• Vent (km/h) : vitesse instantanée wind_speed_10m à 10 m, direction wind_direction_10m en degrés convertie en flèche directionnelle (8 secteurs de 45°). Seuil >40 km/h = vent fort ; >89 km/h = tempête.
• Humidité relative (%) : relative_humidity_2m. Indicateur clé pour le risque phytosanitaire et le calcul FWI.
• ETP — Évapotranspiration Potentielle : calculée selon la norme FAO-56 (Allen et al., 1998) via la variable et0_fao_evapotranspiration. L'ETP quantifie la demande évaporative de l'atmosphère en mm/jour. Un ETP >4 mm/j signale une demande hydrique élevée pour les cultures. Utilisée également pour le calcul du déficit hydrique (sécheresse).
• Données historiques (90j) : via l'API archive-api.open-meteo.com, les 90 derniers jours de précipitations et d'ETP sont extraits pour calculer le déficit hydrique (voir module Sécheresse).
• Code météo WMO : weather_code — code international (Organisation Météorologique Mondiale) de 0 à 99 traduit en icônes et libellés français (ex. 0 = Ciel dégagé ☀️, 95 = Orage ⛈️).
• Clustering géographique : les parcelles distantes de moins de 1 km sont regroupées dans un même "secteur" de calcul. Une seule requête API est émise pour le centroïde moyen du groupe. Cette stratégie est appliquée côté frontend (JS) et côté backend (Python). Elle réduit les appels API de 60 à 80 % sur des exploitations avec parcelles proches.
• Cache TTL : les données météo sont mises en cache 1 heure par point géographique (précision ~1 km), évitant les appels redondants si l'utilisateur change d'onglet ou recharge la page.
Fallback : En cas d’indisponibilité temporaire de l’API Open-Meteo, un mécanisme de solution de repli est automatiquement activé. Il repose sur des données météo précollectées sur des points de référence répartis dans chaque département et stockées dans un fichier mis à jour régulièrement. Lorsque le service n’est pas accessible, les données du point le plus proche de la parcelle sont utilisées afin de garantir la continuité du service, avec une précision légèrement dégradée mais suffisante pour un usage opérationnel.

• Source : fichier n_tri_s issu de la base nationale Géorisques. Les TRI (Territoires à Risque Important d'Inondation) sont définis par la directive européenne 2007/60/CE et désignent les zones soumises à un Plan de Prévention du Risque Inondation (PPRI).
• Méthode géométrique : les requêtes utilisent directement les fonctions PostGIS (ST_Within, ST_DWithin, ST_Distance) sur Supabase. Si la parcelle est à l'intérieur d'un TRI → niveau inside. Sinon, la distance est calculée vers le TRI le plus proche.
• Niveaux de distance : <2 km = close (très proche) · 2–10 km = medium · 10–30 km = far · >30 km = safe. Ces seuils sont définis en fonction de la distance de propagation typique des crues.
• Résultat retourné : niveau de risque, nom du TRI le plus proche, distance en km. Ces données sont mises en cache 24h par point géographique.

• Phénomènes ciblés : parmi les 9 phénomènes de vigilance Météo-France, RiskAgri extrait les phénomènes Crues (id=4) et Pluie-Inondation (id=2) pour le module inondation. Un filtre par nom de phénomène ("CRUE" ou "INOND") est appliqué.
• Croisement géographique : la fonction getParcelAlerts(geometry) détermine le département de la parcelle via point-in-polygon, puis extrait les alertes actives pour ce département. Si une alerte crues ≥ Orange est détectée, elle prend le dessus sur le niveau TRI pour l'affichage des KPI.

• Données : precipitation_sum (mm/j) et precipitation_probability_max (%) sur 7 jours depuis Open-Meteo.
• Indicateurs calculés : cumul 7 jours (total_7d), pluie max sur un jour (max_day), probabilité max à 3 jours.
• Seuils de risque pluvio : max_day >40 mm = risque high ; 20–40 mm = medium ; 10–20 mm = low_medium ; <10 mm = low. Ces seuils correspondent aux valeurs de référence utilisées dans les bulletins de prévision des crues.

Le risque final affiché sur la carte est le maximum entre le niveau TRI et le niveau de vigilance crues. Si le département est en vigilance Rouge, le risque passe en Rouge quelle que soit la distance au TRI. La prévision pluviométrique est affichée en complément pour anticiper les risques de saturation des sols même hors zonage TRI.

• Source : fichier mvt_national — base nationale des mouvements de terrain répertoriés par le BRGM. Chaque point représente un événement passé avec : commune, type, date de début.
• 5 typologies de MVT : 1-Glissement de terrain · 2-Chute de blocs · 3-Coulée de boue · 4-Effondrement de cavité · 5-Érosion de berge. Ces catégories correspondent à la nomenclature officielle du BRGM.
• Index spatial : les requêtes utilisent l'index spatial PostGIS natif de Supabase via ST_DWithin (rayon 50 km). Les opérateurs <-> (KNN) permettent un tri par distance en millisecondes sans charger l'ensemble des données en mémoire.
• Test point-in-polygon : si le centroïde de la parcelle est géographiquement à l'intérieur d'une zone MVT → risque high immédiat. Sinon, la distance haversine vers le point le plus proche est calculée.
• Niveaux de risque structurel : à l'intérieur d'un MVT ou <2 km = high · 2–10 km = medium · 10–30 km = low · >30 km = safe.

• Données : precipitation_sum journalier sur 7 jours (Open-Meteo Forecast). Deux métriques clés : pluie max sur 5 jours (max_5d) et cumul sur 7 jours (cumul_7d).
• Seuils MVT (littérature géotechnique) : >50 mm/j sur un jour = déclenchement possible de glissements superficiels sur sols argileux ; >80 mm cumulés sur 7 jours = saturation de la nappe superficielle et risque accru de coulées. Ces valeurs sont issues des études de référence du BRGM sur le déclenchement des glissements en France.
• Indice de risque pluviométrique : rain_mvt_risk = high si max_5d>50 ou cumul_7d>80 · medium si max_5d>25 ou cumul_7d>40 · low_medium si max_5d>10 · low sinon.
• Combinaison : si le risque structurel est ≥ medium ET le risque pluviométrique est ≥ medium, RiskAgri signale une "combinaison à risque" avec un avertissement visuel spécifique.

• API : https://api.vigieau.gouv.fr/api/zones — interrogée avec les coordonnées GPS de la parcelle et le paramètre profil=exploitation pour obtenir les zones de restriction agricoles actives à cet endroit précis.
• 5 niveaux d'alerte : Normal · Vigilance · Alerte · Alerte renforcée · Crise. L'API retourne un champ niveauGravite (normalisé en niveauAlerte côté serveur). Le niveau le plus élevé parmi toutes les zones actives pour le point est retenu (max_level).
• Usages agricoles : chaque zone retourne un tableau usages[] avec thematique, nom et description. RiskAgri extrait et affiche jusqu'à 4 usages agricoles impactés (filtrés parmi les usages les plus pertinents pour l'exploitation).
• Cache TTL 6h : les données VigiEau sont mises en cache 6 heures par point géographique, car les arrêtés ne changent généralement pas plusieurs fois par jour.

• Formule : Déficit hydrique = Σ Précipitations (90j) - Σ ETP FAO-56 (90j). Un déficit négatif signifie que les sols ont perdu plus d'eau par évapotranspiration qu'ils n'en ont reçu par les pluies. Un déficit > −40 mm déclenche le niveau "Vigilance" ; >−80 mm = "Alerte" ; >−150 mm = "Crise".
• Source données 90j : API Archive Open-Meteo (archive-api.open-meteo.com/v1/archive) avec les variables precipitation_sum et et0_fao_evapotranspiration au pas journalier, pour les 90 derniers jours glissants.
• Fallback : si l'API VigiEau est indisponible, le déficit hydrique Open-Meteo est utilisé seul pour définir le niveau d'alerte. Si Open-Meteo est aussi indisponible, une mention de "données indisponibles" est affichée.

• Source : incendies_fr_2004_2024 — Base de Données sur les Incendies de Forêt en France (BDIFF), produite par le Ministère de l'Agriculture et de la Souveraineté Alimentaire. Contient chaque incendie avec : commune, date d'alerte, département, surface parcourue en m².
• Périmètre d'analyse : tous les incendies dans un rayon de 30 km autour de la parcelle sont extraits via l'index spatial. Ce rayon est retenu comme zone de risque de propagation potentielle pour des feux de grande ampleur.
• Score de risque pondéré : Score = min(n_5ans×8, 40) + min(n_10ans×4, 30) + min(surface_5ans_ha/100, 20) + min(surface_10ans_ha/500, 10). La formule sur 100 points surpondère les 5 dernières années (facteur ×8 vs ×4 pour les 10 ans) pour refléter l'évolution récente du risque liée au changement climatique.
• Niveaux de risque historique : Score ≥60 = very_high · 35–60 = high · 15–35 = medium · 0–15 = low · 0 incendie à 30 km = safe.
• Optimisation : index spatial PostGIS natif (ST_DWithin rayon 30 km) côté Supabase. Cache TTL 24h côté backend (~5.5 km de précision) pour éviter les requêtes redondantes.

• Définition : le FWI (Fire Weather Index) est un standard international développé au Canada et utilisé par l'Union Européenne (European Forest Fire Information System — EFFIS). Il quantifie le potentiel d'inflammabilité de la végétation et la vitesse de propagation d'un feu à partir des conditions météo.
• Variables d'entrée : Température de l'air (°C) · Humidité relative (%) · Vitesse du vent (km/h) · Précipitations des dernières 24h (mm). Ces 4 variables sont extraites de l'API Open-Meteo (current et daily).
• Calcul simplifié dans RiskAgri : le score FWI est estimé par une règle pondérée : +25 pts si T>30°C, +15 si T>25°C ; +30 pts si HR<20%, +15 si HR<35% ; +25 pts si vent>40 km/h, +10 si vent>20 km/h ; +10 pts si pluies <0,1 mm. Score total sur 100 pts.
• Niveaux FWI : <15 = Faible · 15–35 = Modéré · 35–60 = Élevé · >60 = Très élevé. Ces seuils sont alignés sur ceux utilisés par l'EFFIS et Météo-France dans leurs bulletins de risque feux de forêt.
• Prévision J+1 : le FWI du lendemain est calculé avec les prévisions temperature_2m_max, relative_humidity_2m_min, wind_speed_10m_max et precipitation_sum du jour suivant.

• API : apicarto.ign.fr/api/rpg/v2 — interrogée en temps réel avec un polygone circulaire centré sur la position recherchée (rayon configurable, défaut 5 km). Retourne les parcelles RPG (culture, surface parcourue) dans GeoJSON.
• Enrichissement : chaque parcelle reçoit un identifiant unique (ign_X_i), et la surface réelle est calculée géométriquement (haversine, en hectares) depuis les coordonnées du polygone.
• Dessin manuel : outil de tracé polygonal basé sur Leaflet.js. L'utilisateur clique les points du contour ; la fermeture est détectée automatiquement quand le clic est à <18px du premier point. La surface est calculée par la formule de Gauss-Shoelace en projection géographique.
• Import de fichiers : 3 formats supportés — CSV (colonne WKT obligatoire), GeoJSON/JSON (FeatureCollection), Excel XLSX/XLS (colonne WKT). Parser : PapaParse (CSV), XLSX.js (Excel), natif (JSON). Limite : 10 polygones par import, 5 Mo par fichier.
• Formats WKT supportés : POLYGON, MULTIPOLYGON, POINT (avec SRID optionnel). Les MULTIPOLYGON sont automatiquement décomposés en polygones simples.

• Leaflet.js v1.9.4 : moteur cartographique open-source. Gestion des couches, des marqueurs, des popups, des tooltips et de l'interactivité utilisateur.
• Esri World Imagery : imagerie satellite haute résolution mondiale, servie par le CDN Esri. Zoom max : 19. Mise à jour périodique par Esri.
• Esri World Topo : fond topographique mondial (relief, routes, villes) — alternative satellite pour visualisation contextuelle.
• OpenStreetMap / Carto Voyager : fond open-source collaboratif, mis à jour en continu. Utilisé aussi dans les miniatures de prévisualisation des cartes parcellaires dans la sidebar.
• Rendu des labels parcelles : tooltips permanents Leaflet (bindTooltip avec permanent:true) affichant le nom de chaque parcelle active directement sur la carte.

• PPRI / PPRN : les Plans de Prévention des Risques Inondation et Naturels Majeurs encadrent l'usage des parcelles en zones à risque. RiskAgri affiche le zonage TRI à titre informatif ; le PPRI applicable est consultable auprès de la DDT (Direction Départementale des Territoires).
• Code de l'Environnement : Articles L. 562-1 et suivants encadrant les PPRN. Les diagnostics RiskAgri ne constituent pas une expertise certifiée au sens de ces textes.
• Directive 2007/60/CE : directive européenne relative à l'évaluation et la gestion des risques d'inondation, transposée en droit français. Les TRI en découlent directement.

• Règlement UE 2016/679 (RGPD) : RiskAgri applique les principes de minimisation des données, limitation de la finalité et intégrité/confidentialité. Seuls l'email, le mot de passe hashé (bcrypt) et les géométries de parcelles sont stockés.
• Loi Informatique et Libertés n°78-17 : droits d'accès, rectification, effacement et portabilité exercés directement depuis la page Profil.
• Hébergement : Supabase (base de données, AWS eu-west-3 Paris), Render (backend), Netlify (frontend). Transferts encadrés par les clauses contractuelles types de la Commission Européenne.

Les analyses produites par RiskAgri sont des aides à la lecture basées sur des données publiques. Elles ne constituent en aucun cas : une expertise géotechnique certifiée, un avis juridique, un conseil d'assurance, ni une garantie d'absence de risque. L'utilisateur demeure seul responsable de ses décisions conformément aux articles 1240 et 1241 du Code civil.

INENVAS est une association loi 1901 déclarée, à but non lucratif, sans publicité, sans revente de données. L'application est gratuite pour les utilisateurs. Contact : contact@inenvas.fr

• Algorithme : clustering glouton basé sur la distance haversine. Chaque parcelle est assignée au premier cluster dont le centroïde est à moins de R km (R = 1 km côté frontend). Le centroïde du cluster est recalculé comme moyenne arithmétique des centroïdes des parcelles membres.
• Impact : sur une exploitation de 10 parcelles dans un rayon de 2 km, les 10 parcelles forment 1 seul cluster → 1 seule requête API au lieu de 10. Réduction des appels API de 60 à 90 % selon la dispersion géographique.
• Implémentation : côté frontend en JavaScript (clusterParcelsByDistance() dans analyse_brain.js) pour le rendu des résultats, et côté backend en Python (cluster_parcels_by_distance()) pour les appels API.

• Principe : les géométries sont indexées via un index spatial PostGIS (GiST), permettant d’accélérer les requêtes d’intersection grâce à une organisation hiérarchique des enveloppes géométriques.
• Requête : pour un point (lat, lon), seules les cellules dans un rayon de 1 cellule autour de la cellule contenant ce point sont examinées (zone 3×3 = 9 cellules maximum). Les features candidates sont dédupliquées par identifiant Python (id(feat)).
• Performance : sans index, analyser 300 000 points MVT pour une parcelle prend ~2–5 secondes. Avec l'index spatial (construit une seule fois au démarrage), la même analyse prend <50 ms.

• Implémentation : classe Python TTLCache avec dictionnaire thread-safe (verrou threading.Lock()). Chaque entrée contient la valeur et un timestamp d'expiration. L'accès en lecture vérifie l'expiration et supprime les entrées périmées à la lecture (lazy expiration).
• Clés géographiques : les coordonnées sont arrondies à 0,05° (~5,5 km de précision, via round(lat × 20) / 20) pour maximiser la réutilisation du cache entre parcelles proches, en cohérence avec le clustering à 5 km.
• TTL par module : Météo = 1h · Inondation (pluvio) = 2h · Sécheresse VigiEau = 2h · MVT = 2h · Incendie = 2h · TRI = 24h. Ces durées reflètent la fréquence de mise à jour possible de chaque source.

• ThreadPoolExecutor : un pool de 20 threads est utilisé pour traiter les clusters en parallèle. Pour une analyse avec 5 clusters géographiques distincts, les 5 requêtes API sont émises simultanément, divisant le temps de réponse par ~5.
• Gestion des erreurs : chaque future est encapsulée dans un try/except. Un cluster en erreur retourne un résultat partiel sans bloquer les autres clusters.

• Structure : les parcelles sont stockées dans une colonne JSONB (selected_zones) de la table users_profiles. Chaque parcelle est un objet JSON avec id, label, surface, cultures, geometry (GeoJSON), tri (cache du risque), savedAt.
• Suppression SQL jsonb : la suppression d'une parcelle utilise une expression SQL jsonb native (jsonb_agg + jsonb_array_elements) sans charger le JSON entier côté Python, évitant les problèmes de concurrence.
• Limite : 10 parcelles par compte (configurable par compte via la colonne max_parcel dans Supabase). La géométrie complète est toujours stockée (pas de simplification).