Rappels récurrents : comment gérer la complexité cachée

"Ajoute un rappel tous les mardis." Six mots. Facile a dire. Mais derriere cette phrase se cache l'un des problemes les plus sous-estimes du developpement d'applications : les regles de recurrence. J'ai passe des jours entiers a gerer des cas limites que personne n'anticipe avant de les rencontrer.

Points cles a retenir :
- Les rappels recurrents semblent simples mais cachent une complexite enorme (gestion des mois inegaux, fuseaux horaires, exceptions).
- Le stockage hybride (regle sur le parent, occurrences generees a la demande) est le meilleur compromis performance/flexibilite.
- L'UX progressive — simple par defaut, puissant en option — est la cle pour ne perdre aucun utilisateur.
- Un bon systeme de recurrence necessite au minimum 4 types de regles et une gestion robuste des cas limites.

Pourquoi les rappels recurrents sont-ils si complexes a implementer ?

Quand tu penses "rappel recurrent", tu imagines probablement un simple setInterval ou un cron job. La realite est bien plus tordue. TAMSIV supporte quatre types de recurrence : quotidien, hebdomadaire, mensuel et personnalise. Le cas quotidien prend 10 minutes a coder. Le cas "le dernier vendredi de chaque mois" ? Des jours.

Le probleme fondamental, c'est que le calendrier n'est pas regulier. Les mois ont 28, 29, 30 ou 31 jours. Les semaines chevauchent les mois. Les annees bissextiles existent. Et les fuseaux horaires ajoutent une couche supplementaire de chaos.

En tant que developpeur solo de TAMSIV, j'ai du prendre des decisions architecturales critiques des le debut pour eviter de tout refactorer plus tard.

Comment gerer le probleme du "31 de chaque mois" ?

C'est le cas classique que tout developpeur de calendrier redoute. L'utilisateur cree un rappel le 31 janvier avec recurrence mensuelle. Que se passe-t-il en fevrier ? En avril ?

Trois approches existent :

1. Sauter le mois : pas de rappel en fevrier. Mauvaise UX — l'utilisateur pense que c'est un bug.
2. Decalage au dernier jour : le rappel passe au 28 (ou 29) fevrier, 30 avril, etc. C'est intuitif.
3. Forcer le 1er du mois suivant : logique pour certains cas, mais deroutant.

J'ai choisi l'option 2 — le decalage automatique au dernier jour du mois. Pourquoi ? Parce que c'est ce que l'utilisateur attend sans y reflechir. Quand quelqu'un dit "tous les mois", il veut dire "a peu pres a la meme date chaque mois". Le pragmatisme bat la rigueur mathematique.

Ce choix a un impact direct sur le code. Pour chaque occurrence, je calcule d'abord la date theorique, puis je verifie si elle existe dans le mois cible avec Math.min(jourOriginal, dernierJourDuMois). Simple en apparence, mais il faut le faire pour chaque occurrence generee.

Quel est le meilleur modele de stockage pour les evenements recurrents ?

C'est la question architecturale cle. Deux ecoles s'affrontent :

