La littérature sur le commandement et contrôle déborde de marchés publics, de doctrine et d'acronymes ; elle est en revanche pauvre sur la question qu'un ingénieur veut réellement voir traitée : comment en construire un ? Cette série en quatre parties retrace la construction d'un système C2 de défense depuis un dépôt vierge jusqu'au déploiement opérationnel. La partie 1 pose les fondations — portée, architecture, schémas et stack technique. Les parties 2 à 4 abordent la fusion, l'affichage, puis le travail d'interopérabilité et de sécurité qui permet à la plateforme de franchir la porte.

La série complète le Guide complet des systèmes de commandement et contrôle (C2), qui balaie l'ensemble du domaine sur le plan architectural. Ici, on va plus étroit et plus profond : une seule plateforme d'exemple, avec les décisions prises, les compromis explicités et le raisonnement d'ingénierie rendu visible. L'exemple est suffisamment générique pour s'appliquer à différents échelons ; les principes sont transférables.

Étape 1 : choisir une portée et s'y tenir

La première décision est celle qu'on saute le plus souvent, et c'est elle qui détermine si la plateforme atteindra les opérations. Un système C2 conçu pour servir tous les échelons — tactique, opérationnel, stratégique — n'en sert généralement aucun correctement. Choisissez-en un.

Les questions structurantes :

Échelon. Brigade et en dessous, cela signifie des budgets de latence en secondes, un modèle de données à plat et une interface utilisateur pour opérateurs sous tension, avec des gants sur une tablette en plein soleil. Division à corps d'armée, cela signifie des latences plus longues, des outils de planification plus riches et des officiers d'état-major sur stations de travail. Niveau interarmées et national, cela implique des modèles hiérarchiques, du renseignement compartimenté et une expérience d'analyste de classe bureau. Le traitement complet de la manière dont l'échelon façonne l'architecture se trouve dans Qu'est-ce qu'un système C2 ?.

Domaine. Terre, mer, air ou interarmées. Chacun a ses propres familles de capteurs, ses standards de messagerie et ses workflows opérateurs. Une plateforme multi-domaine représente un effort d'ingénierie nettement plus lourd qu'une plateforme mono-domaine et se justifie rarement pour une première construction.

Coalition ou national. Un déploiement en coalition signifie que l'interopérabilité OTAN devient un critère d'achat dès le premier jour. Le strictement national permet un modèle de données souverain avec une passerelle OTAN ajoutée plus tard. Les compromis côté interopérabilité sont détaillés dans Le guide complet de l'interopérabilité OTAN.

Plafond de classification. La classification la plus élevée que la plateforme traitera détermine l'effort d'accréditation, la topologie réseau et les choix d'outillage. Une plateforme NATO RESTRICTED est environ un ordre de grandeur plus simple à construire qu'une plateforme NATO SECRET.

Écrivez les décisions de portée. Étiquetez chaque ticket d'architecture avec la décision de portée qu'il sert. La dérive de portée — l'ajout progressif d'échelons, de domaines ou de classifications pendant le développement — est la plus grande cause unique d'échec de programme.

Pour l'exemple fil rouge de cette série, nous choisissons : C2 tactique au niveau brigade, multi-domaine (conscience situationnelle terre + air), interopérable OTAN, plafond de classification NATO SECRET. D'autres choix décaleraient des décisions précises tout au long de la série, mais pas l'architecture globale.

Étape 2 : adopter l'architecture à quatre couches

Toute plateforme C2 opérationnelle converge vers la même architecture à quatre couches. Capteurs, traitement, affichage, communications. Les noms varient ; les responsabilités, non. La règle architecturale est simple : chaque couche a une responsabilité unique, les interfaces entre couches sont explicites, et aucun concept ne fuit à travers les frontières de couche.

Couche capteurs. Adaptateurs qui traduisent les formats natifs des capteurs (ASTERIX, STANAG 4586, CoT, AIS NMEA, ADS-B) vers la piste canonique interne de la plateforme. Les adaptateurs sont des convertisseurs de données unidirectionnels ; ils ne prennent jamais de décisions sur les pistes.

Couche de traitement. Fusion de pistes, normalisation, magasin de pistes faisant autorité. La piste est l'unité de donnée sur laquelle opère le reste de la plateforme. Cette couche est le sujet de la partie 2.

