Cas d'étude Livroux : comment on a ajouté un système de sous-administrateurs régionaux

Livroux est une application de livraison de repas à domicile, dans la lignée des grandes plateformes type Uber Eats, mais positionnée sur un territoire et un réseau d'enseignes maîtrisés. Quand le projet nous a été confié, l'app tournait déjà et avait livré plus de 100 000 commandes. Le besoin n'était pas une V1, c'était une évolution structurante : ajouter un système de sous-administrateurs régionaux capable de gérer enseignes et livreurs par zone géographique, sans refondre l'application côté utilisateur final.

Le contexte du projet

Livroux s'appuie sur un modèle classique : des utilisateurs qui commandent, des enseignes partenaires qui préparent, des livreurs qui acheminent, et une administration qui pilote le tout. Ce modèle fonctionnait, mais la croissance posait une question simple : comment gérer efficacement l'opérationnel quand le nombre d'enseignes et de livreurs augmente, répartis sur plusieurs zones géographiques, sans que l'administration centrale devienne un goulet d'étranglement ?

La réponse, co-construite avec le client, a été d'introduire une nouvelle strate dans l'organisation : le sous-administrateur régional. Une personne responsable d'un territoire précis, avec des droits limités à sa zone et un outillage adapté pour gérer son périmètre au quotidien.

Le défi : découper sans fragmenter

Sur le papier, ajouter un rôle dans une application peut sembler simple. En pratique, introduire une notion de "zone" dans un produit qui n'en avait pas touche beaucoup plus d'endroits qu'on ne le pense :

• Le modèle de données : chaque enseigne, chaque livreur, chaque commande devait pouvoir être rattaché à une zone, sans casser l'historique existant.
• Les droits d'accès : un sous-admin ne devait voir et ne pouvoir agir que sur son périmètre. Pas question qu'une mauvaise manipulation impacte les données d'une autre région.
• Les interfaces : les écrans d'admin devaient se contextualiser automatiquement à la zone du sous-admin connecté, sans dupliquer toute l'interface de l'admin global.
• Le pilotage terrain : attribution d'une commande à un livreur, gestion des indisponibilités d'enseigne, suivi de l'activité, tout cela devait être filtré par zone.

La solution technique

Un modèle de zones géographiques

On a introduit une entité de zone en coeur du modèle de données, avec une géométrie géographique associée (polygones délimitant la zone sur la carte). Chaque enseigne et chaque livreur sont rattachés à une ou plusieurs zones. Chaque sous-admin est affecté à une ou plusieurs zones également, ce qui définit précisément son périmètre d'action.

Cette approche a l'avantage d'être extensible : ajouter une nouvelle zone ne demande pas de toucher au code, seulement de la configurer côté administration. Si demain un nouveau territoire s'ouvre, il suffit de créer la zone et d'y rattacher un sous-admin.

Un système de droits granulaire

La montée en niveau a introduit trois grandes familles d'acteurs côté pilotage :

Côté implémentation, chaque requête de données est filtrée en amont selon le rôle et les zones de l'utilisateur connecté. Un sous-admin ne peut techniquement pas récupérer de données en dehors de son périmètre, même via une manipulation directe. Cette règle est appliquée côté serveur, pas seulement côté interface.

Une interface unifiée mais contextualisée

On a fait le choix de ne pas créer une application séparée pour les sous-admins. La même application, avec une interface qui s'adapte automatiquement au rôle et au périmètre de l'utilisateur connecté. Un sous-admin voit la carte centrée sur ses zones, les listes filtrées par défaut, les actions disponibles limitées à son champ de responsabilité.

Des outils de pilotage dédiés

Le sous-admin a besoin d'outils concrets pour piloter son territoire. On a développé plusieurs vues spécifiques :

• Tableau de bord régional : vue synthétique de l'activité de la zone (commandes en cours, livreurs actifs, enseignes ouvertes).
• Gestion des enseignes : ajout, suspension, mise à jour des informations des enseignes de la zone.
• Gestion des livreurs : validation des nouveaux livreurs, suivi de leur activité, gestion des indisponibilités.
• Carte opérationnelle : vue géographique temps réel des livreurs et commandes en cours dans la zone.

Les résultats

Le système de sous-administrateurs régionaux a donné au modèle d'exploitation la souplesse dont il avait besoin pour passer à l'échelle.

• +100 000 commandes livrées avec un pilotage opérationnel distribué par zone.
• Administration centrale déchargée des tâches opérationnelles quotidiennes, qui remontent désormais aux sous-admins de chaque territoire.
• Une seule codebase Flutter maintenue pour tous les rôles, ce qui garde la vélocité de développement intacte.
• Un modèle extensible : ouvrir une nouvelle région se fait en configuration, pas en développement.

Ce qu'on retient de ce projet

Ajouter un rôle à une application existante n'est pas une évolution anodine. C'est un changement structurel qui touche le modèle de données, la sécurité, les interfaces et les parcours. Sur Livroux, la réussite du projet tient en grande partie au travail amont : avant d'écrire du code, on a pris le temps de modéliser précisément ce qu'est une zone, qui peut faire quoi dessus, et comment les flux opérationnels existants se projettent dans ce nouveau découpage.

L'autre enseignement, c'est la valeur d'une codebase Flutter unique pour un produit multi-rôles. Adapter l'interface selon le rôle connecté évite la duplication, limite les divergences et garde la charge de maintenance raisonnable, même quand le produit prend de l'ampleur.