--- title: "Droits et partage" url: https://developers.dagio.ai/fr/permissions/ --- # Droits et partage ## Droit effectif et interface Les opérations Surface vérifient l’identité, l’appartenance et les droits sur leur périmètre. Une vue peut masquer ou expliquer une Action indisponible, mais le service reste l’autorité. Une Query, un sélecteur de référence et un export doivent respecter les mêmes limites de lecture. | Niveau | Valeur attendue | Responsabilité | | ---------------------- | --------------------------------- | ------------------------------ | | Compte ou organisation | Identité et appartenance valides | Accès au contexte commun | | Workspace et contenu | Membres, rôles et grants | Consultation et modification | | Opération | Capacité et permission effectives | Exécution d’une Action | | Offre | Fonctionnalités autorisées | Accès aux capacités du produit | ## Accès à une application personnelle en V2 Connectez-vous à Surface avant d’ouvrir une application ou un lien direct vers une Surface. Le serveur vérifie la session courante et l’accès au tenant personnel à chaque lecture ou modification. Un paramètre d’URL ou un lien applicatif ne donne aucun accès à un autre tenant. Un tenant suspendu ou indisponible reste inaccessible même lorsque la connexion réussit. Utilisez **Sign out** dans l’en-tête de l’application pour terminer la session et vider l’application ouverte. Une session révoquée ou expirée exige une nouvelle connexion. Le Marketplace public est accessible avec Free, Plus, Teams, Pro et Business. **Pro ou Business** donne accès au Marketplace privé personnel; **Business** donne aussi accès au Marketplace d’organisation, selon la membership courante et les rôles de publication. Ce périmètre personnel ne définit pas les rôles des tenants partagés; le profil de revue local isolé ne démontre ni déploiement cloud ni réception réelle des courriels de vérification. ## Exemple d’équipe Les commerciaux consultent et préparent les soumissions. Le responsable peut les approuver. Un lecteur externe reçoit seulement le contenu explicitement partagé. La fiche Client ne doit pas révéler, par ses liens ou ses compteurs, des soumissions que ce lecteur n’est pas autorisé à connaître. ## Partager et révoquer Le forfait **Team** permet la collaboration depuis le compte utilisateur; il ne crée pas une équipe ni une Organization. **Organization** est réservée à **Business**. Une Organization et la liste des personnes ayant accès à un Workspace sont deux périmètres distincts. Ouvrez **Workspace → Paramètres → Membres et accès** pour consulter les membres et les invitations. Les rôles de l'application sont **Propriétaire (Owner)**, **Membre (Member)** et **Lecture seule (Reader)**. Le propriétaire prépare les invitations et examine les changements de rôle ou retraits avant confirmation. Le destinataire doit accepter l'invitation avant de recevoir l'accès proposé. Les accès de lecture ou de modification de chaque Space restent distincts du rôle dans le Workspace; un membre n'obtient pas implicitement tous les contenus. Choisissez l’objet et les personnes concernés, puis vérifiez le droit accordé. Un lien ouvre une destination; il ne constitue pas une permission à lui seul. Révoquer l’accès doit prendre effet dans les vues ouvertes et dans les opérations suivantes. Dans les réglages des connaissances, **Sécurité et accès** conserve la demande lorsque son résultat n’est pas confirmé. **Reprendre la demande** vérifie cette même invitation ou modification, sans en créer une autre. Si le changement est déjà enregistré mais que la liste ne s’actualise pas, la reprise relit les accès sans répéter le changement. Une invitation actualisée doit être examinée à nouveau avant son annulation; l’annulation d’une invitation ne retire aucun accès déjà accepté. Pour les contenus déjà partagés, l’Owner peut examiner les accès en lecture manquants aux instructions requises par leur Model. Le contrôle montre les personnes concernées et le nombre d’accès à compléter. Confirmer complète uniquement la lecture de ces instructions : cela n’ajoute personne au Workspace et ne crée ni ne réécrit une invitation. Si la confirmation reste incertaine, reprenez la même demande; le nombre effectivement complété provient du résultat confirmé. ## Coédition et administration Quand l’ajout d’accès est suspendu ou indisponible, le panneau de partage le signale et ne propose pas de nouvelle invitation ni de changement de rôle. L’Owner conserve l’inspection, l’annulation des invitations et le retrait des accès. Une demande déjà incertaine garde sa reprise exacte; elle reste soumise aux droits courants, sans réactiver un accès révoqué. Avant de changer un membre en Member ou Reader, ou de retirer son accès, la revue montre les accès effectifs actuels et proposés pour chaque destination. Les accès directs et ceux d’autres Workspaces restent conservés; le dernier Owner ne peut pas être retiré. Le détail du membre garde son identité exacte lorsqu’aucun nom d’affichage n’est disponible. Si la réponse est incertaine, reprenez la même demande depuis le partage plutôt que de confirmer un second changement. La coédition nécessite l’offre Team ou supérieure et une autorisation effective de session et de contenu. La modification d’un Model, des connexions ou des intégrations exige également les droits adaptés à cette configuration. L’AI utilise les permissions de son contexte; une demande en langage naturel ne lui confère pas un rôle supplémentaire. Les forfaits payants comptent chaque membre humain actif du compte, Reader inclus, une fois par compte, pas par application ou Workspace partagé. Les invitations non acceptées et les identités inactives ne comptent pas. Retirer l'accès à une application ne supprime pas l'appartenance au compte. Le décompte des places n'accorde aucun accès : les droits de l'application et du contenu restent nécessaires. ## Exemples appliqués : Droits de préparation et d’archivage La politique du Space exige editor pour préparer et owner pour archiver, en plus du rôle applicatif. La visibilité de la commande ne remplace pas ces droits. ### Configuration Fragment à placer dans `contentActions[]`. [Propriétés et valeurs admises](https://developers.dagio.ai/fr/reference/content-space-action-policy/). ```json { "contract": "ContentSpaceActionPolicy@1", "spaceKey": "clients", "actionKey": "prepare-quote", "minimumRole": "editor" } ``` ### Variante et raccordement Fragment à placer dans `contentActions[]`. [Propriétés et valeurs admises](https://developers.dagio.ai/fr/reference/content-space-action-policy/). ```json { "contract": "ContentSpaceActionPolicy@1", "spaceKey": "clients", "actionKey": "archive-client", "minimumRole": "owner" } ``` ### Exemple de disposition UI La disposition illustrative ci-dessous situe cette configuration dans l’app Clients/Soumissions. Chaque fragment s’insère à l’emplacement indiqué; ses références aux Fields, Queries et Actions correspondent aux déclarations du Model. 1. Action 2. Rôle minimal 3. Sources autorisées 4. Décision