PD-105 — Implementer push notifications¶

1. Objectif¶

Definir le contrat fonctionnel et non fonctionnel des notifications push iOS pour les evenements probatoires significatifs, afin de garantir :

• l'information en temps quasi reel des changements probatoires,
• la capacite d'action de l'utilisateur depuis la notification,
• la non-divulgation de donnees sensibles dans les payloads push,
• la tracabilite locale via un centre de notifications in-app et un badge coherent.

Elements non directement testables et donc hors perimetre contractuel :

• perception subjective de "confiance" par l'utilisateur,
• appreciation qualitative du style redactionnel des messages.

2. Perimetre / Hors perimetre¶

Inclus¶

• Plateforme iOS uniquement, transport APNs.
• Notifications de type silent et alert (sans rich notifications).
• Flux metier phase 1 : nouveau document, scellement, partage.
• Enregistrement et revocation du device token cote backend.
• Reception et traitement des notifications en foreground, background et app terminee.
• Historique local des notifications dans un centre in-app.
• Badge iOS representant le nombre de notifications non lues.
• Navigation contextuelle au tap sur notification.
• Demande de permission notifications avec message de valeur probatoire.

Exclu¶

• Android / FCM.
• Synchronisation cross-device de l'historique des notifications.
• Rich notifications (media, actions avancees, extensions).
• Notifications sans valeur probatoire (ouverture repetee, telechargement sans impact, acces techniques sans consequence, lecture implicite non declaree).
• Mesure de satisfaction utilisateur (hors perimetre, non testable de maniere deterministe).

3. Definitions¶

• APNs : Apple Push Notification service.
• Device token : identifiant APNs du device/app/environnement permettant l'acheminement d'une notification.
• Notification silent : push sans alerte visuelle/sonore, destinee a une synchronisation en arriere-plan.
• Notification alert : push avec alerte utilisateur visible (et badge eventuel).
• Evenement probatoire significatif : evenement appartenant a au moins une categorie de la doctrine (echec/degradation, revocation d'acces, modification de perimetre, echeance critique, rupture de continuite, action engageante d'un tiers, anomalie de securite, changement de statut legal).
• CRITIQUE : niveau de criticite eleve necessitant une alerte utilisateur immediate via notification alert.
• HAUTE-CRITIQUE : niveau de criticite maximal necessitant une alerte utilisateur immediate via notification alert.
• HAUTE : niveau de criticite important traite en phase 1 sans alerte utilisateur immediate.
• Donnee sensible : information nominative ou contextuelle exploitable directement (ex. titre document, identite explicite, contenu juridique).
• Identifiant opaque : identifiant non semantique ne permettant pas d'inferer la donnee metier sans appel backend autorise.
• Notification lue : notification marquee comme lue lorsque l'utilisateur ouvre le detail de cette notification dans le centre in-app.

Catalogue exhaustif des evenements phase 1 et criticite associee :

4. Invariants (non negociables)¶

5. Flux nominaux¶

FN-105-01 — Enregistrement initial du device token¶

1. Etant donne un utilisateur authentifie sur iOS, l'application obtient le device token APNs.
2. L'application transmet le token au backend avec son contexte minimal (user, device, environnement).
3. Le backend confirme l'enregistrement.
4. Le token est marque actif pour ce couple utilisateur/device.

Resultat attendu : le device est eligible a la reception de notifications de la story.

FN-105-02 — Rotation du device token¶

1. Le token APNs change.
2. L'application detecte le changement et transmet le nouveau token.
3. Le backend invalide l'ancien token et active le nouveau.

Resultat attendu : aucun envoi futur sur token obsolete.

FN-105-03 — Reception d'une notification silent¶

1. Un evenement probatoire significatif necessitant sync silencieuse est declenche.
2. Le backend envoie une notification silent.
3. L'application traite la synchronisation en arriere-plan.
4. L'historique in-app est mis a jour selon politique de phase 1.

Resultat attendu : donnees locales synchronisees sans interruption utilisateur visible.

FN-105-04 — Reception d'une notification alert¶

1. Un evenement CRITIQUE ou HAUTE-CRITIQUE est declenche.
2. Le backend envoie une notification alert.
3. iOS affiche l'alerte a l'utilisateur (selon permissions systeme).
4. L'application enregistre l'evenement dans le centre in-app en non lu.
5. Le badge est incremente pour rester coherent avec les non lus.

