Dans cet article, je vous montre un exemple typique que l'on peut rencontrer lors d'une analyse de projet. Le sujet que j'ai choisi concerne un module de messagerie Intranet pour une plateforme commerciale.

Le besoin

Le management central doit pouvoir envoyer des newsletters aux différents shops dans le but de les informer concernant les procédures internes, les congés, les offres d'emploi,...

Issue 1 : Afficher le nombre de nouveaux messages

Issue 2 : Afficher la liste des messages et mettre en évidence ceux qui n'ont pas encore été lus

Le contexte

Un gérant et un employé est lié à un shop à l'exception de certains profils tels que les administrateurs, les sales,...

Durant la définition du besoin, le client a expliqué qu'il n'était pas nécessaire d'afficher les statuts de messages (lu ou non-lus) par utilisateur, que cela pouvait être lié au shop général. En d'autres mots, le premier utilisateur du shop qui se connectera sur la plateforme et cliquera sur un message non-lu mettra automatiquement le statut du message à "lu".

L'équipe de développement a donc construit ce database model : 

Les contraintes

Avec ce type de schéma, nous avons 2 problèmes :

Problème n°1 : les autres utilisateurs qui sont associés au même shop verront un message déjà lu

Lorsque l'employé A du shop 001 lit le message, le statut de ce message sera "lu". Jusqu'ici tout va bien !

Et maintenant? Que se passe t-il si l'employé B,C,D ou même le gérant de ce même shop se connecte sur la messagerie?

L'employé B,C,D et le gérant du shop 001 aura un statut "lu" au lieu d'un statut "non-lu" pour ce message et le nombre de nouveaux messages dans la barre du haut sera de 0. Ce simple détail peut être confus pour l'utilisateur car il peut croire qu'il a déjà lu le message et ainsi passer à côté d'une information importante.

Problème n°2 : les utilisateurs qui ne sont pas liés à un shop ne pourront pas voir si un message a déjà été lu ou non-lu

Pour rappel : seul les employés et gérants sont liés à un shop. Alors comment les autres types d'utilisateurs (qui ne sont pas liés à un shop mais qui ont pourtant accès à la messagerie) peuvent distinguer les éléments lus et non-lus ?

Solution

Avec ce simple changement, nous avons résolu 2 problèmes en même temps.

N'importe utilisateur peut voir le statut de ses messages (lus ou non-lus) et ainsi avoir le bon chiffre au niveau du compteur des nouveaux messages en haut de l'écran.

Conclusion

Lorsque le client demande quelque chose, il faut être prudent et vérifier les différents scénarios. Avant de se lancer dans un schéma, vous devez penser plus loin que la demande et anticiper les impacts futurs.