Auto-héberger ntfy pour recevoir des alertes serveur

Ce que fait un serveur ntfy auto-hébergé

Un serveur ntfy auto-hébergé transforme une requête HTTP POST en notification push sur votre téléphone. Vous publiez avec curl, puis le message arrive dans l’application Android, l’application iOS, un onglet de navigateur ou tout autre client capable de maintenir une connexion HTTP ouverte. Il n’est nécessaire d’installer aucune bibliothèque cliente ni d’exécuter un message broker.

ntfy adresse les messages par topic. Un topic est un nom inclus dans le chemin de l’URL, comme https://ntfy.example.com/alerts, et il existe dès qu’un utilisateur y publie un message. Avec l’installation par défaut, toute personne qui connaît ce nom peut lire le topic et y publier des messages. C’est pourquoi la documentation du projet compare le nom d’un topic à un mot de passe. Ce modèle convient au service public ntfy.sh. Il ne convient pas à un serveur qui transporte les échecs de vos sauvegardes. Ce guide active donc l’authentification avant l’envoi du premier message.

Ce qu’il vous faut avant de commencer

Vous avez besoin d’un VPS sous Ubuntu 24.04 ou Debian 13 avec Docker Engine et le plugin Compose, d’un nom de domaine et de très peu de RAM. Créez un enregistrement DNS (domain name system) de type A qui pointe ntfy.example.com vers l’adresse IP publique du serveur, puis vérifiez sa résolution avant toute autre opération.

dig +short ntfy.example.com
sudo ufw allow 80,443/tcp
sudo ufw status

dig doit afficher l’adresse IP de votre serveur. L’émission du certificat échoue si la commande n’affiche rien, car l’autorité de certification vérifie le nom depuis l’extérieur. Le port 80 reste ouvert, car ACME (automatic certificate management environment), le protocole utilisé par Let's Encrypt, s’en sert pour le challenge HTTP. Le conteneur ntfy n’expose lui-même aucun port public.

Créer le fichier de configuration de ntfy

L’image Docker ne contient pas de fichier de configuration. Vous devez donc en créer un. Toutes les commandes suivantes de ce guide le liront. Commencez par trouver l’UID et le GID avec lesquels le conteneur s’exécutera.

id -u
id -g
sudo install -d -o "$(id -u)" -g "$(id -g)" /etc/ntfy /var/cache/ntfy /var/lib/ntfy
sudo nano /etc/ntfy/server.yml

base-url: "https://ntfy.example.com"
listen-http: ":2586"
behind-proxy: true
cache-file: "/var/cache/ntfy/cache.db"
cache-duration: "12h"
auth-file: "/var/lib/ntfy/user.db"
auth-default-access: "deny-all"
enable-login: true
enable-signup: false

Quatre de ces lignes sont essentielles. base-url doit être exactement l’adresse HTTPS publique, car ntfy l’utilise pour construire les liens vers les pièces jointes et les requêtes de l’application web. Une valeur incorrecte produit une application web qui se charge, puis échoue lors de chaque action. listen-http: ":2586" écoute sur toutes les interfaces à l’intérieur du conteneur. Cela peut sembler imprudent, mais c’est correct : le conteneur possède son propre namespace réseau. Si vous liez le service à 127.0.0.1 dans le conteneur, le port devient inaccessible depuis l’hôte et le port publié par Docker ne peut jamais établir la connexion. auth-default-access: "deny-all" définit toute la politique de sécurité, car il refuse les opérations de lecture et d’écriture sans autorisation explicite. behind-proxy: true indique à ntfy de récupérer l’adresse du client dans l’en-tête X-Forwarded-For. Les limites de débit comptent ainsi les visiteurs réels au lieu de considérer le reverse proxy comme un seul client très actif.

enable-login: true permet à l’application web et aux applications mobiles de se connecter avec un mot de passe. enable-signup reste à false, car autoriser la création autonome de comptes sur un serveur privé crée une ouverture inutile.

sudo chown "$(id -u):$(id -g)" /etc/ntfy/server.yml
sudo chmod 600 /etc/ntfy/server.yml

Exécuter ntfy avec Docker Compose

