YStay

Inviter son équipe et régler les rôles

Deux axes commandent l'accès d'un coéquipier — ce qu'il a le droit de faire, et sur quels biens. Le formulaire d'invitation règle les deux, et le lien n'est remis qu'une fois.

Un compte YStay se partage. La page Équipe, dans le groupe Compte de la navigation, accueille un concierge, une équipe de ménage, un comptable ou un co-investisseur, et fixe pour chacun deux réglages indépendants : ses permissions (ce qu'il peut faire) et son périmètre de biens (où il peut le faire). Oublier le second revient à confier tout le portefeuille à quelqu'un qui n'entretient qu'un studio.

Ouvrir cette page en écriture ne tient pas au rôle mais à une permission : la case Gestion de la ligne perm.module.coreTeam — l'identifiant technique du module Équipe dans la matrice d'un membre, cf. « Ce que la matrice affiche » plus bas. Un Gestionnaire la reçoit par défaut, un Équipier non ; cochez-la à un Équipier et il gérera l'équipe comme vous, retirez-la à un Gestionnaire — ou posez-lui un modèle d'accès, voir plus bas — et il la perd. Le propriétaire, lui, l'a toujours et n'est jamais modifiable : son rôle ne s'attribue pas, et aucun périmètre ne s'applique à lui. Inviter de nouveaux membres suppose enfin une offre qui inclut le travail en équipe : sinon la page remplace le formulaire par Voir les offres, sans empêcher de gérer les membres déjà présents.

Inviter, écran par écran

  1. Remplir le formulaire d'invitation

    La carte Inviter un collaborateur demande quatre choses : Adresse email, Rôle, Modèle d'accès et Biens accessibles.

    Le Rôle se choisit parmi Gestionnaire, Équipier et Lecture seule : le rôle de propriétaire n'est pas attribuable. Le Modèle d'accès, lui, propose Par défaut (selon le rôle) puis cinq préréglages prêts à l'emploi.

    Capture d'écran à produire

    captures/inviter-equipe-regler-roles/01-inviter-membre.png

  2. Choisir le périmètre de biens

    Sous Biens accessibles, cochez les biens que ce membre doit voir. Ne rien cocher n'est pas un oubli, c'est une décision — et l'écran la formule : « Aucune sélection : accès à tous les biens. » Un bien qui n'appartient pas à votre compte est écarté sans bruit : le périmètre enregistré ne contient jamais que vos biens.

  3. Remettre le lien à la personne invitée

    Inviter confirme par « Invitation envoyée. Partagez le lien ci-dessous pour finaliser l'accès. », affiche le Lien d'invitation, et la personne apparaît dans la liste avec le badge Invité.

    Ce lien ouvre une page qui demande de se connecter — ou de créer un compte — avec l'adresse invitée, puis valide l'accès. Cette page s'affiche en français ; sa version anglaise s'obtient en ajoutant « ?locale=en » à la fin du lien.

    Sur cette page, la personne invitée coche une case avant de pouvoir continuer : « En rejoignant ce compte, j'ai lu et j'accepte les conditions d'utilisation individuelles en vigueur. » Le lien ouvre le texte ; le bouton Rejoindre l'équipe reste inactif tant que la case n'est pas cochée. Ce sont ses conditions, pas les vôtres : elle n'est pas partie à votre contrat avec YStay, et sa réponse n'engage que son accès.

    Capture d'écran à produire

    captures/inviter-equipe-regler-roles/02-lien-invitation.png

  4. Affiner les accès après coup

    Sur la ligne d'un membre, Gérer les accès ouvre sa fiche : Modèle d'accès (preset), Permissions par module — une case par module et par action — et Biens accessibles. Enregistrer les accès clôt le tout.

  5. Relire la matrice de l'équipe

    Chaque ligne rappelle le rôle, le préréglage éventuel et le périmètre : Tous les biens, ou le nombre de biens sélectionnés. Le propriétaire, lui, n'affiche jamais de périmètre.

    Capture d'écran à produire

    captures/inviter-equipe-regler-roles/03-roles-et-perimetre.png

Les agents de terrain, sur la même page

Sous la carte Les rôles, la page Équipe porte une seconde liste : Agents de terrain. Elle ne réunit pas des membres de votre compte mais des intervenants extérieurs — des personnes sans compte YStay, ajoutées avec un nom et un téléphone, qui travaillent depuis un lien envoyé par SMS ou WhatsApp, et des prestataires avec compte invités par e-mail. Son fonctionnement est décrit dans Ajouter un agent de terrain sans compte ; trois points suffisent ici.

  • Elle ne dépend pas de l'offre Équipe. Même quand la page remplace le formulaire d'invitation par Voir les offres, la carte Agents de terrain reste affichée.
  • Elle a son propre module dans la matrice : la ligne Agents de terrain. La case Lecture ouvre la carte ; la case Écriture ouvre Ajouter un agent et les gestes de chaque ligne (modifier, renvoyer ou révoquer un lien, suspendre, inviter à créer un compte). Les modèles Concierge et Manager ont la lecture et l'écriture, le modèle Ménage la lecture seulement.
  • Un agent n'est pas un membre. Il n'a ni rôle, ni accès au tableau de bord : il ne voit que les tâches qu'on lui assigne, depuis son lien.

Les trois rôles, et les cinq modèles d'accès

La carte Les rôles, en bas de page, résume le socle :

  • Propriétaire & Gestionnaire — accès complet : exploitation, commercialisation, équipe et facturation.
  • Équipier — opérations terrain (réservations, séjours, ménage, incidents). Pas de gestion de l'équipe ni de la facturation.
  • Lecture seule — consultation uniquement, sans modification.

Ces résumés sont ceux de la carte, et celui de l'Équipier est plus étroit que la réalité : son socle ouvre, en lecture comme en écriture, les mêmes modules que le modèle Manager — Messagerie & automations, Finances courte durée et Inventaire & tarification compris —, sans la gestion de l'équipe ni de la facturation.

Cinq modèles d'accès sont proposés — Concierge, Ménage, Compta, Co-investisseur, Manager —, plus un mode manuel : Personnalisé (manuel), dans la fiche d'un membre. Un modèle n'affine pas ce socle, il le remplace : dès qu'un modèle est posé sur un membre, ses permissions viennent de ce modèle seul et le socle du rôle n'est plus consulté. Un Gestionnaire à qui vous appliquez un modèle perd donc la gestion de l'équipe et de la facturation — aucun des cinq ne les contient, pas même Manager. Un rôle Lecture seule, lui, reste en lecture quoi qu'on coche : le serveur refuse toute écriture venant de ce rôle.

Chaque membre ne reçoit et ne voit que les notifications des modules que son accès lui ouvre, c'est-à-dire — sauf mention contraire ci-dessous — ceux dont la case Lecture est cochée. La règle est la même sur l'application terrain (les notifications du téléphone) et dans la cloche du tableau de bord (le panneau Notifications). Le propriétaire du compte les reçoit toutes ; un membre retiré de l'équipe n'en reçoit plus aucune. Dans la cloche, l'accès requis est :

  • Messagerie & automations (ligne perm.module.stayMessaging) — un nouveau message voyageur, une demande de voyageur transmise par le support (« Une demande vous a été transmise »).
  • Opérations séjours (réservations, check-in/out) (ligne perm.module.stayOps) — une réservation confirmée, un nouvel avis voyageur, le rappel « Notez votre voyageur », un nouvel incident, un état des lieux voyageur terminé ou à co-valider, le préavis de suppression des preuves StayProof.
  • Finances courte durée (ligne perm.module.stayFinance) — un remboursement d'annulation à finaliser, une caution à restituer manuellement, une action du support à confirmer (libération de caution).
  • Inventaire & tarification (ligne perm.module.stayInventory) — les alertes de vos canaux : échec de synchronisation, mises à jour refusées par un canal, annonce toujours en vente, remise en vente non appliquée, annonce reprise conservée, réservation de canal non rattachée, modification de réservation à arbitrer.
  • Opérations séjours ou Ménage & turnovers (ligne perm.module.stayHousekeeping), l'un des deux suffit — les alertes Terrain : tâche non démarrée, bloquée, non vue la veille, preuve manquante. La cloche les montre pour tout le compte, pas seulement pour vos propres tâches.
  • Abonnement & intégrations (ligne perm.module.coreBilling) — la fin d'essai proche et l'essai terminé, pour ceux qui gèrent l'abonnement : la seule case de cette ligne est Gestion, que le Gestionnaire a par défaut et l'Équipier non.
  • Toute l'équipe, quel que soit l'accès — la réponse du support YStay à une demande du compte (« Réponse à votre demande de support »), dont le titre est neutre.

Un membre limité à certains biens ne voit en outre, dans la cloche, aucune entrée d'un bien hors de son périmètre. Certaines notifications n'existent que sur le téléphone, sans entrée dans la cloche : l'échéance de paiement en retard, par exemple, n'est notifiée qu'aux membres qui ont Finances courte durée (perm.module.stayFinance).

Ce que chaque accès ouvre en courte durée

Le serveur applique la matrice à chaque écran et à chaque geste de l'exploitation courte durée comme de son catalogue (annonces, tarifs, livrets, site, partenaires, contrats) : ce qu'un membre n'a pas le droit de faire n'est pas seulement caché dans le menu et dans l'application, il est refusé — et l'adresse directe d'un écran fermé affiche Accès refusé. Dans chaque module, la case Lecture ouvre ce qui se consulte et la case Écriture ce qui se modifie ; les deux sont indépendantes, et le propriétaire a toutes les cases.

  • Opérations séjours (réservations, check-in/out) — ligne perm.module.stayOps.
    • Lecture : les avis voyageurs (page Avis voyageurs, section Avis du voyageur de la fiche réservation — nom du voyageur et retour privé compris), les réservations et les panneaux de leur fiche, les attestations d'assurance, les contrats générés (onglet Contrats générés de la page Contrats saisonniers : liste, fiche et PDF), le tableau du jour (Arrivées, Départs, Séjours en cours), les séjours, les incidents et leurs dossiers, l'état des codes d'accès — jamais le code lui-même —, les sessions de check-in/out, les états des lieux et leurs comparaisons, les serrures, les écrans TV (page Appareils), les gabarits d'état des lieux, la politique d'incitation, l'export complet des preuves StayProof (Télécharger le dossier complet (ZIP)), les réservations dans la recherche (⌘K) et le nom des voyageurs sur le calendrier, dans les conflits de canaux, à l'arrêt des ventes et au retrait d'une annonce.
    • Écriture : répondre à un avis voyageur (la réponse part sur la plateforme d'origine au nom du compte) et masquer un avis ; créer, modifier ou annuler une réservation ; déclarer un incident et le faire avancer ; Voir le code, émettre et révoquer un code de porte ; rattacher, modifier, tester et détacher une serrure ; associer, renommer et retirer un écran TV, lui envoyer une commande et régler l'affichage de son logement ; fermer ou rouvrir des nuits au calendrier, poser ou lever une période bloquée et modifier un livret — gestes que l'écriture d'Inventaire & tarification ouvre aussi ; ouvrir et clôturer une session ; réaliser un état des lieux ; régler les gabarits d'état des lieux et la politique d'acteur ; émettre, relancer et révoquer le lien voyageur de l'état des lieux — et en lire l'adresse ; lire l'adresse du lien de paiement voyageur ; Régénérer, Renvoyer le lien et Annuler le contrat sur un contrat généré.
  • Messagerie & automations — ligne perm.module.stayMessaging.
    • Lecture : lire les conversations et les messages automatiques envoyés pour une réservation — un code de porte que ces messages contiennent y reste masqué, voir plus bas.
    • Écriture : envoyer un message, demander un brouillon à l'IA, créer et modifier les automations et les modèles de message.
  • Finances courte durée — ligne perm.module.stayFinance.
    • Lecture : les montants, les échéances et les paiements d'une réservation, et les relevés des partenaires (le menu Partenaires s'ouvre aussi à cette lecture).
    • Écriture : encaisser, rembourser, retenir ou libérer une caution, approuver ou rejeter une réclamation, modifier la politique d'incitation à l'état des lieux (carte Incitation état des lieux), et — comme Inventaire & tarification — geler un relevé de partenaire, y ajouter un ajustement, émettre ou révoquer le lien commerçant.
  • Inventaire & tarification — ligne perm.module.stayInventory.
    • Lecture : le Calendrier, comme Opérations séjours (ouvrir la fiche d'une réservation depuis le calendrier reste réservé à Opérations séjours, et le nom du voyageur aussi — voir plus bas) ; les menus Tarification, Contrats — sans son onglet Contrats générés —, Livrets et Mon site ; le menu Partenaires, que la lecture de Finances courte durée ouvre aussi, pour les relevés. Les fiches de biens, de logements et d'annonces — photos, équipements et tarifs compris — ne demandent aucune case : tout membre les lit, et un membre limité à certains biens n'y voit que les siens.
    • Écriture : les propriétés, les logements et les annonces (titre, description, publication, équipements, traductions, arrêt des ventes), leurs photos et leurs zones, les tarifs (tarif de base, saisons, frais, extras), les prix posés au calendrier, les restrictions de séjour, PriceLabs, les canaux (adresse iCal comprise), le site et ses domaines, les partenaires (fiches, encarts, diffusions, QR d'attribution) et les modèles de contrat avec leur surcharge par bien. Trois ouvertures voisines : le livret (contenu, photos, langues, publication) s'ouvre aussi à l'écriture d'Opérations séjours ; fermer ou rouvrir des nuits au calendrier et poser ou lever une période bloquée aussi — mais un prix envoyé exige l'écriture d'Inventaire & tarification ; les relevés des partenaires, leurs ajustements et le lien commerçant s'ouvrent aussi à l'écriture de Finances courte durée.
  • Ménage & turnovers — ligne perm.module.stayHousekeeping.
    • Lecture : les tâches de ménage et d'accueil, leur checklist, leurs preuves photo et Ma journée sur Host Ops.
    • Écriture : les faire vivre (démarrer, terminer, bloquer, assigner, ajouter une preuve) et créer une tâche. Opérations séjours ouvre les mêmes tâches ; ce module-ci, lui, n'ouvre ni les réservations, ni le tableau du jour, ni les codes, ni les sessions, ni les états des lieux.

Trois informations obéissent à une règle plus fine que « lecture » et « écriture », parce qu'elles identifient le voyageur ou ouvrent la porte :

  • Le nom du voyageur, aux endroits où il ne sert qu'à repérer une réservation. Sans la case Lecture d'Opérations séjours — avec la seule lecture d'Inventaire & tarification, par exemple —, le calendrier affiche Réservation à la place du nom (barre de la Timeline, pastille de la vue Mois, en-tête du panneau latéral), les conflits de canaux affichent Voyageur, et l'arrêt des ventes comme le retrait d'une annonce listent les réservations conservées par leur seule période. Le reste — dates, statut, canal, référence — n'est pas retiré : cela suffit à arbitrer un conflit de calendrier. La messagerie et les Encaissements gardent le nom, dont ils ont besoin pour répondre et pour rapprocher un paiement.
  • Un code de porte dans un message automatique. Quand une automation contient le jeton Code d'accès, le voyageur reçoit le vrai code. Côté hôte, la conversation et l'aperçu de la liste des conversations le remplacent par •••• pour qui n'a pas la case Écriture d'Opérations séjours — un membre qui n'a que Messagerie & automations, le rôle Lecture seule — et pour l'équipe YStay quand elle intervient sur votre compte. Le propriétaire et les accès qui ont cette écriture — modèles Concierge et Manager, rôles Gestionnaire et Équipier tant qu'aucun modèle n'est posé — le lisent en clair.
  • L'adresse d'un lien voyageur. Le lien de paiement de l'espace voyageur comme le lien de l'état des lieux ouvrent le parcours du voyageur à sa place : leur adresse n'est montrée qu'aux membres qui ont la case Écriture d'Opérations séjours. Les autres lisent seulement qu'un lien existe — « Un lien de paiement voyageur est actif. » sur la carte Espace voyageur du panneau Contrat & documents de la fiche d'une réservation et dans le panneau Extras, « Un lien voyageur est actif. » dans le bloc Lien voyageur de l'état des lieux —, suivi de « Son adresse n'est affichée qu'aux membres ayant l'écriture sur « Opérations séjours (réservations, check-in/out) ». » L'équipe YStay ne voit jamais ces adresses et n'émet ni code de porte, ni lien voyageur.

Il en va de même de la composition de l'équipe : quand l'équipe YStay intervient sur votre compte, elle ne peut ni inviter un membre, ni modifier les accès d'un membre déjà présent — son rôle, son Modèle d'accès, ses Permissions par module, ses Biens accessibles. Ces gestes restent les vôtres ; elle peut en revanche retirer un membre, geste d'urgence — avec les effets décrits dans « Ce qui part avec un membre », et ce retrait désactive aussi les applications OAuth que ce membre avait créées.

Il en va de même des accès de tiers : elle ne crée, ne supprime ni n'autorise aucune application OAuth à votre place — ni sur la page API & intégrations, ni quand un outil externe demande l'accès à votre compte. Elle ne connecte, ne remplace ni ne retire pas davantage le jeton de votre prestataire de serrures : sur la carte Serrures connectées, Connecter, Mettre à jour le jeton et Déconnecter lui sont refusés. Elle peut en revanche couper l'accès d'une application déjà connectée, mais depuis sa propre console, avec un motif consigné au journal d'audit de votre compte — jamais en se connectant à votre place. Sur la carte Serrure connectée d'une annonce, elle ne rattache, ne modifie ni ne détache pas davantage une serrure ; elle peut toutefois la Tester, sans que ce test change l'état de votre connexion.

Le catalogue — annonces, tarifs, livrets, site, partenaires, contrats — ajoute trois règles à « lecture » et « écriture » :

  • Un membre limité à certains biens. Même avec la case Écriture, il ne modifie que les annonces, les photos et zones, les livrets, les tarifs et la surcharge de contrat de ses biens, et les listes de logements et d'annonces comme la bibliothèque de médias ne lui montrent que ses biens. Les réglages qui valent pour tout le compte lui restent fermés en écriture : le site et ses domaines, les partenaires, les modèles de contrat, les équipements personnalisés, le compte PriceLabs. Il les lit, et l'écran dit « Ce réglage concerne tout le compte : il est réservé aux membres dont l'accès n'est pas limité à certains biens. »
  • La signature du bailleur (onglet Signature bailleur de la page Contrats saisonniers) ne dépend d'aucune case : seul le propriétaire du compte l'enregistre, la remplace ou l'efface, et ni un Gestionnaire ni le modèle Manager ne le peuvent. Les autres membres lisent à la place « Seul le propriétaire du compte peut enregistrer, remplacer ou effacer sa signature. »
  • L'équipe YStay, quand elle intervient sur votre compte, ne fait pas à votre place les gestes qui engagent votre vitrine, votre texte contractuel ou vos liens publics : ni publier ni dépublier un site ou un livret, ni supprimer un site, ni changer son Adresse (slug), son Email de contact ou son Téléphone de contact, ni gérer vos domaines (ajout, vérification, domaine principal, suppression), ni publier ou archiver un modèle de contrat, ni enregistrer une surcharge dans l'onglet Surcharge par bien, ni toucher à votre signature, ni émettre un lien public — le lien commerçant d'un relevé, le lien d'attribution d'une diffusion —, ni lire l'adresse iCal d'un canal, ni envoyer un Message plein écran sur une TV, ni relancer l'état des lieux d'un voyageur. Elle peut en revanche afficher le QR d'un lien d'attribution que vous avez déjà émis, pour vous aider à le réimprimer.

Ce que cela donne pour chaque modèle d'accès :

  • Concierge — Opérations séjours, Messagerie & automations et Ménage & turnovers et Early check-in et late checkout en lecture et en écriture, Inventaire & tarification en lecture ; pas de Finances courte durée. Côté catalogue, son écriture d'Opérations séjours lui laisse le livret entier, la fermeture et la réouverture des nuits au calendrier, les périodes bloquées et les écrans TV ; il ne modifie ni les annonces — description, photos et zones, publication —, ni les prix, extras et frais, ni le site, ni les partenaires, ni les contrats.
  • Ménage — Ménage & turnovers en lecture et en écriture, plus Plans de séjour et Agents de terrain en lecture, et rien d'autre : ni réservations, ni tableau du jour, ni codes, ni sessions, ni états des lieux, ni export des preuves.
  • Compta — Finances courte durée en lecture et en écriture, Opérations séjours en lecture : elle lit les réservations, les incidents, les séjours et l'export des preuves, sans jamais voir un code de porte. Elle tient aussi les relevés des partenaires — les lire, en geler un, y ajouter un ajustement, émettre le lien commerçant —, sans modifier ni les partenaires, ni les encarts, ni les diffusions.
  • Co-investisseur — Opérations séjours et Finances courte durée en lecture seulement, relevés des partenaires compris.
  • Manager — tous les modules en lecture et en écriture, sauf la gestion de l'équipe et de la facturation.
  • Personnalisé (manuel) — aucune case au départ : rien n'est ouvert tant que vous ne l'avez pas coché.

Le rôle hérité Lecture seule consulte tout ce que les cases Lecture ouvrent, mais n'écrit rien : il ne voit donc jamais un code de porte. Il peut en revanche télécharger le dossier complet des preuves StayProof — préparer cette archive est une lecture, qui ne modifie rien dans votre compte.

Ce que voit un rôle Lecture seule

La page Équipe s'ouvre, mais sans un seul contrôle : ni formulaire d'invitation, ni sélecteur de rôle, ni Gérer les accès. Le bandeau nomme le rôle — « Votre rôle (Lecture seule) ne permet pas de gérer l'équipe. » — mais ce qui manque est la permission : un Équipier voit exactement le même écran, et le même Équipier retrouve les contrôles dès qu'on lui coche Gestion sur perm.module.coreTeam. La navigation se resserre en même temps : Abonnement, Paiements et API & intégrations disparaissent, faute du droit de gérer la facturation ; Encaissements et Pilotage restent accessibles, en consultation — tant qu'aucun modèle d'accès n'a été posé sur ce membre, puisqu'un modèle recalcule aussi ce qu'il voit.

Ce qui part avec un membre

Un membre peut avoir branché sur votre compte des outils d'autres éditeurs : les autorisations qu'il a données figurent dans la carte Applications connectées de la page API & intégrations. Elles ne lui survivent pas ; elles sont coupées quand :

  • vous le retirez de l'équipe, avec Retirer ;
  • vous réduisez ses droits en dessous de « tous les droits sur tous les biens » — un rôle plus étroit, un modèle d'accès qui n'ouvre pas tout, ou un périmètre limité à certains biens —, avec Enregistrer les accès ;
  • vous le ré-invitez, ce qui le remet au statut Invité ;
  • son compte utilisateur est effacé de YStay.

Dans chaque cas, les applications tierces qu'il avait autorisées perdent leur accès à votre compte. Chaque coupure est inscrite au journal d'audit de votre compte. Quand l'une de ces applications tente ensuite de renouveler son accès, sa demande est refusée ; elle n'apprend rien sur votre équipe.

Ce qu'a connecté le propriétaire du compte n'est jamais touché, pas plus que ce qu'un autre membre a connecté. Un changement qui laisse au membre tous les droits sur tous les biens ne coupe aucune de ses autorisations. Le détail de la carte, du geste Couper l'accès et des durées de vie se lit dans Régler son compte et ses intégrations.

Les applications que le membre a lui-même créées sur la page API & intégrations tombent dans les mêmes cas, mais elles sont désactivées définitivement : voir l'encadré « Réduire les accès d'un membre désactive ses applications OAuth » plus haut.

Imposer la vérification en deux étapes à l'équipe

Tout en bas de la page, Sécurité de l'équipe porte un interrupteur : Imposer la vérification en deux étapes à l'équipe. La confirmation est franche — « TOUS les membres de l'équipe, vous compris, resteront bloqués tant qu'ils n'auront pas activé la vérification en deux étapes. » D'où le garde-fou : si votre second facteur n'est pas actif, YStay refuse — « Activez d'abord votre propre vérification en deux étapes avant de l'imposer à l'équipe. » — et propose Aller à ma sécurité. Lever l'obligation, à l'inverse, n'a aucune condition.

Et ensuite

Mis à jour le