Latest newsFrançais
Back to feedTechnologiesNewsMeld Editorial

Un MaxCode au lieu d'une dizaine de clés : comment PushMeld ajoute des notifications là où elles n'existaient pas

Comment MaxCode transfère la gestion des notifications push et email des sites, serveurs, scripts et appareils vers PushMeld.

Imaginons un ordinateur domestique qui crée chaque nuit une sauvegarde de fichiers importants. Le résultat est enregistré dans le journal système : opération réussie ou erreur survenue.

Techniquement, tout fonctionne. La gêne survient le matin : il faut ouvrir manuellement le journal et vérifier le résultat. Le programme n'a pas d'application mobile, l'envoi de notifications par les développeurs n'est pas prévu, et personne ne va créer une infrastructure séparée juste pour cette fonction.

Grâce à PushMeld, il est possible d'ajouter une simple requête à ce processus. Après la fin de la sauvegarde, un message arrive sur le téléphone : la copie a été créée ou l'opération a échoué. Si nécessaire, la même notification peut également être reçue par email.

Le principe de cette idée repose sur MaxCode — un code sécurisé unique à travers lequel PushMeld obtient toutes les informations nécessaires pour la livraison ultérieure de la notification.

Lorsque j'ai découvert ce projet, c'est précisément MaxCode qui m'a semblé être sa partie la plus intéressante. Les notifications push et les emails ne sont pas nouveaux. Ce qui est bien plus important, c'est que le programme d'origine ne gère plus la livraison de ces notifications. Il informe simplement PushMeld de l'événement, et tout le reste se passe en dehors de lui.

Pour clarifier : PushMeld fait partie du système MELD®, et DigiMeld UG est la société qui le développe.

Seul l'événement connaît la source

Une intégration classique de notifications devient rapidement compliquée avec des détails techniques. Il faut définir un projet, configurer l'accès, stocker des clés, gérer les tokens d'appareils, connecter l'envoi d’emails et respecter les exigences des différentes plateformes mobiles.

PushMeld transfère tout cela de l'ancien système vers un circuit séparé, géré de manière indépendante.

Le logiciel de sauvegarde connaît seulement que l'opération s'est terminée avec succès ou erreur. Il transmet MaxCode, le titre et le corps du message.

Il n'a pas besoin de savoir :

  • combien d'appareils sont reliés au projet ;

  • quel téléphone est actif ;

  • par quel fournisseur le push doit passer ;

  • si la livraison par email est activée ;

  • si l'utilisateur a un nouveau smartphone ;

  • si l'ancien tablette a été désactivée ;

  • qui doit recevoir quelle notification.

Tout cela est déterminé à l'intérieur de PushMeld.

Selon moi, c'est ici que réside la principale idée architecturale du projet : MaxCode transfère la gestion des notifications de l'application où l'événement s'est produit vers un système dédié à leur livraison.

Un MaxCode unique au lieu d’un lot de clés

Lorsqu'on connecte un service externe, il faut généralement gérer plusieurs éléments : un identifiant de projet, une clé d'accès, éventuellement des secrets, des tokens d'appareils et des paramètres propres à chaque fournisseur.

MaxCode rassemble tout ce qu'il faut pour l'envoi dans un seul code sécurisé.

Pour chaque projet, un MaxCode spécifique est créé. Il intègre l'identification du projet, le droit d'envoyer des notifications et les données permettant à PushMeld d'appliquer la configuration de livraison appropriée.

La source d'envoi n’a pas besoin de stocker séparément :

  • l'identifiant du projet ;

  • la clé API et un secret supplémentaire ;

  • les tokens des appareils connectés ;

  • les paramètres de chaque destinataire ;

  • les clés des différents fournisseurs push ;

  • les paramètres pour push et email.

Une seule MaxCode est ajoutée au programme, site ou script. Lorsqu'il est reçu avec le message, PushMeld lui seul identifie le projet, vérifie la requête, trouve les appareils connectés et sélectionne les canaux disponibles.

MaxCode ne doit pas être perçu comme une clé supplémentaire — son rôle est de remplacer la combinaison habituelle de clés, tokens et identifiants dispersés par un seul code sécurisé.

Une notification envoyée là où ce n’était pas prévu

MaxCode peut être utilisé dans n'importe quel système capable de faire une requête HTTP de façon autonome ou via un petit script auxiliaire.

