For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/mobile/notifications.md (or send Accept: text/markdown).
Notifications et push
La boîte de réception intégrée, les préférences de canaux et le pipeline push Expo.
La boîte de réception et les préférences de canaux
L'onglet notifications liste les notifications de l'espace de travail depuis GET /api/notifications et les marque comme lues par un PATCH sur l'identifiant de la notification. Paramètres → Notifications modifie les préférences de canaux partagées — emailBilling, emailInvites, inAppProduct — via GET et PATCH sur la vue des préférences de la même route, soit le contrat exact utilisé par l'application Web. Le nombre de non lues apparaît sur l'écran d'accueil.
Enregistrer un appareil pour le push
À la connexion — puis à chaque changement d'espace de travail — l'application demande la permission de notification, résout l'identifiant de projet EAS depuis la configuration de l'application, obtient un jeton push Expo et l'envoie à POST /api/mobile/push-tokens. Android s'enregistre sur le canal par défaut avec une importance élevée.
L'enregistrement rapporte registered, permission_denied ou unavailable et ne lève jamais d'exception — la connexion n'est jamais bloquée par le push. Expo Go et les simulateurs ne peuvent pas terminer l'enregistrement : une couverture réelle exige une build de développement. Le jeton est conservé dans SecureStore (supastack.push.token) pour que la déconnexion puisse le désinscrire avant la destruction du cookie de session.
Envoi côté serveur et accusés de réception
GET liste les jetons du membre, POST insère ou met à jour un jeton sous l'espace de travail actif, et DELETE le révoque — la liste et la révocation restent à portée utilisateur pour qu'un compte sans espace de travail puisse toujours faire le ménage. Chaque utilisateur conserve au plus vingt jetons d'appareil ; en enregistrer un de plus supprime le plus ancien.
Chaque notification d'espace de travail intégrée est aussi poussée au mieux : le serveur envoie à l'API push Expo par paquets de cent, enregistre les tickets ok et supprime immédiatement les jetons DeviceNotRegistered. Le jeton optionnel EXPO_ACCESS_TOKEN, réservé au serveur, ajoute un en-tête Bearer à ces appels et n'est jamais journalisé. Une planification de plateforme réconcilie les accusés toutes les trente minutes et balaie les tickets périmés — elle repose sur le même déclencheur périodique du planificateur que les autres planifications de la plateforme.
# Optional server-only token for authenticated Expo push sends:
# apps/web/.env.local
EXPO_ACCESS_TOKEN=Toucher une notification ouvre une route de l'application
Les expéditeurs joignent un chemin Web sous data.href. L'application le valide — uniquement des chemins absolus commençant par une barre oblique, de longueur bornée et sans traversal — et associe les chemins connus à des routes natives, par exemple /billing vers /settings/billing et /dashboard vers /home. Une notification touchée hors connexion est mise en tampon puis vidée une fois la connexion terminée.
Vérification et dépannage
Testez sur une build de développement : accordez puis refusez la permission, basculez le push sous Paramètres → Notifications — l'écran indique cet appareil comme enabled, disabled ou denied — et touchez une notification à froid puis à chaud. Si la désactivation affiche une erreur, la désinscription côté serveur a échoué et l'appareil reste enregistré jusqu'à sa réussite.