Consentement, limitation des finalités et le piège de la fonctionnalité IA

Fin 2023, Zoom a discrètement modifié ses conditions d'utilisation pour laisser entendre que les contenus clients pourraient servir à entraîner des modèles d'IA, avant de faire marche arrière en quelques jours face à une levée de boucliers des utilisateurs. L'épisode est devenu un cas d'école : une entreprise SaaS assise sur une montagne de données clients, une nouvelle fonctionnalité IA à construire, et aucune voie juridique propre pour utiliser l'une au service de l'autre. Cet écart entre « nous avons les données » et « nous pouvons utiliser les données » est l'endroit précis où la plupart des projets de copilote IA enfreignent la loi sans bruit.

Le piège, défini

Les tickets de support, les logs de chat et les données d'usage sont généralement collectés pour une finalité : faire tourner le produit et aider le client. C'est la base légale que vous avez annoncée aux utilisateurs à leur inscription.

Entraîner un copilote IA est une autre finalité. Sous le RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → (Règlement général sur la protection des données, le texte de référence européen en matière de vie privée), cela déclenche la limitation des finalités, principe selon lequel des données personnelles collectées pour une finalité déterminée ne peuvent être réutilisées pour une nouvelle finalité incompatible sans une nouvelle base légale (voir RGPD Article 5(1)(b)).

Les tickets de support sont particulièrement risqués car ils contiennent souvent :

• Des noms, emails, détails de compte (données personnelles par défaut)
• Des captures d'écran ou logs collés avec des secrets clients, des clés APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → ou des PII (informations personnelles identifiables) d'utilisateurs finaux
• Des réclamations sensibles (santé, finances, RH) si votre SaaS sert ces verticales

Injecter ce corpus dans un fine-tuningfine-tuningLe fine-tuning adapte un modèle pré-entraîné à une tâche ou un domaine précis en poursuivant son entraînement sur un jeu de données plus petit et ciblé, ce qui améliore la précision et le style pour ce cas d'usage.Voir la définition complète → de grand modèle de langage (LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète →), ou même l'utiliser pour du retrieval-augmented generationretrieval-augmented generationMéthode qui permet à un modèle d'IA de répondre à partir de vos propres documents, en récupérant les passages pertinents avant de générer une réponse.Voir la définition complète → (RAG, où un modèle va chercher en direct des extraits dans une base pour répondre aux questions), constitue une nouvelle finalité de traitement. Si votre notice de confidentialité initiale disait « pour fournir le support client », vous n'avez probablement pas de base légale pour ajouter « pour entraîner nos fonctionnalités IA ».

Pourquoi ce n'est pas seulement un problème européen

Les entreprises américaines supposent souvent qu'il s'agit d'un casse-tête strictement européen. Ce n'est pas le cas.

• La FTC (Federal Trade Commission) a explicitement mis en garde les entreprises contre la modification « silencieuse » des conditions d'utilisation pour autoriser l'entraînement d'IA sur des données déjà collectées, y voyant une pratique potentiellement déloyale ou trompeuse au titre de la Section 5 du FTC Act. Son billet de blog de 2024 sur le sujet est une bonne introduction : FTC: AI (In)security.
• Le CCPA/CPRA californien (California Consumer Privacy Act, amendé par le California Privacy Rights Act) donne aux utilisateurs un droit de limiter l'usage des informations personnelles sensibles et exige la divulgation des nouvelles finalités de traitement.
• Les règles sectorielles s'empilent par-dessus : HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation. (données de santé, États-Unis) et GLBA (données financières, États-Unis) restreignent l'usage secondaire, IA ou pas.

Le fil rouge commun à l'UE, aux États-Unis et à la plupart des autres cadres : le problème n'est pas l'IA en soi, c'est la réaffectation silencieuse de données collectées sous une promesse plus étroite.

Ce que la « limitation des finalités » exige réellement

Deux voies légales existent quand vous voulez réutiliser des données pour une nouvelle finalité :

1. Test de compatibilité : certains régulateurs (notamment au titre de l'article 6(4) du RGPD) autorisent la réutilisation si la nouvelle finalité est « compatible » avec l'originale, en pesant des facteurs comme le contexte, les attentes raisonnables des utilisateurs et les garanties appliquées. Entraîner une IA sur des catégories de tickets agrégées et anonymisées pour améliorer le routage peut passer. Entraîner un copilote génératif susceptible de restituer le texte exact de la réclamation d'un utilisateur à un autre client, presque certainement pas.
2. Nouveau consentement ou nouvelle base légale : si ce n'est pas compatible, il vous faut une nouvelle base légale, le plus souvent un consentement renouvelé, spécifique et informé, ou une analyse d'intérêt légitime (LIA) documentée et défendable.

L'anonymisation compte ici, mais on en surestime souvent la portée. Une véritable anonymisation (irrirrLe taux de rendement interne est le taux d'actualisation qui annule la valeur actuelle nette d'un projet. Il exprime le rendement annualisé attendu d'un investissement.Voir la définition complète →éversible, sans ré-identification possible) fait sortir totalement du champ du RGPD. La pseudonymisation (remplacement des identifiants par des tokenstokensUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète →), non : une donnée pseudonymisée reste une donnée personnelle en droit européen si la ré-identification est faisable.

Construire le workflow de re-permissioning

Quand le produit veut lancer une fonctionnalité IA au-dessus de données existantes, déroulez cette séquence avant le moindre job d'entraînement.