Par exemple, PushMeld peut signaler quand :

  • le serveur domestique ne répond plus ;

  • une sauvegarde est terminée ou a échoué ;

  • un script propre a exécuté une tâche longue ;
  • une imprimante 3D a terminé d'imprimer ;

  • un capteur a détecté une fuite ;

  • une porte a été ouverte ou une alarme déclenchée ;

  • une information importante est apparue sur un site ;

  • le prix d’un produit a changé ;

  • de l’espace pour écrire s’est libéré ;

  • un ancien programme a fini de traiter un gros fichier ;

  • une petite boutique en ligne a reçu une nouvelle commande.

Ces sources peuvent ne pas avoir leur propre application. Certains appareils ne peuvent faire que des requêtes simples, d'autres peuvent exécuter une commande utilisateur, et certains peuvent être complétés par un scénario d'automatisation court.

Ce qui suffit à transmettre un événement à PushMeld.

Le déclencheur ne devient pas un service de notifications autonome. Il limite simplement à fixer l’événement et à envoyer un message avec MaxCode. Le reste — destinataires, appareils, canaux et route technique — reste géré par PushMeld.

Pas seulement push, aussi email

Le nom PushMeld est avant tout associé aux notifications sur téléphone, mais ses capacités ne s’arrêtent pas là.

Pour la livraison, on peut utiliser push, email ou les deux — selon les paramètres du projet et les options accessibles.

Par exemple, une notification de sauvegarde réussie suffit à être affichée sur le téléphone. Une erreur grave peut aussi être envoyée par courrier électronique.

Dans les deux cas, l’application d’origine fait la même requête avec MaxCode. Il n’est pas nécessaire de configurer séparément un serveur de mail ou de créer un script parallèle.

La décision des canaux de livraison est prise dans PushMeld. Si plus tard un utilisateur ajoute une adresse email à un projet existant, il n’aura pas besoin de reprogrammer la sauvegarde.

Et l’email est utilisé ici comme un moyen supplémentaire d’informer d’un événement provenant du projet connecté, pas comme une campagne de masse.

Un projet, une source d’événements

Les projets permettent de segmenter les notifications en fonction de leur objectif.

Un utilisateur peut par exemple créer :

  • HomeServer — état du serveur domestique ;

  • Backups — résultats de sauvegarde ;

  • SmartHome — capteurs et automatisation ;

  • PriceMonitor — changements de prix ;

  • Website — nouvelles sur le site personnel.

Chacun reçoit son propre MaxCode. Cela permet d'éviter que la domotique ou la surveillance des prix ne soient mélangées avec des sauvegardes. La provenance du message est claire, et il est associé à une tâche précise.

Ce découpage est particulièrement utile quand il y a plusieurs sources : au lieu d’un flux unique, l’utilisateur a plusieurs canaux indépendants, chacun avec ses propres paramètres de livraison.

Un nouveau téléphone sans modification du programme

Un token push classique est lié à une installation d’application spécifique sur un appareil précis.

Si la personne a deux téléphones et une tablette, cela correspond à plusieurs tokens. En réinstallant ou en changeant d’appareil, un token peut changer ou devenir inopérant.

MaxCode opère au-dessus de ce niveau. Il concerne le projet, pas un seul téléphone.

L’utilisateur décide lui-même quels appareils sont liés au projet et doivent recevoir ses notifications. Par exemple, il peut envoyer des alertes du serveur domestique vers son téléphone privé et sa tablette, tandis que les alertes du site professionnel vont uniquement vers le smartphone de service.

Lorsque la personne achète un nouveau téléphone ou désactive l’ancien, le script d’origine continue d’utiliser le même MaxCode. La liste des destinataires actuels est maintenue au sein de PushMeld.

Il en va de même pour l’ajout d’un email ou la modification d’autres paramètres de livraison.

MaxCode n’est donc pas seulement une façon de réduire le nombre de clés. Il crée une frontière entre l’événement et son itinéraire ensuite. Tout ce qui se trouve après cette frontière peut être changé sans modifier le programme source.

Gratuit pour les tâches courantes

Les produits d’infrastructure sont souvent décrits par des systèmes d'entreprise, des commandes serveurs ou de grands volumes de données. On pourrait penser que PushMeld est réservé aux professionnels ou aux entreprises.

En réalité, on peut commencer avec une tâche domestique simple.

L’application elle-même est gratuite. Les fonctionnalités principales de MaxCode fonctionnent sans coût dans la limite des quotas gratuits. On peut créer un projet,connecter un appareil et recevoir des notifications de son serveur, site, script ou domotique.

