Protéger un compte enseignant : double authentification, poste partagé, et un audit mené contre nous-mêmes

En avril 2026, la brèche EduConnect a exposé les données de plus de 3,5 millions d'élèves français : noms, établissements, classes, codes d'activation. Presque tous mineurs. Le point d'entrée n'avait rien d'exotique. C'étaient les identifiants d'un compte de personnel habilité, sans second facteur d'authentification.

C'était la troisième brèche en six mois. En mars, COMPAS exposait les données d'environ 243 000 agents, numéros de sécurité sociale compris. En juillet, c'était au tour du système d'information de la formation des personnels.

En faire le procès de l'institution serait manquer ce que ces trois épisodes ont en commun, et qui vaut pour tout éditeur, nous compris : ce n'est pas le système qui a cédé, c'est un compte.

Un compte enseignant n'est pas un compte comme un autre. Il ouvre sur des élèves nommés, leurs copies, leurs notes, leurs difficultés, parfois leurs aménagements. Dans un outil comme EvalIA, c'est le point où la donnée d'élève est la plus dense. Cet article détaille ce que nous avons changé début août 2026, ce que ces mesures protègent, et ce qu'elles ne protègent pas.

1. La double authentification, et pourquoi elle est vérifiée avant le jeton

Depuis le 2 août 2026, chaque enseignant peut activer un second facteur sur son compte, dans Paramètres, section Sécurité. Le principe est classique : une application d'authentification affiche un code à six chiffres qui change toutes les trente secondes, et ce code est demandé à la connexion.

Trois choix de conception comptent plus que l'annonce elle-même.

Le facteur vit dans l'authentification, pas dans notre interface

Il aurait été plus simple d'afficher un écran « entrez votre code » après la connexion. Ç'aurait été du théâtre. Un écran applicatif se contourne : il suffit d'appeler directement les interfaces de programmation avec le jeton déjà émis, et l'écran n'a jamais existé.

Chez nous, le code est vérifié par le fournisseur d'identité avant l'émission du jeton de connexion. Sans second facteur validé, il n'y a pas de jeton, donc aucune requête possible, sur aucune route, dans aucune des deux applications de l'écosystème (EvalIA et OrIAntation partagent le même compte). La protection ne dépend pas de notre vigilance route par route : elle est en amont de tout.

Aucun numéro de téléphone

Nous n'avons pas retenu le code par SMS, pour deux raisons. La première est de sécurité : l'interception de SMS et l'échange de carte SIM sont des attaques documentées, et le NIST classe l'authentification par SMS parmi les mécanismes à usage restreint dans sa publication SP 800-63B. L'ANSSI recommande de la même façon les applications d'authentification plutôt que le SMS.

La seconde est une raison de principe : un numéro de téléphone est une donnée personnelle supplémentaire. En choisissant l'application d'authentification, nous ajoutons un facteur de sécurité sans collecter la moindre donnée en plus. Le secret ne transite jamais par nos serveurs et n'est stocké nulle part chez nous. Pour beaucoup d'enseignants, il n'y a même pas d'application à installer : les gestionnaires de mots de passe courants génèrent ces codes eux-mêmes.

Le code n'est demandé qu'aux nouvelles connexions

Une sécurité pénible finit désactivée. C'est la règle la plus constante du domaine, et elle explique une partie des dispositifs abandonnés en cours de route. Grâce à la session persistante, un enseignant qui a activé le second facteur ne voit le code qu'à une vraie nouvelle connexion : nouvel appareil, nouveau navigateur, ou après une déconnexion. Au quotidien, rien ne change.

L'activation est volontaire. Nous ne l'imposons pas, et un compte qui ne l'active pas conserve exactement le fonctionnement d'avant. Si vous perdez votre téléphone, écrivez-nous : nous vérifions votre identité sur l'adresse de courriel du compte avant de retirer le second facteur, avec un délai. Personne ne fait sauter un second facteur sur simple demande écrite.

2. Le cas qu'on oublie toujours : la session laissée ouverte

Un second facteur protège la connexion. Il ne protège pas une session déjà ouverte. Or, en établissement, c'est probablement la menace la plus fréquente, et la moins sophistiquée : un poste de la salle des profs, une session non fermée, un couloir, deux minutes.

Nous avons donc lié la déconnexion automatique à un réglage que vous connaissez déjà : la case « Rester connecté sur cet appareil », au moment de vous connecter.

