République Algérienne Démocratique et Populaire

Ministère de la Défense Nationale

École Militaire Polytechnique

Memoire de fin d‘etude

Filière : Génie Informatique
Spécialités : Système d’information et aide à la décision
Intelligence artificielle et science de donnée

Développement du système de
communication et d‘alerte au profit de la
sécurité publique -Chapitre02-

Réalisé par : Encadrants :

Eoc LAGHRIB Yahia Dr. Boukarca Ahcen
Eoc RAMDANI Oussama Dr. DJEBRI Ahmed El Amine

Année Universitaire
2024/2025
Table des matières

Liste des figures iv

Liste des tableaux v

Nomenclature vi

I Généralités sur les systèmes de notification 0

I.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
I.2 Etude des système de notification existant . . . . . . . . . . . . . . . . . . 2
I.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
I.2.2 ntfy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I.2.3 Gotify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
I.2.4 Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.2.5 Rpush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I.2.6 Iris Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
I.2.7 Pushover for Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . 16
I.3 Analyse comparative des systèmes de notification . . . . . . . . . . . . . . 19
I.3.1 Critères de comparaison . . . . . . . . . . . . . . . . . . . . . . . . 19
I.3.2 Analyse comparative . . . . . . . . . . . . . . . . . . . . . . . . . . 19
I.3.3 Principaux résultats et discussion . . . . . . . . . . . . . . . . . . . 20
I.4 Composants d’un Système de Notification . . . . . . . . . . . . . . . . . . 21
I.4.1 Message Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
I.4.2 Notification Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
I.4.3 Thick Client (Heavy Client) . . . . . . . . . . . . . . . . . . . . . . 23
I.5 Solutions existantes pour chaque composant . . . . . . . . . . . . . . . . . 24
I.5.1 Message Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
I.5.2 Notification Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

ii
EMP Sommaire

I.5.3 Thick Client (Heavy Client) . . . . . . . . . . . . . . . . . . . . . . 25

I.6 Analyse des Composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
I.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Bibliographie 30

iii
Liste des figures

iv
Liste des tableaux

I.1 Comparaison des systèmes de notification . . . . . . . . . . . . . . . . . . 20

v
Nomenclature

AFIS Automated Fingerprint Identification System

AMQP Advanced Message Queuing Protocol
APNs Apple Push Notification Services
CRUD Create, Read, Update, Delete
E-mail Electronic Mail
FCM Firebase Cloud Messaging
GN Gendarmerie Nationale
HTTP Hypertext Transfer Protocol
IBIS Integrated Ballistic Identification System
IoT Internet of Things
LIMS Laboratory Information Management System
MCS Managed Cloud Service
MQTT Message Queuing Telemetry Transport
Pub/Sub Publish/Subscribe
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SOA Service-Oriented Architecture
UML Unified Modeling Language
XMPP Extensible Messaging and Presence Protocol

vi
 Chapitre I

GÉNÉRALITÉS SUR LES SYSTÈMES DE

NOTIFICATION
EMP [Link]́néralités sur les systèmes de notification

I.1 Introduction

L’essor des architectures distribuées et des applications en temps réel a conduit à une
évolution significative des systèmes de notification. Ceux-ci jouent un rôle clé dans la
transmission efficace et fiable d’informations aux utilisateurs finaux, qu’il s’agisse de noti-
fications mobiles, de mises à jour système ou d’alertes critiques. Cependant, la conception
d’un système de notification performant repose sur l’intégration de plusieurs composants
interdépendants : un message broker assurant l’acheminement des messages, un serveur
de notification chargé de leur traitement et de leur distribution, ainsi qu’un client lourd
permettant leur réception et leur affichage sur les terminaux utilisateurs.
Ce chapitre se consacre à l’étude approfondie des systèmes de notification existants, en
mettant en lumière leurs avantages et leurs limites. Dans un premier temps, une analyse
critique des solutions actuellement disponibles est menée, mettant en évidence les défis
liés à leur adoption et leurs éventuelles inadéquations aux besoins spécifiques d’un projet
donné. Ensuite, une présentation détaillée des principaux composants d’un système de
notification est réalisée, en s’appuyant sur une comparaison des technologies utilisées pour
leur mise en œuvre. Enfin, une synthèse des choix technologiques retenus est proposée,
justifiant les décisions prises en fonction des critères de performance, de scalabilité et de
flexibilité.
L’objectif de cette étude est d’identifier les solutions les plus adaptées pour construire
un système de notification robuste et évolutif, répondant aux exigences des applications
modernes nécessitant des communications fiables et en temps réel.

I.2 Etude des système de notification existant

I.2.1 Introduction

Dans l’écosystème numérique en perpétuelle mutation, les systèmes de notification

constituent l’un des piliers invisibles mais essentiels de l’interaction entre les plateformes
technologiques et leurs utilisateurs. Véritables vecteurs d’information, ces mécanismes
transcendent la simple fonctionnalité technique pour s’ériger en instruments stratégiques
de communication, capables d’influencer l’engagement, la rétention, voire même la percep-
tion d’une marque. Qu’il s’agisse de notifications push surgissant à l’écran, de courriels soi-
gneusement personnalisés, de SMS concis ou d’alertes intégrées aux applications, chaque
modalité incarne une philosophie distincte de diffusion et de réception de l’information.

2
EMP [Link]́néralités sur les systèmes de notification

Pourtant, derrière cette apparente ubiquité se cache une réalité plus nuancée : tous ces
systèmes ne se valent pas. Leur efficacité, leur pertinence contextuelle et leur résonance
auprès des utilisateurs divergent radicalement selon leur conception, leur implémentation
et leur finalité. Certains parviennent à captiver avec une discrète élégance, tandis que
d’autres, par leur intrusivité ou leur manque de finesse, risquent de susciter l’indifférence,
voire l’exaspération.
C’est dans cette optique que cette section entreprend une exploration rigoureuse des ar-
chitectures notificationnelles dominantes, en dévoilant leurs rouages techniques, leurs fon-
dements algorithmiques et leurs répercussions comportementales. Nous ne nous contente-
rons pas d’un simple inventaire descriptif ; nous ambitionnons plutôt de mener une analyse
approfondie, juxtaposant les forces et les faiblesses intrinsèques de chaque approche, afin
d’en révéler les subtilités opérationnelles et les implications ergonomiques. Notre démarche
s’articulera selon une progression méthodique :

- Cartographie des systèmes de notification prédominants : Examen détaillé des

modalités existantes, de leurs infrastructures sous-jacentes et de leurs logiques de
déclenchement.

- Étude comparative : Mise en regard systématique des performances respectives,

évaluées à l’aune de critères tels que la rapidité, la personnalisation, l’intrusivité et
l’efficacité conversionnelle.

- Critique raisonnée : Réflexion approfondie sur les écueils fréquents, les dilemmes
éthiques (notamment en matière de respect de la vie privée) et les arbitrages néces-
saires entre sollicitation et discrétion.

En menant cette investigation, nous cherchons non seulement à élucider les déterminants
d’un système de notification réussi, mais aussi à anticiper les évolutions futures dans un
paysage où l’attention devient une ressource toujours plus rare et précieuse. Ce faisant,
nous posons les jalons d’une réflexion plus large sur l’équilibre délicat entre technologie,
utilité et expérience humaine.