Placez ceci dans /opt/ntfy/compose.yaml, en remplaçant 1000:1000 par les deux nombres id -u et id -g affichés ci-dessus.

services:
  ntfy:
    image: binwiederhier/ntfy:v2.27.0
    container_name: ntfy
    command: serve
    user: "1000:1000"
    environment:
      - TZ=UTC
    volumes:
      - /etc/ntfy:/etc/ntfy
      - /var/cache/ntfy:/var/cache/ntfy
      - /var/lib/ntfy:/var/lib/ntfy
    ports:
      - "127.0.0.1:2586:2586"
    restart: unless-stopped

cd /opt/ntfy
sudo docker compose up -d
sudo docker compose logs ntfy
curl -s http://127.0.0.1:2586/v1/health

Un serveur opérationnel répond sur {"healthy":true}. Deux détails de ce fichier Compose sont intentionnels. L’image est épinglée sur v2.27.0, la release actuelle en août 2026, plutôt que sur latest, car avec latest, la prochaine docker compose pull modifie la version du serveur et vous ne le découvrez qu’ensuite dans le changelog. Le port est publié sur 127.0.0.1:2586:2586 : le conteneur est donc accessible uniquement depuis l’adresse loopback de l’hôte. Remplacez cette valeur par 2586:2586 et Docker insère ses propres règles de firewall avant les vôtres. Le port répond alors depuis Internet, même si ufw status indique qu’il est fermé.

Si curl affiche Connection refused, consultez le log du conteneur. Une erreur de permission sur /var/lib/ntfy/user.db signifie que la ligne user: ne correspond pas au propriétaire de ces répertoires. Le processus ne peut donc pas créer sa propre base de données et s’arrête. Le guide des bases de Docker Compose pour un VPS explique plus en détail la propriété des volumes et les policies de redémarrage.

Placez TLS devant avec Caddy

Caddy demande et renouvelle lui-même le certificat. C’est la méthode la plus directe pour obtenir un TLS (transport layer security) opérationnel.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

Remplacez le contenu de /etc/caddy/Caddyfile par trois lignes.

ntfy.example.com {
    reverse_proxy 127.0.0.1:2586
}

sudo systemctl reload caddy
curl -s https://ntfy.example.com/v1/health

Le même {"healthy":true} en HTTPS confirme que tout le chemin fonctionne. Un 502 renvoyé par Caddy indique que ntfy n’écoute pas. Vérifiez avec sudo ss -lntp | grep 2586. Une erreur de certificat indique généralement que l’enregistrement DNS est incorrect ou que le port 80 est bloqué. sudo journalctl -u caddy -n 50 précise lequel.

Si nginx est déjà en place, reprenez les paramètres de proxy documentés par ntfy : proxy_http_version 1.1, proxy_buffering off, proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for, ainsi que des timeouts de lecture et d’envoi d’au moins trois minutes. Un subscriber maintient une connexion HTTP ouverte tant qu’il écoute. Par défaut, nginx ferme une connexion upstream inactive après 60 secondes. Les subscribers se reconnectent alors en boucle et les messages envoyés pendant l’interruption sont perdus.

Créer des utilisateurs et restreindre l’accès aux topics

L’authentification est activée et personne n’a encore accès à quoi que ce soit, ce qui est le but recherché. Créez un compte administrateur pour vous et un compte machine pour les scripts. Ces commandes lisent /etc/ntfy/server.yml depuis le conteneur, d’où le montage du fichier de configuration comme volume.

sudo docker compose exec ntfy ntfy user add --role=admin admin
sudo docker compose exec ntfy ntfy user add robot
sudo docker compose exec ntfy ntfy user list

Chaque commande demande un mot de passe. Un administrateur ignore la liste de contrôle d’accès et peut lire et écrire dans tous les topics. Réservez donc ce compte à votre usage et à l’application mobile. robot est un utilisateur standard sans aucun accès tant que vous ne lui en accordez pas.

sudo docker compose exec ntfy ntfy access robot alerts write
sudo docker compose exec ntfy ntfy access robot "alerts_*" write
sudo docker compose exec ntfy ntfy access

