Défense cloud-native : microservices, service mesh et patterns

Les plateformes de commandement et de contrôle de défense ont historiquement été monolithiques — une seule unité déployable contenant la gestion des pistes, le relais des communications, la coordination des feux et l'intégration du renseignement derrière une base de données partagée. Le monolithe n'était pas un accident : il simplifiait l'accréditation, minimisait la surface d'attaque réseau, et correspondait au modèle de personnel d'une petite équipe maintenant un seul artefact. Mais la fragilité qu'il crée est de plus en plus inacceptable. La mise à niveau d'un seul composant exige une fenêtre de maintenance de toute la plateforme. Une poussée du volume de pistes ISR dégrade l'interface des feux. Un changement de schéma de base de données fige des fils de développement sans rapport pendant des semaines.

L'architecture cloud-native traite ces modes de défaillance en décomposant la plateforme en services déployables indépendamment, chacun avec sa propre couche de persistance, exploités par Kubernetes et sécurisés de bout en bout par un service mesh. Il ne s'agit pas principalement d'une histoire de coût ou d'agilité — c'est une histoire de résilience et de souveraineté opérationnelle. Lorsqu'un service de fusion de pistes tombe en panne dans une plateforme C2 cloud-native, il tombe en panne de façon isolée. L'interface de coordination des feux reste opérationnelle, le relais des communications continue d'acheminer les messages, et les opérateurs voient une image opérationnelle commune dégradée — mais pas absente — pendant que le service défaillant se rétablit de lui-même. Aucune isolation équivalente n'est atteignable dans un monolithe sans cloisonnement interne délibéré qui introduirait exactement la même complexité.

Cet article couvre l'ensemble des modèles cloud-native pour les charges de travail C2 et ISR de défense : décomposition du domaine en contextes bornés, déploiement d'un maillage de services pour le TLS mutuel et l'observabilité, modèles d'opérateur Kubernetes pour les composants à état, fusion de capteurs pilotée par les événements avec CQRS et event sourcing, pratiques SRE pour les services critiques pour la mission, et dégradation élégante sous des conditions de réseau contestées.

Pourquoi le cloud-native pour les applications C2/ISR de défense

L'argument en faveur du cloud-native dans la défense n'est pas le même que dans le logiciel commercial. Les équipes commerciales adoptent les microservices pour la vélocité de développement — des équipes plus petites qui possèdent des bases de code plus petites, livrant plus vite et indépendamment. Ces bénéfices existent aussi dans la défense, mais ils sont secondaires. L'argument principal est la résilience : les modes de défaillance du monolithe sont incompatibles avec les exigences de mission.

Fragilité du monolithe en environnements contestés. Une plateforme C2 monolithique possède un seul domaine de défaillance. La pression mémoire dans le thread d'ingestion des pistes dégrade l'interface de feux. Une transaction de base de données bloquée interrompt le routage des messages. Un composant avec une fuite mémoire impose un redémarrage complet de la plateforme — mettant toutes les fonctions hors ligne simultanément. Ces modes de défaillance sont tolérables lorsque le système opère dans un environnement de garnison contrôlé avec des fenêtres de maintenance planifiées. Ils ne le sont pas lorsque le système est l'outil principal de conscience situationnelle d'une unité en contact, ou lorsque l'action adverse vise délibérément la stabilité du système.

Vélocité de déploiement indépendante pour les mises à jour de capacités. Les programmes de défense font face à un paradoxe : ils doivent mettre à jour le logiciel rapidement (nouvelles signatures de menaces, logique de ROE mise à jour, vulnérabilités corrigées) tout en minimisant les perturbations opérationnelles. Dans un monolithe, chaque changement touche le même artefact livrable, exigeant une campagne de tests de non-régression complète et une fenêtre de maintenance de la plateforme entière. Dans une architecture cloud-native, le service de fusion des menaces peut être mis à jour — validé, déployé et le cas échéant revenu en arrière — sans toucher à l'interface de feux ni au relais de communications. Chaque service possède un rythme de livraison indépendant, adapté à sa fréquence de changement et à son profil de risque.