I.2.2 ntfy

Ntfy (prononcé ”notify”) est un service de notification push open-source et auto-

hébergeable, conçu comme une alternative respectueuse de la vie privée aux plateformes
propriétaires telles que Firebase Cloud Messaging (FCM) et Apple Push Notification Ser-
vice (APNS). Contrairement aux services centralisés susceptibles de collecter des données

3
EMP [Link]́néralités sur les systèmes de notification

utilisateur, Ntfy garantit un contrôle total, une sécurité des données renforcée et une
conformité avec des réglementations telles que le GDPR et l’HIPAA.
Au cœur de son fonctionnement, Ntfy adopte un modèle de publication-abonnement
(pub/sub), où les messages sont envoyés à un sujet spécifique et reçus de manière asyn-
chrone par les abonnés. Cette architecture permet une communication efficace et en temps
réel sans nécessiter de connexions persistantes, optimisant ainsi l’utilisation des ressources.
Ntfy se distingue par sa flexibilité et sa facilité d’intégration, en prenant en charge des
protocoles web standards tels que les APIs RESTful HTTP, les WebSockets et MQTT,
éliminant ainsi la nécessité de bibliothèques propriétaires. Cette approche agnostique en
termes de plateformes permet un déploiement sur des applications web, des appareils
mobiles, des interfaces en ligne de commande (CLI ) et des systèmes IoT.
Les caractéristiques architecturales et opérationnelles de Ntfy offrent plusieurs avan-
tages significatifs :

— Léger et efficace : Aucune bibliothèque spécifique au fournisseur n’est requise ; des

appels HTTP simples suffisent pour gérer les messages, réduisant ainsi la surcharge.

— Respectueux de la vie privée : Les messages ne sont ni stockés ni traités, sauf

configuration explicite, garantissant ainsi la sécurité et la conformité aux réglemen-
tations.

— Hautement adaptable : Compatible avec une grande variété d’applications, allant

de la surveillance système à l’automatisation DevOps et à la gestion des tâches
personnelles.

Grâce à sa polyvalence, Ntfy est utilisé dans divers domaines, notamment :

— Surveillance système et alertes d’infrastructure : S’intègre avec des outils comme

Prometheus, Nagios et Grafana pour notifier les administrateurs de l’état des ser-
veurs, des événements de sécurité ou des défaillances.

— CI/CD et automatisation : Permet d’envoyer des alertes en temps réel sur l’état
des builds, les échecs de déploiement et les résultats des tests, facilitant ainsi des
réponses rapides dans les pipelines de développement logiciel.

— Automatisation des tâches et productivité personnelle : Facilite des flux de noti-

fications personnalisés pour les rappels, les listes de tâches et les alertes planifiées,
améliorant ainsi l’efficacité personnelle et professionnelle.

1. Conception architecturale principale

4
EMP [Link]́néralités sur les systèmes de notification

Ntfy repose sur le modèle de messagerie publication-abonnement (pub/sub), un para-

digme bien établi dans l’informatique distribuée et les architectures événementielles. Ce
modèle offre un couplage lâche entre l’émetteur (publisher ) et le récepteur (subscriber ),
améliorant ainsi la scalabilité, la tolérance aux pannes et l’efficacité de la communica-
tion en temps réel. Pour assurer une communication fluide et une livraison efficace des
messages, l’architecture de Ntfy est divisée en trois composants clés :
— Publisher (émetteur de messages) : Toute entité capable d’effectuer une requête
HTTP —telle que des scripts système, des applications, des capteurs IoT ou des pi-
pelines DevOps—peut agir en tant que publisher. L’émission d’un message s’effectue
via une requête POST envoyée au serveur Ntfy avec un sujet spécifié. L’authenti-
fication n’est pas requise, sauf si elle est explicitement activée via des jetons API,
l’authentification basique ou des jetons Bearer.
— Serveur Ntfy (message broker) : Composant central chargé de traiter et d’achemi-
ner les messages vers les abonnés. Il peut être auto-hébergé ou utilisé via l’instance
publique ([Link]). Il prend en charge la persistance des messages, garantissant ainsi
la réception par les abonnés hors ligne dès leur reconnexion, et propose des méca-
nismes de chiffrement facultatifs tels que le chiffrement de bout en bout et TLS pour
sécuriser les données transmises.
— Subscriber (récepteur de messages) : Un client qui écoute les messages sur un
sujet spécifique et reçoit les notifications en temps réel. Ce client peut être une
application Android, un client web, un outil CLI ou même un appareil IoT, et
supporte divers mécanismes de communication tels que le polling, les WebSockets
ou les abonnements MQTT.
Cette architecture permet de concevoir un système de notification scalable et performant,
où la transmission des messages ne nécessite pas de connexions persistantes, réduisant
ainsi la charge réseau et améliorant l’efficacité globale du système.
2. Protocoles de communication et transport des messages
Pour garantir une transmission rapide et fiable des messages, Ntfy implémente plusieurs
protocoles de communication :

— HTTP(S) API :
La méthode la plus simple et la plus largement supportée pour publier des messages
consiste à envoyer une requête POST contenant une charge utile, qui peut inclure
du texte, du JSON ou des métadonnées.

5
EMP [Link]́néralités sur les systèmes de notification

— WebSockets (diffusion d’événements en temps réel) :

En maintenant une connexion active entre le serveur et l’abonné, ce protocole as-
sure une livraison instantanée des messages sans nécessiter de requêtes de polling
constantes, réduisant ainsi considérablement l’utilisation de la bande passante. Cette
approche est idéale pour les clients basés sur navigateur, les tableaux de bord et
autres applications nécessitant une communication à faible latence et haute effica-
cité.

— MQTT :
Ce protocole de messagerie pub/sub léger est optimisé pour les appareils IoT à
faible bande passante et est largement utilisé dans les environnements domotiques,
l’automatisation industrielle et les systèmes de télémétrie. Il permet une intégration
transparente avec des plateformes comme Home Assistant, OpenHAB et d’autres
écosystèmes IoT.

En prenant en charge plusieurs mécanismes de communication, Ntfy garantit que les

notifications sont efficacement livrées quel que soit l’environnement réseau, les capacités
des appareils et les exigences des applications.
3. Stratégies de déploiement

— Serveur public : Une version hébergée de Ntfy ([Link]) qui permet aux utilisateurs
d’envoyer et de recevoir des messages sans nécessiter la mise en place d’une infra-
structure propre. Elle constitue une solution rapide et pratique, adaptée aux usages
personnels et aux petites applications.

— Auto-hébergement (recommandé pour la sécurité et la conformité) : Permet aux

organisations et aux particuliers de conserver un contrôle total sur leur infrastructure
de notification.

I.2.3 Gotify

Gotify est un serveur de notifications push open-source conçu pour les utilisateurs
souhaitant un contrôle total sur leur infrastructure de notification sans dépendre de ser-
vices tiers. Contrairement aux alternatives basées sur le cloud telles que Firebase Cloud
Messaging (FCM) et Apple Push Notification Service (APNS), Gotify est entièrement
auto-hébergé, garantissant la confidentialité des données, la sécurité et la conformité avec
les politiques organisationnelles et les réglementations en vigueur. Il offre un mécanisme

6
EMP [Link]́néralités sur les systèmes de notification

