Lancelot, un apprentissage fédéré chiffré pour résister aux données empoisonnées

Dans un hôpital, une banque ou un réseau d’entreprises, entraîner un modèle d’intelligence artificielle suppose souvent de réunir des données que personne ne peut, ou ne souhaite, centraliser. L’apprentissage fédéré répond à cette contrainte en faisant circuler des mises à jour de modèles plutôt que les données brutes. Mais cette promesse de confidentialité ne suffit pas : si un participant transmet volontairement une mise à jour malveillante, il peut dégrader le modèle collectif. C’est ce double problème que le système Lancelot entend traiter, en associant chiffrement des calculs et sélection robuste des contributions.

Développé par un consortium de chercheurs affiliés à plusieurs institutions, dont l’Université chinoise de Hong Kong, Lancelot se présente comme une proposition d’apprentissage fédéré robuste face aux comportements dits byzantins. Autrement dit, il cherche à continuer de fonctionner même lorsque certains participants se trompent, dysfonctionnent ou tentent délibérément de tromper le système.

L’ambition est exigeante : conserver le secret des mises à jour locales, repérer les contributions qui paraissent peu dignes de confiance et éviter que cette phase de tri elle-même ne révèle des informations sensibles. Selon Siyang Jiang, auteur principal de l’étude, l’objectif est de construire un système fiable, capable de préserver la sécurité des mises à jour tout en accélérant l’entraînement du modèle.

L’apprentissage fédéré, une coopération sans centraliser les données

Dans un schéma classique d’apprentissage automatique, les données sont rassemblées sur un serveur ou dans un même environnement informatique, puis utilisées pour entraîner un modèle. Cette centralisation simplifie les calculs, mais elle pose de sérieuses questions de confidentialité, de gouvernance et de sécurité. Des dossiers médicaux, des transactions financières ou des informations professionnelles peuvent être particulièrement sensibles.

L’apprentissage fédéré modifie la répartition du travail. Chaque organisation ou appareil participant, appelé ici client, conserve ses données localement. Il entraîne ou ajuste le modèle de son côté, puis transmet au système central une mise à jour liée au modèle. Le serveur agrège les mises à jour reçues pour produire une nouvelle version du modèle partagé.

Cette approche ne doit toutefois pas être confondue avec une garantie automatique d’anonymat ou de sécurité totale. Une mise à jour de modèle peut contenir des informations exploitables ou avoir été manipulée. C’est pourquoi un système fédéré doit protéger à la fois les données indirectement représentées par ces mises à jour et la qualité des contributions qui alimentent le modèle collectif.

Pourquoi les attaques par empoisonnement menacent les modèles collaboratifs

Une attaque par empoisonnement consiste à introduire dans le processus d’apprentissage des données ou des mises à jour corrompues. Dans un environnement fédéré, un client malveillant peut chercher à influencer le modèle global en transmettant une contribution spécialement conçue pour en réduire les performances ou orienter son comportement.

Le danger tient à la logique même de la collaboration : le serveur reçoit un ensemble de mises à jour provenant de participants différents et doit décider comment les combiner. Si toutes les contributions sont acceptées sans précaution, quelques mises à jour hostiles peuvent peser sur le résultat final. Dans certains cas, le participant malveillant peut aussi simplement chercher à perturber la formation du modèle, sans qu’il soit nécessaire de connaître les données des autres clients.

Les travaux sur l’apprentissage fédéré robuste ont donc développé des méthodes d’agrégation capables d’ignorer ou de limiter l’influence des contributions jugées anormales. Ces techniques mathématiques visent à rendre le modèle plus résilient face à des comportements byzantins. Elles rencontrent cependant une difficulté fondamentale : pour identifier une mise à jour suspecte, il faut généralement pouvoir l’examiner ou la comparer aux autres. Or cette inspection peut entrer en tension avec la confidentialité recherchée.

Lancelot part précisément de cette contradiction. Le système ne veut pas choisir entre robustesse et secret des mises à jour. Il tente de réunir ces deux propriétés dans une même architecture.

Comment Lancelot chiffre les mises à jour sans bloquer les calculs

Au cœur de Lancelot se trouve un mécanisme de gestion de clés cryptographiques. Un centre de génération de clés produit trois éléments distincts : une clé secrète, notée sk, utilisée pour le déchiffrement, une clé publique, notée pk, destinée au chiffrement, et une clé d’évaluation, notée evk, qui permet d’exécuter des opérations sur les données chiffrées.

La séparation de ces clés organise les rôles de chaque acteur. La clé publique est transmise de manière sécurisée aux clients afin qu’ils puissent chiffrer leurs mises à jour. La clé d’évaluation est réservée aux serveurs qui doivent traiter les informations chiffrées. La clé secrète, elle, est liée au déchiffrement et ne sert pas aux opérations ordinaires d’agrégation du serveur.

Le principe employé est celui du chiffrement homomorphe : certaines opérations peuvent être effectuées sur des informations chiffrées sans les révéler sous leur forme lisible. Concrètement, les clients chiffrent leurs modèles ou mises à jour avant l’envoi. Le serveur peut ensuite réaliser les opérations nécessaires à l’apprentissage sur ces éléments protégés, grâce à la clé d’évaluation, sans obtenir un accès direct à leur contenu.

Cette architecture répond à une limite des dispositifs où le serveur central reçoit les contributions en clair. Elle ne signifie pas que tout calcul devient simple ou gratuit : le chiffrement homomorphe est notoirement exigeant en ressources informatiques. La contribution de Lancelot se situe donc aussi dans les techniques destinées à rendre ce traitement suffisamment efficace pour un usage réaliste.

