Memnos

Le problème

Réviser en relisant ses notes donne l’illusion de savoir : on reconnaît le contenu sans être capable de le restituer. Les deux mécanismes qui marchent vraiment sont le rappel actif (se forcer à retrouver la réponse) et la répétition espacée (revoir juste avant d’oublier). Les outils qui les implémentent existent, mais ils sont soit austères, soit lourds à prendre en main.

Avant d’écrire une ligne de code, j’ai lu des dizaines de témoignages d’étudiants. Trois choses reviennent, et aucune n’est un problème d’algorithme : la prise en main décourage avant la première carte, l’application gratuite devient payante au moment où elle devient utile, et la pile de cartes en retard après quelques jours de pause fait tout abandonner.

Memnos part de là : garder l’ordonnancement sérieux, enlever tout le reste.

Ce que j’ai construit

Une application web complète, utilisable sur ordinateur comme sur téléphone : on crée un paquet, ses cartes, on révise. L’accueil ne montre que ce qui se décide aujourd’hui, les cartes à revoir maintenant, et le taux de maîtrise de chaque paquet.

L’ordonnancement repose sur FSRS (Free Spaced Repetition Scheduler) : à chaque réponse, le modèle réestime la difficulté de la carte et la stabilité du souvenir, puis en déduit la prochaine date de révision. C’est plus fin qu’un simple multiplicateur d’intervalle, et ça change vraiment la charge de révision quotidienne.

Autour de ce noyau :

• Création et partage de paquets — un paquet de cartes peut être publié et repris par quelqu’un d’autre.
• Application installable — elle s’ajoute à l’écran d’accueil du téléphone et se comporte comme une application native.
• Rappels par notification — un déclencheur périodique côté serveur prévient les personnes qui ont des cartes à revoir.
• Statistiques de révision — de quoi voir si la charge quotidienne tient, ce qui est le premier motif d’abandon.
• Suivi des erreurs — les exceptions côté navigateur remontent dans un journal exploitable, pour ne pas découvrir un bug par hasard.

Créer les cartes sans tout retaper

C’est là que se perdent la plupart des gens, et ce n’est jamais à la révision : c’est à la production des cartes. Une heure de cours donne trente cartes à écrire une par une, et personne ne le fait deux fois.

L’application propose donc de les générer depuis ses propres notes : on colle son texte ou on donne un sujet, on choisit la langue, le niveau de difficulté et le nombre de cartes, de une à vingt. Rien n’est ajouté sans relecture : la génération rend un aperçu modifiable, et c’est l’utilisateur qui valide.

L’ordre compte : la création manuelle reste la première entrée de l’écran. Une application de mémorisation qui exige un modèle de langage pour produire sa première carte a déplacé le problème, elle ne l’a pas résolu.

Choix techniques et pourquoi

Monorepo pnpm. Le web et ce qui viendra ensuite partagent les types et la logique métier. Un seul endroit pour le modèle de données, pas de dérive entre deux copies.

Supabase plutôt qu’un backend maison. Postgres géré, authentification et politiques de sécurité au niveau des lignes (RLS) : les règles d’accès sont dans la base, pas seulement dans le code de l’application. Sur un projet mené seul, c’est ce qui garantit qu’une route oubliée ne devient pas une fuite de données.

On peut essayer sans créer de compte. Un formulaire d’inscription avant la première carte, c’est la moitié des visiteurs perdus. En échange, l’application doit savoir fonctionner sans utilisateur identifié, donc porter un état qui n’appartient encore à personne et qui doit pouvoir devenir un compte ensuite. C’est, en dehors de l’algorithme, la décision qui coûte le plus cher.

Quatre langues d’interface : français, anglais, allemand, espagnol. Ce n’est pas une ambition d’export, c’est une contrainte qu’il valait mieux poser au début — une chaîne de caractères écrite en dur se paie à chaque écran ajouté, et on ne repasse jamais sur les anciens.

Déploiement conteneurisé avec un environnement de préproduction séparé. Le site tourne derrière Nginx sur mon serveur, avec une instance de staging identique à la production. Toute modification sensible y passe avant la mise en ligne.

État actuel

Le service est en bêta ouverte depuis juillet 2026 sur memnos.fr. Le modèle est posé : ce qui est gratuit le reste, sans publicité, et un plan payant viendra pour des bonus sans jamais retirer une fonction gratuite. C’est une contrainte de conception autant qu’une promesse commerciale, puisqu’elle interdit de rendre payant ce qui marche déjà.

Le travail en cours porte sur l’acquisition et sur la validation des rappels push sur iOS, où les contraintes du navigateur sont les plus strictes.