Sécuriser les données d’élèves mineurs en EdTech

Sécuriser les données d’élèves mineurs en EdTech

Un environnement EdTech concentre des identités, des productions scolaires, des traces comportementales et parfois des données de handicap. Le compromis central est brutal : personnaliser l’apprentissage augmente la collecte et donc l’exposition. La recommandation est de minimiser les données dès l’architecture, puis de rendre les traitements résiduels auditables et révocables.

Explication de la marmotte

Un service scolaire numérique ressemble à un établissement qui conserverait les copies, les absences et les échanges entre élèves dans les mêmes armoires. Le but est de permettre l’apprentissage et le suivi, sans transformer chaque détail de la vie scolaire en information qui circule sans fin.

→ Lire l’explication complète de la marmotte

Mineurs, finalités et minimisation des données EdTech

Le Règlement général sur la protection des données (RGPD) ne crée pas une catégorie magique appelée « données d’élèves ». Il impose une finalité déterminée, une base légale, une minimisation et une durée de conservation. Avec des mineurs, le seuil de tolérance opérationnelle baisse : une collecte disproportionnée est plus difficile à justifier, et un profilage éducatif peut produire des effets durables sur une personne qui n’a pas choisi son exposition.

En France, le consentement d’un mineur pour les services de la société de l’information repose sur l’âge de 15 ans. Sous ce seuil, l’autorisation du titulaire de l’autorité parentale est requise lorsque le consentement est la base légale retenue. Ce n’est pas une invitation à coller une case à cocher parentale sur une page d’inscription et à déclarer victoire. La vérification de l’autorité parentale doit être proportionnée au risque, et la preuve du consentement doit être conservée avec sa version documentaire.

Le consentement est souvent une mauvaise base légale pour un service imposé dans un cadre scolaire. Une relation déséquilibrée rend son caractère libre contestable, tandis que son retrait doit arrêter le traitement concerné. Pour les traitements nécessaires à la mission éducative, documenter une autre base légale applicable est généralement plus cohérent. Pour les fonctions périphériques, statistiques commerciales, publicité comportementale, enrichissement par un tiers, la bonne réponse est presque toujours de ne pas les déployer. Le ciblage publicitaire d’enfants est un modèle économique, pas une nécessité pédagogique.

Chaque champ doit avoir une raison métier documentée : identifier l’élève, affecter une classe, rendre un devoir, corriger, conserver selon une obligation définie. L’adresse postale, le téléphone personnel, la géolocalisation continue, les contacts du terminal et les identifiants publicitaires ne deviennent pas légitimes parce qu’un kit logiciel les collecte par défaut. Un inventaire des traitements doit associer donnée, finalité, destinataire, durée, localisation, sous-traitant et mécanisme d’effacement.

Les données révélant le handicap, l’origine ou les difficultés sociales appellent une séparation renforcée. Les placer dans le même modèle de données que les notes et les commentaires enseignants multiplie les accès accidentels. Séparer les domaines fonctionnels, les rôles et les clés de chiffrement. La gouvernance des données commence ici, avant le troisième tableau de bord prétendument intelligent.

Identités, fédération et séparation des rôles

Un Environnement numérique de travail (ENT) ou une plateforme de gestion de l’apprentissage doit fédérer les identités avec le système d’identité de l’établissement ou de la collectivité. Créer des comptes locaux permanents pour chaque élève, parent et enseignant fabrique un cimetière d’identifiants : les départs, changements de classe et erreurs d’affectation s’y accumulent avec une régularité presque artistique.

La fédération doit transmettre des attributs minimaux. Un identifiant pseudonyme stable, le rôle, l’établissement et les groupes pédagogiques suffisent souvent. Éviter de propager nom complet, date de naissance, adresse électronique personnelle et identifiant national lorsqu’ils ne sont pas nécessaires. Un identifiant opaque ne protège pas contre tous les recoupements, mais il évite de distribuer une clé de corrélation universelle à chaque fournisseur.

L’autorisation doit être fondée sur les rôles et les relations pédagogiques effectives : un enseignant accède à ses groupes, un responsable légal aux données de l’enfant dont il a la charge, un administrateur technique aux journaux nécessaires à son exploitation. Le contrôle d’accès basé sur les rôles ne suffit pas seul : il faut aussi vérifier le périmètre, par exemple la classe et l’année scolaire. Le rôle enseignant sans relation avec une classe donne accès à une abstraction dangereuse.

Les jetons d’accès doivent être courts, signés, contrôlés côté serveur et invalidables lors d’un changement d’affectation. Un JSON Web Token (JWT) signé mais valable huit heures continue de porter des droits devenus faux après une désinscription ou une révocation. Prévoir une durée de vie de cinq à quinze minutes pour les jetons d’accès, des jetons de renouvellement rotatifs et une liste de révocation pour les événements critiques. La gestion des identités couvre les mécanismes de fédération ; le point EdTech supplémentaire est la cadence des changements de groupes, qui doit alimenter la révocation.