Resultat attendu : information visible + tracabilite locale + badge coherent.

FN-105-05 — Consultation centre de notifications¶

1. L'utilisateur ouvre le centre in-app.
2. La liste des notifications historisees est affichee du plus recent au plus ancien.
3. La consultation marque les elements selon la regle de lecture definie.
4. Le badge est recalcule immediatement.

Resultat attendu : etat lu/non lu coherent entre UI in-app et badge iOS.

FN-105-06 — Navigation contextuelle sur tap¶

1. L'utilisateur tape une notification (systeme ou centre in-app).
2. L'application resolve le contexte metier cible via identifiants opaques.
3. L'application ouvre l'ecran cible (document, partage, evenement) ou fallback detail notification si contexte indisponible.

Resultat attendu : aucun tap sans issue fonctionnelle.

FN-105-07 — Demande de permission notifications¶

1. Avant le premier besoin d'alerte utilisateur, l'application presente la demande de permission.
2. Le message explicite la valeur probatoire de l'activation.
3. Le choix utilisateur est conserve par le systeme iOS.

Resultat attendu : consentement explicite et tracable cote systeme.

5b. Diagrammes¶

Diagramme d'etats — Cycle de vie du device token (INV-105-03, INV-105-04)¶

stateDiagram-v2
    [*] --> Unregistered
    Unregistered --> Active : Enregistrement initial\n(FN-105-01, INV-105-03)
    Active --> Active : Rotation token\n(FN-105-02, INV-105-03)
    Active --> Invalid : Token rejete par APNs\n(ERR-105-02)
    Active --> Revoked : Deconnexion explicite\n(INV-105-04)
    Invalid --> Active : Re-enregistrement\n(ERR-105-02)
    Revoked --> Active : Nouvelle authentification\n(INV-105-03)
    Invalid --> [*]
    Revoked --> [*]

Diagramme d'etats — Cycle de vie d'une notification locale (INV-105-08, INV-105-09)¶

stateDiagram-v2
    [*] --> Received : Notification recue\n(INV-105-08)
    Received --> Unread : Historisee localement\n(UUID v4 + horodatage)
    Unread --> Read : Ouverture detail in-app\n(FN-105-05)
    Unread --> Expired : Retention > 90 jours\n(INV-105-14)
    Read --> Expired : Retention > 90 jours\n(INV-105-14)
    Expired --> [*]

    note right of Unread : Badge iOS = count(Unread)\n(INV-105-09)

Diagramme de sequence — Emission et reception d'une notification alert (INV-105-06, INV-105-07, INV-105-11)¶

sequenceDiagram
    participant Backend
    participant APNs
    participant iOS as iOS System
    participant App as ProbatioVault App
    participant Store as Historique local

    Note over Backend: Evenement probatoire\nCRITIQUE / HAUTE-CRITIQUE\n(INV-105-06)

    Backend->>Backend: Construire payload\n(identifiants opaques uniquement, INV-105-07)
    Backend->>APNs: Envoi notification alert\n(p95 <= 5s, INV-105-11)
    APNs-->>Backend: Acknowledgement

    alt App en foreground
        APNs->>App: Notification recue
        App->>Store: Historiser (UUID v4, type, timestamp, non lu)\n(INV-105-08)
        App->>iOS: Mettre a jour badge = count(non lus)\n(INV-105-09)
        App->>App: Afficher banniere in-app
    else App en background / terminee
        APNs->>iOS: Notification systeme
        iOS->>iOS: Afficher alerte + badge
        iOS->>App: Reveil background (si autorise)
        App->>Store: Historiser (UUID v4, type, timestamp, non lu)\n(INV-105-08)
    end

Diagramme de sequence — Enregistrement et rotation du device token (INV-105-03, INV-105-04)¶

sequenceDiagram
    participant User as Utilisateur
    participant App as ProbatioVault App
    participant APNs
    participant Backend

    User->>App: Authentification
    App->>APNs: Demande device token
    APNs-->>App: Device token

    App->>Backend: POST /device-tokens {token, device, env}\n(INV-105-03)
    Backend-->>App: 201 Created (token actif)

    Note over APNs: Token change (rotation systeme)
    APNs->>App: Nouveau device token
    App->>Backend: PUT /device-tokens {nouveau token}\n(INV-105-03)
    Backend->>Backend: Invalider ancien token
    Backend-->>App: 200 OK (nouveau token actif)

    Note over User: Deconnexion explicite
    User->>App: Logout
    App->>Backend: DELETE /device-tokens\n(INV-105-04)
    Backend->>Backend: Revoquer token
    Backend-->>App: 200 OK (token revoque)

