Messagerie RKR : flux, notifications push et boutique d’applications installables (PWA)

21/10/2026
v2.0.4

[destacado] Le bouton de notifications fonctionne désormais et ne masque plus la conversation.

• Le bouton rond qui apparaît après avoir appuyé sur « Plus tard » permet de rouvrir la notification (il était auparavant inactif pendant les jours de pause). Si les notifications de votre navigateur sont bloquées, une alerte s'affichera puis la notification disparaîtra.
• Il se place désormais dans le coin inférieur gauche, au-dessus du bouton WhatsApp et en dessous des discussions. Il peut être déplacé à l'aide des variables CSS --rkrmensajeria-campana-left/right/bottom/z .

17/10/2026
v2.0.3

RKR Push s'appelle désormais RKR Messaging et son fonctionnement est similaire à celui de Klaviyo. [destacado] Résumé des nouveautés par rapport à RKR Push 1.0.1 (détails dans les 2.0.0 à 2.0.2 ) :

• Parcours utilisant le modèle « Navigation abandonnée » : les utilisateurs qui consultent régulièrement un produit ou une catégorie sans effectuer d’achat reçoivent une notification contenant le produit, son prix actuel et des produits similaires. Les filtres sont vérifiés avant chaque étape, les soumissions intelligentes sont activées et les heures de faible activité sont respectées. Les textes sont disponibles en espagnol, anglais, français, allemand, italien et portugais.
• Le transfert depuis RKR Push s'effectue sans aucune perte : abonnés et clés VAPID inclus ; personne n'a besoin d'accepter à nouveau l'autorisation.
• Il coexiste avec RKR OmniCRM , qui envoie ses notifications push via ce module.
• Clics également attribués depuis le navigateur.
• De nouveaux manuels ( docs/manual-es.pdf , docs/manual-en.pdf ) intitulés « Messagerie RKR » sont disponibles. Ils abordent les flux de travail, l’intégration avec RKR OmniCRM et la transmission de données depuis RKR Push. Documentation uniquement ; le code est celui de la version 2.0.2.
• Le service de relais est à nouveau appelé par son nom d'origine, RKR Push Relay.
• Le menu d'administration s'affiche désormais dans la langue de la boutique. Auparavant, PrestaShop 9 créait les onglets après l'installation du module et ils restaient en anglais ; maintenant, ils sont traduits dès la première ouverture de l'administration.

07/10/2026
v1.0.1

Correctifs de sécurité. Une mise à jour est recommandée.

• Chaque action dans le back-office vérifie désormais les autorisations du profil. PrestaShop ne les vérifie que pour les actions qu'il reconnaît (suppression d'un élément d'une liste, enregistrement d'un formulaire standard). Auparavant, les actions spécifiques à un module étaient accessibles à tout employé ayant accès à l'onglet. Un profil en lecture seule pouvait envoyer une campagne à tous les abonnés , modifier l'URL et les clés de relais, régénérer la paire VAPID ou supprimer des variantes de notification. Désormais : affichage pour l'exportation et les rapports, ajout pour la création et l'importation, modification pour l'enregistrement, la planification et les tests, et suppression pour la suppression.
• Seuls les super-administrateurs peuvent télécharger l'export contenant les clés ; par défaut, il est exporté sans ces clés. Ce fichier contient les clés du navigateur et la clé privée VAPID : grâce à elle, vous pouvez communiquer avec tous les abonnés depuis n'importe où. La génération et le renouvellement de la paire VAPID sont également réservés aux super-administrateurs.
• Les tests ne peuvent plus être envoyés directement aux clients. Auparavant, ils étaient envoyés au dernier abonné ayant consulté la page, généralement un client dans une boutique en ligne : ce dernier recevait la campagne incomplète. Désormais, ils sont uniquement envoyés aux appareils de test sélectionnés par le marchand dans les paramètres de son propre navigateur, via un bouton permettant de sélectionner l'abonnement de ce navigateur : il est impossible de sélectionner celui d'un autre utilisateur.
• La notification de retour à la version par défaut ne s'applique qu'au navigateur lui-même. Elle acceptait un seul identifiant d'abonné par paramètre ; il était donc possible d'abonner un autre utilisateur à des notifications qu'il n'avait pas demandées.
• Le service worker ne sauvegarde plus les pages d'administration. Son / inclut le dossier d'administration, et les pages contenant les données client, les commandes et les jetons étaient auparavant stockées dans le cache du navigateur de l'employé. Désormais, il ne sauvegarde plus les données marquées comme no-store ou private par le serveur, ce qui correspond au fonctionnement du back-office PrestaShop. Lors d'une mise à jour du service worker, les caches de la version 1.0.0 sont supprimés, effaçant ainsi toutes les données mises en cache.
• L'exportation de la configuration n'inclut plus le jeton cron ni la clé du compte relais. Elle peut être téléchargée à l'aide d'un profil en lecture seule, et le jeton cron est utilisé pour initier les transmissions.