L’authentification multifacteur doit être imposée aux personnels d’administration, aux enseignants ayant accès à des données sensibles et aux comptes de support. Elle ne doit pas reposer sur le téléphone personnel d’un élève comme unique facteur de récupération. La récupération de compte est une authentification déguisée : si elle passe par une question triviale ou une boîte mail partagée, le reste du dispositif devient décoratif.

Chiffrement, traces et sous-traitants EdTech

Le chiffrement en transit avec Transport Layer Security (TLS) version 1.2 au minimum, idéalement version 1.3, protège le trajet réseau. Il ne protège ni le navigateur compromis, ni le poste familial infecté, ni le compte parent ouvert sur une tablette partagée. Présenter TLS comme une protection complète des mineurs relève du slogan de salon, catégorie parapluie en papier sous orage.

Les données stockées doivent être chiffrées avec Advanced Encryption Standard (AES) en mode Galois/Counter Mode (GCM), avec une clé de chiffrement de données distincte par périmètre logique. Une clé de chiffrement de clés, ou Key Encryption Key (KEK), protège ces clés de données dans un service de gestion de clés ou un Hardware Security Module (HSM). Le chiffrement par enveloppe permet de faire tourner une KEK sans rechiffrer immédiatement tous les objets, mais il ne dispense pas de conserver les anciennes clés tant que les données existent.

Une rotation de clé ne rend pas des exports historiques inexploitables si les jetons de session, les sauvegardes ou les droits d’accès restent intacts. La rotation doit inclure l’inventaire des versions de clés, la capacité de déchiffrement historique, les tests de restauration et la révocation d’accès. La cryptographie protège un volume volé, pas une application qui autorise abusivement sa consultation. Les choix de primitives et de stockage de clés relèvent de la cryptographie appliquée.

Les journaux constituent eux-mêmes un traitement de données. Ne pas journaliser les réponses libres, les pièces jointes, les mots de passe, les jetons ni les adresses complètes quand un identifiant pseudonyme suffit. Conserver l’événement, l’acteur, la ressource, le résultat, l’adresse réseau tronquée et la corrélation de requête. Appliquer une rétention courte aux traces d’usage courant, puis isoler les événements de sécurité soumis à une conservation plus longue et justifiée.

Les fournisseurs de logiciel en tant que service doivent être traités comme des sous-traitants, pas comme une extension sympathique de l’équipe produit. Le contrat doit fixer les finalités, les catégories de données, les lieux de traitement, les sous-traitants ultérieurs, les délais de notification d’incident, la restitution, l’effacement vérifiable et le droit d’audit. Une plateforme qui refuse de préciser où résident les sauvegardes n’offre pas une architecture cloud, elle offre une boîte noire avec facture mensuelle.

Exemple de contrôle d’accès par relation pédagogique

L’API doit vérifier la relation entre l’utilisateur authentifié et l’élève demandé avant de charger la ressource. Filtrer l’interface ne suffit pas : modifier un identifiant dans une requête reste l’attaque la plus rentable du catalogue.

# Exemple FastAPI reproductible : contrôle côté serveur d'un responsable légal.
# La requête SQL exige une relation active entre le parent et l'élève.
@app.get("/eleves/{eleve_id}/bulletins")
def bulletins(eleve_id: str, utilisateur=Depends(session_authentifiee)):
    if utilisateur.role != "responsable_legal":
        raise HTTPException(status_code=403, detail="role refuse")

    relation = db.execute(
        """
        SELECT 1
        FROM autorites_parentales
        WHERE parent_id = :parent_id
          AND eleve_id = :eleve_id
          AND active = TRUE
        """,
        {"parent_id": utilisateur.id, "eleve_id": eleve_id},
    ).fetchone()

    if relation is None:
        raise HTTPException(status_code=403, detail="relation absente")

    return charger_bulletins(eleve_id)  # Ne jamais accepter un eleve_id sans ce test.

Tester quatre cas : parent lié, parent non lié, relation révoquée et compte de support. Ajouter un test d’autorisation à chaque nouvelle route exposant un objet élève. Les contrôles centralisés réduisent les oublis, mais un endpoint interne non couvert redevient vite une porte latérale très officielle.

Exploitation, incidents et reprise des services scolaires

La disponibilité compte : une indisponibilité le jour d’une évaluation dégrade le service. Elle ne justifie pas une réplication incontrôlée des données dans dix services annexes. Préférer une architecture avec séparation entre données pédagogiques, identité, fichiers et télémetrie, puis définir les objectifs de point de reprise et de délai de reprise pour chaque domaine.

