Apprentissage fédéré

Le principe

Dans l'apprentissage classique, les données sont rassemblées en un point pour entraîner le modèle. Dans l'apprentissage fédéré, chaque site garde ses données et entraîne localement une copie du modèle. Seuls les paramètres mis à jour sont transmis à un coordinateur, qui les agrège pour produire une version commune. Les données brutes ne circulent pas. Le modèle, lui, circule dans les deux sens, ce qui n'est pas anodin pour la confidentialité. Chaque site conserve donc la maîtrise de ses fichiers, et le modèle commun s'améliore sans qu'aucun participant n'ait à ouvrir ses bases aux autres.

Cette architecture répond à un obstacle très concret : des données utiles mais intransférables, pour des raisons juridiques, contractuelles ou concurrentielles. Des établissements de santé, des banques ou des collectivités peuvent ainsi contribuer à un même modèle sans se dessaisir de leurs fichiers. C'est l'argument principal des projets fédérés, et il est solide quand la donnée est réellement immobilisable. Il perd de sa force quand la donnée pourrait circuler sous contrat, car la complexité technique n'est alors plus compensée par un gain réel.

Ce que cela ne résout pas

L'échange de paramètres n'est pas neutre. Des travaux ont montré qu'il est parfois possible de reconstituer des éléments d'entraînement à partir des mises à jour transmises, en particulier sur de petits jeux de données. L'anonymat des données n'est donc pas garanti par l'architecture : il faut y ajouter des protections, comme l'ajout de bruit ou la limitation du détail transmis à chaque tour. Ces protections ne sont pas un supplément contractuel : ce sont des mécanismes techniques, à vérifier dans l'implémentation et pas seulement dans la documentation.

Le coût d'exploitation est également réel. Chaque site doit disposer d'une capacité de calcul, d'une connexion stable et d'une version logicielle compatible. La coordination, la reprise après panne et la traçabilité des contributions compliquent le pilotage. Sur quelques sites bien équipés, cela reste possible ; sur un réseau hétérogène, où les machines et les débits diffèrent, la charge devient vite dissuasive. Un site qui décroche parce que sa machine est trop ancienne bloque l'agrégation, et donc l'ensemble des participants.

Quand cela se justifie

Le fédéré a du sens lorsque la donnée est à la fois précieuse et impossible à déplacer : plusieurs sites d'un même groupe, plusieurs partenaires autour d'un cas d'usage commun, un cadre réglementé. Il a moins de sens lorsque la donnée peut être anonymisée et centralisée sans difficulté, cas où l'approche classique reste plus simple à mettre en œuvre et à expliquer à une direction. Le cas typique est celui d'un groupement d'établissements qui veulent un modèle commun sans mettre en partage leurs dossiers individuels.

Avant de s'engager, il faut évaluer le rapport entre le gain attendu et la complexité ajoutée. Un projet fédéré demande une gouvernance claire : qui agrège, qui possède le modèle final, qui peut l'utiliser, que se passe-t-il si un site se retire en cours de route. Ces questions se tranchent avant la première ligne de code, pas après le premier incident. Une sortie non prévue peut invalider les résultats obtenus jusque-là, et contraindre à recommencer l'agrégation depuis le début.