28/09/2026
v1.0.0

Première version.

• PWA complète : manifeste généré à partir de la configuration, icônes de toutes tailles — y compris des icônes masquables — issues du logo de la boutique, service worker avec stratégies de mise en cache par type et sa propre page hors ligne.
• Le service worker est servi depuis le domaine du magasin avec l'en-tête Service-Worker-Allowed , et l'écran des paramètres vérifie la portée réelle en examinant les en-têtes qui arrivent réellement, y compris le CDN en amont.
• Capturez des abonnés grâce à votre propre notification en deux étapes et à des tests A/B, avec des déclencheurs pour le temps, le défilement, la sortie, l'ajout au panier et le nombre de vues.
• Enregistrement du consentement avec date, heure, adresse IP tronquée, texte affiché et version.
• Sept automatisations : panier abandonné en trois étapes avec coupon, retour en stock, baisse de prix, statut de la commande, navigation abandonnée, réapprovisionnement suite à la consommation et réactivation des articles inactifs.
• Campagnes avec segmentation comportementale, planification, topic , boutons d'action, aperçu et compteur d'octets réel après chiffrement.
• Indicateurs complets — envoyés, affichés, cliqués, fermés, expirés — et revenus attribués avec une fenêtre configurable.
• Importation depuis PushOwl/Brevo, OneSignal, PushEngage, Webpushr et CSV générique, avec tests d'échantillons avant acceptation du lot et panneau de progression de réabonnement silencieux.
• Exportation complète en un clic, avec paires clés et VAPID, aux formats CSV et JSON.
• Mode autonome de premier ordre : le module gère la distribution indépendamment via curl_multi et son partenaire VAPID. Une fois le relais RKR Push connecté, il délègue la distribution en masse et, en cas de défaillance du relais, les transactions critiques sont envoyées depuis la boutique.
• Budget de fréquence par abonné, heures de silence dans le fuseau horaire de chaque abonné et déduplication.
• Rotation de la paire VAPID avec une période de grâce.
• Prise en charge multi-magasins et multilingue, accessibilité WCAG 2.2 AA dans la notice, pas de JavaScript intégré et aucune dépendance tierce.

Vérifié avant publication

Installé et exécuté sur PrestaShop 9.1.5 (multi-boutiques, deux boutiques). Quatre éléments en sont ressortis, invisibles à la lecture du code :

• Une URL conviviale se terminant par .js ne fonctionne pas dans PrestaShop. Le serveur ignore le routage pour les URL se terminant par .gif , .jpg , .png , .css , .js ou .ico . Le chemin du service worker n'a pas d'extension ; le navigateur examine l'en-tête Content-Type .
• ObjectModel rejette une date nulle lors de chaque UPDATE si le champ n'est pas déclaré avec allow_null . Ce comportement s'est produit lors du deuxième enregistrement, c'est-à-dire lors de la deuxième inscription effectuée avec le même navigateur.
• Db::getValue() ajoute sa propre LIMIT 1 , si bien qu'une requête avec LIMIT ... OFFSET se transforme en LIMIT 1 OFFSET 5000 LIMIT 1 et MySQL la rejette. Ce problème ne se produit que lors du nettoyage quotidien : une erreur par jour.
• Google rejette Urgency: very-low avec une erreur 400, bien que défini par la RFC 8030 ; il n'accepte que high , normal et low . Sans traduction, le test d'importation aurait entraîné la résiliation de tous les abonnements Chrome. La distribution a été vérifiée auprès de fcm.googleapis.com : un point de terminaison inexistant renvoie une erreur 410 , ce qui prouve que le service accepte la signature VAPID et le chiffrement, et que le module l'interprète comme une résiliation définitive.