La confiance se vérifie.
LAURA est un assistant de correction, conçu selon le RGPD : l’IA propose, l’enseignant décide, et chaque décision est justifiable. Cette page montre à quoi les directions d’école, les collectivités et les délégués à la protection des données peuvent le vérifier.
Les cinq piliers de vérification
Chaque pilier renvoie à sa preuve : décision d’architecture (ADR) ou code vérifiable. Aucune affirmation marketing sans fondement.
Teacher Final Decision
LAURA n’attribue aucune note automatique. Chaque évaluation est une proposition, qui ne devient définitive que par la validation explicite de l’enseignant. Cette étape est imposée par l’architecture, ce n’est pas une case à cocher dans les réglages.
Preuve : ADR-0012 ; proposition de note déterministe et modifiable (implémentée et testée).
Piste d’audit à chaîne de hachage
Chaque décision est journalisée en append-only et chaînée cryptographiquement par SHA-256. Les manipulations ne sont pas réparées en silence, elles sont rendues visibles : l’historique est vérifiable de façon indépendante.
Preuve : ADR-0019 ; vérification dans apps/worker/audit/verify.py (implémentée et testée).
Résidence des données en UE
Toutes les métadonnées et tous les résultats de traitement se trouvent dans un projet de base de données dédié à Francfort (eu-central-1). Row-Level-Security sur chaque table ; l’école est la frontière stricte entre les locataires.
Preuve : DEC-019/ADR-0026, ADR-0031 ; RLS sur chaque table, imposée pour les nouvelles par le déclencheur d’événement ensure_rls (déployée).
Local-first, traitement contrôlé
Les médias bruts (photos, scans) restent par défaut en local ou dans un espace de stockage contrôlé par l’école. C’est toi qui choisis le niveau : au niveau local, celui par défaut, le serveur refuse activement tout envoi, et avec la formule Hébergement local, Laura tourne entièrement sur tes propres serveurs. Le traitement dans le cloud n’a lieu qu’après validation explicite (opt-in) : jamais en silence, jamais par défaut.
Preuve : ADR-0013/0016/0033 ; matrice processing_mode documentée (local est la valeur par défaut).
Transparence plutôt que pistage caché
Aucun traceur publicitaire, aucun scan caché des appareils des élèves : c’est ancré dans l’architecture. Depuis le 13 août 2026, le site public ne collecte plus aucune statistique de fréquentation : l’ancienne balise Google Analytics a été retirée définitivement. Elle figurait sur 183 pages, coûtait 471 ms de chargement par visite et ne collectait aucune donnée, car le consentement ne pouvait structurellement jamais être donné. L’environnement de correction n’a jamais eu de traceur, et les données d’élèves ou de copies n’ont jamais été concernées. Le composant de consentement reste volontairement dans le code : si les statistiques reviennent un jour, elles ne reviendront qu’avec une bannière visible et une section dédiée dans la politique de confidentialité.
Preuve : ADR-0018 (scan des appareils), ADR-0022 (bacs à sable sans backend), DEC-056/ADR-0071 (aucune statistique web) ; le couplage est imposé par le test de non-régression no-analytics-without-consent.
Flux de données rendus transparents
Trois zones de confiance, nettement séparées. Ce qui se trouve où n’est pas une question de confiance, mais d’architecture.
Zone publique
Vercel : uniquement le frontend web statique (apps/web)
Aucune donnée d’élève, aucun secret, aucun backend, aucun worker.
Zone contrôlée
Base de données UE (Francfort) et traitement contrôlé
Identifiants pseudonymes, métadonnées d’évaluation et d’audit, protégés par l’authentification et Row-Level-Security.
Zone locale
Appareil de l’enseignant / stockage contrôlé par l’école
Médias bruts et table de correspondance des noms réels. Ne quittent l’appareil qu’après validation explicite.
Classes de données en bref (K1-K6)
| Classe | Contenu | Où elle vit |
|---|---|---|
| K1 | Médias bruts (scans, photos) | local / contrôlé par l’école, jamais public |
| K2 | PII élevé (noms réels) | local, correspondance chiffrée, jamais dans le cloud |
| K3 | Métadonnées + pseudonymes | base de données UE, protégée par RLS |
| K4 | Audit / hachages | base de données UE, append-only |
| K5 | Synthétique / public | site web, démos, exclusivement synthétique |
| K6 | Configuration système + secrets | coffre à secrets, jamais dans le frontend, jamais dans Git |
Documents pour ton examen
Le statut de chaque document est indiqué honnêtement. Nous ne listons les certifications qu’une fois obtenues : jusque-là, il n’y en a aucune ici.
Modèle de contrat de sous-traitance
Contrat de sous-traitance au sens de l’art. 28 RGPD pour les écoles et les collectivités.
Aperçu des MTO
Mesures techniques et organisationnelles (art. 32 RGPD).
Documentation des modes de traitement
Modes de traitement documentés (local par défaut / auto-hébergé UE / cloud en opt-in).
Extrait du registre des traitements
Extrait du registre des activités de traitement (art. 30 RGPD).
Guide AIPD
Guide de l’analyse d’impact relative à la protection des données (art. 35 RGPD) pour les écoles.
Concept de suppression
Mise en œuvre du droit à l’effacement (art. 17 RGPD), rétention des sauvegardes comprise.
Questions fréquentes de vérification
- LAURA note-t-elle automatiquement ?
- Non. LAURA n’attribue aucune note automatique. Chaque évaluation est une proposition faite à l’enseignant ; elle ne devient définitive que par sa validation explicite. Cette étape est imposée par l’architecture (Teacher Final Decision).
- Où se trouvent les données des élèves ?
- Les médias bruts (photos, scans) restent en local sur l’appareil ou dans un espace contrôlé par l’école. La base de données UE (Francfort) ne contient que des identifiants pseudonymes, des métadonnées d’évaluation et d’audit, protégés par Row-Level-Security avec l’école comme frontière stricte entre locataires. La correspondance des noms réels reste locale.
- Que voit le cloud ?
- Par défaut : aucun média brut. Le traitement dans le cloud est exclusivement en opt-in, puis limité au strict nécessaire (par exemple des extraits d’image des passages litigieux, pseudonymisés). Il n’existe pas d’escalade silencieuse vers le cloud : elle est exclue par l’architecture.
- Qu’est-ce que la chaîne de hachage ?
- Chaque décision de l’enseignant est chaînée à la précédente par un hachage SHA-256 et stockée en append-only. Toute modification ultérieure brise la chaîne de façon visible ; l’intégrité de tout l’historique peut être vérifiée de façon indépendante.
- LAURA est-elle conforme au RGPD ?
- LAURA est conçue selon le RGPD de bout en bout : protection des données dès la conception et par défaut (art. 25), minimisation des données (art. 5), résidence des données en UE, séparation des locataires par RLS, décisions auditables et modes de traitement documentés. Nous fournissons sur demande le modèle de contrat de sous-traitance et l’aperçu des MTO ; l’évaluation formelle revient à l’école ou à son DPO, et nous en fournissons les pièces.
Vérifie par toi-même au lieu de nous croire
Quatre petites démos à essayer, dont : régler toi-même les seuils de confiance, manipuler un journal d’audit et voir la vérification le détecter, et suivre la résolution d’un conflit entre deux appareils. Tout se passe dans ton navigateur, sans connexion à nos serveurs.
Bac à sable pour développeurs
Quatre démos interactives des algorithmes centraux de Laura. Tout fonctionne localement dans ton navigateur.
Confusion Matrix
Laura apprend de tes corrections. Tu vois ici comment les confusions les plus fréquentes diminuent.
- a→o18,0 %
- e→c14,0 %
- n→m21,0 %
- h→k9,0 %
- u→v11,0 %
Green Word Precision
Un contact direct pour tes questions de protection des données
Aucun formulaire obligatoire : un e-mail suffit. Nous répondons avec les documents demandés, et n’envoyons rien sans ta confirmation explicite (double opt-in).