Dix sources civiles, un module par source : le dual-use en pratique

OC2-Edge est conçu pour le champ de bataille. Les propriétés qui en résultent ne sont pas militaires par nature : fonctionner hors ligne d’abord, dégrader de manière contrôlée, servir des cartes locales sans dépendre d’un cloud. Ce sont exactement les propriétés qui manquent aux outils de gestion de crise quand le réseau tombe, c’est-à-dire au moment où on en a besoin.

Cet article s’adresse aux acteurs de la sécurité civile et de la gestion de crise : préfectures, services d’incendie et de secours, opérateurs d’importance vitale, ONG. Il montre la COP (Common Operational Picture, image commune de situation) hors du champ défense, décrit dix sources de données civiles ouvertes portées chacune par un module, et assume le raisonnement industriel qui sous-tend cette ouverture.

La même COP, un autre théâtre

La COP d’OC2-Edge s’affiche dans un simple navigateur, sur tuiles cartographiques hors ligne, avec des modes LIVE et MAQUETTE explicites. Rien dans cette chaîne n’est spécifique à un usage militaire. Une cellule de crise départementale a le même besoin qu’un poste de commandement tactique : une image partagée, tenue à jour quand les liens le permettent, exacte sur ce qu’elle sait et explicite sur ce qu’elle ne sait pas.

La différence est le contenu. Sur un théâtre civil, les pistes ne viennent pas de senseurs militaires : elles viennent de sources ouvertes, publiques, documentées. Chacune se branche par un module signé, au même titre que n’importe quel module du socle.

La signature et la révocation gardent leur sens hors défense : une cellule de crise qui affiche une donnée sur sa COP engage des décisions d’évacuation ou d’engagement de moyens. Savoir quel module a produit quelle couche, avec quelle version et quelle source, n’est pas une exigence militaire ; c’est une exigence de responsabilité.

Dix sources, dix modules

Le catalogue de démonstration couvre dix sources civiles ouvertes. Chaque ligne correspond à un module autonome, installable et révocable séparément.

Domaine	Données	Source ouverte
Trafic aérien	Positions ADS-B des aéronefs	OpenSky Network [1]
Trafic maritime	Positions AIS des navires	Réseaux de récepteurs AIS coopératifs
Sismologie	Événements sismiques	USGS (API FDSN) [2] et EMSC [8]
Catastrophes	Alertes multi-aléas mondiales	GDACS [3]
Orbites	Éléments orbitaux des satellites	CelesTrak [4]
Transport	Réseaux et horaires de transport public	Flux GTFS [5]
Incendies	Détections thermiques satellitaires	NASA FIRMS [6]
Météo	Prévisions et observations	Open-Meteo ou services OGC
Hydrologie	Niveaux et débits des cours d’eau	Vigicrues ou équivalent national
Imagerie d’urgence	Cartographie rapide de zones sinistrées	Copernicus EMS [7]

Le choix de dix sources n’est pas un plafond : c’est le périmètre de la démonstration. Chaque module suit le parcours outillé standard du projet, décrit dans Un module en une heure : manifeste déclaratif, signature, isolation WASI, installation par le magasin de modules.

Deux exemples fixent les idées. Le module ADS-B interroge l’API d’OpenSky Network sur l’emprise configurée et publie les positions d’aéronefs comme pistes sur la COP, avec leur horodatage source [1] ; un vol sanitaire ou un moyen aérien de lutte contre l’incendie devient un objet de situation au même titre qu’une piste militaire sur l’autre théâtre. Le module FIRMS consomme les détections thermiques satellitaires de la NASA et les affiche comme zones datées [6] ; la donnée est une détection, pas une vérité terrain, et la COP la présente comme telle, avec sa source et son âge. Cette discipline d’affichage (source, horodatage, fraîcheur) vaut pour les dix modules ; elle vient du socle, pas des connecteurs.

Le socle commun des connecteurs

Dix sources auraient pu produire dix intégrations disparates. Le socle impose aux connecteurs trois contrats communs, et c’est ce qui rend l’ensemble tenable en conditions dégradées.

L’emprise géographique. Chaque connecteur reçoit une zone d’intérêt et ne demande à sa source que ce qui la concerne. Une cellule de crise départementale ne télécharge pas le trafic aérien mondial ; elle suit ce qui survole son emprise.

La décimation. Chaque connecteur sait réduire : cadence de rafraîchissement abaissée, précision réduite, objets secondaires filtrés. La décimation est déclarée dans le manifeste du module, par paliers, et la COP affiche le palier en vigueur. La dégradation est contrôlée et visible, jamais silencieuse.

