Résumé

  • Atlassian décrit une application liée à 25 utilisateurs Confluence qui passe au tarif de 100 après l’intégration de l’abonnement à Teamwork Collection, sur un site comptant 100 utilisateurs Jira.
  • La collection déduplique les utilisateurs de ses produits inclus. Les applications Marketplace conservent une logique de licence qui peut élargir leur population facturée lors du regroupement.
  • Les licences par instance, les offres multi-instances Enterprise et la facturation Forge par utilisateurs autorisés répondent à des questions différentes. Le devis doit correspondre au modèle réellement disponible.

Vingt-cinq personnes ont besoin d’un outil. Après le regroupement des logiciels, la facture de cet outil peut en compter cent. Atlassian présente ce cas dans sa documentation de facturation Marketplace.

L’exemple part d’un abonnement Confluence Cloud de 25 utilisateurs avec une application installée. Cet abonnement rejoint Teamwork Collection sur un site qui compte 100 utilisateurs Jira. L’application passe alors au tarif de 100 utilisateurs. Le changement porte sur le cadre commercial auquel elle est rattachée.

La population facturée est multipliée par quatre. Pour connaître la variation du montant, il faudrait le barème de l’application, ses paliers et les remises applicables. L’exemple suffit pourtant à poser une question que le prix séduisant d’un forfait peut laisser dans l’ombre : qu’arrive-t-il aux factures des outils déjà présents quand on change la taille de leur voisinage ?

Le forfait déduplique, l’application peut élargir

La facturation des Collections repose sur les utilisateurs uniques des applications incluses. Une personne ayant accès à au moins l’une d’elles entre dans le calcul ; si elle en utilise plusieurs, elle n’est comptée qu’une fois. Pour Teamwork Collection, les abonnements inclus à Jira, Confluence ou Loom se retrouvent sous une ligne de collection.

L’intérêt est lisible. Un salarié circule entre plusieurs outils ; l’acheteur préfère ne pas le traiter comme une nouvelle personne à chaque porte. Le regroupement rend la proposition commerciale plus simple à expliquer et la facture plus courte à parcourir.

Les applications Marketplace arrivent avec leur propre licence. Atlassian précise que leur facturation dépend de cette licence et de leur lien avec le produit sur lequel elles sont installées. Le transfert d’une application existante vers une collection peut donc modifier son prix.

Une même opération peut ainsi supprimer un doublon dans les produits inclus et agrandir l’assiette d’un outil spécialisé. Le premier calcul concerne les personnes communes au forfait. Le second concerne la population à laquelle le fournisseur de l’application vend sa licence. Additionner les seuls avantages du premier produit un dossier d’achat incomplet.

Pour le responsable d’une petite équipe, le désagrément est facile à comprendre. Le besoin métier n’a pas nécessairement grandi ; le territoire commercial du logiciel, lui, a changé. Il faut désormais expliquer un achat dont le nombre de bénéficiaires attendus et le nombre de personnes facturées peuvent être très différents.

Les utilisateurs absents de l’outil peuvent être présents dans sa licence

La présentation des modèles Forge énonce la règle standard : l’application est payée pour tous les utilisateurs de l’instance hôte, quelle que soit son utilisation réelle.

Atlassian prend une instance Jira de 500 utilisateurs, dont 50 seulement utilisent l’application. Avec le prix pédagogique de 2 dollars par personne et par mois, le montant est de 1 000 dollars pour les 500 personnes. Ces chiffres pédagogiques servent à expliquer le calcul dans cet exemple. Ils montrent comment une petite audience peut devoir justifier une grande licence.

Cette règle pèse sur l’entrée des outils spécialisés dans les grandes organisations. Une équipe peut démontrer qu’une application lui fera gagner du temps et buter malgré tout sur le coût d’un achat dimensionné pour l’instance entière. Le besoin est local, la licence suit l’environnement partagé.

Ce même environnement peut avoir de bonnes raisons d’être vaste : collaboration plus directe, administration commune, moins d’espaces séparés à entretenir. La centralisation possède ses avantages opérationnels. Elle fournit aussi aux applications facturées selon l’hôte une population commerciale plus large. Les deux effets doivent figurer dans le même calcul.

