Désapprentissage machine : un workflow pratique de suppression des données d’AI

Si quelqu’un vous demande de supprimer ses données d’un système d’AI, retirer une seule ligne d’une base de données ne suffit pas. Le désapprentissage machine peut réduire ou réorienter la réponse d’un modèle à des exemples d’entraînement spécifiques, mais il ne nettoie pas automatiquement le reste de la stack : index vectoriels, adaptateurs fine-tunés, prompts mis en cache, checkpoints, répliques, sauvegardes et exports. Le NIST définit le désapprentissage machine comme la suppression sélective de l’influence de points d’entraînement spécifiques d’un modèle entraîné, et précise explicitement que des techniques approximatives efficaces peuvent éviter un réentraînement complet depuis zéro. C’est plus limité que de dire que « tout le système a oublié les données ». NIST

Pour la plupart des équipes, la réponse pratique doit être en couches. Commencez par retracer où les données sont allées. Ensuite, empêchez leur réutilisation. Puis supprimez ou restreignez les artefacts dérivés. Ce n’est qu’après cela que vous décidez si les poids du modèle doivent être réentraînés ou faire l’objet d’un désapprentissage approximatif. Le Machine Unlearning Challenge de Google de 2023 adoptait exactement cette approche centrée sur le modèle : un modèle ayant subi un désapprentissage doit devenir difficile à distinguer d’un modèle réentraîné sans l’ensemble à oublier, tout en conservant ses performances sur l’ensemble conservé. Google Research

Table des matières

Ce que signifie réellement le désapprentissage machine

Le désapprentissage machine est une opération au niveau du modèle. Il consiste à réduire l’influence de données sélectionnées sur le comportement d’un modèle entraîné. Cela peut signifier un réentraînement exact sur l’ensemble conservé, ou une méthode approximative visant à s’en approcher suffisamment sans supporter le coût total du réentraînement. Le NIST utilise ces deux notions dans son entrée de glossaire, et la page du challenge de Google présente comme référence idéale la similarité avec un modèle réentraîné depuis zéro sans les exemples oubliés. NIST Google Research

Cette définition est importante, car les systèmes d’AI ne s’arrêtent que rarement aux poids du modèle. Une stack de production comprend généralement :

Supprimer les données d’une seule de ces couches peut toujours les laisser accessibles ailleurs. En pratique, « supprimer ces données de l’AI » est d’abord un problème de traçabilité, avant de devenir un problème de modification du modèle.

Pourquoi un flux de suppression normal ne suffit pas

De nombreux produits d’AI n’ont jamais entraîné leur modèle sur les données qu’on leur demande de supprimer. Ils les ont seulement récupérées au moment de l’inférence. Dans ce cas, il faut supprimer les enregistrements sources, les embeddings dérivés, les caches et les chemins d’accès. Le désapprentissage du modèle n’est pas pertinent, car les poids du modèle n’ont jamais été modifiés.

Les cas plus difficiles commencent lorsque les données ont affecté les poids, les adaptateurs ou les mémoires persistantes. Il faut alors distinguer quatre situations au lieu de traiter chaque demande de suppression de la même manière.

C’est pourquoi le modèle mental du « bouton de suppression » est incorrect. Le bon modèle est celui d’une suppression délimitée accompagnée de preuves.

Un workflow pratique en sept étapes

1. Délimiter la demande et bloquer la réutilisation

Commencez par les identifiants exacts : identifiant utilisateur, hash de fichier, identifiants de documents, noms de collections vectorielles, identifiants de lots d’entraînement ou références de tickets. Bloquez ensuite toute nouvelle réutilisation. Mettez en pause l’ingestion, le réentraînement, les tâches d’export ou les synchronisations qui pourraient recréer les mêmes données pendant le nettoyage.

Si la demande est motivée par la confidentialité, gardez le cadre juridique précis. L’article 17 du RGPD crée un droit à l’effacement dans certaines circonstances, mais il ne vous indique pas quelle couche technique traiter en premier. L’avis de l’European Data Protection Board du 18 décembre 2024 sur les modèles d’AI indique également que les modèles entraînés avec des données personnelles ne peuvent pas toujours être considérés comme anonymes. Conservez un workflow de suppression explicite au lieu de supposer que le modèle est hors périmètre. EUR-Lex EDPB

2. Retracer la traçabilité avant toute suppression

Cartographiez le chemin complet :

3. Supprimer ou restreindre les artefacts sources et dérivés

Supprimez maintenant ce qui peut l’être de manière déterministe :

Un ticket public AnythingLLM a signalé que les embeddings de documents supprimés seraient restés récupérables dans une configuration reposant sur Weaviate. Un ticket constitue une preuve anecdotique, et non une conclusion valable pour toute la plateforme. Il montre néanmoins pourquoi chaque flux de suppression doit inclure un test négatif de récupération portant sur les identifiants de documents, les expressions distinctives et les paraphrases.

4. Déterminer si les poids du modèle ont réellement changé

C’est le point de bifurcation que les équipes omettent souvent.

Le challenge de Google de 2023 définit l’objectif côté modèle : le modèle ayant subi un désapprentissage doit ressembler à un modèle réentraîné sans les exemples oubliés, tout en conservant le comportement utile appris à partir du reste des données. Google Research

5. Construire les jeux d’évaluation avant de modifier les poids

Il vous faut au moins trois ensembles :

*Légende : Le travail de suppression commence par la traçabilité des données et des artefacts dérivés. Le désapprentissage du modèle ne commence qu’après avoir prouvé si les poids ont été affectés.*

6. Tester simultanément l’oubli et l’utilité conservée

Les recherches récentes rendent le compromis évident.

