Confidentialité différentielle pour télémétrie produit

La confidentialité différentielle permet de mesurer l’usage d’un produit sans transformer la télémétrie en journal d’activité individuel déguisé. Pour des métriques de fonctionnalités utilisées, la bonne approche consiste à borner chaque contribution, ajouter le bruit avant collecte, puis n’agréger que des rapports rendus statistiquement ambigus.

→ Lire l’explication complète de la marmotte

Confidentialité différentielle locale et compromis de précision

La confidentialité différentielle, ou DP (Differential Privacy), formalise une propriété : ajouter ou retirer la contribution d’une personne ne doit pas changer fortement la distribution des résultats publiés. Le paramètre ε (epsilon) borne cette différence. Plus ε est faible, plus la protection est forte et plus le bruit dégrade la précision.

Pour une télémétrie collectée avant agrégation, il faut employer la confidentialité différentielle locale, ou LDP (Local Differential Privacy). Le client transforme sa mesure avant l’envoi. Le collecteur ne voit donc jamais la valeur exacte, même s’il est compromis, curieux ou vendu comme une « plateforme data souveraine », ce qui couvre étonnamment peu de propriétés cryptographiques.

Le compromis est brutal : LDP protège contre le collecteur, mais coûte beaucoup plus de précision que la confidentialité différentielle centrale, où un serveur de confiance ajoute le bruit après collecte. Pour classer trois fonctionnalités très populaires sur une population large, LDP fonctionne. Pour décider qu’un bouton est utilisé par 0,7 % des personnes sur une petite cohorte, LDP produit surtout une estimation, un intervalle de confiance et une occasion de découvrir que la variance ne négocie pas.

La recommandation est donc nette :

employer LDP lorsque le serveur de collecte ne doit jamais recevoir l’événement brut ;
limiter le domaine à des métriques peu nombreuses, stables et définies à l’avance ;
préférer la confidentialité différentielle centrale si une zone de collecte réellement isolée, auditée et à accès restreint existe ;
ne jamais présenter LDP comme une anonymisation universelle.

La page données couvre les sujets voisins de gouvernance et de protection des traitements. La confidentialité différentielle ne remplace ni le chiffrement en transit, ni la minimisation, ni la limitation des accès. Elle réduit ce qu’un rapport individuel révèle ; elle ne transforme pas un entrepôt mal gouverné en sanctuaire.

Définir la métrique avant de calibrer epsilon

Une garantie mathématique ne sauve pas une métrique mal définie. « Fonctionnalité la plus utilisée » doit préciser l’unité : nombre de sessions, nombre de jours actifs, dernier écran visité, ou au plus un usage sélectionné par appareil et par période. Ces définitions ne donnent pas les mêmes résultats et ne consomment pas le même budget de confidentialité.

Chaque client doit produire une contribution bornée. Une règle exploitable consiste à sélectionner au plus une fonctionnalité parmi une liste fermée pour une période fixe, par exemple une journée civile. Ajouter une catégorie aucune-utilisation évite de confondre absence d’activité et absence de rapport. Un appareil qui génère cent événements ne doit pas peser cent fois plus qu’un autre, sinon la sensibilité explose et le bruit avec elle.

Pour une variable catégorielle de k valeurs, le mécanisme de réponse aléatoire généralisée transmet la vraie catégorie avec une probabilité :

p = exp(ε) / (exp(ε) + k - 1)

Chaque autre catégorie est alors envoyée avec une probabilité q = 1 / (exp(ε) + k - 1). Après agrégation, le collecteur corrige le biais connu induit par p et q. Cette correction fournit une estimation non biaisée en théorie, pas un décompte exact. Les estimations négatives ou supérieures au nombre de participants doivent être conservées dans les calculs internes, puis bornées seulement au moment de l’affichage. Borner trop tôt introduit un biais silencieux, le genre de détail qui survit très bien à une présentation trimestrielle.

Un budget de confidentialité doit être défini par personne et par fenêtre de temps. Deux rapports indépendants à ε = 1 ne valent pas un seul rapport à ε = 1 : la perte de confidentialité se compose. Dans le pire cas, les epsilons s’additionnent. Un plafond mensuel, enregistré côté client et contrôlé côté collecte, est obligatoire. Le contrôle serveur ne suffit pas : un client compromis peut ignorer ses propres limites.

