Chapitre 14.5 — RGPD & IA

⏱️ TL;DR — Brancher un LLM sur des données personnelles ne suspend aucune règle du RGPD — ça en ajoute. Cinq réflexes : (1) avoir une base légale pour entraîner et pour utiliser le modèle sur des données personnelles ; (2) minimiser les prompts — n’envoyer au modèle que le strict nécessaire, en pseudonymisant avant l’envoi ; (3) traiter le fournisseur d’IA comme un sous-traitant (DPA signé, et pas d’entraînement sur tes données sans accord explicite) ; (4) prudence maximale sur les mineurs et les données sensibles ; (5) transparence — informer les personnes qu’une IA traite leurs données. Par-dessus le RGPD vient l’AI Act (Règlement (UE) 2024/1689), en vigueur depuis le 1er août 2024, d’application par paliers, qui se combine au RGPD dès qu’un système d’IA traite des données personnelles.

🎯 Objectifs

• Identifier la base légale nécessaire à l’entraînement et à l’usage d’un modèle sur des données personnelles.
• Minimiser un prompt : pseudonymiser et réduire avant d’envoyer à un LLM.
• Traiter le fournisseur de LLM comme un sous-traitant (DPA, non-entraînement).
• Redoubler de prudence sur les mineurs et les données sensibles.
• Situer l’AI Act par rapport au RGPD (combinaison, pas substitution).

Une IA ne suspend pas le RGPD, elle le complique

Le raisonnement à tenir est simple : dès qu’un système d’IA traite des données personnelles — en entrée (les prompts), en sortie (les réponses), ou à l’entraînement — c’est un traitement au sens du RGPD (chapitre 1.1), et toutes les obligations s’appliquent : base légale, finalité, minimisation, transparence, droits, sécurité, sous-traitance. L’IA n’est pas une zone de non-droit ; c’est un traitement de plus, souvent plus risqué parce qu’il est opaque et qu’il envoie des données à un tiers.

Deux traitements distincts à ne pas confondre, chacun avec sa base légale propre (art. 6) :

• Entraîner / affiner un modèle sur des données personnelles : c’est une finalité en soi. Réutiliser les données de tes utilisateurs (leurs cours, leurs copies, leurs messages) pour entraîner un modèle est un nouvel usage, qui n’est pas couvert par la base légale d’origine — il faut sa propre base et sa propre information.
• Utiliser un modèle (l’appeler à l’exécution avec des données personnelles) : c’est un autre traitement, avec sa finalité (aider l’apprenant, corriger une copie) et sa base légale.

⚠️ Piège — « On va entraîner notre IA avec les copies et les messages des élèves, on a déjà leurs données. » Non. Les données ont été collectées pour une finalité (assurer la formation) ; les réutiliser pour entraîner un modèle est une finalité incompatible sans nouvelle base légale ni information — c’est un détournement de finalité (chapitre 1.4), aggravé quand il s’agit de mineurs. Avoir la donnée ne donne pas le droit de la réemployer pour tout.

Minimiser le prompt : ne pas suralimenter le modèle

La minimisation (art. 5) s’applique mot pour mot aux prompts : on n’envoie au LLM que ce qui est strictement nécessaire à la tâche. Envoyer un dossier complet d’apprenant pour « résumer sa progression » alors que trois champs suffisent, c’est de la sur-collecte transmise à un tiers. Deux leviers :

• Réduire : ne transmettre que les champs utiles à la tâche (pas l’e-mail, pas l’adresse, pas l’historique complet si un extrait suffit).
• Pseudonymiser avant l’envoi : remplacer les identifiants directs (nom, e-mail) par des jetons neutres avant l’appel, puis restaurer les vraies valeurs dans la réponse. Le modèle fait son travail sans jamais voir qui est la personne.

// Pseudonymisation d'un prompt : le LLM ne voit JAMAIS les identités réelles.
type Mapping = Record<string, string>
 
// 1) On remplace chaque donnée directe par un jeton neutre et réversible LOCALEMENT.
function pseudonymiserPrompt(texte: string, identites: string[]): {
  prompt: string
  mapping: Mapping
} {
  const mapping: Mapping = {}
  let prompt = texte
  identites.forEach((valeur, i) => {
    const jeton = `[PERSONNE_${i + 1}]`
    mapping[jeton] = valeur
    prompt = prompt.split(valeur).join(jeton)   // "Marie Dupont" -> "[PERSONNE_1]"
  })
  return { prompt, mapping }
}
 