léger mais efficace pour les notifications en temps réel, ce qui le rend idéal pour les pi-
pelines DevOps, la surveillance des systèmes, les applications IoT et l’amélioration de la
productivité personnelle.
Principes de conception et objectifs
Gotify a été développé avec un fort accent sur la simplicité, la faible consommation de
ressources et la facilité d’intégration. Les principaux objectifs du système sont les suivants :

— Auto-hébergement et confidentialité des données : Tous les messages et configu-

rations restent sous le contrôle de l’utilisateur, garantissant une totale maı̂trise des
données de notification.

— Léger et efficace : Développé en Go, Gotify est optimisé pour une utilisation mini-
male de la mémoire et du processeur, ce qui le rend adapté aussi bien aux serveurs
haute performance qu’aux appareils à ressources limitées.

— Flexibilité et extensibilité : Il prend en charge plusieurs mécanismes de communi-

cation et permet une intégration facile dans divers environnements logiciels grâce
aux RESTful APIs et aux WebSockets.

— Configuration minimale et facilité de déploiement : Gotify peut être mis en place

rapidement à l’aide d’un binaire autonome ou d’un déploiement conteneurisé, ce qui
le rend accessible aux développeurs et aux administrateurs système.

Vue d’ensemble architecturale

Gotify adopte une architecture faiblement couplée basée sur le modèle de publication-
abonnement (pub/sub), permettant aux applications et aux utilisateurs d’envoyer et de
recevoir des notifications de manière asynchrone. Ce modèle améliore l’évolutivité et l’effi-
cacité en découplant le producteur du consommateur de messages. Le système est structuré
autour de trois composants principaux :

— Émetteur de message (Message Publisher ) : Toute application, script ou système

capable d’effectuer des requêtes HTTP peut agir en tant qu’émetteur, envoyant des
notifications au serveur Gotify. Les émetteurs s’authentifient via des jetons API
tokens et transmettent les messages via des requêtes HTTP POST.

— Serveur Gotify : Composant central du système, il est responsable de la réception,

du traitement, du stockage et de la transmission des messages. Il prend en charge
l’authentification des utilisateurs, la catégorisation des messages et la gestion des
notifications basées sur les priorités.

7
EMP [Link]́néralités sur les systèmes de notification

— Abonné aux messages (Message Subscriber ) : Des clients tels que des navigateurs
web, des applications mobiles ou des outils CLI s’abonnent à des flux de messages
spécifiques et reçoivent des notifications push en temps réel via des WebSockets ou
des requêtes API périodiques.

Cette architecture élimine le besoin de connexions persistantes, réduisant ainsi la sur-

charge réseau et améliorant l’efficacité globale du système.
Protocoles de communication et transport des messages
Gotify implémente plusieurs protocoles de communication pour garantir une transmis-
sion de messages fiable et flexible dans des environnements variés :

— RESTful HTTP API : Méthode principale de publication des messages, permet-

tant aux applications d’envoyer des notifications via des requêtes HTTP structurées.
Les messages peuvent inclure du texte, des niveaux de priorité et des pièces jointes
optionnelles.

— WebSockets pour les mises à jour en temps réel : Les clients peuvent établir une
connexion WebSocket avec le serveur Gotify afin de recevoir instantanément des
notifications sans avoir besoin d’un sondage constant.

— Sondage via API : Pour les clients ne prenant pas en charge les WebSockets, Go-
tify propose des points d’accès API permettant de récupérer périodiquement les
messages stockés.

Grâce à ces mécanismes de transport, Gotify garantit une livraison efficace des notifi-
cations, indépendamment des contraintes réseau ou des capacités des clients.
Fonctionnalités de sécurité et mécanismes d’authentification
La sécurité est un aspect fondamental de la conception de Gotify, garantissant que
les notifications restent protégées contre tout accès non autorisé. La plateforme intègre
plusieurs fonctionnalités de sécurité :

— Authentification basée sur des jetons API : Les émetteurs et les abonnés s’authen-
tifient à l’aide de jetons API, garantissant que seules les entités autorisées peuvent
envoyer ou recevoir des messages.

— Contrôle d’accès basé sur les rôles (RBAC ) : Gotify prend en charge plusieurs
utilisateurs avec des autorisations distinctes, permettant aux administrateurs de
définir des niveaux d’accès pour différentes applications.

— Chiffrement et transport sécurisé : La communication avec le serveur Gotify peut

8
EMP [Link]́néralités sur les systèmes de notification

être sécurisée via HTTPS et TLS, empêchant les attaques de type écoute clandestine
et man-in-the-middle.

Ces mécanismes fournissent un modèle de sécurité robuste, faisant de Gotify un choix

fiable pour les applications sensibles.
Stratégies de déploiement et évolutivité
Gotify peut être déployé de différentes manières en fonction des besoins opérationnels :

— Binaire autonome (Standalone Binary ) : Une méthode de déploiement simple

où le serveur Gotify fonctionne comme un fichier exécutable unique, idéal pour un
usage personnel et des installations légères.

— Déploiement basé sur Docker : Gotify propose une image Docker officielle, permet-
tant des déploiements rapides et évolutifs dans des environnements conteneurisés.

— Intégration avec un proxy inverse : Il peut être combiné avec Nginx, Apache ou
Traefik pour la terminaison SSL, l’équilibrage de charge et la gestion des accès.

Le système est conçu pour gérer efficacement un volume modéré de messages, ce qui le
rend adapté aux déploiements de petite et moyenne échelle.
Cas d’utilisation et applications
La polyvalence de Gotify lui permet d’être appliqué dans divers domaines, notamment :

— Surveillance des infrastructures et des serveurs

— CI/CD et intégration continue

— IoT et domotique

— Gestion des tâches et productivité personnelle

I.2.4 Slack

Slack est une plateforme de collaboration et de messagerie basée sur le cloud qui fournit
une communication en temps réel, le partage de fichiers et l’intégration avec des services
tiers. Elle est largement utilisée dans les environnements d’entreprise, les équipes de dé-
veloppement et les configurations de travail à distance pour optimiser la communication
interne et l’automatisation des flux de travail. Contrairement aux systèmes de notifica-
tion auto-hébergés tels que Gotify, Slack fonctionne comme un service géré, offrant une
infrastructure évolutive avec de vastes capacités d’intégration.
Principales fonctionnalités et philosophie de conception

9
EMP [Link]́néralités sur les systèmes de notification

Slack est conçu pour améliorer la collaboration en équipe grâce à des canaux de commu-
nication structurés et des fonctionnalités d’automatisation. Ses principes fondamentaux
incluent :

— Communication basée sur les canaux : Les messages sont organisés en canaux, qui
peuvent être publics, privés ou des messages directs, permettant des discussions
structurées et contextualisées.

— Intégrations étendues : Slack prend en charge l’intégration avec de nombreuses

applications tierces, y compris des outils CI/CD, des systèmes de surveillance et des
services cloud.

— Disponibilité multiplateforme : Accessible via le web, les applications de bureau et

mobiles, garantissant une communication fluide sur tous les appareils.

— Personnalisation des notifications : Les utilisateurs peuvent adapter les notifications

en fonction de la priorité, des mots-clés et des types de messages, réduisant ainsi la
surcharge d’informations.

— Sécurité et conformité : Fournit des fonctionnalités de sécurité de niveau entreprise,

