SCOOL
DOCUMENT INTERNE – NON DESTINÉ À LA PUBLICATION
Version : août 2026
Le présent document constitue la base du dispositif interne de conformité à la protection des données personnelles de :
Il comprend notamment :
le registre des activités de traitement ;
l’identification des responsabilités ;
les règles internes d’accès aux données ;
la gestion des demandes RGPD ;
la procédure de gestion des violations de données ;
le registre des violations ;
la gestion des prestataires ;
les transferts internationaux ;
les règles de conservation ;
les mesures de sécurité ;
les procédures concernant les mineurs.
Ce document doit être tenu à jour en fonction du fonctionnement réel de SCOOL.
Adresse : [ADRESSE IFZA À COMPLÉTER]
Site : scoolhub.com
Contact général : contact@scoolhub.com
Contact protection des données : privacy@scoolhub.com
Contact sécurité : safety@scoolhub.com
Représentant dans l’Union européenne lorsqu’applicable : [À COMPLÉTER]
DPO, lorsqu’un DPO est désigné : [À COMPLÉTER]
Personne responsable de la tenue et de l’actualisation du registre :
Cette personne est notamment chargée de :
maintenir le registre à jour ;
identifier les nouveaux traitements ;
contrôler les durées de conservation ;
centraliser les demandes RGPD ;
assurer la traçabilité des incidents ;
suivre les prestataires ;
conserver les documents de conformité.
Le registre doit être revu :
lors de l’ajout d’une nouvelle fonctionnalité ;
lors du changement d’un prestataire ;
lors de l’utilisation d’un nouveau type de donnée ;
lors d’un changement de finalité ;
lors d’un transfert vers un nouveau pays ;
lorsqu’un incident révèle une nouvelle utilisation des données ;
au minimum périodiquement afin de vérifier sa conformité avec la réalité.
Traitement n°1
Nom : Création et gestion des comptes clients, parents et élèves
Personnes concernées :
parents ;
représentants légaux ;
élèves ;
enfants mineurs.
Données concernées :
nom ;
prénom ;
e-mail ;
téléphone ;
pays ;
langue ;
identifiant ;
données de connexion ;
informations relatives au compte familial ;
niveau scolaire ;
matières ;
âge ou date de naissance lorsque nécessaire.
Finalités :
créer le compte ;
permettre l’authentification ;
gérer les utilisateurs ;
permettre l’accès aux services ;
gérer les comptes familiaux.
Base juridique : Exécution du contrat et, selon certaines opérations : obligation légale ou intérêt légitime.
Destinataires : personnel autorisé SCOOL ; prestataires techniques strictement nécessaires.
Durée : Pendant la relation contractuelle puis selon le calendrier de conservation applicable.
Transfert hors EEE : Possible – à documenter.
Traitement n°2
Nom : Gestion pédagogique et protection des élèves mineurs
Données :
identité ;
âge ;
niveau scolaire ;
matières ;
planning ;
enseignants réservés ;
historique des cours ;
informations nécessaires à la sécurité.
Finalités :
organiser les cours ;
adapter les prestations ;
protéger l’enfant ;
permettre la supervision parentale ;
traiter les signalements.
Les mineurs constituent une catégorie de personnes nécessitant une vigilance renforcée.
Mesures :
accès limité ;
compte parental lorsque nécessaire ;
politique spécifique de protection des mineurs ;
mécanisme de signalement ;
limitation des données communiquées aux enseignants ;
restriction de l’utilisation marketing.
Traitement n°3
Nom : Inscription, vérification et gestion des enseignants
Données :
identité ;
coordonnées ;
photographie ;
diplômes ;
CV ;
expérience ;
pays ;
langues ;
matières ;
documents de vérification ;
coordonnées nécessaires à la rémunération.
Finalités :
examiner les candidatures ;
vérifier les profils ;
permettre l’activité sur SCOOL ;
organiser les cours ;
effectuer les paiements ;
prévenir les fraudes.
Base juridique : Selon le traitement : exécution du contrat ; intérêt légitime ; obligation légale.
Accès : Uniquement aux administrateurs autorisés.
Traitement n°4
Données :
identité de l’élève ;
enseignant ;
matière ;
date ;
horaire ;
statut du cours ;
annulation ;
présence ;
crédits utilisés.
Finalité : gestion des réservations ; exécution des prestations ; gestion des annulations ; gestion des litiges.
Base juridique : Exécution du contrat.
Traitement n°5
Données :
compte parent ;
enfants rattachés ;
crédits achetés ;
solde ;
date d’achat ;
date d’expiration ;
débits ;
recrédits ;
historique.
Finalités :
gérer le Portefeuille Famille ;
permettre le paiement des cours ;
gérer l’expiration des crédits ;
traiter les contestations.
Durée de validité commerciale : 1 mois pour les crédits.
La durée de conservation des informations comptables peut être plus longue lorsqu’une obligation légale le nécessite.
Traitement n°6
Nom : Traitement et sécurisation des paiements
Prestataire : STRIPE
Données susceptibles d’être concernées :
identité du client ;
e-mail ;
montant ;
devise ;
référence de transaction ;
date ;
statut ;
informations relatives aux remboursements ;
contestations ;
signaux techniques antifraude.
Données que SCOOL ne doit pas stocker directement :
numéro complet de carte ;
CVC/CVV.
Finalités :
exécuter le paiement ;
confirmer la transaction ;
gérer les remboursements ;
prévenir la fraude ;
gérer les chargebacks ;
assurer la comptabilité.
Rôle de Stripe :
sous-traitant ;
responsable de traitement indépendant.
Le rôle de Stripe doit être déterminé selon le traitement concerné.
Documentation à conserver :
contrat Stripe ;
Data Processing Agreement applicable ;
documentation des transferts internationaux ;
description de l’intégration technique.
Traitement n°7
Données :
identité ;
e-mail ;
contenu de la demande ;
réservation ;
transaction ;
historique nécessaire au traitement.
Finalité : assistance ; résolution des problèmes ; gestion des réclamations.
Accès : Uniquement aux personnes chargées du support.
Traitement n°8
Données :
identité du signalant ;
identité de la personne signalée ;
messages ;
historique pertinent ;
preuves transmises ;
décision ;
recours.
Finalité : protéger les utilisateurs ; traiter les contenus ou comportements interdits ; protéger les mineurs ; défendre les droits de SCOOL ; coopérer avec les autorités lorsque nécessaire.
Niveau de confidentialité : ÉLEVÉ
Traitement n°9
Données :
nom ;
prénom ;
e-mail ;
historique du consentement ;
désinscription.
Finalités : newsletters ; offres commerciales ; actualités SCOOL.
Base juridique : Consentement lorsqu’il est requis.
Règle : Aucune case marketing ne doit être pré-cochée lorsque le consentement est nécessaire.
Le retrait doit pouvoir être effectué facilement.
Traitement n°10
Les outils réellement utilisés doivent être recensés.
Pour chaque outil, SCOOL doit documenter :
fournisseur ;
finalité ;
données ;
durée ;
consentement ou exemption ;
transfert international éventuel.
Aucun outil marketing ou statistique ne doit être ajouté au registre s’il n’est pas réellement installé.
SCOOL doit tenir la liste actualisée des prestataires ayant accès à des données personnelles.
Le tableau interne doit comprendre au minimum :
Les développeurs ou sociétés chargées de la maintenance ne doivent pas disposer d’un accès permanent et illimité aux données de production sans justification.
SCOOL doit appliquer :
• comptes individuels ;
• droits limités ;
• suppression des accès inutiles ;
• authentification renforcée ;
• journalisation lorsque possible ;
• contrat de confidentialité ;
• accord de traitement des données lorsque nécessaire.
17. ACCÈS ADMINISTRATEURS
Chaque administrateur reçoit uniquement les autorisations nécessaires à sa fonction.
Exemple : Administrateur validation enseignants
Peut accéder : profil enseignant ; justificatifs nécessaires ; statut de validation.
Ne doit pas automatiquement accéder : comptes Stripe ; chiffre d’affaires global ; données bancaires ; administration complète ; toutes les données clients.
Les accès doivent respecter le principe : BESOIN D’EN CONNAÎTRE.
Une personne ne doit pas accéder à une donnée uniquement parce que son compte technique lui permet de le faire.
19. COMPTES ADMINISTRATEURS
Les comptes sensibles doivent être individuels.
Il faut éviter : admin@scool.com / mot de passe partagé entre 5 personnes.
Chaque utilisateur administratif doit disposer de son propre compte lorsque cela est techniquement possible.
20. AUTHENTIFICATION FORTE
SCOOL doit mettre en place une authentification renforcée lorsqu’elle est disponible, notamment pour : Stripe ; hébergement ; base de données ; compte administrateur principal ; messagerie professionnelle ; outils développeurs.
Les clés Stripe doivent être traitées comme des secrets techniques.
Les clés secrètes : ne doivent jamais apparaître publiquement dans le code côté navigateur ; ne doivent pas être envoyées par messagerie non sécurisée ; ne doivent pas être communiquées aux enseignants ; doivent être limitées aux personnes et systèmes nécessaires.
Les demandes peuvent notamment concerner : accès ; rectification ; effacement ; limitation ; opposition ; portabilité ; retrait du consentement.
Adresse centrale : privacy@scoolhub.com
Chaque demande doit être enregistrée.
Référence : ____________________
Date de réception : ____________________
Identité : ____________________
Type de demande : ____________________
Vérification d’identité nécessaire : Oui / Non
Date limite de réponse : ____________________
Personne responsable : ____________________
Réponse envoyée le : ____________________
Décision : ____________________
SCOOL doit répondre aux demandes dans le délai applicable prévu par le RGPD.
Le délai de principe est un mois à compter de la réception de la demande, avec possibilité de prolongation dans certaines situations complexes ou en raison du nombre de demandes, à condition d’en informer la personne conformément au RGPD.
SCOOL ne doit pas envoyer les données d’un utilisateur à une personne qui n’est pas autorisée à les recevoir.
En cas de doute raisonnable concernant l’identité du demandeur, SCOOL peut demander les informations supplémentaires nécessaires à sa vérification.
Aucun document d’identité ne doit être demandé systématiquement lorsque cela n’est pas nécessaire.
Lorsqu’une demande concerne les données d’un enfant, SCOOL doit vérifier : l’identité du demandeur ; sa qualité de représentant légal lorsque nécessaire ; l’âge et les droits propres du mineur ; la législation applicable.
La transmission de toutes les données d’un enfant à un parent ne doit pas être considérée comme automatiquement légitime dans toutes les circonstances.
27. SUPPRESSION
Avant d’effacer des données, SCOOL vérifie si leur conservation est encore nécessaire pour : obligation légale ; comptabilité ; fiscalité ; prévention de fraude ; litige ; exercice ou défense de droits.
Le droit à l’effacement n’est pas un droit absolu.
28. PORTABILITÉ
Lorsqu’elle s’applique, la portabilité doit porter sur les données concernées par ce droit et non automatiquement sur l’intégralité des informations détenues par SCOOL.
Une violation de données personnelles peut notamment résulter : d’une perte ; d’un vol ; d’une destruction ; d’une altération ; d’un accès non autorisé ; d’une divulgation non autorisée ; d’une indisponibilité importante affectant des données personnelles.
Le RGPD couvre donc les atteintes à la confidentialité, l’intégrité et la disponibilité des données.
Constituent notamment des situations devant être analysées : piratage d’un compte administrateur ; fuite de la base des élèves ; accès non autorisé aux documents enseignants ; envoi d’un fichier à la mauvaise famille ; vol d’un ordinateur contenant des données non protégées ; accès non autorisé d’un développeur ; exposition publique d’une base de données ; compromission de privacy@scoolhub.com ; compromission des clés API ; export frauduleux du fichier clients ; perte d’enregistrements impliquant des mineurs.
Toute personne découvrant un incident doit immédiatement :
1. SÉCURISER – Limiter l’incident.
2. SIGNALER – Informer la personne responsable de la sécurité/RGPD.
3. CONSERVER – Préserver les éléments nécessaires à l’analyse.
4. DOCUMENTER – Noter la date et l’heure de découverte.
Aucun salarié, administrateur, développeur ou prestataire ne doit dissimuler une violation afin d’éviter : une mauvaise image ; une notification ; une responsabilité ; une sanction interne.
La rapidité de la remontée d’information est essentielle pour respecter les délais réglementaires.
Lorsqu’une violation doit être notifiée à l’autorité compétente, le RGPD prévoit une notification sans délai indu et, si possible, dans les 72 heures après que le responsable du traitement en a pris connaissance.
Le délai ne doit donc pas être calculé simplement à partir de la date technique à laquelle l’attaque aurait commencé si SCOOL n’en avait pas encore connaissance.
Après découverte, SCOOL évalue notamment : nature des données ; nombre de personnes ; présence de mineurs ; caractère sensible des informations ; possibilité d’identifier les personnes ; conséquences financières ; risques de fraude ; risques de harcèlement ; risques de vol d’identité ; risques physiques ou psychologiques ; mesures de sécurité déjà présentes.
35. CLASSIFICATION
Niveau 1 – Risque improbable : Incident documenté dans le registre interne. Notification à l’autorité normalement non nécessaire lorsque la violation est peu susceptible d’engendrer un risque pour les droits et libertés.
Niveau 2 – Risque : Notification à l’autorité compétente requise dans les conditions du RGPD.
Niveau 3 – Risque élevé : Notification à l’autorité + information des personnes concernées lorsque les conditions de l’article 34 sont réunies et qu’aucune exception ne s’applique.
Une violation concernant des données d’enfants doit être évaluée avec une prudence renforcée.
Exemple : Une fuite contenant nom d’enfant ; école ; âge ; coordonnées ; professeur ; horaires de cours, peut présenter des conséquences sensiblement différentes d’une simple fuite d’un identifiant technique.
Lorsque la notification est requise, SCOOL doit notamment fournir les informations prescrites par le RGPD concernant : nature de la violation ; catégories de personnes ; catégories de données ; nombre approximatif de personnes ; conséquences probables ; mesures prises ou envisagées.
Si toutes les informations ne sont pas immédiatement disponibles, elles peuvent être fournies progressivement dans les conditions prévues par le RGPD.
38. AUTORITÉ COMPÉTENTE
L’autorité compétente doit être déterminée en fonction de la situation juridique de SCOOL et des traitements concernés.
SCOOL ne doit pas supposer automatiquement que toutes les violations doivent être notifiées à la CNIL uniquement parce qu’un utilisateur est français.
Le mécanisme de compétence doit être vérifié en fonction du RGPD, du représentant européen et de l’organisation réelle des traitements.
Lorsqu’une violation est susceptible d’engendrer un risque élevé et que l’information est juridiquement requise, SCOOL informe les personnes concernées de manière : claire ; compréhensible ; suffisamment précise.
L’information doit notamment permettre à la personne de comprendre : ce qui s’est passé ; quelles données sont concernées ; les risques ; les mesures prises ; les actions qu’elle peut elle-même entreprendre.
Objet : Information importante concernant la sécurité de vos données SCOOL
SCOOL a identifié le [DATE] un incident de sécurité susceptible d’avoir affecté certaines données personnelles.
Données potentiellement concernées : [À PRÉCISER]
Nature de l’incident : [DESCRIPTION CLAIRE]
Mesures prises par SCOOL : [MESURES]
Ce que nous vous recommandons : [CHANGEMENT DE MOT DE PASSE / VIGILANCE / AUTRE]
Pour toute question : privacy@scoolhub.com
SCOOL tient un registre de toutes les violations de données, y compris celles qui ne sont pas notifiées à une autorité.
La CNIL rappelle que toutes les violations doivent être documentées en interne.
Référence incident : ____________________
Date et heure de l’incident : ____________________
Date et heure de découverte : ____________________
Personne ayant découvert l’incident : ____________________
Nature de l’incident : ____________________
Données concernées : ____________________
Nombre estimé de personnes : ____________________
Mineurs concernés : Oui / Non
Risque évalué : Faible / Risque / Risque élevé
Mesures immédiates : ____________________
Notification autorité : Oui / Non
Date de notification : ____________________
Information des personnes : Oui / Non
Mesures correctrices : ____________________
Date de clôture : ____________________
Lorsqu’un sous-traitant découvre une violation portant sur des données qu’il traite pour SCOOL, le contrat doit prévoir une information de SCOOL sans délai indu.
SCOOL doit pouvoir recevoir suffisamment rapidement l’information pour respecter ses propres obligations de notification.
Un incident Stripe ne signifie pas automatiquement qu’il existe une violation de données relevant de la responsabilité de SCOOL.
SCOOL doit déterminer : quelles données sont concernées ; le rôle de Stripe pour le traitement ; si les données SCOOL sont affectées ; quelles obligations contractuelles ou réglementaires s’appliquent.
Si l’hébergeur informe SCOOL d’une compromission :
1. enregistrer immédiatement l’heure de notification ;
2. demander les données concernées ;
3. identifier les comptes touchés ;
4. évaluer le risque ;
5. appliquer la procédure de violation.
Toute compromission d’un ordinateur ou compte développeur ayant accès à SCOOL doit être signalée à SCOOL immédiatement.
Les accès concernés doivent être : suspendus ; réinitialisés ; vérifiés.
Les clés et mots de passe potentiellement compromis doivent être renouvelés.
SCOOL doit établir un tableau interne précisant pour chaque catégorie : finalité ; durée active ; durée d’archivage ; justification ; mode de suppression.
Aucune durée ne doit être choisie arbitrairement.
48. SUPPRESSION TECHNIQUE
La suppression d’une donnée doit être effective dans les systèmes actifs lorsque son effacement est requis.
SCOOL doit également déterminer le traitement des sauvegardes.
Une donnée supprimée ne doit pas continuer à rester librement accessible à tous les administrateurs dans une archive oubliée.
49. SAUVEGARDES
Les sauvegardes doivent être : protégées ; limitées ; testées ; séparées lorsque nécessaire ; soumises à une politique de conservation.
Les développeurs doivent éviter d’utiliser des données réelles de mineurs ou de clients dans les environnements de test lorsque cela n’est pas nécessaire.
Les données fictives ou anonymisées doivent être privilégiées.
Les exports contenant de grandes quantités de données personnelles doivent être limités aux personnes autorisées.
SCOOL doit éviter les fichiers Excel/CSV téléchargés localement sans nécessité puis conservés indéfiniment.
52. MESSAGERIE
Les données sensibles ne doivent pas être librement envoyées via des canaux personnels non contrôlés.
Il faut notamment éviter d’envoyer : pièces d’identité ; fichiers clients ; mots de passe ; clés API ; données de mineurs, dans des groupes WhatsApp ou canaux personnels lorsque cela n’est pas nécessaire et sécurisé.
Les mots de passe des utilisateurs ne doivent pas être conservés en clair.
Le système doit utiliser des mécanismes modernes de stockage sécurisé des mots de passe.
54. JOURNALISATION
Les événements importants devraient être journalisés lorsque cela est proportionné : connexion admin ; modification de droits ; export important ; suppression ; modification d’un enseignant ; opération sensible sur un compte ; incident de sécurité.
SCOOL doit périodiquement vérifier : qui dispose d’un accès ; si cet accès est toujours nécessaire ; si une personne ayant quitté le projet possède encore un compte ; si les droits sont excessifs.
Lorsqu’une personne quitte SCOOL ou cesse une mission : supprimer ses accès ; récupérer les équipements ; révoquer les clés ; modifier les secrets partagés ; rappeler les obligations de confidentialité.
57. TRANSFERTS INTERNATIONAUX
SCOOL étant établie aux Émirats arabes unis, elle doit tenir une documentation spécifique concernant les transferts de données européennes vers des pays tiers.
Pour chaque transfert : pays ; destinataire ; données ; finalité ; mécanisme juridique ; garanties ; mesures supplémentaires éventuelles.
SCOOL doit vérifier si une analyse d’impact relative à la protection des données est nécessaire pour certains traitements.
Compte tenu notamment : de la présence de mineurs ; des interactions en ligne ; des éventuels systèmes de modération ; des données de sécurité, je recommande formellement d’effectuer au minimum une analyse documentée de la nécessité d’une DPIA avant le lancement européen.
Toute nouvelle fonctionnalité doit faire l’objet des questions suivantes :
1. Quelles données sont nécessaires ?
2. Peut-on en collecter moins ?
3. Qui doit y accéder ?
4. Combien de temps ?
5. Un mineur est-il concerné ?
6. Existe-t-il un transfert international ?
7. Quel prestataire intervient ?
8. Quel est le risque si les données fuient ?
9. Peut-on pseudonymiser ou anonymiser ?
10. Quelle information doit être donnée à l’utilisateur ?
61. NOUVEAU PRESTATAIRE
Avant d’ajouter un prestataire ayant accès aux données : identifier la société ; connaître son pays ; examiner sa documentation de sécurité ; vérifier son DPA ; analyser les transferts ; définir ses accès ; mettre à jour le registre ; mettre à jour la Politique de confidentialité si nécessaire.
Une donnée ne doit pas être collectée simplement parce qu’elle pourrait éventuellement être utile un jour.
Chaque champ demandé doit correspondre à une finalité identifiée.
La collecte des données de mineurs doit toujours être évaluée avec les questions suivantes : est-ce nécessaire ? le parent doit-il être informé ? l’enfant peut-il comprendre l’information ? l’enseignant a-t-il réellement besoin de cette donnée ? peut-elle rester privée par défaut ?
SCOOL doit conserver dans un espace sécurisé : registre des traitements ; registre des violations ; demandes RGPD ; contrats/DPA des prestataires ; contrats Stripe ; analyse des transferts ; DPIA lorsque nécessaire ; politiques internes ; versions des CGU/CGV ; versions des politiques RGPD/Cookies ; preuves de consentement ; audits de sécurité pertinents.
Organisation recommandée :
01 – Registre des traitements
02 – Prestataires et DPA
03 – Transferts internationaux
04 – Demandes RGPD
05 – Violations de données
06 – DPIA / analyses de risques
07 – Sécurité
08 – Mineurs
09 – Cookies
10 – Historique des documents juridiques
Avant le lancement commercial européen, SCOOL doit vérifier :
☐ Adresse légale renseignée
☐ privacy@scoolhub.com opérationnelle
☐ safety@scoolhub.com opérationnelle
☐ support@scoolhub.com opérationnelle
☐ Hébergeur identifié
☐ Pays d’hébergement identifié
☐ Stripe correctement documenté
☐ DPA Stripe vérifié
☐ Prestataire de visioconférence identifié
☐ Développeurs sous contrat approprié
☐ Accès administrateurs limités
☐ Authentification forte activée
☐ Transferts hors UE documentés
☐ Mécanisme cookies testé
☐ Signalement mineur opérationnel
☐ Registre des traitements finalisé
☐ Procédure violation testée
☐ Sauvegardes vérifiées
☐ Nécessité d’une DPIA évaluée
☐ Nécessité d’un représentant UE évaluée
☐ Nécessité d’un DPO évaluée
67. PRINCIPE FINAL
Une politique de confidentialité affichée sur le site ne suffit pas si les pratiques techniques, les accès, les prestataires et les procédures internes ne correspondent pas à ce qui est annoncé.
Fin du Registre RGPD et des Procédures Internes de Protection des Données – SCOOL