Scalabilité horizontale pour les événements de pointe. Les opérations ISR génèrent des volumes de données très variables. Un exercice de niveau théâtre peut générer dix fois la charge de piste normale. Un monolithe se met à l'échelle comme un seul bloc — pour absorber la charge de pointe, chaque composant doit être provisionné à sa capacité de pointe, gaspillant des ressources pendant les opérations normales. Dans une plateforme cloud-native, le service de fusion des pistes se met à l'échelle horizontalement sous charge tandis que l'interface de feux et le relais de communications maintiennent leur nombre de répliques normal. Kubernetes gère la mise à l'échelle automatiquement en réponse au CPU, à la mémoire ou à des métriques personnalisées dérivées de la profondeur de file d'attente dans le pipeline d'ingestion des capteurs.

Le cloud-native pour la défense n'est pas synonyme de cloud public. Le modèle s'applique aussi bien aux infrastructures classifiées sur site, aux environnements de cloud souverain privés, et aux clusters de périphérie déployés en avant exécutant une distribution Kubernetes minimale. La caractéristique déterminante est que les services sont conteneurisés, gérés de manière déclarative et isolés les uns des autres — pas l'emplacement de l'infrastructure.

Décomposition en microservices des applications C2

La partie la plus difficile de l'adoption du cloud-native n'est pas la technologie — c'est de décider où tracer les frontières entre services. De mauvaises frontières créent des microservices fortement couplés par des bases de données partagées ou des chaînes d'appels synchrones si longues qu'une défaillance en un point se propage partout. De bonnes frontières créent des services qui peuvent être déployés, mis à l'échelle et remplacés indépendamment, sans coordination avec les équipes adjacentes.

Conception de contextes bornés pour les domaines C2. La conception pilotée par le domaine fournit le cadre : identifier les domaines distincts de la plateforme C2 et tracer des frontières autour d'eux en fonction de la propriété des données, des populations de consommateurs et de la sémantique des mises à jour. Une plateforme C2 contient typiquement au moins cinq domaines distincts qui se mappent proprement à des contextes bornés :

• Gestion des pistes — détient le magasin de pistes de référence, fusionne les rapports de capteurs, maintient l'historique des pistes et sert l'image opérationnelle commune. La fréquence de mise à jour est élevée (les rapports de capteurs arrivent en continu) ; les consommateurs incluent pratiquement tous les autres services.
• Relais de communications — gère le routage des messages, la topologie du réseau radio et l'allocation des canaux. Découplé de la gestion des pistes : les communications opèrent indépendamment de l'état de santé de la fusion des pistes.
• Coordination des feux — gère les missions de tir, la déconfliction et le suivi d'engagement des cibles. Consomme les données de pistes mais détient son propre état ; l'interface de feux doit rester disponible même si la fusion des pistes est temporairement dégradée.
• Intégration du renseignement — ingère les produits de renseignement, les corrèle aux pistes et publie des évaluations. Des travaux d'analyse de longue durée avec des exigences de latence différentes de la fusion de pistes en temps réel.
• État de la logistique — suit les niveaux d'approvisionnement des unités, la disponibilité des équipements et les demandes de soutien. Rythme de mise à jour et base de consommateurs différents des fonctions C2 opérationnelles.

Contrats d'interface de service. Chaque contexte borné publie un contrat d'interface — spécification OpenAPI pour les interfaces REST ou gRPC synchrones, schéma Avro ou Protobuf pour les interfaces d'événements asynchrones. Les contrats sont le principal mécanisme de couplage entre services et doivent être versionnés et traités comme sensibles aux changements rompus. Un service qui modifie son schéma d'événements sans enregistrer la nouvelle version dans un registre de schémas peut corrompre silencieusement ses consommateurs — un mode de défaillance invisible jusqu'à ce qu'un consommateur traite un événement malformé et produise une sortie incorrecte.

