Alerte sargasses à J+3 : détection, advection et niveau de confiance

Détection : isoler les pixels à fort indice d'algues flottantes

Le point d'entrée est un produit satellite Copernicus Marine : un indice proxy de la biomasse d'algues flottantes, apparenté au NFAI (Normalized Floating Algae Index), calculé pixel par pixel sur la zone de la Guadeloupe. Plutôt que de fixer un seuil de densité absolu — fragile face à la variabilité des conditions d'observation — le système retient un seuil par quantile sur la distribution du jour : le quantile 0,95 par défaut, c'est-à-dire les pixels qui se situent dans les 5 % les plus intenses de l'image.

Ce choix a une conséquence directe et assumée : le seuil quantile s'adapte à chaque scène, pas à une valeur physique fixée une fois pour toutes. Si le quantile 0,95 échoue à isoler des pixels valides sur une image donnée — trop de nuages, trop peu de signal — le système redescend en cascade sur des quantiles plus permissifs (0,90, puis 0,85, puis 0,80) jusqu'à obtenir un ensemble exploitable. C'est un compromis de robustesse opérationnelle, pas un raffinement scientifique : mieux vaut une détection dégradée qu'une absence de détection.

Les pixels retenus forment les taches candidates : les points de départ de la simulation d'advection. Aucune estimation de volume ou de biomasse n'en est dérivée — le produit dit où la densité relative est forte, pas combien de sargasses sont physiquement présentes.

Advection : où ces taches vont-elles en trois jours ?

Une fois les taches candidates identifiées, chacune est représentée par un ensemble de particules virtuelles. Ces particules sont intégrées en avant dans le temps par le champ de courants de surface Copernicus Marine (composantes u, v), sur un horizon de J+3. C'est une advection lagrangienne de premier ordre : le transport suit directement le courant de surface, sans dérive de Stokes, sans traînée du vent, sans modèle de fragmentation des amas.

Pour ne pas produire une trajectoire unique — trompeusement précise — le système exécute plusieurs membres en parallèle (dix par défaut). Chaque membre applique une perturbation légère : un déplacement spatial initial et un bruit ajouté au champ de courant. Le but n'est pas de simuler des scénarios météorologiques alternatifs, mais de faire apparaître une enveloppe d'incertitude de transport — la dispersion entre membres devient elle-même une donnée exploitée à l'étape suivante.

Impact par zone : p_mean, hit_rate et ETA

Le littoral guadeloupéen est découpé en zones côtières prédéfinies. Pour chaque zone et chaque membre d'ensemble, le système teste l'intersection entre la trajectoire advectée et le polygone de la zone. De ce test binaire par membre, trois quantités sont calculées :

p_mean

Moyenne, sur l'ensemble des membres, de la probabilité d'impact par membre — la fraction de membres qui atteignent la zone.

hit_rate

Proportion de membres dont la probabilité de toucher la zone est strictement positive — combien de membres, sur dix, atteignent la zone, indépendamment de leur intensité.

ETA par membre / ETA médiane

Temps d'arrivée estimé pour chaque membre qui touche la zone ; la médiane sur ces membres est retenue comme ETA de zone. Sans impact, aucune ETA n'est calculée.

p_mean n'est pas une probabilité volumétrique — combien de sargasses arriveront — mais une métrique de probabilité de transport : la fraction de trajectoires simulées qui touchent effectivement la zone. C'est une distinction que les systèmes de prévision côtière fondés sur la simulation partagent en général : le modèle dit où le transport mène, pas quelle quantité y arrive.

La logique de confiance : pourquoi p_mean seul ne suffit pas

C'est le point le plus important du système, et celui qui distingue une alerte utilisable d'un simple graphique de probabilité. Un p_mean élevé obtenu par une large majorité de membres qui convergent, tous, vers la même zone au même moment ne vaut pas le même p_mean obtenu par un mélange de membres très dispersés — certains touchant la zone en J+1, d'autres en J+3, d'autres pas du tout. La moyenne peut être identique ; la fiabilité de l'information ne l'est pas.

Le système ne moyenne donc pas l'incertitude : il la classe explicitement, à partir du couple (hit_rate, écart-type inter-membres), selon une cascade de règles :

• p_mean < 0,01 → confiance HAUTE (le signal est faible et cohérent : l'ensemble des membres s'accorde à dire qu'il n'y a pas d'impact)
• hit_rate < 0,25 → confiance BASSE (trop peu de membres touchent la zone pour trancher)
• hit_rate < 0,50 → confiance MOYENNE (une minorité de membres converge, sans majorité claire)
• hit_rate ≥ 0,50, puis sur l'écart-type des probabilités entre membres : std < 0,07 → HAUTE ; std < 0,15 → MOYENNE ; sinon → BASSE

Cette dernière branche est celle qui porte le message central : même quand une majorité de membres s'accorde sur l'impact (hit_rate ≥ 0,50), le système redescend la confiance à BASSE si la dispersion inter-membres reste forte (écart-type ≥ 0,15). Un p_mean élevé né d'un accord fragile entre membres est signalé comme tel, plutôt que présenté avec la même assurance qu'un p_mean élevé né d'un accord serré. La confiance n'est donc jamais une fonction de p_mean seul — elle mesure la cohérence de l'ensemble, pas seulement son centre.

Ce que ce MVP ne fait pas

Il faut être précis sur la portée de ce système, parce que c'est cette précision qui le rend utilisable pour ce qu'il est — une preuve de concept côtière — et non pour ce qu'il n'est pas.

• Aucune validation terrain : aucune campagne d'observation côtière n'a confronté les alertes générées à un échouage réel. Aucun taux de détection, aucun score de justesse, aucune statistique de performance ne peut donc être cité — rien n'est mesuré à ce stade.
• Le transport est de premier ordre : pas de dérive de Stokes, pas de traînée du vent, pas de modèle de fragmentation ni de décomposition biologique des amas. C'est une approximation de transport, pas un modèle de cycle de vie des sargasses.
• Pas d'assimilation de données ni de correction par observation in situ — le système ingère les produits Copernicus tels quels et les propage.
• La latence des produits satellite est une contrainte opérationnelle réelle et suivie explicitement : l'horodatage d'une observation (timestamp) et sa date de mise à disposition (génération) ne coïncident pas. Un produit NFAI daté d'aujourd'hui peut avoir été généré avec un décalage de plusieurs heures, ce qui borne la fraîcheur réelle de l'alerte à J+3 — une alerte émise à partir d'une observation déjà vieille de quelques heures perd d'autant sur son horizon utile.
• La portée géographique est limitée à la Guadeloupe et à un jeu de zones littorales prédéfinies : pas de généralisation automatique à d'autres îles.

Les sorties du système — fichier JSON, cartes PNG de probabilité et de confiance, rapport PDF optionnel — sont conçues pour appuyer une décision humaine, pas pour la remplacer. Un système d'alerte transport-only avec une logique de confiance explicite est un socle défendable pour discuter d'un déploiement opérationnel ; ce n'en est pas encore un.

Vous travaillez sur un système d'alerte ou de prévision côtière et voulez discuter d'une méthode de confiance adaptée à votre cas ? Contactez-nous.

Sources et références

Les métriques, comparaisons et cartes propres à cet article sont des résultats et calculs OceanData Consulting ; les liens ci-dessous documentent les jeux de données, standards et publications mobilisés.

• Copernicus Marine — ocean colour and floating algae products
• Copernicus Marine — global ocean physics analysis and forecast (surface currents)

Questions fréquentes

À lire également