Boucles d'habitude, mécaniques de rétention et notifications push pour une PWA de mathématiques destinée aux enfants

Findings — Part 1: The psychology of habit and retention

1.1 Les trois modèles centraux, et comment ils s’imbriquent

• Signal-Routine-Récompense (Duhigg) [7] : le signal met le cerveau en « mode automatique » ; la routine est le comportement ; la récompense est ce qui fait que le cerveau encode la boucle comme valant la peine d’être répétée. Duhigg documente la boucle via des cas commerciaux (Febreze de P&G) plutôt que des expériences originales — c’est une synthèse de sciences comportementales existantes destinée aux praticiens, pas un modèle évalué par les pairs en lui-même.
• B=MAP (Fogg) [1] : le comportement ne se produit que lorsque la Motivation, l’Aptitude (Ability) et une Invite (Prompt) convergent au même moment. Le corollaire pratique de Fogg — « rends-le minuscule », réduire la friction de l’Aptitude plutôt que d’essayer de fabriquer la Motivation — est la moitié la plus actionnable du modèle pour le design de produit, précisément parce que la motivation est peu fiable et difficile à concevoir, alors que la friction est directement contrôlable.
• Modèle Hook (Eyal) [8] : Déclencheur externe → Action → Récompense variable → Investissement, en se répétant jusqu’à ce que le déclencheur devienne interne (l’ennui, la solitude, un besoin ressenti déclenchent l’appli sans poussée externe). L’auteur du modèle lui-même a plus tard publié un correctif : Indistractable recadre les mêmes mécaniques comme quelque chose à quoi on peut résister, et Eyal s’est publiquement opposé à une régulation générale de la technologie qui crée l’habitude, tandis que des critiques ont établi un parallèle explicite avec la rhétorique de « responsabilité individuelle » de l’industrie du tabac qui masquait un design intentionnellement addictif [9]. Cette critique compte directement pour Math Challenge, un produit pour enfants : les mêmes mécaniques Hook qu’Eyal a vendues aux entreprises d’applis grand public en 2014 sont celles pour lesquelles il a plus tard soutenu qu’un contre-design actif était nécessaire dans un produit destiné aux enfants.

1.2 Le renforcement à ratio variable est le mécanisme porteur

Le calendrier à ratio variable du conditionnement opérant — une récompense après un nombre imprévisible de réponses — produit « un taux de réponse très élevé et persistant » qui résiste à l’extinction plus que les calendriers fixes [11]. C’est explicitement le mécanisme derrière les machines à sous et les loot boxes, et la même source note que « la majorité des jeux vidéo sont conçus autour d’une boucle de compulsion » utilisant ce calendrier [11]. Pour une appli de pratique mathématique, c’est une bifurcation de design, pas un détail : une récompense fixe (même nombre de pièces à chaque bonne réponse) construit une routine ; une récompense variable (multiplicateurs bonus aléatoires, badges de série surprise, déblocages de boîte mystère) construit une boucle de compulsion mécaniquement indiscernable d’une machine à sous. Étant donné que le public cible inclut des enfants, c’est le résultat de psychologie le plus lourd de conséquences pour ce projet.

1.3 Les intentions de mise en œuvre surpassent les rappels vagues

La planification si-alors de Gollwitzer (« Si la situation X, alors je ferai Y ») produit des effets larges et reproduits : +4,1 points de participation électorale, 100 % vs. 53 % d’achèvement des autoexamens des seins, plus grande perte de poids (4,2 kg vs. 2,1 kg sur deux mois), et augmentation de la consommation de fruits/légumes, tout cela par rapport à des groupes témoins avec objectif seul [4]. L’implication de design est concrète : une notification qui dit « Fais ta pratique de maths » est un rappel d’objectif générique ; une notification qui aide la famille ou l’enfant à s’engager à l’avance sur un si-alors spécifique (« Après le petit-déjeuner, fais 5 minutes de Math Challenge ») est une invite d’intention de mise en œuvre et devrait la surpasser. Cela plaide pour un onboarding qui recueille un engagement de moment et de lieu spécifique de la part de la famille, et pour des notifications qui font écho à cet engagement plutôt qu’un texte de réengagement générique.

