Abdelkader Bennat

1. Rôle exact sur le projet
J’ai intervenu comme développeur full-stack (mobile + backend), principalement sur la gestion des demandes clients, la structuration des rôles et les parcours métier.
2. Lien public / éléments concrets
L’application est disponible sur les stores.
À défaut de partager des éléments internes, les schémas fonctionnels simplifiés est le suivant :
A) Parcours global (end-to-end)

B) Zoom “Qualification” (éviter demandes incomplètes) :

C) Zoom “Attribution” (prestataire, sans contact direct avant validation)

D) Rôles & interactions (règle clé)

3. Exemple de cas complexe géré
La gestion stricte des rôles et des interactions :
le client ne pouvait jamais entrer en contact direct avec le prestataire tant que la demande n’était pas validée et qualifiée, avec un pilotage centralisé des statuts et des permissions pour éviter tout contournement du processus.

1. Rôle exact sur le projet
J’ai travaillé en tant que développeur backend et mobile, en renfort d’équipe, sur des briques fonctionnelles bien définies (logique métier, statuts de livraison, notifications et synchronisation des flux).
2. Lien public / éléments concrets
L’application est disponible publiquement sur les stores.
En revanche, je ne peux pas fournir de code source, de captures internes, le projet étant couvert par un contrat de confidentialité et de non-réutilisation.
Par contre le Flux concrets & choix d’architecture sont les suivants :
A. Flux “commande / livraison” (workflow bloquant)
Principe : chaque livraison suit une machine à états côté backend, et aucune étape ne peut être sautée.
États typiques
• CREATED → ASSIGNED → PICKED_UP → IN_TRANSIT → DELIVERED
• exceptions : CANCELLED, FAILED, RETURNED

Règles de transition (exemples)
• Un coursier ne peut passer à PICKED_UP que s’il est assigné.
• DELIVERED nécessite une preuve (ex : photo / OTP / signature) selon la politique.
• Toute transition est validée server-side (le mobile ne “décide” jamais seul).

Flux concret
1. Client crée une demande (ou un opérateur la crée pour lui) → CREATED
2. Backend attribue un coursier (auto ou manuel) → ASSIGNED
3. Coursier confirme collecte → PICKED_UP
4. Suivi progression → IN_TRANSIT (positions/événements)
5. Livraison confirmée → DELIVERED
6. Notifications envoyées à chaque étape + historisation
________________________________________
B. Synchronisation temps réel (tracking & statuts)
Deux canaux
• API REST : lecture/écriture “source de vérité” (création, transitions, détails)
• Événements temps réel : push d’updates (statuts, tracking, messages système)
Pourquoi ce choix
• REST garantit la cohérence (transactions, contrôles d’accès)
• Les événements assurent une UX fluide (pas besoin de refresh constant)
________________________________________
C. Notifications (push) : “event-driven”