La connaissance de la situation maritime

Ce service reçoit l'information maritime — l'AIS d'abord, en fichiers collectés par d'autres systèmes puis par un flux de fournisseur —, la garde dans sa propre base, et en tire des statistiques sur des portes (une ligne en travers d'une voie : ce qui la franchit, par sens, par classe de navire) et des aires (une boîte sur la carte : ce qui s'y trouve, y entre, y attend), dessinées à la souris ou fournies par un catalogue (Ormuz et ses chenaux, Bab el-Mandeb, Suez). Ce qu'il publie est fait pour nourrir la simulation Diodote, le renseignement et la planification ; son périmètre est Ormuz et le Moyen-Orient.

Ce qu'il n'est pas

Pas un outil de désignation d'objectif : il mesure des populations de navires, jamais une coque. Rien de ce qu'il publie ne porte un nom, un MMSI, un IMO ni un armateur ; aucune recherche par nom ni par MMSI, aucune page « navire ».
Pas un flux vivant pour le jeu : le moteur et l'écran du jeu lisent une livraison figée, épinglée par empreinte.
Pas un service de renseignement : la fusion, l'OSINT et la vérification restent chez intell et osint ; il leur livre des mesures.
Pas un suivi de flotte : l'objet est la statistique d'une porte ou d'une aire, pas la poursuite d'un navire.
Jamais une écriture dans un frère : il publie des livraisons que les frères lisent et épinglent.

