doc-locale/fr-fr/subscriptions/manage_seats.md
{{< details >}}
{{< /details >}}
La gestion des sièges est le processus de contrôle et de surveillance des utilisateurs qui occupent des sièges dans votre abonnement. Une gestion efficace des sièges vous aide à maîtriser les coûts, à éviter les frais de dépassement imprévus et à garantir que les membres de votre équipe disposent des accès nécessaires.
Les utilisateurs facturables sont les utilisateurs qui occupent des sièges dans un abonnement et sont comptabilisés dans le nombre de sièges achetés dans votre abonnement.
Les utilisateurs suivants sont comptés comme facturables :
read_codeLe nombre d'utilisateurs facturables change lorsque vous bloquez, désactivez ou ajoutez des utilisateurs à votre instance ou groupe pendant la période d'abonnement en cours. Si un utilisateur appartient à plusieurs groupes ou projets qui relèvent du même groupe principal qui détient l'abonnement, il n'est comptabilisé qu'une seule fois.
L'utilisation des sièges est examinée trimestriellement ou annuellement.
Pour éviter les frais de dépassement liés à des ajouts d'utilisateurs non intentionnels, vous devriez :
Un utilisateur n'est pas comptabilisé comme utilisateur facturable si :
Lorsque le nombre d'utilisateurs facturables dans votre instance ou votre groupe principal dépasse le nombre de sièges achetés, vous avez des utilisateurs en dépassement d'abonnement (ou des sièges dus).
Cela peut se produire, par exemple, lorsque de nouveaux utilisateurs sont ajoutés à votre instance ou groupe, ou lorsque des utilisateurs existants sont promus à des rôles facturables.
Le nombre d'utilisateurs en dépassement d'abonnement est calculé comme suit : nombre maximum d'utilisateurs pendant la période de facturation - sièges achetés dans votre abonnement.
Par exemple, vous achetez un abonnement pour 10 sièges et, pendant la période de facturation, le nombre d'utilisateurs varie comme suit :
| Événement | Utilisateurs facturables | Nombre maximum d'utilisateurs |
|---|---|---|
| Dix utilisateurs occupent les 10 sièges. | 10 | 10 |
| Deux nouveaux utilisateurs rejoignent. | 12 | 12 |
| Trois utilisateurs partent et leurs comptes sont bloqués. | 9 | 12 |
| Quatre nouveaux utilisateurs rejoignent. | 13 | 13 |
Dans ce cas, vous avez 3 utilisateurs en dépassement d'abonnement (13 utilisateurs maximum - 10 sièges achetés).
Lorsque vous dépassez votre limite d'abonnement, vous devez payer pour les utilisateurs supplémentaires avant ou au moment du renouvellement. Le coût est basé sur le nombre maximum d'utilisateurs pendant la période de facturation, et non sur le nombre d'utilisateurs actuel.
Sur GitLab Self-Managed, pour les licences d'essai, la valeur des utilisateurs en dépassement d'abonnement est toujours zéro.
Pour éviter des frais de dépassement imprévus, vous pouvez :
{{< details >}}
{{< /details >}}
Dans l'édition GitLab Ultimate, les utilisateurs auxquels le rôle Invité est attribué ne consomment pas de siège. L'utilisateur ne doit se voir attribuer aucun autre rôle, où que ce soit dans l'instance pour GitLab Self-Managed ou dans l'espace de nommage pour GitLab.com.
Sur GitLab Self-Managed avec l'édition GitLab Premium, si un utilisateur Invité dispose d'un rôle plus élevé dans un projet ou un groupe (y compris son espace de nommage personnel), lorsque vous passez à l'édition GitLab Ultimate, ce rôle plus élevé prend la priorité et l'utilisateur consommera un siège. Pour vous assurer que les utilisateurs Invités sur GitLab Self-Managed Ultimate ne consommeront pas de siège, vérifiez qu'ils n'ont aucune autre attribution de rôle dans l'instance ou l'espace de nommage avant de procéder à la mise à niveau.
[!note] Sur GitLab Self-Managed, si un utilisateur crée un projet, il se voit attribuer le rôle Maintainer ou Owner. Pour empêcher un utilisateur de créer des projets, en tant qu'administrateur, vous pouvez marquer l'utilisateur comme externe.
Les contrôles des sièges vous aident à gérer la façon dont les utilisateurs sont ajoutés à votre abonnement et à éviter les frais de dépassement imprévus. Les contrôles des sièges s'appliquent à l'instance sur GitLab Self-Managed et au groupe principal sur GitLab.com.
{{< history >}}
saas_user_caps.{{< /history >}}
Le plafond d'utilisateurs est le nombre maximum d'utilisateurs facturables pouvant être ajoutés à un groupe principal sur GitLab.com, ou créer des comptes sur GitLab Self-Managed. Une fois le plafond d'utilisateurs atteint, un Owner de groupe ou un administrateur doit approuver les utilisateurs à ajouter à un groupe principal ou à créer des comptes. Une fois les utilisateurs approuvés, ils peuvent accéder au groupe ou à l'instance. Si un Owner de groupe ou un administrateur augmente ou supprime le plafond d'utilisateurs, les utilisateurs en attente d'approbation sont automatiquement approuvés.
Vous pouvez définir un plafond d'utilisateurs pour un groupe principal et pour une instance.
[!note] Sur GitLab.com, le plafond d'utilisateurs ne peut pas être activé si un groupe, sous-groupe ou projet au sein du groupe principal est partagé en dehors de cette hiérarchie d'espace de nommage. Lorsque le plafond d'utilisateurs est activé, l'invitation de groupes en dehors de la hiérarchie de groupes est automatiquement bloquée et ne peut pas être désactivée. L'invitation de groupes au sein du groupe et de ses sous-groupes n'est pas affectée.
Le nombre d'utilisateurs facturables est mis à jour une fois par jour. Le plafond d'utilisateurs peut ne prendre effet qu'après avoir déjà été dépassé. Si le plafond est défini à une valeur inférieure au nombre actuel d'utilisateurs facturables (par exemple, 1), le plafond est activé immédiatement.
[!note] Sur GitLab Self-Managed, pour les instances utilisant LDAP ou OmniAuth, lorsque l'approbation de l'administrateur pour les nouveaux comptes utilisateurs est activée ou désactivée, une interruption de service peut survenir en raison de modifications apportées à la configuration Rails. Vous pouvez définir un plafond d'utilisateurs pour appliquer les approbations pour les nouveaux utilisateurs.
Sur GitLab.com Ultimate, vous ne pouvez pas ajouter des utilisateurs Invités à un groupe lorsque les utilisateurs facturables dépassent le plafond d'utilisateurs. Par exemple, vous définissez le plafond d'utilisateurs à cinq lorsque vous avez trois Developers et deux utilisateurs Invités. Après avoir ajouté deux Developers supplémentaires, vous ne pouvez plus ajouter d'utilisateurs, même s'il s'agit d'utilisateurs Invités qui ne consomment pas de sièges facturables. Pour plus d'informations, consultez le ticket 441504.
{{< history >}}
auto_enable_restricted_access_on_self_managed. Activé par défaut. Activés par défaut.{{< /history >}}
L'accès restreint empêche l'ajout de nouveaux utilisateurs facturables lorsqu'il ne reste plus de sièges sous licence dans votre abonnement. L'activation de l'accès restreint sur un groupe ou une instance qui dépasse déjà sa limite de sièges ne modifie pas le rôle des membres existants, ne les bloque pas et ne les supprime pas ; elle empêche les nouveaux ajouts facturables tout en laissant les membres actuels intacts. Les utilisateurs qui n'ont pas besoin d'accéder aux projets ou aux groupes, comme ceux qui s'authentifient via GitLab en tant que fournisseur OIDC, peuvent se voir attribuer le rôle non facturable d'accès minimum pour ne pas être bloqués par les limites de sièges.
Vous pouvez définir l'accès restreint pour un groupe principal et pour une instance.
L'accès restreint est incompatible avec le partage de groupes externes. Lorsque vous activez l'accès restreint sur GitLab.com, le paramètre visant à empêcher l'invitation de groupes en dehors de la hiérarchie de groupes est automatiquement activé. Ce paramètre permet d'éviter les frais de dépassement causés par des utilisateurs facturables non intentionnels.
Vous pouvez toujours configurer indépendamment le partage de projet pour le groupe et ses sous-groupes selon vos besoins.
L'accès restreint et le plafond d'utilisateurs ne peuvent pas être utilisés simultanément. L'activation de l'accès restreint désactive le plafond d'utilisateurs.
Sur GitLab Self-Managed, GitLab active automatiquement l'accès restreint lorsque votre abonnement n'autorise pas les dépassements. Vous ne pouvez pas désactiver l'accès restreint lorsque votre abonnement n'autorise pas les dépassements.
{{< history >}}
bso_minimal_access_fallback. Désactivées par défaut.{{< /history >}}
Lorsque l'accès restreint est activé et qu'aucun siège d'abonnement n'est disponible, les utilisateurs provisionnés via SAML, SCIM ou LDAP se voient attribuer le rôle d'accès minimum au lieu de leur niveau d'accès configuré. Ce comportement garantit que la synchronisation peut se poursuivre sans consommer de sièges facturables sur GitLab.com et Self-Managed Ultimate.
Les utilisateurs avec le rôle d'accès minimum peuvent s'authentifier et accéder au groupe, mais disposent de permissions limitées. Lorsque des sièges deviennent disponibles, ils peuvent être promus à leur niveau d'accès prévu. Les utilisateurs existants avec des rôles facturables ne sont pas affectés par ce comportement.
Vous pouvez consulter l'utilisation des sièges et gérer les utilisateurs disposant d'un accès minimum.
Lorsque vous activez l'accès restreint, les problèmes connus suivants peuvent se produire et entraîner des dépassements :
De plus, l'accès restreint peut bloquer les flux standard sans dépassement :
Lorsque l'accès restreint est actif et qu'aucun siège sous licence n'est disponible, les utilisateurs dormants (y compris les utilisateurs d'entreprise) qui tentent de se reconnecter sont mis en attente d'approbation au lieu d'être réactivés. Leurs appartenances existantes aux groupes et projets sont conservées. Les membres dormants non-entreprise voient leur appartenance au groupe supprimée au lieu d'être désactivés. Lorsqu'ils rejoignent à nouveau via SAML, SCIM ou la synchronisation LDAP, le comportement de provisionnement s'applique et ils reçoivent le rôle d'accès minimum si aucun siège n'est disponible.
Un Owner de groupe ou un administrateur peut approuver les utilisateurs lorsque des sièges deviennent disponibles.
Les utilisateurs n'ayant que le rôle d'accès minimum sont réactivés directement, car ils ne consomment pas de siège facturable.
Vous pouvez supprimer automatiquement les membres dormants.
Après avoir activé l'accès restreint, il détermine si une invitation en attente peut être acceptée :
Sur GitLab.com, lorsque vous passez du plafond d'utilisateurs à l'accès restreint, tous les membres en attente (à la fois les membres en attente d'approbation et les membres invités) sont automatiquement supprimés. Pour vous assurer que les utilisateurs sont approuvés en tant que membres, vous devez approuver ou supprimer les membres en attente avant d'activer l'accès restreint.
Sur GitLab Self-Managed, le plafond d'utilisateurs maintient les nouveaux comptes utilisateurs en attente d'approbation par l'administrateur, au lieu de bloquer les membres de groupes ou de projets comme sur GitLab.com. Lorsque vous passez du plafond d'utilisateurs à l'accès restreint, les nouveaux comptes utilisateurs en attente ne sont pas automatiquement supprimés. Les utilisateurs restent bloqués jusqu'à ce qu'un administrateur les approuve.
Après avoir activé l'accès restreint, il détermine si une approbation d'utilisateur en attente peut être accordée :
{{< details >}}
{{< /details >}}
Le coût de votre abonnement est basé sur le nombre maximum de sièges utilisés pendant la période de facturation.
Si l'accès restreint est :
Vous ne pouvez pas acheter de sièges pour votre abonnement si :
Pour acheter des sièges pour un abonnement :
Vous recevez le reçu de paiement par e-mail. Vous pouvez également accéder au reçu dans le Portail clients sous Invoices.
Vous pouvez réduire les sièges uniquement lors du renouvellement de l'abonnement. Si vous souhaitez réduire le nombre de sièges dans votre abonnement, vous pouvez renouveler pour moins de sièges.
{{< details >}}
{{< /details >}}
Un abonnement GitLab Self-Managed utilise un modèle hybride. Vous payez un abonnement en fonction du nombre maximum d'utilisateurs activés pendant la période d'abonnement.
Pour les instances qui ne sont pas hors ligne ou sur un réseau fermé, le nombre maximum d'utilisateurs simultanés dans l'instance GitLab Self-Managed est vérifié chaque trimestre.
Si une instance est incapable de générer un rapport d'utilisation trimestriel, le modèle de régularisation existant est utilisé. Les frais calculés au prorata ne sont pas possibles sans rapport d'utilisation trimestriel.
Le nombre d'utilisateurs dans l'abonnement représente le nombre d'utilisateurs inclus dans votre licence actuelle, en fonction de ce que vous avez payé. Ce nombre reste le même tout au long de votre période d'abonnement, sauf si vous achetez davantage de sièges.
Le nombre maximum d'utilisateurs reflète le nombre le plus élevé d'utilisateurs facturables sur votre système pour la période de licence en cours.
Vous pouvez consulter et gérer vos utilisateurs facturables et l'utilisation de la licence.
Pour augmenter le nombre d'utilisateurs couverts par votre licence, achetez davantage de sièges pendant la période d'abonnement. Le coût des sièges ajoutés pendant la période d'abonnement est calculé au prorata à partir de la date d'achat jusqu'à la fin de la période d'abonnement. Vous pouvez continuer à ajouter des utilisateurs même si vous atteignez le nombre d'utilisateurs dans le compte de licences. GitLab vous facture le dépassement.
Si votre abonnement a été activé avec un code d'activation, les sièges supplémentaires sont immédiatement reflétés dans votre instance. Si vous utilisez un fichier de licence, vous recevez un fichier mis à jour. Pour ajouter les sièges, ajoutez le fichier de licence à votre instance.
Si LDAP est intégré à GitLab, toute personne dans le domaine configuré peut s'inscrire à un compte GitLab. Cela peut entraîner une facture inattendue au moment du renouvellement. Si les nouveaux comptes utilisateurs sont autorisés sur votre instance, toute personne pouvant accéder à l'instance peut créer un compte.
Pour éviter des dépassements imprévus, consultez les bonnes pratiques de gestion des sièges.
{{< details >}}
{{< /details >}}
Un abonnement GitLab.com utilise un modèle concurrent (par siège). Vous choisissez un nombre de sièges pour les utilisateurs pouvant utiliser l'abonnement simultanément, et payez un abonnement en fonction du nombre maximum d'utilisateurs affectés au groupe principal, à ses sous-groupes et projets pendant la période de facturation.
Vous pouvez ajouter et supprimer des utilisateurs pendant la période d'abonnement sans frais supplémentaires, tant que le nombre total d'utilisateurs à un moment donné ne dépasse pas le nombre de sièges dans l'abonnement. Si vous ajoutez davantage d'utilisateurs et dépassez le nombre de sièges achetés, vous encourrez un dépassement, qui sera inclus dans votre prochaine facture.
Si vous avez le rôle Owner pour un groupe principal lié à un abonnement inscrit aux réconciliations trimestrielles d'abonnement, vous recevez des alertes concernant l'utilisation des sièges dans l'abonnement.
L'alerte s'affiche sur les pages de groupe, de sous-groupe et de projet. Après avoir ignoré l'alerte, elle ne s'affiche plus jusqu'à ce qu'un autre siège soit utilisé.
L'alerte s'affiche aux intervalles suivants :
| Sièges dans l'abonnement | Alerte |
|---|---|
| 0-15 | Il reste un siège. |
| 16-25 | Il reste deux sièges. |
| 26-99 | Il reste 10 % des sièges. |
| 100-999 | Il reste 8 % des sièges. |
| Plus de 1 000 | Il reste 5 % des sièges. |
Pour afficher la liste des sièges utilisés :
Pour chaque utilisateur, une liste affiche les groupes et les projets dont l'utilisateur est membre direct.
Les données dans la liste d'utilisation des sièges, Sièges utilisés et Sièges dans l'abonnement sont mises à jour en temps réel. Les compteurs de Nombre max. de sièges utilisés et de Sièges dus sont mis à jour une fois par jour.
Pour afficher les informations de votre abonnement et un résumé du nombre de sièges :
Vous pouvez consulter les utilisateurs qui occupent des sièges dans votre abonnement. Pour rechercher l'utilisation des sièges d'un utilisateur :
La recherche renvoie une liste d'utilisateurs dont le prénom, le nom ou le nom d'utilisateur correspond à la chaîne de recherche.
Par exemple, pour un utilisateur prénommé Amir, la chaîne de recherche ami donne un résultat, mais amr ne donne aucun résultat.
Pour exporter les données d'utilisation des sièges sous forme de fichier CSV :
Prérequis :
Pour exporter l'historique d'utilisation des sièges sous forme de fichier CSV :
La liste générée contient tous les sièges utilisés et n'est pas affectée par la recherche en cours.
Pour supprimer un utilisateur facturable de votre abonnement GitLab.com :
Si vous ajoutez un membre à un groupe en partageant le groupe avec un autre groupe, vous ne pouvez pas supprimer le membre en utilisant cette méthode. À la place, vous pouvez :
{{< details >}}
{{< /details >}}
GitLab Enterprise Agile Planning est un module complémentaire qui aide à intégrer les utilisateurs non-ingénieurs dans la même plateforme DevSecOps où les ingénieurs créent, testent, sécurisent et déploient le code. Le module complémentaire favorise la collaboration interéquipes entre les développeurs et les non-développeurs, sans avoir à acheter des licences GitLab Ultimate pour les membres de l'équipe non-ingénieurs.
Grâce aux sièges Enterprise Agile Planning, les membres de l'équipe non-ingénieurs peuvent participer aux workflows de planification, mesurer la vélocité et l'impact de la livraison logicielle avec Value Stream Analytics, et utiliser des tableaux de bord exécutifs pour renforcer la visibilité organisationnelle.
Pour plus d'informations sur les sièges Enterprise Agile Planning et la façon de les acheter, contactez votre représentant commercial GitLab.
Un utilisateur occupe un siège Enterprise Agile Planning si :
Un utilisateur occupe un siège GitLab Ultimate au lieu d'un siège Enterprise Agile Planning si :
Pour utiliser vos sièges Enterprise Agile Planning achetés, vous devez d'abord attribuer le rôle Planificateur aux utilisateurs dans le groupe ou le projet.
Pour empêcher les utilisateurs avec le rôle Planificateur de se voir attribuer un rôle différent et de consommer ainsi des sièges GitLab Ultimate, vous pouvez utiliser le verrouillage global de l'appartenance aux groupes SAML.
Vous pouvez consulter le nombre de sièges Enterprise Agile Planning utilisés dans les détails de votre abonnement et dans le Portail clients. Sur GitLab Self-Managed, vous pouvez également consulter le nombre total d'utilisateurs par rôle dans les statistiques des utilisateurs.
Pour gérer efficacement les sièges de votre abonnement et maîtriser les coûts, suivez ces bonnes pratiques.
Configuration initiale :
Activités régulières :
Planification stratégique :