SOFTIC Academy

Lot 7 — Application mobile (PWA)

Atualizado em 06/11/2026

Este conteúdo ainda não está disponível em Português; é apresentado em Français.

L'application mobile est une PWA servie par l'intranet à l'adresse https://intranet.softic.io/m/ : elle s'installe sur l'écran d'accueil (Android et iOS), fonctionne hors ligne, et parle à l'intranet par l'API api/v1 avec un jeton. Aucun magasin d'applications, aucun compte développeur : une mise à jour de l'intranet met à jour l'application au prochain lancement.

Installer

  • Android (Chrome) : ouvrir https://intranet.softic.io/m/, se connecter, puis Plus → Installer sur l'écran d'accueil (ou le menu ⋮ de Chrome → Installer l'application).
  • iPhone / iPad (Safari) : ouvrir l'adresse, bouton Partager → Sur l'écran d'accueil. Safari n'affiche pas d'invite automatique.
  • Le site doit être en https avec un certificat valide, faute de quoi ni l'installation, ni la caméra (QR), ni la position ne fonctionnent.

Ce qu'elle fait

Écran Contenu
Accueil pointage, demandes à valider, notifications non lues, sondages à répondre, agenda du jour, actions en attente de synchronisation
Pointage Arrivée / Départ avec position, scan du QR du site par la caméra (jsQR, Apache-2.0, embarqué), mes 14 derniers jours et leurs anomalies
Demandes mes demandes, à valider (approuver / refuser avec motif), nouvelle demande : formulaire généré depuis le type, lignes de frais comprises, PDF de la demande
Annuaire recherche, appel (tel:), courriel (mailto:)
Plus notifications, sondages (répondre), agenda 7 jours, file de synchronisation, installation, déconnexion

Langue : celle du profil (fr, en, ar avec écriture de droite à gauche, pt).

Hors ligne

 lecture  : réseau d'abord → réponse gardée dans IndexedDB → hors ligne, la dernière réponse connue est affichée
 action   : envoyée tout de suite si le serveur répond → sinon mise en FILE (IndexedDB), rejouée dans l'ordre au retour du réseau
 identité : chaque pointage porte un identifiant client, chaque demande une référence client → un rejeu ne crée jamais de doublon
 bénin    : « déjà répondu », « déjà pointé », « demande déjà décidée » sont acceptés comme faits ; un refus métier reste en file avec son motif
 heure    : un pointage fait hors ligne est envoyé avec son heure réelle (au plus 7 jours en arrière)

Le service worker (/m/sw.js) met en cache la coquille (pages, scripts, styles, icônes) : l'application s'ouvre sans réseau. L'API n'est jamais mise en cache par le service worker ; c'est la base locale qui garde les données.

Sécurité

  • Jeton d'accès + jeton de rafraîchissement (auth/refresh), gardés dans IndexedDB de l'application ; déconnexion = jetons révoqués et base locale effacée. La politique de l'API s'applique : un jeton de rafraîchissement rejoué ferme toutes les sessions mobiles du compte.
  • Lot 12 (P34, 1.21.3) : un compte dont le mot de passe est à changer ne reçoit aucun jeton. L'application efface ses jetons sans vider la file, affiche le motif et le bouton Changer mon mot de passe (/Account/ChangePassword?returnUrl=/m/), et garde l'action faite au moment du refus ; elle partira après le changement et la reconnexion.
  • Rien de plus n'est exposé que par le site : mêmes droits, mêmes règles, même audit.

Côté serveur (ajouts du lot)

  • TimeEntry.ClientId (index unique par utilisateur), ClockRequest.AtUtc et ClientId ; Request.ClientRef et RequestEditDto.ClientRef.
  • Toutes les routes d'API sont désormais sous api/v1 (organisation, RH, demandes, sondages, pointage comprises).
  • /m est servi explicitement (hors du repli Blazor) ; les fichiers de l'application sont dans wwwroot/m/.

Notifications push (lot 7-2)

Chaque notification de l'intranet (cloche) est aussi poussée aux téléphones abonnés, même application fermée : demande à valider, décision, rappel, sondage, certification qui expire… Le clic ouvre l'écran visé dans l'application.

  • Activer : Plus → Notifications push ; le téléphone demande l'autorisation. Sur iPhone, seule l'application installée sur l'écran d'accueil (iOS 16.4 et plus) peut recevoir des push ; dans Safari ouvert, l'option n'apparaît pas.
  • Mécanique : Web Push standard. Le serveur génère une paire de clés VAPID au premier usage (gardée dans les réglages, la clé privée en secret), chiffre chaque message pour l'appareil (RFC 8291, aes128gcm) et le signe (RFC 8292, ES256) — le tout écrit sur la cryptographie du framework, sans bibliothèque. Les abonnements périmés (404, 410) sont retirés d'eux-mêmes ; cinq appareils au plus par personne.
  • Réseau : le serveur de l'intranet doit joindre en https sortant les services de push des navigateurs : fcm.googleapis.com (Chrome, Edge, Samsung), web.push.apple.com (Safari, iOS), updates.push.services.mozilla.com (Firefox). Sans cette sortie, les push restent silencieusement en échec (journal) ; le reste de l'intranet n'en souffre pas.
  • Paramètres → Notifications push : activation, contact de l'expéditeur (mailto:), exigé par les services de push.
  • API : GET push/vapid-key, POST push/subscribe, POST push/unsubscribe, POST push/test (envoie un essai à mes appareils).

Plus tard

  • Natif (.NET MAUI) si les magasins d'applications deviennent nécessaires : même API, mêmes règles.