Chaque valeur dit sa provenance — mesurée (avec son jeu de données), estimée (avec sa raison) ou illustrative (et l'écran le dit) ; une valeur non calculable reste vide. Le plafond DCS de cet hôte est PUBLIC : un jeu de données étiqueté au-dessus y est refusé ; rien d'un fournisseur n'entre dans le dépôt.

Les objets

17 portes et 1 aire en base, dont 16 du catalogue et 2 illustratifs (la démonstration). La carte demande une session. Les sources : 6 actives, 18 jeux de données ingérés (le dépôt demande une session d'analyste, ou manage.py ingest_file) ; les jours clos : 30 jours UTC mesurés sur 18 objets, le dernier le 10/11/2026.

Ce qui est fait

P0 La spécification, le plan (dix-sept décisions prises par défaut, à confirmer) et les prompts phasés (26–27 oct. 2026).
P1 Le squelette : le service démarre, se teste et se protège — comptes sans inscription publique, clés de service pour les frères (jeu, plan, osint, sysan), santé, étiquettes DCS et porte de sortie, HTMX et Leaflet embarquées, tous les réglages nommés, barrière tools/check_all.sh. Rien de maritime encore.
P2 Les objets et la carte : le catalogue des portes (les sept portes du jeu — Ormuz et ses chenaux, Bab el-Mandeb, Suez — et neuf portes d'ensemble estimées : Gibraltar, Malacca, le Bosphore, l'Øresund, Panama, le Pas de Calais, Taïwan, la Sonde, le Cap), trois périodes de référence publiées (PortWatch, dérivées par le jeu), la carte à colonnes et le dessin à la souris, l'API des objets, la première garde « rien par navire ne sort ». Aucune position, aucune statistique encore.
P3a L'ingestion, le cœur : des fichiers AIS (NMEA 0183, CSV, JSON lignes) entrent par manage.py ingest_file, décodés en flux, comptés (acceptés, refusés par motif), gardés — positions et données statiques ; chaque position connaît sa classe (le code AIS rangé dans un vocabulaire fermé, sourcé sur l'UIT) et son pavillon (la table des MID de l'UIT) ; les sources portent leur licence et leur conservation. Les fournisseurs, le registre et « d'autres informations maritimes » sont des réserves qui disent ce qu'elles attendent.
P3b L'ingestion, l'écran : les sources et le dépôt d'un fichier (lu en flux, borné, dédoublonné par son empreinte, refusé au-dessus du plafond DCS de l'hôte), la progression, le contrôle qualité d'un jeu de données sur la carte (interne, par jeu de données, jamais par navire), la démonstration synthétique (manage.py initialization --demo : quarante navires illustratifs au MID 100, deux objets illustratifs), les correspondances de colonnes (NOAA MarineCadastre écrite sur un en-tête réel ; la générique).
P4a Les mesures, le cœur : les franchissements d'une porte (la présélection par boîte élargie, l'intersection exacte, la fusion d'un louvoiement, le sens, l'instant interpolé, les trous de trace), les présences dans une aire (l'entrée, la sortie, le mouillage, minuit au prorata), la statistique du jour UTC par sens, par classe et par groupe de pavillon (vus seulement : le non-vu arrive en P4b), close chaque nuit à 00:10 UTC et à la demande, partielle sur le jour ouvert ; le recalcul d'un objet dessiné sur l'historique avec sa progression ; la purge des jeux de données échus à 00:30 UTC ; les périodes de référence mesurées ici.
P4b Les mesures, la lecture : les trois lectures du non-vu — comptée (les trous de trace qui enjambent la ligne), estimée (l'écart à la référence), le signal (les extinctions à moins de 25 milles) — jamais additionnées, chacune bornée par la couverture ; les parts de référence ; la série d'un objet (la forme de maritime/v1) ; GET /api/objects/<clé>/stats/ sous session ou clé de service, sans aucun navire ; le graphe SVG tracé par le serveur ; la fiche complète (le tableau classes × sens, ce qui manque, les sources, la provenance au survol) ; un objet sans période de référence n'est pas publiable.
P5 Le flux et la mesure : le flux gratuit aisstream.io (manage.py ais_stream, sous sa propre unité) abonné aux seules boîtes des objets publiés (+ 50 milles, relues toutes les dix minutes), écrit par lots dans un jeu de données de séquence par jour UTC et par connexion, reconnexion à recul exponentiel, son état en base (la santé dit stream : live, stale, absent, error) ; ses conditions lues le 27 oct. 2026 — aucune n'est publiée : la source reste qa_only et n'alimente rien tant que le propriétaire ne l'a pas confirmée ; la classe A et la classe B (la pêche, la plaisance) abonnées ; la géométrie en Python pur mesurée sur un million de positions synthétiques et vingt objets (docs/MESURES.md : D2 tient par jour couvert, D10 non tranchée tant que le rythme réel du flux n'est pas mesuré).
P6 Les livraisons : deux contrats maîtres — maritime/v1 (les objets, leur période de référence, une entrée par jour dans la forme de la série, pour l'écran du jeu, le plan et l'analyse systémique) et gate_counts/v1 (les sept portes du jeu, ses classes, ses trois cases de pavillon, pour son moteur) —, fermés, avec leurs fixtures et un contrôle en Python pur que les lecteurs copient ; une livraison est figée par empreinte (ni modifiée ni supprimée, jusque dans la base), bornée à 92 jours, servie en JSON canonique sous clé de service ou session par la porte DCS, chaque lecture au journal ; un objet sans période de référence est omis et dit, une source qa_only n'alimente rien ; deux réserves : app_context (ce qu'osint apporte sur un objet) et app_mcp (un point d'accès MCP en lecture, sans navire).
L1 La densité du trafic civil pour la carte tactique du jeu : un troisième contrat, traffic_cells/v1 — dans une boîte et au rang H3 de la partie (5, 6 ou 7), le nombre d'identités distinctes (MMSI, sinon contact) vues par cellule et par jour complet, et sa moyenne, aux classes du jeu ; une cellule absente veut dire aucun navire vu (l'AIS terrestre est aveugle au large), jamais aucun présent ; aucun seuil de petits nombres ; 200 000 lignes au plus, refusé au-delà, jamais tronqué ; rien par navire.

Ce qui vient

P7–P9 Les frères : le jeu (la lentille « Maritime », la source ais des comptes de porte), intell (exchange/v1), le plan.
P10 Le déploiement sur mda.aesop.methodart.fr.

La santé du service : /api/health/. Les comptes sont créés par un administrateur (pas d'inscription publique).