notamment le chiffrement, l’authentification unique (SSO) et des certifications de
conformité telles que SOC 2 et ISO 27001.

Vue d’ensemble architecturale

Slack repose sur une architecture basée sur le cloud et orientée événements, conçue
pour être évolutive et fiable. La plateforme comprend les composants suivants :

— Slack API : Permet un accès programmatique aux fonctionnalités de messagerie

et de notifications de Slack, prenant en charge à la fois les mécanismes de push et
de pull.

— WebSockets pilotés par événements : Assure la livraison des messages en temps

réel avec une faible latence en maintenant des connexions WebSocket persistantes.

— Files d’attente et traitement des messages : Slack utilise des systèmes de traitement
distribué des messages pour gérer efficacement un volume élevé de communications.

— Stockage et indexation des données : Les messages et fichiers partagés sont stockés
de manière sécurisée avec une indexation consultable, permettant une récupération
et une référence aisées.

Mécanismes de communication et livraison des notifications

10
EMP [Link]́néralités sur les systèmes de notification

Slack propose plusieurs mécanismes de communication pour faciliter la messagerie en

temps réel et asynchrone :

— Messagerie en temps réel via WebSockets : Assure des mises à jour instantanées
des messages sur les clients connectés.

— Web API basée sur HTTP : Permet aux applications d’envoyer et de récupérer
des messages de manière programmatique.

— Incoming Webhooks : Permet aux services externes d’envoyer des notifications

vers des canaux spécifiques de Slack.

— Commandes Slash et interactions avec des bots : Offre une communication interac-
tive via des automatisations basées sur des bots et des déclencheurs par commandes.

Sécurité et authentification
Slack intègre des fonctionnalités de sécurité avancées pour garantir une communication
sécurisée et la protection des données :

— Authentification via OAuth 2.0 : Assure un contrôle d’accès sécurisé pour les
applications et intégrations tierces.

— Chiffrement de bout en bout des données en transit : Protège les messages et

fichiers avec un chiffrement TLS.

— Contrôles d’accès granulaires : Permet aux administrateurs de configurer des auto-

risations basées sur les rôles.

— Conformité aux normes d’entreprise : Prend en charge les politiques de rétention

des données, les journaux d’audit et la conformité réglementaire.

Cas d’utilisation et applications

L’architecture polyvalente de Slack le rend adapté à une large gamme d’applications :

— Communication en entreprise et en équipe : Facilite la collaboration en temps réel

dans les organisations de toutes tailles.

— Gestion des incidents et surveillance : S’intègre aux outils de surveillance pour

notifier les équipes des événements critiques du système.

— CI/CD et pipelines DevOps : Fournit des notifications automatisées sur les builds
et les déploiements pour les équipes de développement logiciel.

— Automatisation des flux de travail : Permet l’automatisation des processus grâce

aux bots Slack et aux intégrations avec des outils de gestion des tâches.

11
EMP [Link]́néralités sur les systèmes de notification

I.2.5 Rpush

Rpush est un service de notifications push open-source pour les applications Ruby,
offrant une solution flexible et évolutive pour envoyer des notifications vers plusieurs pla-
teformes, y compris Apple Push Notification Service (APNS ), Firebase Cloud Messaging
(FCM ) et d’autres services tiers. Contrairement aux services de notifications gérés, Rpush
permet un contrôle total de l’infrastructure de messagerie, ce qui le rend adapté aux ap-
plications nécessitant confidentialité, personnalisation et intégration directe avec une base
de données.
Principales fonctionnalités et philosophie de conception
Rpush est conçu pour s’intégrer de manière transparente avec Ruby on Rails et d’autres
applications basées sur Ruby, offrant :

— Prise en charge multiplateforme : Permet l’envoi de notifications push vers iOS

(APNS ), Android (FCM/GCM ) et les appareils Windows.
— Traitement asynchrone : Utilise des tâches en arrière-plan pour gérer efficacement
de grands volumes de notifications.
— Persistance en base de données : Stocke les notifications dans une base de données,
garantissant une livraison fiable et un suivi des messages.
— Évolutivité et performance : Prend en charge l’exécution multi-threads et multi-
processus pour gérer des charges de travail à haut débit.
— Personnalisation et extensibilité : Permet aux développeurs de définir des flux de no-
tifications personnalisés et d’intégrer des mécanismes de livraison supplémentaires.

Vue d’ensemble architecturale

Rpush suit une architecture orientée événements et basée sur des files d’attente, ce qui
améliore sa fiabilité et son efficacité. Le système est composé des éléments suivants :

— Files d’attente de messages : Les notifications sont mises en file d’attente et traitées
de manière asynchrone pour éviter les goulots d’étranglement dans l’application.
— Stockage persistant : Utilise ActiveRecord ou d’autres bases de données basées sur
ORM pour stocker les notifications et permettre le suivi et les mécanismes de relance.
— Travailleurs de livraison : Des processus en arrière-plan récupèrent les notifications
en file d’attente et les envoient aux services push correspondants.
— Mécanisme de retour d’information : Reçoit des retours d’APNS/FCM concer-
nant les jetons d’appareils invalides ou expirés, optimisant ainsi la distribution des

12
EMP [Link]́néralités sur les systèmes de notification

messages.

Mécanismes de communication et livraison des notifications

Rpush utilise divers protocoles de communication pour assurer une distribution fiable
des notifications push :

— APNS (Apple Push Notification Service) : Utilise HTTP/2 et des connexions

persistantes pour envoyer des notifications aux appareils iOS.

— FCM (Firebase Cloud Messaging ) : Prend en charge la messagerie basée sur

JSON pour les applications Android et web.

— GCM (Legacy Google Cloud Messaging ) : Compatible avec les anciens appa-
reils Android utilisant encore GCM.

— Adaptateurs personnalisés : Permet l’intégration avec d’autres services de notifica-

tions tiers en étendant les fonctionnalités de Rpush.

Sécurité et authentification
Rpush intègre des mesures de sécurité avancées pour garantir l’intégrité des notifications
envoyées :

— Chiffrement TLS : Assure une communication sécurisée avec les serveurs APNS et
FCM.

— Authentification par certificat : Utilise des certificats APNS délivrés par Apple
pour la messagerie iOS.

— OAuth 2.0 pour FCM : Requiert des clés API et des jetons d’authentification
pour l’envoi de notifications.

— Gestion de la révocation des jetons : Supprime automatiquement les jetons d’ap-

pareils invalides en fonction des retours d’APNS et FCM.

Cas d’utilisation et applications

Rpush est largement utilisé dans les scénarios nécessitant des notifications push en
temps réel et à fort volume :

— Notifications d’applications mobiles : Envoie des alertes et des mises à jour aux
utilisateurs sur les appareils iOS et Android.

— E-commerce et campagnes marketing : Prend en charge les notifications transac-

tionnelles, les messages promotionnels et les campagnes d’engagement des utilisa-
teurs.

13
EMP [Link]́néralités sur les systèmes de notification

— Surveillance système et alertes : Notifie les administrateurs des événements sys-

tème, des pannes ou des problèmes de sécurité.

— Applications sociales et de messagerie : Fournit des notifications de chat en temps

réel et des mises à jour d’activité.

Stratégies de déploiement
Rpush peut être déployé dans différentes configurations en fonction des besoins d’évo-
lutivité et d’infrastructure :

