Intégrer la PDPPL du Qatar au produit, pas autour

EduQate est une plateforme d'admissions scolaires, donc elle détient des données d'enfants. La loi n° 13 de 2016 du Qatar (la PDPPL) donne aux personnes le droit d'accéder à leurs données et de les faire supprimer. Avant ce travail, les deux passaient par un e-mail au support. Voici ce que fait le produit maintenant, et pourquoi.

Ce qu'un parent peut faire lui-même

• Télécharger tout ce qui le concerne. Un clic dans les Paramètres renvoie un export JSON : le profil du compte, les enfants, les candidatures, les métadonnées des documents et l'historique des consentements.
• Supprimer son propre compte. Le titulaire demande un code à usage unique par e-mail, le confirme, et le compte est supprimé. Sans ticket au support.
• Les dossiers d'admission d'un enfant ne sont pas supprimés avec le compte du parent. Ils restent à l'école, au titre de ses propres obligations de conservation. Seules les données du parent partent.

Supprimé doit vouloir dire disparu, partout

Supprimer un compte en laissant d'autres sessions ouvertes voudrait dire que « supprimé » ne veut pas vraiment dire disparu. À la suppression, chaque session de rafraîchissement active de l'utilisateur est révoquée dans la même opération : tout appareil qui détient encore un jeton est déconnecté à sa prochaine requête.

Les sauvegardes sont le cas plus difficile. Les bases sont restaurées en bloc pour la reprise après sinistre. Si quelqu'un supprime son compte le lundi et qu'on restaure la sauvegarde de dimanche le mercredi, il réapparaît, ce qui annule discrètement un droit déjà exercé.

La suppression écrit donc aussi une petite pierre tombale dans un stockage objet qui n'est jamais restauré en bloc comme la base. Un script de réconciliation tourne après chaque restauration et re-supprime toute personne ayant une pierre tombale. Si les identifiants du stockage manquent, l'écriture journalise et ne fait rien au lieu de lever une erreur : cette configuration doit donc être vérifiée en production, pas supposée.

Un consentement qui sait quand il est périmé

Il y a trois types de consentement : l'avis de confidentialité, les conditions et la divulgation de candidature. Chacun a une version, et chaque consentement donné est stocké avec la version acceptée. Si la version courante diffère de la dernière acceptée, l'app bloque derrière un écran de re-consentement jusqu'à nouvelle acceptation. Soumettre une candidature exige de cocher une divulgation explicite, en arabe et en anglais, sur le web et le mobile.

Changer une version interpelle tous les comptes, donc on ne le fait jamais à la légère.

Dire ce que l'app décide toute seule

L'avis de confidentialité dit clairement où la plateforme prend une décision automatisée avec des données personnelles. Il n'y en a qu'une : si une école propose une place et que le parent ne confirme pas l'inscription avant l'échéance, la candidature est retirée automatiquement, sans intervention humaine. L'avis dit aussi ce que l'automatisme ne touche jamais : l'acceptation, le refus et les entretiens restent des décisions humaines.

La règle que je suis : si l'app fait quelque chose automatiquement, l'avis doit le dire, donc le texte de l'avis fait partie du changement, pas seulement le code.

Des journaux d'audit sur les consultations, et un outil d'erreurs aveugle

La responsabilité, c'est « qui a regardé cet enregistrement », pas seulement « qui l'a modifié ». Consulter une candidature ou un document écrit désormais une entrée d'audit, comme créer, modifier ou supprimer.

Les outils d'erreurs capturent par défaut les corps de requête, les cookies et l'identité de l'utilisateur, ce qui peut mettre des noms, des e-mails et des jetons dans un tableau de bord tiers. Sur le back-end, le web et le mobile, la capture de données personnelles par défaut est désactivée. Les corps de requête, les cookies et les en-têtes d'authentification sont retirés avant qu'un événement ne quitte l'app, l'objet utilisateur est réduit à un identifiant, et tout ce qui ressemble à un e-mail est masqué.

Ce qui n'est pas fait

• Vérification d'identité du tuteur : demande une décision produit sur ce qui est suffisant.
• Classification de la sensibilité des données sur chaque modèle.
• Un calendrier de conservation avec purge automatique, conditionné à un accord des écoles sur une durée.
• Des tests automatisés pour ce qui précède. Le travail a été vérifié à la main dans l'app en marche : export, suppression avec fin des sessions, écran de consentement, case de divulgation, et une vraie erreur dont j'ai inspecté la charge. Tant que la passe de tests n'est pas faite, une régression ici serait attrapée par un nouveau contrôle manuel ou par un utilisateur qui la remarque.