À propos de SquawkWatch

SquawkWatch surveille en continu les codes transpondeur ("squawks") signalant une urgence ou une activité particulière : détournement, panne radio, détresse, priorité sûreté, vol médical, activités spéciales et trafic militaire. La surveillance des codes critiques (7500 / 7600 / 7700) couvre le monde entier ; les codes spéciaux et le trafic militaire/mixte ne sont surveillés que dans le périmètre France (métropole + Corse), pour rester sobre en requêtes envers les sources de données.

Pour les codes critiques, le badge « Portée » affiche le pays (ou la zone, ex. « Zone internationale » en mer) survolé à la dernière position connue plutôt qu'un générique « Mondial » — recalculé automatiquement si l'appareil se déplace significativement. Il peut rester « Mondial » quelques instants après une toute première détection, le temps que cette résolution aboutisse.

Score de confiance & faux positifs

Chaque événement est affiché dès sa première détection — jamais retardé, y compris pour les codes critiques — mais accompagné d'un score de confiance qui augmente avec le nombre d'observations cohérentes et, pour les codes critiques, avec le temps écoulé depuis la première détection (plafonné à 60 % avant 3 minutes d'observation continue). Il est également ajusté selon l'altitude (pénalité au-dessus de 20000/30000 ft, plafond de confiance pour les codes non critiques dans ces tranches) et rehaussé pour les indicatifs de service public connus (SAMU, DRAGO).

Pour les codes non critiques uniquement (jamais 7500/7600/7700) : les blocs « mixtes » du périmètre France (ex. approches Roissy/Orly/Istres, Bordeaux/Dijon/Deauville/Châteaudun/Toulouse Blagnac) sont partagés civil/militaire, et un indicatif au format vol de ligne commercial (ex. AFR1234) y correspond presque toujours à un code assigné en routine par le contrôle aérien plutôt qu'à une activité notable. La confiance est donc plafonnée à 20 % dans ce cas, et à 10 % si l'appareil est en plus en croisière haute altitude (> 30000 ft) et proche des limites du périmètre France surveillé — signe probable d'un simple survol de transit international.

Une détection restée à une seule observation, jamais reconfirmée, est reclassée automatiquement « faux positif » à sa clôture — c'est le signal le plus fiable d'un bruit de décodage isolé. Pour les codes critiques (7500 / 7600 / 7700), une durée totale d'observation inférieure à 1 min 15 s déclenche le même reclassement, même en cas d'observations répétées en rafale sur quelques secondes ; au-delà de ce délai, un événement critique clôturé par inactivité reste « clôturé », jamais faux positif.

Avant de créer un nouvel événement, chaque détection est d'abord confrontée aux événements récemment clôturés pour le même appareil et le même squawk : si l'un d'eux a été clôturé ou classé faux positif il y a peu (moins de 6 minutes pour un code critique, 20 minutes pour un code spécial), il est rouvert plutôt que remplacé par un événement isolé supplémentaire. Cela évite qu'une coupure de couverture temporaire d'une source de données (l'appareil n'est vu que par une source moins fréquemment interrogée, par exemple) ne fragmente une même détection continue en une série de faux positifs rapprochés.

Un événement reste « actif » tant qu'il continue d'être détecté, sans limite de durée maximale — une source qui émet en continu depuis un point quasi fixe (transpondeur d'une installation au sol, appareil à l'arrêt) peut donc rester affichée « active » pendant des heures, ce qui est le comportement attendu et ne signale aucun dysfonctionnement. Le badge 📍 Stationnaire signale ces cas (position quasi immobile sur une longue durée) à titre purement informatif — il n'a aucun effet sur le statut de l'événement.

Pour les codes critiques uniquement (7500/7600/7700) : un événement resté confirmé exclusivement par OpenSky — jamais par adsb.fi ni adsb.lol — voit sa confiance plafonnée à 50 % tant qu'aucune autre source ne l'a corroboré ; le même délai de 5 minutes s'applique en interne à la notification de l'administrateur du site (non disponible publiquement — CallMeBot, le service tiers utilisé, est actuellement indisponible). Ce garde-fou ne masque et ne bloque jamais l'événement : il reste affiché dès la première détection comme n'importe quel autre, quel que soit l'état de la notification. La fiche d'un événement concerné affiche le badge confirmé par OpenSky seul à côté du score de confiance. Ce plafond a été ajouté après un faux positif observé en production : un appareil resté affiché en squawk 7500 pendant plus de 18 minutes alors que deux sources indépendantes avec réception ADS-B directe (ADS-B Exchange, FlightAware) montraient un vol parfaitement normal au même moment — seul OpenSky rapportait le squawk d'urgence, adsb.fi ne l'ayant jamais confirmé.

Deux compléments à ce garde-fou. D'abord, sur le tableau de bord, un événement critique est affiché « Faible » dès que sa confiance passe sous 60 % — un seuil plus exigeant que celui utilisé pour les autres squawks (41 %), pour que le plafond à 50 % ci-dessus reste visible sur la page la plus consultée du site plutôt que de s'afficher « Élevée » comme n'importe quel autre événement. Ensuite, la vérification ne se contente plus d'attendre passivement qu'une source non-OpenSky retombe par coïncidence sur le même appareil : dès qu'un squawk critique n'est confirmé que par OpenSky, le serveur interroge lui-même adsb.fi (adsb.lol en secours) pour cet appareil précis, entre 60 et 110 secondes plus tard — une vérification ciblée plutôt qu'une simple attente. Chaque tentative apparaît, en direct, dans le tableau « Vérifications ciblées » de la page Santé, sous adsb.fi:verif-icao / adsb.lol:verif-icao. Si l'une des deux sources confirme le même squawk, l'événement est corroboré normalement. Si l'une des deux voit au contraire cet appareil transmettre un squawk différent — une contradiction directe, pas une simple absence de donnée — l'événement est reclassé faux positif immédiatement, plutôt que d'attendre qu'OpenSky cesse de son côté de le rapporter. Les 10 minutes qui suivent cette fermeture, les hits OpenSky seuls pour ce même appareil sont ignorés (un hit d'une autre source reste, lui, traité normalement) — sans quoi OpenSky, en continuant de rapporter le même squawk toutes les 30 à 60 secondes, aurait rouvert l'événement presque aussitôt.

Sources de données

adsb.fi est la source principale pour la position en direct des appareils : elle est interrogée à chaque cycle de collecte, dans la limite du quota que ses conditions d'utilisation autorisent. OpenSky Network et adsb.lol interviennent en alternance (croisement périodique) et en secours automatique si adsb.fi est temporairement indisponible — elles ne remplacent jamais adsb.fi comme source par défaut. L'enrichissement route et appareil (aéroports, immatriculation, exploitant, constructeur, pays d'immatriculation, photo quand disponible) utilise adsbdb.com en priorité, avec hexdb.io en secours (hexdb ne fournit ni pays d'immatriculation ni photo).

La fiche d'un événement affiche aussi le cap et le taux vertical de l'appareil, ainsi qu'une flèche d'évolution d'altitude (▲ montée / ▼ descente / ▬ stable, seuil de 150 ft/min) à côté de l'altitude. Ces deux champs sont fournis directement par la position en direct : pour OpenSky, leur format est une spécification publique stable et vérifiée ; pour adsb.fi et adsb.lol, ils suivent le schéma standard de cette famille d'API mais n'ont pas pu être vérifiés en conditions réelles (bac à sable de développement sans accès réseau sortant, comme pour la géolocalisation par pays — voir plus haut) : la lecture reste purement défensive et se rabat sur « — » si le champ est absent. Quand le taux vertical n'est pas disponible, la flèche est calculée à partir des deux dernières positions connues de l'appareil. La fiche trace également la trajectoire connue de l'appareil sur la carte (toutes les positions enregistrées depuis la détection), même si elle ne couvre que quelques minutes.

L'état en direct de chacune de ces sources (dernier appel, dernier résultat, disjoncteur) est visible sur la page Santé.

Codes squawk surveillés

Météo & historique par appareil

Chaque fiche événement affiche désormais le METAR de la station météo connue la plus proche de la dernière position de l'appareil (source : aviationweather.gov, NOAA — couvre la France et l'Europe, pas seulement les États-Unis), ainsi que l'historique des autres événements déjà enregistrés pour ce même appareil. Ces deux informations sont indicatives et non officielles — elles ne remplacent pas une préparation de vol réglementaire. Cette source météo, ainsi que l'enrichissement route/appareil (adsbdb.com, hexdb.io ci-dessous), sont interrogés à la demande — leur état en direct (dernier appel, erreurs) est visible sur la page Santé, panneau « Enrichissement & services externes ».

Zones aériennes & NOTAM

Zones aériennes structurelles (P/R/D/CTR/TMA) : étudié pour la V2 (voir le cahier des charges, section 4.4), non encore activé — piste identifiée (OpenAIP, base communautaire gratuite) en attente d'une clé API. Les zones militaires basse altitude (AZBA/RTBA) ont également été étudiées mais écartées : la donnée officielle existe côté SIA/DGAC mais son accès est protégé contre l'usage automatisé.

NOTAM réels : disponibles en option, mais limités aux aérodromes des États-Unis (source FAA — voir le README du projet pour les détails techniques). Aucune source NOTAM complète n'est disponible pour la France/l'Europe en libre-service à ce jour.

Attribution

Données ADS-B fournies par adsb.fi (réseau communautaire, usage personnel non commercial), OpenSky Network et adsb.lol. Enrichissement via adsbdb.com et hexdb.io. Météo fournie par aviationweather.gov (NOAA).