Le secret qui voyage : ce que les cifristi de Venise enseignent sur l'apprentissage fédéré

Une lettre illisible dans une sacoche

En 1542, le Conseil des Dix — l'organe le plus secret de la République de Venise — franchit un pas décisif. Il institutionnalise un service permanent de chiffreurs, les cifristi, logés au Palais ducal. Leur mission : rendre la correspondance d'État illisible pour tout autre que son destinataire légitime.

Un ambassadeur vénitien à Constantinople rédigeait ses dépêches, puis les transformait en une bouillie de signes. La lettre traversait des semaines de mer et de montagnes, passait entre les mains de porteurs, d'aubergistes, parfois d'espions. Aucun d'eux ne pouvait la lire. Le secret voyageait à travers le canal sans jamais s'y exposer.

Cette intuition — faire circuler une information exploitable sans jamais la livrer à ceux qui la transportent — est précisément celle de l'apprentissage fédéré et du calcul confidentiel appliqués aux grands modèles de langage. C'est le sujet de cet essai.

Ce que faisaient vraiment les cifristi

La Sérénissime fut l'une des premières puissances à professionnaliser le secret d'État. Dans son étude Regulating the Transfer of Secret Knowledge in Renaissance Venice, l'historienne Ioanna Iordanou documente la naissance de ce département de cryptologie au XVIe siècle, sous l'autorité directe du Conseil des Dix.

Ce service ne se contentait pas de coder. Il créait de nouveaux chiffres, cassait ceux de l'ennemi, formait les secrétaires et gérait les clés. Chaque ambassadeur recevait ses propres nomenclateurs, différenciés : la zifra grande pour les échanges avec le Conseil et les hauts provéditeurs, la zifra piccola pour les consuls et les commandants navals de moindre rang.

Le génie du système tient en une phrase. La sécurité ne naissait pas d'une muraille protégeant un coffre central, mais de la dissémination maîtrisée d'un secret que le canal lui-même ne pouvait exploiter. On agissait sur l'information sans l'exposer.

Le renversement : le modèle voyage, la donnée reste

Dans l'architecture classique d'un LLM d'entreprise, la logique est inverse. On rassemble les données — dossiers médicaux, contrats, transactions — en un point où le modèle vient les consulter ou s'y affiner. Ce point unique est aussi celui que vise tout attaquant.

L'apprentissage fédéré, ou federated learning, renverse la table. Le modèle voyage vers la donnée, jamais l'inverse. Chaque silo — un hôpital, une agence bancaire, un cabinet — entraîne ou affine localement une copie du modèle, puis ne partage que des poids ou des gradients, pas les données brutes.

La meilleure synthèse récente sur le sujet, Toward Federated Large Language Models publiée dans COMST en 2025, résume la promesse : garder les données sensibles locales, ne mutualiser que l'apprentissage. Un serveur central agrège ces contributions en un modèle global, que chacun récupère amélioré. La donnée n'a jamais quitté son silo.

Pourquoi ce n'est pas une baguette magique

Ici, l'honnêteté impose une nuance que trop de plaquettes commerciales escamotent. Partager des gradients n'est pas anodin. Les mises à jour envoyées au serveur peuvent, à elles seules, laisser fuiter des informations privées.

Les attaques de gradient inversion permettent parfois de reconstituer partiellement les données d'entraînement à partir des seuls gradients partagés. Un serveur curieux peut chercher à extraire des contributions individuelles ; un client adversarial peut inférer des propriétés sur ses voisins. La survey arXiv de 2024 sur l'architecture, la performance et la sécurité du fédéré appliqué aux LLM en dresse la typologie complète.

D'où l'empilement de briques complémentaires. La differential privacy injecte un bruit calibré pour empêcher la mémorisation d'un individu précis. La secure aggregation — un partage de secret additif — garantit que le serveur ne voit que l'agrégat, jamais les mises à jour isolées. Le chiffrement homomorphe et les enclaves sécurisées (TEE) complètent l'arsenal, à un coût de calcul et de latence non négligeable.