— Mode autonome : Fonctionne comme une tâche en arrière-plan au sein d’une appli-
cation Ruby.

— Déploiement en cluster : Utilise plusieurs processus travailleurs pour les environne-

ments à haut débit.

— Configuration Dockerisée : Permet un déploiement conteneurisé pour les applica-

tions cloud-native.

— Intégration avec Sidekiq ou Resque : Améliore les capacités de traitement des

tâches en arrière-plan pour une efficacité accrue.

I.2.6 Iris Server

Iris Server est un serveur de notification open-source avancé conçu pour la messagerie
et l’alerte haute performance. Il est conçu pour gérer des charges de travail de notifications
en temps réel et à grande échelle, ce qui en fait un choix privilégié pour les applications
d’entreprise, les systèmes de surveillance et les architectures pilotées par les événements.
En prenant en charge plusieurs protocoles de communication et en garantissant des me-
sures de sécurité robustes, Iris Server fournit une infrastructure de notification évolutive
et fiable.
Principales fonctionnalités et philosophie de conception
Iris Server est conçu pour offrir un système de notification flexible, modulaire et efficace
avec les caractéristiques clés suivantes :

— Messagerie multi-canaux : Prend en charge les emails, les SMS, les notifications
push et la messagerie en temps réel via WebSockets et MQTT.

— Architecture pilotée par les événements : S’intègre avec des sources d’événements
telles que les outils de surveillance, les journaux d’application et les infrastructures
cloud.

14
EMP [Link]́néralités sur les systèmes de notification

— Haute disponibilité et scalabilité : Conçu pour des déploiements distribués afin

d’assurer la tolérance aux pannes et l’équilibrage de charge.
— Système de plugins extensible : Permet l’ajout de gestionnaires de notifications
personnalisés et de logiques de routage des messages.
— Communication sécurisée : Implémente le chiffrement TLS, des mécanismes d’au-
thentification et un contrôle d’accès basé sur les rôles (RBAC ).

Vue d’ensemble architecturale

Iris Server est structuré autour d’un design modulaire et distribué, composé des élé-
ments suivants :

— Producteurs de messages : Applications, systèmes de surveillance et services ex-

ternes générant des notifications.
— Iris Server Core : Composant central responsable du traitement, de la mise en
file d’attente et de la distribution des messages.
— Stockage back-end : Une base de données ou un système de files de messages (ex. :
PostgreSQL, Redis, Kafka) pour stocker les notifications.
— Mécanismes de distribution : Modules configurables gérant l’acheminement des mes-
sages vers divers canaux de communication.

Protocoles de communication et transport des messages

Iris Server utilise divers protocoles pour assurer une distribution fiable et efficace des
messages :

— HTTP(S) API : Fournit des points de terminaison RESTful pour l’envoi et la

récupération des notifications.
— WebSockets : Permet l’envoi de messages push en temps réel avec une latence
minimale.
— MQTT : Facilite la messagerie légère pour les applications IoT et mobiles.
— SMTP et passerelles SMS : Prend en charge les notifications par email et SMS
via des fournisseurs tiers configurables.
— Files de messages : Utilise Kafka, RabbitMQ ou Redis pour le traitement asynchrone
des messages.

Sécurité et authentification
Iris Server intègre plusieurs couches de sécurité pour protéger la communication et
garantir l’intégrité des données :

15
EMP [Link]́néralités sur les systèmes de notification

— Chiffrement TLS : Assure une transmission sécurisée des messages.

— Authentification par clé API : Contrôle l’accès aux points de terminaison API.

— OAuth 2.0 et JWT : Prend en charge l’authentification basée sur des jetons pour
les intégrations externes.

— Contrôle d’accès basé sur les rôles (RBAC ) : Restreint l’accès en fonction des
rôles et des permissions des utilisateurs.

Cas d’utilisation et applications

Iris Server est utilisé dans une large gamme d’industries et d’applications :

— Surveillance de l’infrastructure informatique : Envoie des alertes pour les pannes

système, les problèmes de performance et les incidents de sécurité.

— DevOps et pipelines CI/CD : Notifie les équipes sur l’état des déploiements, les
échecs de compilation et les résultats des tests.

— Systèmes de réponse aux incidents : Facilite la communication en temps réel dans

les scénarios de gestion d’urgence.

— Engagement client : Prend en charge les notifications push personnalisées pour le

marketing et la messagerie transactionnelle.

Stratégies de déploiement
Iris Server peut être déployé selon différentes approches en fonction des besoins en
infrastructure :

— Déploiement autonome : Fonctionne comme un service single-node pour les appli-

cations à petite échelle.

— Déploiement en cluster : Utilise plusieurs instances avec équilibrage de charge pour

assurer une haute disponibilité.

— Déploiement conteneurisé : Fournit des images Docker pour un déploiement fluide

sur le cloud et en local.

— Intégration serverless : Peut être intégré avec AWS Lambda, Google Cloud Func-
tions ou Azure Functions pour une exécution pilotée par les événements.

I.2.7 Pushover for Desktop

Pushover for Desktop est un système de notification optimisé et efficace, conçu pour
les utilisateurs nécessitant des alertes en temps réel sur leur ordinateur. Il offre un moyen

16
EMP [Link]́néralités sur les systèmes de notification

simple mais puissant de recevoir des notifications provenant de diverses applications, ser-
vices et flux d’automatisation directement sur les environnements de bureau. L’application
de bureau Pushover étend les fonctionnalités de sa version mobile tout en garantissant
une compatibilité multiplateforme fluide et une livraison fiable des messages.
Principales fonctionnalités et philosophie de conception
Pushover for Desktop est conçu pour offrir une expérience de notification légère et
hautement réactive avec les caractéristiques clés suivantes :

— Notifications push instantanées : Livre les messages en temps réel aux utilisateurs
de bureau, garantissant des mises à jour et alertes opportunes.
— Support multiplateforme : Disponible sur Windows, macOS et Linux via une inter-
face web et des intégrations natives.
— Intégration avec des services tiers : Fonctionne de manière fluide avec des outils
d’automatisation comme IFTTT, Zapier et des plateformes de surveillance telles
que Nagios et Prometheus.
— Priorisation et personnalisation des messages : Prend en charge les notifications
normales, prioritaires et d’urgence, permettant aux utilisateurs de gérer efficacement
les niveaux d’alerte.
— Communication sécurisée et fiable : Utilise le chiffrement TLS pour la transmission
des données et un système de mise en file d’attente basé sur le cloud pour garantir
une livraison fiable.

Vue d’ensemble architecturale

Pushover for Desktop suit un modèle de notification push basé sur le cloud, composé
des éléments suivants :

— Sources de messages : Applications, scripts ou systèmes de surveillance qui génèrent

et envoient des notifications via des requêtes API.
— Serveur cloud Pushover : Composant central qui traite, met en file d’attente et
achemine les notifications vers les clients de bureau enregistrés.
— Application cliente de bureau : Une application web ou native qui écoute et affiche
les notifications entrantes en temps réel.

Protocoles de communication et transport des messages

Pushover for Desktop prend en charge plusieurs mécanismes de communication pour
garantir une livraison robuste des messages :

17
EMP [Link]́néralités sur les systèmes de notification

