Chapitre 13.5 — Atelier : sécuriser les transferts

⏱️ TL;DR — On applique toute la partie à FormaCampus. Trois flux sortent de l’UE : l’hébergement, l’outil d’e-mailing et le modèle d’IA (un LLM américain). La démarche tient en cinq temps : cartographier les flux hors EEE → fonder chaque transfert (adéquation/DPF, CCT) → évaluer par un TIA → prendre des mesures (chiffrement, minimisation, hébergement UE quand c’est possible) → documenter. Fil rouge de la partie : le DPF est fragile (appel Latombe), donc on garde CCT + TIA en filet. À la fin, tu sais transformer une pile de services américains en une architecture conforme et démontrable.

🎯 Objectifs

• Cartographier les transferts d’un vrai projet.
• Appliquer l’arbre du chapitre V à chaque flux (adéquation → garanties → dérogation).
• Choisir les mesures supplémentaires adaptées à chaque cas.
• Documenter le tout (accountability) et savoir quand préférer une alternative UE.

La démarche en cinq temps

Étape 1 — Cartographier les flux hors EEE

On ne sécurise que ce qu’on a listé. FormaCampus recense ses briques et repère celles qui font sortir des données de l’EEE :

Résultat : trois transferts à traiter. La cartographie est la première page du dossier — et le point de départ du registre (Partie 11).

Étape 2 — Fonder chaque transfert (chapitre V)

Pour chaque flux, on cherche une base, dans l’ordre adéquation → garanties → dérogation :

• Hébergement — si le fournisseur est certifié DPF (à vérifier sur la liste), le transfert est licite au titre de l’adéquation. On conserve malgré tout des CCT en filet (le DPF est fragile).
• E-mailing — même logique : DPF si certifié, CCT signées en filet (module responsable vers sous-traitant).
• Modèle d’IA — on vérifie la certification DPF du fournisseur ; s’il n’est pas couvert, on redescend aux CCT + TIA. Dans tous les cas, ce flux mérite une attention particulière (voir étape 4).

⚠️ Piège — Traiter l’API d’IA comme un flux anodin. Envoyer à un LLM américain la copie brute d’un élève — avec nom, classe, éventuellement un aménagement de handicap (donnée de santé) — c’est un transfert de données sensibles hors EEE, souvent sans base solide et sans minimisation. C’est précisément le genre de flux « discret » qui passe sous le radar et fragilise toute la conformité.

Étape 3 — Réaliser un TIA

Depuis Schrems II, les CCT ne suffisent pas : pour chaque transfert hors adéquation (et par prudence, même sous DPF), FormaCampus rédige une analyse d’impact du transfert. Elle évalue l’exposition au droit américain (CLOUD Act, FISA), la nature des données envoyées et les recours offerts, puis conclut sur les mesures nécessaires. Le TIA est écrit — sinon il n’est pas démontrable.

Étape 4 — Prendre des mesures supplémentaires

C’est là que le dev agit concrètement :

• Chiffrement — chiffrer au repos et en transit, avec des clés conservées côté EEE quand c’est possible. Une donnée chiffrée dont l’étranger n’a pas la clé reste illisible.
• Minimisation — n’envoyer que le strict nécessaire. Pour le LLM, c’est décisif : pseudonymiser les prompts, retirer les identifiants directs, ne jamais transmettre de données sensibles brutes.
• Relocalisation — pour les flux les plus sensibles (LMS scolaire, données de santé), envisager un hébergeur européen ou SecNumCloud plutôt qu’un acteur soumis au droit extraterritorial (chapitre 13.4).

{
  "traitement": "aide et correction par IA",
  "donnees_envoyees_au_LLM": ["texte de la copie pseudonymise"],
  "donnees_exclues": ["nom", "classe", "amenagement de handicap"],
  "destination": "fournisseur LLM hors EEE",
  "base_chapitre_V": "DPF si certifie sinon CCT",
  "tia": "realise et documente",
  "mesures": ["pseudonymisation des prompts", "chiffrement en transit", "minimisation"]
}

Étape 5 — Documenter (accountability)

Rien de tout cela ne compte s’il n’est pas prouvable. FormaCampus consigne, pour chaque transfert : la base (DPF / CCT), le TIA écrit, les mesures appliquées, et la DPA signée avec le sous-traitant. Le tout entre au registre (Partie 11) et nourrit les mentions d’information (Partie 8) — la personne a le droit de savoir que ses données voyagent.

💡 Réflexe — CCT + TIA en filet, toujours. Même quand le DPF couvre un prestataire, garde les CCT signées et le TIA à jour. Le recours Latombe a été rejeté le 3 septembre 2025, mais l’appel est pendant devant la CJUE — et deux cadres américains sont déjà tombés. Si le DPF s’effondre, ton filet CCT + TIA prend le relais sans interruption. C’est la différence entre subir un revirement et l’absorber.

🧭 Sur FormaCampus — Verdict de l’atelier : les flux peu sensibles (e-mailing, back-office) restent chez des fournisseurs US certifiés DPF, encadrés par CCT + TIA + chiffrement. Les flux sensibles — le LMS scolaire (mineurs, santé) et les prompts envoyés au LLM — sont traités avec une exigence plus haute : pseudonymisation systématique, exclusion des données sensibles, et évaluation sérieuse d’une alternative européenne ou SecNumCloud pour l’hébergement. Chaque décision est écrite et justifiée.

🔒 Côté personne concernée — Un parent doit pouvoir savoir où vont les données de son enfant et quelles garanties les protègent hors EEE. Le sujet est si sensible dans l’éducation que l’Éducation nationale a écarté des offres américaines gratuites dans les écoles, faute de garanties suffisantes sur les transferts. C’est un signal clair : dans le scolaire, la souveraineté n’est pas un luxe — on y revient en Partie 15.

✏️ Exercices

Exercice 1 — La cartographie de FormaCampus. Reprends les trois flux (hébergement, e-mailing, IA) et, pour chacun, donne : la base du chapitre V envisagée, le filet, et une mesure supplémentaire prioritaire.

Exercice 2 — Le prompt dangereux. Un dev veut envoyer au LLM américain la copie complète d’un élève, avec nom, classe et la mention « bénéficie d’un tiers-temps » (aménagement de handicap). Que corriges-tu, étape par étape ?

Exercice 3 — Le DPF tombe. Scénario : la CJUE invalide le DPF sur l’appel Latombe. FormaCampus se réveille-t-elle en transfert illicite ?

🧠 Quiz de révision

Partie suivante : Partie 14 — Le RGPD dans le code — on quitte le juridique pour l’implémentation : privacy by design, patterns de code, purge automatique, gestion des consentements et des droits.