Étape 1 : cartographie des données. Identifiez chaque jeu de données que la fonctionnalité va toucher (tickets, transcriptions de chat, logs d'usage) et sa finalité déclarée d'origine. Des outils comme un inventaire de données ou un registre des activités de traitement (RoPA, journal imposé par le RGPD de ce que vous traitez et pourquoi) rendent cela traçable.

Étape 2 : évaluation de compatibilité. Documentez, par écrit, si le cas d'usage IA est compatible avec la finalité d'origine. L'Information Commissioner's Office (ICO) britannique publie une checklist de compatibilité pratique qui vaut d'être adaptée : Guide de l'ICO sur la limitation des finalités.

Étape 3 : choisir la base légale.

• Compatible et à faible risque (ex. analytics agrégés) → avancez avec une analyse d'impact (DPIA) si le risque n'est pas négligeable.
• Incompatible ou à haut risque (ex. texte brut des tickets dans un LLM) → déclenchez le re-permissioning.

Étape 4 : campagne de re-permissioning. C'est le cœur opérationnel :

• Mettez à jour la notice de confidentialité avec une description en langage clair du cas d'usage IA.
• Présentez un opt-in explicite et granulaire (pas une case groupée « j'accepte les conditions mises à jour »). Les régulateurs rejettent de plus en plus le consentement groupé comme n'étant pas « librement donné ».
• Offrez un véritable opt-out qui ne dégrade pas les fonctions cœur du produit, le RGPD exigeant qu'un consentement soit aussi facile à retirer qu'à donner.
• Journalisez le consentement avec horodatage, version de la notice affichée et mécanisme utilisé, et conservez ce journal à des fins d'audit.

Étape 5 : application technique. Les décisions de consentement doivent réellement atteindre le pipeline de données. Échec classique : le juridique valide un flux d'opt-in, mais l'engineering entraîne sur toute la table des tickets malgré tout, parce qu'aucun flag n'est propagé en aval.

Un correctif de schéma minimal ressemble à ceci :

-- la table ticket gagne un flag de consentement sur lequel les jobs ETL/entraînement doivent filtrer
ALTER TABLE support_tickets
ADD COLUMN ai_training_consent BOOLEAN DEFAULT FALSE;

-- la requête d'extraction pour l'entraînement respecte le flag
SELECT ticket_id, body_text
FROM support_tickets
WHERE ai_training_consent = TRUE
  AND anonymization_status = 'completed';

Sans ce type de filtre imposé, le consentement est une fiction juridique : il existe dans un document de politique, pas dans le pipeline.

Les audits à mener avant et après le lancement

• DPIA pré-lancement : obligatoire sous RGPD quand le traitement est « susceptible d'engendrer un risque élevé », ce qui est typiquement le cas de l'entraînement de modèles génératifs sur des contenus utilisateurs.
• Contrôle de minimisation : le modèle a-t-il besoin du texte brut des tickets, ou des résumés / champs structurés suffiraient-ils ?
• Test de fuite : promptez le modèle entraîné pour voir s'il reproduit mot pour mot du texte client (risque connu de mémorisation des LLM).
• Audit de couverture du consentement : vérification trimestrielle que le pourcentage de données d'entraînement couvertes par un consentement valide et à jour correspond à ce que la conformité croit être le cas.
• Répercussion sur les fournisseurs : si un vendor IA tiers (OpenAI, Anthropic, Google) traite les données, vérifiez que votre accord de traitement (DPA) interdit explicitement l'entraînement de leurs propres modèles sur les données de vos clients.

La tension business, dite franchement

Le re-permissioning est de la friction, et la friction réduit le volume de données d'entraînement. Les équipes produit poussent souvent en sens inverse : « Si on redemande, l'adoption chute et le copilote est moins bon. » Ce compromis est réel, mais l'alternative est une exposition réglementaire. Clearview AI, Meta et Clarivate ont tous fait l'objet d'actions réglementaires ou d'amendes importantes liées à la réaffectation de données personnelles sans base suffisante ; les montants et les décisions varient selon la juridiction et le dossier, mais le schéma est suffisamment constant pour être pris au sérieux.

Le meilleur cadrage pour les équipes produit : intégrez le re-permissioning à l'annonce de la fonctionnalité elle-même. « Nous lançons un assistant IA entraîné sur les motifs de support. Voici exactement ce qu'il utilise, voici votre contrôle » transforme une obligation de conformité en signal de confiance, lequel est en soi un levier de rétention dans les deals SaaS entreprise, où les équipes achats interrogent désormais systématiquement la provenance des données d'entraînement IA.

🎬 [VIDEO: « GDPR and AI: Purpose Limitation Explained » - youtube.com - cherchez les explainers de l'IAPP (International Association of Privacy Professionals) ou de la chaîne de l'ICO sur la limitation des finalités et les données d'entraînement IA, utiles pour un parcours visuel du test de compatibilité]

Points clés

• La limitation des finalités (RGPD article 5(1)(b)) signifie que des données collectées pour le support ne peuvent pas être automatiquement réutilisées pour entraîner des fonctionnalités IA ; c'est un terrain d'enforcement actif dans l'UE et de plus en plus à la FTC et sous CCPA/CPRA aux États-Unis.
• L'anonymisation ne supprime le problème juridique que si elle est irréversible ; une donnée pseudonymisée reste une donnée personnelle régulée.
• Un vrai workflow de re-permissioning tient en cinq étapes : cartographie des données, évaluation de compatibilité, choix d'une base légale, campagne d'opt-in explicite, et application des flags de consentement dans le pipeline de données réel, pas seulement dans les documents de politique.
• Menez une DPIA avant l'entraînement, testez la mémorisation mot pour mot après, et auditez la couverture du consentement chaque trimestre.
• Traitez le re-permissioning comme un actif de confiance et de vente, pas seulement comme un coût juridique, en particulier en SaaS entreprise où les acheteurs scrutent désormais la provenance des données d'entraînement IA pendant l'achat.