Sécurité et traitement des données

La séparation entre les écoles

AiLycée est un système unique qui sert plusieurs écoles. Chaque table appartenant à une école porte son identifiant, et la sécurité au niveau des lignes de PostgreSQL filtre absolument chaque requête sur l’école courante — y compris une requête écrite par erreur. L’application se connecte avec un rôle de base de données incapable de contourner ce filtre. Un défaut dans un écran ne peut donc pas montrer à une école les élèves d’une autre.

Comptes et sessions

Les mots de passe sont hachés avec Argon2id. La connexion par code à usage unique envoie un code éphémère et non réutilisable par WhatsApp ou SMS. Les jetons d’accès sont de courte durée ; les jetons de rafraîchissement tournent à chaque usage et un jeton réutilisé invalide toute la famille, ce qui transforme un vol de jeton en incident détecté plutôt qu’en fuite silencieuse. Les rôles — direction, comptabilité, enseignant, parent, élève, chauffeur, infirmerie — décident de ce que chaque écran et chaque route d’API renvoient.

Ce que nous envoyons à un modèle d’IA, et ce que nous n’envoyons jamais

Deux fonctions seulement appellent un modèle aujourd’hui : les appréciations de bulletin et le résumé hebdomadaire aux parents. Les deux reçoivent le prénom de l’enfant et des faits scolaires — notes, moyennes, tendances, comptages de présence, descripteurs de l’enseignant. Rien d’autre n’entre dans le prompt : ni nom de famille, ni téléphone, ni adresse, ni numéro d’identité, ni photo, ni contenu de message, ni donnée financière. Le constructeur de prompt l’impose et des tests le couvrent.

Chaque génération est enregistrée avec son modèle, sa version de prompt, son nombre de jetons, son statut et, une fois validée, le nom de la personne qui a validé. Une appréciation reste un brouillon tant qu’un enseignant n’a pas cliqué sur valider. Un résumé est vérifié chiffre par chiffre dans les données sources avant l’envoi, et un chiffre invérifiable arrête le message au lieu de partir.

Documents et fichiers

Les documents d’élèves, les reçus et les bulletins sont stockés dans un espace objet sous des clés préfixées par l’école, et servis par des liens signés de courte durée plutôt que par des URL publiques. Les reçus sont immuables une fois émis : une correction est un avoir, la piste d’audit n’est donc jamais réécrite. Chaque reçu et chaque bulletin porte un QR pointant vers ailycee.com/verify, qui confirme l’authenticité du document en ne révélant que son type, l’école, la date d’émission, sa validité et le prénom du titulaire.

Sauvegardes et restauration

Les écoles en cloud sont sauvegardées chaque nuit, chiffrées, avec une rétention de 30 jours. Les installations sur site écrivent un dump chiffré nocturne sur le NAS de l’école, avec une copie externe optionnelle vers un stockage contrôlé par l’école. Les restaurations sont répétées plutôt que supposées, et une école en formule Institution peut demander à assister à un exercice de restauration.

Les applications sur les téléphones

Les applications enseignant, parent et élève conservent une base locale pour fonctionner pendant une coupure de courant ou de réseau. Cette copie locale ne contient que les données auxquelles l’utilisateur connecté a droit, est supprimée à la déconnexion et se resynchronise avec une piste d’audit plutôt qu’un écrasement silencieux. Il n’y a aucun SDK publicitaire ni analytique tiers dans ces applications — c’est une règle, pas un réglage.

Ce site

Le site que vous lisez est un ensemble de fichiers statiques. Les polices sont hébergées par nous, il n’y a aucun script d’analyse, aucun gestionnaire de balises, aucun pixel publicitaire et aucun contenu tiers intégré. L’ouvrir n’envoie de requête à personne d’autre que nous. La recherche dans l’annuaire et le formulaire de démonstration appellent notre propre API, et rien d’autre.

Exploitation

Les mêmes images de conteneurs tournent dans notre cloud et dans une école : ce qui est testé est ce qui est déployé. Les secrets vivent dans le coffre de l’orchestrateur, jamais dans une image. Les formulaires publics sont limités en débit et pourvus d’un pot de miel. Une revue de sécurité précède chaque livraison, et les mises à jour de dépendances suivent un calendrier plutôt qu’un incident.

Si quelque chose se passe mal

Nous vous le dirons. Si un incident de sécurité touche les données de votre école, nous contacterons l’école directement, décrirons ce qui s’est passé et quelles données étaient concernées, dirons ce que nous avons fait, et vous tiendrons informés jusqu’à la clôture — nous n’attendrons pas un rapport trimestriel. Pour signaler une vulnérabilité, écrivez à security@ailycee.com : nous accusons réception sous deux jours ouvrés et nous ne poursuivrons jamais quelqu’un qui signale de bonne foi un vrai problème.