Couche d'affichage. L'image opérationnelle commune (COP) et son outillage périphérique. Tâches, messagerie, planification. Frontend web consommant des APIs WebSocket et REST issues de la couche de traitement. Sujet de la partie 3.

Couche de communication. Bus de messages, réplication store-and-forward, passerelles entre enclaves, intégration des radios tactiques. Sujet de la partie 4, aux côtés de l'interopérabilité et de la sécurité.

Matérialisez ce découpage en dépôts et services réels dès le premier jour. Résistez à la tentation de « commencer avec un seul service et extraire plus tard » — l'extraction ne se fait jamais proprement, et les frontières de couches se brouillent au point de coûter une année de travail à réparer.

Étape 3 : concevoir le schéma canonique des pistes

La piste est la structure de données centrale de toute plateforme C2. Chaque adaptateur produit des pistes. Chaque décision de fusion met à jour des pistes. Chaque COP affiche des pistes. Chaque journal d'audit référence des pistes. Si le schéma est juste, la majeure partie du reste de la plateforme devient simple ; s'il est faux, le coût se compose sur des années.

Le schéma de piste minimum viable comprend :

  • Identifiant de piste. Stable, globalement unique, jamais réutilisé. UUIDv7 ou un préfixe typé suivi d'un UUID sont des valeurs par défaut sûres.
  • Identité. Ce qu'est la piste. Taxonomie de type (navire, aéronef, véhicule, personne, unité) plus sous-type et numéro de queue / de coque / indicatif lorsqu'ils sont connus. L'identité est fusionnée dans le temps ; ne l'inscrivez pas dans l'identifiant.
  • Position. Latitude, longitude, altitude. Système de coordonnées explicite (WGS84 par défaut sûr). Ellipse d'incertitude — pas un nombre unique ; matrice de covariance ou demi-grand/demi-petit axe avec azimut.
  • État cinématique. Vitesse (vecteur), taux de virage, route et vitesse dérivées. Horodaté.
  • Ensemble de sources. Quels adaptateurs ont contribué à cette piste. Classification de la source, diffusion (releasability), confiance.
  • Horodatages. Trois temps distincts : temps d'observation (quand le capteur a vu la cible), temps de rapport (quand le message a quitté le capteur), temps d'ingestion (quand la plateforme l'a reçu). Les confondre est une source de bugs récurrente.
  • État du cycle de vie. Tentative, confirmée, mature, en perte, perdue. Piloté par le moteur de fusion ; visible depuis le COP.
  • Enveloppe de classification. Classification effective calculée à partir de l'ensemble des sources. Marqueurs de diffusion. Marqueurs de compartiment le cas échéant.
  • Confiance et certitude. Confiance au niveau piste ; certitude par attribut là où cela importe (p. ex. la position a une certitude élevée mais l'identité reste tentative).

Versionnez le schéma par évolution additive. Les nouveaux champs sont optionnels ; les champs existants ne changent jamais de sens. Les ruptures ne sont acceptées qu'aux versions majeures de la plateforme, avec une migration documentée. Le traitement détaillé, incluant les motifs de normalisation d'identité et les stratégies d'évolution de schéma, est dans Les défis de l'intégration de données de défense.

Idée clé : le schéma de piste est un contrat avec lequel la plateforme vit pendant toute sa vie opérationnelle. Consacrez un sprint à bien le concevoir ; une semaine à le documenter ; engagez-vous à une évolution strictement additive ; partagez une bibliothèque cliente générée par code avec chaque consommateur. La discipline est ingrate et structurelle ; le coût de l'omettre apparaît deux ans plus tard sous forme d'un refactor de plusieurs mois.

Étape 4 : choisir le stack technique

Le stack technique d'une plateforme C2 de défense doit équilibrer quatre contraintes : la survivabilité opérationnelle (cycle de vie de 20 ans), la compatibilité avec l'accréditation (listes nationales d'approbation), les compétences existantes de l'équipe et l'ergonomie d'ingénierie qui détermine la vélocité de sprint. Les choix ci-dessous constituent un ensemble défendable, pas le seul.

Services backend : un langage typé avec une histoire de concurrence mature. Go et Rust sont les deux choix forts pour les nouveaux programmes ; Java reste un titulaire défendable. Évitez les langages de niche à un seul mainteneur — la plateforme survivra à la communauté du langage.

Bus de messages : Kafka ou NATS JetStream comme journal d'événements durable ; le choix entre les deux est traité dans Files de messages pour les pipelines de données de défense. Pour les petits déploiements, NATS est plus léger ; pour les grands, Kafka a fait ses preuves en opérations.

Base de données géospatiale : PostGIS sur PostgreSQL est le défaut. Mature, compatible avec l'accréditation, passe à l'échelle de milliards de points avec une indexation appropriée. Les détails d'ingénierie sont dans PostGIS pour les données géospatiales de défense.

Base de séries temporelles : TimescaleDB en extension de PostGIS, ou InfluxDB comme magasin séparé. Les historiques de capteurs et la télémétrie y appartiennent — pas dans le magasin opérationnel des pistes.

Stack frontend : React ou Vue, typé (TypeScript). Cesium pour la 3D et les vues globe ; Mapbox GL ou MapLibre pour la 2D. Les compromis détaillés du rendu cartographique sont dans Rendu cartographique temps réel pour le C2 militaire.

Transport temps réel : WebSocket pour le navigateur, MQTT pour l'edge tactique, gRPC entre services à l'intérieur du datacenter. Chacun a une niche claire et ils coexistent.

Authentification et autorisation : OpenID Connect pour les utilisateurs humains (avec intégration de la PKI nationale lorsque c'est requis), mTLS entre services avec des certificats à durée de vie courte. RBAC et classification superposés via un moteur de politique dédié — Open Policy Agent est un choix défendable. Le motif détaillé est dans Contrôle d'accès basé sur les rôles dans les systèmes C2 de défense.

Déploiement : conteneurs (OCI), orchestrés par Kubernetes en cloud ou en gros on-prem ; systemd ou k3s pour les nœuds d'edge tactique. Les mêmes artefacts s'exécutent sur tout le spectre ; seule l'orchestration change.

Résistez à la sur-ingénierie. Une première construction n'a pas besoin d'un service mesh, d'une abstraction multi-cloud ou d'un framework maison. Les choix ennuyeux — bien supportés, largement déployés, avec un dossier d'accréditation mature — sont les bons choix pour la défense.

Étape 5 : mettre en place la structure du dépôt

Décidez tôt entre monorepo et multi-repo. Pour une nouvelle plateforme avec une seule équipe, le monorepo est généralement le bon choix : les bibliothèques partagées (schéma, client RBAC, télémétrie) vivent à côté des services, les changements circulent atomiquement et le système de build impose la cohérence. Le multi-repo ne devient attrayant que lorsque les frontières d'équipe divergent.

Une structure de premier niveau défendable :

  • schemas/ — schéma canonique des pistes, schémas de messages, contrats d'API. Bindings générés par code pour chaque langage consommateur.
  • adapters/ — adaptateurs de capteurs, un par type de source.
  • services/ — moteur de fusion, magasin de pistes, moteur de politique, service d'audit.
  • frontend/ — le COP et l'UI associée.
  • tools/ — outils opérationnels, harnais de tests, simulateurs.
  • deploy/ — manifestes Kubernetes, charts Helm, playbooks Ansible pour les nœuds d'edge tactique.
  • docs/ — décisions d'architecture (ADR), runbooks, dossiers d'accréditation.

Traitez le répertoire de documentation comme du code : revu, versionné, obligatoire. Les ADR (Architecture Decision Records) évitent à la plateforme de re-débattre des mêmes compromis tous les six mois à l'arrivée d'un nouvel ingénieur.

La suite

La partie 1 a cadré la plateforme. Portée choisie, architecture à quatre couches actée, schéma canonique des pistes conçu, stack technique choisi, dépôt structuré. Le squelette existe ; rien n'ingère encore un capteur ni n'affiche une piste.

Partie 2 : le moteur de fusion reprend le schéma et construit la couche qui ingère les rapports de capteurs, les corrèle en pistes et les expose au reste de la plateforme. C'est le cœur d'ingénierie du système C2, et c'est là que les décisions architecturales de la partie 1 sont confrontées à la réalité.

Avant de passer à la partie 2, arrêtez les décisions de portée et écrivez le schéma canonique des pistes. La série suppose que les deux sont en main.