Résumé

  • GitLab compte les invités parmi les utilisateurs facturables de Premium, mais dispense certains invités d’un siège dans Ultimate. Le choix du forfait modifie ainsi la population à laquelle appliquer le prix.
  • L’exception Ultimate pour un rôle Guest complété seulement par la lecture du code est étroite. D’autres permissions peuvent consommer un siège, avec une dépense supplémentaire si la capacité achetée est dépassée.

La petite faveur qui intéresse les achats

Donner un droit supplémentaire à un collègue ressemble rarement à un achat de logiciel. Il lui manque une fonction, quelqu’un ouvre les paramètres, le travail peut reprendre. Chez GitLab, ce geste peut pourtant modifier la population des utilisateurs payants. Le service achats a négocié le prix unitaire ; une équipe vient peut-être d’en changer le multiplicateur.

La gestion des sièges rend cette mécanique très concrète. Dans Premium, le rôle Guest entre dans le décompte facturable. Dans Ultimate, un utilisateur qui reste dans les conditions prévues pour les invités peut participer sans occuper de siège. Le même effectif de collaborateurs produit donc des besoins de licence différents selon le forfait et les rôles réellement attribués.

L’offre supérieure vend des fonctionnalités, mais aussi une autre frontière entre les personnes qui doivent payer et celles qui peuvent simplement participer. Cette différence compte pour une organisation entourant son équipe de développement de nombreux interlocuteurs métier. Elle compte moins si presque tout le monde a besoin des capacités d’un rôle payant.

La page tarifaire publique affiche actuellement Premium à 29 dollars par utilisateur et par mois, facturés annuellement. Ultimate passe par un devis. Il manque le devis obtenu par l’entreprise et la répartition de ses rôles pour chiffrer l’économie éventuelle. Réduire le nombre de sièges facturables peut rendre un forfait supérieur intéressant ; il faut encore multiplier les bons nombres.

La lecture du code possède sa propre exception

Le mot invité est trompeusement familier. Dans GitLab, Guest désigne un ensemble précis de permissions. D’après le tableau des rôles, il permet notamment de participer aux tickets et aux epics, sans donner l’accès ordinaire au code d’un dépôt privé. Un Reporter peut consulter ce code, mais fait partie des rôles facturables. La lecture seule ne forme donc pas une catégorie commerciale universellement gratuite.

Ultimate offre une solution plus fine. Un rôle personnalisé peut partir de Guest et lui ajouter uniquement read_code. Cette combinaison est explicitement exemptée de siège. Elle permet d’ouvrir le code à une personne qui doit le comprendre sans lui attribuer un rôle plus large.

La documentation des invités précise la limite : ajouter d’autres permissions rend le rôle consommateur d’un siège. L’exception tient à la composition exacte des droits, pas à un intitulé bien choisi. Rebaptiser un accès généreux « invité » ne change pas ce qu’il autorise.

Pour le client, cette granularité a une valeur réelle. Un interlocuteur peut lire ce dont il a besoin sans recevoir toute la boîte à outils du développeur. Elle demande aussi une décision : dès que son travail réclame autre chose, faut-il lui attribuer la capacité correspondante et en assumer l’effet sur les sièges ?

Une entreprise qui répond systématiquement non risque de payer autrement. Quelqu’un devra effectuer l’action à sa place, lui transmettre l’information ou attendre qu’un autre intervenant soit disponible. La facture de licences baisse facilement sur un tableau ; le temps perdu se répartit dans les conversations. À l’inverse, attribuer des rôles larges à tous pour éviter les questions peut faire acheter des capacités dont une partie des participants n’a aucun usage.

Un rôle ailleurs suffit à changer le calcul

Le badge Guest affiché dans un projet ne raconte pas toute l’histoire. Pour GitLab.com, la vérification doit couvrir le périmètre du namespace concerné par l’abonnement. Une personne ayant un rôle facturable plus élevé dans un autre projet ou sous-groupe de ce périmètre ne devient pas gratuite parce qu’elle apparaît comme invitée ici.

Sur Self-Managed, le contrôle porte sur l’instance entière. GitLab demande notamment de vérifier ces autres rôles avant de passer à Ultimate. Le cas d’un namespace personnel sur GitLab.com relève d’une frontière différente. La forme d’hébergement détermine donc aussi l’étendue du contrôle à effectuer.

Il faut cependant compter les personnes correctement. Un même utilisateur présent dans plusieurs projets ou sous-groupes du même groupe racine abonné est compté une seule fois. Additionner toutes les lignes des listes de membres gonflerait artificiellement le besoin. Chercher uniquement le rôle le moins élevé pourrait, à l’inverse, le minorer.

Cette règle donne une responsabilité économique aux propriétaires des accès. Leur décision peut être parfaitement justifiée par le travail demandé. Encore faut-il que l’organisation sache si elle utilise un siège déjà disponible ou augmente le besoin total. Le budget et les droits d’accès sont gérés dans des écrans différents, mais finissent dans le même contrat.

Le maximum a meilleure mémoire que le tableau du jour

Le passage à un rôle facturable ne produit pas nécessairement une nouvelle dépense immédiate. Un siège déjà acheté et libre peut l’accueillir. GitLab.com permet également de remplacer des utilisateurs pendant la période d’abonnement sans surcoût tant que le nombre occupé reste dans la capacité achetée.

Lorsque cette capacité est dépassée, le maximum atteint pendant la période devient décisif. Retirer ensuite une permission ou un membre réduit l’occupation actuelle ; cela n’efface pas automatiquement le sommet déjà enregistré pour la facturation.

GitLab décrit deux mécanismes dans ses règles de dépassement : une régularisation trimestrielle fondée sur le maximum du trimestre et les modalités de prorata pour la durée restante, ou une régularisation annuelle appliquant le prix annuel aux utilisateurs ajoutés. L’éligibilité à la première formule varie. Le dernier effectif visible ne suffit donc pas à reconstituer le montant dû.

Réduire le nombre de sièges achetés pour la période suivante passe par le renouvellement de l’abonnement. Nettoyer les accès aujourd’hui, libérer une capacité déjà payée et commander moins de sièges demain sont trois résultats différents. Ils doivent apparaître séparément dans le suivi des économies.

Le moment utile pour poser la question du coût est ainsi celui de l’attribution du droit. Attendre le renouvellement revient à découvrir après le dîner quels invités occupaient une place payante. GitLab donne des moyens de faire participer davantage de monde ; l’entreprise doit savoir lesquels de ses participants remplissent réellement les conditions de gratuité.