Politique de confidentialité

Responsable de traitement - comptes staff et console réseau : la Mission laïque française (MlfMonde), 9 rue Humblot, 75015 Paris, France, pour les identifiants professionnels, les journaux d’accès à la plateforme et l’administration des établissements.

Responsable de traitement - dossier vie scolaire d’un site : l’établissement (collège / lycée) qui importe les élèves, photos, EDT et autorisations, et qui habilite son personnel. La plateforme Viesco agit alors comme sous-traitant (article 28 RGPD) : elle héberge et fait fonctionner le logiciel selon les instructions de l’établissement.

En pratique, un CPE qui scanne à la grille agit pour le compte de son établissement. Un super-administrateur réseau agit pour MlfMonde, sans se substituer au chef d’établissement sur le dossier pédagogique.

Contact établissement : administrateur Viesco / direction / CPE de votre hôte ({slug}.viesco.mlfmonde.cloud). Contact plateforme : administrateur Viesco réseau, via viesco.mlfmonde.cloud. Accueil MLF : accueil.mlf@mlfmonde.org · +33 (0)1 45 78 61 71.

Le RGPD s’applique notamment parce que :

• l’éditeur a son siège en France ;
• les serveurs et sauvegardes de Viesco sont en Union européenne (voir hébergement) ;
• une partie des personnels et, parfois, des familles, sont des résidents de l’UE.

Bases légales mobilisées (article 6) :

• mission d’intérêt public / obligation légale liée à l’organisation de l’établissement (surveillance, assiduité, sécurité des mineurs, vie scolaire) - pour les scans, l’EDT et les autorisations de sortie ;
• intérêt légitime de l’éditeur : sécuriser la plateforme, journaux d’authentification, lutte contre l’abus d’accès (pondéré : pas de publicité, pas de profilage commercial) ;
• contrat / mesures précontractuelles pour les comptes professionnels du personnel (fourniture de l’outil métier).

Nous ne fondons pas le traitement des élèves sur un « consentement cookie » marketing. Le consentement parental peut exister par ailleurs (autorisation de sortie, droit à l’image scolaire) : il est recueilli par l’établissement selon ses procédures, pas par un bandeau Viesco.

Données sensibles (article 9) : Viesco n’est pas conçu pour traiter la santé, la religion, les opinions, l’origine ethnique ou le NIR. N’importez pas ces champs. Une indication de cantine ou de régime de sortie n’est pas un dossier médical.

La Commission Nationale de contrôle de la protection des Données à caractère Personnel (CNDP) veille à l’application de la loi n° 09-08 relative à la protection des personnes physiques à l’égard du traitement des données à caractère personnel. Site : cndp.ma.

Pour un établissement du réseau situé au Maroc, cela implique notamment :

• un responsable de traitement identifiable (souvent l’établissement ou l’entité gestionnaire locale, selon les statuts) ;
• le respect des principes de finalité, de proportionnalité, de sécurité et d’information des personnes (personnels, et familles pour les élèves) ;
• le cas échéant, les formalités CNDP (déclaration, autorisation) selon la nature du fichier - en particulier si des données sont transférées hors du Maroc ;
• un transfert vers la France / l’UE (hébergement OVH Strasbourg) : ce n’est pas un envoi vers un pays « tiers » au sens RGPD (l’UE est le lieu d’hébergement), mais au regard du droit marocain il s’agit d’un transfert transfrontalier, qui peut exiger une autorisation CNDP et des garanties contractuelles entre l’établissement et MlfMonde.

Viesco ne déclare pas la CNDP à la place de l’établissement. Chaque site marocain doit s’assurer, avec sa direction et le cas échéant un conseil, que ses traitements vie scolaire (y compris cet outil) sont couverts. Les familles peuvent s’adresser à la CNDP (réclamation) en plus du chef d’établissement.

Personnel utilisateur : nom affiché Google, adresse e-mail @mlfmonde.org, identifiant interne, rôle, établissement(s), permissions, horodatage de connexion, adresse IP et user-agent dans les journaux de sécurité, indicateur 2FA le cas échéant, actions d’administration (création d’un compte, changement de logo, etc.).

Élèves (dossier établissement) :

• nom et prénom complets - identifiant métier affiché à la grille et encodé dans le QR de la carte (charge utile textuelle du type « NOM Prénom », sans identifiant national) ;
• classe, niveau, identifiants internes d’import (tableur établissement) ;
• photographie de la carte (fichier image) pour contrôle visuel humain ;
• emploi du temps via URL ou fichier iCal (cours, horaires, fuseau Africa/Casablanca pour le Maroc) ;
• autorisations de sortie / régime (sortie autorisée ou non selon créneaux) ;
• lien cantine / demi-pension si l’établissement active le module ;
• historique des scans (qui a scanné, quand, résultat autorisé / refusé, motif technique le cas échéant).