Case	Ce que ça veut dire	Conséquence
Cochée (par défaut)	« c'est mon ordinateur »	La session est conservée, aucune déconnexion sur inactivité
Décochée	« poste partagé »	La session meurt à la fermeture du navigateur, et se ferme après 30 minutes d'inactivité, avec un avertissement une minute avant

Le minuteur se réarme à chaque interaction : un enseignant qui travaille ne le verra jamais. Il ne se déclenche que si la personne s'est éloignée. C'est une mesure d'hygiène contre l'accès physique opportuniste, pas une frontière cryptographique, et nous la présentons comme telle.

Dans le même mouvement, la longueur minimale du mot de passe à l'inscription est passée à huit caractères, côté navigateur comme côté serveur.

3. L'audit : nous mettre à la place d'un compte volé

Activer un second facteur réduit la probabilité qu'un compte soit usurpé. Cela ne dit rien de ce qui se passerait si l'un d'eux l'était. Nous avons donc posé la question à l'envers : avec un compte enseignant valide en main, jusqu'où peut-on aller ? Peut-on lire les élèves d'un autre professeur ? Aspirer la base ?

L'audit a passé au crible les règles d'accès de la base de données et une centaine de routes serveur.

Ce qui a tenu. La lecture s'est révélée étanche. Les règles sont cadrées sur l'identifiant du propriétaire aussi bien pour lire un document que pour en lister ; les collections les plus sensibles (dépôts de copies, progressions, cercles d'équipe, ressources publiées) sont inaccessibles depuis le navigateur et ne transitent que par le serveur. Surtout, un enseignant ne peut pas lister les élèves : il n'existe pas de requête qui les énumère, et les identifiants sont aléatoires, donc non devinables. Il n'y a pas de chemin vers une aspiration de masse.

Ce qui n'a pas tenu. L'audit a trouvé un défaut réel, en écriture et sans fuite de données. Sur une route de recalcul, un enseignant qui connaissait l'identifiant d'une correction appartenant à un collègue pouvait déclencher une mise à jour du profil d'un élève qui n'était pas le sien, et fausser sa moyenne calculée. Rien ne pouvait être lu : cette route ne renvoie aucune donnée. Il s'agissait d'une altération ciblée, exigeant un identifiant de 122 bits impossible à deviner, et réparable par un simple recalcul. Le correctif a été écrit et déployé le jour même. Dans la foulée, cinq autres routes qui faisaient une confiance implicite comparable ont été durcies, et un test automatisé garde désormais ce comportement.

Nous aurions pu ne rien en dire. Ce défaut n'a jamais été exploité, et personne n'en aurait rien su.

Nous le disons parce qu'un audit qui ne trouve rien ne prouve qu'une chose : qu'il a mal cherché. Nous préférons publier une méthode et un résultat plutôt qu'un badge de confiance. C'est la même règle que nous appliquons à nos choix d'infrastructure et à ce que nous faisons des données de vos élèves.

4. Ce que tout cela ne protège pas

Trois limites, nommées.

Le second facteur reste facultatif. Tant qu'il n'est pas activé, un compte est protégé par son seul mot de passe. Nous n'imposons pas l'activation : nous préférons une adoption réelle à une obligation contournée. C'est un arbitrage, et il pourra être revu.

Un code à usage unique ne neutralise pas tout l'hameçonnage. Les attaques les plus élaborées relaient le code en temps réel vers le vrai site. La parade s'appelle les clés d'accès, qui lient la connexion au domaine visité et rendent l'attaque inopérante. Notre fournisseur d'identité ne les prend pas encore en charge ; nous suivons le sujet et basculerons dès que ce sera possible.

Un point moyen reste ouvert. Notre limitation du nombre de tentatives vit en mémoire de processus : elle se réinitialise quand l'infrastructure redémarre une instance. Cela n'ouvre aucun accès aux données d'autrui, mais cela affaiblit la protection contre les tentatives répétées sur les codes courts. Le correctif est identifié, il n'est pas encore fait, et nous le disons.

5. Activer la double authentification, en une minute

1. Ouvrez Paramètres, puis la section Sécurité.
2. Cliquez sur Activer la double authentification et saisissez votre mot de passe.
3. Scannez le code affiché avec votre application d'authentification, ou collez la clé dans votre gestionnaire de mots de passe.
4. Saisissez le code à six chiffres pour confirmer.

C'est terminé. Vous ne reverrez ce code qu'à votre prochaine connexion depuis un nouvel appareil.

Une dernière chose, si vous travaillez sur un poste partagé : décochez « Rester connecté sur cet appareil » quand vous vous connectez. Le geste prend une seconde et ferme la porte que le second facteur, lui, ne ferme pas.