Les premières versions de FlashLearning savaient créer des cartes, afficher une question et enregistrer un niveau. C’était une base fonctionnelle. Il manquait encore une réponse à la question produit : que doit faire la personne maintenant pour avancer vers un objectif réel ?
J’ai fait évoluer le produit autour de cette question. Mon travail a couvert le cadrage pédagogique, les parcours, les états d’interface, les règles de révision, les données Firebase, la sécurité et la mise en ligne. Les choix UX et techniques ont progressé dans la même boucle.
2–3 octobre 2026 / Identité et continuité
FlashLearning garde son moteur de rappel et adopte des surfaces sombres avec un accent corail. La couleur sert la hiérarchie ; je ne lui attribue aucun effet sur l’apprentissage.
Le passeport lit les parcours, leçons terminées et rappels actuels, avec repli sur les anciens formats. Les règles privées restent propres au compte. La passe de maintenance vérifie aussi formatage, compilation, lint et 105 tests ; l’audit des dépendances de production ne remonte aucune vulnérabilité au contrôle du 3 octobre.
01 / Cadrage produit
Une flashcard n’est pas un résultat
Relire des cartes peut donner une impression d’activité sans produire un rappel durable. J’ai donc défini FlashLearning comme un chemin entre une intention et une preuve observable : formuler ce que l’on veut savoir faire, récupérer l’information sans la voir, qualifier la réponse, revenir au bon moment, puis réutiliser le savoir dans une tâche.
Ce cadrage m’a permis de hiérarchiser les premières hypothèses. Masquer la réponse devait provoquer un effort de récupération. Le retour donné après chaque carte devait programmer la suite. La progression devait indiquer où agir, pas seulement compter des clics.
- Une mission nomme un objectif, un rythme et une preuve finale.
- Une session commence par une tentative avant d’afficher la correction.
- Un feedback explicite modifie la date de retour de la carte.
- Complétion, maîtrise, mémoire et transfert restent quatre signaux différents.
02 / Parcours
Dessiner la boucle avant les écrans
J’ai posé la boucle sous une forme courte : intention → mission → notion → tentative → confiance → feedback → prochaine échéance → preuve de transfert. Chaque écran devait préparer le geste suivant ou expliquer le résultat du geste précédent.
Cette structure a changé l’accueil. Un tableau de bord exhaustif obligeait à interpréter plusieurs indicateurs avant d’agir. L’accueil guidé choisit maintenant une action selon un ordre lisible : vérifier une erreur faite avec assurance, retravailler une notion fragile, réviser les cartes dues, apprendre une nouvelle unité, produire la preuve finale ou entretenir un acquis.
La recommandation garde sa raison, sa cible et une durée estimée. Je peux donc faire évoluer la règle sans transformer l’interface en boîte noire.
03 / UX de révision
Garder la friction qui aide à apprendre
Dans une session, l’interface résiste à l’envie de montrer la réponse trop tôt. La personne lit la question, tente de récupérer la réponse, puis révèle la correction. Elle indique ensuite la difficulté perçue et son niveau de confiance. Une carte ratée revient quelques positions plus tard pour éviter qu’une erreur disparaisse dans le résumé de fin.
J’ai réduit la friction autour de cet effort. Les formats express, standard et approfondi adaptent le volume de cartes au temps disponible. Une session peut être suspendue, reprise et annulée après une mauvaise saisie. Au clavier, Espace révèle la réponse, les touches 1 à 4 évaluent le rappel et U annule la dernière action.
Le démarrage de la session reste simple. L’effort de mémoire, lui, reste au bon endroit.
04 / Moteur pédagogique
Préférer une règle testable à une décision opaque
Le moteur de révision est une fonction TypeScript pure. Il reçoit la qualité du rappel, le nombre de répétitions, la stabilité, la difficulté et les oublis. Il renvoie un nouvel état et une prochaine date. Une erreur réduit la stabilité et augmente le nombre d’oublis. Une réponse correcte allonge l’intervalle selon l’historique de la carte.
J’ai gardé cette décision hors de React, de Firebase et de Luna. Je peux la tester sans navigateur, expliquer pourquoi une carte revient et remplacer la politique plus tard sans réécrire la session. L’IA peut proposer ou évaluer du contenu, mais une règle déterministe valide les données et choisit l’action.
Ce moteur reste une politique produit. Mesurer un gain mémoriel demandera un protocole dédié. Les paramètres devront être confrontés à l’usage avant de chercher une personnalisation plus fine.
05 / Full-stack
Faire tenir l’expérience, les données et la sécurité ensemble
L’interface utilise React, TypeScript et TanStack Router. Zustand orchestre les états de session. Firebase Auth sépare les comptes et Firestore conserve les missions, les cartes et la progression. Le mode local reste utilisable, puis les données authentifiées sont rattachées au bon utilisateur sans mélanger deux sessions.
Au fil du produit, les stores ont accumulé trop de responsabilités. J’ai isolé les règles pures, puis organisé la migration autour de domaines explicites : identité, parcours, pratique et révision, progression et communauté. Des ports décrivent les capacités attendues ; les adaptateurs Firebase portent les détails de persistance. Cette migration avance par flux couverts par des tests afin de ne pas casser les formats déjà enregistrés.
Luna passe par une fonction serveur. Le flux vérifie l’authentification, l’origine, la taille des entrées et des sorties, puis applique un budget quotidien atomique par utilisateur. L’IA reste derrière une limite de coût et un contrat de données, au lieu d’être appelée directement depuis l’écran.
06 / Itérations
Les incidents ont aussi dessiné le produit
Une PWA peut rester bloquée sur une ancienne version après un déploiement. L’incident m’a conduit à automatiser le rafraîchissement vers la version disponible. La génération Luna a aussi demandé plusieurs correctifs en production : validation plus stricte des entrées, contrôle de l’origine, authentification et comptabilisation des réponses servies depuis le cache.
La dette la plus délicate concerne deux représentations historiques de la progression. J’ai choisi une migration progressive plutôt qu’une réécriture destructive. Les anciens formats restent lisibles pendant que les nouveaux cas d’usage prennent possession de leurs données.
Les audits mobile et clavier ont produit des changements concrets : titre de session focalisé au démarrage, progression annoncée comme telle aux technologies d’assistance, réponses conservées après révélation et navigation mobile avec gestion du focus et de la touche Échap.
07 / Mesure
Ce que je peux prouver, et ce que je ne prétends pas savoir
La version en ligne permet de définir un parcours, créer des cartes, lancer une session, différer la réponse, enregistrer le feedback et calculer la prochaine révision. Les règles métier, les cas d’usage et les règles Firestore sont versionnés et testés dans le dépôt.
Je n’ai pas de mesure publique vérifiable sur la rétention, le retour hebdomadaire ou le gain de mémoire. Je ne transforme donc pas un produit fonctionnel en succès d’usage. La prochaine phase de validation doit observer des comportements précis.
- Le temps nécessaire pour atteindre une première révision utile.
- La part des sessions commencées qui arrivent au récapitulatif.
- Le retour lorsque des cartes arrivent réellement à échéance.
- L’écart entre confiance déclarée et qualité du rappel.
- La capacité à réutiliser une notion dans la preuve finale.
08 / Recul
Ce que je ferais plus tôt
Je commencerais encore plus petit : un objectif observable, une carte, une tentative, un feedback et une prochaine date. J’instrumenterais cette boucle dès la première version afin de distinguer rapidement une interface utilisée d’un apprentissage qui progresse.
Je séparerais aussi plus tôt la progression pédagogique des récompenses. Les XP peuvent soutenir le rythme, mais ils ne doivent jamais devenir une preuve de maîtrise. Enfin, je garderais la génération IA après la validation de la session de rappel, car une création de contenu plus rapide ne compense pas une boucle de révision confuse.
La prochaine étape consiste à tester si l’action recommandée aide réellement une personne à commencer, revenir au bon moment et produire une preuve hors de FlashLearning.