Oui. Un deuxième atelier, une deuxième boutique, plusieurs chantiers : le site est une DONNÉE que vous décrivez au moment de la génération, pas une édition du logiciel à acheter. Chaque enregistrement est rattaché au sien, les listes se filtrent, les indicateurs se calculent sur ce que vous avez délimité, et aucune ligne de tarif ne dépend du nombre de sites. Deux limites sont à connaître avant de vous lancer, et elles comptent : il n'y a pas de sélecteur GLOBAL de site qui bascule toute l'application d'un coup, et les comptes n'ont pas de restriction par site — un compte qui peut lire, lit tout. Cette page dit ce qui marche, la forme à choisir selon vos sites, et ce qui demanderait du développement.
Le piège n'est pas le prix, c'est la duplication
Ce que décrivent les comparatifs du secteur est très constant : quand une petite entreprise ouvre un deuxième point de vente sans outil pensé pour ça, elle installe une COPIE de l'existant. Résultat, deux fichiers indépendants, deux facturations séparées, et aucune vision d'ensemble sans une compilation manuelle en fin de mois. S'y ajoute une frustration plus insidieuse : beaucoup d'outils affichent « multi-boutiques » sans offrir de véritable pilotage centralisé — on a additionné des caisses, on n'a pas gagné un réseau.
La question n'est donc pas « ce logiciel propose-t-il une option multi-sites », mais « comment le site est-il représenté dans mes données ». C'est un problème de MODÉLISATION, et c'est exactement le terrain où une application décrite puis générée se comporte différemment d'un produit sur étagère : il n'y a pas d'édition supérieure à débloquer, il y a une description à écrire correctement une fois.
Le site est une donnée, pas une édition du logiciel
Concrètement, vous le décrivez comme le reste : « J'ai deux ateliers, Nord et Sud ; chaque intervention, chaque pièce en stock et chaque client est rattaché à l'un des deux, et je veux voir mes chiffres par atelier. » Le générateur produit alors la structure correspondante — l'entité ou la liste de valeurs, le rattachement de chaque enregistrement, les écrans qui filtrent. Rien n'est deviné : ce que vous n'écrivez pas n'existe pas, et ce que vous écrivez est produit de façon déterministe.
Un point mérite d'être dit clairement parce qu'il est inhabituel : aucune ligne de la grille tarifaire ne dépend du nombre de sites. Les formules se distinguent par le nombre d'applications actives et le volume de génération, pas par le nombre d'établissements, d'ateliers ou de chantiers que votre application suit. Un troisième site n'est pas un palier à franchir, c'est une valeur de plus dans une liste.
La forme à choisir selon vos sites
Deux formes existent et elles ne rendent pas la même chose, alors autant choisir en connaissance de cause. Si vos sites sont peu nombreux et stables — deux ateliers, trois boutiques —, déclarez-les comme une LISTE DE VALEURS. C'est la forme qui donne le plus : le panneau de filtres porte alors un sélecteur de site à côté de la recherche, le filtre choisi survit dans l'adresse de la page — donc un lien « les interventions en retard de l'atelier Sud » s'envoie à un collègue tel quel —, et les vues qui regroupent par statut savent aussi regrouper par site.
Si vos sites sont de vraies fiches — une adresse, un responsable, des horaires, un contact —, ce sont des ENREGISTREMENTS à part entière, reliés à vos autres données. Vous y gagnez la fiche du site, vous y perdez le sélecteur immédiat : le panneau de filtres ne pose un critère dédié que pour les listes de valeurs, les autres champs étant repliés dans la recherche plein texte, qui les couvre déjà. Et dans les deux cas, un indicateur du tableau de bord peut être délimité à un site précis, avec un clic qui atterrit sur la liste correspondante, déjà filtrée.
Les deux limites à connaître avant de vous lancer
La première : il n'existe pas de sélecteur GLOBAL de site. Le filtrage vit dans chaque liste, il n'y a pas de bascule en haut de l'écran qui mettrait toute l'application « en mode atelier Sud » pour la session. Pour une petite structure qui veut justement la vision d'ensemble, ce n'est pas gênant — c'est même l'inverse du problème décrit plus haut. Pour quelqu'un qui passe sa journée sur un seul site et ne veut jamais voir les autres, c'est un vrai inconfort, et mieux vaut le savoir avant.
La seconde est plus sérieuse : les comptes n'ont pas de restriction par site. Une application qui demande une connexion embarque une vraie gestion d'utilisateurs, chacun avec son identifiant, en lecture seule ou avec le droit de modifier — mais ce droit porte sur l'application, pas sur un périmètre. Un compte qui peut lire, lit tout. Si la confidentialité entre sites est une exigence, deux chemins : faire ajouter ce cloisonnement au code, qui vous appartient et s'exporte, ou générer une application par site — en acceptant alors de retrouver exactement le problème du début, l'absence de vision d'ensemble. Le dire d'avance vaut mieux que de le découvrir après.