GSB
Gestion des rapports de visites — laboratoire pharmaceutique
Le contexte
GSB (Galaxy Swiss Bourdin) est un laboratoire pharmaceutique fictif qui s'appuie sur des visiteurs médicaux pour promouvoir ses produits auprès des praticiens (médecins généralistes, spécialistes, services hospitaliers, infirmiers, pharmaciens).
Comme la publicité grand public sur les médicaments remboursés est interdite, ces visites sur le terrain sont au cœur de l'activité commerciale. Chaque visiteur dispose d'un portefeuille de praticiens attribué — pas de chevauchement, un médecin n'est jamais visité deux fois par le même labo.
L'objectif du projet : fournir aux visiteurs une application mobile qui centralise leurs comptes-rendus, leur donne accès aux coordonnées des praticiens et offre une vision synthétique de leur activité.
Architecture
Le projet se découpe en deux briques distinctes qui communiquent en HTTP :
API REST
Point d'entrée unique pour la donnée métier.
- TypeScript côté serveur
- MongoDB comme base de données
- Authentification du visiteur
- Endpoints : visiteurs, praticiens
Application Android
Interface utilisée par le visiteur sur le terrain.
- Java + projet Gradle
- Retrofit pour les appels HTTP
- Écran de login
- Affichage du portefeuille
Le découpage API / mobile permet de respecter une contrainte du cahier des charges : l'indépendance vis-à-vis du SGBD. L'app Android ne sait rien de MongoDB, elle parle uniquement à l'API.
Périmètre actuel
Le projet est en cours de développement. État d'avancement :
- Authentification du visiteur FAIT
- Modélisation des entités
visiteursetpraticiensen MongoDB FAIT - Endpoints API pour la consultation du portefeuille FAIT
- Écran Android de login FAIT
- Écran Android d'affichage du portefeuille FAIT
- Saisie et historique des rapports de visite À VENIR
- Mode hors-ligne et synchronisation différée À VENIR
- Modules Délégué et Responsable (statistiques, vision d'équipe) À VENIR
Cahier des charges — points clés
Hiérarchie commerciale
L'organisation suit une structure géographique : Visiteur → Délégué régional → Responsable de secteur. Le délégué régional est un visiteur à part entière qui consacre un quart de son temps à l'organisation et garde un accès aux rapports de ses collègues.
Trois modules selon le profil
- Module Visiteur (priorité, en cours) — saisie des comptes-rendus, consultation des données sur 3 ans, statistiques d'activité personnelle
- Module Délégué — vision de l'activité des visiteurs rattachés à une région, en plus de ses propres comptes-rendus
- Module Responsable — vision globale d'un secteur sous forme de statistiques et de graphiques
Contraintes techniques
- Application Android (les visiteurs sont équipés et habitués)
- Architecture orientée objet
- Indépendance vis-à-vis du SGBD
- Mode hors-ligne avec synchronisation au retour de connexion
- Authentification sécurisée des utilisateurs
Stack technique
- API : TypeScript, MongoDB
- Mobile : Android (Java), projet Gradle
- Communication : Retrofit (client HTTP typé) sur API REST
- Outils : Android Studio, MongoDB Compass
Ce que j'en retiens jusqu'ici
Premier projet où je conçois les deux côtés du fil : définir un contrat d'API côté serveur et le consommer côté Android force à penser le découpage des responsabilités proprement.
Le passage par Retrofit a été formateur : les interfaces Java déclaratives mappent directement les endpoints, ce qui rend le code Android beaucoup plus lisible qu'un appel HTTP brut.
La suite du projet (mode hors-ligne) sera l'occasion de creuser la persistance locale Android et les stratégies de synchronisation — un vrai sujet métier puisque les visiteurs travaillent souvent dans des cabinets sans connexion.