On retrouve l'exacte tension vénitienne. Un chiffre trop simple se casse ; un chiffre trop complexe ralentit la diplomatie et multiplie les erreurs de déchiffrement. La sécurité se paie toujours en frottement.

Le prix à payer : gouvernance et performance

Décentraliser réduit la surface d'attaque. C'est vrai, et c'est précieux face à une menace que j'ai décrite ailleurs : la centralisation d'un corpus offre à un attaquant une cible unique qu'il suffit d'empoisonner avec quelques centaines de documents. Disperser la donnée, c'est refuser ce point de bascule.

Mais la décentralisation a un revers. La gouvernance se complexifie : gérer des clients hétérogènes, tolérer les pannes et les défections, orchestrer des tours de communication coûteux. La convergence est plus lente, la performance du modèle souvent dégradée par rapport à un entraînement centralisé.

Et même parfaitement fédéré, un LLM reste un LLM. Il prédit le mot suivant, donc il peut régurgiter en sortie un secret appris en entrée. Le fédéré protège le canal d'entraînement ; il ne dispense ni d'un filtrage des réponses ni d'une vigilance sur la surface d'attaque du modèle déployé, celle que je détaille dans mon guide sur la manière dont on attaque un LLM en production.

Sur le terrain : quand le fédéré est un mirage

Je déploie des systèmes RAG et des agents pour des clients de secteurs régulés, et je le dis sans détour dans mes missions de conseil et de réalisation sur mesure : dans neuf cas sur dix, le fédéré est une réponse surdimensionnée.

La plupart des dirigeants qui l'évoquent cherchent en réalité une chose simple : que leurs données ne partent pas nourrir le modèle d'un éditeur tiers. Or un déploiement on-premise — le modèle tourne sur leurs propres serveurs — ou un bon contrat de non-rétention avec un fournisseur cloud sérieux répond à ce besoin, pour une fraction de la complexité et du coût.

Le fédéré n'a de sens que dans une configuration précise : plusieurs silos qui gagneraient à mutualiser un modèle sans se voir mutuellement. Trois hôpitaux voulant un meilleur modèle diagnostique sans partager leurs dossiers patients. Des banques concurrentes améliorant une détection de fraude sur des schémas qu'aucune ne veut exposer. C'est là que la Sérénissime éclaire : plusieurs ambassades servant une même République, chacune avec son propre chiffre.

Trois questions avant de se lancer

Avant d'engager un projet fédéré, je pose systématiquement trois questions à un DSI ou un RSSI.

1. Mes données sont-elles réellement non-déplaçables ? Non par prudence, mais par contrainte juridique dure — RGPD sur données de santé, secret bancaire, données de défense. Si un simple on-premise règle le problème, le fédéré est un luxe.
2. Ai-je plusieurs silos qui gagneraient à mutualiser un modèle sans se voir ? Sans cette pluralité d'acteurs qui refusent de se dévoiler entre eux, le fédéré perd sa raison d'être.
3. Mon adversaire est-il capable d'attaquer un point central ? Si oui, la dissémination change la donne. Sinon, elle ajoute du frottement pour un gain théorique.

Si les trois réponses sont oui, alors le calcul confidentiel mérite une étude sérieuse, DP et secure aggregation comprises.

Ce que Venise savait déjà

Les cifristi n'ont pas inventé le secret. Ils ont inventé une manière de le faire agir à distance sans jamais le rendre lisible au monde traversé. Cinq siècles plus tard, l'apprentissage fédéré poursuit la même idée avec des gradients à la place des nomenclateurs.

Dans les deux cas, la leçon est identique et contre-intuitive. La sécurité la plus robuste ne vient pas de la forteresse où l'on entasse ses trésors, mais de la dissémination maîtrisée qui prive l'attaquant de sa cible unique. Encore faut-il, comme le Conseil des Dix, savoir que la complexité du chiffre a un prix — et ne le payer que lorsque le secret le vaut vraiment.