Apprentissage fédéré pour l'IA militaire sur données classifiées

Le paradoxe central de l'entraînement de l'IA militaire est que les données qui amélioreraient le plus la performance opérationnelle d'un modèle sont exactement celles qui ne peuvent pas être déplacées. Des journaux de capteurs classifiés, des images ISR de théâtres actifs, des enregistrements d'ordre de bataille électronique et des jeux de données de partenaires alliés existent derrière des limites de compartimentation qui rendent impossible l'entraînement centralisé conventionnel. L'apprentissage fédéré résout ce paradoxe en inversant le paradigme d'entraînement : au lieu de déplacer les données vers le modèle, c'est le modèle qui va vers les données. Chaque organisation participante s'entraîne localement sur son propre corpus classifié et ne partage que des mises à jour de gradient — des dérivées mathématiques qui améliorent le modèle global sans exposer les exemples d'entraînement sous-jacents. Cet article examine la pile d'ingénierie complète pour déployer l'apprentissage fédéré dans des environnements de défense, depuis le choix de la topologie de fédération jusqu'à l'étalonnage de la confidentialité différentielle, l'agrégation sécurisée, l'opération tactique asynchrone et l'atténuation des menaces robustes aux byzantins.

Pourquoi l'apprentissage fédéré pour la défense — souveraineté des données entre commandements, barrière de classification et fraîcheur des modèles en périphérie

Les données d'entraînement de l'IA militaire sont distribuées entre silos organisationnels par conception, non par hasard. La politique de classification, les autorités légales et les exigences de sécurité opérationnelle créent des frontières strictes entre les organisations propriétaires de données. Les images ISR d'un commandement des opérations spéciales ne peuvent pas être transmises à l'infrastructure d'entraînement d'une force conventionnelle sans naviguer dans les contrôles d'accès aux compartiments, ce qui peut prendre des mois à résoudre — si une résolution est possible. Une nation alliée partenaire qui contribue des données de capteurs à un modèle de coalition ne peut légalement transférer ces données hors de son infrastructure souveraine en vertu du droit de la sécurité nationale, quel que soit le cadre de traités entre les nations.

La barrière de classification est le problème le plus aigu. Un entraînement centralisé sur des données multi-classification exige d'élever l'infrastructure d'entraînement au niveau de sensibilité le plus élevé de n'importe quel jeu de données contributeur. Un cluster d'entraînement autorisé pour des données Top Secret/SCI coûte un ordre de grandeur de plus en construction, en personnel et en accréditation qu'un établissement de niveau Secret, et limite le pool d'ingénieurs et de data scientists pouvant y travailler à une fraction de la main-d'œuvre. En pratique, la plupart des programmes d'IA pour la défense choisissent de s'entraîner sur les données les moins sensibles disponibles plutôt que d'accréditer un établissement de niveau supérieur — ce qui prive le modèle des exemples d'entraînement les plus pertinents sur le plan opérationnel. L'apprentissage fédéré élimine ce compromis en permettant à chaque silo de contribuer au modèle global à son propre niveau de classification. Les mises à jour de gradient qui sortent de chaque silo ne portent aucune marque de classification équivalente à leurs données sources — ce sont des artefacts mathématiques du processus d'entraînement, pas des enregistrements de données.

La fraîcheur des modèles en périphérie est la troisième motivation. Un défi de inférence IA edge pour les systèmes militaires est que le modèle déployé sur une plateforme tactique il y a des mois a été entraîné sur un instantané du monde qui peut ne plus correspondre à l'environnement opérationnel actuel. Les ensembles de véhicules cibles évoluent, de nouvelles formes d'onde radar sont déployées, et les techniques de camouflage adverses s'adaptent pour déjouer les schémas de détection connus. L'apprentissage fédéré permet une amélioration continue du modèle à partir des données collectées sur les plateformes déployées et sur les bases opérations avancées, en renvoyant les améliorations au modèle global sans exiger que les plateformes envoient les données opérationnelles brutes vers l'échelon supérieur — une contrainte de bande passante et de sécurité qui rend l'exfiltration de données brutes depuis les plateformes tactiques peu pratique. Le modèle s'améliore grâce au terrain, tandis que les données restent sur le terrain.

