Durées de conservation : faut‑il supprimer une donnée encore présente dans un modèle entraîné ?

Par Emmanuel Forgues - 26 juin 2026

En Europe, le Règlement général sur la protection des données (RGPD) impose aux responsables de traitement de respecter des durées de conservation strictes. Or, les modèles d’intelligence artificielle (IA) conservent souvent, sous forme de paramètres, des traces indétectables de chaque observation utilisée pour l’apprentissage. Cette dualité soulève une question cruciale : lorsqu’une donnée personnelle doit être effacée, est‑il suffisant de la retirer du jeu de données source ou faut‑il également « dé‑entraîner » le modèle ? L’article analyse les exigences légales, les risques techniques et opérationnels, les solutions d’« machine unlearning », ainsi que les bonnes pratiques à mettre en œuvre pour concilier conformité, performance et maîtrise des coûts.

Introduction

Imaginez qu’un client demande la suppression de ses informations personnelles suite à l’exercice du droit à l’effacement (article 17 du RGPD). Votre équipe data‑science a déjà intégré ces données dans un modèle de recommandation qui alimente le moteur de votre site e‑commerce. La donnée n’apparaît plus dans les bases, mais les poids du réseau neuronal continuent d’en porter la trace. Si l’autorité de protection des données (APD) venait à auditer votre système, pourriez‑vous démontrer que le droit à l’effacement a été pleinement respecté ?

Cette situation se répète aujourd’hui dans tous les secteurs qui exploitent le machine learning (ML) : santé, finance, ressources humaines, marketing. La frontière entre « suppression de la donnée brute » et « effacement du savoir incrusté dans le modèle » n’est plus purement théorique. Les législateurs commencent à s’y intéresser – la CNIL a publié en 2022 un guide sur le droit à l’oubli et les systèmes d’IA, le Comité européen de protection des données (EDPB) travaille à une orientation « right to be forgotten for AI models ».

Cet article propose une analyse structurée pour aider les DSI, RSSI, responsables IA et décideurs à décider quand et comment supprimer réellement les informations contenues dans un modèle entraîné.

1. Cadre juridique des durées de conservation

Points à retenir

• Le RGPD considère une donnée « personnelle » dès lors qu’elle permet, directement ou indirectement, d’identifier une personne. Un modèle entraîné sur des données personnelles peut donc être assimilé à une donnée personnelle s’il permet de reconstruire, même partiellement, les informations originales.
• La jurisprudence (affaire Google Spain 2014) a déjà établi que les résultats de recherche sont soumis au droit à l’effacement lorsqu’ils révèlent des faits personnels. Par analogie, un modèle qui génère ou influence des réponses contenant des éléments d’une donnée supprimée peut être concerné.
• L’obligation de « documentation et traçabilité » (Art. 30 RGPD) impose aux organisations de pouvoir justifier du processus suivi pour effacer les données – y compris au niveau des modèles.

2. Le modèle d’apprentissage comme réservoir de données

2.1 Comment les informations sont‑elles mémorisées ?

Lors d’un entraînement supervisé, chaque observation ajuste les paramètres (poids) du modèle afin de réduire l’erreur sur le jeu de données. La mise à jour se fait généralement par descente de gradient stochastique ou variantes (Adam, RMSProp). Cette procédure ne conserve pas la donnée brute mais crée une empreinte statistique :

• Mémorisation locale : les poids d’un neurone peuvent devenir fortement influencés par des exemples rares ou atypiques.
• Sur‑apprentissage (overfitting) : le modèle reproduit fidèlement certaines entrées, ce qui augmente la probabilité de reconstruction de données individuelles.
• Embedding vectors : dans les modèles de langage ou de recommandation, chaque entité (utilisateur, produit) est représentée par un vecteur appris à partir des interactions passées – ces vecteurs sont directement dérivés des données d’origine.

2.2 Quand le modèle devient‑il une donnée personnelle ?

• Réidentification directe : si l’on peut interroger le modèle et obtenir, avec suffisamment de requêtes, un texte ou une image reproduisant exactement la donnée supprimée.
• Extraction de paramètres : des attaques d’inférence (model inversion) permettent de récupérer des attributs sensibles à partir des poids publiés ou accessibles via une API.
• Linkage : lorsqu’un modèle est combiné avec d’autres sources, les corrélations peuvent révéler l’identité d’une personne.

Ces scénarios sont décrits dans la littérature académique : Fredrikson et al., « Privacy in Machine Learning », 2015 [1] ; Nasr et al., « Machine learning models are vulnerable to attribute inference attacks », 2019 [2].

3. Risques liés à la persistance de données dans les modèles

4. Techniques de « machine unlearning » et atténuation technique

4.1 Panorama des approches

4.2 Mise en œuvre pratique

