Qu'est-ce que l'apprentissage automatique préservant la confidentialité ?

Une équipe décide d'exécuter un modèle de langage sur ses propres serveurs plutôt que d'appeler une API externe. La motivation est la confidentialité : garder les données sensibles en interne, ne jamais les confier à un tiers. L'intuition est saine, et le contrôle qu'elle apporte est réel, mais elle est aussi incomplète. On peut amener un modèle entraîné sur des dossiers privés à révéler si l'enregistrement d'une personne précise figurait dans son jeu d'entraînement. Des mises à jour fédérées qui ne transportent jamais de données brutes peuvent être inversées pour reconstituer les images qui les ont produites. Un grand modèle peut mémoriser et restituer des fragments de ce sur quoi il a été entraîné. Les données sont restées à la maison, et le modèle a quand même fuité.

C'est cet écart, entre se sentir confidentiel et l'être de façon démontrable, que traite l'apprentissage automatique préservant la confidentialité. Le pipeline d'apprentissage automatique classique exige que les données brutes soient accessibles à l'infrastructure d'entraînement, ce qui entre en collision avec la réglementation sur la vie privée, avec les exigences de souveraineté des données et avec des partenaires qui refusent tout partage de leurs jeux de données. L'apprentissage automatique préservant la confidentialité est la famille de techniques qui résout cette collision.

La distinction utile sépare les techniques qui réduisent les déplacements de données, celles qui bornent ce que les sorties peuvent révéler et celles qui gardent les données confidentielles pendant le calcul. L'auto-hébergement vient s'ajouter à ces contrôles plutôt que les remplacer.

La version courte

• L'apprentissage automatique préservant la confidentialité (PPML) est une catégorie générale, pas une méthode unique. Cet article se concentre sur quatre approches majeures : l'apprentissage fédéré, la confidentialité différentielle, le chiffrement homomorphe et le calcul multipartite sécurisé. D'autres architectures renforçant la confidentialité, notamment les environnements d'exécution de confiance, peuvent aussi apparaître dans les systèmes PPML.
• L'apprentissage fédéré seul n'offre aucune garantie formelle de confidentialité. Il maintient les données brutes à la source, mais les mises à jour de gradients partagées peuvent parfois être inversées pour reconstituer des enregistrements d'entraînement. La confidentialité différentielle est une façon courante d'ajouter une borne formelle sur les fuites.
• La force de la confidentialité différentielle se résume généralement à epsilon. La garantie dépend aussi de delta, de l'unité protégée et de la méthode de comptabilité de la confidentialité. Une garantie formelle assortie de paramètres faibles peut rester une garantie sur le papier et du théâtre en pratique.
• Le chiffrement homomorphe est bien réel, et lent. Calculer sur des données chiffrées fonctionne, mais le surcoût le cantonne aujourd'hui à des modèles plus simples, à de l'inférence tolérante à la latence et à des flux d'affinage expérimentaux, pas à l'entraînement ordinaire de grands modèles ni à leur préentraînement complet.
• Auto-héberger un modèle relève de la localisation des données, pas du PPML. Garder les données sur une infrastructure que vous contrôlez détermine qui peut y accéder. Cela ne détermine pas ce que le modèle lui-même peut révéler.

Note de périmètre : ceci est un article conceptuel, pas un guide de mise en œuvre. Il ne traite en profondeur ni de l'installation de bibliothèques, ni du choix d'epsilon, ni de la conformité réglementaire, ni de l'affinage privé de LLM. L'objectif ici, c'est la carte. Les indications virage par virage relèvent de guides de mise en œuvre dédiés.

Comment l'apprentissage automatique préservant la confidentialité protège les données

L'apprentissage automatique préservant la confidentialité est un terme générique pour les méthodes qui réduisent, restreignent ou bornent formellement l'exposition d'information lors de l'entraînement des modèles, de l'inférence et de l'analyse collaborative. Cet article se concentre sur quatre approches majeures : l'apprentissage fédéré, la confidentialité différentielle, le chiffrement homomorphe et le calcul multipartite sécurisé. Elles protègent des actifs différents sous des modèles de menace différents, et ne doivent donc pas être traitées comme des garanties interchangeables.

