# Teams Espaces de mémoire partagée isolés par locataire pour équipes collaboratives d'agents. Les administrateurs d'espace gèrent les limites de l'espace de travail sur le plan de gestion, tandis que l'accès à la mémoire est partitionné par sièges sur le plan de données. - Canonical: https://docs.xmemo.dev/fr/docs/capabilities/teams - Locale: fr-FR - Content-Locale: fr-FR - Canonical-Content-Digest: 683a48f04a5f54654f8d734721bc2af8e92c80d4945ca6276756bd086e701f4a - Edition-Digest: 8ada7fdaa02cf3db05e116e8b708478ad7289ddc8471f6eeb8ed0e72e2e61084 - Source-Revision: sha256:097bdf026d1d9352be562c7452c3f2d43aa7b273daa1d8428329f4a76bcb7efe ## Architecture de mémoire d'équipe et statut Preview Teams est une fonctionnalité du plan Business. En production, la création d'équipe est désactivée par défaut jusqu'au lancement du plan Business ; le runtime actuel fonctionne en mode de refus strict (deny-only) pour les requêtes non autorisées. Les administrateurs d'espace gèrent les limites de l'espace de travail et le provisionnement des locataires sur le plan de gestion de l'espace de travail, tandis que l'accès des agents à la mémoire est régi par des sièges sur le plan de données avec liaisons cryptographiques d'espace isolées par locataire. - Statut Preview : Dans la Memory Console sur https://xmemo.dev/me#teams, Team Management porte le badge Preview. - Contexte de l'espace de travail de la console : L'en-tête de Team Management annonce "One workspace for members and invitations." où les administrateurs gèrent les membres actifs et les invitations en attente. - Navigation dans l'espace : Les collaborateurs basculent dans un espace d'équipe à l'aide du paramètre d'espace explicite (https://xmemo.dev/me?space=#memory) ou inspectent les connaissances partagées (https://xmemo.dev/me?space=#knowledge) et les compétences (https://xmemo.dev/me?space=#skills). - Isolation collaborative : Les espaces de travail d'équipe fournissent un contexte partagé multi-agent isolé des espaces de mémoire personnelle de chaque utilisateur (/me#memory). ## Éligibilité d'équipe, conditions de création et limites d'abonnement La création d'équipe nécessite un abonnement Business valide avec au moins 2 sièges achetés. Le plan Business n'étant pas ouvert à l'achat pour le moment, la création d'équipe en libre-service est désactivée par défaut pour les comptes généraux. La documentation publique ne présente jamais l'achat de sièges comme une action disponible. - Posture de création : La création d'équipe en libre-service est désactivée par défaut dans les environnements de production jusqu'au lancement du plan Business. - Condition d'éligibilité : La console vérifie les droits de l'organisation avant d'ouvrir la création d'équipe. En cas d'inéligibilité, l'interface affiche : "A Business subscription with at least 2 purchased seats is required to create a team." - Raison de limitation Preview : Si un compte n'est pas autorisé sur la liste verte, la console affiche : "Team creation is currently limited to preview accounts." - Raison d'indisponibilité générale : Pour les comptes non provisionnés, la console indique : "Team creation is not available for this account yet." - Statut commercial : L'abonnement Business n'est pas achetable actuellement. L'ajout de sièges en libre-service et les mises à niveau de forfait sont désactivés. - Modale de création : Dans les comptes de préversion autorisés, cliquer sur Create team ouvre une modale indiquant : "Enter your company name. This will become the team name inside XMemo." avec le champ de saisie "Company name" (espace réservé "e.g. Acme Corp"). ## Hiérarchie RBAC à quatre niveaux et plafonds d'émission d'identifiants Les autorisations d'adhésion à l'équipe et les plafonds d'émission d'identifiants sont appliqués par les services de la console personnelle. Les membres actifs ayant le rôle owner, admin ou member peuvent émettre des identifiants liés à l'équipe dans les limites des portées spécifiques à leur rôle, tandis que les viewers sont strictement en lecture seule et n'ont pas accès à l'émission de jetons. Le schéma des rôles ci-dessous est un récapitulatif illustratif (et non une réponse d'API) : - Hiérarchie des rôles : Récapitulatif illustratif (non une réponse d'API) associant les rôles de l'espace de travail aux niveaux d'autorisation et aux plafonds d'émission de jetons. - owner (niveau 3) : Créateur de l'espace de travail lié au compte de facturation. Peut inviter des membres avec les rôles Admin, Member ou Viewer ; peut mettre à jour les rôles des membres non propriétaires (entre Admin, Member et Viewer) ; peut supprimer des membres non propriétaires et révoquer les invitations. Peut émettre des identifiants liés à l'équipe avec n'importe quelle portée en libre-service, y compris les portées de mémoire du plan de données, ledger, connaissances et audit (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write et read:audit). - admin (niveau 2) : Administrateur de l'espace de travail. Peut inviter des membres avec les rôles Member ou Viewer (ne peut pas inviter d'Admins) ; peut supprimer des membres non propriétaires et révoquer des invitations en attente ; ne peut pas modifier les rôles des membres. Peut émettre des identifiants liés à l'équipe avec n'importe quelle portée en libre-service, y compris les portées de mémoire du plan de données, ledger, connaissances et audit (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write et read:audit). - member (niveau 1) : Collaborateur standard de l'espace de travail. Accès en lecture, écriture et restauration aux sièges de mémoire partagée d'équipe, aux éléments de connaissances d'équipe et aux Cloud Skills d'équipe. Peut émettre des identifiants personnels liés à l'équipe plafonnés aux portées de membre d'équipe (memory:read, memory:write, memory:restore, read:memories et write:memories) ; ne peut pas émettre de portées élevées de ledger ou de connaissances, ni gérer les membres ou paramètres de l'espace de travail. - viewer (niveau 0) : Accès en lecture seule à la mémoire dans la console (memory:read) et consultation des connaissances partagées. Aucune émission d'identifiants autorisée ; interdiction d'écrire dans la mémoire, de mettre à jour l'état ou d'émettre des identifiants d'équipe. - Contrainte de propriétaire unique : Un propriétaire unique tentant de quitter l'équipe reçoit la notification : "Cannot leave team as the sole owner. Transfer ownership or delete the team first." (avec infobulle : "Sole owner must transfer ownership before leaving"). ```json { "roles": { "owner": { "level": 3, "token_issuance_cap": [ "memory:read", "memory:write", "memory:restore", "read:memories", "write:memories", "delete:memories", "ledger:read", "ledger:write", "knowledge:read", "knowledge:write", "read:audit" ] }, "admin": { "level": 2, "token_issuance_cap": [ "memory:read", "memory:write", "memory:restore", "read:memories", "write:memories", "delete:memories", "ledger:read", "ledger:write", "knowledge:read", "knowledge:write", "read:audit" ] }, "member": { "level": 1, "token_issuance_cap": [ "memory:read", "memory:write", "memory:restore", "read:memories", "write:memories" ] }, "viewer": { "level": 0, "token_issuance_cap": [] } } } ``` ## Liaison d'espace souveraine sur le serveur et révocation dynamique L'isolation multi-tenant est appliquée côté serveur via des liaisons cryptographiques d'espace. Chaque clé d'API délimitée à une équipe contient des revendications immuables (bound_team_id, membership_id_at_issue, space_binding_version) qui ne peuvent pas être modifiées ni fournies par des requêtes clientes. Les requêtes ciblant une équipe incompatible échouent immédiatement en mode fermeture sécurisée avec HTTP 403 token_space_mismatch. - Vérification d'espace souveraine : Les requêtes ciblant une équipe incompatible échouent immédiatement en fermeture sécurisée avec HTTP 403 token_space_mismatch. - Garantie anti-usurpation : Les requêtes comportant des en-têtes d'équipe falsifiés ou conflictuels sont rejetées en périphérie (edge) avant d'accéder aux pools de bases de données. - Révocation dynamique basée sur l'époque : La validation de l'adhésion vérifie l'époque de membership_id active à chaque requête authentifiée, garantissant que les membres supprimés perdent immédiatement l'accès lors de la mise à jour de l'époque sans attendre l'expiration du jeton. ## Gestion des sièges, cycle de vie des invitations et limites opérationnelles La capacité de l'espace de travail est suivie de manière qualitative entre adhésions actives et invitations en attente. Les limites opérationnelles régissent l'émission des invitations, l'expiration et les capacités de la console : - Décompte qualitatif des sièges : Les sièges occupés se composent des membres actifs plus les invitations en attente non expirées, affichés dans l'en-tête de la console sous la forme "Seats {used} / {limit} used, {members} members, {pending} pending". - Expiration technique des invitations : Les invitations d'équipe expirent 7 jours après leur émission (teams_service.py:1184-1188). Les invitations expirées libèrent leur réservation et ne comptent plus dans les sièges occupés. - Limite de capacité de sièges : Lorsque tous les sièges disponibles sont occupés, la modale Add member avertit : "Team seat limit reached. Upgrade or remove a member or pending invitation to send more invitations." - Statut du flux d'invitation : L'envoi d'une invitation génère un lien de jeton sécurisé valable 7 jours. Toutefois, l'acceptation de l'invitation n'a aucun consommateur dans l'interface de la console aujourd'hui ; le flux complet d'acceptation d'invitation n'est pas encore disponible dans la console. - Pas de suppression d'équipe ni de transfert de propriété : La console ne fournit aucune route ni contrôle d'interface utilisateur pour supprimer un espace de travail d'équipe ou transférer la propriété de l'équipe. Ces actions ne sont pas disponibles en libre-service. ## Ressources partagées, accès des agents et limites d'exportation de données La fonctionnalité Teams n'introduit aucun changement sur la surface du Model Context Protocol (MCP). Les agents accèdent à la mémoire d'équipe partagée de manière transparente à l'aide des outils standard (remember, recall, recall_context, search, etc.) en s'authentifiant simplement avec un jeton lié à l'équipe. - Mémoire d'équipe partagée : Les agents connectés qui s'authentifient avec un jeton lié à l'équipe lisent et écrivent dans l'espace de mémoire d'équipe partagé. - Connaissances d'équipe partagées : Les collections de documents publiées sous l'espace d'équipe (?space=#knowledge) peuvent être récupérées par les agents d'équipe et les membres d'équipe disposant de la portée knowledge:read. - Cloud Skills d'équipe partagées : Les compétences procédurales créées sous l'espace d'équipe (?space=#skills) sont régies par les rôles d'équipe. La publication dans un espace d'équipe crée une révision PROPOSED nécessitant l'approbation d'un Admin ou Owner. - Limite des projets personnels : Les espaces de travail de projets restent strictement personnels aujourd'hui (services/personal_console.py:7222). La création d'un espace de travail de projet avec team_id est rejetée par le backend. - Limite d'exportation de données : L'exportation de données personnelles (/api/v1/export ou /me#memory) exporte exactement les mémoires personnelles et exclut strictement les enregistrements de mémoire partagée d'équipe. - Surface d'outils figée : Aucun outil de gestion d'équipe (tel que la création d'équipe ou la gestion des invitations) n'est ajouté au MCP. - Compatibilité universelle des clients : Claude Desktop, ChatGPT, Codex, Cursor et Gemini CLI interagissent avec la mémoire d'équipe sans aucune modification de configuration côté client. - Isolation délimitée : Les mémoires écrites par des agents dans un espace d'équipe reçoivent automatiquement l'attribution de l'équipe et sont isolées de la mémoire personnelle de l'utilisateur. ## Limites explicites et fonctionnalités non vérifiées Pour éviter tout décalage de documentation par rapport au code livré, les fonctionnalités suivantes ne sont explicitement pas disponibles et hors de portée pour la version actuelle : - Plan Business requis : La fonctionnalité Teams appartient au plan Business, qui n'est actuellement pas encore ouvert à l'achat public. - Création en production désactivée : La création générale d'équipes en libre-service est désactivée dans les environnements de production jusqu'au lancement du plan Business. - Aucune synchronisation automatisée SCIM / SAML : La synchronisation d'annuaire avec des fournisseurs d'identité d'entreprise n'est pas prise en charge. - Aucune réplication de données multi-cloud ou multi-régions : Les données d'équipe résident dans une partition de locataire régionale unique. - Aucun outil de mutation MCP : Les équipes ne peuvent pas être créées, modifiées ou supprimées via des appels d'outils MCP. - Mode runtime de refus strict : Le runtime actuel fonctionne en mode de refus strict pour les requêtes non autorisées jusqu'au lancement du plan Business. - Aucune métrique de performance non vérifiée : Les délais de révocation et de requête sont des propriétés opérationnelles d'exécution et non des garanties numériques fixes. ## Utilisateur de ChatGPT Donnez à ChatGPT un accès durable à vos préférences XMemo, faits de projet, décisions et TODOs sans coller de jetons bearer dans un chat. Connectez le serveur MCP XMemo hébergé via le flux OAuth de l'application ChatGPT/OpenAI, puis approuvez les autorisations memory:read et memory:write pour votre compte XMemo. Enregistrez une préférence synthétique ou une note de projet, démarrez un nouveau chat, puis demandez à ChatGPT de la rappeler via XMemo avant de poursuivre le travail. Si OAuth échoue ou si les outils n'apparaissent pas, déconnectez-vous du serveur MCP dans l'application hôte, reconnectez l'URL du serveur XMemo et réessayez avant de créer des jetons directs. ## Développeur Copilot / Codex Transmettez les décisions du dépôt, les conventions de codage, les notes de correctifs et l'historique des tâches entre les agents IDE et CLI. Utilisez OAuth pour VS Code / GitHub Copilot et Gemini CLI lorsqu'il est disponible. Pour Copilot CLI, Codex, Cursor ou d'autres clients MCP directs, conservez XMEMO_KEY dans l'environnement local ou le gestionnaire de secrets et définissez un identifiant XMEMO_AGENT_INSTANCE_ID stable. Enregistrez une décision relative au code ou un correctif, puis demandez au prochain agent de l'IDE ou de la CLI de rappeler le contexte XMemo pertinent avant toute modification. Si les rappels sont vides, vérifiez le chemin de configuration MCP sélectionné, la variable d'environnement XMEMO_KEY pour les clients directs et tout identifiant OAuth obsolète dans l'application hôte. ## Responsable de projet pilote d'équipe / entreprise Évaluez la mémoire partagée avec les contrôles de compte, l'attribution des sources, les flux d'exportation/suppression et des preuves de configuration sécurisées pour les évaluateurs. Créez ou rejoignez l'espace de travail sécurisé XMemo, invitez les utilisateurs approuvés, puis connectez chaque client via OAuth ou un identifiant direct délimité selon les badges de disponibilité. Demandez à un membre du projet pilote d'enregistrer une mémoire d'équipe synthétique, confirmez l'attribution de la source dans XMemo, puis examinez les chemins de suppression/exportation et de support. Si un membre ne parvient pas à se connecter, vérifiez les permissions de rôle, l'approbation OAuth, l'état de disponibilité du client et les conseils du support avant d'émettre un nouveau jeton. ## Opérateur d'agents autonomes Permettez aux agents autonomes ou planifiés d'enregistrer leur progression, de récupérer les décisions antérieures et de conserver une identité d'instance stable et non secrète. Récupérez /api/v1/mcp/config/autonomous-agent. Privilégiez auth_modes.oauth lorsque l'exécuteur prend en charge OAuth + en-têtes personnalisés ; utilisez auth_modes.xmemo_key avec XMEMO_KEY issu d'un gestionnaire de secrets uniquement pour les exécuteurs entièrement autonomes. Exécutez une tâche synthétique qui consigne la progression dans XMemo, redémarrez l'exécuteur et confirmez qu'il rappelle cette progression à l'aide du même XMEMO_AGENT_INSTANCE_ID. Si l'attribution change ou si les rappels se scindent entre instances, conservez XMEMO_AGENT_INSTANCE_ID hors de git et vérifiez que l'exécuteur ne le régénère pas à chaque démarrage.