// 2) On restaure les vraies valeurs dans la réponse, côté serveur uniquement.
function restaurer(reponse: string, mapping: Mapping): string {
  let sortie = reponse
  for (const [jeton, valeur] of Object.entries(mapping)) {
    sortie = sortie.split(jeton).join(valeur)
  }
  return sortie
}
 
// Exemple d'usage : corriger une copie sans révéler l'identité de l'élève au modèle.
const { prompt, mapping } = pseudonymiserPrompt(
  "Corrige la copie de Marie Dupont (marie.dupont@ecole.fr) : ...",
  ["Marie Dupont", "marie.dupont@ecole.fr"],
)
// prompt envoyé : "Corrige la copie de [PERSONNE_1] ([PERSONNE_2]) : ..."
const reponseBrute = await llm.complete(prompt)   // le modèle ne voit que les jetons
const reponse = restaurer(reponseBrute, mapping)  // on remet les vraies valeurs pour l'utilisateur

Le mapping reste chez toi, en mémoire le temps de la requête ; le fournisseur ne reçoit que des jetons. Ce n’est pas magique (un contenu de copie peut lui-même contenir des informations personnelles), mais c’est une réduction d’exposition réelle et facile à mettre en place.

💡 Réflexe — Avant chaque appel LLM, pose-toi la question du chapitre 1.4 version IA : « De quoi le modèle a-t-il vraiment besoin pour cette tâche ? » La réponse est presque toujours moins que ce que le code envoie par défaut. Coupe les champs inutiles, pseudonymise les identités, tronque les historiques. Un prompt minimal est plus sûr et souvent meilleur.

Le fournisseur de LLM est un sous-traitant

Quand tu appelles une API d’IA hébergée par un tiers avec des données personnelles, ce tiers traite ces données pour ton compte : c’est un sous-traitant au sens de l’article 28 (Partie 12). Les mêmes obligations qu’avec ton hébergeur ou ton service d’e-mailing s’appliquent :

• Un contrat de sous-traitance (DPA) écrit, encadrant les finalités et les instructions.
• Le fournisseur agit sur ta seule instruction documentée — il ne réutilise pas les données pour ses propres fins.
• Pas d’entraînement sur tes données sans accord : c’est le point spécifique à l’IA. Beaucoup d’offres, par défaut ou selon le palier, peuvent réutiliser les entrées pour améliorer leurs modèles. Il faut vérifier les conditions et choisir une offre (souvent « entreprise » / « API ») qui exclut l’entraînement sur tes données, et le matérialiser dans le DPA.
• Localisation & transferts : si le fournisseur héberge hors UE, on repasse par le chapitre des transferts internationaux (Partie 13) — adéquation, clauses contractuelles types, analyse d’impact du transfert.

🧭 Sur FormaCampus — FormaCampus utilise un LLM pour deux fonctions : une aide au formateur (suggérer des corrections) et une aide à l’apprenant (expliquer une notion). Avant tout appel, les prompts sont pseudonymisés (jetons à la place des noms et e-mails) et réduits aux champs utiles. Le fournisseur est encadré par un DPA qui interdit l’entraînement sur les données de FormaCampus et précise la localisation du traitement (transfert géré comme en Partie 13 si hors UE). Et parce que le LMS concerne des élèves mineurs, l’usage de l’IA sur leurs données est restreint au minimum, avec une information claire des familles.

Mineurs et données sensibles : prudence maximale

Deux catégories imposent de relever le curseur avant toute IA :

• Mineurs (art. 8 ; 15 ans en France pour le consentement numérique) : le RGPD leur accorde une protection renforcée, et l’IA (opaque, potentiellement biaisée, difficile à expliquer) amplifie les risques. Sur des données d’enfants, la règle est la retenue : minimiser à l’extrême, éviter tout profilage, informer en langage clair et adapté, et se demander sérieusement si l’IA est nécessaire ici.
• Données sensibles (art. 9 : santé, etc.) : ne pas les envoyer à un LLM sans base solide et garanties fortes. Le plus souvent, on les exclut du prompt (elles ne sont presque jamais nécessaires à la tâche).