La règle des applications Jira ajoute une précision utile. Sur un site avec 100 utilisateurs Jira et 80 agents Jira Service Management, Atlassian retient la quantité la plus élevée, soit 100, pour les applications concernées. Les deux groupes ne sont pas simplement additionnés à 180. Si l’abonnement Jira de 100 utilisateurs est désactivé, le tarif de 80 s’applique à partir du cycle suivant.

Un relevé des personnes ayant ouvert l’application ne répond donc pas à toutes les questions. Il faut aussi identifier le produit hôte qui détermine la quantité, le site concerné et le moment où un changement modifie la facturation.

L’instance est aussi une décision d’achat

Le guide de facturation Enterprise décrit une organisation fictive, Acme, dont les 8 000 utilisateurs Jira se répartissent entre deux instances de 5 000 et 3 000 personnes. Une application Marketplace installée sur la première donne lieu, dans ce modèle par instance, à une facture correspondant au palier de 5 000 utilisateurs.

La taille totale de l’entreprise n’est donc pas automatiquement celle de chaque licence. Le lieu d’installation peut fixer une frontière commerciale. Un outil destiné à une activité précise peut être acheté dans un cadre différent de celui d’un outil commun à toute l’organisation.

Découper les environnements a cependant un coût de travail. Il faut entretenir leurs réglages, guider les utilisateurs et organiser les échanges entre équipes. Une facture d’application réduite peut cohabiter avec davantage d’administration. L’acheteur a intérêt à comparer l’ensemble de la configuration, plutôt qu’à célébrer le seul poste devenu plus petit.

Une autre page décrit la tarification multi-instances pour Jira ou Confluence en Cloud Enterprise. Plusieurs instances peuvent relever d’un abonnement Marketplace au niveau de l’organisation. Les utilisateurs uniques sont comptés une seule fois entre ces instances, selon le palier choisi au début de l’abonnement. Les applications doivent ensuite être installées dans les instances pour que leurs fonctions y soient disponibles.

Cette formule traite la répétition d’une même personne entre plusieurs environnements. Elle diffère d’une licence réservée à une fraction des utilisateurs à l’intérieur d’une seule instance. Les deux peuvent sembler promettre moins de doublons ; ils déplacent des frontières différentes.

La page présente encore au futur la disponibilité de la tarification multi-instances pour toutes les applications. Le choix concret dépend donc des options proposées pour celle que l’entreprise achète. Une famille de modèles documentés ne remplace pas la licence effectivement offerte.

Faire payer seulement les utilisateurs autorisés exige aussi un vendeur

Le guide Forge consacré à la facturation par utilisateurs décrit un modèle dans lequel l’administrateur accorde l’accès à un groupe précis, puis l’organisation paie pour ce groupe. La population est celle des personnes autorisées, plutôt qu’un compteur de clics ou de jours d’activité.

Les documents consultés qualifient ce dispositif d’EAP et décrivent des essais en environnement hors production. La publication Marketplace, le paramétrage des prix, les révisions et les approbations figurent parmi les évolutions annoncées. Le guide contient aussi des conditions de publication et de transition en production ; pour un achat présent, il faut vérifier le modèle réellement activé pour l’application visée.

Le fournisseur conserve un rôle décisif dans cette conception. Le partenaire choisit d’adopter le modèle, peut adapter ses prix et fait suivre ses clients existants lors de la transition. Le dispositif concerne Forge ; une application Connect doit d’abord adopter Forge. Réduire une liste de permissions du côté du client ne crée pas, à lui seul, un nouveau contrat commercial.

Une population facturée plus étroite pourrait faciliter l’entrée d’un outil spécialisé dans une grande entreprise. Un fournisseur peut également revoir son prix unitaire lorsque cette population rétrécit. La quantité et le prix continuent de se rencontrer sur le devis ; aucune des deux variables ne disparaît parce que le modèle paraît plus fin.

Pour établir le montant ou l’économie d’une migration particulière, il manque la licence applicable, le palier sélectionné et le devis du fournisseur. Les règles publiques permettent déjà de demander les bons documents avant le regroupement.

Un forfait peut rendre les logiciels plus faciles à acheter ensemble. L’exercice est achevé lorsque les applications qui les accompagnent ont elles aussi été chiffrées dans leur nouveau cadre. Sinon, les 25 utilisateurs ont seulement découvert que leur petit outil venait de louer un plus grand immeuble.