Le problème est simple : les pipelines ML standards supposent souvent que le processus d'entraînement peut accéder aux enregistrements bruts, alors que la réglementation sur la vie privée, les exigences de souveraineté des données et les accords avec les partenaires empêchent souvent cet accès. Les quatre familles répondent à cette contrainte de façons différentes : déplacer le calcul vers les données au lieu de déplacer les données vers le calcul (apprentissage fédéré), ajouter un bruit calibré pour que les sorties révèlent moins sur une personne donnée (confidentialité différentielle), calculer sur des données qui restent chiffrées (chiffrement homomorphe), ou laisser plusieurs parties calculer conjointement un résultat sans s'exposer mutuellement leurs entrées brutes (calcul multipartite sécurisé).

Le risque sous-jacent est exposé sans détour dans les recommandations de Google sur l'IA responsable : les modèles d'apprentissage automatique peuvent retenir ou révéler des aspects des données auxquelles ils ont été exposés, et le travail sur la confidentialité existe pour poser des garde-fous autour de cela. Le PPML répond à ce risque, et il se distingue de la simple anonymisation, pour des raisons que la section suivante rend concrètes.

Pourquoi l'anonymisation ne suffit-elle pas ?

Des données anonymisées peuvent encore être ré-identifiées. Retirer les noms et les identifiants évidents d'un jeu de données réduit l'exposition la plus visible, mais ne garantit pas la confidentialité dès lors que ces données peuvent être recoupées avec des informations extérieures. C'est la faiblesse récurrente des approches de dé-identification comme le k-anonymat : elles peuvent réduire l'identifiabilité sous certaines hypothèses, mais elles n'apportent pas les garanties formelles offertes par des techniques comme la confidentialité différentielle ou les méthodes PPML cryptographiques.

Cette distinction pratique compte pour quiconque s'est entendu dire « on l'a anonymisé, donc tout va bien ». L'anonymisation est une affirmation portant sur un jeu de données dans un contexte et un modèle de menace précis. Une attaque par recoupement n'a pas besoin de casser le chiffrement ni de contourner les contrôles d'accès. Il lui suffit d'un autre jeu de données qui recoupe le vôtre. Ce point est énoncé directement dans les recommandations du NIST sur la dé-identification, qui note que des données dé-identifiées peuvent encore être ré-identifiées en les reliant à des jeux de données auxiliaires.

La confidentialité différentielle apporte quelque chose que la dé-identification ordinaire n'apporte pas : une borne mathématique sur l'influence que les données d'un individu peuvent avoir sur un résultat publié, sous une unité de confidentialité et un modèle de menace définis. Le chiffrement homomorphe et le SMPC offrent d'autres formes de confidentialité cryptographique, tandis que l'apprentissage fédéré change surtout l'endroit où les données sont traitées. Ces garanties sont apparentées, mais elles ne sont pas identiques.

Comment fonctionne l'apprentissage fédéré, et pourquoi ne suffit-il pas à lui seul ?

Dans l'apprentissage fédéré, un modèle global est envoyé vers des appareils ou serveurs locaux, s'entraîne sur les données qui s'y trouvent, et ne renvoie au centre que ses mises à jour de paramètres. Les données brutes ne bougent jamais. C'est un schéma réellement utile, et il tourne en production à grande échelle. Ce n'est pas non plus, en soi, une garantie de confidentialité.

Le mécanisme va du modèle vers les données plutôt que des données vers le modèle. Le déploiement Gboard de Google fait tourner plus de 30 modèles de langage sur l'appareil, dans plus de 7 langues et plus de 15 pays, en s'entraînant sur du texte qui ne quitte jamais le téléphone. C'est l'apprentissage fédéré qui fonctionne comme annoncé : le clavier s'améliore sans que Google collecte ce que vous avez tapé.

Le problème, c'est ce qui voyage dans les mises à jour. Les gradients portent de l'information sur les données qui les ont produits, et cette information peut être récupérée. Zhu, Liu et Han l'ont montré dans Deep Leakage from Gradients (NeurIPS 2019), en démontrant des attaques par inversion de gradient qui récupèrent des exemples d'entraînement privés à partir de mises à jour de modèle partagées, avec une reconstruction d'images exacte au pixel près et une correspondance au token près pour le texte dans leurs expériences. L'apprentissage fédéré a réduit les déplacements de données. Il n'a pas éliminé le risque de fuite.

Si l'objectif est de borner ce que la participation peut révéler, la confidentialité différentielle est un ajout courant. L'agrégation sécurisée traite un risque différent en cachant les mises à jour individuelles des clients au serveur coordinateur. Gboard combine apprentissage fédéré et confidentialité différentielle formelle plutôt que de s'appuyer sur la seule fédération.

