Les parties 1 et 2 ont produit des pistes fiables. La partie 3 construit la surface que l'opérateur voit réellement. L'image opérationnelle commune est la couche sur laquelle la plateforme est jugée — réussissez-la et l'indulgence se propage à tout le reste de la stack ; ratez-la et un pipeline de fusion techniquement correct sera désactivé dès la deuxième semaine d'opérations. Les motifs architecturaux sont établis (voir L'image opérationnelle commune : comment elle est construite dans les logiciels de défense modernes) ; la partie 3 les transforme en décisions d'ingénierie concrètes.

Étape 1 : la stack frontend

Pour la plateforme de référence, le COP est une application navigateur. Le choix entre natif et web est tranché depuis plus d'une décennie en faveur du web ; l'empreinte native résiduelle concerne les plateformes portatives spécialisées (l'écosystème ATAK — voir Développement de plugins ATAK) plutôt que les afficheurs de poste de commandement.

La stack défendable :

  • React avec TypeScript pour la coquille applicative. La maturité de l'écosystème, la disponibilité des profils au recrutement et l'outillage compatible accréditation en font le choix sûr pour une plateforme à 20 ans. Vue est défendable ; Svelte n'est pas encore un choix de niveau achat public pour la défense.
  • Cesium pour la vue globe et la 3D — terrain, volumes aériens, traces satellitaires. Accéléré par WebGL, mature, standard de facto pour le 3D géospatial en défense.
  • Mapbox GL ou MapLibre pour la vue carte 2D. Tuiles vectorielles pour la vitesse ; tuiles raster en repli pour le mode hors-ligne. Les compromis et le plafond de performance sont détaillés dans Rendu cartographique temps réel pour le C2 militaire.
  • Zustand ou Redux Toolkit pour l'état. Le volume de mises à jour de pistes en streaming rend l'état React naïf intenable ; utilisez un store avec sélecteurs à références stables et comparaisons shallow-equal.
  • Ant Design ou Mantine pour l'UI environnante — panneaux, modales, formulaires. Résistez à la tentation de bâtir un design system sur mesure dès la première itération ; choisissez une bibliothèque mature et thémez-la aux conventions de défense.

Une décision moins évidente : gardez le COP en application monopage, pas en site multipage. Les opérateurs ne naviguent pas. Ils ouvrent le COP une fois et l'utilisent pendant des heures. Le rechargement de page est la mauvaise abstraction ; des vues et panneaux dans une coquille unique sont la bonne.

Étape 2 : symbologie militaire, faite correctement

Les pistes s'affichent sous forme de symboles. Le catalogue de symboles est régi par MIL-STD-2525D (ou la variante OTAN équivalente APP-6). Une symbologie maison est un drapeau rouge à l'achat public et un bloqueur d'interopérabilité : dès que la plateforme s'intègre à un système allié, le moindre symbole discordant déclenche un échec immédiat de conformité.

Utilisez une bibliothèque maintenue. L'implémentation open-source milsymbol est le choix de facto pour les COP web ; elle produit le jeu de symboles standard en SVG ou en éléments canvas. La bibliothèque gère l'affiliation (ami, hostile, neutre, inconnu), les marqueurs d'échelon, les textes d'identification et les modificateurs qui transforment un symbole d'infanterie générique en « 1er bataillon, mécanisé, en posture défensive ».

Le motif d'intégration : le moteur de fusion émet des pistes assorties d'attributs d'identité ; le COP recherche le SIDC (Symbol Identification Code) MIL-STD-2525 approprié pour ces attributs ; la bibliothèque rend le symbole. Cachez les symboles rendus par SIDC ; le même symbole est réutilisé des milliers de fois dans une image opérationnelle typique.

Un détail pratique à signaler : MIL-STD-2525D contient des milliers de symboles distincts. Presque aucun scénario opérationnellement pertinent n'en utilise plus de quelques centaines. Construisez le catalogue de l'intérieur vers l'extérieur — partez de ce que produisent les capteurs de la plateforme, élargissez à mesure que de nouvelles classes de capteurs arrivent.

Étape 3 : mises à jour temps réel via WebSocket

La tâche du COP est de refléter la base de pistes en quasi-temps-réel. Le polling ne passe pas à l'échelle ; le WebSocket est la réponse structurelle. Le motif architectural :

Un service de passerelle maintient des connexions WebSocket ouvertes vers chaque navigateur. Il s'abonne aux sujets tracks.updates et tracks.lifecycle du moteur de fusion. Lorsqu'une mise à jour de piste arrive, la passerelle évalue le filtre propre à la connexion (quelle zone, quels rôles, quelles classifications) et pousse la mise à jour vers le navigateur. Le navigateur applique la mise à jour à son store d'état local ; React ne re-rend que les symboles affectés.

Les détails d'ingénierie moins évidents qui déterminent si cela tient à l'échelle :

Le filtrage se fait côté serveur. Pousser chaque piste vers chaque navigateur ne fonctionne pas — à 10 000 pistes mises à jour plusieurs fois par minute, le fil comme le navigateur étouffent. Chaque connexion porte un filtre d'abonnement (bornes de viewport, couches basées sur les rôles, filtre de classification) et seules les mises à jour correspondantes circulent.

Mises à jour incrémentielles (deltas), pas des remplacements complets. Une mise à jour de piste est partielle — la position a changé, l'état du cycle de vie a changé, l'identité a été affinée. Le navigateur applique le patch à sa copie locale. Les payloads de piste complets ne sont envoyés qu'à l'abonnement initial et lors des migrations de schéma.

Reconnexion avec récupération d'état. Les connexions WebSocket tombent, surtout sur les réseaux tactiques. À la reconnexion, le navigateur échange son dernier numéro de séquence vu avec la passerelle, qui rejoue les mises à jour manquées depuis le bus. Pas de perte d'état, pas de récupération complète.

Gestion de la contre-pression (backpressure). Un client lent ne doit pas bloquer la passerelle. La profondeur de file par client est bornée ; lorsque la file déborde, le client est largué et forcé de se reconnecter avec une récupération d'état complète. Mieux vaut un opérateur qui se reconnecte que tous les opérateurs figés.

Étape 4 : filtrage basé sur les rôles et classification

Tous les opérateurs ne voient pas toutes les pistes. Le COP d'un chef de section d'infanterie n'affiche pas les zones d'engagement de défense aérienne. Un compte NATO-RESTRICTED ne voit pas les pistes classifiées SECRET. La plateforme applique cela en deux endroits : le filtre de passerelle (quoi envoyer) et le moteur de politique (envoyer ou non).

Le filtre de rôle est une configuration par utilisateur et par session : quels types de pistes, quelles zones d'opérations, quelles couches d'affichage. L'utilisateur peut ajuster dans la limite de son autorisation ; le système applique la borne supérieure. Le filtre de classification n'est pas négociable : la classification effective d'une piste (calculée en fusion, propagée à la passerelle) doit être inférieure ou égale à l'habilitation de l'utilisateur. Des contre-vérifications aux niveaux API et base de données — jamais uniquement dans l'UI — sont la règle. Le motif détaillé figure dans Contrôle d'accès basé sur les rôles dans les systèmes C2 de défense.

Une note opérationnelle : construisez l'UI de configuration des rôles avec la communauté des opérateurs, pas en vase clos. Les valeurs par défaut comptent. Un utilisateur d'infanterie ne veut pas commencer chaque session en désactivant six couches de données de défense aérienne non pertinentes. Un opérateur d'escadre aérienne ne veut pas commencer chaque session en activant les couches de défense aérienne que son prédécesseur avait désactivées. Des valeurs par défaut basées sur le rôle qui correspondent au métier réel de l'opérateur divisent par deux le niveau de base de frustration.

Idée clé : Le COP qui gagne une démo est dense, animé et plein de surcouches. Le COP qui gagne en opérations est sobre, rapide et n'affiche que ce dont l'opérateur a besoin. Par défaut, optez pour moins de symboles, plus grands, à fort contraste. Laissez les opérateurs ajouter du détail ; ne les démarrez pas à la densité d'information maximale.

Étape 5 : ergonomie opérateur

Un COP qui échoue ergonomiquement échoue opérationnellement. La discipline se construit à partir d'une poignée de règles non négociables.

Indication de piste périmée. Lorsque l'état du cycle de vie d'une piste passe à « en perte » ou « perdue », le symbole change — typiquement plus terne, éventuellement contouré, avec un indicateur d'âge. Les opérateurs doivent voir d'un coup d'œil quelles pistes sont fiables.

UI de résolution de conflits. Lorsque deux opérateurs éditent la même piste ou la même tâche simultanément, la plateforme doit faire remonter le conflit, pas écraser silencieusement un côté. Last-writer-wins par attribut est la valeur par défaut ; réconciliation explicite pour les attributs à fort enjeu.

Conception clavier d'abord. Les UI à la souris seule échouent en opérations sous stress. Chaque action courante a un raccourci clavier ; les raccourcis sont documentés dans le produit et découvrables.

Manipulation tactile et avec gants pour les cibles durcies (ruggedized). Le même COP tourne dans les postes de commandement sur des stations de travail et sur des tablettes ruggedized aux positions avancées de brigade. Les cibles tactiles sont dimensionnées pour les gants ; les modes à fort contraste sont de première classe. Le motif plus large figure dans UX durcie pour opérateurs militaires.

Fonctionnement hors-ligne. Les déploiements en edge tactique perdent la connectivité. Le COP doit fonctionner sur son cache local, rejouer les actions opérateur en file à la reconnexion et indiquer clairement quelles données sont périmées. Le motif architectural figure dans Applications militaires offline-first ; le volet cartographique hors-ligne dans Cartes hors-ligne avec MBTiles et PMTiles.

Étape 6 : au-delà de la carte — tableaux de bord et panneaux

Le COP, c'est plus qu'une carte. Les opérateurs ont besoin d'interfaces de tasking, de composition de messages, d'outils de planification, de panneaux de renseignement, de vues de logs. La règle UX transversale à la plateforme : chaque panneau obéit aux mêmes conventions d'interaction. Si sélectionner une piste sur la carte la met en évidence dans un panneau latéral, alors sélectionner une piste dans n'importe quel panneau doit la mettre en évidence sur la carte. L'incohérence à cette couche est l'échec UX le plus courant dans les logiciels de défense.

La séparation architecturale à maintenir : la vue carte est un panneau ; les tableaux de bord et panneaux latéraux sont d'autres panneaux ; ils partagent le même état de sélection via le store central. Ajouter un nouvel outil d'analyste, c'est un nouveau panneau, pas une nouvelle application. Les motifs d'architecture de tableau de bord figurent dans Architecture de tableau de bord C2.

Étape 7 : cibles de performance

Les cibles du COP sont plus serrées qu'elles n'en ont l'air :

  • Chargement initial sous 3 secondes sur un portable d'edge tactique avec assets statiques en cache.
  • Latence de mise à jour de piste sous 200 ms entre l'émission par la passerelle et le déplacement visible du symbole dans le navigateur.
  • 60 FPS soutenus en rendu cartographique avec jusqu'à 10 000 pistes visibles.
  • Pan-and-zoom réactif aux échelles cartographiques tactiques typiques (1:50 000 à 1:1 000 000).
  • Mémoire bornée — le navigateur doit tourner toute la journée sans fuir. Profilez chaque release.

Ces cibles sont atteignables avec la stack choisie ; les manquer est généralement le résultat d'un raccourci architectural plus tôt dans le pipeline (filtrage côté serveur non implémenté, payloads complets au lieu de deltas, gestion d'état naïve).

La suite

La partie 3 a construit le COP. Les pistes s'affichent avec la bonne symbologie ; les mises à jour streament en WebSocket ; les opérateurs ne voient que ce pour quoi ils sont habilités ; l'ergonomie soutient les opérations réelles. La plateforme est désormais utilisable par un opérateur — mais pas encore livrable.

La partie 4 ferme la boucle : ponts d'interopérabilité OTAN (CoT, MIP4, STANAG 4559), marquage de classification et application des règles de diffusion, pipeline DevSecOps qui produit les preuves d'accréditation, et déploiement air-gapped pour l'usage en edge tactique. Après la partie 4, la plateforme est déployable opérationnellement.