Un tri de confiance qui ne révèle pas les contributions

La question la plus délicate est la suivante : comment choisir les mises à jour fiables si elles restent chiffrées ? Lancelot attribue un rôle particulier à une entité distincte et de confiance, le centre de génération de clés. Celui-ci ne déchiffre que les informations nécessaires à l’établissement d’un classement des contributions, sans divulguer les identités.

Le système s’appuie sur une méthode de tri fondée sur un masque. Plutôt que de procéder à de lentes comparaisons directes sur des données chiffrées, l’entité de confiance classe les mises à jour des clients puis renvoie au serveur une liste de sélection chiffrée. Le serveur peut alors retenir les contributions pertinentes pour l’agrégation sans connaître les informations ayant permis de les départager.

Cette étape est importante pour deux raisons. D’une part, elle vise à empêcher les contributions douteuses de peser sur le modèle final. D’autre part, elle cherche à préserver le secret du mécanisme de sélection : les autres clients ne doivent pas savoir quelles mises à jour ont été retenues ni sur quels éléments précis repose l’évaluation de confiance.

Le dispositif suppose néanmoins un modèle de confiance clair. Lancelot ne fait pas disparaître toute confiance dans le système, il la concentre notamment sur une entité séparée chargée de fonctions cryptographiques et de classement limité. C’est un choix d’architecture : au lieu de rendre chaque acteur omniscient, il répartit les capacités et limite ce que chacun peut observer.

Deux optimisations pour réduire le coût du chiffrement homomorphe

Préserver la confidentialité tout au long de l’agrégation a un prix : les opérations cryptographiques sont plus lourdes que des calculs sur des données non chiffrées. Lancelot cherche à réduire cette surcharge par deux opérations cryptographiques majeures, exécutées avec l’appui d’unités de traitement graphique, les GPU.

La première optimisation est la rélinéarisation paresseuse. Elle réduit le nombre de rélinéarisations nécessaires, ce qui limite la quantité de calculs supplémentaires engendrés par certaines opérations sur les textes chiffrés. L’idée est de ne pas effectuer immédiatement toutes les étapes de remise en forme cryptographique lorsqu’elles ne sont pas indispensables.

La seconde est l’élévation dynamique, qui parallélise des opérations répétées afin d’en améliorer l’efficacité. Les calculs intensifs, notamment les multiplications polynomiales, sont déportés vers les GPU. Ces processeurs sont adaptés à l’exécution d’un grand nombre d’opérations en parallèle, une propriété utile lorsque de nombreuses mises à jour doivent être traitées simultanément.

Ces choix techniques n’annulent pas les contraintes de bande passante ou de latence. Ils visent plutôt à les rendre compatibles avec un apprentissage fédéré robuste. L’enjeu est de ne pas transformer une garantie de sécurité théoriquement solide en système impraticable dès que le nombre de participants augmente.

Quels usages pour la santé et la finance ?

Les environnements qui détiennent des informations personnelles ou stratégiques sont les premiers concernés. Dans le secteur de la santé, plusieurs établissements pourraient vouloir améliorer un modèle à partir de leurs données locales sans partager directement des dossiers médicaux. Dans la finance, des institutions pourraient rencontrer une contrainte comparable avec des informations transactionnelles ou des profils clients.

Lancelot est conçu pour cette configuration de coopération sous fortes contraintes. Il pourrait permettre de traiter des mises à jour de modèles provenant de plusieurs clients, de les chiffrer, d’écarter les contributions considérées comme peu fiables et d’agréger le reste. Son intérêt ne réside donc pas dans le remplacement des règles de protection des données ou des procédures de contrôle internes, mais dans l’ajout d’une couche technique pour réduire l’exposition des informations pendant l’apprentissage.

Il convient également de distinguer ce que le système protège. Lancelot vise la confidentialité des mises à jour et la robustesse contre l’empoisonnement. La qualité des données locales, la pertinence du modèle pour un usage donné, les autorisations de traitement et la gouvernance entre organisations restent des questions distinctes. Dans un hôpital comme dans une banque, la technologie ne dispense pas de définir précisément qui participe, à quelles conditions et avec quelles responsabilités.

Ce qu’il faut surveiller pour un déploiement à grande échelle

À la date du 20 octobre 2025, Siyang Jiang et ses collègues poursuivent l’amélioration de la version pilote de Lancelot afin d’en étendre l’application pratique. La priorité annoncée est d’explorer des modèles de confiance supplémentaires sans accroître la bande passante ni la latence.

Ce point sera déterminant. Dans un petit groupe de participants, un protocole chiffré et un classement contrôlé peuvent être plus simples à coordonner. À grande échelle, la taille des mises à jour, la fréquence des échanges, la capacité de calcul et l’organisation de l’entité de confiance deviennent des paramètres centraux. Une solution robuste devra démontrer qu’elle conserve ses propriétés de confidentialité et de résistance aux attaques sans ralentir excessivement l’entraînement.

Lancelot illustre ainsi une évolution importante de l’apprentissage fédéré : il ne suffit plus de laisser les données chez leurs détenteurs. Pour rendre la collaboration réellement crédible dans les secteurs sensibles, il faut aussi protéger les calculs, traiter le risque de participants malveillants et rendre l’ensemble techniquement soutenable. C’est sur cet équilibre entre confidentialité, robustesse et performance que se jouera la portée pratique de cette approche.