Remarque : L'apprentissage fédéré est souvent qualifié de « privé » parce que les données brutes restent à la source. Cette description est trompeuse. Sans protection supplémentaire, les mises à jour fédérées peuvent porter assez de signal pour reconstruire des enregistrements d'entraînement. Le DP-FL ajoute une garantie formelle de confidentialité différentielle plutôt que de s'appuyer sur la seule fédération. La fédération, à elle seule, est un choix de traitement des données, pas une preuve de confidentialité.

Qu'est-ce que la confidentialité différentielle, et que contrôle réellement epsilon ?

La confidentialité différentielle est une définition mathématique qui borne à quel point une analyse peut changer lorsqu'une unité de confidentialité est ajoutée ou retirée. Beaucoup de mécanismes obtiennent cette garantie en ajoutant de l'aléa calibré. Epsilon est un paramètre visible, mais une garantie qui a du sens dépend aussi de l'unité de confidentialité, de la variante de DP et de tout paramètre supplémentaire comme delta, sans oublier la composition, la comptabilité et les détails d'implémentation.

Epsilon est décrit comme le budget de confidentialité dans le glossaire de NVIDIA : des valeurs plus basses signifient une confidentialité plus forte mais plus de bruit, des valeurs plus hautes préservent la précision au prix de garanties plus faibles. Une façon courante d'appliquer la confidentialité différentielle pendant l'entraînement en apprentissage profond est le DP-SGD, la descente de gradient stochastique différentiellement privée : écrêter chaque gradient par échantillon à une taille bornée, ajouter un bruit gaussien calibré, puis agréger. L'écrêtage limite l'influence qu'un exemple peut avoir sur le modèle. Le bruit masque l'influence qui subsiste.

Ce budget se consomme. Le mécanisme est décrit dans la documentation de Tumult Analytics sur les budgets de confidentialité : chaque requête contre un jeu de données protégé dépense une part du budget de confidentialité. La façon dont ces dépenses s'additionnent relève de la théorie standard de la confidentialité différentielle, exposée dans The Algorithmic Foundations of Differential Privacy, de Dwork et Roth : en composition de base, k requêtes chacune au paramètre epsilon s'additionnent en une perte de confidentialité totale de k fois epsilon, et les théorèmes de composition avancée donnent des bornes plus serrées. Vous n'avez pas droit à un nombre illimité de questions. Vous avez un budget, et vous le dépensez.

Le choix des paramètres décide donc si la garantie a un sens en pratique. Une critique des approches de la confidentialité en apprentissage automatique, évaluée par les pairs, soutient que le cadrage mathématique peut donner un « vernis d'objectivité » qui sert ensuite à blanchir un projet. Réglez les paramètres de confidentialité assez faiblement et la garantie peut devenir quasi vide de sens tout en permettant à une équipe d'affirmer qu'elle a satisfait la confidentialité différentielle. La garantie est réelle. Sa force pratique, elle, est un choix de conception.

Remarque : Une garantie de confidentialité différentielle n'a de sens que si vous connaissez les paramètres de confidentialité et l'unité qu'ils protègent. Un epsilon très élevé, un delta lâche ou une comptabilité floue peuvent rendre une garantie techniquement valide très peu protectrice en pratique. Lire « ce système utilise la confidentialité différentielle » ne vous apprend presque rien en soi : ce sont les paramètres de confidentialité, ce sur quoi ils ont été mesurés et la façon dont ils se composent qui portent le sens. Des déploiements concrets le rendent tangible. Google annonce un epsilon de 1 au niveau utilisateur pour son système Provably Private Insights, mais c'est le choix d'un déploiement pour un cas d'usage, pas un chiffre à recopier.

Comment le chiffrement homomorphe calcule-t-il sur des données qu'il ne déchiffre jamais ?

Le chiffrement totalement homomorphe (FHE) permet à un serveur d'exécuter des calculs directement sur des données chiffrées et de renvoyer un résultat chiffré que seul le propriétaire des données peut déchiffrer. Le serveur fait le travail sans jamais voir le texte en clair. C'est l'un des outils de confidentialité les plus puissants du domaine, mais le compromis se paie en performances.

L'analogie utile est celle d'une boîte à gants verrouillée avec des gants intégrés : un opérateur peut y glisser les mains et manipuler ce qui s'y trouve sans jamais ouvrir la boîte ni en sortir le contenu. Le propriétaire des données détient la seule clé. Le calcul se fait sur le contenu scellé, et seul le propriétaire peut ouvrir la boîte pour lire le résultat. C'est ce que le FHE fait mathématiquement : opérer sur du chiffré de sorte que déchiffrer la sortie donne la même réponse qu'un calcul sur le clair.