Le budget d’octets par source. L’opérateur alloue à chaque connecteur un budget de transfert explicite. Sur un lien confortable, les budgets sont larges ; sur un lien radio ou satellitaire partagé, l’arbitrage entre sources devient une décision d’opérateur, pas un hasard de congestion. Un connecteur qui atteint son budget décime ou s’arrête, il ne déborde pas sur les autres.

Ces trois contrats sont le cœur réutilisable : écrire un onzième connecteur, c’est implémenter ces trois interfaces et décrire la source dans le manifeste. Les connecteurs sont isolés en WASI : un connecteur ne voit que sa source déclarée et son budget, et la défaillance d’une source (API indisponible, format modifié, données aberrantes) reste confinée au module concerné. Les neuf autres sources continuent d’alimenter la COP, et l’écart est journalisé.

Cas d’emploi : quand le réseau est tombé

Le scénario de démonstration gestion de crise enchaîne trois situations.

Avant la crise, la préparation hors ligne : les tuiles cartographiques de la zone, les référentiels (réseaux, établissements sensibles) et les modules sont chargés sur les nœuds. Une clé USB suffit à livrer les cartes à un poste isolé ; aucun nœud ne dépend d’un serveur distant pour afficher sa COP. Cette préparation est aussi une question de maîtrise des données : les données de situation d’une cellule de crise restent sur ses nœuds, sous sa responsabilité, sans transiter par un service en nuage soumis à un contrat, à une juridiction ou à une panne extérieurs. Le hors ligne d’abord n’est pas un mode dégradé du nuage ; c’est l’architecture nominale, et le nuage n’y est jamais requis.

Pendant la crise, la connectivité intermittente : les connecteurs alimentent la COP tant que des liens existent, avec décimation à mesure que la bande passante se réduit. Quand l’infrastructure de télécommunications tombe, les nœuds continuent en maillage direct, de proche en proche, sans infrastructure : la COP locale reste partagée entre les nœuds joignables, datée et honnête sur sa fraîcheur.

Pour l’exercice, le mode MAQUETTE : les mêmes modules rejouent des données enregistrées, avec un marquage explicite à l’écran. Un exercice ne se confond jamais avec la situation réelle ; la distinction est portée par le socle, pas par la discipline des opérateurs.

Le matériel requis reste celui du socle : un calculateur modeste par nœud, un navigateur pour la COP. La démonstration gestion de crise s’exécute intégralement sur les nœuds émulés x86-64 et ARM64 du dépôt ; une cellule de crise peut donc l’évaluer sur ses propres machines, sans acquisition préalable, avec les mêmes ~930 tests automatisés en garantie de l’état du socle.

Le funnel dual-use, assumé

Ce positionnement n’est pas une diversification opportuniste, et il n’est pas non plus désintéressé. Le raisonnement est le suivant, et il est public.

Les propriétés techniques sont identiques : hors ligne d’abord, dégradation contrôlée, modules signés, cartes locales. Aucune bifurcation de code n’existe entre l’usage sécurité civile et l’usage défense ; ce sont les mêmes nœuds, les mêmes modules de socle, un autre catalogue de connecteurs.

Les cycles d’achat civils sont plus courts que les cycles d’acquisition de défense. Une préfecture, un service de secours ou une ONG peut évaluer, déployer et éprouver le socle sur des délais que la défense ne permet pas.

La sécurité civile est donc un terrain de preuve : chaque déploiement civil produit des retours d’emploi réels, des heures de fonctionnement en conditions dégradées et des contributions au socle commun des connecteurs, qui bénéficient au projet entier. Le chemin inverse vaut aussi : les exigences défense (signature, révocation, emploi hors ligne) élèvent le niveau des outils servis à la sécurité civile. La démonstration gestion de crise se rejoue sur émulateur et peut être présentée sur demande.

Sources

OpenSky Network, « The OpenSky Network : Free ADS-B and Mode S data », 2024, https://opensky-network.org/
USGS Earthquake Hazards Program, « FDSN Event Web Service », 2024, https://earthquake.usgs.gov/fdsnws/event/1/
GDACS, « Global Disaster Alert and Coordination System », 2024, https://www.gdacs.org/
CelesTrak, « Current GP Element Sets », 2024, https://celestrak.org/
MobilityData, « GTFS : General Transit Feed Specification », 2024, https://gtfs.org/
NASA, « FIRMS : Fire Information for Resource Management System », 2024, https://firms.modaps.eosdis.nasa.gov/
European Commission, « Copernicus Emergency Management Service », 2024, https://emergency.copernicus.eu/
EMSC, « Euro-Mediterranean Seismological Centre », 2024, https://www.emsc-csem.org/