Non collecté par conception : géolocalisation GPS continue, microphone, contacts du téléphone, publicités, réseaux sociaux, paiement, données de santé, documents d’identité numérisés (passeport, CIN) - sauf si un établissement les place par erreur dans un import : cela doit être corrigé et le fichier inutilisé détruit.

Le nom et le prénom sont des données personnelles. Ils sont indispensables : un AED à la grille doit pouvoir confirmer qui se présente. Le QR ne contient pas, dans le modèle actuel, de secret cryptographique individuel : il porte une chaîne d’identité lisible. Conséquences :

• une carte perdue peut être présentée par un tiers - le contrôle visuel (photo + visage) reste obligatoire ;
• il ne faut pas publier de photos de cartes (réseaux, messageries parentales ouvertes) ;
• l’établissement peut faire opposer une carte, recréer un badge, et consigner l’incident dans la vie scolaire.

Les listes d’élèves (Excel, exports) ne doivent pas transiter par des boîtes mail personnelles ni être déposées sur des clouds grand public. Les imports se font dans l’interface administrateur Viesco.

Les photos ont une finalité unique : reconnaissance visuelle par un humain habilité au moment du scan.

• pas de moteur de reconnaissance faciale, pas d’empreinte biométrique stockée ;
• pas de galerie publique, pas de trombinoscope web ouvert aux familles dans Viesco ;
• pas d’usage marketing, presse ou réseaux sociaux via cette application ;
• stockage objet (MinIO) sur l’infrastructure UE, accès authentifié, pas d’URL publique indexable ;
• le droit à l’image scolaire (autorisation parentale classique de l’établissement) reste géré par l’établissement pour les usages hors Viesco (site web du collège, etc.) - Viesco n’élargit pas ces usages.

Un parent peut demander, via l’établissement, la suppression ou le remplacement de la photo dans Viesco (perte de qualité du contrôle visuel à la grille : l’établissement en est informé).

L’emploi du temps est un traitement de données (présence attendue, créneaux). Viesco interroge des flux iCal fournis par l’établissement. Règle produit : sans iCal exploitable, la sortie est refusée (fail-closed). Cela évite d’autoriser une sortie « par défaut » si le calendrier est cassé.

Le fuseau utilisé pour le Maroc est Africa/Casablanca. Un décalage d’import (mauvais fuseau, calendrier périmé) peut produire des refus injustifiés : la correction se fait sur la source EDT, pas en « forçant » l’application.

L’EDT n’est pas revendu, ni croisé avec de la publicité. Il n’est visible qu’aux profils habilités de l’établissement (et, pour le support, dans des conditions d’audit limitées).

• décider, au moment du scan, si une sortie est compatible avec l’EDT, les autorisations et la cantine ;
• identifier l’élève (nom, prénom, photo) pour éviter les substitutions de carte ;
• conserver un historique de passages pour la vie scolaire et les incidents ;
• administrer les établissements, logos, comptes staff et permissions ;
• sécuriser l’authentification Google Workspace et tracer les accès anormaux ;
• améliorer la stabilité technique (journaux applicatifs, sans publicité).

Aucune finalité de scoring commercial, de revente de fichiers, ni de ciblage publicitaire.

L’infrastructure de production Viesco est opérée sur des serveurs OVHcloud situés en France, région de Strasbourg (SBG), donc dans l’Espace économique européen. Objectif : pas d’hébergement nominatif des bases élèves aux États-Unis ni dans un pays sans décision d’adéquation pour ce service.

• application web et API sur le réseau interne MlfMonde, exposées via reverse-proxy (Traefik) en HTTPS ;
• base PostgreSQL, cache Redis, stockage fichiers (photos) MinIO - services non publiés sur Internet brut ;
• certificats TLS (Let’s Encrypt, DNS) pour viesco.mlfmonde.cloud et le joker *.viesco.mlfmonde.cloud ;
• sauvegardes : politique interne MlfMonde, conservation en UE.

OVHcloud agit comme hébergeur / sous-traitant d’infrastructure. Les accès console cloud sont limités aux administrateurs plateforme. Un incident OVH (datacenter) peut affecter la disponibilité : l’établissement doit prévoir une procédure papier / contrôle manuel.

Mesures en place (défense en profondeur, sans publicité excessive) :

