EsTcalade.fr s'installe sur l'écran d'accueil d'un téléphone, s'ouvre en plein écran et envoie des notifications même lorsque le navigateur est fermé. Pourtant, ce n'est pas une application native : c'est une Progressive Web App. Voici ce que cela recouvre concrètement, et comment c'est mis en œuvre.
Pourquoi une PWA plutôt qu'une application native
Pour un club amateur, publier une application native signifie deux développements, deux magasins d'applications, deux processus de validation et deux cycles de mise à jour — sans compter le compte développeur annuel. Une PWA offre l'essentiel de l'expérience attendue :
- une icône sur l'écran d'accueil ;
- un affichage plein écran, sans barre d'adresse ;
- des notifications push, application fermée ;
- une mise à jour immédiate pour tout le monde — il n'y a rien à réinstaller.
Le prix à payer est connu : pas d'accès aux fonctions les plus profondes du téléphone, et une prise en charge des notifications qui a longtemps été le point faible côté iOS. Pour organiser des séances, ce périmètre suffit largement.
Les trois pièces du dispositif
1. Le manifeste
Un simple fichier JSON déclare le nom de l'application, ses icônes, sa couleur de thème et — le point décisif — le mode d'affichage standalone. C'est lui qui fait disparaître l'interface du navigateur une fois l'application ajoutée à l'écran d'accueil, et qui donne au système les icônes à utiliser.
2. Le service worker
C'est un script qui tourne à côté de la page, et continue de vivre quand celle-ci est fermée. Il joue ici trois rôles.
Il met en cache le strict nécessaire. La stratégie retenue est volontairement simple : on tente toujours le réseau d'abord, et on ne se rabat sur le cache qu'en cas d'échec. Pour une application dont tout le contenu est vivant — qui vient à la séance, quels messages viennent d'arriver — servir une version en cache serait pire que d'afficher une erreur. Les requêtes qui ne sont pas de simples lectures et le canal temps réel sont explicitement exclus.
Il reçoit les notifications push et les affiche, même application fermée :
À la réception d'un message, le service worker affiche la notification avec son icône, sa vibration, et mémorise l'adresse à ouvrir au clic.
Il gère le clic sur la notification. C'est le détail qui fait la différence à l'usage : plutôt que d'ouvrir systématiquement un nouvel onglet, le service worker cherche d'abord une fenêtre déjà ouverte sur la bonne adresse et lui donne le focus. On revient dans l'application là où il faut, sans empiler les onglets.
3. L'abonnement aux notifications
Côté navigateur, la souscription se fait en quelques étapes : demander la permission à l'utilisateur, récupérer la clé publique du serveur, s'abonner auprès du service de push du navigateur, puis transmettre cet abonnement au serveur, qui le stocke pour l'utilisateur.
Le code vérifie surtout ce qui peut manquer, et le nomme : navigateur non compatible, page non servie en HTTPS, permission refusée, clé serveur absente. Chaque cas renvoie une raison distincte, affichée telle quelle à l'utilisateur. C'est ce qui évite le grand classique du support : « ça ne marche pas » — sans savoir laquelle des quatre causes est en jeu.
À noter, deux exigences non négociables du Web Push : HTTPS obligatoire (une page en clair ne peut pas s'abonner), et la nécessité que chaque message push aboutisse à une notification visible — pas de message silencieux.
Amener l'utilisateur à installer, sans le harceler
Le bandeau d'activation : une seule proposition, avec un « plus tard » qui est réellement respecté.
Une PWA ne sert à rien si personne ne l'installe. Trois dispositifs y conduisent, dans cet ordre :
- une notice d'accueil en quatre écrans, affichée à la première connexion : installer l'application, activer les notifications, partager ses statistiques, changer son code PIN. Elle ne s'affiche qu'une fois — un drapeau en base est effacé dès sa fermeture — et un administrateur peut la réactiver pour une personne ou pour tout le monde, ce qui est précieux au moment d'accueillir une nouvelle team ;
- un bandeau d'activation des notifications sur la page d'accueil, qui peut être écarté — et le reste, la préférence étant mémorisée dans le navigateur ;
- un avertissement explicite lorsque la page n'est pas servie en HTTPS et que les notifications ne peuvent donc pas fonctionner, plutôt qu'un bouton qui échouerait sans explication.
Les instructions d'installation diffèrent selon la plateforme — « Partager puis Ajouter à l'écran d'accueil » sur iPhone, menu du navigateur sur Android — et la notice les donne dans les deux versions. Ce n'est pas très glorieux à écrire, mais c'est exactement ce qui bloque les utilisateurs.
Ce qu'il faut retenir
La partie technique d'une PWA est modeste : un fichier de manifeste, un service worker d'une centaine de lignes, une poignée de fonctions d'abonnement. Le vrai travail est ailleurs — décider ce qu'on met en cache (ici : presque rien, volontairement), nommer précisément les raisons d'échec, et accompagner l'installation sans transformer chaque écran en publicité pour l'application.
Résultat : une application installée depuis une simple adresse web, mise à jour pour tout le monde en même temps, et qui prévient ses utilisateurs une heure avant la séance.
Essayer l'application
EsTcalade.fr est gratuite et ouverte aux groupes, aux équipes et aux clubs.
- L'application : app.estcalade.fr — inscription avec un identifiant et un code PIN, puis validation par un administrateur.
- La présentation : www.estcalade.fr — fonctionnalités, captures d'écran et instructions d'installation sur mobile.
Sur téléphone, ouvrez l'application dans le navigateur puis utilisez « Ajouter à l'écran d'accueil » : elle s'installe comme une application et les notifications deviennent disponibles.