Maîtrisez vos sièges GitLab avec l'accès restreint

L'accès restreint de GitLab pour les administrateurs d'instance, les propriétaires de groupe et les responsables de facturation, garantit des coûts liés aux sièges prévisibles avec moins de contrôles manuels. Cette fonctionnalité a été considérablement améliorée et offre désormais une couverture plus complète pour les workflows qui influencent habituellement l'utilisation des sièges. Cette mise à jour comble les lacunes liées au provisionnement via les fournisseurs d'identité, à la réactivation des utilisateurs inactifs et aux processus de connexion, afin que les organisations puissent utiliser l'accès restreint plus sereinement dans des environnements réels.

Qu'est-ce que l'accès restreint ?

L'accès restreint est une fonctionnalité de gestion des sièges disponible sur GitLab.com et GitLab Self-Managed. Lorsqu'elle est activée et que tous les sièges sous licence sont déjà utilisés, GitLab empêche l'ajout de nouveaux utilisateurs facturables.

Les organisations peuvent ainsi éviter une augmentation imprévue du nombre de sièges avant le renouvellement et maintenir une utilisation des sièges en adéquation avec le nombre de sièges achetés. L'accès restreint est conçu pour prévenir les futurs dépassements, et non pour corriger ceux qui existent déjà.

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 OpenID Connect (OIDC), peuvent se voir attribuer le rôle Accès minimal (non facturable). Ces utilisateurs peuvent toujours s'authentifier sans utiliser de siège payant.

Aucun impact rétroactif sur les membres facturables existants

L'accès restreint s'applique uniquement aux utilisateurs futurs. Si vous l'activez sur un groupe ou une instance qui dépasse déjà la limite de sièges, GitLab ne rétrograde pas, ne supprime pas et ne bloque pas les membres facturables existants. Les abonnements actuels restent inchangés. En cas de dépassement, les administrateurs doivent tout de même restreindre l'utilisation dans les limites de l'abonnement souscrit, en supprimant des membres facturables ou en achetant des sièges supplémentaires.

Une fois l'utilisation des sièges régularisée, l'accès restreint contribue à empêcher toute nouvelle augmentation supplémentaire des coûts facturables au-delà de cette limite.

Meilleure intégration de l'accès restreint à votre fournisseur d'identité

Un volet majeur des récentes améliorations a porté sur le comportement de l'accès restreint face au provisionnement basé sur l'identité.

Lorsque l'accès restreint est activé et qu'aucun siège n'est disponible, les utilisateurs provisionnés via SAML, SCIM ou LDAP ne sont plus ajoutés directement à des rôles facturables. À la place, GitLab leur attribue le rôle Accès minimal (non facturable). La synchronisation peut ainsi se poursuivre sans provoquer immédiatement un dépassement facturable.

Ce comportement est particulièrement utile pour les organisations qui s'appuient sur le provisionnement automatisé et souhaitent renforcer le contrôle des coûts sans renoncer à une gestion centralisée des identités.

Si vous utilisez GitLab comme fournisseur OIDC et que certains utilisateurs n'ont besoin que d'une authentification, sans accès aux projets ou aux groupes, leur attribuer le rôle Accès minimal au niveau du groupe principal reste une pratique pertinente. Ces utilisateurs ne consomment pas de siège facturable, et les utilisateurs disposant uniquement du rôle Accès minimal peuvent toujours être réactivés, même quand aucun siège n'est disponible.

Plus de dépassements invisibles par les utilisateurs inactifs

GitLab peut désactiver automatiquement les utilisateurs restés inactifs pendant une durée configurable pour libérer des sièges. Auparavant, lorsque ces utilisateurs se reconnectaient via OIDC ou l'authentification unique (SSO), ils pouvaient être réactivés de manière invisible en tant qu'utilisateurs facturables. Ils contournaient ainsi les restrictions d’accès et provoquaient des dépassements de licence.

