Expression de besoin — PD-105¶
Story : Implémenter push notifications Epic : MOBILE-IOS (PD-195) Date : 2026-02-10 Auteur : Claude (orchestrateur) + PO
1. Contexte¶
ProbatioVault est une application de coffre-fort probatoire. Les utilisateurs stockent, scellent et partagent des documents ayant une valeur juridique. La confiance repose sur la traçabilité des événements probatoires.
Actuellement, l'application iOS ne dispose d'aucun mécanisme de notification push. L'utilisateur doit ouvrir l'application pour découvrir les événements survenus sur ses documents.
2. Problème¶
Sans notifications push : - L'utilisateur ignore qu'un document lui a été partagé - L'utilisateur croit qu'un scellement a réussi alors qu'il a échoué - L'utilisateur rate des échéances critiques (fin de période WORM, expiration d'accès) - L'utilisateur ne peut pas anticiper une perte de droits
Le silence du système est interprété comme un succès ou une stabilité, ce qui est dangereux dans un contexte probatoire.
3. Doctrine des notifications probatoires¶
3.1 Principe directeur¶
Une notification a du sens uniquement si elle informe l'utilisateur d'un : - Changement d'état probatoire - Changement de droits ou de capacité - Risque, échec ou anomalie - Point de non-retour temporel - Changement de relation entre parties
Tout le reste est du bruit.
3.2 Catégories de notifications¶
| Catégorie | Exemples | Criticité |
|---|---|---|
| Échec/dégradation probatoire | Échec de scellement, horodatage partiel, ancrage différé | CRITIQUE |
| Révocation d'accès | Accès retiré, révocation automatique (expiration, incident) | CRITIQUE |
| Modification de périmètre | Durée raccourcie, droits réduits | HAUTE |
| Échéance critique imminente | Fin période WORM, dernière opportunité de prolongation | HAUTE-CRITIQUE |
| Rupture de continuité probatoire | Perte de symétrie, fin de détention conjointe, transfert de propriété | CRITIQUE |
| Action engageante d'un tiers | Refus explicite, renonciation, déclaration formelle | HAUTE-CRITIQUE |
| Anomalie de sécurité | Révocation device, tentatives bloquées, changement de clé | HAUTE |
| Changement de statut légal | Nouvelle obligation, changement de durée légale, requalification | HAUTE |
3.3 Ce qui NE doit PAS être notifié¶
- Ouverture répétée d'un document
- Téléchargement sans impact probatoire
- Accès techniques sans conséquence
- Lecture implicite non déclarée
Surcharge = perte de confiance
4. Objectifs¶
4.1 Objectif principal¶
Permettre à l'utilisateur d'être informé en temps réel des événements probatoires significatifs, avec un niveau de détail adapté à la criticité.
4.2 Objectifs secondaires¶
- Maintenir la confiance : L'utilisateur sait que le système agit pour lui
- Permettre l'action : Les notifications mènent à une décision ou une action
- Respecter l'attention : Zéro notification sans valeur probatoire
5. Périmètre¶
5.1 Phase 1 (PD-105)¶
| Élément | Inclus | Exclu |
|---|---|---|
| Plateforme | iOS (APNs) | Android (FCM) — phase 2 |
| Type | Silent + Alert | Rich notifications |
| Handlers | Nouveau doc, scellement, partage | Tous les autres |
| Stockage | Historique in-app + badges | Synchronisation cross-device |
5.2 Décomposition technique¶
| Composant | Description |
|---|---|
| APNs Config | Configuration Apple Push Notification service (certificats, entitlements) |
| Backend endpoint | API pour enregistrer/révoquer les device tokens |
| Dispatch service | Service backend envoyant les notifications APNs |
| Client handlers | Gestion des notifications reçues (foreground, background, killed) |
| Centre de notifications | UI in-app listant l'historique des notifications |
| Badges | Compteur sur l'icône de l'application |
6. Exigences fonctionnelles¶
F-105-01 : Enregistrement du device token¶
L'application DOIT enregistrer son device token APNs auprès du backend lors de la première connexion et après chaque changement de token.
F-105-02 : Réception de notifications silencieuses¶
L'application DOIT pouvoir recevoir des notifications silencieuses pour synchroniser les données en arrière-plan sans déranger l'utilisateur.
F-105-03 : Réception de notifications alertes¶
L'application DOIT afficher des notifications alertes pour les événements critiques (échecs, révocations, échéances).
F-105-04 : Historique des notifications¶
L'application DOIT maintenir un historique des notifications reçues, consultable depuis un centre de notifications in-app.
F-105-05 : Compteur badges¶
L'application DOIT afficher un badge sur l'icône indiquant le nombre de notifications non lues.
F-105-06 : Navigation contextuelle¶
Lorsque l'utilisateur tape sur une notification, l'application DOIT naviguer vers le contexte approprié (document, partage, événement).
F-105-07 : Gestion des permissions¶
L'application DOIT demander la permission notifications au moment opportun, avec un message expliquant la valeur probatoire.
7. Exigences non fonctionnelles¶
NFR-105-01 : Latence¶
Les notifications DOIVENT être envoyées dans un délai inférieur à 5 secondes après l'événement déclencheur (côté backend).
NFR-105-02 : Fiabilité¶
Le système DOIT garantir un taux de livraison APNs supérieur à 99% pour les notifications alertes.
NFR-105-03 : Sécurité¶
Les payloads de notifications NE DOIVENT PAS contenir de données sensibles (titres de documents, identités). Seuls des identifiants opaques sont transmis.
NFR-105-04 : Persistence¶
L'historique des notifications DOIT être stocké localement sur le device (SecureStore ou SQLite chiffré).
NFR-105-05 : Économie de batterie¶
Les notifications silencieuses DOIVENT respecter les quotas iOS pour éviter le throttling APNs.
8. Contraintes¶
- Expo SDK 52 : Utiliser
expo-notificationspour la compatibilité Expo - Certificats APNs : Nécessite un certificat p8 (APNs Auth Key) configuré dans le backend
- Entitlements : Activer les push notifications dans les capabilities Xcode
- EAS Build : Les notifications ne fonctionnent pas avec Expo Go, nécessite un build EAS
- Backend NestJS : Le dispatch service doit s'intégrer à l'architecture existante
9. Critères de succès¶
| Critère | Mesure |
|---|---|
| Notifications reçues en foreground | 100% des alertes affichées |
| Notifications reçues en background | >95% traitées correctement |
| Latence moyenne | <5s entre événement et réception |
| Badges cohérents | Compteur = nombre réel de non-lus |
| Navigation contextuelle | 100% des taps mènent au bon écran |
10. Questions ouvertes¶
- Priorité des types : Quels événements spécifiques pour la phase 1 ? (ex: seulement échec scellement + nouveau partage)
- Localisation : Faut-il localiser les messages de notification (FR/EN) ?
- Opt-out granulaire : L'utilisateur peut-il désactiver certaines catégories ?