Architectures FL pour la défense : cross-silo vs cross-device — fédération au niveau du commandement et au niveau de la plateforme

L'apprentissage fédéré dans les déploiements de défense se divise en deux schémas architecturaux fondamentalement différents, chacun adapté à une couche distincte de la hiérarchie organisationnelle militaire. Comprendre la différence est un préalable à la sélection du framework, de la stratégie d'agrégation et de l'architecture de sécurité corrects.

La fédération cross-silo connecte un petit nombre de participants importants et institutionnellement stables — typiquement 5–50 — chacun détenant des jeux de données classifiés substantiels. Dans un contexte de défense, les participants cross-silo sont des commandements militaires, des agences de renseignement, des nations partenaires ou des bureaux de programmes de plateformes. Chaque silo dispose d'une infrastructure de calcul dédiée capable d'exécuter une boucle complète d'entraînement de modèle, d'une connexion réseau persistante au serveur d'agrégation (avec des fenêtres de maintenance planifiées pour la déconnexion) et d'une autorité institutionnelle sur ses données. La fédération cross-silo tolère des coûts de communication plus élevés par tour car les participants sont bien dotés, et elle bénéficie de la richesse statistique du grand jeu de données local de chaque participant. Les défis d'ingénierie principaux sont les distributions de données hétérogènes entre organisations, les cadres légaux et réglementaires régissant la participation, et l'infrastructure d'authentification et d'autorisation nécessaire pour garantir que seuls les silos autorisés peuvent contribuer au modèle global.

La fédération cross-device connecte un grand nombre de participants contraints en ressources et disponibles par épisodes — potentiellement des milliers de terminaux de soldats, de nœuds de capteurs, de stations terrestres de drones ou de modules de calcul embarqués. Chaque appareil ne détient qu'une petite quantité de données générées localement, a une connectivité réseau intermittente et peut entrer et sortir de la fédération de façon imprévisible. Le FL cross-device exige une agrégation asynchrone, une compression agressive des gradients pour minimiser la bande passante de communication, et des méthodes statistiques capables d'extraire un signal utile de très petits jeux de données locaux hautement non-IID (non indépendants et identiquement distribués). C'est l'architecture appropriée pour l'IA tactique en maillage, où l'objectif est de mettre à jour un modèle partagé à partir de l'expérience collective d'un réseau de capteurs distribué sans qu'aucun nœud individuel n'accumule jamais assez de données pour s'entraîner significativement par lui-même.

La plupart des programmes institutionnels d'IA pour la défense — ceux qui opèrent au niveau du commandement, du domaine ou du programme d'équipement — utilisent l'architecture cross-silo avec 10–30 participants bien identifiés. L'architecture cross-device s'applique principalement aux programmes d'IA tactique expérimentaux où les plateformes individuelles sont les participants à l'entraînement. Les deux peuvent être combinées de façon hiérarchique : la fédération cross-device au niveau du réseau tactique s'agrège en un participant cross-silo au niveau du commandement opérationnel, qui participe à son tour à une fédération cross-silo stratégique. Cette structure hiérarchique permet aux données des capteurs tactiques individuels d'influencer finalement le modèle global sans qu'aucune donnée brute de capteur ne traverse plus d'un saut de réseau.

Confidentialité différentielle pour les données d'entraînement militaires — étalonnage du bruit DP-SGD, choix d'epsilon pour les cas d'usage de défense, arbitrage utilité vs confidentialité

Les mises à jour de gradient, sans être des données brutes, ne sont pas parfaitement opaques. La recherche a démontré que les attaques par inversion de gradient peuvent reconstruire des exemples d'entraînement individuels à partir des mises à jour de gradient avec une fidélité étonnante, en particulier pour de petites tailles de lot locales et des architectures de modèles peu profondes. Dans un contexte de défense, même une reconstruction partielle de données d'entraînement à partir d'un gradient intercepté pourrait compromettre des sources de renseignement, révéler des modes de collecte de capteurs ou exposer des capacités de plateforme. La confidentialité différentielle (DP) fournit un mécanisme mathématiquement rigoureux pour borner cette fuite.

