Cette analyse suit la méthodologie officielle de la CNIL (guides « PIA, la méthode » et « PIA, les modèles »). Elle documente, de bonne foi et avec sérieux, les risques du traitement de données mis en œuvre par Komen'Rtard et les mesures qui les réduisent.
Selon la CNIL, une AIPD est obligatoire dès qu'un traitement remplit au moins deux des neuf critères du CEPD (évaluation/notation des personnes, personnes vulnérables, usage innovant d'une nouvelle technologie, etc.). Sur sa page dédiée à l'IA en éducation, la CNIL est explicite : « chacun des traitements mis en œuvre par les établissements scolaires ayant recours à un système d'IA et concernant les informations des élèves — mineurs — nécessiterait, en principe, la réalisation d'une AIPD. » Komen'Rtard traite des données d'élèves mineurs via un système d'IA (correction automatique, génération de commentaires, profils de progression) : plusieurs critères sont réunis — personnes vulnérables, évaluation systématique, usage d'une technologie innovante. La réalisation d'une AIPD est donc requise, et la présente analyse y répond.
Cette obligation est distincte de celle du règlement européen sur l'IA (article 27, « analyse d'impact sur les droits fondamentaux » ou FRIA), qui pèse sur l'établissement scolaire utilisateur (le « déployeur »), pas sur Komen'Rtard. Mais la CNIL recommande explicitement qu'un éditeur de solution IA « mette à disposition une AIPD-cadre que l'établissement personnalise » — c'est l'objet de ce document.
| Nature du traitement | Hébergement et traitement de données pédagogiques ; génération de texte assistée par IA (commentaires de bulletin, comptes-rendus de réunion, mots aux parents, remédiation, fiches de préparation, programmations, demande d'aide au RASED, projet d'école) ; correction automatique de copies par IA ; transcription locale de réunions (dans le navigateur, l'audio ne quitte jamais l'appareil) ; suivi quotidien du comportement (« Météo de la semaine ») et tickets imprimés pour le cahier de liaison ; prise de rendez-vous en ligne avec les familles ; comptabilité de coopérative scolaire ; suivi périscolaire (cantine, étude) ; partage temporaire du cahier journal à un remplaçant ; suivi de ses missions par l'enseignant remplaçant (espace « Brigade ») ; organisation de l'école par son directeur (espace « Direction ») ; préparation des PPRE et des PAP (brouillons de travail) et aide à leur report dans le Livret de parcours inclusif (LPI) ; extension de navigateur « Extension Komen'Rtard », qui reporte depuis l'ordinateur de l'enseignant ses propres données dans le LSU et le LPI. |
|---|---|
| Finalités | Rédaction assistée du livret scolaire ; suivi des élèves et repérage des besoins ; suivi du comportement et information des familles par le cahier de liaison ; correction assistée des évaluations ; comptes-rendus de réunion ; rencontres avec les familles ; gestion de la coopérative scolaire ; organisation du périscolaire ; continuité pédagogique en cas de remplacement ; préparation des PPRE et des PAP et report dans le Livret de parcours inclusif ; demande d'aide spécialisée (RASED) ; organisation et fonctionnement de l'école par le directeur (équipe, surveillances, sorties scolaires, accompagnement par les AESH, absences non remplacées, projet d'école, conseils d'école, élections des représentants de parents, sécurité, prévisions d'effectifs) ; report des bilans périodiques dans le LSU ; gestion du compte enseignant et de son abonnement, y compris lorsqu'une commune le finance. |
| Personnes concernées | Enseignants utilisateurs (dont directeurs et remplaçants) ; élèves — mineurs ; tiers cités dans les contenus ou nécessaires à l'organisation : parents (rendez-vous, candidats aux élections de parents), collègues, AESH, membres du conseil d'école, personnels de direction et d'inspection, animateurs périscolaires, contacts des partenaires et de la commune. |
| Responsable de traitement | Le DASEN dans le premier degré (le chef d'établissement dans le second degré) ; les enseignants et les directeurs d'école agissent sous son autorité. Pour les données de compte des utilisateurs (adresse e-mail professionnelle, abonnement, sécurité d'accès), Komen'Rtard est lui-même responsable de traitement. |
| Sous-traitant | Komen'Rtard (Thierry Fourmaux, entrepreneur individuel) — voir l'accord de sous-traitance. |
| Sous-traitants ultérieurs | Supabase (base de données + authentification, hébergement UE — Francfort) ; Cloudflare (hébergement du site et de l'application web, CDN) ; OpenAI (génération de texte assistée par IA + lecture des copies de mathématiques — États-Unis) ; Mistral AI (lecture des copies hors mathématiques, lecture d'une liste de classe importée par l'enseignant, proposition d'objectifs de PPRE, rédaction d'une demande d'aide au RASED à partir de notes sans identité, aide à la rédaction du projet d'école — société française, hébergement UE, pas d'entraînement sur les données) ; Brave Search (résolution d'un lien documentaire à la demande, à partir d'un mot-clé de ressource — aucune donnée d'élève — États-Unis) ; Resend (e-mails transactionnels, dont l'e-mail de bienvenue et le remerciement de parrainage) ; RevenueCat, Stripe, Apple, Google (paiement et abonnement — traitent uniquement des données de facturation, sous leurs propres conditions, sans accès aux données d'élèves). Détail et localisation dans l'accord de sous-traitance. |
| Référentiels applicables | Aucun code de conduite (art. 40) ni certification (art. 42) à ce jour — micro-entreprise sans moyens pour ces démarches. |
| Catégorie | Exemples | Sensibilité (typologie CNIL) |
|---|---|---|
| Identité des élèves | Nom, prénom, date de naissance, genre, niveau / classe | Courante |
| Données scolaires | Évaluations, compétences, appréciations et commentaires de livret, position sur les profils / radars, appartenance à un groupe de besoin | Courante |
| Besoins éducatifs particuliers (élèves EBEP) | Mentions PPRE, PAP, AESH, ULIS ; objectifs et adaptations (mode ULIS) ; points d'appui, difficultés observées et aménagements, choisis dans les listes officielles fermées du Livret de parcours inclusif. Aucun diagnostic médical ni trouble nommé n'est enregistré — seuls des objectifs pédagogiques et des observations scolaires. | Perçue comme sensible (proche de données de santé / handicap) |
| Comportement | Appréciations par critère (attitude, participation, concentration, autonomie), de A à E, et adjectifs choisis dans une liste fermée ; « Météo de la semaine » (ligne suivante). Aucun texte libre sur le comportement d'un enfant. | Perçue comme sensible |
| Météo de la semaine (comportement au quotidien) | Fonction facultative. Pour chaque élève et chaque jour de classe, une météo parmi cinq (soleil, éclaircies, nuages, pluie, orage), ou « absent » / « pas de classe ». Chaque jour passé est pré-rempli au soleil — les absences sont reprises de l'appel de l'enseignant, les jours fériés écartés — et l'enseignant ajuste les seules exceptions. Le bilan de la semaine est la moyenne des jours, que l'enseignant peut ajuster ; un objectif pour la semaine suivante peut être choisi dans une liste fermée (« Garder son calme »…) : aucun texte libre. Les tickets sont imprimés par l'enseignant, collés dans le cahier de liaison et signés par les parents ; l'élève y entoure sa propre météo, sur le papier (rien n'est enregistré de cette auto-évaluation). La moyenne des bilans d'une période pré-remplit l'« attitude » du livret, que l'enseignant peut changer d'un geste : une aide à son appréciation, jamais une décision automatique. Une semaine seulement consultée n'est pas enregistrée. Visible du seul enseignant de la classe (règle appliquée par la base de données), jamais du directeur ; aucun traitement par IA. | Perçue comme sensible — listes fermées, sans texte libre, effacée chaque 1er septembre |
| Copies d'élèves (correction auto) | Photographies de copies (la bande où l'élève écrit son nom est masquée avant tout envoi), texte manuscrit reconnu, barème, notes, appréciations | Courante |
| Réunions | Titre, date, transcription texte (l'audio est transcrit dans le navigateur et n'est jamais transmis ni enregistré), fiche structurée, compte-rendu généré, participants saisis | Perçue comme sensible selon le contenu (situations d'élèves, situations familiales évoquées) |
| Coopérative scolaire | Numéro de coopérative, nom du mandataire, nom et adresse de l'école, mouvements comptables, soldes | Courante (comptabilité associative) |
| Périscolaire | Listes d'élèves inscrits, présences quotidiennes (cantine, étude), régime alimentaire | Perçue comme sensible — le régime alimentaire peut révéler une conviction religieuse ou philosophique |
| Cahier journal partagé | Contenu du cahier journal et pièces jointes, communiqués à un remplaçant par lien temporaire (en lecture seule) | Courante |
| Répartition des classes (constitution collaborative) | Le temps d'une session rejoignable par code, les enseignants d'un même niveau mettent en commun, pour préparer les classes de l'année suivante : prénom, nom, genre, mois de naissance (pas la date complète), niveau par domaine (français, mathématiques) et un repère agrégé de charge « besoins éducatifs particuliers » : une valeur unique aucun / léger / lourd par élève, calculée localement à partir des dispositifs saisis dans son profil (PAP, PPRE, PPS, AESH…). Ni le type de dispositif, ni aucune donnée médicale, ni le comportement ne sont partagés — seulement ce repère, nécessaire pour ne pas concentrer les élèves à besoins dans une même classe. Modifiable par l'enseignant. La répartition est proposée ; l'affectation finale est décidée par l'équipe. | Repère de charge perçu comme sensible (proche du handicap) — minimisé (valeur agrégée, non nominative du dispositif) ; partage limité aux enseignants participants, session purgée à 60 jours |
| Import d'une liste de classe (photo / PDF) | Pour éviter la ressaisie de chaque élève en début d'année : une photographie d'une liste d'appel, ou un PDF d'export administratif (type ONDE), est transmise ponctuellement à Mistral AI (UE) pour en extraire prénom, nom, date de naissance et genre. Le fichier n'est pas conservé. Le résultat s'affiche dans un tableau que l'enseignant vérifie et corrige avant toute création d'élève ; les mêmes données peuvent aussi être collées depuis un tableur, sans recours à l'IA. C'est la seule opération où des nom et prénom d'élèves sont transmis en clair à l'IA : la pseudonymisation y est impossible par nature, puisque lire une liste suppose d'en lire les noms. Mesures compensatoires : prestataire situé dans l'UE et ne s'entraînant pas sur les données, transmission ponctuelle, aucun stockage du fichier, validation humaine de chaque ligne avant création, et disponibilité d'une saisie sans IA (à la main ou par collage). | Courante — mêmes données que la saisie manuelle d'un élève |
| Portrait de l'élève (fiche EBEP) | Pour cocher plus vite les cases officielles de la fiche EBEP, l'enseignant choisit des mots dans une liste (« À l'aise dans ce domaine », « Lent », « Distrait »…) ; la correspondance avec les cases du LPI et les aménagements proposés est calculée sur l'appareil, sans IA, et l'enseignant valide, décoche ou complète. La fonction « Décrire l'élève » (description libre classée par Mistral AI) a été retirée le 2 octobre 2026 : plus aucune description d'élève n'est transmise à l'IA pour remplir la fiche. | Perçue comme sensible — sans IA, listes fermées |
| Demande d'aide au RASED | L'enseignant téléverse une fois la fiche vierge de sa circonscription (PDF ou Word) ; elle est gardée pour les demandes suivantes et partagée avec les collègues actifs de la même école Komen'Rtard. Elle ne contient aucune donnée d'élève (le cas échéant, les coordonnées professionnelles des membres du RASED, déjà diffusées par la circonscription). Pour une demande, l'enseignant décrit l'élève avec ses mots ; Mistral AI (UE) reçoit cette description débarrassée du prénom et du nom (un terme de diagnostic est signalé avant l'envoi), le niveau de classe, le genre, les libellés des rubriques de la fiche et, si l'enseignant le laisse coché, le profil de la fiche EBEP en libellés officiels (points d'appui, difficultés, aménagements, dispositifs, suivi extérieur oui / non, maintien) — jamais le nom, le prénom, la date de naissance ni l'école. L'IA propose un texte par rubrique ; l'enseignant relit et corrige tout. L'identité est écrite dans la fiche sur l'appareil ; la fiche remplie n'est pas enregistrée par Komen'Rtard. | Perçue comme sensible (difficultés scolaires) — pseudonymisée, non conservée |
| PPRE / PAP préparés (brouillons) | Type (PPRE ou PAP), date, durée, fonctions des participants (jamais leurs noms, saisis directement dans le LPI), points d'appui, difficultés et aménagements (codes officiels du LPI), personnes mobilisées et objectifs. Pour le PPRE, l'enseignant peut demander une proposition d'objectifs : Mistral AI (UE) reçoit le niveau de classe, le type et la durée du PPRE et les libellés cochés — jamais le nom, le prénom, l'année de naissance ni l'école ; un éventuel contexte libre est débarrassé du prénom et du nom, bloqué s'il contient un terme de diagnostic, et n'est pas conservé. L'avis médical requis pour un PAP n'est jamais transmis à Komen'Rtard : l'enseignant le dépose directement dans le LPI. Le LPI reste le document officiel ; le brouillon n'est accessible qu'à l'enseignant qui a l'élève dans sa classe. | Perçue comme sensible (un PAP suppose un avis médical, dont Komen'Rtard n'a jamais connaissance) |
| Extension Komen'Rtard (LSU et LPI) | Extension pour le navigateur Chrome, installée par l'enseignant sur son ordinateur et reliée à son compte par un code personnel. Elle lit ses propres données (élèves, appréciations et niveaux pour le LSU ; PPRE / PAP préparés pour le LPI) et les saisit, dans son navigateur, dans le LSU et le LPI — applications officielles où il est déjà connecté. Aucun autre destinataire : les données vont de la base Komen'Rtard au navigateur de l'enseignant, puis à l'application officielle. L'extension n'agit que sur l'onglet où l'enseignant la déclenche (permission « onglet actif ») ; dans le LSU, elle ne remplit un bilan qu'après avoir vérifié que c'est bien celui de l'élève attendu ; dans le LPI, elle ne clique jamais « Enregistrer » ni « Finaliser » (le document devient alors visible des familles) et ne touche pas à l'avis médical : l'enseignant relit et valide lui-même. Seul le code personnel est enregistré dans le navigateur ; les données d'élèves n'y sont gardées que le temps de la session (12 heures au plus, jamais sur le disque). | Courante à perçue comme sensible selon le contenu (mêmes données que dans l'application) |
| Espace Direction — l'équipe et les élèves de l'école | Le directeur crée l'école (nom, UAI, commune, circonscription) et la partage par un code ; un enseignant ne la rejoint qu'en y consentant, puis le directeur accepte sa demande. Pour les seuls membres actifs de son école, le directeur voit, par des fonctions serveur dédiées qui ne renvoient que des colonnes listées : le nom et les classes des collègues ; l'identité de base des élèves (nom, prénom, date de naissance, genre, classe), pour les documents administratifs (listes, certificats de scolarité) et l'organisation (absences) ; l'appel fait ou pas fait par classe — jamais le détail des absences ; pour les prévisions d'effectifs, une ligne par élève sans nom (classe, niveau, ULIS) et une empreinte technique qui évite de compter deux fois un élève inscrit en ULIS et dans sa classe d'inclusion ; pour le tableau des 108 heures, les totaux d'heures par collègue et par type d'activité — jamais les dates, notes ni libellés de l'agenda. Il ne voit jamais les évaluations, appréciations, comportement (dont la météo de la semaine), fiches EBEP, PPRE / PAP ni réunions de ses collègues. | Courante |
| Espace Direction — organisation de l'école | Documents tenus par le directeur, visibles de lui seul sauf mention : tableau des services (noms des adultes de l'équipe ; lu par les membres, comme l'affichage dans l'école) ; sorties scolaires (préparées par l'enseignant, autorisées par le directeur ; noms et qualités des accompagnateurs adultes, aucun nom d'élève — seulement les identifiants techniques des élèves qui ne partent pas) ; demandes d'inscription aux projets ADAGE (classe, effectif) ; élections des représentants de parents (noms des candidats, déjà affichés ; aucune liste électorale ni d'émargement, qui restent dans ONDE) ; registre de sécurité (exercices incendie et PPMS, sans donnée nominative) ; conseils d'école (composition — noms des membres adultes —, ordre du jour, procès-verbal) ; courriers (ceux qui nomment un élève ne sont jamais enregistrés) ; projet d'école (aucune donnée d'élève ; l'aide à la rédaction par Mistral AI, UE, reçoit des textes débarrassés des noms de l'école, de la commune, de la circonscription et des personnes) ; dates partagées dans l'agenda de l'équipe ; carnet d'adresses du directeur (mairie, partenaires, parents élus : nom, téléphone, e-mail). PAI : guide, formulaire officiel et courriers produits sur l'appareil, aucune donnée enregistrée (Komen'Rtard n'est pas un hébergeur certifié de données de santé). | Courante |
| Répartition des AESH (espace Direction) | Pour construire l'emploi du temps des AESH de l'école : élèves accompagnés désignés par leur prénom et l'initiale du nom, classe, nombre d'heures et type d'aide (individuelle ou mutualisée) ; noms et disponibilités des AESH. Jamais de diagnostic, jamais la notification de la MDPH. Accès : le directeur seul. | Sensible — un accompagnement révèle une situation de handicap (voir § 2.2) |
| Absences non remplacées (espace Direction) | Le directeur note l'absence d'un collègue (classe, nom de l'enseignant s'il le souhaite, dates, remplacement) — jamais le motif. Si personne ne remplace, l'application propose la répartition des élèves dans les autres classes, désignés « Prénom N. », et le mot aux familles. Chaque enseignant peut préparer à l'avance la répartition de ses élèves (enregistrée par identifiants, sans noms en double) ; son directeur la retrouve le jour venu, en « Prénom N. ». | Courante |
| Espace Brigade (enseignants remplaçants) | Le remplaçant enregistre ses écoles (nom, commune, adresse, téléphone, horaires, informations pratiques), ses classes d'accueil (niveau, nom du titulaire, élèves comme dans une classe ordinaire), ses missions (dates), son emploi du temps et son cahier journal. Pour chaque élève, des étiquettes rapides (« PAI », « allergie », « AESH », « PPS », « besoin ») et une note courte, pour la sécurité et la continuité pendant le remplacement — sans détail médical. Accès : le remplaçant seul. | Perçue comme sensible (étiquettes liées à la santé ou au handicap) — minimisée, effacée chaque 1er septembre (voir § 2.2) |
| Rendez-vous avec les familles | L'enseignant ouvre des créneaux (dates, plage horaire, durée) et partage un lien de classe ; chaque famille réserve sans compte en saisissant un nom (parent et enfant) et peut annuler elle-même grâce à un lien personnel. Les familles passent uniquement par une fonction serveur : une famille ne voit jamais le nom d'une autre, et le lien cesse de fonctionner 7 jours après la dernière date. Aucune autre donnée n'est demandée (ni e-mail, ni téléphone). | Courante |
| Financement par une collectivité | Quand une commune finance Komen'Rtard pour ses écoles : nom de la collectivité, SIRET, adresse, nom, fonction, e-mail et téléphone de son contact, écoles couvertes, nombre de classes, devis et factures (Chorus Pro). La commune n'accède à aucune donnée (ni élèves, ni enseignants) ; ce dossier est réservé à l'éditeur. | Courante (données professionnelles) |
| Compte enseignant | E-mail académique (@ac-…), mot de passe (haché), secret de double authentification, département, poste choisi (enseignant, direction, remplaçant), solde de crédits, historique d'abonnement ; canal d'arrivée (liste fermée, relevé sans cookie) ; code de parrainage et lien parrain–filleul ; suivi de l'envoi de l'e-mail de bienvenue ; statut de membre d'une école (en attente, actif). Après la suppression d'un compte, il ne reste qu'un compteur anonyme : la date de suppression et l'ancienneté en jours. | Courante |
Cycle de vie : collecte par saisie directe de l'enseignant (ou photo, pour la correction ; accès par code pour le périscolaire ; lien de réservation, pour les familles) → stockage chez Supabase (base de données, UE — Francfort) ; l'application et le site sont servis par Cloudflare (HTTPS partout) → lors d'une génération demandée, un texte pseudonymisé est traité ponctuellement par un prestataire IA (les vrais noms et dates ne sont réinjectés que localement, sur l'appareil ; l'import d'une liste de classe fait exception — cf. § 1.2) → restitution à l'enseignant → conservation selon les durées du tableau ci-dessous → suppression automatique à l'échéance, ou sur demande. La transcription de réunion est réalisée 100 % en local dans le navigateur : l'enregistrement audio ne quitte jamais l'appareil.
| Principe | Évaluation |
|---|---|
| Finalité déterminée, explicite, légitime | Satisfaisant — mission d'enseignement, finalités documentées dans la politique de confidentialité. |
| Base légale (art. 6) | Satisfaisant — données pédagogiques : exécution d'une mission d'intérêt public (l'enseignement), au titre de laquelle l'enseignant agit (art. 6.1.e). Gestion du compte et de l'abonnement : exécution du contrat (art. 6.1.b). |
| Minimisation | Satisfaisant — seules les données nécessaires à l'usage pédagogique sont collectées. Renforcée par : transcription des réunions 100 % locale (l'audio n'est jamais transmis) ; pseudonymisation avant tout envoi à l'IA d'un contenu rédigé (commentaire de bulletin, compte-rendu de réunion, mot aux parents, remédiation…) — prénoms des élèves, noms de famille accolés à un prénom ou cités après une civilité (« Monsieur / Madame … »), dates de naissance — au moyen notamment d'un dictionnaire des prénoms courants (fichier INSEE), la correspondance avec les vrais noms n'existant que localement sur l'appareil ; seule exception, assumée et documentée : l'import d'une liste de classe (§ 1.2), où les nom et prénom sont l'objet même de la lecture et ne peuvent être masqués — la protection y repose alors sur un prestataire situé dans l'UE ne s'entraînant pas sur les données, une transmission ponctuelle sans stockage, et la validation humaine de chaque élève avant sa création ; masquage de la bande « nom » sur les photos de copies ; correction automatique indisponible sur les applications mobiles ; pour la fiche EBEP et les PPRE / PAP : listes officielles fermées du LPI, blocage des termes de diagnostic avant tout envoi à l'IA, retrait du prénom et du nom des textes libres, participants enregistrés par leur seule fonction, contexte d'objectifs jamais conservé, « Décrire l'élève » retiré le 2 octobre 2026 au profit du Portrait de l'élève, sans IA ; pour la météo de la semaine : niveaux et objectifs en listes fermées, aucun texte libre, jamais visible du directeur ; pour l'espace Direction : fonctions serveur qui ne renvoient que des colonnes listées (jamais évaluations, appréciations, comportement ni suivi particulier), élèves accompagnés par une AESH ou répartis lors d'une absence désignés par leur prénom et une initiale, motif d'absence d'un collègue jamais demandé, courriers nommant un élève jamais enregistrés, PAI sans aucune donnée enregistrée ; pour la demande d'aide au RASED : notes débarrassées de l'identité, fiche remplie produite sur l'appareil et non conservée ; pour les rendez-vous : un nom, rien d'autre. L'interface recommande à l'enseignant de ne pas citer le nom de l'établissement ni de la commune pendant une réunion — les noms de lieux ne sont pas masqués automatiquement ; il s'agit d'une recommandation, non d'une garantie. |
| Qualité des données | Satisfaisant — données saisies et corrigeables directement par l'enseignant, qui valide chaque note portée au livret et relit tout compte-rendu avant enregistrement. |
| Durée de conservation limitée | En cours — durées définies et bornées (voir le tableau des durées de conservation) ; la purge automatique de la règle générale « 12 mois » est en cours d'implémentation, celle des photos de copies est déjà active. |
Trois catégories de données traitées peuvent relever de l'article 9 (données « sensibles ») :
Ces traitements sont mis en œuvre par l'enseignant et l'établissement dans le cadre de leur mission de service public (scolarisation inclusive, sécurité des élèves, organisation de la restauration scolaire), ce qui relève du motif d'intérêt public important prévu par le droit national (art. 9.2.g). Komen'Rtard n'intervient qu'en tant que sous-traitant, ne détermine pas ces finalités et ne prend aucune décision automatisée sur ces données (pas de profilage, pas de tri). Point à confirmer avec le délégué à la protection des données de l'établissement.
| Droit | Évaluation |
|---|---|
| Information (art. 12-14) | Partielle — enseignants : politique de confidentialité publique et accessible. Familles : informées par l'intermédiaire de l'enseignant / de l'établissement ; un modèle d'information aux familles est fourni (il mentionne la météo de la semaine et la prise de rendez-vous depuis la version 3.6), et un rappel de cette obligation sera ajouté dans l'application (plan d'action). Pour la météo de la semaine, l'application fournit en outre un mot aux familles prêt à coller dans le cahier de liaison, qui en explique le fonctionnement et ce qui est attendu des parents. La page de réservation des rendez-vous recevra une courte mention d'information (plan d'action). |
| Consentement | Non applicable — base légale = mission d'intérêt public, pas de consentement requis (confirmé par la doctrine CNIL sur l'IA en éducation). Droit d'opposition RGPD conservé par les familles. |
| Accès, rectification, effacement (art. 15-17) | Satisfaisant — l'enseignant peut consulter/corriger/supprimer à tout moment ; page dédiée Suppression des données. |
| Sous-traitance contractualisée (art. 28) | Satisfaisant — accord de sous-traitance publié ; DPA signés ou archivés avec chaque sous-traitant ultérieur (OpenAI, Mistral AI, Supabase, Cloudflare, Resend), consignés dans un registre. Demande de non-conservation (Zero Data Retention) déposée auprès d'OpenAI le 6 septembre 2026 ; OpenAI a répondu le 18 septembre 2026 qu'elle n'est proposée qu'aux comptes entreprise. La mesure retenue est donc la rétention anti-abus de 30 jours, couverte par le DPA et le Data Privacy Framework, avec journalisation des appels API désactivée. |
| Transferts hors UE (art. 44-49) | Encadré — stockage (Supabase, Francfort) et lecture des copies hors mathématiques (Mistral AI, Suède) : dans l'UE, aucun transfert. OpenAI (États-Unis) : DPA signé, société certifiée au Data Privacy Framework UE–États-Unis et clauses contractuelles types ; le texte transmis est pseudonymisé. Resend (États-Unis, e-mails) : DPA et certification Data Privacy Framework. Brave Search (États-Unis) : requête documentaire sans donnée d'élève. Cloudflare : DPA incluant les clauses contractuelles types. |
Règle générale : les données pédagogiques sont conservées 12 mois après la dernière activité sur la ressource concernée (la classe, le livret, la fiche…), puis supprimées automatiquement. Un e-mail d'avertissement est envoyé à l'enseignant environ un mois avant toute suppression automatique, l'invitant à exporter ce dont il a besoin.
| Donnée | Conservation | Purge |
|---|---|---|
| Classe et élèves, livret et appréciations, fiche de suivi élève, résultat de correction IA | 12 mois après la dernière activité sur la ressource | Automatique |
| Compte-rendu de réunion, mot de liaison, document généré | 12 mois après la création | Automatique |
| Compte enseignant | Suppression demandée : effective sous 30 jours. Inactivité prolongée : 12 mois, puis purge. Après la suppression, l'adresse e-mail peut subsister dans les journaux techniques des prestataires (authentification, envoi d'e-mails) jusqu'au terme de leur propre durée de conservation ; elle n'est plus utilisée. | Automatique |
| Session de répartition des classes (pool d'élèves mis en commun) | Supprimée automatiquement 60 jours après sa création, avec toutes les données associées (tâche de purge planifiée quotidienne). | Automatique |
| Photos de copies transmises à l'IA | Supprimées dès la fin de la correction — jamais de stockage permanent ni dans un espace de fichiers. Cas du relais de capture par QR code : table éphémère, au plus tard 15 minutes (tâche de purge planifiée toutes les minutes, exécution vérifiée en production le 6 septembre 2026). | Automatique |
| Photo / PDF d'une liste de classe importée | Transmis ponctuellement au service de lecture, jamais stocké : ni en base de données, ni dans un espace de fichiers. Seuls les élèves validés par l'enseignant sont enregistrés — ils suivent alors la durée « Classe et élèves » ci-dessus. | Immédiate |
| PPRE / PAP préparés (brouillons) | Jusqu'au 1er septembre suivant (fin de l'année scolaire), ou plus tôt sur suppression par l'enseignant ; supprimés avec la fiche de l'élève. Le document officiel est celui du LPI. | Automatique (tâche annuelle) |
| Contexte donné pour les objectifs de PPRE ; notes d'une demande d'aide au RASED et fiche remplie | Aucune conservation : transmis ponctuellement à l'IA ou produits sur l'appareil, jamais enregistrés. La fiche vierge de la circonscription est gardée jusqu'à sa suppression ou celle du compte. | Immédiate |
| Météo de la semaine (jours, bilans, objectifs) | Jusqu'au 1er septembre suivant (toute la table est effacée chaque année), ou plus tôt avec l'élève. | Automatique (tâche annuelle) |
| Espace Direction : tableau des services, élections, sorties scolaires, demandes ADAGE, répartition des AESH, absences non remplacées | Jusqu'au 1er septembre suivant (fin de l'année scolaire) | Automatique (tâches annuelles) |
| Espace Direction : registre de sécurité | Trois ans, pour comparer d'une année sur l'autre | Automatique (tâche annuelle) |
| Espace Direction : projet d'école, conseils d'école, courriers, carnet d'adresses, 108 heures, prévisions d'effectifs, répartition préparée en cas d'absence | Règle générale ci-dessus ; supprimés avec le compte (ou la classe) concerné | Automatique (règle générale, en cours) |
| Espace Brigade : étiquettes et notes sur les élèves des classes d'accueil | Effacées chaque 1er septembre ; classes et élèves suivent ensuite la règle générale | Automatique (tâche annuelle) |
| Rendez-vous avec les familles | 30 jours après la dernière date de rencontre, la session est supprimée avec ses réservations ; plus tôt si l'enseignant la supprime ou si la famille annule | Automatique (tâche quotidienne) |
| Dossier de financement d'une collectivité | Dix ans pour les devis et factures (obligation comptable) ; le reste sur demande | Manuelle |
| Données d'élèves chargées par l'Extension Komen'Rtard | Mémoire de session du navigateur uniquement (12 heures au plus), jamais sur le disque ; une copie plus ancienne laissée par une version antérieure de l'extension est effacée à son ouverture. | Automatique |
| Instructions (« prompts ») envoyées à l'IA et contenant des données d'élèves | Aucune conservation applicative — les fonctions serveur ne journalisent aucune instruction ni aucune donnée d'élève (vérifié dans le code le 6 septembre 2026). | Immédiate |
| Journaux techniques applicatifs | 6 mois | Automatique |
| Sauvegardes de la base | Rotation de 30 à 90 jours ; une demande d'effacement portée sur les données actives se propage hors des sauvegardes au terme de ce cycle. | Automatique |
La mise en œuvre technique de la purge automatique de la règle générale « 12 mois » est en cours (la purge des photos de capture, elle, est déjà active et vérifiée) — voir le plan d'action.
Trois événements redoutés types (méthode CNIL), chacun noté sur les échelles officielles à 4 niveaux (1 Négligeable → 4 Maximal), après prise en compte des mesures déjà en place.
Mesures existantes : cloisonnement strict par enseignant — chaque compte n'a techniquement accès qu'à ses propres élèves, par une règle de sécurité appliquée au niveau de la base de données (RLS « propriétaire uniquement » sur toutes les tables d'élèves — deux règles trop larges, découvertes et corrigées le 25 septembre 2026 : voir la version 3.5) ; la fiche EBEP et le profil de l'élève, rangés par identité, suivent la règle « besoin d'en connaître » : il faut avoir l'élève dans sa classe et être le propriétaire de la fiche ou un collègue actif de la même école (règle trop large découverte le 2 octobre 2026 et restreinte : voir la version 3.6) ; espace Direction : accès du directeur limité aux membres actifs de son école, qui y ont consenti, par des fonctions serveur qui ne renvoient que des colonnes listées ; inscription réservée aux adresses académiques (@ac-…), verrouillée côté serveur ; fonctions serveur d'IA réservées aux utilisateurs connectés (session vérifiée à chaque appel) ; extension de navigateur limitée à l'onglet où l'enseignant la déclenche ; accès sans compte (périscolaire, partage du cahier journal, réservation des rendez-vous par les familles) uniquement via des fonctions serveur protégées par un jeton révocable et à expiration ; connexions chiffrées (HTTPS) partout ; mots de passe hachés ; transcription des réunions 100 % locale (l'audio n'est jamais transmis) ; pseudonymisation avant tout envoi à l'IA d'un contenu rédigé (prénoms d'élèves, noms après civilité, dates de naissance — réversible uniquement en local ; l'import d'une liste de classe en est l'exception documentée, § 1.2, encadrée par un prestataire UE sans entraînement, sans stockage, et une validation humaine) ; masquage de la bande « nom » sur les photos de copies ; double authentification (TOTP) disponible et fortement incitée ; déconnexion automatique après 30 minutes d'inactivité.
Gravité : 3 — Importante (des données incluant des mentions de besoins particuliers exposées causeraient des difficultés réelles, sans être irrémédiables) · Vraisemblance : 2 — Limitée (cloisonnement base de données, verrou académique et pseudonymisation avant IA réduisent fortement le risque ; la double authentification, encore facultative, ne protège que les comptes qui l'ont activée — la rendre obligatoire est au plan d'action)
Mesures existantes : le cloisonnement par enseignant empêche techniquement la modification des données d'un autre compte ; historique de versions côté base de données (Supabase).
Gravité : 2 — Limitée (une évaluation altérée est gênante mais généralement rectifiable par l'enseignant) · Vraisemblance : 2 — Limitée
Mesures existantes : sauvegardes automatiques gérées par Supabase ; l'enseignant peut à tout moment exporter ses données en PDF (livret, programmations, comptes-rendus), ce qui limite la dépendance totale à la plateforme.
Gravité : 2 — Limitée (perte de travail en cours d'année, gênante mais rarement irrémédiable) · Vraisemblance : 2 — Limitée
En cas d'incident portant sur des données personnelles : (1) détection — surveillance des journaux, alertes des hébergeurs, signalement d'un utilisateur ; (2) qualification sous 24 heures — nature, volume, personnes concernées, risque pour les droits et libertés ; (3) si un risque est établi, notification à la CNIL sous 72 heures (téléservice de notification) et information sans délai des enseignants responsables de traitement concernés, à charge pour eux d'informer les familles en cas de risque élevé ; (4) journalisation de toute violation dans un registre interne, qu'elle soit notifiée ou non.
Sur les trois événements redoutés, aucun ne dépasse le niveau « Importante » en gravité. L'accès illégitime reste le point le plus sensible (gravité 3, du fait de la nature parfois sensible des données — besoins éducatifs particuliers, accompagnement par une AESH, comportement, contenu des réunions, régime alimentaire) : sa vraisemblance est ramenée à « Limitée » par le cloisonnement au niveau de la base de données, le verrou des adresses académiques et la pseudonymisation avant tout envoi à l'IA. Elle deviendra « Négligeable » lorsque la double authentification sera rendue obligatoire (plan d'action). Les deux autres événements sont à vraisemblance « Limitée ».
| Mesure | Objectif | Statut |
|---|---|---|
| Double authentification (TOTP) + déconnexion automatique après 30 min d'inactivité | Réduire la vraisemblance d'un accès illégitime (vol d'identifiants, appareil non surveillé) | Faite |
| Pseudonymisation élargie avant envoi à l'IA — comptes-rendus de réunion : masquage des prénoms d'élèves, des noms cités après une civilité et des dates de naissance (dictionnaire des prénoms courants INSEE), réversible uniquement en local | Protéger toutes les personnes citées, pas seulement les élèves de l'enseignant | Faite |
| Retrait du prestataire Google / Gemini (utilisé en essai pour la lecture de copies) : code supprimé, clé d'accès révoquée | Limiter la chaîne de sous-traitance au strict nécessaire | Faite |
| Étendre la pseudonymisation aux mots aux parents et aux autres fonctions de génération de texte | Cohérence de la protection sur l'ensemble des fonctionnalités IA | Prévue |
| Pseudonymisation du prénom côté serveur (2e barrière, en plus du masquage côté application) | Réduire davantage le risque en cas de contournement du premier verrou | Prévue |
| Implémenter la purge automatique de la règle générale « 12 mois après dernière activité » (la purge des photos de capture est déjà active) | Rendre les durées de conservation effectives, pas seulement documentées | En cours |
| Rendre la double authentification obligatoire | Ramener la vraisemblance de l'accès illégitime à « Négligeable » pour tous les comptes | Prévue |
| Signer / archiver les DPA de chaque sous-traitant (OpenAI, Mistral, Supabase, Cloudflare, Resend) et tenir un registre ; demande de Zero Data Retention déposée auprès d'OpenAI | Sécuriser juridiquement la sous-traitance et les transferts hors UE | Faite — ZDR non disponible hors compte entreprise (réponse OpenAI du 18/09/2026) ; rétention 30 j encadrée retenue |
| Journalisation des appels API désactivée au niveau de l'organisation OpenAI (les prompts et réponses ne sont pas conservés pour consultation dans le tableau de bord) | Réduire la rétention côté OpenAI au minimum sans attendre la ZDR | Faite |
| Formaliser le registre des activités de traitement du sous-traitant (art. 30.2), distinct du registre des accords de sous-traitance déjà tenu | Obligation documentaire du sous-traitant | Prévue |
| Cadrage documenté de la base légale des données particulières (art. 9) — mission de service public, minimisation ; à confirmer avec le DPO de l'établissement | Sécuriser le traitement des mentions ULIS et des régimes alimentaires | Faite |
| Modèle d'information aux familles fourni ; rappel de l'obligation d'information à ajouter dans l'application | Permettre à l'enseignant d'informer les familles, dont il est responsable | Modèle fait, rappel in-app prévu |
| Procédure de gestion des violations de données (qualification 24 h, notification CNIL 72 h, registre interne) | Réagir dans les délais légaux à un incident | Faite |
| Permettre à l'enseignant d'exporter l'ensemble de ses données depuis son compte, en autonomie | Faciliter le droit à la portabilité et l'archivage avant purge | Prévue |
| Faire relire l'analyse par un délégué à la protection des données ou un conseil externe ; la tenir à la disposition de la CNIL et des établissements | Validation au-delà de l'auto-évaluation | Prévue |
| Restreindre l'accès à la fiche EBEP et au profil de l'élève (règle « besoin d'en connaître » : propriétaire ou collègue actif de la même école ayant l'élève) ; puis permettre deux fiches distinctes pour deux enfants homonymes de deux écoles (mise à jour de l'application) | Supprimer l'accès possible par un compte d'une autre école ayant un élève homonyme | Faite — 2e étape prévue |
| Purge automatique des rendez-vous avec les familles, 30 jours après la dernière date | Borner la conservation des noms saisis par les familles | Faite |
| Courte mention d'information sur la page de réservation des familles (données saisies, destinataire, durée) | Informer les familles au moment de la collecte | Prévue |
| Rappel à l'écran, dans l'espace Brigade : ne noter aucun détail médical | Éviter qu'une donnée de santé n'entre par la note courte | Prévue |
| Modèle d'information aux familles mis à jour (météo de la semaine, rendez-vous, localisation des services d'IA) ; mot aux familles de la météo fourni dans l'application | Information claire et exacte des familles | Faite |
| Mise à disposition d'un export téléchargeable de ce document depuis le compte enseignant | Permettre à chaque enseignant de transmettre cette analyse à sa direction | À construire |
En l'absence de délégué à la protection des données désigné (non obligatoire pour une micro-entreprise de cette taille), cette analyse est validée par l'éditeur lui-même, avec l'intention de la faire relire par un délégué à la protection des données ou un conseil externe, et de la mettre à jour à chaque évolution significative du traitement — au minimum une fois par an.
Version 3 (6 septembre 2026) : ajout des fonctionnalités coopérative scolaire, périscolaire, cahier journal partagé et transcription locale de réunions ; liste complète des sous-traitants ultérieurs ; durées de conservation chiffrées et bornées ; pseudonymisation élargie avant envoi à l'IA (dictionnaire INSEE, civilité, dates de naissance) ; retrait du prestataire Google / Gemini ; § 2.2 sur les données particulières (art. 9) ; procédure de violation de données ; information des familles ; DPA signés / archivés avec les sous-traitants, journalisation des appels API OpenAI désactivée, demande de Zero Data Retention déposée.
Version 3.1 (7 septembre 2026) : ajout de la constitution collaborative des classes — les enseignants d'un même niveau mettent en commun, le temps d'une session rejoignable par code, les seules données utiles (prénom, nom, genre, mois de naissance, niveau par domaine) pour préparer la répartition de l'année suivante ; la répartition est proposée, l'affectation finale reste une décision de l'équipe ; session purgée automatiquement au bout de 60 jours ; aucune donnée de comportement ni de santé.
Version 3.2 (8 septembre 2026) : ajout de l'import d'une liste de classe par photo ou PDF (export administratif type ONDE). L'image est transmise ponctuellement à Mistral AI (UE, pas d'entraînement sur les données) pour en extraire prénom, nom, date de naissance et genre ; elle n'est pas conservée. Le résultat est présenté dans un tableau que l'enseignant vérifie et corrige avant toute création d'élève — aucune création automatique. Les mêmes données restent saisissables à la main ou par collage depuis un tableur, sans IA. C'est, à ce jour, la seule opération où des noms d'élèves sont transmis à l'IA sans pseudonymisation — impossible par nature ici — ; les § 1.2 et 2.1 (minimisation) en précisent les mesures compensatoires, et le modèle d'information aux familles a été mis à jour en conséquence.
Version 3.3 (8 septembre 2026) : la répartition collaborative des classes prend désormais en compte la charge « besoins éducatifs particuliers » comme critère d'équilibrage — pour éviter de concentrer les élèves suivis (PAP, PPRE, PPS, AESH…) dans une même classe. La donnée partagée dans la session est un unique repère agrégé par élève (aucun / léger / lourd), calculé localement depuis les dispositifs du profil ; le type de dispositif, les données de santé et le comportement ne sont jamais transmis ni partagés, et l'enseignant peut ajuster ce repère. Aucun traitement par IA. Session toujours purgée automatiquement au bout de 60 jours.
Version 3.4 (18 septembre 2026) : OpenAI a précisé que la non-conservation (Zero Data Retention) n'est proposée qu'aux comptes entreprise ; la rétention anti-abus de 30 jours — encadrée par le DPA, le Data Privacy Framework et la désactivation de la journalisation des appels API — est donc actée comme mesure définitive. Rappel : la responsabilité de ne pas transmettre de données personnelles d'enfants de moins de 13 ans, et de recueillir le cas échéant le consentement parental, incombe à la plateforme éducative ; elle est assurée ici par la pseudonymisation systématique avant tout envoi de contenu rédigé à l'IA (seule exception documentée : l'import d'une liste de classe, § 1.2). Harmonisation du vocabulaire : « pseudonymisation » plutôt que « anonymisation » là où la correspondance avec les vrais noms subsiste localement.
Version 3.5 (26 septembre 2026) : ajout de la préparation des PPRE et des PAP et de leur report dans le Livret de parcours inclusif (§ 1.2, 2.1, 2.2, 2.4) — fiche des élèves à besoins éducatifs particuliers (EBEP) alignée sur les listes officielles fermées du LPI ; « Décrire l'élève » (classement par Mistral AI, UE, d'une description pseudonymisée et sans diagnostic, jamais conservée) ; proposition d'objectifs de PPRE (Mistral AI, UE, sans donnée identifiante) ; brouillons purgés chaque 1er septembre ; avis médical du PAP jamais transmis. Ajout de l'Extension Komen'Rtard (LSU et LPI), qui n'était pas encore décrite dans cette analyse : données transmises au seul navigateur de l'enseignant, permission limitée à l'onglet actif, plus aucune copie des données d'élèves conservée sur le disque. Sécurité : le 25 septembre 2026, deux règles d'accès trop larges ont été découvertes et corrigées le jour même — les réunions de la fiche EBEP et les appréciations de comportement pouvaient être lues ou modifiées par tout enseignant connecté (inscription réservée aux adresses académiques), et non par le seul enseignant de l'élève, au moyen d'un appel direct au serveur (l'application n'affichait à chacun que ses propres élèves). Les lignes présentes étaient des saisies d'essai de l'éditeur et d'une enseignante testeuse, qui en a été informée. Une appréciation de comportement ne contient ni nom ni prénom : seulement un identifiant technique d'élève, dont la correspondance avec l'élève est restée protégée, et des libellés choisis dans une liste fermée. L'incident est consigné au registre interne. Le même jour, les fonctions serveur d'IA ont été réservées aux utilisateurs connectés.
Version 3.6 (3 octobre 2026) : ajout des traitements mis en ligne depuis la version 3.5 et qui n'étaient pas encore décrits — Météo de la semaine (comportement au quotidien en listes fermées, sans IA, effacée chaque 1er septembre ; elle pré-remplit l'« attitude » du livret, que l'enseignant peut changer) ; espace Direction (école rejointe avec consentement, fonctions serveur limitées aux colonnes nécessaires, répartition des AESH en prénom et initiale sans diagnostic, absences sans motif, PAI sans aucune donnée enregistrée, aide IA au projet d'école sur des textes débarrassés des noms) ; espace Brigade pour les remplaçants (étiquettes « PAI » ou « allergie » sans détail, effacées chaque 1er septembre) ; demande d'aide au RASED (Mistral AI, UE, notes sans identité, fiche remplie produite sur l'appareil et non conservée) ; rendez-vous avec les familles, en ligne depuis le 18 septembre (sans compte, purge 30 jours après la dernière date) ; financement par une collectivité ; e-mail de bienvenue, parrainage et canal d'arrivée. Retrait de « Décrire l'élève » : plus aucune description d'élève n'est envoyée à l'IA pour remplir la fiche EBEP, désormais remplie par le Portrait de l'élève, sans IA. Correction du modèle d'information aux familles, qui situait à tort tous les services d'IA dans l'Union européenne. Sécurité : le 2 octobre 2026, une règle d'accès trop large a été découverte sur la fiche EBEP et le profil de l'élève, rangés par identité (nom, prénom, année de naissance) : un compte ayant dans sa classe un élève de même identité, quelle que soit son école, pouvait lire ou modifier la fiche de l'autre enfant par un appel direct au serveur. Vérification faite sur la base réelle, aucune fiche n'était visible de deux comptes. La règle a été restreinte avant la publication de cette version : il faut désormais avoir l'élève dans sa classe et être le propriétaire de la fiche ou un collègue actif de la même école. L'incident est consigné au registre interne.
Consultation préalable de la CNIL (art. 36). Après application des mesures, aucun risque résiduel n'atteint un niveau élevé (gravité au plus « Importante », vraisemblance au plus « Limitée »). Une consultation préalable de la CNIL au titre de l'article 36 du RGPD n'est donc pas requise. L'éditeur tient la présente analyse à la disposition de la CNIL et la met à jour à chaque évolution significative du traitement.
Décision : Validée, avec plan d'amélioration continue