myFenyx

myFenyx est l’application interne des consultants de Fenyx Group, dans laquelle chacun déclare les actions qui lui valent des points, suit son portefeuille et le classement, puis échange ses points contre des cadeaux.

Rôle: Auteur de l’application mobile et auteur principal de l’API
Période: De janvier 2023 à aujourd’hui
État: En service. En service, publiée sur Google Play et sur l’App Store
Technologies: Django 3.2, Django REST Framework, Celery, PostgreSQL, Redis, Flutter, flutter_bloc
Dépôts: Deux

Figure 1. Architecture de myFenyx. Le trait interrompu désigne les notifications, qui partent du serveur vers les téléphones.

Cette étude complète l’article myFenyx : transformer un système RH manuel en vraie application, qui expose l’intention du projet. Elle s’en tient à l’architecture et à quelques choix techniques, les règles propres à l’entreprise n’ayant pas leur place ici.

Contexte

Le dispositif de récompenses de Fenyx Group était tenu à la main par les ressources humaines, et un consultant devait téléphoner pour connaître son solde. myFenyx l’a remplacé à partir de janvier 2023 par une application mobile et par une interface d’administration, depuis laquelle les ressources humaines lisent les déclarations, créditent les points et traitent les demandes d’échange. L’application s’est ensuite étendue aux actualités et aux événements du groupe, avec leurs notifications.

Problème

Une économie interne suppose des soldes exacts et un classement lisible sans délai, alors que les points sont attribués par année et consommés bien après avoir été gagnés. Il fallait par ailleurs qu’une demande d’échange ne retire rien à un consultant tant qu’elle n’a pas été validée, et que la connexion convienne à des agences qui ne disposent pas toutes du même annuaire.

Réponse apportée

Un portefeuille par année, un classement précalculé

Les crédits et les débits sont deux tables distinctes, dont chaque ligne porte son année, et le solde s’obtient par différence. Une troisième table conserve pour chaque consultant et chaque année ses points, ses dépenses, son solde et son rang ; elle est reconstruite lorsque l’administration modifie les données, et le point d’accès du classement ne lit qu’elle. L’application affiche ainsi le classement sans que le serveur ait à le calculer à la demande.

Écran d’accueil : le solde de points de l’année, les accès aux cagnottes et à l’échange, puis les actions qui rapportent des points — Figure 2. L’accueil d’un consultant puis son portefeuille, tenu par année, avec des données de démonstration.

Écran du portefeuille : un total, puis une ligne par année avec son solde — Figure 2. L’accueil d’un consultant puis son portefeuille, tenu par année, avec des données de démonstration.

Écran d’échange : la demande en cours avec son total de 600 points et un bouton Annuler, puis la liste des cadeaux avec leur prix en points — Figure 3. Une demande d’échange en cours, que le consultant peut encore annuler, au-dessus du catalogue des cadeaux, avec des données de démonstration.

Un échange en deux temps

La demande d’un consultant vérifie que son solde couvre son panier, mais ne débite rien, et elle reste annulable. Le débit n’intervient qu’au traitement par un administrateur, à l’intérieur d’une transaction, en puisant d’abord dans l’année la plus ancienne et en écrivant une ligne de dépense par année entamée. Cet ordre, premier entré, premier sorti, est celui que décrit l’article.

Une connexion décidée par le serveur

Chaque agence déclare les méthodes de connexion qu’elle accepte, à savoir l’annuaire Microsoft de l’entreprise ou un code à usage unique envoyé par courrier, et l’application enchaîne ses écrans en conséquence. Le parcours par code a été réécrit en juillet 2026 : le code est tiré au hasard, seule son empreinte est conservée, il ne sert qu’une fois, les tentatives sont comptées, et la réponse est identique que le compte existe ou non. La limitation de débit s’appuie sur Redis, afin de tenir quel que soit le processus qui reçoit la requête.

Des notifications conservées

Une notification est d’abord une ligne en base, créée pour chaque consultant concerné par un événement ou une actualité, et c’est son enregistrement qui déclenche l’envoi vers le téléphone. Elle porte un code de type et un identifiant, que l’application traduit en une destination. Le numéro de build de l’application est enfin dérivé du nombre de commits, puis reporté dans une étiquette git, de sorte qu’une version en magasin se rattache toujours à un état du dépôt.

Écran d’accueil faisant défiler une invitation à un événement avec ses réponses, puis une actualité illustrée — Figure 4. Les événements et les actualités du groupe, auxquels renvoient les notifications, avec des données de démonstration.

Limites et perspectives

Les tests ne couvrent que la connexion par code, soit six cas, et rien ne vérifie encore le portefeuille, l’ordre de débit ni le classement, qui sont pourtant le cœur de l’application. Le classement est par ailleurs reconstruit en entier et de façon synchrone à chaque modification, ce qui convient à l’effectif actuel et devra passer en tâche de fond s’il augmente.

Un canal WebSocket a été préparé côté serveur sans être mis en service, l’application se rafraîchissant à la réception d’une notification. Les pipelines d’intégration ne sont pas branchés et les livraisons partent encore de mon poste. L’API reste enfin sur Django 3.2, dont la montée de version est à prévoir, et l’historique du schéma n’est pas versionné, ce qu’il conviendra de corriger en premier.

Retour aux réalisations