1.4 Séries : aversion à la perte, coûts irrécupérables et effet de progression dotée

L’aversion à la perte (Kahneman & Tversky) soutient que les pertes sont ressenties environ deux fois plus intensément que des gains équivalents [12]. Les mécaniques de série recadrent l’engagement de la recherche de gain (« gagner plus ») vers l’évitement de la perte (« ne pas perdre ce que tu as »), ce qui est le levier psychologiquement le plus puissant [12]. Le sophisme du coût irrécupérable — continuer à investir à cause de ce qui a déjà été investi, en partie pour éviter de « paraître gaspilleur » — amplifie cela : une série de 47 jours n’est pas juste un nombre, c’est un investissement irrécupérable que l’utilisateur (ou le parent, par procuration) ne veut pas avoir gâché [13]. Cette famille d’effets (aversion à la perte, coût irrécupérable, et l’effet de progression dotée étroitement lié issu de la recherche sur les programmes de fidélité, où les utilisateurs qui reçoivent une longueur d’avance vers un objectif l’atteignent plus vite que ceux qui partent de zéro) est précisément le mécanisme sur lequel sont construits la série, les jetons de gel et les achats de réparation de série de Duolingo [15].

Duolingo comme exemple travaillé [15] : série (avec une variante sociale « Friend Streak »), ligues hebdomadaires classant des cohortes allant jusqu’à 30 utilisateurs, badges, et un système de notification personnalisé par algorithme bandit qui sélectionne quelle relance chaque utilisateur reçoit. La persona de « rappel agressif » de sa propre mascotte est devenue un mème, que Duolingo a délibérément exploité dans son marketing. L’inconvénient documenté : des critiques de l’enseignement des langues disent que la gamification « a mené à la triche, au piratage, et a incité des stratégies de jeu qui entrent en conflit avec l’apprentissage réel », et une étude financée par Duolingo en 2023 a trouvé que ses apprenants d’anglais « n’ont pas significativement appris beaucoup de grammaire » [15]. La leçon pour Math Challenge : les métriques d’engagement et les résultats d’apprentissage peuvent diverger, et une série optimisée purement pour les comptes d’ouverture quotidienne peut mesurablement évincer l’objectif pédagogique réel — un risque qui compte davantage, pas moins, dans un produit pour enfants où un parent confie à l’appli du temps d’apprentissage, pas seulement de l’attention.

1.5 Efficacité, fréquence et lassitude des notifications push

Des données de terrain directement reproductibles sur les courbes de désabonnement par fréquence de notification se sont révélées plus difficiles à sourcer en direct dans cette session que la littérature de psychologie ci-dessus (plusieurs URL de rapports du secteur — Airship, OneSignal, Business of Apps — ont retourné 404/403 pendant cette passe de recherche et ne sont donc pas citées ci-dessous ; c’est un manque, pas un résultat nul, et il est signalé dans les Questions ouvertes). Ce qui est vérifiable à partir de sources techniques/comportementales primaires :

• La demande de permission elle-même est la décision au plus fort effet de levier. Les propres directives de développeur de Chrome sont explicites : « La pire chose que vous puissiez faire est de montrer la boîte de dialogue de permission aux utilisateurs dès qu’ils atterrissent sur votre site. Ils n’ont aucun contexte… bloquer les permissions à ce stade par frustration n’est pas rare » [6]. Une fois qu’un utilisateur bloque la permission, le site ne peut pas re-demander de façon programmatique — l’utilisateur doit aller dans les paramètres du navigateur pour la changer [6]. Cela rend la première demande plus proche d’un coup unique que d’une ressource à dépenser facilement.
• Le motif recommandé est un flux de demande douce / double permission : montrer d’abord une explication in-app de la valeur, et ne déclencher l’invite native du navigateur qu’après que l’utilisateur ait accepté cette explication, plus donner aux utilisateurs un moyen toujours visible de gérer/désactiver les notifications plus tard plutôt que de forcer une décision tout-ou-rien au premier contact [6].
• La recherche psychologique sur l’anticipation de récompense en ratio variable [11] implique qu’un texte de notification qui surprend occasionnellement (« le bonus mystère du jour est disponible ») surperformera un texte monotone en taux d’ouverture — mais c’est exactement le mécanisme signalé au §1.2 comme adjacent à la compulsion, donc il devrait être utilisé, si tant est qu’il le soit, avec parcimonie et transparence plutôt qu’exploité.