Une ACL (access control list) associe un utilisateur, un topic et une permission. Le topic est soit un nom littéral, soit un pattern dans lequel * correspond à n’importe quelle valeur. alerts_* couvre donc alerts_backup et alerts_db sans exécuter une commande pour chaque hôte. La permission write autorise uniquement la publication. Ainsi, un token volé depuis un cron job ne peut pas s’abonner ni relire ce qu’il a envoyé. Le nom d’utilisateur spécial everyone définit les actions autorisées pour un visiteur non authentifié. Utilisez-le uniquement pour exposer volontairement une ressource publique, comme ntfy access everyone status read.

Les scripts doivent utiliser un token, pas votre mot de passe.

sudo docker compose exec ntfy ntfy token add robot

La commande affiche un token qui commence par tk_. Un token hérite exactement des accès de l’utilisateur auquel il appartient. Celui-ci peut donc publier dans les topics alerts et ne peut rien faire d’autre. ntfy token list affiche les éléments existants et ntfy token remove révoque un élément sans modifier le mot de passe de l’utilisateur.

Envoyez votre premier message et vérifiez que le verrou fonctionne

Commencez par vérifier que la porte est fermée.

curl -s -o /dev/null -w '%{http_code}\n' -d "hello" https://ntfy.example.com/alerts

Cette commande affiche 403, et 403 est la réponse attendue : auth-default-access: "deny-all" refuse une publication anonyme. Envoyez maintenant un vrai message.

curl -H "Authorization: Bearer tk_REPLACE_WITH_YOUR_TOKEN" \
  -H "Title: Nightly backup finished" \
  -H "Priority: default" \
  -H "Tags: white_check_mark" \
  -d "42 GB copied in 11 minutes" \
  https://ntfy.example.com/alerts

Le serveur renvoie le message enregistré au format JSON. Vous savez ainsi qu’il a été accepté et non ignoré. Title correspond à la première ligne en gras. Priority utilise une valeur de 1 à 5 ou, par nom, une valeur comprise entre min et urgent. Cette valeur détermine si le téléphone émet un son. Tags deviennent des emoji dans la notification lorsque le nom correspond à un code court d’emoji connu. Sinon, ils restent du texte brut.

Pour surveiller un topic depuis un terminal, diffusez son contenu en continu :

curl -s -u admin https://ntfy.example.com/alerts/raw

curl demande le mot de passe. Chaque message arrive sur une seule ligne. Les lignes vides qui apparaissent de temps en temps sont des keepalives. Ouvrir https://ntfy.example.com dans un navigateur et vous connecter avec le même compte vous donne accès à la version web de ce même flux.

Définir des limites de débit pour qu’un script ne puisse pas saturer le serveur

Par défaut, chaque visiteur dispose d’un quota de 60 requêtes, reconstitué à raison d’une requête toutes les 5 secondes. Cette limite est généreuse pour un serveur privé, et un script bloqué dans une boucle de nouvelle tentative l’épuisera entièrement. Ajoutez des limites à server.yml.

visitor-request-limit-burst: 30
visitor-request-limit-replenish: "10s"
visitor-message-daily-limit: 500

sudo docker compose restart ntfy

Un visiteur qui dépasse la limite reçoit HTTP 429 au lieu que le message soit remis. La limite est comptabilisée par adresse du visiteur. C’est pourquoi behind-proxy: true est si important : sans lui, ntfy ne voit que l’adresse de Caddy, tous les clients sont considérés comme un seul visiteur, et un script trop bavard épuise le quota partagé par votre téléphone et vos autres serveurs.

Alerte en cas d’échec d’une tâche cron

Ne placez pas le token dans la ligne de commande. ps aux affiche la ligne de commande complète de chaque processus en cours à tous les utilisateurs de la machine. Un token transmis avec -H est donc lisible par n’importe quel compte local pendant toute la durée d’exécution de curl. Un fichier de configuration curl évite ce problème.

sudo install -d -m 700 /etc/ntfy-alert
printf 'header = "Authorization: Bearer tk_REPLACE_WITH_YOUR_TOKEN"\n' | sudo tee /etc/ntfy-alert/curlrc
sudo chmod 600 /etc/ntfy-alert/curlrc

Entourez maintenant la tâche d’un script. Enregistrez-le sous /usr/local/bin/backup-with-alert.sh, puis rendez-le exécutable avec chmod 750.