Le hic, c'est le coût. Concrete ML, de Zama, convertit des modèles scikit-learn et PyTorch en équivalents compatibles FHE sans obliger l'utilisateur à manipuler directement des primitives cryptographiques, et sa version v1.9 est sortie le 10 avril 2025. Mais les propres bancs d'essai du projet montrent le surcoût : un réseau de classification d'images CIFAR10 tourne à environ 4 minutes par image sous FHE. C'est acceptable pour certaines inférences tolérantes à la latence, pour des modèles plus simples et pour de l'affinage chiffré expérimental. Ce n'est toujours pas une voie praticable vers le préentraînement complet de grands modèles ni vers les charges d'entraînement ordinaires de grands modèles. Le FHE est aujourd'hui un instrument de précision pour un ensemble restreint de tâches, pas une couche de confidentialité polyvalente.

Qu'est-ce que le calcul multipartite sécurisé en apprentissage automatique ?

Le calcul multipartite sécurisé (SMPC) permet à plusieurs parties de calculer conjointement une fonction sur leurs entrées privées combinées sans qu'aucune partie ne voie les données brutes des autres. L'entrée de chaque partie reste secrète. Seul le résultat convenu devient connu. Le SMPC peut être construit avec des techniques comme le partage de secret, les circuits brouillés, le transfert inconscient et leurs combinaisons. Dans les protocoles de partage de secret, les valeurs privées sont découpées en parts de sorte qu'une part isolée ne révèle pas l'entrée. Les protocoles à circuits brouillés fonctionnent autrement : ils encodent un calcul pour que les parties puissent l'évaluer sans révéler leurs entrées privées.

Le cas d'usage naturel est la collaboration entre organisations. Plusieurs hôpitaux veulent entraîner un modèle sur leurs données patients combinées, mais aucun ne peut légalement partager ses dossiers avec les autres. Le SMPC leur permet de calculer le modèle commun comme si les données étaient mises en commun, tandis que les dossiers de chaque hôpital restent scellés chez lui. Le surcoût du SMPC dépend fortement du protocole, du modèle de sécurité, des conditions réseau, du nombre de parties et de la fonction évaluée. Beaucoup de protocoles sont gourmands en communication, si bien que la performance doit se mesurer sur la collaboration précise plutôt que se classer de façon générique face à la confidentialité différentielle ou au FHE. Ce schéma exact pour l'apprentissage automatique en santé est traité dans une étude de 2025 parue dans WIREs Computational Statistics.

Un modèle d'apprentissage automatique peut-il divulguer ses données d'entraînement ?

Oui. Un modèle entraîné peut trahir ses données d'entraînement de plusieurs façons distinctes : l'inférence d'appartenance révèle si un enregistrement précis figurait dans le jeu d'entraînement, l'inversion de modèle et la fuite par gradients permettent de reconstruire des enregistrements, et les grands modèles de langage peuvent mémoriser et restituer mot pour mot des morceaux de leurs données d'entraînement. Ce ne sont pas des hypothèses. Ce sont des attaques démontrées, et elles sont la raison d'être des techniques ci-dessus.

Le résultat fondateur, c'est l'inférence d'appartenance. Shokri et ses collègues, dans Membership Inference Attacks Against Machine Learning Models (IEEE S&P 2017), ont montré qu'un attaquant observant le comportement de prédiction d'un modèle peut déterminer si un enregistrement donné faisait partie de son jeu d'entraînement. Cela paraît abstrait jusqu'à ce que le jeu d'entraînement soit « les patients porteurs d'un diagnostic précis », auquel cas l'appartenance est justement le fait sensible. L'inversion de modèle et les attaques par fuite de gradients évoquées plus haut étendent cela de « cet enregistrement était-il présent » à « reconstruire l'enregistrement ».

La frontière, ce sont les grands modèles de langage, et c'est là que les cadres PPML plus anciens s'adaptent le moins bien. Des travaux sur l'émission de données d'entraînement par les LLM documentent que les grands modèles mémorisent des portions de leur corpus d'entraînement et peuvent être amenés à le reproduire, des attaques par extraction récupérant des données d'entraînement mot pour mot ou quasi. Le DP-SGD peut s'appliquer à un affinage privé, mais le coût en précision et en calcul à l'échelle des grands modèles est sévère, ce qui explique en partie pourquoi l'atelier PPML 2026 d'Apple a consacré toute une session aux modèles de fondation et à la confidentialité. Les défenses qui fonctionnent proprement pour un classifieur de régression logistique ne se transposent pas gratuitement à un modèle de plusieurs milliards de paramètres.