DP-SGD (Stochastic Gradient Descent différentiellement privé) applique deux opérations à chaque gradient avant qu'il ne quitte le silo d'entraînement. D'abord, le clipping des gradients par exemple borne la sensibilité du signal d'entraînement : la norme L2 du gradient de chaque exemple individuel est tronquée à une valeur maximale C, ce qui garantit qu'un seul exemple d'entraînement ne peut pas dominer la mise à jour de gradient. Ensuite, un bruit gaussien calibré d'écart type proportionnel à C / sigma est ajouté à la somme des gradients tronqués. Le rapport C / sigma est le multiplicateur de bruit ; des valeurs de sigma plus grandes ajoutent plus de bruit, offrant une confidentialité plus forte au prix d'un signal de gradient plus dégradé.

La garantie formelle de confidentialité s'exprime par epsilon (le budget de confidentialité) et delta (une probabilité d'échec négligeable). Après R tours d'entraînement, chacun avec une taille de lot locale B tirée de N exemples d'entraînement au total, l'epsilon accumulé croît approximativement comme epsilon ≈ (q * sigma_inv * sqrt(2 * R * log(1/delta))) où q = B/N est le taux d'échantillonnage. En pratique, le suivi se fait avec le moments accountant ou le comptable de confidentialité différentielle Renyi, qui donnent des bornes plus serrées que le théorème de composition de base.

# DP-SGD with Opacus (PyTorch) — defense FL configuration
import torch
from opacus import PrivacyEngine
from opacus.accountants import RDPAccountant

model = MyDetectionModel()
optimizer = torch.optim.SGD(model.parameters(), lr=0.01)

privacy_engine = PrivacyEngine(accountant="rdp")

model, optimizer, train_loader = privacy_engine.make_private_with_epsilon(
    module=model,
    optimizer=optimizer,
    data_loader=train_loader,
    epochs=local_epochs,
    target_epsilon=3.0,       # authorized privacy budget for SECRET data
    target_delta=1e-5,        # negligible failure probability
    max_grad_norm=1.0,        # clipping norm C (set to median gradient norm)
)

# Train local epochs
for epoch in range(local_epochs):
    for batch in train_loader:
        optimizer.zero_grad()
        loss = criterion(model(batch["inputs"]), batch["labels"])
        loss.backward()
        optimizer.step()  # gradient clipping + noise injection happens here

# Check remaining budget before transmission
epsilon_consumed = privacy_engine.get_epsilon(delta=1e-5)
assert epsilon_consumed <= AUTHORIZED_EPSILON_CEILING, "Privacy budget exceeded"

Le choix d'epsilon pour les cas d'usage de défense dépend du niveau de classification des données d'entraînement et du modèle d'adversaire. Une heuristique utile pour les programmes de défense est d'échelonner epsilon selon la classification : les données d'entraînement non classifiées peuvent tolérer un epsilon de 8–12 où l'impact sur la précision est minimal ; les données Secret justifient un epsilon de 2–5 où le coût de précision est réel mais la garantie mathématique est forte ; les données Top Secret ou compartimentées peuvent exiger un epsilon proche de 1 où la dégradation de précision est significative et doit être pesée par rapport à l'exigence de confidentialité. Le coût de précision d'une DP forte est réel — un modèle de détection entraîné avec epsilon = 1 peut perdre 3–6 mAP par rapport à une ligne de base non privée — et les bureaux de programme doivent formellement accepter cet arbitrage plutôt que de le voir fait implicitement par les choix logiciels d'un ingénieur.

Stratégies d'agrégation de modèles — FedAvg, FedProx pour des distributions de données hétérogènes, agrégation pondérée par la qualité et la quantité des données

FedAvg (Federated Averaging), l'algorithme canonique d'agrégation FL, calcule la mise à jour du modèle global comme une simple moyenne des mises à jour de gradient des participants sur un tour. Il est simple, efficace en communication et bien compris. Il est aussi fragile lorsque les distributions de données des participants sont très hétérogènes — la situation qui est la règle plutôt que l'exception dans les déploiements militaires cross-silo, où les données d'entraînement de chaque silo organisationnel reflètent son contexte opérationnel spécifique, sa plateforme de capteurs et son théâtre géographique d'opérations.

