Gérer les offres Cursor Teams
Gérer Cursor pour une équipe change votre façon d'appréhender le produit : au lieu d'une seule personne gérant un abonnement unique, un administrateur gère un pool de sièges, un budget d'utilisation partagé et un ensemble de politiques qui s'appliquent à chaque développeur. Ce guide parcourt l'administration quotidienne d'une offre Cursor Teams, notamment l'ajout et le retrait de sièges, l'attribution des rôles, la montée des sièges vers des paliers supérieurs, la configuration du SSO, la lecture des tableaux de bord d'utilisation et le traitement des problèmes de facturation les plus fréquents.
Vue d'ensemble de l'offre Teams
Un abonnement Teams est facturé au siège, mensuellement ou annuellement, et s'administre depuis le tableau de bord web plutôt que depuis l'éditeur. Chaque siège inclut une allocation d'utilisation, et les dépenses liées à l'usage de l'équipe sont mutualisées et contrôlées de manière centralisée afin que les administrateurs puissent voir où va le budget.
| Aspect | Fonctionnement sur Teams |
|---|---|
| Modèle de tarification | Par siège et par mois, avec options de facturation annuelle |
| Utilisation | Chaque siège inclut une allocation ; les dépenses liées à l'usage sont mutualisées au niveau de l'équipe |
| Administration | Tableau de bord web pour les sièges, les rôles, la facturation et l'utilisation |
| Rôles | Admin et membre ; les admins gèrent les sièges, la facturation et les politiques |
| Confidentialité | Le mode confidentialité à l'échelle de l'équipe peut être imposé par un admin |
| SSO | Authentification unique SAML pour le domaine de messagerie de l'équipe |
| Support | Canaux de support prioritaires pour les questions de facturation et de compte |
Fonctionnement du pool d'utilisation partagé
Sur une offre Teams, il y a deux niveaux d'utilisation à comprendre :
- Allocation par siège. Chaque siège inclut une allocation de base d'utilisation des modèles, renouvelée à chaque cycle de facturation. Un développeur qui reste dans les limites de son allocation ne génère pas de frais supplémentaires.
- Budget partagé basé sur l'usage. Lorsqu'un membre dépasse l'allocation de son siège, l'utilisation supplémentaire est facturée sur le budget partagé de l'équipe, aux tarifs basés sur l'usage. Les admins peuvent définir des plafonds de dépenses et recevoir des notifications à mesure que le pool est consommé.
Cette conception signifie qu'un utilisateur d'agent intensif ne peut pas faire exploser silencieusement sa propre facture, mais qu'il peut ponctionner le pool partagé. Traitez le budget partagé comme une ressource d'équipe que vous surveillez comme toute autre dépense cloud.
Les allocations de chaque siège sont renouvelées à chaque cycle, mais les dépenses basées sur l'usage puisent dans le pool partagé. Consultez la vue d'utilisation au niveau de l'équipe avant de lancer des charges de travail d'agent longues et coûteuses en fin de période de facturation.
Ajouter et retirer des sièges
Toutes les opérations sur les sièges se déroulent dans le tableau de bord d'administration, sous la section équipe ou membres. Vous devez être connecté avec un compte disposant du rôle admin.
Ajouter un siège
- Connectez-vous sur cursor.com et ouvrez le tableau de bord de l'équipe avec votre compte admin.
- Rendez-vous dans la section membres ou sièges et choisissez l'option d'invitation.
- Saisissez l'adresse e-mail professionnelle du développeur et envoyez l'invitation.
- Le siège est réservé dès l'envoi de l'invitation (ou dès son acceptation, selon la configuration de votre offre), et tout frais en cours de cycle est calculé au prorata.
- Le développeur accepte l'invitation et se connecte avec cette adresse e-mail pour prendre possession du siège.
Retirer un siège
- Ouvrez la liste des membres dans le tableau de bord.
- Trouvez le membre qui part et retirez son appartenance.
- Si vous voulez aussi cesser de payer ce siège, retirez le siège lui-même dans la section facturation. Supprimer une appartenance sans libérer le siège est la cause la plus fréquente de paiement pour des personnes parties.
- L'accès se termine immédiatement ou à la fin du cycle en cours, selon l'option choisie.
| Action | Facturé comme | Fin de l'accès |
|---|---|---|
| Ajout d'un siège en cours de cycle | Au prorata du reste | Immédiatement à l'acceptation |
| Retrait de l'appartenance uniquement | Le siège continue d'être facturé | Dépend de la libération du siège |
| Retrait du siège | S'arrête au prochain renouvellement ou au prorata, selon les conditions de l'offre | Selon l'option choisie |
Rôles : admins et membres
Les offres Teams comportent deux rôles intégrés. La personne qui a créé l'équipe est admin par défaut.
| Capacité | Admin | Membre |
|---|---|---|
| Inviter et retirer des membres | Oui | Non |
| Ajouter ou libérer des sièges | Oui | Non |
| Consulter et modifier la facturation | Oui | Non |
| Configurer le SSO | Oui | Non |
| Imposer le mode confidentialité de l'équipe | Oui | Non |
| Consulter les tableaux de bord d'utilisation de l'équipe | Oui | Généralement limité à sa propre utilisation |
| Utiliser toutes les fonctionnalités de l'IDE | Oui | Oui |
Choisir qui devient admin
Gardez le rôle admin restreint : généralement le responsable ingénierie qui gère le budget et un suppléant. Les admins peuvent modifier la facturation, donc chaque admin supplémentaire est une personne de plus susceptible d'ajouter accidentellement des sièges ou de changer le moyen de paiement. Promouvez un membre depuis la liste des membres du tableau de bord ; le changement prend effet à sa prochaine connexion.
Faire évoluer un siège vers un palier supérieur
Au-delà du siège standard, Cursor propose des paliers supérieurs (par exemple Ultra, et dans certains contextes de facturation un palier de tête appelé Super) qui augmentent l'utilisation incluse et débloquent les modèles les plus performants ainsi que les fonctionnalités d'agent longue durée. Sur une offre Teams, ces évolutions se gèrent par siège et sont administrées par un admin, et non par le membre individuel.
Comment faire évoluer un siège
- Ouvrez le tableau de bord de l'équipe et localisez le membre dont vous souhaitez faire évoluer le siège.
- Ouvrez les options de siège ou d'abonnement de ce membre.
- Choisissez le palier supérieur et confirmez. Les frais sont soit calculés au prorata immédiatement, soit appliqués au prochain renouvellement, selon l'option de facturation affichée lors du paiement.
- Demandez au membre de se déconnecter puis de se reconnecter à l'IDE afin que les nouvelles limites apparaissent dans son panneau de compte.
Problèmes de facturation fréquents après une évolution
- Confusion sur le prorata. Une évolution en cours de cycle génère une ligne au prorata ponctuelle sur la prochaine facture, en plus du renouvellement habituel. C'est normal, il ne s'agit pas d'un doublon.
- Évolution appliquée au mauvais siège. Les listes de sièges s'allongent avec le temps et contiennent souvent des entrées obsolètes. Vérifiez l'adresse e-mail du siège avant de confirmer l'évolution.
- Limites non visibles immédiatement. Les changements de palier peuvent prendre effet au cycle suivant. Le panneau de compte de l'IDE du membre indique quelles limites sont actuellement actives.
- Échec de paiement. Si la carte de l'équipe est refusée, l'évolution peut échouer silencieusement. Consultez l'historique de facturation à la recherche d'une transaction échouée avant de réessayer.
Selon la configuration de facturation de votre équipe, une évolution de siège peut prendre effet immédiatement avec des frais au prorata, ou au début de la période de facturation suivante. Si les limites du nouveau palier ne sont pas visibles tout de suite, vérifiez la date du cycle de facturation avant de conclure que l'évolution a échoué.
Bases de la configuration du SSO
L'authentification unique SAML lie chaque siège à votre fournisseur d'identité, de sorte que l'arrivée et le départ de l'entreprise contrôlent automatiquement qui peut utiliser Cursor. La configuration se fait depuis les paramètres de sécurité du tableau de bord d'administration.
- Dans le tableau de bord, ouvrez les paramètres de sécurité ou d'authentification.
- Choisissez SAML SSO et copiez les détails du fournisseur de service que Cursor vous fournit (entity ID et ACS URL).
- Dans votre fournisseur d'identité (Okta, Entra ID, Google Workspace et similaires), créez une nouvelle application SAML avec ces valeurs.
- Collez l'URL ou le XML des métadonnées de votre fournisseur d'identité dans le tableau de bord Cursor.
- Affectez d'abord l'application à un groupe de test, vérifiez la connexion, puis déployez-la à toute l'équipe.
<!-- Example SAML attribute mapping most identity providers accept -->
<Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
</Attribute>
L'attribut email doit correspondre à l'e-mail du siège du membre. Si les utilisateurs SSO ne peuvent pas se connecter, la discordance entre l'e-mail du fournisseur d'identité et celui du siège est la première chose à vérifier.
Activez le SSO pour un admin et un membre avant de l'imposer à toute l'équipe. Si le mappage des attributs est erroné, vous pouvez bloquer tout le monde, alors validez avec des comptes auxquels vous pouvez encore accéder par mot de passe.
Tableaux de bord d'utilisation et mode confidentialité
Lire le tableau de bord d'utilisation
La section utilisation du tableau de bord de l'équipe affiche, pour le cycle en cours :
- L'utilisation totale de l'équipe par rapport au pool partagé, avec les plafonds de dépenses que vous avez configurés.
- La répartition par membre montrant la consommation de requêtes et de tokens, afin d'identifier les utilisateurs intensifs avant l'épuisement du pool.
- La distribution des modèles, qui vous indique si des modèles à long contexte coûteux dominent vos dépenses.
- Les courbes de tendance sur plusieurs cycles, utiles pour prévoir si le palier actuel convient encore à l'équipe.
Imposer le mode confidentialité pour l'équipe
Le mode confidentialité empêche votre code d'être stocké sur les serveurs Cursor au-delà de ce qui est nécessaire pour traiter la requête. Sur les offres Teams, un admin peut imposer le mode confidentialité à tout le monde, ce qui retire aux membres individuels la possibilité de le désactiver.
- Ouvrez les paramètres de confidentialité dans le tableau de bord d'administration.
- Activez l'imposition pour toute l'équipe.
- Vérifiez dans l'IDE : les membres doivent voir le mode confidentialité indiqué comme imposé et grisé dans leurs paramètres.
Pour les équipes traitant des données clients ou du code réglementé, imposez le mode confidentialité au niveau de l'équipe plutôt que de faire confiance aux paramètres individuels. Notez que les fonctionnalités d'agent qui s'exécutent dans le cloud ont leurs propres conditions de traitement des données, examinez-les séparément si cela compte pour votre conformité.
Gérer les moyens de paiement et les factures
Mettre à jour les coordonnées de paiement
Ouvrez la section facturation du tableau de bord pour changer la carte enregistrée, mettre à jour l'e-mail de facturation ou modifier le nom de l'entreprise et les informations fiscales qui figurent sur les factures. Les changements s'appliquent à la prochaine facture ; les factures déjà émises conservent les informations avec lesquelles elles ont été générées.
Rapprocher les factures
Les factures listent les frais par siège et tout dépassement basé sur l'usage sur des lignes distinctes. Lorsque les chiffres ne correspondent pas à votre représentation de l'équipe, exportez la facture et votre liste de membres actuelle puis comparez-les :
# reconcile.py - compare an exported invoice CSV against the active members CSV
import csv
def load_rows(path):
with open(path, newline="", encoding="utf-8") as f:
return list(csv.DictReader(f))
invoice = load_rows("invoice.csv") # columns: email, line_type, amount
members = load_rows("members.csv") # columns: email, role, status
billed = {r["email"] for r in invoice if r["line_type"] == "seat"}
active = {m["email"] for m in members if m["status"] == "active"}
print("Billed but not active:", sorted(billed - active))
print("Active but not billed:", sorted(active - billed))
total = sum(float(r["amount"]) for r in invoice if r["line_type"] != "tax")
print(f"Invoice total excluding tax: {total:.2f}")
Tout ce qui figure dans la liste « facturé mais non actif » est un siège obsolète : libérez-le pour qu'il cesse d'être renouvelé.
Dépanner les problèmes courants
L'évolution de siège ne s'applique pas
Parcourez cette liste de vérification avant de contacter le support :
- Confirmez que l'évolution a été achetée depuis le compte admin, et non depuis un compte membre.
- Vérifiez l'historique de facturation à la recherche d'une transaction terminée (et non échouée).
- Vérifiez si les conditions de l'offre indiquent que l'évolution prend effet au cycle suivant.
- Demandez au membre de se déconnecter complètement de l'IDE puis de se reconnecter ; des identifiants en cache peuvent afficher des limites obsolètes.
- Vérifiez que l'évolution a porté sur le siège avec la bonne adresse e-mail.
Si tout ce qui précède est correct et que le palier affiche toujours standard, écrivez à [email protected] avec le nom de l'équipe, l'e-mail du siège et l'ID de la facture de l'évolution.
Un siège d'équipe ne peut pas être évolué vers Super
Certaines configurations Teams n'exposent pas le palier de tête comme une évolution par siège en libre-service, ou l'option apparaît mais échoue au paiement. En pratique :
- Assurez-vous que le propriétaire de la facturation (l'admin qui a configuré les paiements) effectue l'évolution, car les changements de palier par siège sont liés au moyen de paiement.
- Essayez l'évolution depuis la section facturation plutôt que depuis la liste des membres, ou l'inverse ; l'option se trouve à des endroits différents selon la version de l'offre.
- Si le paiement échoue de manière répétée, contactez le support ou le service commercial et demandez que le changement de palier du siège soit appliqué manuellement. Indiquez l'e-mail du siège et le palier souhaité.
- Comme contournement, certaines équipes font tourner ce seul utilisateur intensif sur un abonnement individuel de palier supérieur et gardent le reste de l'équipe sur l'offre Teams. Ce n'est pas élégant, mais cela débloque le développeur pendant que la facturation est réglée.
Doublons de facturation
Causes et correctifs fréquents :
| Cause | Comment confirmer | Correctif |
|---|---|---|
| Nouvelle tentative de paiement après un délai d'attente | Deux transactions, dont une marquée en attente ou échouée | La transaction en attente se résorbe généralement automatiquement ; si les deux aboutissent, contactez le support |
| Abonnements individuel et d'équipe sur un même e-mail | L'historique de facturation montre deux produits | Résiliez l'offre individuelle ou demandez au support de consolider |
| Siège ajouté deux fois dans un même cycle | Deux lignes de siège au prorata pour le même e-mail | Libérez le siège en trop ; le support peut rembourser le chevauchement |
| Carte enregistrée deux fois par une erreur de saisie automatique du navigateur | Deux moyens de paiement, tous deux débités | Supprimez un moyen et demandez le remboursement du mauvais |
Ouvrez toujours un ticket de support avec les ID de facture et les horodatages des transactions. Les remboursements pour de véritables doublons sont courants, mais ils nécessitent l'identification des frais concernés.
Un membre retiré consomme toujours un siège
Cela signifie presque toujours que l'appartenance a été retirée mais que le siège lui-même n'a pas été libéré, ou qu'une affectation de groupe SSO a immédiatement reprovisionné l'utilisateur. Pour corriger cela :
- Dans le tableau de bord, vérifiez si la personne apparaît comme membre inactif ou en attente. Les invitations en attente réservent des sièges.
- Annulez toute invitation en attente, puis libérez le siège dans la section facturation.
- Si le SSO recrée automatiquement l'appartenance, retirez l'utilisateur du groupe d'application Cursor dans votre fournisseur d'identité.
- Relancez votre rapprochement de sièges par rapport à la facture pour confirmer que le siège n'est plus renouvelé.
# Quick audit: list seats from the exported members CSV where last_active is over 30 days old
import csv
from datetime import datetime, timedelta
with open("members.csv", newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
last = datetime.strptime(row["last_active"], "%Y-%m-%d")
if datetime.now() - last > timedelta(days=30):
print("candidate for seat release:", row["email"])
L'utilisation ne se réinitialise pas chaque semaine
Le malentendu le plus courant sur les offres Teams concerne le calendrier de réinitialisation. En règle générale :
- Les allocations de siège sont renouvelées au cycle de facturation, qui est mensuel sauf choix contraire à l'inscription. Il n'y a pas de réinitialisation hebdomadaire de l'allocation principale.
- Les budgets partagés basés sur l'usage sont suivis par période de facturation, et la ponction du pool que vous voyez dans le tableau de bord ne reflète que la période en cours.
- Certaines fonctionnalités ont leurs propres fenêtres. Certaines fonctionnalités d'agent et de prévisualisation ont des limites glissantes plus courtes, indépendantes du cycle de facturation, ce qui explique pourquoi deux chiffres du tableau de bord peuvent se réinitialiser à des moments différents.
Si votre pool semble ne pas se réinitialiser après le passage manifeste de la date de renouvellement, vérifiez l'ancrage de facturation : la réinitialisation suit la date d'abonnement d'origine, et non le mois calendaire, et un changement de siège en cours de cycle peut décaler ce que vous attendez. Lorsque le tableau de bord reste figé plus d'un jour après le renouvellement, contactez le support avec le nom de votre équipe et l'ID de la dernière facture.
Désignez un admin comme interlocuteur unique pour la facturation, gardez le moyen de paiement sur une carte d'entreprise et rapprochez la facture de la liste des membres à chaque cycle. Presque tous les problèmes de facturation Teams de ce guide deviennent une correction de cinq minutes lorsque quelqu'un surveille réellement la facture.
Référence rapide
| Tâche | Où | Remarques |
|---|---|---|
| Ajouter un siège | Tableau de bord, section membres | Au prorata en cours de cycle |
| Libérer un siège | Tableau de bord, section facturation | Le retrait de l'appartenance seul n'arrête pas la facturation |
| Faire évoluer le palier d'un siège | Tableau de bord, options de siège ou de facturation | Admin uniquement ; peut s'appliquer au cycle suivant |
| Imposer le mode confidentialité | Tableau de bord, paramètres de confidentialité | À l'échelle de l'équipe, les membres ne peuvent pas le désactiver |
| Configurer le SSO | Tableau de bord, paramètres de sécurité | Testez d'abord avec deux comptes |
| Lire l'utilisation | Tableau de bord, section utilisation | Vue du pool plus répartition par membre |
| Litiges de facturation | [email protected] | Incluez les ID de facture et les horodatages |
Comprendre l'attribution des sièges et les attestations de facturation
Un siège est une licence attribuée à une personne nommée, donc votre facture suit le nombre de sièges attribués, et non le nombre d'installations. Les sièges relèvent de quatre états : attribué à un membre, réservé par une invitation en attente, libéré et non facturé, et facturable lorsque attribué plus réservé est comptabilisé au moment de la facturation. Une invitation en attente réserve le siège avant que le développeur l'accepte, c'est pourquoi les invitations abandonnées gonflent discrètement la prochaine facture.
Changements de siège en cours de cycle et prorata
L'ajout ou la libération d'un siège en cours de cycle est calculé au prorata sur les jours restants de ce cycle. Un ajout au prorata facture la fraction restante, tandis qu'une libération au prorata crédite les jours inutilisés (généralement sous forme de ligne négative plutôt que de remboursement), et le prochain renouvellement revient à la quantité totale que vous détenez désormais.
Bases de la facturation
Les factures sont générées au début de chaque cycle pour les sièges que vous détenez à ce moment-là, le dépassement du cycle précédent étant ajouté sur sa propre ligne. Les modifications en cours de cycle du nom de l'entreprise, de l'ID fiscal ou de l'e-mail de facturation ne s'appliquent qu'à la prochaine facture.
Une attestation de facturation (parfois appelée reçu) confirme qu'un paiement a été encaissé, tandis qu'une facture détaille ce qui a été facturé. La finance a souvent besoin des deux, donc téléchargez-les depuis la section facturation plutôt que de transférer l'e-mail de confirmation.
Configurer le SSO et la vérification de domaine
Le SSO lie chaque siège à votre fournisseur d'identité afin que l'arrivée ou le départ de l'entreprise contrôle automatiquement l'accès. Parcourez quatre étapes dans l'ordre.
Étape 1 — Vérifier votre domaine
Ajoutez l'enregistrement DNS TXT que Cursor vous fournit et attendez sa propagation avant de cliquer sur vérifier. Un enregistrement type ressemble à une entrée TXT _cursor-verification.example.com dont la valeur est cursor-domain-verification=8f3c1a90b7e44d2fa1c6, publiée dans votre hébergeur DNS.
Étape 2 — Configurer le fournisseur d'identité
Cursor parle SAML 2.0 et OIDC. Copiez les valeurs de fournisseur de service que Cursor vous fournit, créez l'application dans votre fournisseur et collez les métadonnées de votre fournisseur en retour (pour OIDC, les mêmes valeurs correspondent à un client ID, un secret, une redirect URI et une revendication email, qui doit correspondre à l'e-mail du siège) :
{
"protocol": "SAML",
"sp_entity_id": "https://cursor.com/saml/metadata",
"acs_url": "https://cursor.com/saml/acs",
"attribute_mapping": { "email": "user.email", "groups": "user.groups" },
"signature": "required"
}
Étape 3 — Mapper les attributs et provisionner les membres
Affectez l'application à un groupe pilote d'un admin et un membre, puis confirmez que l'attribut email correspond exactement à l'e-mail du siège avant d'élargir. Les fournisseurs qui prennent en charge le provisionnement SCIM créent et retirent les membres automatiquement, de sorte que Cursor devient la source de vérité pour les sièges.
Étape 4 — Imposer le SSO à tout le monde
- Confirmez qu'au moins deux admins peuvent se connecter via le SSO, et pas uniquement par mot de passe, et qu'un chemin de récupération existe si l'application se comporte mal.
- Activez l'imposition, puis faites tester une nouvelle connexion à un membre.
Une fois le SSO imposé, un mappage d'attributs défectueux ou une application en échec dans votre fournisseur d'identité bloque toute l'équipe, vous y compris. Gardez au moins un admin capable d'atteindre le tableau de bord de facturation, vérifiez le mappage avec deux comptes pilotes au préalable et vérifiez séparément le compte admin de votre fournisseur d'identité avant d'imposer.
Référence des rôles et permissions
Cursor Teams est livré avec un rôle admin, un rôle membre et, sur certaines offres, un rôle facturation uniquement pour le personnel financier. Utilisez le rôle le plus restreint qui fait encore le travail, et limitez le rôle admin au propriétaire du budget plus un suppléant, car chaque admin supplémentaire peut modifier la facturation. L'accès facturation uniquement ne peut pas ajouter de sièges ni modifier l'accès des membres, ce qui correspond au moindre privilège dont la finance a réellement besoin.
| Capacité | Admin | Facturation uniquement | Membre |
|---|---|---|---|
| Inviter et retirer des membres | Oui | Non | Non |
| Ajouter ou libérer des sièges | Oui | Non | Non |
| Changer le palier d'un siège | Oui | Non | Non |
| Mettre à jour le moyen de paiement | Oui | Oui | Non |
| Configurer le SSO et la vérification de domaine | Oui | Non | Non |
| Imposer le mode confidentialité de l'équipe | Oui | Non | Non |
| Consulter les tableaux de bord d'utilisation de l'équipe | Oui | Lecture seule | Sa propre utilisation |
| Utiliser les fonctionnalités de l'éditeur et de l'agent | Oui | Pas de siège | Oui |
Les changements de rôle s'appliquent à la prochaine connexion de la personne concernée, donc demandez-lui de se déconnecter puis de se reconnecter plutôt que de supposer que le changement a échoué.
Analyse et reporting de l'utilisation
Métriques du tableau de bord
| Métrique | Ce qu'elle vous indique | Action typique |
|---|---|---|
| Tokens et requêtes de l'équipe | Consommation totale par rapport au pool partagé | Comparez au budget |
| Répartition par membre | Qui ponctionne le pool le plus vite | Accompagnez ou faites évoluer les utilisateurs intensifs |
| Dépenses par rapport au plafond | Marge avant le plafond souple ou strict | Ajustez le plafond |
Exporter l'utilisation et agréger par membre
L'export est un fichier ligne par ligne, peu pratique à lire à l'échelle d'une équipe, donc agrégez-le localement avec un pipeline awk (ou l'équivalent jq -r '.members[] | [.email, .tokens] | @csv' usage.json lorsqu'il s'agit de JSON) :
# Export the cycle, then rank members by token consumption
curl -s -H "Authorization: Bearer $CURSOR_ADMIN_TOKEN" \
"https://api.cursor.com/teams/usage/export?cycle=2026-09" -o usage.csv
awk -F, 'NR>1 {tok[$1]+=$4} END {for (u in tok) printf "%s,%d\n", u, tok[u]}' usage.csv \
| sort -t, -k2 -nr | head -20
Définir des alertes souples
Les alertes souples vous avertissent avant l'épuisement du pool partagé sans bloquer personne. Définissez-en une à environ 70 pour cent et une autre à environ 90 pour cent (une configuration telle que alerts: {soft: [70, 90], hard_cap: 100}), envoyez-les vers un canal que l'équipe consulte, et gardez le plafond strict au-dessus des deux pour qu'une alerte précède toujours un verrouillage.
Imposer le mode confidentialité pour une équipe
Le mode confidentialité empêche votre code d'être stocké sur les serveurs Cursor au-delà de ce qui est nécessaire pour traiter la requête. Un admin peut l'imposer à toute l'organisation, ce qui retire à chaque membre la possibilité de le désactiver.
- Ouvrez les paramètres de confidentialité dans le tableau de bord d'administration.
- Activez l'imposition pour tous les membres de l'équipe, puis enregistrez et confirmez que le tableau de bord l'indique comme imposé.
L'imposition grise la bascule du membre dans l'éditeur, empêche que les requêtes soient conservées pour l'entraînement dans le cadre de la politique de l'équipe et laisse les fonctionnalités d'agent cloud sur leurs propres conditions de traitement des données. Vérifiez-la à trois endroits plutôt que de vous fier à un seul : le tableau de bord, l'état imposé dans les paramètres d'un membre et votre vue des politiques d'administration.
Imposer le mode confidentialité définit la manière dont les requêtes de votre équipe sont traitées ; cela ne remplace pas votre propre examen de conservation des données. Documentez où le paramètre est imposé et qui en est responsable afin qu'un auditeur puisse tracer le contrôle.
Automatiser les audits de sièges
Transformez le rapprochement manuel en un audit planifié qui signale les sièges inactifs et affiche ce qu'il retirerait, afin qu'un humain approuve chaque changement.
# seat-audit.sh -- flag seats with no activity for more than N days
#!/usr/bin/env bash
set -euo pipefail
CSV="${1:-members.csv}"; STALE="${2:-30}"; NOW=$(date +%s)
awk -F, -v s="$STALE" -v n="$NOW" 'NR>1 {
split($4, d, "-")
age = int((n - mktime(d[1]" "d[2]" "d[3]" 00 00 00")) / 86400)
if (age > s && $3 == "active") printf "%s,%s,%d days,REVIEW\n", $1, $2, age
}' "$CSV"
Injectez cette sortie dans un workflow de suppression en simulation qui n'agit qu'avec un indicateur explicite :
# remove-seats.sh -- dry run unless --apply is passed
MODE="dry-run"; [[ "${2:-}" == "--apply" ]] && MODE="apply"
while IFS=, read -r email role age action; do
[[ "$MODE" == "dry-run" ]] \
&& echo "would release: $email (inactive $age)" \
|| curl -s -X DELETE -H "Authorization: Bearer $CURSOR_ADMIN_TOKEN" \
"https://api.cursor.com/teams/seats?email=$email"
done < <(./seat-audit.sh "$1")
Lancez la simulation chaque semaine, examinez la sortie, puis appliquez les retraits. Ignorez tout siège réservé par une invitation en attente afin de ne jamais couper l'accès à une recrue active.
Automatisez l'audit et laissez la suppression derrière un indicateur manuel. Une tâche qui à la fois audite et supprime finira par retirer un siège pendant des vacances avant que quiconque remarque la perte d'accès.
Renouvellement, résiliation et rétrogradations
Au renouvellement, l'offre se réattribue à la quantité que vous détenez, renouvelle l'allocation partagée et facture le dépassement du cycle précédent, donc rapprochez les membres de la facture une semaine avant la date. La rétrogradation reflète la montée : libérez les sièges des personnes parties, supprimez les paliers inutiles, réduisez la quantité de sièges dans la facturation et confirmez le nouveau nombre sur la prochaine facture, généralement effective au cycle suivant.
| Changement | Les membres conservent | Les membres perdent |
|---|---|---|
| Remplacer un membre | Les membres restants sont inchangés | Le siège et l'accès du membre retiré |
| Rétrograder le palier d'un siège | Fonctionnalités de base de l'éditeur | Utilisation incluse supérieure et modèles de tête |
| Réduire la quantité de sièges | Les sièges jusqu'au nouveau nombre | Les sièges au-delà du nouveau nombre sont libérés |
| Résilier l'offre | L'accès jusqu'à la fin du cycle payé | Le tableau de bord d'équipe, le SSO et le pool partagé |
Résilier une offre d'équipe ne rembourse pas le cycle en cours ; l'accès court jusqu'à la fin de la période déjà payée puis s'arrête. Recréer l'équipe plus tard implique de reconfigurer les sièges, le SSO et la confidentialité, donc exportez votre liste de membres et vos factures avant de résilier.
Questions fréquentes
Les sièges sont-ils facturés par personne ou par installation ?
Par personne. Un siège couvre un membre nommé, quel que soit le nombre de machines. Partager une seule connexion économise un siège mais ne peut pas être audité par personne, donc évitez-le.
Que se passe-t-il si j'ajoute un siège et en retire un autre dans le même cycle ?
Les deux sont calculés au prorata sur les jours restants et s'annulent souvent en une légère variation nette. Recherchez une ligne d'ajout et une ligne de libération correspondantes avant de supposer que vous avez été facturé deux fois.
Un membre peut-il faire évoluer son propre siège ?
Non. Les changements de palier de siège sont effectués par un admin depuis le tableau de bord d'équipe sur le moyen de paiement de l'équipe.
Pourquoi le pool ne se réinitialise-t-il pas le premier du mois ?
Le pool suit votre ancrage de facturation, la date à laquelle vous vous êtes abonné à l'origine, et non le mois calendaire. Vérifiez la date de début du cycle sur la dernière facture avant de considérer un tableau de bord figé comme un bug.
Que faire si le SSO bloque tout le monde ?
Gardez un chemin de récupération avant d'imposer. Si cela tourne mal, corrigez le mappage ou l'application dans votre fournisseur d'identité et réactivez la connexion plutôt que de désactiver entièrement le SSO.
La finance peut-elle payer la facture sans siège ?
Oui, sur les offres qui proposent un rôle facturation uniquement. Il accorde l'accès au paiement et aux factures sans administration des sièges ou des membres, soit le moindre privilège dont la finance a réellement besoin.