Notification push

Notification push : Message envoyé par le serveur et affiché par le système même application fermée, levier de réengagement à manier avec mesure.

Classé dans la famille « Technique », ce terme revient dans les échanges entre un client et son agence. Voici ce qu’il faut en comprendre avant d’en discuter le prix.

Pourquoi Notification push compte sur un projet mobile

Notification push appartient à la plomberie de l’application, la partie que personne ne montre en démonstration et qui explique pourtant une bonne moitié des retards.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

La traduction en exigences

Le chapitre des contraintes techniques est la bonne place pour « Notification push », avec les volumes attendus, les pics prévus et les environnements à livrer.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Le volume de données attendu au lancement, puis à douze mois.
• Le comportement de l’application sans réseau, et ce qui doit rester consultable.
• Les délais d’affichage acceptables sur les écrans les plus consultés.
• L’hébergement retenu, sa localisation, et qui en paie l’abonnement mensuel.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Comment le vérifier à la recette

Le contrôle de « Notification push » demande d’aller voir derrière l’écran : journaux, mesures, comportement en panne.

• Relever les temps d’affichage des écrans les plus consultés, chiffres à l’appui.
• Déclencher une alerte pour vérifier qu’elle arrive bien à quelqu’un.
• Demander la facture d’hébergement du mois, pour éviter la découverte à six mois.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Erreurs fréquentes

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• Dimensionner l’infrastructure sur le trafic du lancement et non sur celui d’une campagne.
• Considérer les sauvegardes comme faites parce qu’elles sont configurées, sans tester de restauration.
• Découvrir les coûts d’hébergement après la mise en ligne, faute de les avoir demandés au devis.
• Mesurer la performance sur un téléphone récent et l’annoncer comme celle du parc réel.
• Employer le mot sans le définir, et laisser chaque partie prenante y mettre son propre sens.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• API REST
• Webhook
• Lien profond
• Feature flag

Questions fréquentes

Que signifie « Notification push » ?

Message envoyé par le serveur et affiché par le système même application fermée, levier de réengagement à manier avec mesure. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

Quand faut-il en parler dans le projet ?

Au cadrage, avec les autres contraintes techniques. Une fois l’application en ligne, la même décision se paie en migration, en interruption de service et parfois en reprise des données déjà collectées.

Par où commencer quand le sujet est nouveau ?

Par les parcours et les règles de gestion, pas par les outils. Le guide du cahier des charges donne l’ordre dans lequel poser les questions à une agence.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.