Le problème d'hétérogénéité se manifeste par la dérive des clients : le modèle optimisé localement par chaque participant dérive dans une direction déterminée par sa distribution de données locale, et la moyenne de plusieurs modèles dérivés peut être pire que le modèle local de n'importe lequel des participants. Un commandement opérant exclusivement dans un théâtre arctique entraînera son modèle local à reconnaître des véhicules enneigés ; un commandement de théâtre désertique se spécialisera dans les signatures de cibles couleur sable. Moyenner les deux produit un modèle qui sous-performe par rapport aux deux. FedProx traite la dérive des clients en ajoutant un terme de régularisation proximale à la fonction d'objectif locale de chaque participant :

# FedProx local objective — adds proximal term to standard loss
# w_global = global model weights from last aggregation round
# w_local  = local model weights being updated
# mu       = proximal regularization strength (0.01 – 0.1)

def fedprox_loss(predictions, targets, w_local, w_global, mu=0.05):
    task_loss = criterion(predictions, targets)
    proximal_term = (mu / 2) * sum(
        torch.norm(w_l - w_g) ** 2
        for w_l, w_g in zip(w_local.parameters(), w_global.parameters())
    )
    return task_loss + proximal_term

Le terme proximal pénalise la dérive du modèle local par rapport au point de départ global, empêchant un participant unique de trop tirer la mise à jour agrégée dans la direction de sa distribution de données locale. L'hyperparamètre mu contrôle l'arbitrage : mu = 0 récupère FedAvg standard (pas de régularisation) ; mu = 1.0 empêche l'optimisation locale d'améliorer le modèle global (trop de régularisation). Des valeurs dans l'intervalle 0,01–0,1 sont typiques pour les déploiements de défense cross-silo. Le réglage de mu exige de surveiller la précision du modèle global sur un jeu d'évaluation central mis de côté sur les tours d'entraînement — si la précision oscille ou ne converge pas, augmentez mu ; si la convergence est trop lente, diminuez-le.

L'agrégation pondérée par la quantité de données remplace la moyenne à poids égaux par une agrégation proportionnelle au nombre d'exemples. Un commandement avec 500 000 exemples annotés doit contribuer davantage à la mise à jour globale qu'une base opérations avancée avec 800 exemples. La pondération par le nombre d'exemples est simple : chaque participant signale son nombre d'exemples locaux (ces métadonnées de comptage n'exposent pas le contenu des données), et le serveur calcule le poids de chaque participant comme son nombre divisé par le total de tous les silos participants du tour.

