Une isolation appliquée par la base de données, pas par le code applicatif.
Chaque requête qui modifie quelque chose est autorisée trois fois, à trois endroits qui échouent indépendamment. Derrière eux se trouvent 868 politiques de sécurité au niveau des lignes : une erreur dans un handler est donc un bug, pas une fuite de données. Cette page est écrite pour la personne qui doit nous valider.
Comment Lurno protège les données d'une organisation de celles d'une autre
Lurno autorise chaque requête modifiante à trois endroits indépendants. L'interface vérifie une permission avant d'afficher un contrôle. Le serveur exige la même permission avant de toucher aux données, et refuse si la réponse est non. La base de données applique une politique de sécurité au niveau des lignes qui décide quelles lignes la requête a le droit de renvoyer. Les trois doivent passer. Il existe 868 politiques de ce type réparties sur 676 migrations, et les tables applicatives vivent dans 14 schémas métier plutôt que dans le schéma public par défaut : les lignes d'une organisation restent donc hors d'atteinte depuis la session d'une autre organisation, même quand le code au-dessus est faux. Les modifications administratives sont écrites dans un journal d'audit en ajout seul, dont les lignes sont chaînées en SHA-256 et vérifiables par une requête. Augmental Learning Inc. est aligné sur les pratiques ISO 27001 ; l'entreprise ne détient ni certificat ISO 27001 ni rapport SOC 2, et nous le disons dans le questionnaire plutôt que de laisser un acheteur supposer le contraire.
- Autorisation à trois barrières
- Un modèle dans lequel une requête est autorisée trois fois, par trois mécanismes qui échouent indépendamment. La première barrière est l'interface : elle masque un contrôle pour lequel la personne connectée n'a aucune permission. La deuxième est le serveur : le handler exige la permission avant de toucher aux données et lève une erreur si la réponse est non. La troisième est la base de données : une politique de sécurité au niveau des lignes sur la table restreint les lignes que la requête peut renvoyer. La première barrière est un confort, la deuxième est la frontière principale, et la troisième est ce qui tient encore quand la deuxième a été contournée.
Trois barrières, et ce qu'il y a derrière chacune
Une requête, autorisée trois fois
Un contrôle de l'interface demande si la personne connectée détient une permission avant de s'afficher. Le handler côté serveur exige la même permission avant de faire quoi que ce soit. Puis la base de données applique une politique qui décide quelles lignes la requête peut voir. Trois mécanismes, trois endroits distincts où avoir raison, et il suffit que l'un dise non pour que la requête s'arrête.
- Le contrôle dans l'interface est un confort, pas une frontière. Il masque un bouton ; il ne protège pas une table.
- Chaque vérification passe par un seul catalogue de permissions et une seule fonction. Aucun handler ne lit un nom de rôle et ne décide seul de ce que ce rôle signifie.
- Un rôle attribué sur une branche de l'arborescence d'une organisation se propage le long de cette branche — et les politiques de la base de données lisent la même arborescence que l'interface, si bien que les deux ne peuvent pas diverger.
868 politiques réparties sur 676 migrations
L'isolation relève du schéma, pas de la convention. Les tables sont créées avec la sécurité au niveau des lignes activée et des politiques qui délèguent à la même fonction de permission que celle appelée par le serveur, et un contrôle de migration cherche les tables auxquelles un accès a été accordé sans politique derrière. Ce nombre n'est pas un argument marketing — c'est ce que renvoie la base de données quand on lui demande combien de politiques elle applique.
- Les politiques n'écrivent pas leur propre logique en ligne. Elles appellent la fonction de permission, si bien que la réponse ne peut pas diverger de ce que le serveur a décidé un instant plus tôt.
- Les politiques d'écriture portent une clause de vérification en plus de la clause de lecture : une insertion ne peut donc pas placer une ligne dans une organisation pour laquelle son auteur n'a aucune permission.
- Lorsqu'une vue expose des données personnelles, l'accès est accordé colonne par colonne. Un octroi sur toute la table annulerait discrètement la protection au niveau colonne : il n'est donc pas utilisé.
Quatorze schémas métier, jamais le schéma public
Les tables applicatives vivent dans quatorze schémas nommés — un pour l'identité et les accès, un pour les organisations, un pour les médias, et ainsi de suite. Rien de ce qui compte ne se trouve dans le schéma public par défaut, l'endroit où un octroi accidentel ou une valeur par défaut trop permissive risque le plus d'exposer des données. Les médias privés n'ont aucune politique de stockage pour les navigateurs connectés : chaque lecture est signée par un serveur qui a d'abord vérifié la ligne propriétaire, et chaque dépôt est émis de la même manière.
- Les jetons à usage unique — invitations, réinitialisations de mot de passe, récupération de compte — sont stockés sous forme de hachages salés. Le jeton brut est affiché une seule fois, dans l'e-mail, et jamais plus.
- Seule la marque est publique. Le logo et la favicon d'une organisation doivent s'afficher avant toute connexion ; les avatars et les médias de leçon, non : ils restent signés.
Prouver après coup ce qui s'est passé
Un journal d'audit que personne ne peut vérifier n'est qu'un fichier de log mieux vendu. Celui-ci est en ajout seul et révèle toute falsification, et le vérifier tient en une requête.
Un journal en ajout seul
Les modifications administratives sont écrites sous forme d'événements portant l'acteur, l'action, la ressource, l'organisation et un contenu avant/après. Rien ne met à jour une ligne d'audit. Le chemin d'écriture ne fait qu'ajouter.
Une chaîne de hachage SHA-256
Chaque événement stocke le hachage du précédent et un hachage de lui-même, tous deux attribués par un déclencheur de base de données plutôt que par le code qui a journalisé l'événement. Modifiez une ligne et tous les hachages suivants cessent de correspondre.
Une vérification que vous pouvez voir s'exécuter
Une fonction de vérification parcourt la chaîne et désigne la première ligne où elle se rompt. Nous l'exécuterons devant vous pendant une revue.
Des revues d'accès
Qui détient quel rôle, dans quelle organisation, revu selon un calendrier plutôt qu'au moment de l'audit. Un retrait est un événement d'audit comme un autre.
Deux personnes pour les actions destructrices
Anonymiser ou supprimer une personne est une demande, puis une approbation distincte. Le demandeur ne peut pas approuver sa propre demande, et personne ne peut se prendre soi-même pour cible.
Des sessions que vous pouvez clore
Une personne connectée peut révoquer ses autres sessions, et une session révoquée est bloquée dès la prochaine vérification de permission, et non lorsque son jeton finit par expirer.
Du consentement à l'effacement, avec un compteur à chaque étape
Chaque tenant est responsable de traitement des données de ses apprenants et Lurno en est le sous-traitant. La mécanique ci-dessous est ce qui rend cette répartition réelle plutôt que contractuelle.
- 01
Un consentement, avec une version
Chaque politique à laquelle une personne consent porte une version. Modifiez la politique et l'ancien consentement cesse de compter : la personne est sollicitée à nouveau, et ce qu'elle a accepté et quand est enregistré. Le traitement par AI fait l'objet d'un consentement distinct — retirez-le et plus rien n'est envoyé à aucun fournisseur.
- 02
Une demande d'accès, sous forme d'assistant
Un administrateur suit la demande étape par étape au lieu de l'improviser : identifier la personne concernée, rassembler ce qui est détenu dans toute la plateforme, produire l'export. La portabilité veut dire lisible par une machine — JSON et CSV, pas un PDF de capture d'écran.
- 03
Une conservation avec une date de fin
Les données personnelles portent une durée de conservation par catégorie plutôt que de vivre indéfiniment par défaut. Les comptes inactifs, les invitations expirées et les sessions obsolètes ont tous une date après laquelle ils cessent d'exister.
- 04
Un effacement soumis à la règle des deux personnes
Un administrateur le demande, un second l'approuve, et ce n'est qu'alors qu'il s'exécute. Le demandeur ne peut jamais approuver, et aucun des deux ne peut se prendre pour cible. L'effacement atteint les tables qui référencent la personne, pas seulement la ligne de profil.
- 05
Un registre des violations avec un compteur de 72 heures
Un incident est une ligne avec une échéance calculée à 72 heures à compter de la découverte, et des rappels qui continuent de se déclencher jusqu'à sa clôture. Le compteur démarre à la découverte, pas au moment où quelqu'un se souvient de l'article 33.
Où résident réellement les données
Un stockage des médias que vous pouvez rediriger
Les fichiers sont écrits via une interface de stockage dotée de quatre implémentations : Supabase Storage, Amazon S3, Azure Blob Storage et Google Cloud Storage. C'est généralement la réponse honnête à une exigence de localisation — un déploiement peut écrire les fichiers dans un bucket situé dans la région que vous devez utiliser, plutôt que d'attendre qu'un fournisseur en ouvre une. Dites-nous l'exigence tôt et nous vous dirons clairement si elle est satisfaite aujourd'hui.
- La base de données, l'authentification et les fonctions sur lesquelles tourne l'API sont hébergées par Supabase. C'est la seule dépendance que vous ne pouvez pas configurer autrement, et elle est nommée dans le DPA.
- Les domaines personnalisés par organisation sont servis via Cloudflare avec des certificats émis automatiquement : un apprenant à Beyrouth ou à Milan voit votre domaine, pas le nôtre.
Une analytique produit dans l'UE, sans les apprenants
L'analytique de la plateforme passe par PostHog dans sa région UE, derrière une abstraction qui permet de remplacer le fournisseur sans toucher au produit. Le replay de session est masqué, et il n'enregistre jamais les apprenants — l'interface apprenant n'est pas du tout instrumentée pour le replay.
- Les champs de saisie et tout ce qui est marqué comme donnée personnelle sont masqués dans le navigateur, avant qu'un replay ne parte où que ce soit.
- L'analytique est soumise au consentement et désactivée tant qu'une organisation ne l'active pas. Rien concernant un mineur n'est profilé, sur aucune interface.
Ce qui arrive au texte avant qu'il n'atteigne un fournisseur d'AI
Le message d'un apprenant, un PDF déposé, une question tapée dans le copilote : tout cela est du contenu, rien n'est une instruction. Cette distinction est appliquée, pas demandée dans un prompt.
Classification des injections
Les entrées non fiables sont classées avant l'exécution du véritable appel. Un texte qui tente de détourner le modèle est signalé plutôt qu'exécuté.
Une barrière aléatoire
Le texte non fiable est encadré par une balise propre à chaque requête, impossible à deviner, et cette balise est retirée du contenu lui-même. Une troncature referme la barrière au lieu de la laisser ouverte.
Une expurgation avant l'appel
Les noms, e-mails et identifiants sont remplacés avant que quoi que ce soit ne parte vers un fournisseur. La correction s'effectue sur une copie anonymisée ; la correspondance avec l'apprenant reste sur notre serveur.
Une validation du schéma de sortie
Chaque réponse est validée par rapport à un schéma. Une réponse mal formée a droit à une tentative de réparation puis échoue, plutôt que d'atterrir dans un cours.
Une traçabilité de la proposition à la modification
Les demandes, les brouillons acceptés et les brouillons refusés sont des entrées distinctes dans le même journal chaîné par hachage. Ce que le modèle a suggéré figure à côté de ce qu'une personne a appliqué.
Comment les utilisateurs se connectent
Écrit comme un auditeur sécurité en a besoin : ce qui est livré aujourd'hui, et ce qui ne l'est pas.
Des comptes sur invitation
Les comptes sont créés par un administrateur ou par une invitation — il n'y a pas d'inscription en autonomie. Les liens de réinitialisation et de récupération sont à usage unique et stockés sous forme de hachage.
Authentification partenaire (SSO silencieux)
Un système partenaire qui a déjà authentifié quelqu'un peut le transférer avec une assertion signée, de sorte que l'apprenant ne voit jamais une seconde connexion. Cela se configure par organisation, avec une clé, et c'est révocable.
SSO SAML et OIDC
Feuille de routePas construit. Si votre déploiement dépend d'Entra ID ou d'Okta, dites-le dès le premier appel et nous vous dirons où cela en est plutôt que de laisser croire que c'est là.
MFA et clés d'accès
Feuille de routeÉgalement sur la feuille de route. Aujourd'hui, le fournisseur d'identité gère le mot de passe, les sessions peuvent être révoquées par leur propriétaire, et la révocation prend effet à la prochaine vérification de permission.
Tous ceux qui touchent à vos données
Cinq, et chacun est nommé dans l'accord de traitement des données plutôt que découvert plus tard.
| Capability | Ce qu'il traite | Où cela s'applique |
|---|---|---|
| Supabase | Base de données, authentification, stockage de fichiers et les fonctions sur lesquelles tourne l'API | Le sous-traitant principal. Le stockage des médias peut être redirigé vers S3, Azure ou GCS. |
| Cloudflare | DNS, TLS et le domaine personnalisé sur lequel chaque organisation est servie | Termine le TLS pour les domaines par organisation ; les certificats sont émis automatiquement. |
| OpenAI | Génération AI, tutorat et brouillons de correction | Appelé uniquement lorsqu'une requête en a besoin, après expurgation. Anthropic et Google peuvent être configurés à la place, et une organisation peut connecter sa propre clé. |
| Resend | E-mails transactionnels — invitations, notifications, réinitialisations | Une organisation peut envoyer depuis son propre sous-domaine, avec sa propre clé. |
| PostHog | Analytique produit et replay de session masqué | Région UE. Les interfaces apprenant ne sont pas enregistrées. |
La liste qui fait foi est celle de l'accord de traitement des données, aux côtés de l'avenant FERPA sur la confidentialité des données des élèves pour les établissements scolaires. Nous vous enverrons les deux avant un appel plutôt qu'après.
WCAG 2.1 AA, et ce que nous n'avons pas
Lurno est construit selon WCAG 2.1 AA. Des contrôles axe automatisés s'exécutent en intégration continue : un défaut de contraste ou un libellé manquant casse une compilation au lieu d'atteindre une version publiée. Les parcours au clavier, le focus visible et les préférences de mouvement réduit vivent dans la bibliothèque de composants plutôt que d'être ajoutés après coup écran par écran. Le produit est livré en anglais, en français, en arabe et en italien, et l'arabe est de droite à gauche de bout en bout, pas une mise en page de gauche à droite traduite.
Ce que nous n'avons pas, c'est un VPAT ou un audit d'accessibilité par un tiers, et nous préférons l'écrire ici plutôt que de l'enterrer dans la réponse à la question 47. Si un rapport de conformité formel est une condition d'achat, évoquez-le tôt — c'est une conversation de cadrage, pas une case à cocher.
Répondues avant même que vous ayez à envoyer le questionnaire
Les pages vers lesquelles celle-ci renvoie sans cesse
Envoyez-nous le questionnaire.
L'essentiel y trouve déjà sa réponse ci-dessus. Apportez le reste — localisation, conservation, sous-traitants, le DPA — à un appel, et nous répondrons avec les mêmes mots simples qu'ici.