#!/bin/bash
out=$(/usr/local/bin/backup.sh 2>&1)
code=$?
if [ "$code" -ne 0 ]; then
  printf '%s' "$out" | tail -c 1000 | curl -K /etc/ntfy-alert/curlrc \
    -H "Title: backup.sh failed with exit $code" \
    -H "Priority: high" \
    -H "Tags: warning" \
    --data-binary @- \
    https://ntfy.example.com/alerts
fi
exit "$code"

17 3 * * * /usr/local/bin/backup-with-alert.sh >> /var/log/backup-alert.log 2>&1

$? est capturé sur la ligne qui suit immédiatement la commande, car la commande suivante l’écraserait. La sortie passe par tail -c 1000, car ntfy impose une taille maximale aux messages et une notification ne remplace pas un lecteur de journaux. exit "$code" final préserve le code de retour d’origine. Tout autre système qui surveille cette tâche voit donc toujours un échec. Testez l’ensemble en configurant le script pour utiliser /bin/false lors d’une exécution.

Une branche d’échec qui ne s’exécute jamais est pire qu’une absence d’alertes, car elle donne l’impression que le silence signifie que tout fonctionne. Cron fournit à votre tâche un environnement presque vide et un PATH bien plus court que celui de votre shell de connexion. Un script qui fonctionne lorsque vous le lancez manuellement peut donc s’arrêter avant même d’atteindre la ligne curl. Le guide expliquant pourquoi une tâche cron ne s’exécute pas détaille ces problèmes d’environnement. Utilisez des chemins absolus partout et consultez le fichier journal après la première exécution planifiée au lieu de partir du principe que tout fonctionne.

Alerter lorsqu’une unité systemd échoue

Cron convient aux tâches planifiées. Les services qui s’exécutent en continu ont besoin de OnFailure=, que systemd exécute dès qu’une unité passe à l’état failed. Créez une unité modèle et réutilisez-la pour chaque service du serveur. Enregistrez-la sous /etc/systemd/system/ntfy-unit-failed@.service.

[Unit]
Description=Send an ntfy alert because %i failed

[Service]
Type=oneshot
ExecStart=/usr/local/bin/ntfy-unit-failed %i

Exécutez ensuite /usr/local/bin/ntfy-unit-failed, avec le mode 750 :

#!/bin/bash
unit="$1"
journalctl -u "$unit" -n 15 --no-pager -o cat | tail -c 1000 | curl -K /etc/ntfy-alert/curlrc \
  -H "Title: $unit failed on $(hostname -s)" \
  -H "Priority: urgent" \
  -H "Tags: rotating_light" \
  --data-binary @- \
  https://ntfy.example.com/alerts

Associez-la à un service au moyen d’un drop-in, afin qu’une mise à niveau de paquet ne puisse pas écraser votre modification.

sudo systemctl edit myapp.service

[Unit]
OnFailure=ntfy-unit-failed@%n.service

%n est remplacé par le nom complet de l’unité. L’instance devient donc ntfy-unit-failed@myapp.service, et %i, dans le modèle, transmet myapp.service au script comme premier argument. C’est ce qui permet à un seul modèle de servir pour toutes les unités. Vérifiez son fonctionnement avec une unité qui échoue volontairement, enregistrée sous /etc/systemd/system/ntfy-selftest.service.

[Unit]
Description=Deliberately failing unit
OnFailure=ntfy-unit-failed@%n.service

[Service]
Type=oneshot
ExecStart=/bin/false

sudo systemctl daemon-reload
sudo systemctl start ntfy-selftest.service

La commande de démarrage se termine avec un code différent de zéro et affiche Job for ntfy-selftest.service failed because the control process exited with error code. Le téléphone doit vibrer environ une seconde plus tard. Supprimez ensuite l’unité de test.

Un piège mérite votre attention. OnFailure= s’exécute uniquement lorsqu’une unité atteint l’état failed. Un service avec Restart=always peut ne jamais atteindre cet état, car systemd le redémarre à la place. L’unité n’échoue qu’après avoir dépassé StartLimitBurst redémarrages dans StartLimitIntervalSec. Définissez ces deux valeurs pour tout service dont vous voulez être informé. Sinon, une boucle de crash peut continuer silencieusement pendant des jours. Les timers remplacent plus proprement le modèle Cron présenté plus haut : l’unité de service d’un timer reçoit OnFailure= automatiquement. Le guide des services et des timers systemd sur un VPS explique comment convertir l’un d’eux.

