01 / Créer
Partir de ce que l’on veut savoir faire
L’accueil part d’un objectif, d’un niveau et du temps disponible. Le parcours relie une notion, une pratique puis des cartes à retrouver sans aide.
Objectif · parcours · cartes
Écosystème SupraLearning
05 / Produit · UX · full-stack
FlashLearning
Un moteur pédagogique qui transforme les principes des sciences cognitives en rappels utiles.
Écouter le podcast du projet
Captures et vérifications locales — 2–3 octobre 2026. Derniers correctifs sur les versions publiques à confirmer.
CONÇU & DÉVELOPPÉ PAR ALEX ATCReact / TypeScript
LE PROJET EN 30 SECONDESAlex ATC / Product Engineer
- L’intention
- Faire passer les principes des sciences cognitives dans une boucle simple et actionnable.
- Ma contribution
- Concevoir le moteur pédagogique en traduisant les principes des sciences cognitives en règles de révision concrètes.
- Ce qui existe
- Un moteur de révision fondé sur le rappel actif et la répétition espacée.
01 / Le sujet
J’ai conçu une boucle qui relie intention, rappel actif, prochaine action et preuve de transfert, avec un moteur React et Firebase.
Le produit rassemble la création de cartes, la session guidée, le rappel actif et la répétition espacée. J’ai travaillé sur le moteur pédagogique qui orchestre ces mécanismes pour proposer le bon effort de mémorisation au bon moment, sans demander à l’utilisateur de piloter un planning complexe.
Stack & terrainReact · TypeScript · Firebase · Pédagogie cognitive
Lire le processus de création ↗ Reactinterface produit
Firebasedonnées & authentification
En ligneversion consultable
02 / Aperçus de fonctionnalités
Trois vues pour comprendre le produit.
Des captures réelles, reliées à une action et à son résultat.
02 / Réviser
Faire émerger le rappel actif
La session affiche d’abord la question et réserve la réponse au moment où l’utilisateur s’engage à la retrouver.
Session guidée · réponse différée · feedback03 / Progresser
Donner un retour simple
Chaque réponse alimente le moteur pédagogique et la suite de la session. La progression sert à comprendre où agir, pas à décorer l’écran.
Répétition espacée · progression · prochaine carte03 / Ma contribution
Ce que j’ai pris en charge.
- 01
Concevoir le moteur pédagogique en traduisant les principes des sciences cognitives en règles de révision concrètes.
- 02
Définir la boucle produit de la carte à la prochaine révision.
- 03
Concevoir l’interface React et les états de session.
- 04
Connecter les données et l’authentification avec Firebase.
- 05
Livrer une version accessible en ligne et vérifier le parcours complet.
Étude de casProblème, décisions et résultats.Le détail reste disponible pour vérifier les faits et les arbitrages.Ouvrir l’étude complète
01 / Problème
Le rappel actif et la répétition espacée sont utiles seulement si la personne fait l’effort de retrouver une réponse puis revient au bon moment. Le problème produit était de transformer ces principes en une boucle simple, sans demander de gérer soi-même un calendrier de révision.
02 / Rôle · équipe · durée · contraintes
- Rôle
- Product Engineer — cadrage pédagogique, UX des sessions, développement React/TypeScript, logique de progression, Firebase et mise en ligne.
- Équipe
- Projet personnel. Le dépôt ne documente pas d’autre rôle ; je limite l’étude aux contributions visibles dans le produit et le code.
- Durée
- Durée non publiée. Je ne transforme pas l’historique Git en estimation de charge.
Contraintes
- Préserver une session courte et compréhensible tout en conservant les états nécessaires au moteur pédagogique.
- Séparer les données entre comptes et garder un chemin utilisable en mode local ou invité.
- Protéger la génération Luna côté serveur : authentification, origine, limites de taille et budget.
- Faire évoluer la progression sans migration destructive des données déjà présentes.
03 / Hypothèses
- Masquer la réponse jusqu’à l’engagement de l’apprenant provoque un rappel plus actif qu’une relecture immédiate.
- Calculer la prochaine révision à partir du retour donné réduit la planification manuelle.
- Une progression doit aider à choisir le prochain effort plutôt que seulement récompenser une série de clics.
Alternatives étudiées
- Un lecteur de cartes sans planification aurait été plus simple, mais n’aurait pas orchestré le retour des notions dans le temps.
- Un calendrier fixe aurait été plus prévisible, mais n’aurait pas tenu compte de la difficulté signalée après chaque réponse.
- Une génération IA placée au centre du produit aurait accéléré la création ; elle reste subordonnée à la qualité de la boucle rappel → feedback → prochaine révision.
04 / Arbitrages UX & tech
- Automatisation contre contrôle : le moteur propose la suite, tandis que la personne garde un feedback explicite sur sa réponse.
- Réactivité locale contre synchronisation distante : les stores gardent l’interface fluide et Firebase porte les données authentifiées avec des règles privées.
- Génération utile contre coût et abus : Luna passe par un endpoint Responses API avec limites de corps, contexte et sortie, ainsi qu’un budget atomique de 0,20 € par utilisateur et par jour.
05 / Tests · incidents · itérations
- Un incident de mise à jour PWA après déploiement a conduit à automatiser le rafraîchissement vers la nouvelle version.
- La génération Luna a nécessité des correctifs de production ; le flux valide désormais l’authentification, l’origine, les entrées et comptabilise aussi les réponses servies depuis le cache.
- Les règles Firestore gardent les données privées et App Check reste un garde-fou optionnel, sans prétendre qu’il est activé en production.
- La documentation d’architecture rend explicite la migration progressive du double modèle de progression afin d’éviter une rupture de données.
06 / Résultats observés
- La version en ligne permet de créer des cartes, lancer une session guidée, différer la réponse et alimenter la prochaine révision.
- Le moteur relie rappel actif, feedback, répétition espacée et progression dans une même expérience React/Firebase.
- La génération Luna est bornée par utilisateur et côté serveur ; les règles de données privées sont versionnées dans le dépôt.
- Aucune métrique d’adoption, de rétention ou de gain mémoriel n’est présentée sans mesure publique vérifiable.
Preuves
Preuves et accès.
Produits publics, captures et traces de validation disponibles.
Code privé — demander l’accès ↗Produit en ligne
Boucle de création, session et progression consultable dans la version déployée.
Ouvrir le produit ↗Capture de session
Question avant réponse et état de session documentés par une capture du produit.
Ouvrir la capture ↗Rapport tests & sécurité
105 tests, formatage, lint et compilation sous Node 22 vérifiés le 3 octobre ; aucune vulnérabilité dans l’audit de production de cette passe. Rapport disponible sur demande.
URL publique à relierDemander cette preuve ↗UN POSTE / UNE MISSION / UN ÉCHANGE
Paris / À distanceFaisons avancer votre prochain produit.
Dites-moi ce que vos utilisateurs doivent faire, ce qui les bloque et ce que vous voulez construire. Nous pouvons partir de là.
contact@alexatc.com