• Inventaire des modèles
• Cataloguer chaque artefact (type, version, jeux d’entraînement, hyper‑paramètres).
• Identifier les modèles qui ont été entraînés sur des données soumises à conservation limitée.

• Évaluation de l’influence
• Utiliser des métriques d’influence (e.g., Cook’s distance adaptée aux réseaux neuronaux) pour quantifier la contribution d’une observation au modèle.
• Prioriser les modèles où l’influence est élevée, car le risque de résidu est plus fort.

• Choix de la méthode
• Petits jeux de données / modèles simples : retraining complet reste la référence.
• Modèles volumineux (LLM, vision) : combiner DP pendant l’entraînement et exact unlearning pour les demandes ponctuelles.
• Environnements à forte contrainte de latence : approximation via fine‑tuning ou pruning.

• Automatisation du pipeline d’unlearning
• Intégrer une étape « unlearn » dans le CI/CD ML (ex. GitLab, Jenkins).
• Conserver les check‑points de gradients afin de permettre la reconstruction inverse si besoin.

• Audit et traçabilité
• Générer un journal d’opération indiquant : modèle concerné, identifiant de la donnée supprimée, méthode d’unlearning appliquée, résultat des tests de réidentification post‑unlearning.

4.3 Exemple de code (Python – exact unlearning)

import torch
from torch import nn, optim

def exact_unlearn(model: nn.Module,
                  data_point: tuple[torch.Tensor, torch.Tensor],
                  optimizer_state: dict):
    """
    Supprime l'influence d'un point d'entraînement en inversant le gradient.
    Nécessite que les gradients initiaux (avant entraînement) soient stockés.
    """
    x, y = data_point
    model.zero_grad()
    loss = nn.functional.cross_entropy(model(x), y)
    loss.backward()

    # Inverse des gradients sauvegardés lors de l'entraînement initial
    for p in model.parameters():
        if p.grad is not None:
            p.data += optimizer_state['lr'] * p.grad  # retour du pas d'optimisation

# Exemple d'utilisation
model = MyNet()
optimizer = optim.SGD(model.parameters(), lr=0.01)
# ... entraînement initial avec sauvegarde des gradients dans `grad_store` ...

exact_unlearn(model, (x_del, y_del), optimizer_state={'lr': 0.01})

Remarque : Cette implémentation ne fonctionne que pour les optimisateurs à pas constant et nécessite la conservation sécurisée des gradients originaux.

5. Implications opérationnelles et coûts

Analyse de rentabilité (ROI)

• Scénario A – Retraining complet chaque suppression : idéal sur le plan juridique, mais coût prohibitif pour les modèles LLM (> 100 M paramètres). ROI négatif dès que > 5 % des utilisateurs demandent l’effacement.
• Scénario B – DP + Approximate unlearning : réduction du risque de ré‑identification à < 1 % (selon études de Abadi et al., 2016) avec une perte de précision moyenne de 0,3 % sur les jeux standards. ROI positif dès que le taux d’effacement annuel dépasse 2 %.
• Scénario C – Hybrid (DP à l’entraînement + exact unlearning pour cas critiques) : combine la garantie mathématique du DP et la précision du retraining ciblé. Coût additionnel de ~15 % par rapport à une chaîne ML classique, mais permet d’éviter les sanctions majeures.

6. Gouvernance, audit et traçabilité

• Politique de rétention des données d’entraînement
• Définir pour chaque catégorie de donnée (clients, logs, images) une durée maximale conforme aux exigences légales.
• Automatiser la purge des jeux bruts via des scripts cron ou des solutions de data‑lifecycle management (ex. Informatica, Collibra).

• Registre des modèles (inspiré du Model Card de Mitchell et al., 2019)
• Version, date d’entraînement, jeu(s) de données source, méthodes de confidentialité appliquées, métriques de performance, niveau de conformité au droit à l’effacement.

• Processus de demande d’effacement
• Interface utilisateur (portail DPO) → ticket automatisé → identification du ou des modèles impactés → exécution du pipeline d’unlearning → génération d’un rapport d’audit signé.

• Contrôles internes
• Tests périodiques d’inférence de données (model inversion) pour vérifier l’absence de résidus après unlearning.
• Revue annuelle par le comité de gouvernance des données incluant DPO, RSSI, architectes IA.

7. Étude de cas – Suppression d’un jeu de données client dans un modèle de recommandation

Contexte

• Entreprise : plateforme e‑commerce européenne (CA ≈ 200 M€).
• Modèle : système de filtrage collaboratif basé sur des embeddings utilisateurs/produits, entraîné mensuellement sur 10 M d’interactions.
• Demande : un client a exercé son droit à l’effacement (article 17 RGPD) concernant toutes ses interactions historiques.

Démarche appliquée

| 4️⃣ Choix de la technique | Influence > 0,05 ⇒ recours à

Retour au blog