L'Ukraine n'a pas construit un seul système de connaissance de la situation. Elle en a construit une douzaine, en parallèle, sous le feu, puis a passé trois ans à les relier entre eux. Le résultat n'est pas un diagramme d'architecture bien ordonné — c'est un écosystème de plateformes cloud, d'applications pour tablettes, de calculateurs d'artillerie et de pipelines de vidéo de drones, chacun optimisé pour une couche différente de la chaîne de frappe, faiblement fédérés par une poignée de passerelles et de formats de données. Pour les ingénieurs occidentaux habitués aux programmes C2 mono-maître d'œuvre et décennaux, la question intéressante n'est pas de savoir si cet écosystème est élégant. Il ne l'est pas. La question intéressante est de savoir pourquoi il fonctionne, et ce qui survit à la transposition vers un contexte d'alliance.

1. la pile en un coup d'œil — de nombreux outils, un seul objectif : raccourcir la boucle capteur-tireur

Chaque composant de la pile SA ukrainienne existe pour comprimer le temps entre le moment où un capteur voit une cible et celui où une arme l'affecte. C'est le principe organisateur, et il explique la fragmentation apparente. Delta fournit l'image opérationnelle commune au niveau du théâtre. Kropyva exécute le flux de travail reconnaissance-et-tirs sur une tablette de bataillon. La famille GIS Arta coordonne l'artillerie distribuée. Les stations de contrôle au sol des drones font remonter la vidéo en direct et les coordonnées. Le cluster Brave1 est le moteur d'achat et d'intégration qui continue de produire de nouveaux outils.

Aucun d'entre eux n'a commencé comme un grand programme unifié. Ils sont nés de projets de volontaires, d'efforts d'ONG et de petites entreprises, chacun résolvant un problème urgent pour l'unité qu'il avait devant lui. La standardisation est venue plus tard, rétroactivement, poussée par le besoin pratique de faire en sorte que la désignation de cible d'un opérateur de drone aboutisse dans la même image que celle qu'un commandant d'artillerie regardait déjà. Cet ordre — d'abord la capacité, ensuite l'intégration — est le fait structurel le plus important de tout l'écosystème.

2. Delta — la couche cloud de connaissance de la situation, l'image opérationnelle commune, l'exposition aux exercices de l'OTAN

Delta est ce qui se rapproche le plus, en Ukraine, d'une image opérationnelle commune à l'échelle du théâtre. Développée sous l'égide du pôle innovation du ministère de la Défense, c'est une plateforme web-et-mobile qui agrège les positions amies et ennemies, les rapports de renseignement, les flux de capteurs et le statut des unités dans une carte unique qui s'étend d'un état-major de brigade jusqu'au niveau de l'état-major général. Sur le plan architectural, elle est nativement cloud : un client navigateur, des applications mobiles, et un back-end qui ingère des rapports provenant aussi bien d'humains que de machines et les résout en une base de données de pistes partagée.

Ce qui rend Delta intéressante pour un ingénieur en interopérabilité, c'est son modèle de données. Plutôt que de se coupler étroitement à un client particulier, Delta expose le format Delta — une représentation structurée d'entités, d'observations et de surcouches que d'autres systèmes peuvent lire et écrire. Ce découplage est ce qui permet à une application pour tablette, à une station de drone et à un navigateur d'état-major de contribuer tous à la même image sans partager de code. Delta a été présentée à des publics de l'OTAN lors d'exercices de l'alliance, où ses interfaces conformes aux standards lui permettent d'échanger des pistes avec des systèmes de coalition plutôt que de vivre dans un silo national.

3. Kropyva — l'application d'artillerie et de reconnaissance, le calcul de contrôle des tirs, le flux de travail sur tablette

Là où Delta est l'image du théâtre, Kropyva est la surface de travail d'un bataillon au combat. Construite par l'effort Army SOS d'origine volontaire, elle tourne sur une tablette Android durcie et regroupe deux tâches que les armées occidentales répartissent habituellement entre des systèmes distincts : le compte rendu de reconnaissance numérique basé sur une carte et le calcul du contrôle des tirs d'artillerie.