Ajoute la vigilance sur la décision automatisée : si une sortie d’IA produit une décision ayant un effet significatif sur une personne (orientation, refus, notation déterminante), l’article 22 encadre les décisions entièrement automatisées — prévois une intervention humaine réelle plutôt qu’une validation de façade.

🔒 Côté personne concernée — Un parent découvre que les copies de son enfant sont « corrigées par une IA ». Sa première question est légitime : où partent ces copies, qui les voit, servent-elles à entraîner un modèle ? Il a le droit de le savoir (transparence) et de s’attendre à ce que l’identité de son enfant ne soit pas exposée à un tiers, que ses données ne nourrissent pas un modèle commercial, et qu’un humain garde la main sur toute décision qui compte. Répondre clairement à ces questions, c’est la condition de la confiance.

Transparence : dire que l’IA est là

On ne peut pas traiter des données avec de l’IA en douce. La transparence (art. 13/14, Partie 8) impose d’informer les personnes qu’un traitement par IA a lieu : quelle finalité, quelles données, quel fournisseur (catégorie), quels droits. Concrètement, ça se traduit dans les mentions d’information et, souvent, par une indication au point d’usage (« cette suggestion est générée par une IA »). Cacher l’IA, c’est manquer à la loyauté (chapitre 1.4) — et l’AI Act pousse dans le même sens en matière de transparence.

L’AI Act se combine au RGPD

L’AI Act (Règlement (UE) 2024/1689) est le règlement européen sur l’intelligence artificielle. Points à connaître, sans surinterpréter :

• Il est en vigueur depuis le 1er août 2024, avec une application par paliers (échelonnée sur les années suivantes).
• Il ne remplace pas le RGPD : il s’y ajoute. Dès qu’un système d’IA traite des données personnelles, tu dois respecter les deux — le RGPD pour la protection des données, l’AI Act pour les obligations propres aux systèmes d’IA (approche par le risque, transparence, gouvernance).
• Pour un dev, la posture pratique aujourd’hui : applique le RGPD à fond (base légale, minimisation, sous-traitance, transparence, droits) — c’est déjà l’essentiel du travail — et suis la montée en charge de l’AI Act pour les obligations spécifiques selon le niveau de risque de ton système.

⚠️ Piège — Croire que « se conformer à l’AI Act » dispense du RGPD (ou l’inverse). Ce sont deux cadres cumulatifs. Une IA parfaitement documentée au titre de l’AI Act mais qui traite des données sans base légale reste non conforme au RGPD, et réciproquement. On empile, on ne substitue pas.

📚 Le texte — L’AI Act est le Règlement (UE) 2024/1689, en vigueur depuis le 1er août 2024, d’application par paliers. Il se combine au RGPD dès qu’un système d’IA traite des données personnelles. Le reste s’appuie sur des articles déjà vus : sous-traitance (art. 28, DPA, instruction documentée — Partie 12), minimisation et finalités (art. 5 — chapitre 1.4), mineurs (art. 8, 15 ans en France — Partie 5), données sensibles (art. 9), transparence (art. 13/14 — Partie 8), décision automatisée (art. 22). Pour les obligations précises et le calendrier détaillé de l’AI Act, réfère-toi aux sources officielles (le texte sur eur-lex.europa.eu, les publications de la CNIL) plutôt qu’à la mémoire.

✏️ Exercices

Exercice 1 — Minimise ce prompt. Un développeur envoie ce prompt à une API LLM externe : "Rédige un mot d'encouragement pour Marie Dupont, née le 04/03/2011, marie.dupont@ecole.fr, 12 rue des Lilas, moyenne 8/20, aménagement dyslexie, absente 3 fois." Que retires-tu, que pseudonymises-tu, et pourquoi ?

Exercice 2 — Le fournisseur de LLM. Ton équipe veut intégrer une API d’IA tierce pour aider à la correction. Liste les quatre vérifications RGPD à faire avant de brancher l’API en production.

Exercice 3 — Vrai ou faux. « L’AI Act étant entré en vigueur, il suffit de s’y conformer : le RGPD ne s’applique plus à notre chatbot qui traite des données clients. » Corrige.

🧠 Quiz de révision

Chapitre suivant : Partie 15 — RGPD dans l’enseignement & la formation — on quitte le code pur pour le terrain métier : LMS scolaires, données d’élèves mineurs, organismes de formation, Qualiopi et cas concrets du fil rouge FormaCampus.