Configuration multi‑sites pour petites chaînes : structurer succursales, rôles du personnel et clients partagés pour que chaque site ne voie que les données nécessaires.
Une configuration multi‑sites pour petites chaînes commence souvent par une idée simple : un seul système pour tout le monde. Les problèmes apparaissent quand chaque succursale utilise les mêmes écrans, les mêmes listes et les mêmes boutons, alors qu'elles n'ont pas les mêmes responsabilités.
L'échec le plus courant est la visibilité mélangée. Un employé à l'accueil de la Succursale A peut voir des rendez‑vous, des notes ou des factures de la Succursale B. Ou un responsable tente de corriger un problème local et modifie accidentellement un réglage global qui affecte toutes les succursales. Au début c'est pratique, puis cela devient vite du bruit et un risque.
« Chaque site voit ce qu'il doit voir » est simple : le personnel ne devrait voir que les clients, commandes, plannings, stocks et rapports qui correspondent à leur travail et à leur site. Si quelqu'un travaille sur deux sites, il doit voir les deux. Si quelqu'un est administrateur régional, il voit tout, mais uniquement parce que vous l'avez choisi volontairement.
Quand vous ne faites rien (ou comptez sur des règles informelles), quelques problèmes prévisibles apparaissent :
L'objectif n'est pas de tout verrouiller. C'est d'être délibéré sur ce qui est partagé et ce qui est séparé. Beaucoup de chaînes veulent une base clients partagée (pour reconnaître un client partout), tout en gardant des données propres à la succursale comme les plannings locaux, les notes internes et la performance du personnel.
Si vous utilisez un constructeur no‑code, décidez de ces règles avant de créer les écrans et workflows. Sinon vous bricolerez les permissions après que les gens aient déjà commencé à utiliser le système.
Les configurations multi‑sites fonctionnent mieux quand vous vous mettez d'accord sur quelques points avant de construire écrans, formulaires ou rapports. Si vous les sautez, les permissions deviennent compliquées et les données difficilement fiables.
Commencez par nommer vos blocs de construction. La plupart des petites chaînes ont besoin de succursales (emplacements), d'utilisateurs (comptes du personnel), de rôles (types de poste), de clients (identité partagée) et de transactions (commandes, rendez‑vous, tickets, retours).
Ensuite, décidez quels enregistrements sont globaux et lesquels appartiennent à une succursale. Les enregistrements globaux sont partagés dans l'entreprise, comme le profil client, un catalogue produit, ou des règles tarifaires corporate. Les enregistrements appartenant à une succursale concernent un seul site, comme le rapport de caisse quotidien, un planning local ou un inventaire propre à la succursale.
Les permissions ont besoin de deux dimensions, pas une :
Accès lecture et édition doivent être séparés. Un manager régional peut lire toutes les succursales mais ne modifier que le personnel de sa propre succursale. Un employé d'accueil peut lire les profils clients mais ne créer et modifier que les rendez‑vous pour son site.
Enfin, décidez comment doivent fonctionner les rapports. La plupart des équipes ont besoin à la fois de performances par site pour la gestion quotidienne et de rapports inter‑sites pour les propriétaires et la finance. Mettez‑vous d'accord tôt pour ne pas construire des rapports qui mélangent les données de façon déroutante.
Une configuration multi‑sites commence par une décision : que signifie « succursale » dans votre activité ? Pour certains, c'est un magasin que les clients visitent. Pour d'autres, c'est une clinique, un entrepôt ou une unité franchisée qui doit rester séparée.
Choisissez une signification et tenez‑vous‑y dans votre modèle de données. Si vous avez besoin plus tard de départements ou de zones de service, ajoutez‑les comme concepts séparés plutôt que de surcharger l'enregistrement de succursale.
Donnez à chaque succursale un identifiant stable qui ne change jamais, même si le nom change. Un code court (comme « NYC‑01 ») est généralement plus simple que d'utiliser l'adresse ou le nom comme clé.
Stockez ce dont dépend votre travail quotidien : code et nom d'affichage de la succursale, adresse, fuseau horaire (critique pour les horaires, réservations et rapports), heures d'ouverture (avec éventuels changements pour jours fériés) et un statut comme actif, temporairement fermé ou archivé.
Décidez ensuite comment le personnel est lié aux succursales. Certaines entreprises sont strictes (une personne = une succursale). D'autres déplacent le personnel entre sites. Les deux approches fonctionnent, mais cela change la façon d'assigner le travail et de filtrer les enregistrements.
Une approche pratique est de modéliser une table d'affectation Personnel‑Succursale distincte pour supporter le un‑à‑plusieurs sans devoir tout réorganiser plus tard.
Considérez les nouveaux sites comme des données, pas des cas spéciaux. Un test simple : « Peut‑on ajouter la succursale n°7 sans changer la logique ? » Idéalement, ajouter un site signifie créer un nouvel enregistrement succursale, définir fuseau horaire et horaires, puis affecter le personnel. Si vous modifiez beaucoup de règles, le modèle est trop couplé.
Une configuration de permissions propre part d'une idée : séparer ce qu'une personne peut faire (rôle) de ce qu'elle peut voir (périmètre). Si vous mélangez, vous finirez par donner des accès « utiles » qui deviennent du partage excessif.
La plupart des petites chaînes peuvent garder des rôles simples : propriétaire, manager régional, manager de succursale, employé, support. Définissez des permissions par défaut par rôle et gardez‑les simples. Pour chaque domaine (clients, rendez‑vous/commandes, inventaire, notes, rapports), décidez ce que signifient consulter, créer et modifier. Puis identifiez les actions qui ne sont jamais par défaut, comme l'export ou les modifications d'administration.
Une checklist qui évite la confusion :
Le périmètre est la seconde moitié du verrou. La plupart des équipes n'ont besoin que de trois périmètres : propre succursale seulement, succursales assignées, ou toutes les succursales. Un manager de succursale peut éditer mais uniquement dans sa succursale. Un manager régional peut voir plusieurs succursales mais n'éditer que le personnel et les plannings.
Prévoyez les exceptions avant d'en avoir besoin. Les accès temporaires doivent expirer automatiquement et ne pas dépendre de la mémoire de quelqu'un. Les comptes de formation doivent utiliser des données fictives ou un sandbox restreint. Les contractuels doivent recevoir le périmètre minimal et pas d'exports par défaut.
Une base client partagée est souvent le point central d'une configuration multi‑sites, mais elle peut aussi être la manière la plus rapide de divulguer des données entre succursales. Décidez ce qui est vraiment « un client, partout » et ce qui doit rester local.
Les données partagées comprennent généralement le profil client (nom, coordonnées), le statut fidélité et des préférences générales comme « ne pas appeler » ou « préfère e‑mail ». Cela aide n'importe quelle succursale à reconnaître la personne et à la servir de façon cohérente.
Les données spécifiques au site doivent rester liées à la succursale : visites, achats, rendez‑vous, notes de service et tags locaux comme « VIP pour Succursale A » ou « rappel la semaine prochaine ». Garder ces éléments locaux réduit le bruit et empêche le personnel de lire des détails inutiles.
La politique la plus simple : tout le monde peut trouver le client, mais tout le monde ne voit pas tout.
Le personnel d'accueil voit les détails du profil et les préférences de contact, plus les visites de sa succursale. Les managers peuvent voir des totaux inter‑succursales (comme le montant dépensé à vie) sans les notes détaillées d'autres sites. Les rôles HQ ou support peuvent consulter l'historique complet quand une montée en escalade l'exige. Le marketing peut accéder au statut d'opt‑in et aux segments, pas aux notes privées.
Ainsi la base client partagée reste utile sans devenir un journal partagé.
Les données sensibles (notes privées, documents, plaintes, détails médicaux ou juridiques) doivent être séparées des notes générales et verrouillées par des permissions plus strictes. Si vous stockez des documents, rendez l'accès explicite : qui peut téléverser, qui peut consulter, et si la consultation est limitée à la même succursale.
Exemple : un client visite la Succursale 1 pour une coupe et la Succursale 2 pour un achat. Le personnel de la Succursale 2 doit voir le niveau de fidélité et une préférence « allergie aux parfums », mais pas la note détaillée de la Succursale 1 sur une plainte.
Une décision clé est de séparer les données en les taguant ou en les scindant physiquement. La plupart des petites chaînes peuvent rester simples avec une seule base de données et des règles claires.
C'est le choix habituel. Commandes, rendez‑vous, comptages d'inventaire et actions du personnel vivent dans les mêmes tables, mais chaque ligne contient un BranchID (ou LocationID). Cela permet les clients partagés, le reporting inter‑sites et le personnel multi‑sites.
Cela peut sembler « plus sûr », mais augmente les coûts opérationnels. Les migrations doivent être faites plusieurs fois, les rapports deviennent plus compliqués et les clients partagés nécessitent de la synchronisation.
Règle pratique :
Quel que soit le schéma choisi, rendez les filtres de succursale automatiques. Ne comptez pas sur chaque écran ou rapport pour se souvenir du filtre. Traitez l'emplacement comme faisant partie de la session utilisateur et appliquez‑le en un seul endroit afin que chaque liste et action soit portée par défaut.
Prévoyez aussi des éléments globaux vs des remplacements locaux. Gardez les définitions globales (éléments du catalogue, modèles de service, règles tarifaires), puis ajoutez des champs d'override par succursale quand nécessaire (prix spécifique par succursale, seuil de stock, heures d'ouverture). Cela évite de copier tout le catalogue par site.
Ajoutez tôt des pistes d'audit. Vous devrez répondre à « qui a changé ceci, et où ? ». Au minimum, capturez l'ID utilisateur, l'ID de succursale, l'horodatage, l'action (création, mise à jour, suppression) et les valeurs avant‑après pour les champs sensibles.
L'objectif est simple : les gens doivent voir uniquement ce dont ils ont besoin pour faire leur travail, et rien d'autre. La manière la plus simple d'y arriver est de décider ce qui appartient à une succursale, ce qui est partagé et comment le personnel circule entre les écrans.
Commencez sur papier (ou un simple tableur) avant de toucher à la base de données ou à l'outil de création.
Ne zappez pas les tests. La plupart des problèmes de permissions n'apparaissent qu'en se connectant avec un vrai rôle et en effectuant des tâches quotidiennes rapidement.
La plupart des problèmes multi‑sites ne sont pas des catastrophes. Ce sont des valeurs par défaut qui fuient des données ou empêchent le travail. Considérez que chaque écran, rapport et export nécessite une règle de localisation.
Les rapports et exports sont souvent oubliés. Les équipes filtrent soigneusement les vues à l'écran par succursale, puis exportent « tous les clients » ou « les ventes du mois dernier » et incluent par erreur d'autres succursales. Traitez les exports comme des fonctionnalités séparées avec leurs propres filtres et tests. Si un employé ne peut pas voir un enregistrement dans l'app, il ne devrait pas pouvoir l'exporter.
Un autre problème est le rôle manager qui devient silencieusement admin. Cela arrive quand on regroupe les actions par écran et non par risque. Les managers peuvent avoir besoin de faire des remboursements, modifier des shifts ou ajouter des notes, mais pas de créer des utilisateurs, changer les permissions ou configurer des succursales. Séparez « gérer les opérations » de « gérer le système ».
Les clients partagés deviennent confus quand tout est stocké dans un seul champ. Si vous mettez des notes propres à une succursale (par ex. « demande toujours une remise ici ») dans une note globale, vous créez du partage excessif. Séparez les faits clients partagés de l'historique local de visites.
L'absence de piste d'audit entraîne reproches et retouches. Quand deux succursales modifient le même client, vous avez besoin du basique « qui a changé quoi et quand ». Même des champs simples created_by, updated_by et des horodatages aident.
Enfin, prévoyez le personnel flottant entre succursales. Si vous « déplacez » une personne entre sites au lieu de lui donner un accès multi‑site, les plannings et la visibilité se cassent.
Corrections pratiques à intégrer tôt :
Avant d'ouvrir l'accès à chaque succursale, faites une journée simulée avec des comptes tests. Créez au moins un employé par succursale, plus un manager régional. Ensuite effectuez le travail normal : réserver un rendez‑vous, créer une commande, mettre à jour un client, lancer un rapport.
Utilisez cette checklist pour attraper les problèmes qui causent le plus de confusion :
Testez ensuite une situation limite : un client achète à la Succursale A, puis appelle la Succursale C pour du support. Le personnel de la Succursale C doit voir le profil client partagé, mais pas les notes internes ou enregistrements restreints de la Succursale A.
Imaginez une petite chaîne de salons avec trois succursales : Centre‑ville, Riverside et Centre Commercial. Elles partagent une liste client pour qu'un client puisse réserver n'importe où, mais chaque succursale garde son planning, son personnel et ses notes quotidiennes.
Maya (accueil au Centre‑ville) ouvre le système. Elle ne voit que le calendrier du Centre‑ville, le personnel du Centre‑ville et les rendez‑vous du jour. Elle peut chercher les clients dans toutes les succursales, mais ne voit que les informations de base : nom, téléphone, allergies et statut fidélité. Elle ne voit pas le planning, la performance du personnel ou les notes privées de Riverside.
Alex (le propriétaire) se connecte. Alex voit les trois calendriers, les rapports de chiffre d'affaires par succursale et peut gérer les rôles du personnel. Alex peut aussi approuver des exceptions comme de grandes remises.
Jordan va habituellement au Centre‑ville, mais cette semaine réserve au Mall. Quand le Mall enregistre Jordan, ils voient le profil de base et l'historique des services (quels services, quand et par qui). Après le rendez‑vous, le Mall ajoute le nouveau service à l'historique de Jordan. Le Centre‑ville le voit ensuite pour éviter les répétitions de questions ou proposer le bon suivi.
Un moment délicat arrive au paiement. Jordan demande 30% de réduction pour un long délai. L'accueil du Mall peut saisir une demande de remise, mais ne peut pas l'appliquer au‑delà de 10%. La demande est envoyée à Alex pour approbation. Alex approuve, le reçu est mis à jour et le journal d'audit montre qui a demandé et qui a approuvé.
Les notes sensibles sont traitées différemment. Si un·e styliste ajoute une note privée comme « client en traitement médical, attention au soin du cuir chevelu », seuls les stylistes et le propriétaire peuvent la voir. L'accueil voit un indicateur plus sûr du type « manipulation particulière requise » sans les détails.
Ce qui fait que cela fonctionne, ce sont quelques règles claires : plannings et personnel scindés par succursale, informations clients de base partagées, notes sensibles restreintes, et limites d'approbation pour les remises.
Une configuration multi‑sites reste propre uniquement si vos règles sont écrites et testées comme une fonctionnalité, pas une impression. Transformez vos décisions « qui voit quoi » en phrases simples.
Visez 10 à 15 déclarations courtes couvrant les cas quotidiens : réservations, profils clients, paiements, remboursements, notes et rapports. Par exemple :
Décidez quels écrans et rapports doivent toujours par défaut utiliser le périmètre de succursale. Si un écran peut montrer toutes les succursales, faites‑en un filtre explicite, pas le réglage par défaut. Un bon test : un·e caissier·ère peut‑il·elle ouvrir accidentellement le rapport de chiffre d'affaires d'une autre succursale sans le vouloir ? Si oui, resserrez le défaut.
Testez avec des rôles réels, pas des comptes admin. Créez trois utilisateurs test (caissier, manager, HQ) et suivez un flux réaliste : un client appelle la Succursale A, visite la Succursale B la semaine suivante, et demande un remboursement à la Succursale C. Confirmez que chaque personne ne voit que ce dont elle a besoin.
Programmez une vérification mensuelle des permissions pour éviter la dérive : nouveaux rôles, changements de poste, nouvelles succursales et expansion des accès aux rapports.
Si vous construisez un outil interne sur mesure, AppMaster (appmaster.io) peut vous aider à modéliser succursales, rôles et règles métier en un seul endroit, puis regénérer du code propre au fur et à mesure des changements pour garder les règles de permission cohérentes à mesure de la croissance.
10 mars 2026
10 min
08 mars 202610 min
07 mars 202610 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