• chiffrement en transit : HTTPS / TLS sur les hôtes publics ; pas de mot de passe Viesco local en production (délégation à Google Workspace) ;
• cookies de session HttpOnly, Secure en HTTPS, SameSite=Lax ; pas de jeton d’accès exposé au JavaScript de tracking ;
• Content-Security-Policy avec nonce par requête (pas d’unsafe-eval) ; en-têtes HSTS, X-Frame-Options / frame-ancestors none, Referrer-Policy, Permissions-Policy (caméra uniquement sur le scanner établissement) ;
• isolation des données par établissement (school_id) ; super-admin hors tenant par défaut ;
• journaux d’administration et d’authentification ;
• SSO limité au domaine @mlfmonde.org, comptes pré-provisionnés ;
• caméra : permission navigateur demandée seulement pour le scan QR, pas sur la page de connexion.

Le chiffrement au repos des disques dépend de la configuration des volumes OVH / de l’hyperviseur interne. Les secrets applicatifs ne sont pas versionnés dans Git. Aucune garantie d’invulnérabilité : signalez un soupçon via Signalement.

• personnel habilité de l’établissement (selon permissions) ;
• super-administrateurs MlfMonde (console réseau, support, incidents) ;
• Google Ireland / Google Workspace : authentification uniquement (identité e-mail professionnelle) ;
• OVHcloud : hébergement UE (Strasbourg) ;
• prestataires de messagerie ou support interne MLF si un ticket est ouvert.

Pas de revente à des brokers, pas de pixels publicitaires, pas de CDN de tracking. Les polices d’interface sont servies depuis l’application (self).

• compte staff : durée de la fonction, puis désactivation / suppression selon procédure établissement ou réseau ;
• dossier élève (identité, photo, régime) : scolarité dans l’établissement + délai d’usage vie scolaire, puis purge à la demande de l’établissement ;
• historiques de scan : typiquement l’année scolaire en cours, extensible selon politique interne (souvent 12 mois glissants pour l’audit) ;
• journaux de sécurité / connexions : jusqu’à 12 mois ;
• sauvegardes : rotation limitée, alignée sur la politique DSI MlfMonde.

L’établissement peut demander un export ou une suppression de sa base élèves. La suppression effective peut être différée le temps des sauvegardes, puis les copies expirent avec la rotation.

Selon le cadre applicable, les personnes concernées disposent notamment des droits :

• d’accès et de copie des données ;
• de rectification (nom mal orthographié, photo obsolète, mauvais régime) ;
• d’effacement lorsque le droit l’autorise (un élève encore scolarisé ne peut pas « tout effacer » si le traitement reste nécessaire à la vie scolaire) ;
• de limitation et d’opposition dans les cas prévus ;
• de portabilité lorsque la base légale et la nature du traitement le permettent (surtout données staff fournies par la personne) ;
• de retirer un consentement distinct (ex. photo extra-scolaire) sans bloquer le contrôle de sortie s’il repose sur une autre base.

Élèves / parents : s’adresser en premier lieu à la direction ou au CPE de l’établissement (responsable du dossier). Personnels : administrateur Viesco ou DSI / DPO MLF. Nous ne répondons pas aux demandes via des comptes Google personnels hors @mlfmonde.org pour un accès staff.

La quasi-totalité des élèves concernés sont mineurs. Les informations sont destinées aux représentants légaux via les canaux de l’établissement (règlement intérieur, livret, réunion de rentrée), pas via un compte Viesco parent. Viesco n’envoie pas d’e-mails marketing aux familles.

Les bases élèves Viesco sont conçues pour rester en UE (France, Strasbourg). Google Workspace (SSO) peut impliquer des traitements Google soumis aux conditions Workspace de MlfMonde (clauses types, région d’hébergement Google selon le contrat Workspace de l’association).

Depuis le Maroc, l’usage de Viesco constitue un transfert vers la France. L’établissement s’assure des formalités CNDP. Il n’y a pas de sous-traitant analytics américain dans le front Viesco.

Vous pouvez introduire une réclamation auprès de l’autorité compétente, sans préjudice d’un recours juridictionnel :

• CNIL (France / RGPD) - cnil.fr, 3 Place de Fontenoy, TSA 80715, 75334 Paris Cedex 07 ;
• CNDP (Maroc) - cndp.ma.

Merci d’écrire d’abord à l’établissement ou à MlfMonde : la plupart des demandes (photo, nom, compte staff) se règlent plus vite en interne.

Nous mettons à jour cette page lorsque le produit, l’hébergement ou la loi changent. La date en tête de document prévaut. Les CGU, cookies, mentions, accès et signalement complètent cette notice.