Quand plusieurs ordinateurs synchronisent une même instance, leurs vérifications périodiques peuvent multiplier les requêtes même si aucun fichier n'a changé. Nextcloud Notify Push, nommé Client Push dans l'App Store, réduit ces contrôles en signalant les changements aux clients. En 2026, son installation ne consiste pourtant pas à activer une simple extension : elle requiert Redis, un démon permanent et un proxy inverse compatible WebSocket. Ce guide explique son rôle exact, sa mise en place et les tests à effectuer, sans lui attribuer une garantie de livraison qu'il ne fournit pas.
À quoi sert Nextcloud Notify Push ?
Le client de synchronisation Nextcloud doit savoir quand un fichier a été ajouté, modifié ou supprimé sur le serveur. Sans mécanisme de poussée, il interroge périodiquement l'instance. Cette méthode reste fonctionnelle, mais chaque poste connecté produit des contrôles, y compris lorsque le contenu n'a pas évolué. L'effet devient plus visible quand le nombre de clients augmente.
L'application officielle notify_push ajoute un canal de notification entre le serveur et les clients. Lorsqu'un changement pertinent survient, le service avertit le client, qui peut alors contrôler et synchroniser les données. Elle ne transporte pas les fichiers à la place de Nextcloud. Elle ne remplace pas non plus le protocole de synchronisation décrit dans notre guide Nextcloud Desktop et mobile.
La documentation du projet qualifie ces notifications de « best effort ». Un changement peut arriver sans notification, et une notification peut être émise alors qu'aucune mise à jour utile n'attend le client. Celui-ci doit donc conserver des vérifications périodiques, mais il peut les espacer. C'est une optimisation de réactivité et de charge, pas une file de messages garantissant chaque événement.
Au 24 septembre 2026, l'App Store Nextcloud affiche Client Push 1.4.0 pour Nextcloud 30 à 35, avec des versions antérieures pour les branches 20 à 29. La page de version officielle date la 1.4.0 du 12 août 2026 et annonce sa compatibilité avec Nextcloud 35. Vérifiez toujours la ligne proposée pour votre version avant une mise à jour.
Notification ne veut pas dire synchronisation
Notify Push annonce qu'un contrôle est utile. Le client Nextcloud vérifie ensuite l'état distant et exécute la synchronisation normale. Les conflits, fichiers ignorés et erreurs de droits restent traités par le client.
Quels prérequis faut-il préparer ?
Redis est obligatoire. Nextcloud doit déjà être configuré pour l'utiliser, car le démon s'appuie sur sa fonction de publication et d'abonnement pour recevoir les événements. La documentation permet une instance Redis distincte via l'option notify_push_redis, notamment lorsque l'administrateur veut séparer ce trafic de l'usage courant du cache. Ce choix demande une exploitation supplémentaire et n'est pas requis pour commencer.
Le service a aussi besoin de lire la configuration Nextcloud, ou de recevoir séparément les paramètres de base de données, Redis et URL d'instance. Le projet recommande de charger config.php, car le démon reste ainsi aligné avec l'application. Si ce fichier n'est pas accessible, les variables DATABASE_URL, DATABASE_PREFIX, REDIS_URL et NEXTCLOUD_URL peuvent fournir les informations nécessaires. Ne placez jamais leurs secrets dans un fichier lisible par tous.
Prévoyez ensuite un processus permanent. L'exemple officiel utilise systemd avec Restart=always, un utilisateur de service non privilégié et le port local 7867. OpenRC est aussi documenté. Le port se règle avec PORT ou --port; un socket Unix est possible avec SOCKET_PATH. Le démon doit être redémarré après chaque mise à jour de l'application afin de charger le nouveau binaire.
Enfin, le domaine public doit être servi en HTTPS par un proxy inverse capable de transmettre WebSocket. Le projet déconseille l'exposition directe du démon. Le proxy évite d'ouvrir un port supplémentaire sur Internet et chiffre la connexion. Si le proxy et le démon se trouvent sur des hôtes différents, le projet prévoit aussi TLS entre eux avec TLS_CERT et TLS_KEY.
| Élément | Rôle | Point à vérifier |
|---|---|---|
| Redis | Transmettre les événements au démon | Nextcloud l'utilise déjà correctement |
| Base de données | Résoudre les informations nécessaires | Accès identique à la configuration Nextcloud |
Démon notify_push | Maintenir les connexions et émettre les signaux | Démarrage automatique et redémarrage après mise à jour |
| Proxy inverse | Publier /push/ en HTTPS et WebSocket | En-têtes Upgrade, chemin et barres obliques |
| Clients Nextcloud | Recevoir le signal puis vérifier les fichiers | Versions maintenues et synchronisation saine |
Comment installer et relier le service ?
Installez d'abord Client Push depuis l'App Store de l'instance. Depuis le répertoire Nextcloud, la commande suivante active l'application si elle est déjà installée :
sudo -u www-data php occ app:enable notify_push
Le chemin de php, l'utilisateur du serveur web et le répertoire d'installation varient selon votre système. N'appliquez donc pas cet exemple sans les adapter. L'assistant officiel couvre la majorité des installations :
sudo -u www-data php occ notify_push:setup
En configuration manuelle, créez un service qui lance le binaire fourni par l'application avec le chemin absolu de config.php. Le projet donne 7867 comme port par défaut. Le service doit fonctionner sous un compte autorisé à lire la configuration, sans recevoir plus de droits que nécessaire. Après avoir rechargé systemd, activez le démarrage automatique puis contrôlez l'état du processus et ses journaux.
Le schéma sépare quatre fonctions : Nextcloud enregistre le changement, Redis publie l'événement, le démon maintient le canal de notification, puis le proxy expose ce canal aux appareils. Cette séparation aide à localiser une panne. Une synchronisation web fonctionnelle ne prouve pas que Redis publie, et un démon actif ne prouve pas que le WebSocket traverse le proxy.
Sauvegardez avant de modifier l'infrastructure
Une erreur de proxy peut affecter le domaine Nextcloud entier. Validez la syntaxe, conservez la configuration précédente et prévoyez un retour arrière avant de recharger le serveur web.
Comment configurer le proxy WebSocket ?
Pour Nginx, la documentation officielle place un bloc location dans le serveur virtuel Nextcloud. Les deux barres obliques finales sont nécessaires :
location ^~ /push/ {
proxy_pass http://127.0.0.1:7867/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Validez la configuration Nginx avant son rechargement. Pour Apache, le projet documente proxy, proxy_http et proxy_wstunnel, puis deux routes distinctes : /push/ws vers le WebSocket et /push/ vers HTTP. Caddy v2 peut utiliser handle_path /push/* avec un reverse_proxy pointant vers le démon local.
Une fois le proxy accessible, associez l'application à son URL publique :
sudo -u www-data php occ notify_push:setup https://cloud.exemple.fr/push
La commande lance automatiquement plusieurs tests. Une réussite est plus probante que la seule présence du processus, car elle vérifie la chaîne depuis l'instance. Si Nextcloud signale que le serveur push n'est pas un proxy de confiance, cherchez d'abord une liste trusted_proxies dupliquée et contrôlez forwarded_for_headers. Le README officiel demande que HTTP_X_FORWARDED_FOR reste présent lorsque ce réglage a été personnalisé.
Pour Docker, NEXTCLOUD_URL doit désigner une adresse joignable depuis le conteneur du démon. Selon le réseau, ce peut être le nom du service interne plutôt que le domaine public. Avec un certificat autosigné, la documentation propose une URL locale non chiffrée sur un réseau maîtrisé ou ALLOW_SELF_SIGNED=true. Désactiver la validation réduit toutefois l'assurance d'identité : un certificat de confiance reste préférable.
Comment tester le fonctionnement et diagnostiquer une panne ?
Commencez par la commande de configuration, puis observez un cas réel : modifiez un fichier depuis un premier appareil et vérifiez qu'un second client détecte rapidement le changement. Ce test ne doit pas se limiter à l'interface web. Il faut utiliser les clients et le parcours réseau qui bénéficieront réellement de Notify Push. Pour comprendre l'événement obtenu, le journal d'activité Nextcloud complète l'observation du client.
Le service journalise seulement les avertissements par défaut. Augmentez temporairement le niveau pendant le diagnostic, puis restaurez-le pour éviter un volume inutile :
sudo -u www-data php occ notify_push:log debug
sudo -u www-data php occ notify_push:log --restore
Les niveaux acceptés par le projet sont error, warn, info, debug et trace. Utilisez trace sur une durée courte, car il produit davantage d'informations. Contrôlez en parallèle les journaux du proxy, du service et de Nextcloud. Une réponse HTTP incorrecte sur /push/, un échec de mise à niveau WebSocket ou une connexion Redis refusée orientent vers des couches différentes.
Notify Push peut publier des métriques compatibles Prometheus grâce à METRICS_PORT, ou sur un socket Unix via METRICS_SOCKET_PATH. Attention : le port de métriques écoute par défaut sur toutes les interfaces. Filtrez son accès ou préférez un socket local. La commande suivante fournit aussi des métriques sans exposer ce point réseau :
sudo -u www-data php occ notify_push:metrics
Après une mise à jour de l'application, redémarrez le démon et relancez les tests. Vérifiez aussi la compatibilité dans l'App Store avant de changer de branche Nextcloud. Enfin, gardez les contrôles de sécurité Nextcloud séparés : Notify Push réduit des vérifications périodiques, mais ne remplace ni les mises à jour, ni la protection des comptes, ni les sauvegardes.
Faut-il déployer Notify Push sur toutes les instances ?
Le gain potentiel augmente avec le nombre de clients de bureau connectés et la fréquence des changements. Une instance utilisée seulement depuis le navigateur tirera peu de valeur de ce canal. À l'inverse, une équipe qui synchronise plusieurs postes peut rechercher une détection plus rapide tout en réduisant les interrogations répétées. Le choix doit donc partir des usages observés, pas de la seule disponibilité de l'application.
L'exploitation a un coût : service permanent, Redis, règles de proxy, supervision et redémarrage après mise à jour. Si ces éléments ne sont pas maîtrisés, une synchronisation classique bien configurée reste préférable à un composant supplémentaire mal suivi. Mesurez avant et après, en comparant les connexions, les erreurs du proxy et la perception des utilisateurs. Ne promettez pas une livraison instantanée, puisque le projet conserve explicitement une sémantique de meilleur effort.
Pour une instance autogérée, documentez le binaire, le compte système, l'URL interne, les règles de pare-feu et la procédure de retour arrière. Pour un service géré, demandez si Client Push est installé, surveillé et compatible avec l'architecture proposée. Le guide d'hébergement Nextcloud en France aide à replacer cette fonction parmi les critères de stockage, d'administration et d'assistance.
Conclusion
Nextcloud Notify Push est pertinent lorsque des clients synchronisés interrogent souvent la même instance. Son intérêt repose sur une chaîne entière : Redis opérationnel, démon permanent, proxy WebSocket correct, URL publique testée et clients maintenus. Le contrôle final doit confirmer la commande de configuration, un changement réel entre deux appareils, les journaux et les métriques. Si vous préférez utiliser Nextcloud sans administrer ces composants, comparez le périmètre exact du service avant de commander.
Découvrir l'offre Nextcloud GaprodEspace privé hébergé en France