L'agrégation pondérée par la qualité des données est plus complexe. Les proxies de qualité calculables sans accéder aux données brutes incluent la précision de validation du modèle local (si un jeu de validation local mis de côté est disponible), la norme du gradient (des normes de gradient extrêmement grandes ou petites peuvent indiquer des problèmes de qualité des données) et l'accord du modèle (la mise à jour locale pointe-t-elle dans une direction similaire à celle de l'agrégat des autres participants). Les programmes de défense avec une qualité de capteurs hétérogène — mêlant des images électro-optiques haute résolution d'actifs ISR stratégiques à des caméras de véhicules terrestres basse résolution — devraient implémenter une agrégation pondérée par la qualité pour empêcher les sources de données de faible qualité de dégrader la performance du modèle global sur les tâches de détection à fort enjeu qui dépendent des données de meilleure qualité.

Protocoles d'agrégation sécurisée — agrégation cryptographique (SecAgg), environnement d'exécution de confiance pour le serveur d'agrégation, chiffrement des gradients

Le serveur d'agrégation est l'unique point de l'architecture FL qui doit traiter les mises à jour de gradient de tous les participants. Même si les participants individuels ne peuvent pas accéder aux gradients des autres, l'opérateur du serveur d'agrégation — et tout adversaire qui compromet le serveur — peut observer toutes les mises en ligne individuelles de gradients. Dans un déploiement FL de défense où les participants sont différentes organisations ou nations, cette visibilité centralisée crée un risque de collecte de renseignement : un adversaire sophistiqué qui contrôle ou a pénétré le serveur d'agrégation peut tenter des attaques par reconstruction de gradient contre les données d'entraînement des participants individuels.

L'agrégation sécurisée (SecAgg) élimine cette exposition en permettant au serveur de calculer l'agrégat des gradients des participants sans jamais voir le gradient d'un participant individuel en clair. Le protocole utilise un partage de secrets par paires entre participants :

• Dans la phase de mise en place, chaque paire de participants établit un secret partagé via un échange de clés Diffie-Hellman sur un canal authentifié. Le serveur d'agrégation facilite la distribution des clés mais n'apprend pas les secrets par paires.
• Avant d'envoyer son gradient, chaque participant génère un vecteur de masquage pseudo-aléatoire pour chacun de ses partenaires (dérivé du secret par paire), et ajoute tous ces masques à son gradient. Le masque de la paire de participants (i, j) est ajouté avec un signe positif par le participant i et un signe négatif par le participant j.
• Lorsque tous les gradients masqués sont sommés côté serveur, les masques s'annulent par paires, ne laissant que la somme réelle des gradients non masqués. Le serveur a calculé l'agrégat correctement sans jamais voir le gradient en clair d'un participant individuel.
• Les abandons de participants sont gérés par un schéma de partage de secrets pour les clés de masquage : si un participant abandonne avant de soumettre, un seuil d'autres participants peut reconstruire le masque de ce participant et le retirer de l'agrégat.

L'environnement d'exécution de confiance (TEE) du serveur d'agrégation fournit une couche de protection complémentaire. Un TEE — implémenté via Intel TDX, AMD SEV-SNP ou ARM TrustZone — crée un contexte d'exécution isolé au niveau matériel où le code et les données sont chiffrés et protégés même contre le système d'exploitation et l'hyperviseur de l'infrastructure. Lorsque le serveur d'agrégation s'exécute dans un TEE, l'opérateur du serveur ne peut pas inspecter le gradient agrégé en clair sans rompre les garanties d'attestation du TEE. L'attestation à distance permet aux participants de vérifier cryptographiquement que le serveur d'agrégation exécute le code d'agrégation autorisé dans un TEE authentique avant de soumettre les mises à jour de gradient. Cela traite la menace interne au niveau de l'opérateur d'infrastructure — un administrateur cloud ou un prestataire informatique gouvernemental qui opère l'infrastructure du serveur d'agrégation ne peut pas utiliser un accès privilégié pour intercepter le trafic de gradients.

Pour les systèmes de vision par ordinateur pour la défense qui participent à un programme de FL cross-silo, le chemin de données complet — depuis la sortie de l'entraînement local, en passant par le masquage, par un transport chiffré, par l'agrégation basée sur TEE, et de retour au participant sous forme de modèle global mis à jour — doit être documenté et accrédité dans le cadre du paquet d'autorisation de sécurité du programme. Chaque maillon de la chaîne exige sa propre évaluation des contrôles de sécurité.

Le FL dans les environnements tactiques déconnectés et intermittents — FL asynchrone avec gradients différés, planification des liaisons satellite, versionnage de modèle pour les gradients périmés

Le protocole FL idéal suppose que tous les participants sont atteignables simultanément au début de chaque tour d'entraînement et le restent pendant toute la durée du tour. Les environnements tactiques militaires violent systématiquement cette hypothèse. Les avant-postes reliés par satellite peuvent n'avoir que des fenêtres de connectivité de 20 minutes toutes les 12 heures. Les unités débarquées opérant dans un terrain où les communications sont refusées peuvent être hors ligne pendant des jours. Les participants embarqués sur véhicule peuvent avoir une connectivité intermittente due au masquage du terrain, aux interférences de radiofréquence liées au brouillage adversaire, ou aux procédures de contrôle des émissions (EMCON) qui interdisent d'émettre.

L'apprentissage fédéré asynchrone découple la disponibilité des participants du calendrier d'agrégation. Au lieu de collecter tous les gradients des participants avant de calculer un tour, le serveur d'agrégation maintient un tampon de gradients et applique les mises à jour au fur et à mesure de leur arrivée. Le modèle global avance en continu, en intégrant la contribution de chaque participant au moment de son arrivée. Le défi d'ingénierie est la péremption des gradients : un participant qui a entraîné son modèle local sur la version T du modèle global et soumet son gradient à l'instant T+5 contribue un gradient calculé par rapport à un modèle qui est désormais périmé de cinq pas globaux. Agréger naïvement des gradients périmés peut ralentir la convergence ou, dans les cas extrêmes, la déstabiliser.

# Staleness-weighted asynchronous aggregation (server side)
# Each gradient submission includes the round number it was computed from

def async_aggregate(gradient_buffer, current_round, max_staleness=10):
    """
    Aggregate gradient updates from the buffer, applying staleness weighting.
    Discard updates older than max_staleness rounds.
    """
    valid_updates = [
        (g, w, r) for g, w, r in gradient_buffer
        if (current_round - r) <= max_staleness
    ]

    total_weighted_grad = None
    total_weight = 0.0

    for grad, sample_weight, submission_round in valid_updates:
        staleness = current_round - submission_round
        # Exponential staleness decay: weight halves every 3 rounds
        staleness_factor = 0.5 ** (staleness / 3.0)
        effective_weight = sample_weight * staleness_factor

        scaled_grad = {k: v * effective_weight for k, v in grad.items()}
        if total_weighted_grad is None:
            total_weighted_grad = scaled_grad
        else:
            for k in total_weighted_grad:
                total_weighted_grad[k] += scaled_grad[k]
        total_weight += effective_weight

    # Normalize by total weight
    return {k: v / total_weight for k, v in total_weighted_grad.items()}

La planification du FL par liaison satellite aligne l'achèvement des tours d'entraînement sur les fenêtres de connectivité prévues. Si la liaison satellite d'un participant est disponible de 02:00 à 02:20 UTC chaque jour, le client d'entraînement de ce participant doit être configuré pour terminer son entraînement local et avoir le gradient prêt à transmettre avant 02:00. Le serveur planifie les tours d'agrégation avec une échéance qui correspond à la fenêtre de connectivité du dernier participant. Pour les participants ayant plusieurs passages quotidiens, le client d'entraînement peut utiliser le gradient le plus récent si une exécution d'entraînement a été achevée depuis la dernière transmission, ce qui évite la complexité de l'accumulation de gradients sur plusieurs passages.

Le versionnage de modèle au niveau du participant est essentiel pour la résilience. Le stockage local de modèles doit conserver au moins trois points de contrôle : le modèle d'inférence actuellement déployé, le dernier modèle global reçu (utilisé comme point de départ de l'entraînement local) et le modèle local en cours d'entraînement (avant extraction du gradient). Si la connectivité est perdue après une exécution d'entraînement locale mais avant la transmission du gradient, le gradient peut être retenu et transmis dans la prochaine fenêtre de connectivité sans refaire le calcul d'entraînement. Si le participant reçoit une mise à jour du modèle global pendant une exécution d'entraînement locale en cours, il doit décider s'il achève l'exécution en cours (et soumet un gradient potentiellement périmé) ou redémarre depuis le nouveau modèle global (en gaspillant l'investissement de calcul). Pour les plateformes d'inférence en périphérie contraintes en énergie où le calcul est coûteux, achever l'exécution en cours et accepter la péremption est généralement la meilleure politique.

Modèle de menace pour l'IA militaire fédérée — agrégation robuste aux byzantins (Krum, Trimmed Mean), détection d'empoisonnement de modèle, atténuation des attaques par inversion de gradient

L'apprentissage fédéré dans les programmes de défense opère contre un modèle de menace plus sophistiqué que les applications FL civiles. L'adversaire a à la fois la motivation et potentiellement la capacité technique de compromettre des participants au FL, d'intercepter les transmissions de gradients ou d'infiltrer l'infrastructure d'agrégation. Les catégories de menaces pertinentes pour le FL militaire sont l'empoisonnement de gradient (un participant compromis soumet des gradients malveillants), l'empoisonnement de modèle (l'adversaire injecte des données d'entraînement conçues pour produire un modèle avec une porte dérobée), l'inversion de gradient (un intercepteur reconstruit des données d'entraînement à partir de mises à jour de gradient capturées) et la compromission du serveur d'agrégation (l'adversaire accède au point d'agrégation central).