Ce n’est pas une démonstration temporaire. Pour un usage quotidien, ces fonctionnalités gratuites sont généralement suffisantes.

Des plans tarifaires sont nécessaires lorsque le nombre de requêtes augmente, si des fonctionnalités supplémentaires sont demandées ou si le système est utilisé à plus grande échelle.

Un principe unique pour l’individu et l’entreprise

Le fonctionnement de MaxCode ne varie pas selon la taille de la tâche.

Une personne reçoit une notification de fin de sauvegarde. Un atelier découvre que son imprimante 3D a terminé une impression longue. Une boutique en ligne reçoit une nouvelle commande. L’équipe technique est avertie d’une erreur serveur.

Les volumes ou le nombre de projets peuvent différer, mais le principe reste le même.

Prenons une organisation avec trois sources d'événements :

  • Orders — nouvelles commandes ;

  • Payments — paiements et remboursements ;

  • ServerStatus — erreurs techniques.

Pour chaque source, un MaxCode spécifique est créé et ses appareils configurés. Les commandes sont envoyées au propriétaire et au gestionnaire, les événements financiers au responsable, et les erreurs techniques aux employés qui entretiennent le serveur.

Dans tous les cas, le système fait essentiellement la même chose : transmettre le contenu de l’événement et le MaxCode correspondant.

Si des employés changent, ou si les appareils ou les méthodes de livraison évoluent, il n’est pas nécessaire de reconfigurer le système d’origine. La gestion reste à l’intérieur de PushMeld.

APNs, FCM et HMS restent hors du programme

Pour la livraison push sur différents appareils, il peut utiliser APNs, FCM ou HMS. Chaque fournisseur a ses règles, ses tokens et ses spécificités techniques.

Ces différences doivent généralement être prises en compte lors du développement du système d’envoi. Avec PushMeld, elles sont gérées en dehors du MaxCode.

Le serveur domestique, le site ou le script ne détermine pas quel téléphone le destinataire utilise ni par quelle infrastructure le message doit passer. Ils envoient une seule requête, et PushMeld choisit le chemin approprié.

MaxCode ne remplace pas les infrastructures d’Apple, Google ou Huawei. Il constitue une entrée unifiée avant elles.

De cette façon, le système d’origine n’a pas besoin d’évoluer avec les appareils de l’utilisateur. Aujourd’hui, le message peut passer par FCM, demain par APNs, ou un autre téléphone ou email peut être ajouté au projet. Pour le logiciel où l’événement s’est produit, rien ne change.

MaxCode et clé API ordinaire — ce n’est pas la même chose

Une clé API classique permet rarement autre chose qu’un accès au service. Après vérification, le système doit aussi connaître le projet, les destinataires et le mode de livraison.

MaxCode combine ces contextes dans un seul code.

Il permet à PushMeld de reconnaître le projet, de vérifier la requête et d’appliquer ses paramètres actuels. Le programme externe transmet juste le MaxCode et le contenu de l’événement, sans gérer la suite du routage.

La différence pratique peut être résumée ainsi : une clé API donne accès à une fonction, mais MaxCode indique aussi dans quel contexte cette fonction doit être exécutée.

Notification comme fonctionnalité intégrable

Après avoir découvert PushMeld, je ne le qualifierais pas seulement d’application de notifications push.

Il s’agit plutôt d’un moyen d’ajouter des notifications là où elles n’étaient pas possibles auparavant, puis de les gérer de façon indépendante du programme source.

La source peut être un serveur domestique, un capteur, une vieille application, une boutique en ligne, un script personnalisé ou un système interne d’entreprise. Si elle peut faire une requête HTTP toute seule ou via un petit script d’accompagnement, l’événement peut lui être transmis à PushMeld.

Ensuite, MaxCode établit la frontière entre l’événement et sa livraison. D’un côté se trouve le programme qui indique ce qui s’est produit, de l’autre, PushMeld, qui détermine le projet, les appareils, les canaux et la route technique.

Par conséquent, la capacité la plus importante de MaxCode n’est pas seulement de remplacer plusieurs clés par un seul code. Il transfère la gestion des notifications en dehors du système source.

Le téléphone peut être remplacé, l’email ajouté, un vieux appareil désactivé, ou le trajet de livraison modifié, tout en conservant la fonction principale : informer sur l’événement.