Ce que FERPA exige réellement d’une plateforme edtech

La mention « conforme à FERPA » apparaît sur presque tous les sites edtech, généralement à côté d’un petit bouclier. C’est aussi l’une des affirmations les plus mal comprises du secteur. On la présente comme un label que l’on obtient et affiche. Ce n’en est pas un. Il n’existe ni certificat FERPA, ni audit public qui approuve votre produit, ni organisme qui vous écrira un jour : « vous êtes désormais conforme à FERPA ».

Une fois le marketing écarté, FERPA est un ensemble d’obligations qui partent des établissements scolaires et se retrouvent dans les contrats qu’ils signent et les systèmes qu’ils achètent. Si vous développez ou vendez un logiciel éducatif qui traite des données étudiantes aux États-Unis, ces obligations deviennent des choix d’architecture et des clauses contractuelles, que vous les ayez anticipées ou non. Cet article explique ce que la loi demande réellement, pourquoi un fournisseur peut traiter des dossiers étudiants, ce qu’il doit construire pour respecter sa part du contrat et quelles autres lois s’appliquent aux mêmes données. Il s’agit d’un guide pratique, pas d’un avis juridique : faites confirmer vos obligations particulières par un conseil compétent.

FERPA en un paragraphe

FERPA, le Family Educational Rights and Privacy Act, est une loi fédérale américaine de 1974 qui protège la confidentialité des dossiers scolaires. Elle s’applique aux écoles, districts, universités et établissements d’enseignement supérieur qui reçoivent des fonds du département américain de l’Éducation, c’est-à-dire presque tous. Elle donne aux parents — puis aux étudiants à partir de 18 ans ou dès leur entrée dans l’enseignement supérieur — le droit de consulter leur dossier, d’en demander la correction et de contrôler qui d’autre peut y accéder. Un « dossier scolaire » désigne largement tout document qui identifie directement un étudiant et que l’établissement, ou un tiers agissant pour son compte, conserve.

Les mots importants sont « agissant pour son compte ». FERPA lie l’établissement, pas directement votre entreprise. Mais dès qu’un établissement vous confie des données pour faire fonctionner sa plateforme, vous agissez pour son compte. Par le contrat que vous signez, ses obligations deviennent alors votre problème.

Une affirmation qui, seule, ne veut rien dire

Comme il n’existe aucune certification, « logiciel conforme à FERPA » exprime une intention, pas un fait vérifié. Personne n’attribue ce statut. Cela compte pour l’acheteur comme pour le fournisseur.

Si vous achetez, cette formule vous apprend très peu. Les questions utiles sont précises : que deviennent les données, qui peut y accéder, combien de temps sont-elles conservées et le fournisseur signera-t-il un véritable accord qui l’engage par écrit ? Un éditeur qui s’abrite derrière le badge sans répondre vous donne malgré tout une information précieuse.

Si vous construisez, la même règle vaut pour votre marketing. Revendiquer la conformité est facile. La rendre défendable grâce aux contrôles d’accès, règles de conservation, journaux et engagements contractuels est le vrai travail. La promesse ne vaut que ce que l’architecture qui la soutient permet de tenir.

Pourquoi un fournisseur peut-il traiter des données étudiantes ?

C’est le point que beaucoup ratent. FERPA interdit en principe à un établissement de communiquer le dossier d’un étudiant sans consentement. Comment des milliers de fournisseurs edtech peuvent-ils alors traiter ces données chaque jour sans recueillir un formulaire signé pour chaque enfant ? Grâce à une exception précise appelée school official exception, l’exception du responsable scolaire.

Un établissement peut considérer un prestataire externe comme un « responsable scolaire » ayant un « intérêt éducatif légitime » et lui transmettre des dossiers sans consentement distinct, mais uniquement à certaines conditions :

• Le fournisseur accomplit une tâche que l’établissement aurait autrement assurée lui-même. Exploiter la plateforme d’apprentissage en fait partie. Vendre de la publicité, non.
• Le fournisseur est placé sous le contrôle direct de l’établissement pour l’utilisation et la conservation des dossiers. En pratique, le contrat établit ce contrôle.
• Le fournisseur utilise les données uniquement aux fins autorisées et ne les transmet à personne d’autre sans permission.

Le troisième point est le plus sensible. Les données confiées pour dispenser des cours ne peuvent pas discrètement servir à entraîner un modèle sans rapport, être vendues à un partenaire ou alimenter des profils publicitaires. L’exception qui vous autorise à les détenir limite aussi strictement ce que vous pouvez en faire. Dépassez cette limite : l’établissement enfreint FERPA, tandis que vous rompez votre contrat et mettez votre réputation en jeu.