Intégrer un monitor de disponibilité au même topic

Uptime Kuma, le monitor de disponibilité auto-hébergé, propose un type de notification ntfy. Ouvrez Settings, puis Notifications, puis Setup Notification, sélectionnez Ntfy, définissez l’URL du serveur sur https://ntfy.example.com et le topic sur alerts, choisissez une priorité, puis collez le token d’accès robot. Envoyez la notification de test avant d’enregistrer, car un nom de topic incorrect échoue silencieusement avec un grant write qui ne couvre pas ce topic.

La limite réelle de cette configuration est la suivante : un monitor exécuté sur le même VPS ne peut pas vous indiquer que le VPS est hors service, et ntfy ne peut pas transmettre l’information que ntfy est hors service. Exécutez le monitor sur une autre machine et donnez-lui un second canal de notification, par exemple l’e-mail, pour le monitor qui surveille ntfy lui-même. Le type de monitor Push d’Uptime Kuma couvre l’autre angle mort : votre cron job appelle une URL push après une exécution réussie, et Kuma vous alerte lorsque ces appels cessent d’arriver. Une branche d’échec ne se déclenche que lorsque le job s’exécute ; elle ne dit donc rien d’un job qui n’a jamais démarré.

Le serveur ntfy auto-hébergé fonctionne-t-il sur Android et iPhone ?

Sur Android, oui, sans restriction. Installez l’application depuis Google Play ou F-Droid, ouvrez Settings, définissez le serveur par défaut sur https://ntfy.example.com, ajoutez votre compte dans l’écran de gestion des utilisateurs, puis abonnez-vous à alerts. La livraison instantanée maintient un foreground service actif afin que les messages arrivent même lorsque le téléphone est en mode doze. La notification permanente qui l’accompagne est une exigence d’Android pour les foreground services, et non un bug. La version F-Droid ne contient aucun code Firebase. Toutes les souscriptions utilisent donc la livraison instantanée. ntfy peut également servir de distributeur UnifiedPush, une solution open source qui remplace le service push de Google. Les autres applications compatibles avec UnifiedPush peuvent donc aussi transmettre leurs notifications via votre serveur.

Sur iOS, cela fonctionne avec une dépendance que vous ne pouvez pas supprimer. Apple ne réactive une application en arrière-plan que par l’intermédiaire d’APNs (Apple push notification service). Seul le détenteur des identifiants de signature de l’application peut lui envoyer des notifications. Votre serveur ne peut donc pas joindre directement l’application. ntfy contourne cette limitation avec un relay : votre serveur envoie un poll_request contenant l’identifiant du message à ntfy.sh. ntfy.sh le transmet ensuite par Firebase et APNs pour réactiver l’application. L’application récupère alors le contenu du message sur votre serveur.

upstream-base-url: "https://ntfy.sh"

Soyez clair sur le coût de ce fonctionnement. Le contenu du message reste sur votre serveur, mais le fait qu’un message soit arrivé, ainsi que son identifiant, transite par une infrastructure que vous ne contrôlez pas. Sans ce paramétrage, les notifications d’un serveur auto-hébergé arrivent en retard sur iPhone ou n’arrivent pas du tout, car rien ne réactive l’application. Le seul moyen de supprimer le relay consiste à compiler et publier vous-même l’application iOS avec votre propre compte Apple Developer et vos propres clés APNs. Cela implique des frais annuels et une nouvelle compilation pour chaque mise à jour. Si ce relay ne convient pas à votre usage, conservez les alertes sur Android ou dans l’application web de bureau.

Sauvegardes, mises à niveau et verrouillage de l’image

Deux chemins ne peuvent pas être régénérés : /etc/ntfy/server.yml et /var/lib/ntfy/user.db. Le second contient tous les utilisateurs, les hachages de mots de passe, les entrées ACL et les tokens. Traitez-le comme une clé privée.

