GitLab : haro sur le nouveau modèle économique
Sur l’autel du ROI, GitLab a mis fin au moins onéreux de ses abonnements (Starter). Quelles issues pour les clients affectés ?
GitLab devrait-il proposer une option de facturation mensuelle ? Cette demande revient régulièrement chez les utilisateurs. On en reparle d’autant plus à l’heure où la plate-forme change son modèle économique… mais sur un autre aspect. Elle met, en l’occurrence, fin à son forfait Starter (Bronze pour la version SaaS).
À 48 $/an/utilisateur, ce forfait constituait le ticket d’entrée de l’offre payante. C’est désormais la formule Premium (ex-Silver pour la version SaaS) qui remplit ce rôle. Elle regroupe toutes les fonctionnalités de Starter et y ajoute, entre autres, des briques de sécurité, de CI/CD et de gestion de projet. Mais pas au même prix : 228 $/an/utilisateur. Soit cinq fois plus cher.
GitLab s’en cache à peine : la formule Starter ne lui apportait pas le ROI attendu. Aux clients concernés, l’entreprise fournit deux pistes. D’un côté, opter pour la version gratuite (Free / Core), qui inclut « 89 % des fonctionnalités » de Starter. De l’autre, aller au bout de l’abonnement Starter échu, puis le renouveler pour un an en version Premium, sans surcoût. Et ensuite bénéficier de remises sur les renouvellements ultérieurs (72 $/an/utilisateur la première année ; 108 $ la deuxième ; 180 $ la troisième). L’accès à ces avantages est direct jusqu’à 25 utilisateurs. Au-delà, on est invité à consulter l’équipe commerciale de GitLab.
À l’expiration des abonnements Starter, on perdra l’accès aux fonctionnalités payantes et aux données associées – elles seront toutefois conservées en attendant une éventuelle souscription à Premium. Les installations sur site passeront quant à elles en lecture seule.
GitLab appelé à moduler ses tarifs
Le cas des déploiements on-prem passe particulièrement mal chez les utilisateurs. « Je ne comprends pas comment [cette offre] peut être vendue à perte », déplore l’un d’entre eux, soulignant que GitLab n’a pas de maintenance à effectuer contrairement à ses offres cloud.
Une autre suggestion souvent faite par le passé revient sur la table : proposer une tarification différenciée en fonction du rôle des utilisateurs. Des témoignages qui ressortent, on constate effectivement qu’un bon nombre d’entre eux (product owners, clients, bots…) sont loin d’exploiter les mêmes fonctionnalités que les développeurs.
Certains suggèrent de proposer un tarif « de base » et d’y greffer des packs de fonctionnalités. Quand d’autres dénoncent le « mauvais timing » de cette décision, dans le contexte de la crise économique.