— REST API : Permet aux applications d’envoyer des notifications via des requêtes
HTTP(S) POST avec des charges utiles structurées.
— WebSockets : Fournit une connexion persistante pour la livraison instantanée des
messages push aux clients de bureau.
— Passerelle Email-to-Push : Convertit les emails en notifications push pour les
utilisateurs souhaitant recevoir des alertes basées sur les emails.

Sécurité et authentification
Pour garantir la confidentialité et la sécurité des données, Pushover for Desktop implé-
mente les mesures suivantes :

— Chiffrement TLS : Protège la communication entre les clients et le serveur cloud.

— Authentification utilisateur : Nécessite des jetons API pour la soumission des mes-
sages et des identifiants de connexion pour le contrôle d’accès.
— Enregistrement et gestion des appareils : Les utilisateurs peuvent gérer et autoriser
les appareils de bureau enregistrés depuis leur compte Pushover.

Cas d’utilisation et applications

Pushover for Desktop est largement utilisé dans divers domaines, notamment :

— Surveillance de l’infrastructure informatique : Fournit des alertes en temps réel sur

l’état des serveurs, les menaces de sécurité et les pannes système.
— Automatisation des processus métier et notifications de flux de travail : Améliore
la productivité en envoyant des notifications sur l’achèvement des tâches, les mises
à jour de statut et les déclenchements d’automatisation.
— Réponse aux incidents et alertes critiques : Assure une prise de conscience rapide
des événements critiques dans les domaines du DevOps, de la cybersécurité et de la
gestion des urgences.

Stratégies de déploiement
Pushover for Desktop peut être déployé de plusieurs manières pour répondre aux dif-
férents besoins des utilisateurs :

— Accès via le web : Aucune installation requise ; les utilisateurs peuvent recevoir des
notifications via le client web Pushover.
— Applications de bureau natives : Offrent des fonctionnalités supplémentaires telles
que les notifications dans la barre système et la mise en cache des messages hors
ligne.

18
EMP [Link]́néralités sur les systèmes de notification

— Intégration pilotée par API : Permet aux entreprises et aux développeurs d’intégrer
Pushover dans leurs applications pour une gestion fluide des notifications sur bureau.

I.3 Analyse comparative des systèmes de notification

Cette section présente une analyse comparative de divers systèmes de notification, en

évaluant leurs points forts, leurs faiblesses et leur applicabilité en fonction de plusieurs
critères techniques et opérationnels. L’objectif de cette analyse est d’apporter un éclairage
sur le système le plus adapté à différents cas d’usage.

I.3.1 Critères de comparaison

Pour assurer une comparaison structurée, les critères suivants sont utilisés :

— Architecture : Modèle centralisé ou décentralisé, y compris les mécanismes de trans-

port des messages.

— Protocoles de communication : Prise en charge des APIs HTTP, WebSockets,

MQTT ou autres protocoles de messagerie.

— Modèle de déploiement : Disponibilité des solutions auto-hébergées (self-hosted )

par rapport aux solutions basées sur le cloud.

— Fonctionnalités de sécurité : Mécanismes de chiffrement, authentification et confor-

mité aux réglementations.

— Intégration et extensibilité : Compatibilité avec des applications tierces et des outils

d’automatisation.

— Scalabilité et performance : Débit des messages, latence et capacité à gérer des

charges de trafic élevées.

— Adéquation aux cas d’usage : Adaptation aux usages personnels, aux environne-
ments d’entreprise, à l’IoT ou à l’automatisation DevOps.

I.3.2 Analyse comparative

Le tableau suivant fournit une vue d’ensemble des performances de chaque système de
notification selon ces critères.

19
 EMP [Link]́néralités sur les systèmes de notification

Système Architecture Protocoles Déploiement Sécurité Extensibilité Cas d’usage heightGotify

Auto-hébergé, Pub/Sub HTTP, WebSockets Auto-hébergé Authentification par jeton API Modérée Personnel, DevOps heightntfy Auto-hébergé, Pub/Sub
HTTP, MQTT, WebSockets Auto-hébergé/Public Chiffrement de bout en bout Élevée Surveillance système, IoT heightSlack Basé sur le cloud API HTTP, WebSockets
Cloud OAuth, chiffrement TLS Élevée Collaboration en entreprise heightRpush Auto-hébergé, Push-based APNS, FCM Auto-hébergé
Authentification par jeton Modérée Notifications mobiles push heightIris Server Distribué, Push-based HTTP, XMPP Auto-hébergé Authentification renforcée
Élevée Entreprise, systèmes à grande échelle heightPushover Basé sur le cloud API HTTP, WebSockets Cloud OAuth, TLS Élevée
Alertes IT, automatisation height

Table I.1 – Comparaison des systèmes de notification

I.3.3 Principaux résultats et discussion

Scalabilité et performance Les systèmes comme Iris Server et Slack offrent une haute
scalabilité grâce à leur architecture distribuée et à leur infrastructure de niveau entreprise.
En revanche, les solutions auto-hébergées comme Gotify et Rpush conviennent mieux aux
déploiements de plus petite envergure avec des besoins de messagerie modérés.
Sécurité et confidentialité Pour les organisations mettant la sécurité et la conformité
au premier plan, ntfy et Iris Server offrent des mécanismes de chiffrement et d’authenti-
fication avancés. Les solutions basées sur le cloud comme Slack et Pushover reposent sur
l’authentification OAuth et le chiffrement TLS, mais peuvent ne pas convenir aux envi-
ronnements hautement sensibles où la souveraineté des données est un critère critique.
Intégration et extensibilité Slack et Pushover offrent des intégrations poussées avec des
applications tierces, ce qui les rend idéaux pour l’automatisation des processus métier et
la collaboration en entreprise. Gotify et Rpush, bien qu’efficaces, offrent une extensibilité
plus limitée et nécessitent une personnalisation supplémentaire pour des flux de travail
avancés.
Adéquation aux cas d’usage
Usage personnel et petites équipes : Gotify et ntfy sont idéaux pour les particuliers
ou petites équipes cherchant une solution simple et auto-hébergée.
Communication et collaboration en entreprise : Slack excelle dans les environnements
de travail collaboratif avec des fonctionnalités de messagerie intégrées.
Notifications mobiles : Rpush est spécifiquement conçu pour les applications mobiles,
avec une intégration native aux services APNS et FCM.
Automatisation IoT et surveillance système : ntfy et Pushover conviennent parfaite-
ment aux flux d’automatisation et aux alertes d’infrastructure.
Déploiements à grande échelle : Iris Server est optimal pour les organisations ayant
des exigences de haute disponibilité et de messagerie distribuée.

20
EMP [Link]́néralités sur les systèmes de notification

I.4 Composants d’un Système de Notification

Un système de notification est composé de plusieurs composants clés qui fonctionnent

ensemble pour permettre la livraison de messages en temps réel, garantissant ainsi une
communication efficace et fiable. Les principaux composants d’un tel système incluent le
extitmessage broker, le notification server et le thick client. Chacun de ces éléments joue
un rôle distinct dans l’architecture globale, facilitant la transmission, le traitement et la
réception des messages. Cette section propose une analyse technique et académique appro-
fondie de ces composants, en décrivant leurs architectures, fonctionnalités et intégration
au sein des écosystèmes de notification.

I.4.1 Message Broker