sudo tar czf ntfy-backup.tgz -C / etc/ntfy var/lib/ntfy
sudo chmod 600 ntfy-backup.tgz

Copiez ce fichier hors du serveur. cache.db contient uniquement les messages récents, sur 12 heures avec le cache-duration ci-dessus. Sa perte ne coûte donc rien qu’il soit utile de protéger. Pour effectuer une mise à niveau, modifiez le tag dans le fichier Compose, puis faites un pull.

sudo docker compose pull
sudo docker compose up -d
curl -s https://ntfy.example.com/v1/health

Lisez d’abord les notes de version. Les bases SQLite sont migrées au démarrage. Revenir à un tag plus ancien après une modification du schéma n’est donc pas sûr. Conservez la sauvegarde que vous venez de créer jusqu’à ce que la nouvelle version ait fonctionné pendant une journée.

Gotify et Apprise

Gotify est l’option la plus légère : un seul binaire avec une interface web et une application Android, sans jokers de topic ni client iOS officiel. Il convient donc à un serveur privé dont la seule cible est Android. Apprise est une bibliothèque Python et un outil en ligne de commande, pas un serveur. Il diffuse un même message vers plus d’une centaine de services, dont ntfy. Il convient donc à un script qui doit atteindre plusieurs destinations simultanément. ntfy est le seul des trois à fournir un serveur, une API HTTP et des applications sur les deux plateformes mobiles. C’est pourquoi il est généralement choisi pour l’envoi d’alertes depuis un serveur loué.

FAQ

Pourquoi la publication vers mon serveur ntfy renvoie-t-elle 403 ?

Avec auth-default-access: "deny-all" dans server.yml, une publication anonyme est refusée, ce qui est le comportement prévu. Envoyez des identifiants avec -u user:pass ou -H "Authorization: Bearer tk_...". Si vous envoyez déjà un token et obtenez toujours 403, l’utilisateur associé à ce token ne possède aucune entrée ACL correspondant au topic. Exécutez ntfy access pour afficher la liste complète. N’oubliez pas qu’une autorisation write ne permet pas de s’abonner : un compte qui publie correctement sera donc quand même refusé lorsqu’il essaiera de lire le même topic.

Les notifications fonctionnent-elles sur iPhone avec un serveur ntfy auto-hébergé ?

Oui, mais via un relay que vous ne pouvez pas éviter. Apple réveille les applications uniquement via APNs (Apple push notification service), et seul l’éditeur de l’application peut y envoyer des notifications. ntfy transmet donc à ntfy.sh un poll_request contenant l’identifiant du message, puis ntfy.sh le relaie vers l’appareil. Définissez upstream-base-url: "https://ntfy.sh" dans server.yml, puis redémarrez le conteneur. Le corps du message est toujours récupéré depuis votre serveur. Sans ce paramètre, les notifications iOS sont retardées ou n’apparaissent jamais.

Pourquoi l’alerte ntfy de ma tâche cron n’est-elle jamais arrivée ?

Exécutez d’abord la ligne curl seule pour vérifier que le token et le topic sont corrects. Si elle fonctionne manuellement mais pas depuis cron, l’échec se produit avant l’alerte : cron exécute les tâches avec un environnement minimal et un PATH court. Un script qui appelle une commande par son nom seul peut donc s’arrêter avant d’atteindre la ligne curl. Utilisez des chemins absolus, redirigez la sortie de la tâche vers un fichier journal, puis consultez ce fichier après l’exécution suivante. Une réponse 429 au lieu d’une livraison signifie que la limite de débit fonctionne et que votre script réessaie trop rapidement.

Dois-je exposer ntfy sur Internet public ?

Les applications mobiles doivent pouvoir y accéder depuis les réseaux mobiles. Un endpoint HTTPS public avec auth-default-access: "deny-all" et des ACL par topic constitue donc la configuration habituelle. Elle est sûre tant qu’aucun topic n’est lisible par everyone. Une instance accessible uniquement via un VPN convient lorsque chaque abonné est une machine que vous contrôlez. Cette configuration convient mal aux téléphones, car l’application ne reçoit les notifications que lorsque le tunnel est actif. Les alertes restent donc en attente jusqu’à la reconnexion du téléphone.