Outil de code conforme RGPD pour l'école : comment choisir

Pourquoi le RGPD concerne directement le choix d'un outil de code en classe ?

Apprendre le code à l'école est inscrit au programme du cycle 3 et séduit de plus en plus d'enseignants. Mais dès qu'un outil numérique fait travailler une classe entière, il manipule des données d'enfants : prénoms, parfois noms, identifiants de connexion, progression, productions. À l'école, ce n'est pas un détail technique, c'est une responsabilité juridique encadrée par le Règlement général sur la protection des données (RGPD).

La grande différence avec un usage familial, c'est l'échelle et la responsabilité. Un parent décide pour son enfant ; un enseignant décide pour vingt-cinq élèves dont les parents n'ont pas tous donné leur avis. En France, le responsable du traitement à l'école, c'est l'établissement (le chef d'établissement dans le second degré, la commune ou le DASEN pour le premier degré). L'enseignant propose un outil, mais la conformité se valide à un autre niveau. Choisir un outil RGPD by design simplifie énormément cette chaîne de responsabilité.

Quels critères pour un outil numérique RGPD à l'école ?

Inutile de devenir juriste : quelques critères concrets permettent d'écarter rapidement les outils les moins fiables. L'idée est de privilégier des solutions qui protègent les élèves par défaut, sans que vous ayez à régler manuellement chaque paramètre de confidentialité pour chaque enfant.

Voici les points à vérifier avant d'adopter une application de code pour votre classe :

• Minimisation des données : l'outil ne demande que ce qui est utile à l'apprentissage, pas la date de naissance complète ni l'e-mail de chaque élève.
• Connexion sans e-mail enfant : un identifiant et un code valent mieux qu'une adresse e-mail personnelle pour des mineurs.
• Hébergement en Europe : les données restent soumises au RGPD et ne partent pas vers des serveurs hors UE sans garanties.
• Aucune publicité ni achat intégré exposé aux élèves dans l'interface de classe.
• Politique de confidentialité claire : finalités, durée de conservation et sous-traitants explicitement listés.
• IA encadrée : si un tuteur IA accompagne l'enfant, il ne doit pas recevoir son identité (prénom, nom).
• Documentation fournie : l'éditeur met à disposition les informations nécessaires pour le registre des traitements.

Quelles obligations RGPD pour l'enseignant et l'établissement ?

Le RGPD ne demande pas à l'enseignant de tout porter seul, mais il fixe quelques principes incontournables. Le traitement des données d'élèves doit avoir une base légale (souvent la mission de service public de l'éducation), être limité à sa finalité pédagogique, et respecter la minimisation. Les familles doivent être informées des outils utilisés et des données traitées.

Concrètement, l'établissement tient un registre des traitements qui recense les outils numériques et les données qu'ils manipulent. Chaque académie dispose d'un délégué à la protection des données (DPO/DPD) qui peut conseiller en cas de doute. Avant de généraliser un outil, le réflexe sûr est de vérifier qu'il figure parmi les solutions validées localement, ou d'en parler au chef d'établissement et au DPD académique.

• Vérifier la base légale et la finalité strictement pédagogique du traitement.
• Informer les familles des outils numériques utilisés en classe.
• Faire inscrire l'outil au registre des traitements de l'établissement.
• Solliciter le délégué à la protection des données (DPD) de l'académie en cas de doute.
• Conserver les comptes élèves le temps de l'usage, puis demander leur suppression.

Comment vérifier concrètement la conformité d'une application de code ?

Avant d'inscrire toute une classe, prenez dix minutes pour ouvrir la politique de confidentialité de l'outil. Si elle est introuvable, illisible ou rédigée uniquement en anglais juridique, c'est déjà un signal. Une application sérieuse explique en langage clair quelles données elle collecte, pourquoi, combien de temps elle les garde et avec qui elle les partage.

Testez aussi le parcours d'inscription d'un élève fictif : observez si l'outil exige un e-mail enfant, une géolocalisation ou des informations sans rapport avec l'apprentissage. Vérifiez enfin la présence de publicités, de trackers ou de boutons de partage vers les réseaux sociaux dans l'interface élève. Un bon outil scolaire est sobre, sans distraction commerciale, et conçu pour l'usage en classe.

Un exemple d'approche RGPD by design pour le code : Early Eyes

On peut très bien apprendre à coder sans exposer l'identité des enfants. C'est le parti pris d'Early Eyes, une application française qui enseigne le code aux enfants de 8 à 12 ans avec la méthode du code-dessin (façon tortue Logo) : l'enfant écrit du vrai code qui dessine à l'écran et voit immédiatement le résultat. Sa conception illustre ce que veut dire « protéger les données dès la conception » (RGPD-K).

Plusieurs choix techniques limitent l'exposition des élèves. Les comptes enfants fonctionnent par identifiant et code, sans e-mail enfant. Le prénom n'est jamais envoyé au tuteur IA « Early », qui guide par indices progressifs sans avoir besoin d'identifier l'utilisateur. L'application est française, hébergée dans le respect du RGPD, et intègre des réglages d'accessibilité DYS (polices adaptées, confort de lecture) utiles en classe hétérogène. Le modèle freemium permet de démarrer gratuitement avant tout engagement. C'est un exemple parmi d'autres, mais il montre qu'apprendre et préserver la vie privée des élèves ne s'opposent pas.

Quelles alternatives et quels points de vigilance selon les outils ?

Beaucoup d'enseignants utilisent des outils populaires comme Scratch, Code.org ou d'autres plateformes de code. Plusieurs sont de grande qualité pédagogique, mais leur conformité dépend de la configuration : un compte créé sans données identifiantes n'expose presque rien, tandis qu'un compte lié à l'e-mail réel d'un élève ou hébergé hors Europe demande davantage de précautions. Le critère n'est donc pas la notoriété de l'outil, mais la façon dont il traite les données.

Le point de vigilance le plus fréquent concerne l'hébergement hors Union européenne et les outils tiers intégrés (statistiques, publicité, IA externe). Quand c'est possible, préférez une version « éducation » ou « classe » de l'outil, souvent plus protectrice que la version grand public, et évitez de demander aux élèves de saisir des informations personnelles dans des champs libres ou des chats.

• Privilégier les versions « école » ou « classe » des outils, généralement mieux encadrées.
• Éviter les comptes liés à l'e-mail réel ou au nom complet des élèves.
• Se méfier des outils tiers intégrés (pub, analytics, IA externe) et de l'hébergement hors UE.
• Interdire la saisie d'informations personnelles dans des champs libres ou des chats.
• Comparer la politique de confidentialité plutôt que la seule réputation de l'outil.

Comment associer les familles et sécuriser l'usage en classe ?

La transparence envers les familles est à la fois une obligation et un gage de confiance. Une courte note d'information dans le cahier de liaison ou l'ENT suffit souvent : nom de l'outil, objectif pédagogique, données traitées, hébergement et durée de conservation. Cela évite les malentendus et associe les parents à la démarche numérique de la classe.

Côté usage quotidien, quelques gestes simples réduisent les risques : créer des comptes élèves avec un prénom seul ou un pseudonyme plutôt qu'un nom complet, ne pas réutiliser les mots de passe d'une année sur l'autre, et supprimer les comptes en fin d'année si l'outil le permet. Le principe de minimisation s'applique en classe comme ailleurs : moins on collecte, moins on expose.

Les critères d'un outil de code conforme RGPD