Findings — Part 2: The technical reality of web push in 2026

2.1 iOS/iPadOS Safari — exigences strictes

Selon le propre billet de blog d’ingénierie de WebKit sur Web Push pour les applis web [2] :

• Version 16.4 minimum du système d’exploitation. Aucun web push du tout sur iOS/iPadOS antérieur.
• L’installation sur l’écran d’accueil est obligatoire. Le manifeste doit déclarer display: "standalone" ou "fullscreen", et l’utilisateur doit ajouter l’appli via Partager → « Sur l’écran d’accueil ». Web Push ne fonctionne pas pour le même site ouvert dans des onglets Safari ordinaires ou via un marque-page — l’installation est un verrou strict, pas une préférence.
• La permission doit suivre un geste utilisateur direct (par ex. appuyer sur un bouton « S’abonner ») — Apple n’autorise pas les invites de permission ambiantes/automatiques.
• Basé sur les standards : utilise la même pile W3C Web Push que macOS Ventura/Safari, s’appuyant sur l’infrastructure Apple Push Notification service, et — notamment — ne requiert aucune adhésion au Apple Developer Program pour envoyer du web push, contrairement au push iOS natif.
• L’API de badge est prise en charge pour les applis web installées (navigator.setAppBadge() / clearAppBadge()), et les notifications respectent les modes Focus du système, avec des paramètres par appli synchronisés entre les appareils de l’utilisateur via le champ id du manifeste.
• Les données de caniuse corroborent le verrou de version : iOS Safari ne montre qu’un support partiel de 16,4 à la version la plus récente suivie au moment de cette recherche, contre un support complet sur macOS Safari depuis la version 18 [3]. Ce marqueur « partiel » est une réserve réelle et actuelle, pas une donnée périmée — traiter toute affirmation de seconde main de « support iOS complet » avec suspicion jusqu’à re-vérification via caniuse ou les propres billets de WebKit.

2.2 Android / Chrome — support le plus large, aucun verrou d’installation

La Push API est « Largement disponible » (référence commune inter-navigateurs) depuis mars 2023 [5], et caniuse montre un support complet sur Chrome pour Android et les équivalents Chrome/Firefox/Samsung Internet de bureau, atteignant environ 95 % de la part d’usage globale des navigateurs en incluant le support partiel [3]. Contrairement à iOS, l’installation sur l’écran d’accueil n’est pas requise pour recevoir du push sur Android Chrome — une page avec un service worker enregistré et actif peut s’abonner et recevoir du push tout en fonctionnant comme un onglet de navigateur ordinaire, bien que les PWA installées/en mode standalone obtiennent une expérience de notification/lancement au tap plus nativement ressentie. Chrome n’impose aucune limite de quota sur le volume de messages push ; Firefox impose bien un quota (rafraîchi à chaque visite du site) sauf si le message produit de façon fiable une notification visible [5].

2.3 Bureau — mature, mais pas également implémenté

Desktop Safari n’a atteint le support complet de la Push API qu’à Safari 18 (partiel en 16,1–17,6) [3] ; Chrome desktop a un support complet depuis la v50, Firefox depuis la v44 [3]. Le bureau ne porte généralement pas l’exigence d’Apple d’installation sur l’écran d’accueil — l’asymétrie principale est spécifiquement macOS Safari, qui a hérité des mêmes règles de geste de permission et (pour les versions les plus récentes) d’intégration au mode Focus que son équivalent iOS [2].

2.4 Notification Triggers / notifications locales programmées — pas viable en 2026