Le message broker agit comme un intermédiaire entre les éditeurs et les abonnés de
messages, assurant un acheminement et une livraison efficaces des messages. Il fonctionne
selon les principes des modèles de messagerie publish-subscribe (pub/sub) ou point-to-point,
en fonction des exigences du système.
Architecture et Conception Un message broker adopte généralement une architecture
distribuée afin de garantir la tolérance aux pannes, l’évolutivité et une haute disponibilité.
Parmi les message brokers les plus couramment utilisés, on trouve RabbitMQ, Apache
Kafka et NATS. Ces brokers gèrent les files d’attente de messages et les topics, permettant
ainsi une communication asynchrone entre les composants distribués.

— Message Queuing : Les messages sont temporairement stockés dans des files d’at-
tente jusqu’à ce qu’ils soient traités ou consommés par les abonnés.

— Topic-based Routing : Dans un modèle pub/sub, les messages sont classés sous
des topics, permettant à plusieurs consommateurs de recevoir des mises à jour en
fonction de leur abonnement.

— Persistence et Durabilité : Selon la configuration, les brokers peuvent stocker les

messages sur disque afin d’assurer leur fiabilité en cas de défaillance du système.

— Répartition de Charge et Évolutivité : De nombreux brokers utilisent des techniques

de clustering pour répartir la charge de travail entre plusieurs nœuds.

Protocoles de Communication et Intégration Les message brokers prennent en charge

plusieurs protocoles de communication, notamment :

21
EMP [Link]́néralités sur les systèmes de notification

— AMQP (Advanced Message Queuing Protocol) : Utilisé par RabbitMQ pour une
messagerie robuste et de niveau entreprise.

— MQTT (Message Queuing Telemetry Transport) : Un protocole léger optimisé

pour les applications IoT et mobiles.

— Kafka Protocol : Approche unique d’ Apache Kafka pour le distributed event

streaming.

— REST et WebSockets : Pour l’interopérabilité avec les applications web mo-

dernes.

Fonctionnement d’un Message Broker Un message broker fonctionne selon les étapes
suivantes :

1. Un éditeur (par exemple, une application ou un événement système) envoie un mes-

sage vers un topic ou une file d’attente spécifique.

2. Le message broker reçoit et catégorise le message en fonction de règles prédéfinies.

3. Le broker distribue ensuite le message aux abonnés qui se sont inscrits à ce topic ou
à cette file d’attente.

4. Si un abonné est hors ligne, le broker peut persister le message jusqu’à ce que
l’abonné se reconnecte.

5. L’abonné récupère et traite le message en conséquence.

I.4.2 Notification Server

Le notification server agit comme l’unité centrale de traitement responsable de la ges-

tion des messages entrants, de l’application de la logique métier et de l’orchestration de
la livraison aux destinataires appropriés.
Fonctions et Responsabilités Principales Un notification server exécute les fonctions
critiques suivantes :

— Réception des Messages : Accepte les messages provenant de diverses sources telles
que les APIs, les événements système ou les actions des utilisateurs.

— Traitement et Filtrage : Applique des règles pour déterminer la pertinence des

messages pour différents utilisateurs ou groupes.

— Gestion des Files d’Attente : Travaille en collaboration avec le message broker pour
gérer la priorité, l’expiration et la relance des messages.

22
EMP [Link]́néralités sur les systèmes de notification

— Optimisation de la Livraison : Sélectionne la meilleure méthode de transport en

fonction des préférences de l’utilisateur, de la disponibilité des appareils et des condi-
tions du réseau.

Implémentation et Technologies Les notification servers peuvent être implémentés à

l’aide de différents frameworks et technologies, notamment :

— [Link] avec WebSockets : Adapté aux notifications à faible latence et basées

sur les événements.

— [Link] Core avec SignalR : Fournit des notifications en temps réel sur des
architectures évolutives.

— Java Spring Boot avec intégration Kafka : Utilisé pour les systèmes de mes-
sagerie d’entreprise.

I.4.3 Thick Client (Heavy Client)

Un thick client, également appelé heavy client, est une application logicielle installée
sur l’appareil d’un utilisateur qui interagit directement avec le notification server pour
recevoir et traiter les notifications.
Caractéristiques et Architecture Contrairement aux thin clients, qui reposent sur des
interfaces web, les thick clients possèdent des capacités de traitement intégrées, offrant
des avantages tels que :

— Support Hors Ligne : Peut mettre en file d’attente et stocker localement les messages
lorsque l’appareil est déconnecté.

— Interface Utilisateur Avancée : Offre une expérience plus riche et interactive par
rapport aux notifications basées sur le web.

— Faible Latence : Établit des connexions persistantes avec le notification server pour
une récupération rapide des messages.

— Authentification Sécurisée : Peut implémenter des mécanismes avancés de chiffre-

ment et d’authentification multi-facteurs.

Technologies et Plateformes Les thick clients sont développés en utilisant des techno-
logies spécifiques aux plateformes ou des technologies multiplateformes :

— Clients Desktop : Développés avec [Link], JavaFX ou WPF pour Windows et

macOS.

23
EMP [Link]́néralités sur les systèmes de notification

— Clients Mobiles : Construits avec Kotlin (Android), Swift (iOS) ou Flutter pour
une prise en charge multiplateforme.

— Appareils IoT : Utilisent des frameworks pour systèmes embarqués comme FreeR-
TOS et Zephyr RTOS pour les notifications push.

I.5 Solutions existantes pour chaque composant

I.5.1 Message Broker

Les message brokers jouent un rôle essentiel en facilitant la communication asynchrone

entre les composants distribués d’un système de notification. Ils garantissent une livraison
fiable des messages, une montée en charge efficace et un découplage des services. Diffé-
rents message brokers ont été développés pour répondre à divers cas d’usage, allant du
traitement d’événements à haut débit à la messagerie légère pour l’IoT.
RabbitMQ RabbitMQ est un message broker open-source implémentant le protocole
AMQP (Advanced Message Queuing Protocol ). Il prend en charge la mise en file d’attente
des messages, le modèle publish-subscribe et le routage avancé. RabbitMQ repose sur un
modèle de liaison exchange-queue, permettant un routage flexible des messages selon des
règles prédéfinies. Il est largement utilisé dans les applications d’entreprise nécessitant une
livraison fiable des messages et une prise en charge des transactions.
Apache Kafka Apache Kafka est une plateforme de diffusion d’événements distribuée,
conçue pour le traitement des messages à haut débit et tolérante aux pannes. Elle repose
sur une architecture basée sur un journal (log-based architecture), où les messages sont
stockés dans des partitions et consommés de manière séquentielle par les abonnés. Kafka
assure sa scalabilité grâce à un partitionnement horizontal et une réplication sur plusieurs
brokers.
NATS NATS est un système de messagerie léger et performant, conçu pour la com-
munication en temps réel. Il adopte une architecture décentralisée et prend en charge
les modèles de messagerie publish-subscribe et request-reply. NATS est particulièrement
adapté aux microservices et aux applications cloud-native.
ActiveMQ ActiveMQ est un message broker open-source prenant en charge plusieurs
protocoles de messagerie, notamment AMQP, MQTT et STOMP. Il offre des mécanismes
avancés de mise en file d’attente, de clustering et de basculement automatique pour garan-
tir une haute disponibilité et une fiabilité optimale dans les environnements d’entreprise.