PPML et IA auto-hébergée : ce que l'inférence locale vous apporte, et ce qu'elle ne vous apporte pas

Auto-héberger un modèle garde vos données sur une infrastructure que vous contrôlez. C'est un vrai gain de contrôle d'accès et de localisation des données : elles ne voyagent pas vers un tiers, et vous décidez qui peut atteindre la machine sur laquelle il tourne. Ce n'est pas pour autant de l'apprentissage automatique préservant la confidentialité. L'inférence locale ne fait rien, à elle seule, contre l'inférence d'appartenance visant le modèle, et elle n'empêche pas un modèle de révéler ce qu'il a mémorisé.

Les deux résolvent des moitiés différentes du problème, et les confondre est une erreur fréquente dans ce domaine. La localisation des données régit qui peut atteindre les données : une question de périmètre, à laquelle répondent l'endroit où résident les octets et celui qui détient les clés de la pièce. Le PPML régit ce que le modèle lui-même peut révéler, une question de fuite d'information à laquelle répondent les quatre techniques ci-dessus. Faire tourner un modèle sur votre propre serveur est une réponse solide à la première question et aucune réponse à la seconde.

Si la question que vous pesez est de savoir s'il faut faire tourner le modèle vous-même, le versant coût de cette décision mérite sa propre analyse : voir Auto-héberger un LLM open-weight vs une API : les vrais calculs de coût.

Pour une ingénieure plateforme ou infrastructure, la lecture opérationnelle est celle-ci : « ça tourne sur notre propre serveur » peut satisfaire certaines exigences de localisation des données et de contrôle d'accès, mais cela ne contraint pas en soi ce que le modèle peut révéler. Si le modèle ou ses sorties sont un jour partagés, entre équipes, avec des partenaires ou dans un produit, le périmètre que vous avez bâti autour du matériel ne suit pas le modèle dehors. Les choix d'architecture qui déplacent réellement la garantie sont ceux du PPML : confidentialité différentielle sur les sorties que vous publiez, DP-FL pour l'entraînement sur des sites que vous ne pouvez pas centraliser, calcul fondé sur le chiffrement là où les données ne doivent pas être exposées même à votre propre infrastructure. Le déploiement Provably Private Insights de Google est instructif justement parce qu'il combine plusieurs contrôles, confidentialité différentielle, environnements d'exécution de confiance et analytique fédérée confidentielle, au lieu de s'appuyer sur un seul. La localisation fait partie d'une véritable architecture. Elle n'en constitue pas la totalité.

Quand faut-il utiliser quelle technique PPML ?

La logique de sélection suit la contrainte, pas la mode. Utilisez l'apprentissage fédéré quand les données ne peuvent pas être centralisées. Utilisez la confidentialité différentielle quand il vous faut une garantie formelle sur ce que le modèle révèle. Utilisez le chiffrement homomorphe quand le calcul doit se faire sur des données jamais déchiffrées et que la latence le permet. Utilisez le calcul multipartite sécurisé quand plusieurs parties doivent calculer ensemble sans partager leurs entrées.

Les techniques se combinent aussi. Le DP-FL en est l'exemple le plus net : choisissez les contrôles selon les garanties dont le système a besoin, plutôt que de forcer le problème dans une seule technique.

Les compromis en un coup d'œil :

Ces caractérisations sont tirées d'une étude de mars 2026 sur le PPML orientée IoT, des bancs d'essai Concrete ML de Zama et de la littérature sur la ré-identification.

Le tableau n'est qu'un point de départ. Les systèmes réels combinent souvent les techniques : un problème d'entraînement multisite qui exige en plus une garantie formelle de confidentialité est généralement un problème DP-FL, pas un choix entre apprentissage fédéré et confidentialité différentielle. Qui veut structurer la décision plus rigoureusement peut travailler avec le cadre structuré d'aide à la décision pour développeurs , publié fin 2024.