Le volet contrôle des tirs est la partie que les ingénieurs occidentaux sous-estiment. Kropyva effectue le calcul balistique — distance, azimut et corrections — transformant la référence de grille d'un observateur et une position de canon connue en une solution de tir en quelques secondes. Un observateur marque une cible sur la carte ; l'application calcule la géométrie canon-cible, applique les corrections météorologiques et de vitesse initiale, et produit les données que l'équipe de pièce affiche. La même tablette qui a dessiné la surcouche de reconnaissance produit la mission de tir, réduisant un flux de travail qui implique ailleurs un observateur avancé, un centre de direction des tirs et plusieurs relais radio à un seul appareil et un seul opérateur.

Cette intégration est délibérée. En gardant la reconnaissance et les tirs dans une seule application sur une seule tablette, Kropyva supprime les transferts où le temps et la précision se perdent. Ses pistes et désignations de cibles peuvent être poussées vers l'image plus large, de sorte qu'une mission de tir locale devient aussi une contribution à la connaissance de la situation au niveau du théâtre.

Idée clé : L'avantage de la pile ukrainienne ne réside pas dans une application unique — c'est que le calculateur d'artillerie, le flux de drone et la carte d'état-major écrivent tous dans un modèle d'entités partagé plutôt que les uns dans les autres. Le modèle de données est le point d'intégration, pas l'application. Chaque application est remplaçable ; l'image ne l'est pas.

4. la lignée GIS Arta — la coordination des tirs distribués, le schéma « Uber pour l'artillerie »

GIS Arta est le système qui a donné à l'écosystème son schéma distinctif. Conçu avant l'invasion à grande échelle, il s'est attaqué à un problème difficile de systèmes distribués : étant donné de nombreux capteurs générant des cibles et de nombreux canons de types et de disponibilités différents, comment associer chaque cible à l'arme la mieux positionnée et la mieux adaptée, rapidement, sans goulot d'étranglement humain ?

La réponse est devenue connue par analogie comme l'« Uber pour l'artillerie ». Une cible entre dans le système depuis n'importe quel observateur — un éclaireur, un drone, un radar. Le logiciel évalue quelles unités de tir sont à portée, disponibles et appropriées, et achemine la mission vers le canon optimal, à la manière dont une plateforme de VTC associe un passager au chauffeur le plus proche. L'effet rapporté de cet appariement a été une compression spectaculaire du calendrier d'engagement, des dizaines de minutes typiques d'une coordination manuelle à quelques minutes ou moins.

La lignée importe parce que le schéma GIS Arta — traiter les tirs comme un problème de répartition distribuée, optimiser l'allocation dans le logiciel, maintenir les humains sur l'approbation plutôt que sur l'acheminement — s'est propagé dans la manière dont le reste de l'écosystème conçoit le transfert de cible. Les outils ultérieurs ont hérité de l'hypothèse selon laquelle une désignation de cible est un message structuré à acheminer, et non un appel vocal à relayer.

5. les flux de drones et Brave1 — le cluster defense-tech, la vidéo de reconnaissance, la désignation de cible

La couche capteur de cet écosystème est massivement sans pilote. Des milliers de drones de reconnaissance et de frappe génèrent l'essentiel des données de cible fraîches, et leurs stations de contrôle au sol sont des participants à part entière de la pile SA, pas des éléments accessoires. Un opérateur de drone qui regarde la vidéo en direct peut marquer une coordonnée et pousser une désignation de cible directement dans l'image, où elle devient disponible pour la coordination des tirs en quelques secondes.

Brave1 est le cluster qui industrialise cela. Plateforme de coordination soutenue par le gouvernement, lancée pour connecter les développeurs, les unités militaires et les financements, Brave1 fonctionne à la fois comme une place de marché et comme un facteur déclencheur d'intégration pour la defense-tech ukrainienne. C'est là que de nouveaux outils sont découverts, testés auprès d'unités réelles et — point crucial — poussés vers la conformité avec les formats de données partagés afin de pouvoir se brancher sur Delta et la couche de tirs plutôt que de devenir une autre île. Les canaux Brave1 et Delta Marketplace sont désormais l'endroit où résident la source et la distribution d'une grande partie de ce logiciel.

L'effet est une boucle de rétroaction : une unité a besoin d'une capacité, une petite équipe la construit, Brave1 aide à la déployer et à l'intégrer, et les outils qui survivent convergent vers le modèle de données commun. C'est la pression de sélection, et non la conception centralisée, qui produit l'intégration.