Option A : stocker toutes les occurrences. Tu generes 365 lignes en base pour un rappel quotidien annuel. Avantage : requetes simples. Inconvenient : explosion de la base de donnees et complexite de modification (changer l'heure du rappel = modifier 365 lignes).

Option B : stocker uniquement la regle. Tu gardes "chaque mardi a 9h" et tu calcules a la volee. Avantage : base de donnees legere. Inconvenient : queries complexes pour savoir "quels rappels tombent cette semaine ?".

J'ai opte pour un modele hybride dans TAMSIV : la regle de recurrence est stockee sur l'evenement parent, et les occurrences sont generees a la demande. Quand un rappel est converti en evenement calendrier — par exemple via le systeme d'agenda avec filtres — une occurrence concrete est creee en base.

Concretement, la structure de la base de donnees ressemble a ca :

• Table parent : contient le titre, la description, et un champ JSON avec la regle de recurrence (type, interval, daysOfWeek, endDate)
• Table occurrences : creee a la demande quand l'utilisateur interagit (complete, reporte, modifie)
• Calcul dynamique : pour l'affichage calendrier, les occurrences futures sont calculees cote client

Ce modele hybride permet d'eviter les N+1 queries tout en gardant la base de donnees sous controle. Avec le systeme de cache optimise, les performances restent excellentes meme avec des centaines de rappels.

Comment creer un rappel recurrent par la voix ?

L'un des avantages uniques de TAMSIV, c'est que tu peux creer des rappels complexes en parlant naturellement. Le pipeline vocal IA analyse ta phrase et extrait automatiquement la regle de recurrence.

Exemples concrets :

• "Rappelle-moi d'arroser les plantes tous les 3 jours" → recurrence personnalisee, intervalle 3 jours
• "Reunion d'equipe chaque lundi et mercredi a 10h" → hebdomadaire, jours specifiques
• "Payer le loyer le premier de chaque mois" → mensuel, jour fixe avec gestion des cas limites
• "Anniversaire de Marie le 15 mars chaque annee" → annuel

Le LLM (via OpenRouter) decompose la phrase en intentions structurees. La fonction create_calendar_event recoit ensuite un objet avec les parametres de recurrence deja extraits. L'utilisateur n'a qu'a valider — ou modifier — avant la sauvegarde en base.

C'est la force du dictaphone integre : rendre invisible la complexite technique pour l'utilisateur final.

Quels sont les pieges des fuseaux horaires avec les rappels ?

Si tu penses que les mois irreguliers sont penibles, attends de voir les fuseaux horaires. Un rappel quotidien a 9h se declenche a 9h heure locale. Mais qu'est-ce que "9h heure locale" quand l'utilisateur voyage ? Quand le changement d'heure ete/hiver intervient ?

Deux strategies possibles :

• Stocker en UTC et convertir au rendu : propre mais problematique pour "9h tous les jours" (qui peut devenir 8h ou 10h selon la saison)
• Stocker en heure locale avec timezone : plus fidele a l'intention mais plus complexe a gerer en base

Dans TAMSIV, j'ai opte pour le stockage en UTC avec le fuseau horaire de reference de l'utilisateur. Quand le calcul d'occurrence tombe sur un jour de changement d'heure, le systeme ajuste pour garder l'heure locale stable. C'est le comportement qu'attendent les utilisateurs de Google Calendar ou Apple Calendar.

Comment concevoir l'UX des rappels sans submerger l'utilisateur ?

Le defi UX est tout aussi important que le defi technique. Comment presenter des regles de recurrence potentiellement complexes sans perdre l'utilisateur occasionnel ?

La reponse : le design progressif (progressive disclosure).

Voici comment je l'ai implemente dans TAMSIV :

1. Niveau 1 — 4 boutons simples : Tous les jours, Toutes les semaines, Tous les mois, Pas de recurrence. Couvre 80% des besoins.
2. Niveau 2 — Panneau avance : accessible via "Personnaliser". Jours de la semaine selectionnables, intervalle personnalise (tous les N jours/semaines/mois), date de fin optionnelle.
3. Niveau 3 — Cas complexes : "Le dernier vendredi du mois", "Le 2e mardi de chaque mois". Interface specialisee pour ces regles rares.

Le principe directeur : simple par defaut, puissant en option. L'utilisateur occasionnel ne doit jamais se sentir perdu. L'utilisateur avance ne doit jamais se sentir limite. Ce principe guide aussi le systeme d'onboarding de l'application.

J'ai egalement implemente la navigation par swipe sur les ecrans de rappels pour fluidifier l'experience.

Quelle difference avec les rappels de Google Calendar ou Todoist ?

Les solutions existantes comme Todoist ou Google Calendar gerent bien les recurrences. Mais elles ont toutes le meme defaut : la saisie manuelle.

Avec TAMSIV, la creation vocale change fondamentalement l'equation. Dire "rappelle-moi d'envoyer le rapport tous les vendredis a 17h" est incomparablement plus rapide que naviguer dans 3 menus pour configurer la meme chose manuellement.

De plus, le systeme de gamification recompense la completion des rappels recurrents, ce qui cree un cercle vertueux de productivite. Chaque tache recurrente completee alimente ton streak et te rapproche du prochain niveau.

Quelles lecons retenir de l'implementation des recurrences ?

Apres avoir code ce systeme, voici les lecons que je retiens :

• Ne pas sous-estimer les cas limites : le "31 du mois", les annees bissextiles, les changements d'heure — chaque cas semble rare individuellement, mais collectivement ils touchent des milliers d'utilisateurs.
• Tester avec de vraies donnees : les tests unitaires ne suffisent pas. Il faut simuler une annee entiere d'occurrences et verifier visuellement.
• Le modele hybride est le bon compromis : ni tout-en-base, ni tout-calcule. Le mix offre le meilleur des deux mondes.
• L'UX progressive sauve des vies : cacher la complexite derriere des niveaux de detail est la seule approche viable pour une app grand public.

Si tu developpes une app de productivite ou un systeme de calendrier, ne sous-estime jamais les rappels recurrents. Ce qui semble etre une feature de 2 jours peut facilement en prendre 10.

FAQ

Combien de types de recurrence TAMSIV supporte-t-il ?

TAMSIV supporte quatre types principaux : quotidien, hebdomadaire, mensuel et personnalise. Le mode personnalise permet de definir n'importe quel intervalle (tous les N jours, certains jours de la semaine, etc.) et couvre des cas avances comme "le dernier vendredi du mois".

Peut-on creer un rappel recurrent par la voix ?

Oui, c'est meme l'un des points forts de TAMSIV. Tu peux dire "rappelle-moi d'envoyer le rapport tous les lundis a 9h" et l'IA comprend automatiquement le type de recurrence, le jour et l'heure. Il suffit de valider pour que le rappel soit cree.

Que se passe-t-il si un rappel mensuel tombe un jour qui n'existe pas ?

TAMSIV decale automatiquement le rappel au dernier jour du mois. Par exemple, un rappel le 31 sera avance au 28 ou 29 en fevrier, et au 30 en avril, juin, septembre et novembre. C'est le comportement le plus intuitif pour l'utilisateur.

Les rappels recurrents fonctionnent-ils avec la gamification ?

Absolument. Chaque completion d'un rappel recurrent rapporte des points d'experience et alimente ton streak quotidien. C'est un excellent moyen de maintenir une routine productive et de rester motive sur la duree.

Comment modifier ou supprimer une seule occurrence d'un rappel recurrent ?

Tu peux modifier ou supprimer une occurrence specifique sans affecter les autres. Le systeme cree alors une "exception" pour cette date. Le reste de la serie continue normalement selon la regle definie.