Federated Learning
En 2016, Google fait face à un dilemme : les utilisateurs de Gboard tapent des milliards de messages par jour — une mine d’or pour entraîner des modèles de langage. Mais ces messages sont privés. Les envoyer à un serveur central pour entraînement violerait la confidentialité des utilisateurs.
Le Federated Learning (FL) résout ce dilemme en inversant le flux de données : au lieu d’envoyer les données au modèle, on envoie le modèle aux données. Chaque appareil (téléphone, hôpital, voiture) entraîne localement sur ses propres données, puis n’envoie au serveur que la mise à jour des poids — jamais les données brutes. Le serveur agrège ces mises à jour (typiquement via FedAvg — une moyenne pondérée) et renvoie le modèle global mis à jour.
Cette architecture résout la confidentialité mais crée de nouveaux défis. Le non-IID : les données des clients ne sont pas indépendantes et identiquement distribuées — un hôpital a surtout des radios de poumons, un autre des IRM de genoux. Leurs gradients pointent dans des directions différentes, créant un client drift qui ralentit la convergence. FedProx (Li et al., 2019) ajoute un terme proximal pour limiter la dérive. SCAFFOLD (Karimireddy et al., 2020) estime et corrige le drift explicitement.
Mais le FL introduit aussi une surface d’attaque. Un client malveillant peut envoyer des gradients empoisonnés pour faire dévier le modèle global — c’est exactement le modèle de menace byzantin. Les GARs (Krum, Bulyan, Median) sont nés de ce besoin : agréger des gradients de manière robuste quand une fraction des clients est compromise. Le FL est donc le théâtre naturel de la robustesse byzantine : données privées, architecture distribuée, clients non fiables — tous les ingrédients sont réunis.
Lien thèse : Le FL est l’architecture cible de ta librairie. Chaque client est un worker potentiellement byzantin. Le serveur d’agrégation est le Parameter Server qui exécute les GARs. En 2024-2025, le FL devient industriel — Apple Private Cloud Compute (PCC) déploie des modèles Apple Intelligence avec FL + DP, et Google entraîne Gboard sur des milliards d’appareils.
| Année | Contribution | Acteurs |
|---|---|---|
| 2016 | Federated Learning — formalisation : données locales, serveur agrège les poids | McMahan et al. (Google) |
| 2017 | FedAvg — algorithme de base, moyenne pondérée des poids clients | McMahan et al. |
| 2018 | Federated Learning + DP — ajout de confidentialité différentielle | McMahan et al. |
| 2019 | FedProx — FedAvg + proximal term pour données non-IID | Li et al. |
| 2020 | SCAFFOLD — correction du client drift avec contrôle variance | Karimireddy et al. |
| 2021 | FedNova — normalisation des pas locaux | Wang et al. |
| 2021 | FL + Byzantine — premiers papiers combinant FL et robustesse Byzantine | |
| 2022 | personalized FL — modèles personnalisés par client (pFL, AFL) | |
| 2023 | FL + LLM — fine-tuning de LLMs en fédéré | |
| 2024 | Apple Private Cloud Compute — FL en production à grande échelle |
🔗 Lien thèse : Le FL est l’architecture naturelle des GARs (Krum, Bulyan, Median). Le non-IID (section Concepts) est le dilemme central : comment distinguer un client honnête atypique d’un attaquant ?
🔗 Voir aussi : Distributed Systems — le FL est un système distribué avec des contraintes de confidentialité uniques.
← Adversarial ML & Robustesse • 20 • Attaques Byzantines →