L’article *Behavioral Audit of Machine Unlearning Has a Privacy Cost* soutient que, pour les modèles convexes, un audit comportemental en boîte noire ne peut pas à la fois détecter un désapprentissage insuffisant et éviter de divulguer à un auditeur honnête mais curieux des informations sur l’appartenance à l’ensemble conservé. Les auteurs présentent également des preuves empiriques montrant que cette tension persiste dans des contextes non convexes. Cela signifie qu’un score d’audit unique et propre n’est pas équivalent à une preuve universelle d’un oubli sûr. arXiv

Le framework d’audit de Google Research du 10 juin 2026 aborde le problème sous un autre angle. Il propose des Regularized f-Divergence Kernel Tests afin de rendre les audits plus sensibles et de contrôler plus fiablement les faux positifs selon la taille des échantillons. Il s’agit d’un test statistique, et non d’une preuve de suppression complète. Google Research

PrivUn distingue trois niveaux de récupération : récupération directe, récupération en contexte et restauration par fine-tuning. Utilisez les niveaux qui correspondent à votre accès au modèle. Un refus sur le prompt d’origine peut réussir la première vérification alors qu’un chemin de récupération plus puissant expose encore la cible.

7. Retirer les artefacts obsolètes et conserver les preuves

Après le travail côté modèle, supprimez ou mettez en quarantaine les répliques, checkpoints, adaptateurs et caches obsolètes. Conservez ensuite un dossier de preuves comprenant :

Ces preuves transforment un workflow de suppression en un processus que le support, la sécurité, le juridique et l’ingénierie peuvent tous vérifier.

Ce que les recherches récentes sur le désapprentissage permettent réellement d’affirmer

Trois articles récents sont utiles ici, mais ils étayent des affirmations différentes.

Les audits comportementaux ne sont pas gratuits

L’article de juin 2026 sur l’audit comportemental est le principal avertissement contre les affirmations excessives. Son résultat central n’est pas que le désapprentissage est impossible. Le résultat est plus limité et plus utile : avec un propriétaire malhonnête et un auditeur honnête mais curieux, un audit comportemental peut créer un compromis entre confidentialité et audit. Si votre argumentaire de conformité repose uniquement sur des sondages en boîte noire, vous risquez de divulguer des informations sur les données conservées en essayant de vérifier l’oubli. arXiv

La modification ciblée peut fonctionner sur certains benchmarks

*ZeroUnlearn* présente un résultat plus optimiste. L’article reformule le désapprentissage machine comme un problème de modification de modèle, rapporte de solides résultats de benchmark sur Llama-3.2, Llama-3.1 et Qwen-3, et indique que sa mise à jour few-shot sous forme fermée maintient l’étape SVD sous 0,3 seconde sur MCF et ZsRE, tandis que la modification de bout en bout passe d’environ 0,04 heure pour 10 échantillons à 3,35 à 3,82 heures pour 1 000 échantillons, avec une mémoire totale d’environ 14,9 à 17,4 Go. Ces chiffres sont importants, car ils montrent que le désapprentissage approximatif n’est pas automatiquement trop coûteux à tester. arXiv

Mais les limites comptent davantage que le titre accrocheur. L’article évalue des modèles ouverts et des jeux de données de benchmark sélectionnés, tels que MCF, ZsRE et une version single-hop adaptée de MQUAKE. Il utilise également une sélection ciblée des couches afin d’éviter d’endommager les capacités générales. Il s’agit d’éléments en faveur d’une suppression prometteuse de faits à l’échelle de benchmarks, et non d’une preuve qu’un système de production a complètement effacé chaque copie d’une information sensible. arXiv

La suppression continue reste faible dans les systèmes multimodaux

*ICU-Bench* constitue le contrepoids plus préoccupant. Le benchmark contient 1 000 profils sensibles issus de rapports médicaux et de contrats de travail, 9 500 images, 16 000 paires de questions-réponses et 100 tâches séquentielles d’oubli. Sa conclusion est simple : les méthodes actuelles de désapprentissage multimodal rencontrent des difficultés dans les contextes continus et ne préservent pas simultanément la qualité de l’oubli, l’utilité des données conservées et la stabilité sur de longues séquences. Si votre produit reçoit régulièrement des demandes de suppression, c’est l’article à lire avant de promettre une automatisation propre. arXiv

Pris ensemble, ces articles soutiennent une position pratique :

Ce qu’il faut promettre aux utilisateurs et aux parties prenantes

Promettez moins. Vérifiez davantage.

Une formulation correcte ressemble à ceci :

Une mauvaise formulation ressemble à ceci :

Si vous avez besoin d’une règle courte, utilisez celle-ci : le désapprentissage machine est une couche d’un workflow plus large de suppression des données d’AI.

FAQ

La suppression d’une ligne dans une base vectorielle fait-elle oublier les données au LLM ?

Non. Elle peut empêcher un chemin de récupération de réintroduire les données, ce qui constitue souvent la bonne première correction pour les systèmes RAG. Mais si le même contenu a été utilisé pour le fine-tuning, l’entraînement continu ou la mémoire persistante du modèle, la suppression de la seule ligne vectorielle ne modifie pas les poids.

Le désapprentissage machine peut-il prouver que mes données ont disparu de toutes les copies du modèle ?

Pas à lui seul. Les recherches récentes sur l’audit montrent que les audits en boîte noire ont des limites, et les systèmes de production comprennent souvent des caches, adaptateurs, checkpoints, répliques et sauvegardes situés en dehors de la surface du modèle audité. Il faut des preuves au niveau du système, et pas seulement un score au niveau du modèle. arXiv Google Research

Vérification des affirmations

Sources