6. Cas d'erreur¶

7. Criteres d'acceptation (testables)¶

8. Scenarios de test (Given / When / Then)¶

TC-105-01 — Enregistrement initial token (CA-105-01, INV-105-03)¶

Given un utilisateur iOS authentifie pour la premiere fois et un token APNs valide
When l'application initialise le service notifications
Then un enregistrement token actif est visible cote backend pour ce user/device.

TC-105-02 — Rotation token (CA-105-02, INV-105-03)¶

Given un ancien token actif et un nouveau token emis par APNs
When l'application detecte le changement et soumet le nouveau token
Then l'ancien token est inactif et le nouveau token est actif.

TC-105-03 — Silent sans perturbation (CA-105-03, INV-105-05)¶

Given une notification silent valide pour un evenement de sync
When le device recoit la push en background
Then aucune alerte visuelle/sonore n'est produite et la sync est executee.

TC-105-04 — Alert critique affichee (CA-105-04, INV-105-06)¶

Given un evenement de criticite CRITIQUE
When le backend emet une notification alert
Then iOS affiche l'alerte et une entree non lue est ajoutee au centre in-app.

TC-105-05 — Cohesion badge/non lu (CA-105-05, INV-105-09)¶

Given trois notifications non lues dans le centre in-app
When l'application recalcule le badge
Then la valeur badge iOS est 3.

TC-105-06 — Navigation contextuelle succes (CA-105-06, INV-105-10)¶

Given une notification avec contexte resolvable
When l'utilisateur tape la notification
Then l'application ouvre l'ecran cible attendu.

TC-105-07 — Navigation contextuelle fallback (CA-105-06, INV-105-10)¶

Given une notification dont le contexte n'est plus disponible
When l'utilisateur tape la notification
Then l'application ouvre l'ecran detail notification avec motif d'indisponibilite.

TC-105-08 — Confidentialite payload (CA-105-07, INV-105-07)¶

Given un lot de payloads push emis en preproduction
When un audit de contenu est execute
Then aucune donnee sensible n'est detectee et seuls des identifiants opaques sont presents.

TC-105-09 — Latence backend (CA-105-08, INV-105-11)¶

Given des evenements declencheurs horodates
When le backend emet les pushes APNs
Then le delai evenement->tentative APNs respecte <= 5s selon seuils definis.

TC-105-10 — Fiabilite livraison (CA-105-09, INV-105-12)¶

Given une fenetre glissante de 30 jours de notifications alert
When le taux de livraison APNs est calcule
Then le taux est >= 99%.

TC-105-11 — Filtre anti-bruit (CA-105-11, INV-105-02)¶

Given des evenements exclus (ouverture repetee, telechargement sans impact, acces technique sans consequence)
When le moteur de dispatch evalue l'emission
Then aucune notification n'est envoyee.

TC-105-12 — Contexte de validation EAS (CA-105-10, INV-105-13)¶

Given une campagne d'acceptation push
When les preuves d'execution sont collectees
Then seules les executions sur build EAS iOS sont acceptees.

9. Hypotheses explicites¶

10. Points a clarifier¶

1. Catalogue exact des evenements phase 1 : catalogue fige en section 3 pour PD-105; toute extension est hors perimetre de cette specification.
2. Politique de localisation : langue unique FR ou FR/EN pour le texte des alertes.
3. Opt-out granulaire : activation/desactivation par categorie autorisee ou non pour phase 1.
4. Regle de lecture : une notification devient "lue" a l'ouverture du detail de cette notification dans le centre in-app.
5. Fenetre de mesure latence reception : la NFR contractualise la latence d'envoi backend (p95 <= 5s); le seuil de reception reste a contractualiser si requis.
6. Definition de "traitee correctement" en background (>95%) : criteres exacts de succes/erreur a fixer pour test non ambigu.

References¶

• Epic : MOBILE-IOS (PD-195)
• JIRA : PD-105
• Repos concernes : ProbatioVault-app (frontend), ProbatioVault-backend
• Documents associes : PD-105-besoin.md