L'agrégation robuste aux byzantins se défend contre l'empoisonnement de gradient en rendant la mise à jour globale insensible à un nombre borné de contributions adversariales de participants. FedAvg standard n'est pas robuste aux byzantins — un participant unique soumettant un gradient pointant dans la direction opposée du vrai gradient peut dégrader sensiblement la convergence. Les algorithmes robustes aux byzantins sélectionnent soit un sous-ensemble de gradients, soit calculent une statistique robuste qui limite l'influence adversariale :

Multi-Krum sélectionne les m gradients les plus similaires à leurs k plus proches voisins parmi tous les gradients soumis. Les gradients byzantins, conçus pour biaiser la mise à jour globale, tendent à être des valeurs aberrantes dans la distribution des gradients — loin du cluster des gradients honnêtes. Le critère de sélection de Krum rejette ces valeurs aberrantes. L'algorithme exige de connaître une borne supérieure f du nombre de participants byzantins ; par prudence, réglez le paramètre de Krum sur n - f - 2, où n est le nombre total de participants.

Coordinate-wise Trimmed Mean écarte les fractions p supérieure et inférieure des valeurs de gradient dans chaque dimension indépendamment avant de calculer la moyenne. C'est computationnellement moins coûteux que Krum et efficace lorsque les gradients byzantins sont extrêmes dans des dimensions individuelles — une structure courante pour les stratégies d'attaque de gradient simples. La fraction de rognage p doit être réglée au moins sur la fraction byzantine supposée plus une marge de sécurité de 5–10 %.

