
Comment des modèles IA peuvent collaborer sans partager leurs données (ni leurs paramètres)
Le Federated Learning (ou apprentissage fédéré) est une technique connue des spécialistes : elle permet d'entraîner une IA sur des données dispersées (comme sur des smartphones) sans jamais les centraliser. C'est un avantage majeur pour la vie privée. Mais une fois le modèle entraîné, comment faire collaborer plusieurs entreprises sans qu'elles aient à montrer leur "marchandise" (leurs paramètres de modèle) ? Une récente étude sur arXiv propose une réponse fascinante : la Federated Inference. L'idée ? Faire collaborer des modèles à l'exécution, tout en gardant tout le monde dans le noir.
Le problème : le Federated Learning ne suffit pas
Le Federated Learning (FL) a résolu beaucoup de problèmes d'entraînement. Mais il a ses limites. Imaginons deux banques. Elles ont chacune leur propre modèle de détection de fraude, entraîné sur leurs clients. Elles voudraient confronter leurs expertises pour affiner un diagnostic, mais elles ne veulent (et ne peuvent) pas :
- Réentraîner un modèle commun (trop cher, trop lent).
- Partager les poids de leur modèle (c'est leur propriété intellectuelle, leur "secret sauce").
- Exposer les données d'entrée (les transactions clients) à l'autre partie.
C'est là que le blocage opérationnel se produit. On a besoin de collaboration, mais à l'instant T, pour une prédiction précise, pas pour un long entraînement commun.
La solution : la Federated Inference
La Federated Inference (FI) change la perspective. Au lieu de fusionner les modèles ou les données, on les fait travailler en parallèle sur une même requête, de manière isolée, puis on agrège les résultats. Le concept clé défini dans l'étude "Federated Inference: Toward Privacy-Preserving Collaborative and Incentivized Model Serving" est simple : les modèles sont statiques, ils ne bougent pas. Seul le résultat de leur réflexion voyage, et encore, de manière totalement chiffrée.
C'est un peu comme si vous consultiez plusieurs experts médicaux pour un diagnostic. Vous leur montrez vos analyses (chiffrées), ils donnent un avis (chiffré), et un tiers agrège ces avis pour vous donner une réponse finale. Aucun expert ne voit le dossier de l'autre, ni ne sait qui sont les autres experts.
Sous le capot : le Secret Sharing et le SMPC
Comment fait-on pour calculer quelque chose sur des données qu'on ne voit pas ? La technologie magique ici, c'est le SMPC (Secure Multi-Party Computation), et plus précisément le Secret Sharing (partage de secret).
Imaginez que vous voulez envoyer un nombre secret à trois serveurs. Au lieu d'envoyer le nombre "10", vous envoyez "3" au serveur A, "-5" au serveur B et "12" au serveur C. Individuellement, ces chiffres ne veulent rien dire. Mais si on les additionne (3 + -5 + 12), on retrouve 10. C'est ça, le Secret Sharing.
Dans un système de FI, le propriétaire du modèle découpe les milliards de paramètres de son réseau neuronal en "parts" aléatoires et les envoie à différents serveurs de calcul. Le client fait de même avec sa question (l'input). Les serveurs effectuent ensuite des opérations mathématiques (additions, multiplications) directement sur ces parts. Grâce aux propriétés mathématiques, le résultat de l'opération sur les parts correspond à la part du résultat final. Personne n'a jamais vu le modèle ni les données en clair.
Le workflow en quatre temps
Concrètement, une requête suit un chemin bien tracé. D'abord, lors de la phase de provisionnement, chaque organisation éclate son modèle en morceaux et les distribue aux serveurs de calcul. Ensuite, le client envoie sa requête, lui aussi découpée en morceaux, à ces mêmes serveurs.
Vient alors le cœur du système : l'inférence préservant la confidentialité. Chaque serveur exécute une partie du calcul de chaque modèle sur sa part de la requête. Ils coordonnent leurs calculs pour obtenir des prédictions partielles, toujours chiffrées. Enfin, on procède à l'agrégation sécurisée. Les prédictions partielles sont combinées (par exemple une moyenne pondérée) pour former un résultat final chiffré, qui est renvoyé au client. Ce dernier peut alors reconstruire la réponse finale, seule chose visible en clair du processus.
Pourquoi c'est critique (et pas parfait)
Franchement, c'est une approche puissante pour l'industrie. Elle permet à des concurrents de coopérer sur un sujet précis (comme la cybersécurité ou la santé) sans briser la loi ou perdre leur avantage compétitif. Elle permet aussi de créer des "super-modèles" à la volée en assemblant des spécialistes.
Mais soyons critiques. La latence est l'ennemi. Faire du calcul chiffré entre plusieurs serveurs, c'est beaucoup plus lent qu'une inférence classique. L'étude le reconnaît : il y a un compromis inévitable entre confidentialité et vitesse. De plus, la mise en place est complexe. Il faut gérer plusieurs serveurs, la synchronisation, et s'assurer qu'il n'y a pas de collusion (c'est-à-dire que les serveurs ne s'allient pas pour voler les données).
Sources
- Federated Inference: Toward Privacy-Preserving Collaborative and Incentivized Model Serving - arXiv : L'étude académique de référence qui définit le paradigme de la Federated Inference et l'architecture FedSEI.
- CrypTen: Secure Multi-Party Computation Meets Machine Learning - GitHub : Le cadre open-source (utilisé dans l'étude) développé par Facebook Research pour faire du calcul chiffré, notamment du Secret Sharing.
Quelle différence y a-t-il entre l'entraînement fédéré (Federated Learning) et l'inférence fédérée (Federated Inference) ?
Le Federated Learning vise à entraîner un modèle commun sur des données dispersées. La Federated Inference, elle, vise à faire collaborer des modèles déjà entraînés pour une prédiction ponctuelle, sans partage de données ni de paramètres.
Comment la Federated Inference parvient-elle à garantir la confidentialité des données et des modèles sans partage ?
Elle utilise le Secret Sharing (partage de secret) et le calcul multi-partie sécurisé (SMPC). Les données et les modèles sont découpés en fragments incompréhensibles distribués sur plusieurs serveurs, empêchant toute reconstitution de l'information originale par une seule partie.
Pourquoi le temps de réponse (latence) est-il un défi majeur pour la Federated Inference ?
Car les opérations de chiffrement et la nécessité de coordonner les calculs entre plusieurs serveurs distants prennent beaucoup plus de temps qu'une inférence classique locale, créant un compromis entre sécurité et rapidité.
Dans quels secteurs d'activité la collaboration sécurisée entre modèles IA via Federated Inference est-elle la plus pertinente ?
Elle est idéale pour les secteurs à haute sensibilité comme la finance, la santé ou la défense, où des entités doivent confronter leurs expertises (ex: détection de fraude interbancaire) sans partager de données sensibles ni leurs algorithmes propriétaires.





