Outils de développement : les README, articles et docs qui amènent des développeurs dont l’équipe paie.

01Comment ils vendent

• AbonnementDes offres d’équipe par utilisateur, mensuelles ou annuelles, souvent avec une remise, voire gratuites, pour les projets open source.
• FreemiumUne version gratuite individuelle, les fonctions d’équipe comme la configuration partagée, le SSO ou les journaux d’audit étant réservées aux offres payantes.
• À l’usageCertains facturent chaque mois au build, à la minute, à la requête ou à l’utilisateur actif.

02Les paiements qu’il lit

• StripeOffres d’équipe et usage via des abonnements Stripe ; les utilisateurs ajoutés, les renouvellements et les remboursements sont lus.
• PolarChoisi par les outils de développement qui veulent une facturation pensée pour les développeurs ; commandes, cycles d’abonnement et litiges perdus sont lus.
• PaddleLes outils de développement qui vendent à des entreprises du monde entier passent par Paddle comme marchand officiel ; transactions et ajustements sont lus.
• Lemon SqueezyLes outils de développeurs indépendants vendent des licences via Lemon Squeezy, avec clés de licence.

03D’où viennent les acheteurs

• README GitHubUn lien dans le README d’un dépôt populaire envoie des développeurs qui font déjà confiance au projet.
• Hacker News et RedditLes posts de lancement et les articles techniques de fond envoient des vagues de développeurs qui essaient d’abord et paieront peut-être bien plus tard.
• Recherche vers la docLes développeurs qui cherchent un message d’erreur ou la façon de faire une chose précise arrivent sur les pages de documentation.
• Assistants de code IAEn répondant à une question de code, un assistant peut recommander votre outil et envoyer le développeur vers sa documentation, dans le canal IA.
• Conférences et podcastsLes talks de conférence et les podcasts de développeurs envoient des gens qui cherchent l’outil après coup, en tapant l’adresse plutôt qu’en suivant un lien.

04Ce à quoi Tally répond

1. Quels liens de README envoient des développeurs qui finissent par payer ?

   GitHub apparaît comme référent, avec ses visiteurs et les revenus qui lui sont attribués ; ajoutez des UTM aux liens de chaque README pour distinguer les dépôts.

   Sources et revenus

2. Combien de temps entre la première visite d’un développeur et une offre d’équipe ?

   Le parcours d’achat donne le délai médian et le nombre de visites entre la première visite et le premier paiement, ainsi que les pages vues par les acheteurs ; un essai sur un projet perso avant l’achat d’une équipe apparaît comme un long parcours, avec des pages de docs vers la fin.

   Parcours d’achat

3. Puis-je consulter mes revenus sans quitter le terminal ?

   La ligne de commande et la REST API vous donnent les chiffres depuis un terminal ou un script, et le serveur MCP permet à un assistant IA dans votre éditeur de répondre à vos questions à leur sujet.

   API, CLI et MCP

4. Pourquoi certaines offres d’équipe n’ont-elles pas de source ?

   La couverture donne la part des revenus liée et la raison de chaque vente non liée, comme une session Checkout créée par la commande de mise à niveau de la CLI sans l’identifiant du visiteur, avec le snippet qui corrige.

   Couverture

5. Le fil de lancement a-t-il amené des équipes payantes, des mois plus tard ?

   Le justificatif de chaque offre d’équipe garde la première visite en plus de celle qui est attribuée : un développeur qui vous a découvert dans un fil de lancement et a payé des mois plus tard garde ce fil dans la preuve.

   Justificatifs

05Les chiffres à suivre

Visiteurs venus d’assistants IA

Les visites venues d’assistants IA qui répondent à des questions de code, comptées dans un canal à part.

Délai médian avant l’achat

Le délai médian entre la première visite et le premier paiement : la durée de la phase projet perso.

Couverture

La part des revenus liée à une visite ; les passages au payant lancés depuis une CLI ou un IDE sont la lacune habituelle.

Revenus par source

Les revenus derrière chaque campagne de README, chaque communauté et chaque page d’entrée de la documentation.

06Un exemple

07Mise en place

1. Next.jsSi la doc et le site forment une seule app Next.js, placez la balise dans le layout racine : la doc, la page de tarifs et le tableau de bord la portent tous.
2. PolarAvec Polar, renseignez tally_visitor_id dans les métadonnées du paiement quand un développeur choisit une offre d’équipe.
3. Ajoutez des UTM aux liens de vos README et de vos pages de paquets, car un référent peut ne porter que le domaine du site, pas le dépôt.
4. Appelez tally('identify', { email }) après la connexion, pour qu’un paiement fait plus tard avec cet e-mail se lie, même depuis le terminal.

08Questions fréquentes

• Les installations npm ou d’extensions d’éditeur comptent-elles ?

  Non. Les installations depuis les registres de paquets et les places de marché d’extensions ne sont pas lues ; les visites de votre site et les paiements chez votre prestataire, si.

• Les assistants de code IA nous envoient-ils des développeurs ?

  Les visites venues de ChatGPT, Claude, Perplexity et d’autres assistants ont leur propre canal, avec les revenus en regard ; pour un outil de développement, regardez sur quelles pages de docs ces visiteurs arrivent.

• Un développeur paie pour lui-même, puis son entreprise achète une offre d’équipe. Un client ou deux ?

  Deux si les paiements utilisent des e-mails ou des navigateurs différents, chacun attribué à sa propre dernière visite hors accès direct. Si le même e-mail identifié paie les deux, ils figurent sur la ligne d’un seul client.