Une API pour programmer des notifications se déclenchant à un moment futur sans aller-retour réseau (Notification.showTrigger, faisant partie d’une capacité proposée « Notification Triggers ») a été explorée comme essai d’origine réservé à Chrome il y a plusieurs années mais n’a jamais atteint de consensus inter-navigateurs ni d’implémentation stable, expédiée, sur voie de standardisation, utilisable en production. Les tentatives dans cette session de recherche de localiser une spécification actuelle et en direct ou une page de fonctionnalité expédiée pour cela ont retourné des erreurs 404 à la fois sur l’URL du brouillon W3C et l’URL du propre billet de blog de Chrome — cohérent avec le fait qu’elle ait été mise de côté plutôt que promue au rang de véritable standard. Conséquence de design : ne construire aucune fonctionnalité (par ex. « rappelle-moi à exactement 4h de l’après-midi dans le fuseau horaire de cet appareil même si l’appli n’ouvre jamais le réseau ») qui dépende de notifications locales programmées côté client. Chaque rappel programmé dans Math Challenge a besoin d’un vrai Web Push déclenché par le serveur, qui à son tour a besoin d’un abonnement actif et, sur iOS, d’une PWA installée.

2.5 Envoyer du web push à l’échelle, côté Cloudflare

La bibliothèque Node.js de référence pour Web Push (web-push de web-push-libs) est construite sur les API Buffer et crypto de Node et n’est pas documentée comme sensible au runtime edge/serverless d’origine [14]. Deux chemins natifs à Cloudflare rendent cela réalisable au sein de la pile Workers déjà existante plutôt que de nécessiter un serveur Node séparé :

1. API Web Crypto native — Cloudflare Workers prend entièrement en charge l’interface SubtleCrypto standard [17], suffisante pour signer à la main le JWT ES256 (ECDSA P-256) de VAPID et le chiffrement de charge utile AES-GCM/ECDH que Web Push requiert, sans aucun drapeau de compatibilité Node.
2. node:crypto sous nodejs_compat — depuis l’entrée du changelog Cloudflare d’avril 2025, les API complètes node:crypto et node:tls sont disponibles dans les Workers lorsque le drapeau de compatibilité nodejs_compat est activé [16], ce qui signifie que le paquet npm web-push existant (ou un fork proche) peut probablement fonctionner directement dans un Worker plutôt que de nécessiter une réécriture contre SubtleCrypto brut — vaut un petit spike pour confirmer avant de s’engager sur l’une ou l’autre approche.

Les deux chemins gardent l’envoi de push à l’intérieur de la pile Workers/Queues déjà utilisée ailleurs dans ce projet (selon AGENTS.md §5.2), évitant un nouveau service non-Cloudflare juste pour déclencher des notifications.

Tableau de support des plateformes

Capacité	iOS/iPadOS Safari	Android Chrome	Bureau (Chrome/Firefox/Safari)
Push API (push serveur avec appli fermée)	Partiel ; nécessite 16,4+ [3]	Complet, référence depuis 2023 [5]	Complet sur Chrome (v50+)/Firefox (v44+) ; Safari seulement depuis v18, partiel 16,1–17,6 [3]
Doit être installée sur l’écran d’accueil / standalone	Oui, obligatoire [2]	Non — fonctionne depuis un onglet de navigateur avec un service worker actif	Non (le bureau n’a pas de verrou « écran d’accueil » ; macOS Safari hérite de la même règle de geste de permission)
Règles d’invite de permission	Doit suivre un geste utilisateur direct ; aucune invite ambiante [2]	Doit suivre un geste utilisateur selon les bonnes pratiques Chrome [6] ; moins strictement appliqué par l’OS que sur iOS	Même bonne pratique, non appliquée par l’OS
Re-demander après blocage par l’utilisateur	Pas possible de façon programmatique ; l’utilisateur doit le changer dans les Réglages système [2][6]	Pas possible de façon programmatique ; doit être changé dans les paramètres de site du navigateur [6]	Idem
Badge (compteur de badge sur l’icône de l’appli)	Pris en charge pour les applis web installées [2]	Pris en charge via l’API de badge sur les PWA installées	Variable ; moins couramment affiché sur le chrome de l’OS de bureau
Push silencieux / discret / arrière-plan uniquement	Le traitement en arrière-plan avant permission est possible [2] ; aucune garantie séparée de « push silencieux » documentée	Traitement standard des événements push en service worker ; aucune notification n’est optionnelle si les données seules, mais en montrer une est effectivement requis par la politique du navigateur pour éviter l’abus de « push silencieux »	Traitement standard des événements push en service worker
Limites de volume de messages	Régies par APNs via le service de push de WebKit, non documentées séparément ici	Aucun quota imposé par Chrome [5]	Firefox applique un quota sauf si les messages produisent des notifications visibles [5]
Notifications programmées/locales sans réseau (Notification Triggers)	Non disponible — aucune preuve d’un standard expédié en 2026	Non disponible	Non disponible