La règle cardinale : les services possèdent leurs données. Le service de gestion des pistes possède le magasin de pistes. Le service de feux possède l'état des missions de tir. Aucun service ne lit directement la base de données d'un autre service. Tout accès inter-services aux données passe par l'interface publiée. C'est la contrainte qui rend le déploiement indépendant réel — sans elle, un changement de schéma de base de données dans la gestion des pistes casse le service de feux, quelle que soit leur indépendance nominale.

Pour un traitement plus approfondi de la manière dont ces services sont durcis au niveau de l'infrastructure, voir Kubernetes defense hardening pour la configuration de sécurité des pods, de politique réseau et de contrôle d'admission qui complète la décomposition en services.

Maillage de services : mTLS et observabilité

Un maillage de services insère un proxy sidecar (Envoy dans le cas d'Istio ; un proxy Rust léger dans Linkerd) dans chaque pod, prenant en charge tout le trafic réseau entrant et sortant. L'application communique avec localhost ; le sidecar gère le chiffrement, l'authentification, les nouvelles tentatives, le disjoncteur et la collecte de télémétrie. Du point de vue de l'application, le réseau est abstrait ; du point de vue de l'opérateur, chaque appel à travers le maillage est visible et contrôlé par des politiques.

TLS mutuel pour le trafic est-ouest dans les réseaux C2 à confiance zéro. L'architecture à confiance zéro exige qu'aucun appel réseau ne soit du fait de la seule position réseau — un service à l'intérieur de la frontière du cluster doit s'authentifier aussi rigoureusement qu'un service à l'extérieur. Dans un maillage de services configuré pour un mTLS strict, chaque appel est-ouest (service à service dans le cluster) est authentifié avec des certificats de charge de travail émis par l'autorité de certification du maillage. Un service qui ne peut pas présenter un certificat valide — qu'il s'agisse d'une charge de travail non autorisée, d'un déploiement mal configuré ou d'un conteneur compromis — est rejeté au proxy sidecar avant que la demande n'atteigne l'application.

Dans les environnements classifiés, l'autorité de certification du maillage doit s'intégrer à l'IPKI interne de l'enclave plutôt qu'à une autorité de certification accessible depuis Internet. Istio prend en charge des backends d'autorité de certification amovibles — l'autorité de certification Istio peut être remplacée par une autorité personnalisée qui émet des certificats à partir d'une chaîne de confiance enracinée dans l'infrastructure IPKI accréditée du programme. La rotation des certificats doit être automatisée : la gestion manuelle des certificats est fragile sur le plan opérationnel et a causé des pannes dans des systèmes classifiés lorsque des certificats ont expiré pendant des exercices.

Istio contre Linkerd dans les environnements classifiés. Istio offre un ensemble de fonctionnalités plus riche — AuthorizationPolicy au niveau de la méthode et du chemin HTTP, miroir de trafic pour l'analyse canari, crochets d'extension Lua — mais au prix d'une complexité plus élevée et d'une empreinte de plan de contrôle plus grande. Linkerd a une surface d'attaque nettement plus petite et un modèle opérationnel plus simple, ce qui le rend attractif pour les programmes où la minimisation de la base de calcul de confiance est une priorité. Le choix dépend des exigences fonctionnelles du programme spécifique : si l'autorisation par chemin et le miroir de trafic sont nécessaires, la complexité d'Istio est justifiée ; si les exigences principales sont le mTLS et l'observabilité de base, la simplicité de Linkerd est préférable.

Traçage distribué pour l'analyse de latence. Dans une plateforme C2 avec sept services ou plus dans une chaîne d'appels, les problèmes de latence sont presque impossibles à diagnostiquer sans traçage distribué. Une demande qui prend 800 ms de bout en bout peut avoir passé 600 ms à attendre une requête de base de données dans le service de gestion des pistes et seulement 200 ms en transit et traitement dans les six autres services. Sans traçage, le seul signal disponible est la latence totale — les contributions de chaque service sont invisibles. Avec le traçage, la cascade est visible dans Jaeger ou Tempo : chaque span de service, sa durée et sa relation à la demande globale sont immédiatement apparentes.

Le maillage de services génère automatiquement des spans de trace pour chaque appel qu'il proxifie, sans exiger d'instrumentation dans le code applicatif. Les spans au niveau applicatif (requêtes de base de données, appels d'API externes dans un service) nécessitent une instrumentation explicite avec le SDK OpenTelemetry, mais le squelette inter-services est fourni gratuitement par le maillage. Dans les environnements classifiés, le backend de traçage (Jaeger, Tempo ou Zipkin) doit s'exécuter à l'intérieur de la frontière accréditée — les données de trace contiennent des noms de services, des chemins de points de terminaison et des informations de temporisation qui peuvent être sensibles pour un système C2 classifié.

Modèles d'opérateur Kubernetes pour les charges de travail de défense à état

Kubernetes gère bien les charges de travail sans état dès la sortie de la boîte — si un pod échoue, le contrôleur ReplicaSet en crée un remplaçant. Les charges de travail à état exigent une gestion plus sophistiquée : l'ordre dans lequel les répliques démarrent et s'arrêtent importe, les données doivent être migrées entre volumes de stockage pendant les mises à niveau, et la séquence de mise à niveau doit préserver les garanties de cohérence des données. Le modèle opérateur encode ce savoir-faire opérationnel sous la forme d'un contrôleur qui s'exécute dans le cluster.

Définitions de ressources personnalisées pour l'état C2. Un opérateur est construit autour d'une définition de ressource personnalisée (CRD) qui exprime l'état souhaité du composant géré en des termes significatifs pour le domaine applicatif. Pour un magasin de pistes C2, la CRD pourrait spécifier le nombre de répliques, la classe de stockage, la politique de rétention, le facteur de réplication et le nombre minimum de répliques synchronisées requis avant que l'opérateur n'autorise une mise à niveau. Les opérateurs exposent une interface déclarative aux équipes d'infrastructure : elles déclarent ce qu'elles veulent, et l'opérateur détermine comment y parvenir. Le comment est encodé une fois pour toutes dans l'opérateur, non redérivé pour chaque déploiement.

Boucle de réconciliation de l'opérateur pour l'auto-guérison. La boucle de réconciliation est le cœur d'un opérateur : elle lit l'état actuel de la ressource gérée, le compare à l'état souhaité dans la CRD et entreprend le minimum d'actions nécessaires pour conduire la convergence. Si une réplique du magasin de pistes est en CrashLoopBackOff, l'opérateur détecte la divergence et déclenche une récupération — pouvant provoquer un remplacement de réplique, un basculement sur un secondaire, ou une alerte nécessitant une intervention humaine selon le chemin de récupération que l'opérateur a été conçu pour suivre. L'opérateur s'exécute en continu, si bien que la récupération commence quelques secondes après la détection de la défaillance plutôt que d'exiger qu'un humain la remarque et réagisse.

Mise à niveau progressive sans trou de mission. Mettre à niveau un composant C2 à état dans un système en production sans trou de mission exige une séquence précise : vérifier que la cible de mise à niveau est saine avant de commencer, vider une réplique à la fois, attendre que le remplaçant atteigne un état connu comme sain avant de vider la suivante, et interrompre si les contrôles de santé échouent à un moment quelconque. Un opérateur Kubernetes encode cette séquence sous la forme d'une machine à états dans la boucle de réconciliation. L'opérateur impose le nombre minimum de répliques saines à chaque étape — il ne passera pas à l'étape de mise à niveau suivante si le système devait passer sous le minimum configuré. C'est l'avantage décisif sur les mises à niveau manuelles : la contrainte est appliquée par du code s'exécutant à la vitesse du cluster, non par un humain suivant une liste de contrôle sous pression opérationnelle.

Le pipeline CI/CD air-gapped defense qui construit et signe les images de l'opérateur est aussi important que l'opérateur lui-même — un opérateur déployé depuis une image non signée et non scannée est un risque de chaîne d'approvisionnement dans un environnement classifié.

Architecture pilotée par les événements pour la fusion de capteurs

La fusion de capteurs — l'intégration de rapports issus de plusieurs types de capteurs en une image cohérente de l'environnement opérationnel — est l'une des charges de travail les plus exigeantes d'une plateforme C2. Elle est intrinsèquement pilotée par les événements : les rapports de capteurs arrivent de manière asynchrone, à des débits variables, depuis plusieurs sources simultanément. L'architecture synchrone requête-réponse est structurellement inadaptée à cette charge de travail. Une architecture pilotée par les événements avec un journal durable comme colonne vertébrale est l'ajustement correct.

Flux d'événements fondés sur Kafka pour les données de capteurs. Apache Kafka (ou Apache Pulsar pour ses capacités de multi-location et de stockage par niveaux) fournit le journal durable et partitionné qui soutient le pipeline de fusion de capteurs. Chaque type de capteur publie sur son propre topic — les rapports radar sur un topic, le renseignement électronique sur un autre, les indices d'imagerie sur un troisième. Le service de fusion des pistes s'abonne à tous les topics pertinents et traite les rapports à leur arrivée. Le mécanisme de groupe de consommateurs de Kafka permet de mettre à l'échelle horizontalement le service de fusion : chaque réplique prend une partition, si bien que le débit augmente avec le nombre de répliques. Le journal durable de Kafka signifie que si le service de fusion est temporairement indisponible — pendant une mise à niveau ou une panne de nœud — les rapports s'accumulent dans le journal et sont traités dans l'ordre lorsque le service revient, sans perte.

Modèle CQRS pour la gestion de l'état des pistes. Le modèle Command Query Responsibility Segregation sépare le chemin d'écriture (les commandes qui modifient l'état) du chemin de lecture (les requêtes qui retournent l'état). Dans le service de gestion des pistes, le chemin d'écriture traite les rapports de capteurs entrants et les commandes d'opérateur, met à jour le magasin de pistes de référence et ajoute des événements au journal d'événements. Le chemin de lecture sert l'image opérationnelle commune et les interfaces d'analyste depuis une projection optimisée pour la lecture — une vue matérialisée de l'état des pistes optimisée pour les modèles d'accès des consommateurs de la COP, qui diffèrent des modèles d'écriture de la fusion de capteurs.

Le CQRS permet de mettre à l'échelle le chemin de lecture indépendamment du chemin d'écriture. Pendant un événement de pointe où le volume de rapports de capteurs est élevé, le chemin d'écriture se met à l'échelle pour absorber l'ingestion tandis que le chemin de lecture maintient une latence de COP stable pour les opérateurs. Le chemin de lecture peut aussi servir différentes projections à différents consommateurs sans ajouter de complexité au chemin d'écriture — le consommateur de la COP obtient une vue filtrée, les plus récents en premier ; l'outil d'analyste obtient une vue fenêtrée dans le temps avec l'historique complet.

Event sourcing pour la piste d'audit. L'event sourcing étend le modèle piloté par les événements à la persistance : au lieu de stocker l'état actuel d'un enregistrement de piste et de l'écraser à chaque mise à jour, le système stocke la séquence d'événements qui a produit l'état actuel. L'enregistrement de piste de référence est dérivé en rejouant le journal d'événements. Cette approche produit plusieurs propriétés précieuses dans les contextes d'accréditation de défense : l'historique complet de chaque transition d'état est préservé et immuable ; l'état du système à un moment passé quelconque peut être reconstruit en rejouant les événements jusqu'à ce point ; et la piste d'audit exigée par les normes d'accréditation est une sortie directe de l'architecture plutôt qu'un journal maintenu séparément.

SRE pour les services de défense critiques pour la mission

Les pratiques d'ingénierie de fiabilité des sites — SLO, budgets d'erreur, gestion structurée des incidents — s'appliquent aux plateformes C2 de défense, mais l'implémentation doit être adaptée à l'environnement opérationnel classifié, aux contraintes de tempo opérationnel et au modèle de conséquences des applications concernées.

Définition des SLO et SLI pour les services C2. Les SLO commerciaux sont typiquement formulés comme métriques d'expérience utilisateur. Les SLO C2 doivent être formulés comme métriques d'effet opérationnel définies en collaboration avec les opérateurs et les planificateurs de mission qui comprennent quels comportements du système affectent réellement les résultats de mission. SLO représentatifs pour une plateforme C2 :

• Latence de mise à jour des pistes : l'âge des pistes sur la COP au 95e centile ne doit pas dépasser 15 secondes. Mesuré comme la différence entre l'horodatage du rapport de capteur et le moment où la mise à jour de la piste est visible sur la COP.
• Taux de livraison des messages : les messages de commande doivent être livrés avec moins de 1 % de perte sur toute fenêtre de 30 minutes. Mesuré comme le rapport des livraisons acquittées aux messages envoyés à la frontière du service de relais.
• Disponibilité de l'interface de feux : l'interface de coordination des feux doit être disponible sur 99,9 % des fenêtres pondérées par le temps pendant les périodes opérationnelles déclarées. Mesuré par des sondes synthétiques, non par le taux de succès passif des requêtes.
• Latence d'ingestion des capteurs : les rapports de capteurs doivent être ingérés et validés dans le journal d'événements dans les 5 secondes suivant la réception au 99e centile. Mesuré depuis l'horodatage de réception réseau à la passerelle d'ingestion jusqu'à l'horodatage de validation du décalage Kafka.

La mesure des SLI doit utiliser la télémétrie du maillage de services dans la mesure du possible — les métriques de couche maillage sont indépendantes du code applicatif et ne peuvent pas être gonflées par des bogues au niveau applicatif qui sous-comptent les erreurs. Lorsque les métriques du maillage sont insuffisantes (par exemple, mesurer l'ancienneté exige des horodatages au niveau applicatif non disponibles à la couche proxy), instrumenter l'application avec OpenTelemetry et exporter vers un backend compatible Prometheus à l'intérieur de l'enclave.

Politique de budget d'erreur. Un budget d'erreur est le complément du SLO : si le SLO de fraîcheur des pistes est une conformité de 99,5 % sur 30 jours, le budget d'erreur est de 0,5 % — soit environ 2 heures et 10 minutes de fenêtres non conformes par mois. Lorsque le budget est sain, les équipes d'ingénierie peuvent déployer des changements et accepter un risque calculé. Lorsque le budget approche l'épuisement, la politique bascule vers la stabilité : pas de déploiements non d'urgence, ressources d'ingénierie redirigées vers l'amélioration de la fiabilité, et un examen obligatoire après épuisement du budget. Les programmes de défense doivent superposer des fenêtres opérationnelles à la politique de budget d'erreur : certaines périodes sont déclarées opérationnelles et la consommation de budget pendant ces périodes emporte un coût élevé quelle que soit la balance cumulée.

Runbooks d'astreinte. Les runbooks pour les systèmes C2 classifiés doivent satisfaire un niveau d'exigence supérieur aux runbooks commerciaux. Ils doivent être exécutables par le personnel d'astreinte qui peut ne pas être les architectes d'origine du service, à toute heure, sous pression opérationnelle, en utilisant uniquement les outils disponibles dans la frontière accréditée. Chaque runbook devrait inclure : le mappage symptôme-diagnostic (quelles alertes correspondent à quels modes de défaillance), les commandes exactes à exécuter (avec la sortie attendue pour le cas sain et la sortie d'erreur pour les cas de défaillance courants), les contacts d'escalade avec les niveaux d'habilitation notés, et les temps de récupération attendus pour chaque procédure.

Dégradation élégante en conditions contestées

Les environnements contestés imposent des conditions de défaillance qui ne se produisent pas en garnison : brouillage délibéré des liaisons de communications, déni du GPS affectant la synchronisation temporelle, dommages physiques à l'infrastructure réseau, et charge induite par l'adversaire via des rapports de capteurs falsifiés. Une plateforme C2 cloud-native doit dégrader élégamment dans toutes ces conditions — maintenant les capacités de plus haute priorité aussi longtemps que possible, avec un comportement défini et testé à chaque niveau de dégradation.

Disjoncteurs pour la connectivité dégradée. Les disjoncteurs empêchent une dépendance lente ou défaillante de propager la défaillance à travers la chaîne d'appels. Dans le maillage Istio, les disjoncteurs sont configurés via la ressource OutlierDetection sur une DestinationRule : spécifier le seuil d'erreurs consécutives qui déclenche le disjoncteur, l'intervalle d'éjection et le temps d'éjection de base. Lorsque le taux d'erreur d'un service dépasse le seuil, le maillage cesse de lui router des appels et renvoie des erreurs immédiatement plutôt que de mettre en file d'attente des appels qui expireront. Cela protège le budget de latence de l'appelant — le service de feux n'attend pas 30 secondes qu'une requête de piste expire, il reçoit une erreur immédiate et revient à un état mis en cache.

Modèles de repli lecture-depuis-le-cache. Lorsqu'un service amont est indisponible, les services qui servent des charges de travail à forte lecture peuvent revenir à un cache local ou distribué contenant le dernier état connu comme bon. Le repli sur cache n'est acceptable que lorsque l'ancienneté des données est bornée et présentée aux opérateurs — une COP qui sert silencieusement des pistes vieilles de 10 minutes sans indiquer leur âge est pire qu'une COP qui marque explicitement les pistes comme anciennes. Implémenter le repli avec un en-tête de réponse ou un champ de charge utile explicite indiquant l'âge et la source des données (en direct contre mis en cache), afin que les interfaces opérateur puissent présenter l'état de dégradation plutôt que le masquer.

Dégradation progressive du service capable de fonctionner hors ligne. L'isolement complet — aucune connectivité à un service amont quelconque — exige des données prépositionnées et une logique applicative capable de fonctionner hors ligne. Concevoir une matrice de dégradation pour la plateforme spécifiant quelles capacités opèrent dans chaque état de connectivité : pleinement connectée (tous les services joignables), partiellement connectée (certains services joignables, d'autres non), et totalement isolée (aucune connectivité externe). Chaque capacité de la matrice doit avoir une implémentation testée de son comportement dégradé — non une note dans un document de conception, mais un chemin de code testé qui a été exercé dans des tests d'injection de fautes avant le déploiement opérationnel.

Le cas partiellement connecté est le plus difficile à concevoir car l'ensemble des services disponibles est imprévisible — le magasin de pistes peut être joignable mais le service d'intégration du renseignement peut ne pas l'être, ou inversement. Les services doivent être conçus pour opérer avec le sous-ensemble de dépendances disponible, en se dégradant de manière fluide à mesure que des dépendances individuelles échouent plutôt que d'exiger une connectivité tout ou rien. Cela exige une classification explicite des dépendances au niveau du service : obligatoire (le service ne peut pas fonctionner sans elle), préférée (le service fonctionne mieux avec elle mais peut dégrader élégamment sans elle), et optionnelle (le service ignore totalement son indisponibilité).

Pour les fondations de sécurité des conteneurs qui soutiennent toute cette architecture — signature d'images, analyse de vulnérabilités et application de politiques à l'exécution — voir container image security defense. Une architecture cloud-native n'est aussi sûre que les images qui y tournent ; la décomposition en microservices multiplie la surface d'attaque des conteneurs si les images ne sont pas durcies et scannées en continu.

L'architecture cloud-native pour les plateformes C2 et ISR de défense est un investissement d'ingénierie significatif : analyse de contextes bornés, déploiement et exploitation d'un maillage de services, développement d'opérateurs, conception de pipelines pilotés par les événements, définition de SLO avec les parties prenantes opérationnelles, et tests de dégradation élégante exigent tous un effort d'ingénierie délibéré qu'une plateforme monolithique n'exige pas. Le retour sur cet investissement est une plateforme où la défaillance est locale, les mises à jour indépendantes, l'échelle élastique, et la dégradation conçue plutôt que fortuite — des propriétés qui deviennent non négociables pour un logiciel de défense opérant dans des environnements contestés.