# Coordinate-wise Trimmed Mean aggregation
import numpy as np

def trimmed_mean_aggregate(gradients, trim_fraction=0.2):
    """
    Byzantine-robust aggregation: trim top and bottom trim_fraction
    of gradient values per dimension, then average.

    gradients: list of flat numpy arrays, one per participant
    trim_fraction: fraction to trim from each tail (e.g., 0.2 = 20%)
    """
    grad_matrix = np.stack(gradients, axis=0)  # shape: (n_participants, n_params)
    n = grad_matrix.shape[0]
    k = int(np.floor(trim_fraction * n))        # number to remove from each tail

    # Sort along participant axis, trim k from top and bottom
    sorted_grads = np.sort(grad_matrix, axis=0)
    trimmed = sorted_grads[k : n - k, :]       # remove k from each end

    return np.mean(trimmed, axis=0)

La détection d'empoisonnement de modèle exige de surveiller le comportement du modèle global sur un jeu d'évaluation central propre après chaque tour d'agrégation. Une chute soudaine de précision, une augmentation du taux de faux négatifs sur une classe de cible précise, ou l'apparition de comportements de classification inattendus (comme une classification erronée à forte confiance d'un type de véhicule précis qui n'était pas présent dans le jeu d'évaluation avant le tour) sont des indicateurs d'un empoisonnement réussi. Les programmes de FL pour la défense doivent maintenir un jeu d'évaluation de réserve constitué par une équipe indépendante de tout participant au FL, afin qu'aucun participant ne puisse s'entraîner à bien performer sur le jeu d'évaluation tout en empoisonnant le comportement opérationnel du modèle. La détection d'anomalies sur les statistiques de gradient par participant — norme du gradient, similarité cosinus avec l'agrégat du tour et variance sur les tours d'entraînement — fournit un signal d'alerte précoce indiquant que le comportement de gradient d'un participant a changé, ce qui peut indiquer une compromission.

L'atténuation de l'inversion de gradient opère par trois mécanismes complémentaires. D'abord, le bruit DP-SGD masque les valeurs de gradient sous le plancher de bruit, empêchant une reconstruction haute fidélité. Ensuite, SecAgg garantit que seuls les gradients agrégés sont visibles sur le serveur d'agrégation, limitant la surface d'attaque au canal de communication entre chaque participant et le serveur. Enfin, augmenter la taille de lot locale de quelques unités à 64 exemples ou plus par pas de gradient augmente considérablement la difficulté de l'inversion, car le gradient est une moyenne sur de nombreux exemples plutôt qu'une empreinte d'un enregistrement unique. Pour les données d'entraînement les plus sensibles, des tailles de lot locales de 128 ou plus empêchent efficacement les techniques actuelles d'inversion de gradient de récupérer des enregistrements d'entraînement individuels.