Côté outillage, TensorFlow Federated fournit un cadre open source pour l'apprentissage fédéré et les calculs sur données décentralisées. TensorFlow Privacy fournit des utilitaires d'entraînement différentiellement privé, les bibliothèques Differential Privacy de Google couvrent les statistiques et l'agrégation différentiellement privées, et Concrete ML fournit la voie FHE. PySyft se concentre désormais plus largement sur la science des données à distance préservant la confidentialité, où les calculs s'exécutent contre des données détenues par leur propriétaire et où seuls les résultats approuvés sont partagés. Voilà les noms et ce qu'ils font. L'installation relève de guides de mise en œuvre dédiés, pas d'ici. La leçon qui revient, c'est que les maths peuvent tenir pendant que l'implémentation échoue. La garantie ne compte que si le système est conçu autour du bon modèle de menace et que les paramètres de confidentialité correspondent au risque à protéger.

Foire aux questions

Que signifie PPML ?

L'apprentissage automatique préservant la confidentialité est un terme générique désignant les méthodes qui réduisent, restreignent ou bornent formellement l'exposition d'information pendant l'apprentissage automatique. Les principales approches incluent l'apprentissage fédéré, la confidentialité différentielle, le chiffrement homomorphe et le calcul multipartite sécurisé, mais elles protègent des actifs différents et offrent des garanties de nature différente.

L'apprentissage fédéré suffit-il à protéger la vie privée ?

Non. L'apprentissage fédéré garde les données brutes à leur source, mais les mises à jour de paramètres qu'il partage peuvent être inversées pour reconstituer des enregistrements d'entraînement, via des attaques par inversion de gradient. À lui seul, il n'offre aucune garantie formelle de confidentialité. La confidentialité différentielle peut ajouter une borne formelle sur les fuites, ce qui donne la combinaison qu'on appelle habituellement DP-FL.

Quelle valeur d'epsilon utiliser pour la confidentialité différentielle ?

Il n'existe pas de valeur universelle. Epsilon est l'un des principaux paramètres du compromis confidentialité-précision : des valeurs plus basses signifient en général plus de confidentialité et plus de bruit, tandis que des valeurs plus hautes signifient en général moins de confidentialité et moins de bruit. Le bon réglage dépend de la sensibilité des données et du risque que vous pouvez accepter. Il n'y a aucun seuil universel qui rendrait une valeur d'epsilon « sûre ». Évaluez epsilon conjointement avec l'unité de confidentialité, la variante de DP et tout paramètre supplémentaire comme delta, la méthode de composition et le modèle de menace du système.

Quelle est la différence entre le PPML et l'anonymisation ?

L'anonymisation retire les identifiants d'un jeu de données, mais des enregistrements anonymisés peuvent être ré-identifiés en les reliant à des données auxiliaires d'autres sources. Certaines techniques PPML offrent des garanties formelles que l'anonymisation ordinaire n'offre pas. La confidentialité différentielle peut borner l'influence des données d'un individu sur un résultat publié, tandis que le FHE et le SMPC apportent d'autres formes de confidentialité cryptographique.

Peut-on extraire des données d'entraînement d'un modèle d'apprentissage automatique ?

Oui. Les attaques par inférence d'appartenance révèlent si un enregistrement précis figurait dans le jeu d'entraînement, l'inversion de modèle et la fuite par gradients permettent de reconstruire des enregistrements, et les grands modèles de langage peuvent mémoriser et restituer mot pour mot des données d'entraînement. Ce sont des attaques démontrées et documentées dans la littérature de sécurité, pas des risques hypothétiques.

Auto-héberger un modèle garantit-il la confidentialité des données ?

Non. L'auto-hébergement garde les données sur une infrastructure que vous contrôlez, ce qui relève du contrôle d'accès et de la localisation des données, un vrai gain pour gouverner qui peut atteindre ces données. Ce n'est pas de l'apprentissage automatique préservant la confidentialité et cela n'arrête ni l'inférence d'appartenance ni les fuites par mémorisation. Cela se marie bien avec les techniques PPML, mais ne les remplace pas.

Quels outils open source existent pour l'apprentissage automatique préservant la confidentialité ?

Plusieurs outils open source couvrent différentes parties du PPML. TensorFlow Federated prend en charge l'apprentissage fédéré et les calculs sur données décentralisées, TensorFlow Privacy fournit des utilitaires d'entraînement différentiellement privé, et Concrete ML couvre l'apprentissage automatique avec FHE. PySyft se concentre désormais sur la science des données à distance préservant la confidentialité, où les calculs s'exécutent contre des données contrôlées par leur propriétaire et où seuls les résultats approuvés sont partagés.