Réponse courte. Une application ne « envoie des SMS » pas plus qu'elle n'« envoie des push » : elle émet des événements, commande expédiée, paiement reçu, livreur en route, et un service de notification décide pour chacun, selon le client et ses préférences, quel canal, à quelle heure, en quelle langue, et s'il faut envoyer du tout. Le push de Google et d'Apple vient en premier parce qu'il ne coûte rien par message et arrive en secondes ; la boîte in-app reçoit toujours une copie, c'est la seule qui ne perd rien ; WhatsApp prend le relais quand le push n'est pas accusé dans le délai écrit ; le SMS reste pour le message critique vers un téléphone sans application ni WhatsApp. Chaque envoi est journalisé avec son canal, son coût, son accusé et sa raison d'échec, parce qu'un push échoue en silence six fois sur dix façons différentes : permission refusée, jeton expiré, constructeur qui tue l'application, téléphone sans services Google. Huit semaines, dont la première sans aucun envoi.
Ce guide s'adresse au fondateur installé en France dont l'application doit prévenir des clients en Algérie, au gérant d'une plateforme de livraison, d'une clinique ou d'une école qui paie des SMS pour tout, et à celui qui compare des devis où « notifications » tient en un mot. Il ne traite pas du code de connexion par SMS ou WhatsApp, décrit dans le guide sur l'OTP, ni de l'agent qui répond aux clients sur WhatsApp, décrit dans le guide dédié ; il décrit ce qui se construit entre l'événement et le téléphone du client.
Ce que les chiffres disent
Le push n'est plus acquis par défaut. Depuis Android 13, publié en 2022, les notifications d'une application nouvellement installée sont désactivées tant que l'utilisateur n'a pas accordé une permission, demandée par l'application au moment qu'elle choisit ; la documentation Android recommande d'attendre un geste qui donne un sens à la demande, « l'utilisateur soumet une commande de livraison » est son exemple, plutôt que de la poser au premier écran. Sur iOS, la permission a toujours été demandée. Ce que cela impose : une application qui demande la permission à l'ouverture, avant d'avoir montré à quoi elle sert, perd une partie de ses clients pour toujours, et une application qui ne lit pas l'état de la permission avant d'envoyer croit qu'elle a prévenu.
Le push arrive quand le téléphone veut bien. La documentation de Firebase Cloud Messaging, le service de push de Google utilisé par la plupart des applications Android, distingue deux priorités : en priorité normale, « la livraison peut être retardée pour économiser la batterie jusqu'à ce que l'appareil sorte du mode veille » ; en priorité haute, la livraison est tentée immédiatement et peut réveiller l'appareil, mais si les messages en priorité haute n'affichent pas de notification visible, « vos messages peuvent être rétrogradés en priorité normale », décision prise par application sur sept jours de comportement. Le site Don't Kill My App, tenu par des développeurs, classe les constructeurs selon l'agressivité de leur économie de batterie envers les applications en arrière-plan : Huawei, Xiaomi, OnePlus et Samsung au plus haut niveau, Oppo juste derrière, realme et Tecno au milieu ; c'est un classement de développeurs, pas une mesure, mais il correspond à ce que nous voyons au pilote.
Les téléphones de vos clients ne sont pas ceux de votre équipe. Selon StatCounter pour octobre 2026, les six premières marques en Algérie sont Samsung (24 %), Apple (16 %), Xiaomi (15 %), Oppo (13 %), realme (8 %) et Infinix (8 %) ; c'est une mesure de trafic web, pas un recensement, et elle sert à une chose : une recette faite sur trois téléphones de l'équipe ne dit rien de ce que reçoivent les clients. Les téléphones vendus sans services Google existent, et sur ceux-là le push de Google ne partira jamais. Côté coût, les grilles des opérateurs algériens pour les SMS professionnels ne sont pas publiques ; les fiches de revendeurs que nous avons lues placent le SMS à vingt à trente fois le prix d'un message WhatsApp utilitaire, et Meta facture WhatsApp par message livré depuis juillet 2025, avec des tarifs par région qui ne sont pas repris ici parce qu'ils changent. Ce qui ne change pas : le push ne coûte rien par message, et c'est la raison de tout le reste.
La vie d'une notification, en six moments
Une notification ne se décrit pas par son canal mais par ce qui arrive à un événement, de la commande expédiée à la ligne de journal qui dira par où elle est passée.
L'événement est émis par l'application avec son client et son contexte : commande expédiée, paiement reçu, rendez-vous demain, livreur en route ; l'application ne dit jamais « envoie un SMS », elle dit ce qui s'est passé. La règle décide, pour cet événement et ce client : quel canal, à quelle heure, en quelle langue, avec quelle priorité, et s'il faut envoyer du tout ; c'est là que vivent les préférences du client, les heures calmes, le plafond par jour et le dédoublonnage. Le rendu prend un gabarit versionné par canal et par langue, arabe de droite à gauche compris ; le même événement donne un push de deux lignes, un message WhatsApp approuvé par Meta, un SMS qui tient en 160 caractères.
L'envoi et le repli : la boîte in-app reçoit toujours une copie, avant tout envoi ; le push part en premier ; si rien n'est accusé dans le délai écrit pour ce type de message, WhatsApp ; si WhatsApp échoue et que le message est critique, SMS ; sinon rien de plus. L'accusé dit livré, ouvert, cliqué, ou échoué avec la raison : jeton expiré, permission refusée, numéro invalide, gabarit refusé ; c'est lui qui décide du repli et de la facture. Le journal écrit chaque envoi avec son canal, son coût, son accusé et son délai ; c'est ce qui permet de répondre « la notification est partie à 14 h 02 en push, non accusée, relancée à 14 h 12 sur WhatsApp, lue à 14 h 13 » au client qui dit n'avoir rien reçu, et d'alimenter l'écran du gérant décrit dans le guide sur le tableau de bord.
Les notifications d'une application, en cinq couches
Derrière les six moments, cinq couches, et celle du milieu est la seule qui nous appartient.
L'application montre la boîte de réception in-app, demande la permission au bon moment avec l'explication, et laisse le client régler ses préférences par type de message ; c'est ce que le client voit. Le service de notification est le vrai livrable : règles par événement, préférences, heures calmes, plafonds, dédoublonnage, délais d'accusé, repli d'un canal à l'autre, gabarits ; c'est la seule couche qui sait ce qui doit partir, et elle est à vous, dans votre dépôt. Les canaux sont interchangeables derrière elle : push Google et Apple, push du constructeur quand le téléphone n'a pas les services Google, WhatsApp Business, SMS par agrégateur, e-mail, appel vocal ; chacun a son coût, son délai et sa forme d'accusé, et changer d'agrégateur SMS est un réglage.
Les données tiennent les jetons d'appareil par client, les préférences, le journal des envois et des accusés, les gabarits versionnés ; un jeton expiré ou une permission refusée se voit ici avant que le client appelle. L'exploitation lit chaque semaine le taux de livraison par canal et par constructeur, le coût par envoi, la part partie en repli, les plaintes et les désactivations, avec une alerte quand l'une dérive. Une application qui appelle l'API d'un agrégateur SMS depuis chaque écran n'a aucune de ces couches : pas de règle, pas de préférence, pas de repli, pas de journal, et une facture SMS qui est le seul indicateur.
«L'application ne dit jamais « envoie un SMS » ; elle dit ce qui s'est passé, et le service décide du canal, de l'heure et de la langue.»
Un exemple chiffré
Un exemple sur des hypothèses de volume, avec une mécanique qui n'en est pas : une plateforme de livraison, 3 000 commandes par jour, un mois.
12 000 notifications par jour : quatre événements par commande, confirmée, préparée, livreur en route, livrée ; c'est notre hypothèse de volume, à mesurer au pilote. 0 DA par push chez Google et Apple : aucun coût par message ; le coût est dans le service qu'on construit une fois et dans l'accusé qu'on lit. Un rapport de vingt entre un SMS et un message WhatsApp utilitaire selon les fiches de revendeurs, à vérifier sur vos devis, les tarifs opérateurs algériens n'étant pas publics ; ce qui ne dépend pas de la grille, c'est qu'une plateforme qui envoie ses 12 000 événements par SMS paie chaque jour ce qu'un push aurait fait gratuitement pour la grande majorité des clients, et qu'une plateforme qui n'envoie en SMS que le code de livraison des clients sans application ni WhatsApp en envoie quelques centaines.
Cent pour cent des envois journalisés avec canal, coût, accusé et délai, et zéro message envoyé sans règle, sans préférence vérifiée et sans écriture dans la boîte in-app : c'est la mécanique, pas une hypothèse. Les hypothèses à vérifier chez vous : combien d'événements méritent vraiment un message, quelle part de vos clients a l'application installée avec la permission accordée, quelle part a WhatsApp, et quel délai d'accusé votre gérant accepte avant de relancer ; la première semaine du projet y répond, et le guide sur la plateforme de livraison dit ce que les livreurs, eux, doivent recevoir.
Six canaux, et pour quel message chacun est fait
Six canaux, et aucun n'est « le bon » : chacun est fait pour un type de message, et chacun échoue d'une façon qui lui est propre.
Le push porte tout ce qui est utile tout de suite et gratuit : statut de commande, message reçu, rappel ; en priorité haute seulement quand le client doit agir, parce qu'une priorité haute sans notification visible finit rétrogradée. Il échoue par permission refusée, jeton expiré, constructeur qui tue l'application, téléphone sans services Google. La boîte in-app reçoit tout, toujours : c'est la copie que le client retrouve en ouvrant l'application même si aucun canal n'a abouti ; elle n'échoue que si elle est une réflexion tardive, ajoutée après les canaux. WhatsApp Business porte le message qui doit être lu et peut appeler une réponse, livreur en route, rendez-vous, facture, en repli du push ; il échoue par gabarit non approuvé, numéro non inscrit, et coûte par message hors de la fenêtre de 24 heures décrite dans le guide sur l'agent WhatsApp.
Le SMS reste pour le message critique vers un téléphone sans application ni WhatsApp : code de livraison, rappel de rendez-vous ; il coûte à chaque envoi, tient en 160 caractères, deux fois moins en arabe, et n'a pas d'accusé de lecture. L'e-mail porte le document, facture, reçu, récapitulatif hebdomadaire, jamais l'urgence ; une partie des clients en Algérie n'a pas d'adresse consultée. L'appel vocal est le dernier recours écrit, commande à valider avant la coupure, livraison bloquée, déclenché par une règle et jamais à la main. La règle générale : le push et la boîte in-app pour tout, WhatsApp pour ce qui doit être lu, le SMS pour ce qui est critique et ne peut passer autrement, et chaque passage d'un canal au suivant écrit à l'avance, par type de message, avec son délai.
Six raisons pour lesquelles la notification n'arrive pas
Six pannes que nous voyons sur les applications que nous reprenons, et ce que l'architecture fait contre chacune.
La permission refusée : sur Android 13 et plus, les notifications sont désactivées par défaut, la demande posée au premier écran est refusée et ne revient pas ; demande posée au moment utile, après une commande, avec l'explication, état de la permission lu avant chaque envoi, repli WhatsApp si elle est refusée. Le constructeur qui tue l'application : sur certains téléphones, l'économie de batterie ferme l'application et retarde ou bloque le push ; priorité haute réservée aux messages qui demandent une action, notification visible à chaque push pour ne pas être rétrogradé, écran d'aide par constructeur, repli si rien n'est accusé. Le téléphone sans services Google : le jeton n'existe pas et le push de Google ne partira jamais ; détection à l'installation, push du constructeur quand il existe, sinon WhatsApp et boîte in-app dès le départ.
Le jeton expiré : le client réinstalle, change de téléphone ou n'ouvre plus l'application, et le jeton meurt en silence ; jeton rafraîchi à chaque ouverture, retour d'erreur lu et jeton supprimé, repli vers le canal suivant, journal. La priorité normale en veille : le push part en priorité normale, le téléphone en veille le garde pour plus tard, et le livreur est déjà passé ; priorité haute pour le message qui attend une action, normale pour le reste, délai d'accusé écrit puis WhatsApp. Trop de messages : quatre promotions par jour, et le client coupe tout, y compris le statut de sa commande ; plafond par client et par jour, heures calmes, dédoublonnage, préférences par type, désactivations comptées et lues chaque semaine. Les trois premières se découvrent au pilote si l'on teste sur de vrais téléphones de clients ; les trois dernières, trois mois plus tard, dans les désactivations.
«Les téléphones de l'équipe reçoivent toujours tout ; la recette se fait sur vingt téléphones de clients.»
Vu ailleurs : Android 13, Firebase, Don't Kill My App, et ce qui se transpose
Trois sources disent l'essentiel. La documentation Android dit que la permission de notification est refusée par défaut depuis Android 13 et qu'il faut la demander au moment où elle a un sens ; ce qui se transpose, c'est que la demande est un écran du produit, dessiné la deuxième semaine, pas une boîte de dialogue au lancement. La documentation de Firebase dit que la priorité normale attend la sortie de veille, que la priorité haute peut réveiller l'appareil, et qu'une priorité haute sans notification visible est rétrogradée après sept jours ; ce qui se transpose, c'est une priorité par type de message, écrite dans la règle, et un accusé lu pour savoir si le push a abouti.
Don't Kill My App dit que les constructeurs les plus vendus en Algérie sont parmi ceux qui ferment le plus volontiers les applications en arrière-plan ; ce qui se transpose, c'est une recette sur des téléphones de clients de marques variées et un repli qui ne dépend pas du push. Ce que ces sources ne disent pas : quels événements de votre activité méritent un message, quelle part de vos clients a WhatsApp, et quel délai votre gérant accepte avant de relancer ; la première semaine du projet y répond.
Les règles d'une notification qui arrive
Six règles, écrites la première semaine et relues à chaque nouveau type de message. Un événement, pas un message : l'application dit ce qui s'est passé, le service décide. La boîte in-app d'abord : chaque notification y est écrite avant tout envoi ; c'est la seule copie garantie. Le push gratuit en premier, le payant en repli : WhatsApp si le push n'est pas accusé dans le délai écrit, SMS pour le critique seulement. La permission demandée au moment utile, avec l'explication, et lue avant chaque envoi. Un plafond, des heures calmes et des préférences par type, parce qu'un client qui coupe tout ne reçoit plus le statut de sa commande. Un journal complet, canal, coût, accusé, délai, raison d'échec, lu chaque semaine par constructeur.
Une septième règle porte sur le devis : « notifications push et SMS » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « service de notification avec règles par événement, préférences par type, boîte in-app, push avec accusé, repli WhatsApp après X minutes pour les types A et B, SMS pour le type C seulement, journal par envoi, taux de livraison par constructeur mesuré sur vingt téléphones de clients à la recette, coût par envoi affiché », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui chiffre « les SMS » a chiffré une facture mensuelle, pas un service.
Six applications, et le message qu'on construit d'abord
Six applications que nous construisons souvent, et pour chacune le premier type de message retenu la première semaine, avec son canal et son repli.
- La plateforme de livraison, décrite dans le guide dédié. « Livreur en route » en push priorité haute, WhatsApp après dix minutes sans accusé, code de livraison en SMS pour le client sans application.
- Le cabinet dentaire ou médical, décrit dans le guide sur le cabinet. Rappel de rendez-vous la veille en push, WhatsApp le matin même si non accusé ; jamais le contenu médical dans le canal, seulement l'invitation à ouvrir l'application.
- L'école privée. Absence du jour en push aux parents, bulletin et facture dans la boîte in-app et par e-mail ; heures calmes strictes, plafond par jour.
- L'application de terrain des prévendeurs, décrite dans le guide dédié. Commande validée ou refusée en push, synchronisée avec la file hors ligne décrite dans le guide sur le mode hors ligne ; aucun SMS.
- La salle des fêtes réservée depuis la France, décrite dans le guide dédié. Acompte reçu et date confirmée en push et par e-mail au client en France, WhatsApp au gérant en Algérie.
- L'espace propriétaire d'un appartement loué, décrit dans le guide dédié. Loyer reçu et quittance en push et e-mail au propriétaire en France, rappel d'échéance en WhatsApp au locataire en Algérie.
Le calendrier 2027
Le calendrier est celui d'un service de notification complet en huit semaines, dont la première sans aucun envoi et une de recette sur de vrais téléphones.
La semaine 0 à 1 fait l'inventaire des messages : chaque événement qui mérite un message, pour qui, en quelle langue, avec quelle urgence, et ce qui ne sera jamais envoyé ; signé. La semaine 1 à 2 dessine les préférences et la permission : l'écran de préférences par type, le moment de la demande, les heures calmes, les plafonds, et la boîte in-app. Les semaines 2 à 4 construisent le service, le push et la boîte in-app : règles, gabarits, jetons, accusés, journal, push Google et Apple, chaque envoi écrit dans la boîte avant de partir. La semaine 4 à 5 ajoute WhatsApp et le SMS en repli : gabarits approuvés par Meta, délai d'accusé par type, repli écrit, coût par envoi lu.
La semaine 5 à 6 est la recette sur vingt téléphones de clients, de marques variées, avec permission refusée, mode avion, réinstallation, et un taux de livraison par constructeur ; les téléphones de l'équipe ne comptent pas, ils reçoivent toujours tout. La semaine 6 à 7 est le pilote sur une partie des clients, livraison et accusés lus chaque jour, plaintes et désactivations comptées. La semaine 7 à 8 installe la supervision hebdomadaire, taux par canal et par constructeur, coût, part en repli, et ajuste les règles. Chaque lot de deux semaines est démontré et recetté comme le guide sur la livraison le décrit, et le coût de fonctionnement rejoint le budget annuel décrit dans le guide sur faire vivre une application.
Ce qui fait échouer les notifications
Les services de notification que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- Le SMS pour tout. La facture est le seul indicateur, et personne ne sait qui a lu quoi.
- La permission demandée au lancement. Refusée avant que l'application ait montré à quoi elle sert ; elle ne revient pas.
- Pas de boîte in-app. Le canal échoue, et il n'existe aucune copie que le client puisse retrouver.
- La recette sur les téléphones de l'équipe. Trois téléphones qui reçoivent tout ; les clients sur d'autres marques, rien.
- Pas d'accusé lu. Le service croit avoir prévenu ; le jeton était mort depuis deux mois.
- La priorité haute partout. Rétrogradée après sept jours sans notification visible, et le message urgent attend la sortie de veille.
- Pas de plafond. Les promotions coupent les notifications de service ; le client ne reçoit plus le statut de sa commande.
Questions fréquentes
Les questions que nous recevons de fondateurs installés en France, de gérants en Algérie et d'équipes qui comparent des devis.
- Pourquoi mes clients ne reçoivent-ils pas les notifications ?
- Pour l'une de six raisons, et le journal doit dire laquelle : permission refusée, fréquente depuis Android 13 où elle est refusée par défaut ; jeton expiré après une réinstallation ; constructeur qui ferme l'application en arrière-plan ; téléphone sans services Google ; push en priorité normale retenu pendant la veille ; ou client qui a tout coupé après trop de messages. Un service qui lit l'accusé et replie vers WhatsApp traite les cinq premières ; un plafond et des préférences traitent la sixième.
- Push, SMS ou WhatsApp : lequel choisir ?
- Les trois, chacun pour son message : le push, gratuit et immédiat, pour tout ce qui est utile tout de suite ; WhatsApp, facturé par message, pour ce qui doit être lu et peut appeler une réponse, en repli du push ; le SMS, le plus cher et sans accusé de lecture, pour le message critique vers un téléphone sans application ni WhatsApp. La boîte in-app reçoit tout, toujours, et le passage d'un canal au suivant est écrit à l'avance par type de message.
- Combien coûte une notification ?
- Rien par message en push chez Google et Apple ; par message livré sur WhatsApp, à des tarifs par région publiés par Meta ; par envoi en SMS, à des tarifs opérateurs qui ne sont pas publics en Algérie, les fiches de revendeurs plaçant le SMS à vingt à trente fois le message WhatsApp. Ce qui pèse n'est pas le prix unitaire mais la part des messages qui partent en payant ; un service qui replie seulement ce qui n'est pas accusé la garde basse, et le coût par envoi est lu chaque semaine.
- Et si le client a un téléphone sans services Google ?
- Le push de Google ne partira jamais, et le service doit le savoir dès l'installation : détection du téléphone, push du constructeur quand il existe, sinon WhatsApp et boîte in-app dès le départ pour ce client. Les téléphones de ce type existent en Algérie ; la recette sur vingt téléphones de clients en inclut au moins un.
- Quand demander la permission de notification ?
- Au moment où elle a un sens pour le client, et avec l'explication : après sa première commande, en activant le suivi d'un dossier, en appuyant sur une cloche ; c'est la recommandation de la documentation Android, et c'est ce que nous dessinons la deuxième semaine. Jamais au premier écran : sur Android 13 et plus, un refus à ce moment-là est un refus pour longtemps, et le service doit lire l'état de la permission avant chaque envoi.
- Combien de temps pour construire les notifications ?
- Huit semaines pour un service complet : une d'inventaire des messages sans aucun envoi, une pour les préférences et la permission, deux pour le service, le push et la boîte in-app, une pour WhatsApp et le SMS en repli, une de recette sur vingt téléphones de clients, une de pilote, une de supervision. Chaque lot de deux semaines est démontré et recetté.