6. comment les couches échangent les données — passerelles, CoT, API, les coutures d'intégration et leurs frictions

La fédération entre ces systèmes repose sur un petit nombre de mécanismes. Le format Delta et ses API sont l'épine dorsale principale : les systèmes lisent et écrivent des entités et des surcouches via des interfaces documentées. Lorsque des outils tiers et de coalition sont en jeu, Cursor-on-Target (CoT) — le schéma d'événements XML léger popularisé par ATAK — fait office de lingua franca, et des passerelles traduisent entre les événements CoT et le modèle d'entités natif de Delta.

Ces passerelles sont là où réside la friction. CoT est orienté événement et faiblement typé ; le modèle Delta est orienté entité et plus riche. Faire correspondre l'un à l'autre revient à décider comment un marqueur CoT transitoire devient une entité suivie persistante, comment l'identité et la qualité de la piste survivent à la traduction, et comment éviter les entités en double lorsque deux systèmes signalent le même objet. Chaque passerelle est, de fait, un traducteur partial, et deux passerelles peuvent produire des images subtilement différentes à partir des mêmes événements. La latence, la déduplication et la réconciliation d'identité sont les problèmes d'ingénierie récurrents — la même classe de problème que rencontre tout système de fusion multisource, résolu ici de manière pragmatique et couture par couture plutôt que par un seul grand schéma.

7. l'interopérabilité OTAN — Delta comme surface tournée vers l'alliance, l'alignement sur les standards

Lorsque l'écosystème doit dialoguer avec l'alliance, Delta est la surface qu'il présente. Ses interfaces conformes aux standards et son exposition lors d'exercices en font le courtier naturel entre les outils nationaux et le C2 de coalition. Plutôt que de demander aux partenaires de l'OTAN d'intégrer une douzaine d'applications ukrainiennes, le modèle consiste à s'intégrer à Delta et à laisser Delta fédérer vers le bas dans Kropyva, la couche de tirs et les stations de drones.

C'est une bonne pratique d'interopérabilité OTAN : un point de fédération unique et bien spécifié est bien plus facile à certifier et à accréditer qu'un maillage d'intégrations bilatérales. L'alignement sur les standards d'échange de données de l'alliance — les formats de messagerie et les modèles d'entités que les systèmes de coalition utilisent déjà — est ce qui permet à une piste ukrainienne d'apparaître dans l'image d'un partenaire et inversement. Le travail est continu et imparfait, mais l'instinct architectural est juste : concentrer l'interface tournée vers l'alliance en un seul endroit et la durcir.

8. les leçons pour le C2 occidental — itérer au plus près du terrain, supposer des communications dégradées, découpler les applications du modèle de données

Trois leçons se transposent proprement. Première : itérer au plus près du terrain. Les outils ukrainiens se sont améliorés parce que les unités les utilisaient quotidiennement et renvoyaient des corrections à de petites équipes qui livraient des mises à jour en quelques jours, et non en cycles de programme. Un maître d'œuvre occidental ne peut pas reproduire la guerre, mais il peut reproduire la boucle : mettre le logiciel devant les opérateurs tôt et raccourcir impitoyablement le cycle de retour.

Deuxième : supposer des communications dégradées. Chaque application de cette pile est conçue pour continuer à fonctionner lorsque le réseau est brouillé, intermittent ou absent — calcul local sur la tablette, synchronisation en stockage-et-retransmission, dégradation gracieuse. Un C2 occidental qui suppose une épine dorsale fiable construit pour un environnement que la guerre électronique ne fournira pas. Concevez d'abord pour le cas déconnecté et traitez la connectivité comme un bonus.

Troisième, et le plus important : découpler les applications du modèle de données. La raison pour laquelle cet écosystème fragmenté se fédère du tout est que le modèle d'entités est le contrat, et que les applications sont des clients interchangeables de celui-ci. Un programme occidental qui laisse le protocole ou l'interface d'un fournisseur s'infiltrer dans son modèle de domaine central s'achète un problème de remplacement complet dès que les exigences changent. La pile pragmatique, parfois désordonnée, de l'Ukraine a réussi une chose sur le plan structurel — l'image appartient au modèle de données, pas à une quelconque application — et c'est la leçon la plus digne d'être importée.