Désormais, quand l'accès restreint est activé et qu'aucun siège n'est disponible, les utilisateurs inactifs qui se reconnectent sont placés en attente d'approbation. Leurs adhésions aux groupes et aux projets sont conservées, et un administrateur peut les approuver dès qu'un siège se libère.

Des avertissements, bannières et notifications plus clairs

L'accès restreint est également plus simple à gérer au quotidien. Des améliorations récentes ont introduit davantage d'indications directement dans le produit, afin que les administrateurs puissent suivre ce qui se passera avant et après avoir atteint leur limite de sièges. Selon le cas, cela inclut :

• Des avertissements contextuels lors de la configuration de la synchronisation LDAP, des liens de groupe SAML ou du provisionnement SCIM pendant que l'accès restreint est actif
• Des états distincts au sein du produit lorsque la limite de sièges approche et lorsqu'elle est atteinte
• Des notifications par e-mail aux propriétaires de groupe ou aux administrateurs d'instance lorsque des utilisateurs se voient attribuer le rôle Accès minimal faute de sièges payants disponibles
• Une visibilité d'audit pour les événements de repli du rôle Accès minimal

L'objectif ne se limite pas à bloquer les nouveaux utilisateurs facturables : il s'agit aussi de faciliter la compréhension de ce comportement et sa gestion.

Le cache des paramètres de GitLab Self-Managed

Sur GitLab Self-Managed, les paramètres de l'application sont mis en cache pendant 60 secondes par défaut pour des raisons de performance.

Par conséquent, si vous basculez entre l'accès restreint et le plafond d'utilisateurs, certains changements d'interface ou comportements de contrôle des sièges peuvent ne pas apparaître immédiatement. Le cache se rafraîchit automatiquement, et les modifications seront visibles à ce moment-là. Si nécessaire, les administrateurs peuvent ajuster la durée de mise en cache.

Consultez notre documentation sur le cache des paramètres de l'application.

La différence entre l'accès restreint et le plafond d'utilisateurs

L'accès restreint et le plafond d'utilisateurs sont liés, mais ils répondent à des problèmes différents.

Le plafond d'utilisateurs place les nouveaux utilisateurs dans un processus d'approbation destiné aux administrateurs ou aux propriétaires de groupe, que des sièges soient encore disponibles ou non. L'accès restreint, lui, est directement lié au nombre de sièges sous licence et bloque les nouveaux ajouts facturables uniquement lorsqu'il ne reste plus de sièges.

Autrement dit, le plafond d'utilisateurs est un contrôle d'approbation. L'accès restreint est un contrôle de limite de sièges.

Les deux fonctionnalités ne peuvent pas être activées en même temps. Lorsque vous activez l'accès restreint, le plafond d'utilisateurs est automatiquement désactivé. Sur GitLab.com, passer du plafond d'utilisateurs à l'accès restreint peut également affecter les membres en attente, il est donc recommandé de consulter notre documentation relative à ce comportement avant d'effectuer tout changement.

Premiers pas

L'accès restreint est disponible sur GitLab.com et GitLab Self-Managed.

• Sur GitLab.com, les propriétaires de groupe peuvent l'activer via Paramètres > Général > Permissions et fonctionnalités du groupe > Contrôle des sièges > Accès restreint.
• Sur GitLab Self-Managed, les administrateurs peuvent l'activer via Admin > Paramètres > Général > Restrictions pour les nouveaux comptes utilisateurs > Contrôle des sièges > Accès restreint.
• Sur GitLab.com, l'accès restreint n'est pas disponible lorsque le groupe principal est partagé avec un groupe externe.

Votre équipe souhaite mieux maîtriser la croissance du nombre de sièges, éviter les mauvaises surprises liées à la facturation et disposer d'un modèle opérationnel plus clair pour le provisionnement et la réactivation ? Adoptez l'accès restreint dès maintenant.

Ressources

• Documentation sur l'accès restreint
• Documentation sur la gestion des sièges
• Documentation sur le cache des paramètres de l'application