24
EMP [Link]́néralités sur les systèmes de notification

I.5.2 Notification Server

Un notification server est chargé de recevoir les messages du message broker, de les
traiter et de déterminer la méthode de livraison appropriée. Il joue un rôle central dans
la gestion des préférences utilisateur, la priorisation des messages et l’assurance d’une
livraison en temps opportun via divers canaux.
Firebase Cloud Messaging (FCM) FCM est un service de notifications push basé sur
le cloud, proposé par Google. Il permet aux développeurs d’envoyer des messages aux
applications Android, iOS et web. FCM prend en charge la messagerie bidirectionnelle
(upstream et downstream) et s’intègre à d’autres services Google Cloud pour l’analyse
avancée et le ciblage des utilisateurs.
OneSignal OneSignal est une plateforme multi-supports permettant l’envoi de notifica-
tions push, de messages intégrés aux applications et d’e-mails. Elle offre des fonctionnalités
de segmentation, d’automatisation et de tests A/B pour optimiser la livraison des mes-
sages et l’engagement des utilisateurs.
Apache Pulsar Apache Pulsar est un système de messagerie distribué conçu pour les
environnements cloud-native. Il prend en charge la diffusion d’événements et le modèle
publish-subscribe, tout en offrant des fonctionnalités avancées telles que la multi-locataires,
la réplication géographique et le stockage hiérarchisé.
Airship (anciennement Urban Airship) Airship est une plateforme de distribution de
notifications offrant des capacités de messagerie en temps réel sur mobile, web, e-mail
et SMS. Elle propose des fonctionnalités avancées de personnalisation et d’analyse pour
améliorer l’engagement des utilisateurs.

I.5.3 Thick Client (Heavy Client)

Les thick clients sont des applications installées sur les appareils des utilisateurs qui
maintiennent une connexion persistante avec le notification server pour recevoir et traiter
les notifications. Ils offrent des fonctionnalités avancées telles que le stockage hors ligne
des messages, une interface utilisateur personnalisable et une récupération des messages
à faible latence.
Clients basés sur [Link] [Link] est un framework permettant de développer
des applications de bureau multiplateformes à l’aide des technologies web. Il permet de
créer des applications de notification avec une interface utilisateur avancée et une prise
en charge hors ligne.

25
EMP [Link]́néralités sur les systèmes de notification

Applications natives en Kotlin et Swift Les applications mobiles natives développées

avec Kotlin (Android) et Swift (iOS) offrent une gestion optimisée des notifications avec
une intégration profonde aux systèmes d’exploitation. Ces applications exploitent les APIs
spécifiques aux plateformes pour le traitement des messages en arrière-plan et la gestion
des notifications push.
Clients basés sur Flutter Flutter est un outil cross-platform permettant de développer
des applications avec prise en charge des notifications sur plusieurs plateformes, y compris
Android, iOS et bureau. Il prend en charge le traitement des messages en arrière-plan et
la personnalisation de l’interface des notifications.
Applications WPF (Windows Presentation Foundation) WPF est un framework
Microsoft permettant de concevoir des applications de bureau riches sur Windows. Les
clients basés sur WPF peuvent s’intégrer avec SignalR ou MQTT pour assurer une mes-
sagerie en temps réel, tout en offrant une interface utilisateur hautement personnalisable.

I.6 Analyse des Composants

Les trois composants principaux — le message broker, le serveur de notification et le

client lourd — doivent être sélectionnés avec soin en fonction des exigences du système.
Message Broker : Un message broker efficace doit garantir une communication asyn-
chrone fiable et évolutive. Parmi les solutions étudiées, RabbitMQ se distingue par son
implémentation du protocole AMQP, sa gestion avancée des files d’attente et son support
pour des modèles de routage flexibles. Contrairement à Kafka, optimisé pour le streaming
d’événements à grande échelle, RabbitMQ est mieux adapté aux systèmes transactionnels
nécessitant une livraison garantie et un contrôle granulaire des messages.
Serveur de Notification : Un serveur de notification doit être conçu pour rece-
voir, traiter et distribuer les messages tout en respectant des contraintes de performance
et de disponibilité. Bien que des solutions comme Firebase Cloud Messaging (FCM ) et
OneSignal offrent des services cloud performants, elles impliquent une dépendance à des
plateformes tierces et des limitations en matière de personnalisation. Développer un ser-
veur de notification en [Link] Core permet un contrôle total sur la logique métier,
l’intégration aux systèmes existants et l’optimisation des performances selon les besoins
spécifiques du projet.
Client Lourd : Le client lourd joue un rôle crucial dans la réception et l’affichage
des notifications, offrant une interface utilisateur avancée ainsi qu’un support hors ligne.

26
EMP [Link]́néralités sur les systèmes de notification

WPF/WPFUI a été retenu pour le développement du client, car il permet une person-
nalisation approfondie de l’interface utilisateur, une intégration native avec Windows et
une gestion efficace des threads pour garantir la réactivité de l’application.
Les choix technologiques adoptés reposent sur des critères techniques précis :

— RabbitMQ : Une solution éprouvée pour les systèmes transactionnels nécessitant

des garanties de livraison, un routage flexible et une forte compatibilité avec les
architectures basées sur des microservices.

— [Link] Core : Un framework robuste et performant pour développer un ser-

veur de notification évolutif, sécurisé et hautement personnalisable, sans dépendance
aux services cloud tiers.

— WPF/WPFUI : Une technologie adaptée aux applications desktop avancées, per-

mettant une expérience utilisateur riche et une gestion efficace des notifications en
temps réel.

I.7 Conclusion

L’analyse des systèmes de notification existants a mis en évidence les atouts et les
limites des solutions actuellement disponibles sur le marché. Bien que des plateformes
comme Firebase Cloud Messaging ou OneSignal offrent des services performants, leur
dépendance à des infrastructures tierces et leurs restrictions en matière de personnalisation
constituent des freins pour certaines applications critiques. De même, les choix de message
broker doivent être adaptés aux besoins spécifiques du système : RabbitMQ s’impose
comme une solution idéale pour les architectures nécessitant une livraison garantie et un
contrôle précis des messages, tandis que Kafka est plus adapté au streaming d’événements
à grande échelle.
L’étude des composants a permis d’établir des critères précis pour le choix des techno-
logies les plus adaptées à un système de notification performant. L’implémentation d’un
serveur de notification en [Link] Core garantit une personnalisation avancée et une
intégration fluide avec des systèmes existants. Pour le développement du client lourd,
WPF/WPFUI s’est révélé être un choix pertinent en raison de ses capacités avancées en
matière d’interface utilisateur et de gestion des notifications en temps réel.
Ainsi, l’architecture définie offre un équilibre optimal entre performance, évolutivité
et maı̂trise technologique. Les choix effectués permettent de construire un système de
notification robuste, adapté aux exigences des applications modernes nécessitant des in-

27
EMP [Link]́néralités sur les systèmes de notification

teractions en temps réel, tout en assurant un contrôle total sur la gestion et la distribution
des messages. Ce cadre théorique pose les bases du chapitre suivant, qui détaillera la mise
en œuvre technique de l’architecture retenue et son intégration au sein d’un environnement
applicatif concret.

28
Bibliographie

30