Trois modèles économiques, pas un
Un assistant de code se facture au siège, à l'usage ou au jeton, et ces trois modèles ne conviennent pas aux mêmes équipes. Comparer les tarifs affichés sans identifier le modèle produit une décision fausse.
La facturation au siège est un abonnement par personne, quel que soit l'usage. Elle est prévisible et pénalise les équipes où la moitié des développeurs se servent peu de l'outil.
La facturation à l'usage compte les requêtes ou les complétions. Elle épouse le besoin réel et rend le budget imprévisible.
La facturation au jeton, enfin, est celle des API brutes. Elle est la moins chère à volume maîtrisé et la plus dangereuse sur une automatisation mal bornée.
Le calcul à faire sur son propre profil
Relever le nombre de développeurs réellement actifs et leur volume mensuel suffit à trancher, et cela prend une heure. C'est le seul calcul qui compte.
La première grandeur est le taux d'usage réel. Sur une équipe de vingt personnes équipées, il est fréquent que huit se servent de l'outil quotidiennement et que le reste l'ouvre une fois par semaine. Une facturation au siège coûte alors plus du double du besoin.
La seconde est la dispersion. Un développeur qui automatise des tâches avec l'outil consomme dix à cinquante fois la moyenne. Sur une facturation à l'usage, ces quelques personnes portent l'essentiel de la facture.
Cette dispersion est le point que les calculs oublient systématiquement, et c'est le même mécanisme que celui décrit dans mesurer le coût par fonctionnalité : la moyenne ne prédit rien, il faut regarder le quantile élevé.
Ce qu'il faut vérifier au-delà du prix
- Le préavis en cas de changement tarifaire. Ces offres ont beaucoup bougé en dix-huit mois, et un doublement se subit.
- Ce qui est compté, exactement : une complétion refusée est-elle facturée ? une requête en erreur ?
- Le plafond, et s'il existe. Une facturation au jeton sans plafond appliqué par le service est un incident en attente.
- La portabilité des réglages si vous changez d'outil, ce qui arrivera. Voir la couche qui rend le modèle remplaçable.
Le cas de l'écart tarifaire entre marchés
Le même produit peut être facturé trois fois moins dans un autre pays, et c'est une information sur le coût réel du service, pas une bonne affaire à saisir. Elle mérite d'être lue correctement.
Un éditeur qui propose son offre à un tiers du prix sur un marché donné démontre que sa marge le permet. Cela ne signifie pas qu'une entreprise française puisse y accéder : les conditions d'éligibilité sont contractuelles et leur contournement est une rupture de contrat, pas une optimisation.
Ce que cette information autorise, en revanche, c'est la négociation. Un acheteur qui connaît l'écart tarifaire mondial d'un produit négocie mieux, surtout sur un contrat pluriannuel.
Le sujet est traité pour lui-même dans le même produit à deux prix.
Ce que je recommande selon le profil
Équipe stable et usage régulier : au siège. Usage irrégulier ou équipe étendue : à l'usage. Automatisation et traitement par lot : au jeton, avec un plafond. Ces trois règles couvrent la quasi-totalité des situations.
L'équipe stable est celle où presque tout le monde développe tous les jours. La prévisibilité vaut alors le léger surcoût, et la gestion administrative est plus simple.
L'usage irrégulier concerne les équipes mixtes, où des profils non développeurs touchent au code occasionnellement. La facturation au siège y est très défavorable.
L'automatisation, enfin, ne devrait jamais passer par une offre par siège : elle consomme sans rapport avec le nombre de personnes, et elle relève de l'API avec les garde-fous correspondants, décrits dans les usages qui basculent quand le coût s'effondre.
Le relevé qui suffit à décider
Sur un mois : combien de personnes ont utilisé l'outil au moins trois fois par semaine, et quelle part du volume total les trois plus gros consommateurs représentent. Ces deux chiffres désignent le bon modèle sans autre calcul.
Ce qu'il faut prévoir au renouvellement
Ces offres changent de tarif et de périmètre plus souvent que les autres briques de la chaîne, et il faut le provisionner. C'est une différence réelle avec un logiciel classique.
En dix-huit mois, la plupart des offres du marché ont modifié soit leur prix, soit ce qui est inclus, soit le modèle sous-jacent. Une décision prise il y a un an est probablement à reprendre.
La parade tient en deux éléments. Un rendez-vous annuel qui rejoue le calcul sur les chiffres constatés, et une clause de préavis en cas de changement tarifaire.
Ce rythme s'inscrit dans le même rendez-vous que les autres décisions d'exploitation, décrit dans ce qui occupe l'équipe la deuxième année, ce qui évite d'en créer un de plus.
Questions fréquentes
Quel modèle de facturation choisir ?
Au siège pour une équipe stable où presque tout le monde développe quotidiennement, à l'usage pour une équipe mixte ou irrégulière, au jeton avec plafond pour l'automatisation.
Quels chiffres relever avant de décider ?
Le nombre de personnes utilisant l'outil au moins trois fois par semaine, et la part du volume total portée par les trois plus gros consommateurs. Ces deux chiffres suffisent.
Pourquoi la moyenne ne suffit-elle pas ?
Parce qu'un développeur qui automatise consomme dix à cinquante fois la moyenne. Sur une facturation à l'usage, quelques personnes portent l'essentiel de la facture.
À quelle fréquence reprendre la décision ?
Une fois par an. En dix-huit mois, la plupart des offres ont changé de prix, de périmètre ou de modèle sous-jacent : une décision d'il y a un an est probablement à reprendre.