Le problème qu’on essaie d’éviter
Toute plateforme scientifique « cloud » fonctionne sur le même modèle : vos données voyagent jusqu’au serveur central, l’opérateur les traite, les éventuels modèles entraînés appartiennent à l’opérateur, et vos données restent — souvent à perpétuité, parfois revendues — dans la base de données de quelqu’un d’autre.
Pour des données scientifiques publiques (UniProt, AlphaFold, PDB) c’est sans enjeu : elles sont déjà publiques par définition. Pour des données de criblage interne d’un laboratoire académique ou biotech, c’est un problème majeur. Les datasets de bioactivité non-publiés sont la monnaie d’échange des collaborations scientifiques. Les exposer en clair sur un cloud étranger, c’est souvent juridiquement interdit (cellules patients, propriété intellectuelle d’une thèse en cours, accord avec un industriel).
La conséquence pratique : les laboratoires les plus intéressants sont aussi ceux qui ne peuvent pas contribuer à une plateforme centralisée. Bactaegion serait alors limité à ce qui est déjà publié — c’est-à-dire à ce qui n’a plus de valeur compétitive — et raterait précisément les contributions à forte valeur scientifique.
L’apprentissage fédéré renverse complètement la mécanique.
Comment ça marche, dans les grandes lignes
Dans un apprentissage centralisé classique :
- Le laboratoire envoie ses données au serveur central.
- Le serveur entraîne un modèle sur ces données.
- Le modèle entraîné est utilisable.
Dans un apprentissage fédéré (FL) :
- Le laboratoire reçoit le modèle courant depuis le serveur.
- Le laboratoire entraîne localement le modèle sur ses données privées — qui ne quittent jamais son réseau.
- Le laboratoire renvoie au serveur uniquement les mises à jour de poids du modèle (les gradients), pas les données.
- Le serveur agrège les mises à jour de tous les laboratoires et produit un nouveau modèle courant.
- On recommence.
Les données restent dans chaque laboratoire. Le modèle global apprend de toutes les données sans qu’aucune n’ait jamais été transmise.
La question naturelle est : les mises à jour de poids ne fuient-elles pas indirectement les données ? La réponse, depuis 2017, est mathématiquement précise : oui, un peu, mais on peut quantifier et borner cette fuite. C’est l’apport de la differential privacy.
Differential Privacy et la spec DAP
La differential privacy ajoute un bruit aléatoire calibré aux mises à jour de poids avant qu’elles ne quittent le laboratoire. Le bruit est dimensionné pour garantir mathématiquement qu’un observateur, même malveillant, ne peut pas inférer si un patient/échantillon donné était dans le dataset d’entraînement.
L’IETF a standardisé en 2023-2024 le protocole DAP (Distributed Aggregation Protocol) qui formalise cette mécanique pour des cas d’usage réels (typiquement les statistiques anonymes de navigateurs). Mozilla, Google, Cloudflare et l’ISRG (Let’s Encrypt) ont déployé des aggregators publics opérables sans dépendre d’une seule entreprise.
L’implémentation de référence côté Cloudflare s’appelle Daphne — un serveur DAP en Rust. Il a été pensé pour passer à l’échelle (millions de contributeurs) sans coût marginal exorbitant.
Pour Bactaegion, ça donne : si on a un jour 50+ laboratoires contributeurs, on peut entraîner un modèle d’embedding sur leurs datasets de criblage privés sans qu’aucun ne révèle ses molécules.
Pourquoi Phase 4 et pas plus tôt
Trois raisons pour lesquelles Bactaegion n’active pas le FL en V1.
D’abord, on n’a pas encore 50 contributeurs. Un FL avec 3 nœuds est statistiquement non-représentatif et fournit une privacy quasi-illusoire (l’opérateur peut souvent inférer qui a contribué quelle mise à jour). DAP est conçu pour des centaines à des milliers de contributeurs.
Ensuite, le serveur d’agrégation a un coût opérationnel non nul. Daphne tourne sur Cloudflare Workers + R2, mais le rythme d’agrégations + le stockage des gradients + la vérification des seuils consomme des ressources. Tant qu’on n’a pas de volume, c’est un coût qui ne se justifie pas.
Enfin, les modèles d’embedding pertinents pour les défenses bactériennes sont en cours d’évolution rapide (2024-2026 : ESM2, ESM3, ProteinMPNN, RFdiffusion). Adopter trop tôt une architecture fédérée nous bloquerait sur une famille de modèles déjà obsolètes dans 18 mois.
L’attente est donc délibérée, pas un manque d’ambition.
Ce qui est livré dès aujourd’hui
Le V1 livre une base architecturale compatible : tout ce qui est visiteur reste local (IndexedDB), tout ce qui est public (UniProt, AlphaFold, PDB) est fetché live sans duplication. Aucune donnée sensible n’est jamais transmise à Bactaegion en V1 — pas même les clés BYOK, pas même les passphrases, pas même les verdicts de revue.
C’est la même doctrine qui permettra le FL en Phase 4 : on n’a rien à retirer. La donnée privée n’est jamais entrée. Elle peut simplement se mettre à participer à l’entraînement le jour venu, sans migration douloureuse.
Cette continuité doctrinale est ce qui distingue Bactaegion des plateformes qui essaient de rétrofiter la confidentialité après coup.
La page Federation Hub
La page /federation/ explique l’état actuel : aucune fédération n’est encore active, les conditions techniques sont posées, le calendrier de Phase 4 dépendra du volume de contributeurs au cours de 2026-2027. On y publie aussi les références scientifiques :
- IETF DAP draft v07 (avril 2024)
- ISRG Prio3 reference implementation
- Daphne (Cloudflare, MIT)
- Apple-Google COVID exposure notification (premier déploiement à grande échelle de FL en santé publique, 2020)
- FedScale benchmark (2022)
C’est un commitment public à long terme. Si vous travaillez sur du FL en biologie et que vous voulez contribuer à l’architecture Bactaegion Phase 4, c’est le moment de rejoindre la conversation.
Pour aller plus loin
- /federation/ — Federation Hub, statut Phase 4
- Chapitre 7 : L’attribution sans hiérarchie — la grammaire d’attribution non-hiérarchique des contributeurs
- Gouvernance — comment les décisions de Phase 4 seront prises
- PLAN.md — le calendrier complet des 4 phases