Ce que FERPA vous demande réellement de construire

Lorsque vous traitez des dossiers dans ce cadre, les droits accordés aux familles se traduisent en fonctions et contrôles que votre plateforme doit prendre en charge. Rien d’exotique, mais beaucoup sont oubliés tant qu’un client ne les réclame pas.

Deux éléments méritent une attention particulière. La journalisation des accès est souvent repoussée et regrettée ensuite : sans elle, impossible d’enquêter sérieusement sur une fuite présumée ou de prouver ce qui s’est passé. La suppression réelle est plus difficile qu’il n’y paraît, car les données se propagent dans les sauvegardes, les outils d’analyse et les services tiers. Tous doivent faire partie du processus. Ce sont les mêmes capacités architecturales qui vous protègent au quotidien ; d’où le lien direct avec la liste de contrôle pour la sécurité des données étudiantes et la leçon tirée de la faille Canvas, où le problème venait moins d’un piratage sophistiqué que d’un contrôle d’accès ordinaire à grande échelle.

FERPA n’est pas la seule loi concernée

Construire uniquement pour FERPA ne suffit pas. Plusieurs textes s’appliquent souvent simultanément aux mêmes données. Voici les trois que vous rencontrerez le plus.

Pour les éditeurs américains, la colonne des lois d’État est souvent la surprise. FERPA engage l’établissement et vous atteint par le contrat. Des textes comme la SOPIPA californienne réglementent directement le fournisseur : pas de vente de données étudiantes, pas de publicité ciblée, pas de profilage à d’autres fins que la mission éducative. De nombreux États ont désormais leur propre version. Une plateforme présente dans plusieurs États finit, en pratique, par se conformer à la règle la plus stricte.

Le document qui fixe réellement les règles

En l’absence de certificat, vos obligations sont précisées par un contrat, généralement un Data Privacy Agreement, ou DPA, parfois appelé accord de confidentialité des données étudiantes. Le service achats ou juridique de l’établissement vous le soumettra. C’est là que la loi abstraite devient une série d’engagements concrets : quelles données vous recevez, ce que vous pouvez en faire, comment vous les protégez, combien de temps vous les gardez, ce qui se passe en cas d’incident et comment elles sont supprimées à la fin de la relation.

Aux États-Unis, de nombreux districts utilisent des modèles communs publiés par le Student Data Privacy Consortium, afin que les écoles et les fournisseurs ne renégocient pas les mêmes clauses à chaque fois. Si vous vendez aux établissements, attendez-vous à signer l’un de ces accords et à vous engager sur les contrôles décrits ci-dessus. Lire attentivement un DPA standard est, honnêtement, l’un des moyens les plus rapides de comprendre ce que « conforme à FERPA » signifie en pratique : les vraies exigences y figurent dans un langage contractuel direct.

Ce que la « conformité » apporte — et n’apporte pas

Respecter ces obligations a une valeur réelle. Vous réduisez votre exposition juridique et réputationnelle, et vous passez les achats. Pour qui vend aux écoles, cela fait souvent la différence entre signer et échouer lors de l’évaluation de sécurité. C’est de plus en plus un prérequis : le questionnaire arrive tôt, et le fournisseur incapable d’y répondre est écarté avant même la démonstration.

En revanche, il n’existe pas de ligne d’arrivée. La conformité n’est pas un badge obtenu une fois pour toutes, mais un ensemble d’engagements permanents, inscrits dans les contrats et appliqués par le comportement quotidien de la plateforme. Chaque nouvelle fonction, chaque nouveau sous-traitant et chaque nouveau flux de données peut rompre une promesse faite dans un DPA. Les équipes responsables traitent la confidentialité comme la sécurité et l’accessibilité : une propriété durable du système, pas un projet ponctuel. Ces obligations vont souvent de pair, ce qui place naturellement FERPA à côté de ce que WCAG 2.2 AA exige d’une plateforme d’apprentissage.

Le fil conducteur est le même pour la sécurité et l’accessibilité. Les obligations qui protègent les étudiants — et votre entreprise — se traduisent par des décisions d’architecture et de contrat prises tôt, quand elles restent peu coûteuses à honorer. FERPA n’est pas un autocollant dans le pied de page. C’est une promesse sur la façon dont votre système est construit et se comporte. La seule version qui compte est celle que votre plateforme peut réellement tenir.