Les sauvegardes doivent être chiffrées, inventoriées, isolées des privilèges d’administration quotidiens et restaurées régulièrement dans un environnement séparé. Une sauvegarde jamais restaurée n’est pas une sauvegarde, c’est une croyance avec extension .bak. Vérifier après restauration les clés disponibles, les dépendances d’identité, les règles d’accès et l’absence de comptes supprimés réintroduits par erreur.

Un incident impliquant des données de mineurs exige d’abord de contenir : révoquer sessions et jetons, suspendre les clés ou comptes compromis, préserver les journaux, mesurer les catégories touchées et identifier les destinataires possibles. L’analyse d’impact sur la protection des données, ou AIPD, doit déjà avoir décrit les scénarios de compromission et les mesures prévues. La notification réglementaire relève du responsable de traitement et de son délégué à la protection des données ; l’architecture doit fournir les preuves, pas improviser une chronologie à partir de journaux incomplets.

La supervision doit alerter sur les exportations massives, les consultations hors périmètre, les échecs d’authentification, les changements de rôles et les appels inhabituels aux interfaces de programmation applicative. Une alerte sans procédure de qualification devient un carillon numérique : elle sonne, elle rassure vaguement, puis personne ne sait pourquoi.

🐝 Ce qui arrive si on s’en passe

Sans clé de données distincte par périmètre logique, l’effacement en fin de conservation ne peut pas s’appuyer sur la destruction d’une clé : chaque copie (base, réplique, sauvegarde, export) doit être retrouvée et supprimée une à une, et toute copie oubliée reste lisible après le départ de l’élève. Sans journal liant acteur, ressource et résultat, un incident ne peut pas être circonscrit aux élèves réellement consultés. Le périmètre d’impact s’étend alors par défaut à toute la population hébergée, et la notification comme l’information des familles portent sur des personnes non concernées. Enfin, un identifiant national propagé à chaque fournisseur permet de relier des traces scolaires provenant de services distincts, ce qu’aucune révocation ultérieure ne peut défaire une fois les copies faites.

🦫 Explication de la marmotte 🍫

Un service scolaire numérique doit d’abord décider quelles informations sont nécessaires pour chaque action : suivre une classe, remettre un devoir, corriger ou informer un responsable légal. Il ne doit pas demander des informations supplémentaires juste parce qu’elles sont disponibles. Les données sur le handicap ou les difficultés personnelles sont séparées des données scolaires ordinaires.

Chaque personne reçoit un compte lié à son rôle. Un élève voit ses propres travaux. Un enseignant voit seulement les groupes dont il est chargé. Un responsable légal voit seulement les informations de l’enfant qui lui est rattaché. Avant d’afficher une information, le serveur vérifie cette relation. Masquer un bouton sur une page ne suffit pas, car une personne malveillante peut tenter d’appeler directement le serveur.

Les échanges entre l’appareil et le service sont chiffrés. Les données conservées sont aussi chiffrées, avec des clés gardées séparément. Les clés sont remplacées selon un calendrier, mais les anciennes restent disponibles tant que les anciennes données doivent être lues. Les journaux gardent la trace des accès sans recopier les contenus sensibles.

En cas de départ d’un élève, de changement de classe ou de compte compromis, les accès doivent disparaître rapidement. En cas d’incident, il faut couper les accès concernés, conserver les preuves et déterminer quelles données ont été vues. Des copies de secours permettent de restaurer le service, mais elles doivent être protégées et testées, sinon elles peuvent remettre en circulation des accès supprimés.

À lire aussi

• Sécuriser la télémétrie et les données d’usage produitConcevoir une collecte de télémétrie produit minimisée, consentie, protégée et supprimée selon une durée de rétention vérifiable.
• RGPD : exigences d’architecture et contrôles techniquesLe RGPD impose des choix d’architecture sur les données, les identités, la sécurité, la rétention et la capacité à démontrer les contrôles appliqués.
• Sécuriser l'accès des flottes de véhicules connectésSécuriser les systèmes de contrôle d'accès des véhicules connectés et des flottes face aux attaques par diagnostic et connectivité cellulaire.
• Comment sécuriser les jetons stockés sur mobilePourquoi le chiffrement de partition ne protège pas suffisamment les jetons et caches sensibles sur un appareil mobile, et comment exploiter Keychain iOS et Keystore Android.

Pages voisines

La citent

• DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir

Sécuriser les données d’élèves mineurs en EdTech

Elle cite

• ⇄Lien dans les deux sens :Pourquoi le RGPD produit des rituels de consentement
• La récupération de compte, maillon faible
• ReBAC Zanzibar pour les autorisations relationnelles fines

⇄ : les deux pages se citent l’une l’autre.