Sites multiples

Vue d’ensemble

Ziptask n’a pas d’objet « site » dédié — et pour la plupart des exploitations multi-sites, il n’en a pas besoin. Les équipes sont la frontière du site. Une équipe isole qui peut voir et travailler sur un ensemble de listes, de sorte que modéliser chaque site (ou chaque site + service) comme sa propre équipe garde le travail de chaque site proprement séparé au sein d’un seul compte, avec une seule connexion partagée, un seul jeu de modèles et des rapports à l’échelle du compte pour les propriétaires.

Ce guide couvre le modèle recommandé, quand l’utiliser, et les limites à connaître avant de passer à l’échelle.

Nécessite : l’indicateur de fonctionnalité teams_enabled activé. Les rôles personnalisés (mentionnés ci-dessous) nécessitent le forfait Starter ou supérieur. Voir teams.md, permissions.md et feature-flags.md.

Décidez d’abord : isoler, ou simplement étiqueter ?

Il y a deux besoins différents qui se ressemblent. Choisissez celui qui correspond à la façon dont votre personnel travaille réellement — cela détermine toute la configuration.

Vous voulez…	Utilisez	Pourquoi
Que le personnel de chaque site ne voie et ne travaille que sur les listes de son propre site	Équipes	Les équipes imposent l’accès. Un membre d’une équipe ne peut pas voir les listes d’une autre équipe.
Une équipe partagée unique qui circule entre les sites, et vous voulez juste filtrer/rapporter par site	Étiquettes	Les étiquettes étiquettent et filtrent les listes mais ne restreignent pas l’accès — tout le monde voit toujours tout. Voir tags.md.

Un Client peut aussi tenir lieu de site lorsque le « site » est en réalité une propriété cliente que vous desservez (courant pour le nettoyage, l’aménagement paysager et la gestion immobilière) — rattachez chaque liste au client et utilisez l’historique du client comme relevé par site.

Le reste de ce guide suppose que vous voulez l’isolement — un personnel distinct par site — ce qui est le cas habituel pour les succursales, les établissements et les franchises.

Le modèle recommandé : les équipes comme site × service

Pour une exploitation à deux sites avec une cuisine et une salle à chaque site, créez quatre équipes :

Site A — Cuisine
Site A — Salle
Site B — Cuisine
Site B — Salle

Puis attribuez les rôles selon la portée de la responsabilité de chaque personne :

Personne	Rôle	Appartenance aux équipes
Personnel de terrain / équipe sur un site + service	Team User	Leur unique équipe (par ex. `Site A — Cuisine`)
Responsable de service sur une équipe	Team Admin	Cette unique équipe
Responsable de site sur un site entier	Team Admin	Les deux équipes de ce site (Cuisine + Salle)
Propriétaire / responsable régional (tous les sites)	Admin ou Root	Aucune appartenance à une équipe requise

Deux choses rendent cela possible :

Les membres peuvent appartenir à plusieurs équipes. C’est ainsi qu’un responsable de site obtient l’administration des deux services de son site — ajoutez-le aux deux équipes en tant que Team Admin. Voir teams.md.
Root et Admin voient tout à l’échelle du compte, quelle que soit l’équipe. Le propriétaire n’a pas besoin d’être ajouté à chaque équipe — le périmètre du compte couvre déjà tous les sites. Réservez l’appartenance à plusieurs équipes aux responsables de site qui en ont besoin.

Si vous n’avez besoin que d’une séparation par site (pas site × service), simplifiez : une équipe par site (Site A, Site B).

Mettre cela en place

Activez teams_enabled (Root, depuis les paramètres du compte) si ce n’est pas déjà fait.
Créez les équipes — une par site, ou une par site × service (page Équipes → Créer une équipe). Voir teams.md.
Ajoutez les membres à leur(s) équipe(s) et définissez le rôle de chaque personne (Team User pour l’équipe de terrain, Team Admin pour les responsables). Une personne présente dans plusieurs équipes obtient un sélecteur d’équipe lors de la création de listes.
Construisez les listes de chaque site à partir de vos modèles. Créez la liste à partir d’un modèle, puis définissez son équipe sur la bonne équipe de site. Les modèles sont partagés à l’échelle du compte, donc vous construisez la liste de vérification une seule fois et l’apposez par site. Voir tasks.md.
Pour les routines récurrentes, définissez l’équipe sur la liste maître. Chaque instance que la planification génère hérite automatiquement de cette équipe — voir ci-dessous.

Comment les listes récurrentes se comportent entre les sites

Une liste maître récurrente appartient à une seule équipe, et chaque instance qu’elle génère hérite de cette équipe. Ainsi, une routine qui s’exécute sur les deux sites nécessite une liste maître par équipe de site (par ex. une liste maître de fermeture nocturne sur Site A — Cuisine et une autre sur Site B — Cuisine). Construisez chacune à partir du même modèle pour les garder identiques.

Il en va de même pour les attributions : quiconque est attribué à la liste maître est copié sur chaque instance générée automatiquement, de sorte que vous définissez une fois l’équipe permanente d’un site sur la liste maître et chaque instance future la porte. Voir tasks.md et reminders.md.

Limites à connaître

Une personne a un rôle par compte, appliqué à toutes ses équipes. Vous ne pouvez pas faire de quelqu’un un Team Admin sur une équipe et un Team User sur une autre — s’il est Team Admin, il gère chaque équipe à laquelle il appartient. Pour la hiérarchie habituelle (les responsables administrent leurs sites, le personnel travaille dans son service), c’est exactement ce qu’il faut ; cela ne pose problème que si vous avez besoin que quelqu’un gère un site mais travaille simplement sur un autre.
Aucun cumul inter-sites au-delà de Root/Admin. Un Team Admin ne voit que ses équipes. La visibilité et les rapports à l’échelle du compte sont une vue Root/Admin (propriétaire). Voir reporting.md et activity-log.md.
Les équipes sont l’unité d’isolement — pas une frontière de facturation ou de données. Tous les sites partagent un seul abonnement, un seul annuaire de membres, une seule bibliothèque de modèles/étiquettes/clients et un seul historique d’activité. Si vous avez besoin d’une facturation ou de données entièrement séparées par site, utilisez plutôt des comptes distincts.

Notes pour l’assistance

Si un responsable de site ne peut pas voir les listes d’un site, vérifiez (a) qu’il est membre de la ou des équipes de ce site, et (b) que les listes ont effectivement la bonne équipe définie (visible dans la barre latérale du détail de la liste). Les listes sans équipe ne sont visibles que par leur créateur et Root. Voir teams.md.
Si les instances récurrentes d’un nouveau site ne portent pas la bonne équipe, vérifiez l’équipe et les attributions de la liste maître — les instances héritent des deux depuis la liste maître au moment de la génération, donc les corrections se font sur la liste maître (et s’appliquent aux instances futures ; celles déjà générées se modifient individuellement).
Renommer un site : renommez l’équipe (page Équipes). Les listes existantes conservent leur association automatiquement.
Fermer un site : supprimer son équipe retire l’équipe et ses appartenances mais pas les listes ni les tâches — réattribuez ou archivez ces listes d’abord si vous voulez les retirer du répertoire actif.
Les propriétaires qui « ne trouvent pas la fonctionnalité Sites » : il n’y en a pas — ce modèle basé sur les équipes est la configuration multi-sites. Orientez-les vers ce guide.