Fethi BoughaliaPortfolio d’ingénierie de sécurité
← Toutes les études de cas

01 / Ingénierie produit sécurisée

The Five

Une application mobile de concentration quotidienne pour choisir jusqu’à cinq objectifs importants, les décomposer en étapes et examiner sa progression dans le temps.

Rôle
Concepteur et développeur
Backend
Serveur HTTP Python
Données
SQLite
Frontend
HTML/CSS/JS natifs

Le problème

Les gestionnaires de tâches généralistes encouragent l’accumulation. The Five impose une contrainte volontaire : pas plus de cinq objectifs par jour. Chaque objectif peut être décomposé en sous-tâches, le travail terminé s’efface visuellement et les journées passées restent disponibles pour la réflexion plutôt que de former un backlog indéfiniment modifiable.

Le produit associe un modèle d’interaction ciblé, une persistance multi-utilisateur et une authentification sans mot de passe, sans framework frontend ni étape de build.

Architecture

Client web mobile
JavaScript natif · Shell PWA
→
Serveur Python
Authentification · sessions · API
→
SQLite
Utilisateurs · jours · objectifs · étapes

Frontière de confiance : l’état du navigateur améliore l’interface, mais les sessions authentifiées côté serveur restent l’autorité pour l’identité et les données quotidiennes.

Choix produit

  • La limite de cinq objectifs transforme la priorisation en règle du produit.
  • Le calendrier et l’historique chronologique exposent les journées terminées ou incomplètes sans rechargement.
  • Reporter un objectif crée un nouvel enregistrement sans modifier la journée historique d’origine.
  • Le mode Anti-procrastination verrouille les jours passés tout en laissant leurs détails consultables.
  • Les préférences de réduction des animations sont respectées pour le réordonnancement et la célébration finale.

Choix de sécurité

  • L’inscription et la connexion sans mot de passe utilisent des codes e-mail à six chiffres, valables dix minutes et limités à cinq tentatives.
  • Les sessions sont gérées côté serveur, transmises par cookies HttpOnly et expirent après sept jours.
  • Les OTP et jetons de session bruts ne sont pas stockés directement ; seules leurs représentations hachées persistent.
  • Les API de données quotidiennes exigent une session valide et imposent la propriété par utilisateur.
  • Le changement d’adresse exige la vérification de la nouvelle adresse et ferme les autres sessions.

Limite assumée : le jalon actuel est un prototype multi-utilisateur local. L’e-mail dépend de Gmail SMTP, les rappels ne fonctionnent que lorsque l’application reste ouverte, et les fonctions multi-appareils dépendantes du backend restent à venir. Une exploitation en production exigerait aussi déploiement durci, HTTPS, secrets gérés, supervision, sauvegardes, contrôles anti-abus et tests de sécurité plus larges.

État des preuves : projet en ligne et étude d’ingénierie. Aucun dépôt source public n’est actuellement revendiqué.