Exemple de réponse aléatoire catégorielle

L’exemple suivant transforme localement une catégorie parmi quatre fonctionnalités. Il utilise le générateur aléatoire cryptographiquement sûr de Python pour montrer le mécanisme. En production web, employer l’interface aléatoire du navigateur ; en environnement mobile, employer le générateur fourni par le système d’exploitation.

# Python 3.11+, sans dépendance externe.
# La valeur transmise est déjà bruitée : le collecteur ne reçoit pas `vraie_categorie`.

import math
import secrets

CATEGORIES = ["recherche", "export", "partage", "aucune-utilisation"]
EPSILON = 0.7

def rapport_prive(vraie_categorie: str) -> str:
    """Retourne une catégorie bruitée par réponse aléatoire généralisée."""
    if vraie_categorie not in CATEGORIES:
        raise ValueError("Catégorie hors du schéma de télémétrie")

    k = len(CATEGORIES)
    p = math.exp(EPSILON) / (math.exp(EPSILON) + k - 1)

    # Avec probabilité p, conserver la valeur réelle.
    if secrets.SystemRandom().random() < p:
        return vraie_categorie

    # Sinon, transmettre uniformément l'une des autres catégories.
    autres = [categorie for categorie in CATEGORIES if categorie != vraie_categorie]
    return secrets.choice(autres)

# Exemple : cet objet peut être envoyé une fois par période, jamais l'événement brut.
rapport = {"periode": "2026-09-23", "categorie": rapport_prive("export")}
print(rapport)

Le champ periode ne doit pas devenir un identifiant déguisé. Une granularité journalière est souvent suffisante ; une heure exacte facilite le recoupement avec des journaux réseau. Le rapport ne doit contenir ni identifiant de compte, ni adresse Internet Protocol (IP), ni empreinte de navigateur, ni chaîne de version excessivement précise. Ajouter ces données « seulement pour déboguer » annule souvent le bénéfice du mécanisme. La télémétrie adore les métadonnées, parce qu’elles ont l’air inoffensives jusqu’au moment où elles ne le sont plus.

Le transport doit utiliser Transport Layer Security (TLS), avec authentification du serveur et validation stricte du certificat. LDP réduit l’exposition de la mesure, pas l’exposition aux injections, rejouements ou détournements de trafic.

Surface d’attaque et limites de la garantie

LDP protège une valeur rapportée, pas l’identité réseau de l’émetteur. Un collecteur qui conserve l’adresse IP, l’heure à la milliseconde et un identifiant publicitaire peut toujours suivre un appareil, même si la catégorie transmise est bruitée. La séparation doit être architecturale : le point d’ingestion pseudonymise ou élimine les métadonnées de transport avant stockage analytique, avec des journaux d’accès distincts et une rétention courte.

Le rejeu constitue une attaque directe contre la qualité statistique. Un adversaire capable de répéter un même rapport peut gonfler artificiellement une fonctionnalité. Chaque rapport doit porter un jeton d’anti-rejeu lié à une période et vérifié par le serveur, sans servir ensuite de clé analytique. Un code d’authentification de message, ou MAC (Message Authentication Code), calculé avec une clé propre à l’installation peut protéger l’intégrité du paquet. Cette clé doit être rotative et révocable ; elle ne doit jamais être recyclée pour chiffrer des données ou signer des versions.

Un client modifié peut aussi mentir sur sa catégorie. LDP ne garantit pas l’intégrité de la mesure, seulement la confidentialité de la contribution. Les contre-mesures sont le plafonnement par installation, la détection de distributions aberrantes, l’attestation de plateforme lorsqu’elle est disponible, et la comparaison avec des métriques opérationnelles indépendantes. Aucune de ces mesures ne rend les données parfaites. Les chiffres parfaits sont généralement ceux qui ont survécu trop longtemps à leur propre contrôle qualité.

L’attaque par différence doit être traitée au niveau des publications. Publier des tableaux trop fins, puis publier le même tableau avec une ligne en moins, permet parfois d’isoler une estimation. Les résultats destinés à l’analyse doivent respecter des cohortes minimales, des dimensions limitées et un registre des requêtes publiées. Les principes de cryptographie appliquée aident ici à ne pas confondre une primitive avec un système complet : le mécanisme est correct, l’assemblage peut rester catastrophique.

Exploitation, rotation et reprise de la télémétrie