Implications de design pour Math Challenge

1. Faire de la première demande de permission une demande douce, pas une demande forte. Ne jamais déclencher l’invite native du navigateur au premier chargement. Montrer un explicatif in-app (« Nous rappellerons [enfant] une fois par jour quand c’est l’heure de la pratique ») avec un « Pas maintenant » clair, et ne déclencher la vraie invite OS qu’après opt-in explicite — une invite refusée ne peut pas être re-montrée de façon programmatique sur aucune plateforme [2][6].
2. Verrouiller l’étape « installer sur l’écran d’accueil » avant de promettre du push sur iOS. Étant donné que le Web Push iOS est indisponible en dehors d’une PWA installée [2], le flux d’opt-in aux notifications sur iOS doit d’abord guider le parent à travers « Ajouter à l’écran d’accueil », ou doit dégrader silencieusement vers l’absence de push et s’appuyer sur des rappels in-app / email à la place.
3. Adresser les notifications au parent par défaut, pas à l’enfant. Étant donné que les mécaniques d’aversion à la perte/série sont le levier le plus proche de la compulsion disponible (§1.2, §1.4), et que le public inclut des enfants, le défaut le plus sûr est : les relances de série en danger et de réengagement vont vers l’appareil/canal enregistré du parent, l’enfant ne recevant que des invites in-app (pas push) pendant une session active.
4. Plafonner le push à une notification par jour, limite stricte, avec un snooze/mute in-app facile. Aucune courbe de fréquence-vs-désabonnement du secteur n’a pu être re-vérifiée de façon indépendante dans cette passe (signalé dans les Questions ouvertes), donc pécher par prudence : une relance quotidienne, jamais plus, plus un contrôle familial toujours visible pour la réduire ou la faire taire — reflétant la conclusion « donner une sortie facile ou les utilisateurs prennent l’option nucléaire » des propres directives de Chrome [6].
5. Utiliser un texte d’intention de mise en œuvre, pas un texte de réengagement générique. À l’onboarding, demander à la famille de choisir un moment/lieu concret (« après le petit-déjeuner », « avant de dormir »). Le texte de notification devrait faire écho à cet engagement (« C’est [heure] — le moment maths de [enfant] ») plutôt qu’un simple « Reviens jouer ! », cohérent avec les tailles d’effet si-alors du §1.3 [4].
6. Utiliser une récompense fixe et transparente pour la boucle centrale ; réserver la variabilité aux événements bonus rares et clairement étiquetés. Étant donné que la récompense à ratio variable est mécaniquement identique au design des machines à sous/loot boxes [11], la récompense de bonne réponse du quotidien (pièces, étoiles) devrait être prévisible. Réserver tout élément surprise (une « étoile mystère » une fois par semaine) à quelque chose de peu fréquent, clairement borné, et jamais monétisé.
7. Ne pas vendre de réparation ou d’assurance de série. L’aversion à la perte fait déjà le travail motivationnel gratuitement [12][13] ; faire payer de l’argent pour éviter de perdre une série convertit une mécanique psychologique en monétisation directe de l’aversion à la perte d’un enfant ou d’une famille, ce qui va plus loin que le propre modèle de Duolingo et vaut la peine d’être évité sur cette seule base.
8. Traiter le compteur de série lui-même comme quelque chose qu’un parent peut réinitialiser/pardonner sans pénalité. La pression de coût irrécupérable (§1.4) peut faire qu’une série cassée ressemble à une raison d’abandonner complètement (« on l’a déjà perdue, à quoi bon ») ; une affordance en un tap « on est toujours là, on recommence en douceur » atténue la falaise du tout-ou-rien que créent les mécaniques de série pures.
9. Construire chaque rappel programmé comme un Web Push envoyé par le serveur, jamais une notification locale programmée côté client. Le §2.4 n’a trouvé aucune API viable de type Notification Triggers en 2026 — toute fonctionnalité « rappelle-moi à 4h de l’après-midi » a besoin d’un serveur (Cloudflare Worker + Queues/cron) qui pousse au bon moment par utilisateur, pas d’une promesse que le client peut tenir hors ligne.
10. Envoyer le push depuis Cloudflare Workers en utilisant Web Crypto (ou node:crypto sous nodejs_compat) plutôt que de monter un serveur push Node séparé. Les deux chemins sont confirmés disponibles sur Workers aujourd’hui [16][17] ; prototyper les deux contre la bibliothèque web-push existante avant de choisir, puisque la compatibilité avec cette bibliothèque spécifiquement (vs. VAPID fait à la main) n’a pas été confirmée de façon indépendante dans cette passe.
11. Concevoir le contenu de notification pour survivre gracieusement au verrou d’installation d’iOS. Pour la fraction d’utilisateurs iOS qui n’installent jamais sur l’écran d’accueil, se replier sur l’email ou une bannière in-app à la prochaine ouverture plutôt qu’une promesse brisée de « tu seras rappelé » — le verrou du §2.1 est absolu, pas une permission que l’appli peut contourner.
12. Distinguer « habitude » de « compulsion » avec une métrique interne explicite, pas seulement DAU/longueur de série. Étant donné la propre tension documentée de Duolingo entre engagement et résultats d’apprentissage [15], suivre une métrique pédagogique (par ex. problèmes maîtrisés, amélioration du taux d’erreur) aux côtés des métriques de série/ouverture, et traiter une série en hausse avec une métrique de maîtrise plate ou en baisse comme un signal d’alerte, pas une victoire.
13. Respecter les modes Focus et les heures calmes par défaut. iOS intègre déjà le push aux modes Focus du système [2] ; Math Challenge devrait en plus appliquer ses propres heures calmes au niveau de l’appli (par ex. pas de push avant 7h du matin ou après 8h du soir heure locale) quelle que soit la plateforme, puisque toutes les plateformes ne s’intègrent pas automatiquement à Focus.
14. Faire de la limite de temps d’écran parentale et de la cadence de notification le même levier, pas deux réglages séparés. Étant donné que la prémisse du produit est une limite quotidienne définie par le parent, le plan de notification devrait faire atterrir par défaut sa relance unique quotidienne près du début de la fenêtre approuvée par le parent, opérationnalisant la conclusion d’intention de mise en œuvre (§1.3) plutôt que de pousser à une heure arbitraire optimale pour le marketing.

Questions ouvertes pour le propriétaire du projet

1. Les notifications push devraient-elles être parent uniquement, enfant uniquement (sur l’appareil propre de l’enfant), ou les deux avec un contenu différent, étant donné que le foyer peut avoir un appareil partagé ou spécifique à l’enfant ?
2. Quel est le plafond acceptable — une push par jour est-elle acceptable, ou certains jours devraient-ils en avoir zéro par politique (par ex. push uniquement en cas de jour manqué, jamais un jour déjà complété) ?
3. La mécanique de « bonus surprise » devrait-elle exister du tout, ou le chevauchement du mécanisme de compulsion avec le design des machines à sous/loot boxes (§1.2) l’exclut-il entièrement pour un produit destiné aux enfants, quelle que soit la façon dont il est borné ?
4. Une mécanique de réparation/gel de série est-elle voulue du tout (même jamais vendue contre de l’argent), ou les séries cassées devraient-elles toujours redémarrer proprement pour éviter la pression de coût irrécupérable sur un enfant ?
5. Cette passe de recherche n’a pas pu re-vérifier de façon indépendante les données actuelles du secteur sur fréquence-vs-désabonnement (les sources Airship/OneSignal/Business-of-Apps ont retourné 404/403) — vaut-il la peine de faire une passe de recherche de suivi spécifiquement pour extraire ces données d’un miroir accessible, ou le défaut prudent d’une push par jour au point 4 ci-dessus est-il acceptable sans cela ?
6. Math Challenge devrait-il engager du temps d’ingénierie maintenant pour prototyper web-push basé sur node:crypto sur Workers vs. VAPID Web Crypto fait à la main, étant donné que les deux sont techniquement disponibles mais qu’aucun n’a été validé de bout en bout dans cette passe de recherche ?