Calcul du prochain intervalle de répétition espacée

Il applique la règle de multiplication courante des systèmes simples de répétition espacée, puis arrondit le résultat selon la précision que vous choisissez. La sortie déterministe reprend les entrées et la formule : elle convient donc aux outils d’étude, planificateurs de cartes mémoire, tableurs et parcours pédagogiques auditables. Aucun compte, appel réseau, accès à l’horloge ou profil caché de l’apprenant n’est nécessaire.

Saisissez l’intervalle précédent et le facteur de facilité

Commencez par le nombre de jours séparant les deux dernières révisions programmées. Saisissez cette valeur dans previous_interval_days. Il peut s’agir d’un entier, comme 6, ou d’une valeur fractionnaire si votre application planifie plus finement. Indiquez ensuite ease_factor, le multiplicateur retenu par votre système d’apprentissage après la dernière révision. Un facteur supérieur à 1 allonge le délai, tandis qu’un facteur inférieur à 1 le raccourcit. Par exemple, un intervalle de 6 jours et un facteur de 2.5 donnent 15 jours avant arrondi. Les deux valeurs doivent être finies et positives. Le calculateur ne déduit volontairement pas le facteur d’une note, d’un bouton, d’un nombre d’oublis ou d’un temps de réponse, car ces règles varient selon les systèmes. Il effectue une étape de planification transparente avec les valeurs déjà choisies par votre application. Le résultat reste ainsi reproductible dans un SDK, un tableur, un jeu de test ou un worker de file sans recopier tout un algorithme de cartes mémoire.

Comprenez la multiplication et l’arrondi

Le calcul multiplie previous_interval_days par ease_factor. Le produit est ensuite arrondi à decimal_places, réglé par défaut sur 2 et compris entre 0 et 6. Choisissez 0 si votre planificateur ne conserve que des jours calendaires entiers ; choisissez davantage de précision si une autre couche convertit les fractions de jour en heures ou en horodatages. L’arrondi intervient une seule fois, après la multiplication, afin qu’une troncature intermédiaire ne réduise pas discrètement un long parcours. La réponse reprend previous_interval_days, ease_factor, decimal_places et la formule avec next_interval_days. Ces champs rendent les journaux explicites et séparent une décision de planification d’une conversion d’affichage. Aucun minimum d’un jour n’est imposé : un petit produit valide peut rester inférieur à un jour. Aucun bonus, plafond, aléa, ajustement de retard ou traitement spécial de première révision n’est ajouté. Si votre produit applique ces règles, faites-le explicitement et consignez-les séparément. Une même entrée JSON produit toujours la même sortie JSON.

Intégrez le résultat à un parcours de révision durable

Considérez next_interval_days comme un délai de planification, et non comme une date. L’application appelante peut l’ajouter à l’heure de fin de la dernière révision réussie et décider elle-même du traitement des fuseaux horaires, week-ends, séances manquées ou changements de journée. Cette capacité ne lit jamais la date actuelle : une requête identique ne change donc pas parce qu’elle est exécutée plus tard. Dans un service de cartes mémoire, conservez l’intervalle avec l’évaluation et le facteur qui l’ont produit ; cette courte piste d’audit explique les évolutions futures. Dans un tableau de bord scolaire, ne lancez un lot qu’après avoir vérifié les valeurs de chaque apprenant. Lors d’une migration de tableur, comparez les champs de formule aux colonnes existantes avant de remplacer les anciennes données. La version navigateur facilite les contrôles manuels et l’API coûte $0.002 par élément réussi lorsque l’automatisation exige le même contrat déterministe. Corrigez les erreurs de validation plutôt que d’appliquer silencieusement une politique par défaut.