Le schéma de catégories, la valeur d’epsilon, le plafond de rapports et la période constituent un contrat versionné. Modifier l’un de ces paramètres casse la comparabilité historique. Chaque export analytique doit donc inclure la version du mécanisme, le nombre de rapports reçus, la formule d’estimation et un intervalle d’incertitude.

Les clés de MAC doivent être stockées hors du code applicatif, distribuées par un mécanisme de secrets et renouvelées avec une période de chevauchement limitée. La rotation doit accepter l’ancienne et la nouvelle clé durant une fenêtre définie, puis rejeter l’ancienne. En cas de fuite, révoquer la clé empêche les nouveaux rapports frauduleux ; elle ne retire pas les rapports déjà acceptés. Les lois de la causalité restent hostiles aux plans de remédiation rétroactifs.

Les sauvegardes doivent contenir les agrégats et les métadonnées de méthode, pas les paquets bruts au-delà de la rétention nécessaire au contrôle d’intégrité. Une reprise doit pouvoir recalculer les estimations depuis des rapports bruités, jamais depuis des événements nominaux conservés « au cas où ». La supervision doit alerter sur la chute du taux de participation, l’épuisement du budget, la dérive des catégories inconnues, les échecs de validation et les pics de rejeu.

Enfin, LDP ne démontre pas la conformité à un texte réglementaire et ne dispense pas d’une base légale, d’une information des personnes ou d’une politique de conservation. Elle apporte une propriété technique mesurable. C’est déjà beaucoup ; lui demander de résoudre la gouvernance entière reviendrait à confier un extincteur au comité de direction.

🐝 Ce qui arrive si on s’en passe

Sans bruit local, chaque rapport de télémétrie devient un fait attribuable : la catégorie reçue est la vraie, et l’appareil émetteur perd tout déni plausible sur son usage. Toute personne disposant d’un accès en lecture au stockage, à un tampon d’ingestion, à un journal applicatif ou à un export destiné à un prestataire obtient alors une chronologie exacte des fonctionnalités utilisées par appareil. Les fonctionnalités rares aggravent l’exposition : leur simple présence dans un rapport agit comme une empreinte qui distingue une installation parmi des milliers et permet de la relier à d’autres jeux de données partageant la même période. Une demande d’accès, une réquisition ou une copie de sauvegarde porte ainsi sur des comportements individuels réels, et aucune correction statistique ultérieure ne peut rendre ambigus des événements déjà collectés en clair.

🦫 Explication de la marmotte 🍫

Pour mesurer l’usage d’un produit, l’application choisit d’abord une question limitée, par exemple la fonctionnalité utilisée pendant une journée. Elle ne doit pas envoyer tous les clics, ni permettre à une personne très active de compter beaucoup plus que les autres. Chaque appareil produit donc au plus une réponse dans une liste prévue à l’avance, y compris une réponse indiquant qu’aucune fonctionnalité n’a été utilisée.

Avant l’envoi, l’application modifie parfois volontairement sa réponse. Elle peut garder la vraie réponse, ou en envoyer une autre choisie selon une règle calculée. La règle est réglée par un nombre qui détermine le compromis : davantage de protection produit des résultats moins précis. Le serveur reçoit seulement ces réponses modifiées, puis les additionne. Comme la règle de modification est connue, il peut corriger les totaux pour estimer la tendance réelle.

Cette méthode échoue si l’application envoie aussi un identifiant, une adresse réseau ou une heure trop précise permettant de reconnaître l’appareil. Elle échoue aussi si un même appareil répond sans limite, si un pirate rejoue des messages, ou si les résultats sont découpés en groupes trop petits. Les réponses doivent donc être limitées, protégées contre les répétitions, surveillées et supprimées après la durée nécessaire. Le résultat final est une estimation avec une marge d’erreur, pas une liste fiable des actions de chaque personne.

Pages voisines

La citent

Confidentialité différentielle pour télémétrie produit

Elle cite

: les deux pages se citent l’une l’autre.

Confidentialité différentielle pour télémétrie produit

Confidentialité différentielle pour télémétrie produit

Confidentialité différentielle locale et compromis de précision

Définir la métrique avant de calibrer epsilon

Exemple de réponse aléatoire catégorielle

Surface d’attaque et limites de la garantie

Exploitation, rotation et reprise de la télémétrie

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines