EasyScol traite des données scolaires sensibles (identité des mineurs, résultats, absences, données de santé transmises à l’infirmerie). La question n’est pas de savoir si la plateforme « respecte le RGPD » au sens marketing du terme, mais quels mécanismes techniques et organisationnels sont réellement déployés pour protéger ces informations.
Hébergement dédié en France et politique de sauvegarde d’EasyScol
Le choix d’infrastructure conditionne tout le reste. EasyScol fonctionne sur un hébergement sur serveur dédié situé en France, ce qui place les données scolaires sous juridiction française et européenne. Ce point n’est pas anodin dans un contexte où les débats parlementaires récents portent sur l’usage de prestataires extra-européens pour stocker les données d’élèves.
Un serveur dédié signifie qu’EasyScol ne mutualise pas ses ressources avec d’autres applications tierces. L’isolation réduit la surface d’attaque et simplifie le cloisonnement réseau.
Côté résilience, la plateforme applique des sauvegardes automatiques trois fois par jour. En cas d’incident (panne matérielle, ransomware, erreur humaine), la perte de données se limite à quelques heures au maximum. Ce rythme de sauvegarde dépasse ce que proposent beaucoup d’ENT mutualisés, où la fréquence reste souvent quotidienne voire hebdomadaire.
Souveraineté numérique des données d’élèves : pourquoi le sujet dépasse EasyScol
L’hébergement français d’EasyScol s’inscrit dans une logique de souveraineté numérique appliquée à l’éducation. Nous observons que ce positionnement répond à une préoccupation croissante des établissements privés qui, contrairement aux structures publiques rattachées à un ENT académique, choisissent eux-mêmes leur outil de gestion scolaire.
Le risque concret d’un hébergement hors UE tient à la possible application du Cloud Act américain ou de législations équivalentes, qui permettent à un gouvernement étranger de réquisitionner des données stockées par ses entreprises nationales, même sur des serveurs européens. En restant sur un prestataire français opérant sur le sol national, EasyScol coupe ce vecteur juridique.
Pour autant, localiser un serveur en France ne suffit pas à garantir la conformité RGPD. La chaîne de sous-traitance (infogérant, éditeur de sauvegarde, prestataire de monitoring) doit elle aussi respecter le cadre européen. Nous recommandons aux établissements de demander à EasyScol la liste de ses sous-traitants techniques, comme le prévoit l’article 28 du RGPD.
Conformité RGPD d’EasyScol : vérifications côté établissement
Un logiciel conforme ne rend pas automatiquement l’établissement conforme. Le RGPD impose au responsable de traitement (l’établissement, pas l’éditeur) de vérifier plusieurs points avant de déployer une solution comme EasyScol.
- Vérifier auprès du rectorat ou de la DSDEN que la version d’EasyScol utilisée figure dans les listes d’éditeurs validés pour le protocole d’échange avec les bases académiques.
- S’assurer que le contrat de sous-traitance (Data Processing Agreement) entre l’établissement et EasyScol précise les finalités de traitement, les durées de conservation et les mesures de sécurité techniques.
- Documenter le registre de traitement en y intégrant les flux de données transitant par EasyScol : notes, absences, cahier de texte, messagerie interne, données d’infirmerie le cas échéant.
- Informer les parents et les élèves via une mention d’information conforme, distincte du simple règlement intérieur.
L’oubli le plus fréquent concerne les durées de conservation des données scolaires. Un bulletin archivé indéfiniment dans EasyScol sans base légale constitue un manquement. L’établissement doit paramétrer ou exiger la purge automatique à l’issue du cycle scolaire ou selon les délais réglementaires fixés par le ministère.
Profils et cloisonnement des accès
EasyScol segmente les accès par profils : enseignant, CPE, parents, élèves, administrateur. Un enseignant ne voit que les classes qui lui sont affectées. Un parent n’accède qu’aux données de son enfant. Ce cloisonnement applicatif limite le risque de fuite interne.
Le profil administrateur reste le maillon critique. Nous recommandons de restreindre ce rôle à une ou deux personnes par établissement et d’activer un mot de passe renforcé, voire une authentification à deux facteurs si EasyScol la propose.
Données de santé et infirmerie dans EasyScol : un traitement à part
Le module infirmerie d’EasyScol traite des données qualifiées de « sensibles » au sens du RGPD (article 9). Allergies, traitements médicaux, passages à l’infirmerie : ces informations relèvent d’un régime juridique plus strict que les notes ou les absences.
Un établissement qui active ce module doit s’assurer que seul le personnel habilité (infirmier scolaire, direction dans certains cas) y accède. Les enseignants ne doivent pas voir les données de santé sauf protocole d’accueil individualisé (PAI) explicitement partagé.
Le chiffrement des données de santé au repos (sur le serveur) et en transit (entre le navigateur et le serveur) constitue un prérequis technique. Le protocole HTTPS couvre le transit, mais le chiffrement au repos dépend de la configuration serveur d’EasyScol. C’est une question précise à poser à l’éditeur lors de l’audit initial.
Réinitialisation quotidienne de la démo : un indicateur de maturité sécurité
Un détail révélateur figure sur la page de démonstration d’EasyScol : les données de test sont réinitialisées chaque nuit, avec des noms, prénoms et adresses entièrement fictifs. Ce fonctionnement évite qu’un visiteur puisse accéder à des données réelles via l’environnement de démonstration, un risque que certains éditeurs négligent en utilisant des copies partielles de bases de production.
Ce cloisonnement strict entre environnement de test et environnement de production est un signal positif sur la maturité sécurité de l’éditeur.
La sécurité des données scolaires ne se joue pas uniquement côté éditeur. EasyScol fournit une infrastructure solide (hébergement français, sauvegardes fréquentes, cloisonnement des profils), mais la conformité finale dépend de chaque établissement. Paramétrer les durées de conservation, restreindre les accès administrateur, auditer le traitement des données de santé : ces actions relèvent du responsable de traitement, pas du logiciel.
