- Lago, basé à Paris, a annoncé, à l’occasion de son lancement officiel, les résultats de sa transition vers une plateforme de facturation open source pour développeurs, en levant environ 22 millions de dollars (22 M$) sur deux tours
- La dernière Series A de 15 millions de dollars a été menée par FirstMark, tandis que la précédente levée seed de 7 millions de dollars a été menée par SignalFire, avec la participation de Y Combinator, New Wave, Script et d’investisseurs individuels
- L’équipe, qui voulait à l’origine créer un “Zapier” pour les équipes marketing, a pivoté vers une plateforme de facturation après qu’un post sur Hacker News au sujet des problèmes de facturation des développeurs a suscité une forte réaction
- Mistral.ai, Together.ai et Juni ont rejoint la bêta privée en tant que premiers clients, et Lago cible les startups qui gèrent des modèles tarifaires par abonnement, à l’usage ou hybrides
- Sur un marché où l’on trouve Stripe, Adyen, Salesforce, Zoho et Paddle, Lago met en avant la scalabilité et la mise en œuvre d’une facturation personnalisée comme principaux différenciateurs
Lancement officiel et structure de l’investissement
- La startup parisienne Lago a annoncé, avec le lancement officiel de sa plateforme de facturation open source, avoir levé au total 22 millions de dollars
- L’investissement se compose de deux tours
- La dernière Series A de 15 millions de dollars a été menée par FirstMark
- La précédente levée seed de 7 millions de dollars a été menée par SignalFire
- Y Combinator, New Wave et Script ont également participé à l’investissement
- Parmi les investisseurs individuels figurent Meghan Gill, responsable de la monétisation chez MongoDB, Romain Huet, ancien de Stripe et aujourd’hui en charge des relations développeurs chez OpenAI, ainsi que Clément Delangue, CEO de Hugging Face
- Selon des sources, la valorisation de Lago s’élèverait à environ 100 millions de dollars
Bêta privée et premiers clients
- Avant son lancement officiel, Lago était exploité en bêta privée
- Parmi ses premiers clients figurent des startups comme Mistral.ai, Together.ai et Juni
- L’entreprise se concentre sur l’aide aux développeurs pour qu’ils puissent ajuster eux-mêmes leur système de facturation en fonction de nouveaux services
- Elle permet de mesurer les données d’usage afin de gérer les abonnements ou d’autres modèles tarifaires
Pivot d’un outil marketing vers une plateforme de facturation
- Lago n’était pas, à l’origine, une entreprise créée pour construire une plateforme de facturation
- Les cofondateurs Anh-Tho Chuong et Raffi Sarkissian ont créé l’entreprise après avoir travaillé chez Qonto, puis ont rejoint la cohorte Y Combinator Summer 2021
- Lors de leur entrée chez YC, ils n’avaient pas encore de produit, puis ont choisi l’idée d’un “Zapier” pour les équipes marketing
- Sur un marché des technologies marketing très concurrentiel, ce premier produit n’a pratiquement pas trouvé de traction
- Pour attirer l’attention, Sarkissian a publié sur Hacker News un billet sur les problèmes de facturation des développeurs
- Son titre était “Billing systems are a nightmare for engineers”
- Il faisait écho à son expérience de création d’un produit destiné à résoudre les problèmes de facturation chez Qonto
- De nombreux utilisateurs ayant partagé leurs propres problèmes de facturation, Lago a changé de cap pour s’attaquer aux problèmes de facturation des développeurs
Une stratégie open source visant la facturation complexe
- Selon Lago, il existe déjà de nombreuses solutions pour les modèles tarifaires simples et la facturation, mais pas assez de réponses satisfaisantes pour la facturation complexe
- Les entreprises qui créent des produits fondés sur l’IA cherchent encore un modèle économique viable, et beaucoup envisagent une approche hybride combinant abonnement forfaitaire et tarification à l’usage
- Ce type d’approche nécessite des outils capables de s’intégrer aux produits créés par les développeurs et d’identifier les données d’usage à appliquer
- De nombreuses entreprises, comme Qonto, construisent leur propre système de facturation, mais les ingénieurs n’aiment pas cela, et le coût d’embauche d’ingénieurs dédiés est également élevé
- Timothée Lacroix, cofondateur et CTO de Mistral.ai, a expliqué avoir choisi Lago en raison de sa confiance dans l’écosystème open source, ajoutant que Lago leur avait permis de suivre le rythme des releases tout en restant concentrés sur leur cœur de métier
Concurrence et prochains axes d’expansion
- Sur le marché de la facturation, on trouve déjà des solutions proposées par de grandes entreprises technologiques comme Stripe, Adyen, Salesforce, Zoho et Paddle
- Il existe aussi des fournisseurs historiques ayant adopté une approche open source
- FOSSBilling
- ChargeBee
- Kill Bill
- jBilling d’AppDirect
- Open Source Billing
- Lago estime que, même sur un marché très concurrentiel, il existe une opportunité autour de la scalabilité et de la mise en œuvre d’une facturation adaptée à chaque startup
- À l’avenir, l’entreprise prévoit d’étendre son activité actuelle tout en explorant deux domaines
- L’analyse de données, en lien avec son idée marketing d’origine : fournir des informations sur ce que les clients consomment et paient, ainsi que sur leurs habitudes de paiement
- Le paiement, soit l’autre versant de la facturation
- Il est peu probable que Lago construise sa propre payment stack ; l’entreprise pourrait plutôt se concentrer sur l’orchestration des paiements, afin que les utilisateurs puissent continuer à utiliser les outils de paiement de leur choix tout en les intégrant efficacement à la plateforme de facturation
2 commentaires
Lago a vraiment beaucoup insisté sur la comparaison avec Stripe... et comme prévu, ils ont levé beaucoup d’argent.
Ils avaient aussi publié des articles comme Le vrai prix de Stripe : guide d’introduction.
Cela dit, l’idée d’une API de billing open source semble quand même un peu paradoxale.
Avis sur Hacker News
J’ai voulu l’utiliser pour un nouveau produit SaaS, mais j’ai été surpris de voir que les tarifs commençaient à 3 000 $/mois
Ça semble aller dans le sens inverse. Une petite équipe comme la mienne ne veut pas faire de self-hosting, mais plutôt une solution managée. Les grandes entreprises, elles, ont l’échelle nécessaire et donc davantage les moyens de l’auto-héberger
Quelques années plus tard, quand le volume de transactions a augmenté, on a voulu renégocier le contrat ; si on avait pu réintégrer avec Lago à ce moment-là, ça aurait probablement servi de levier lors du renouvellement avec Stripe. On payait 30 k$ par mois en frais Stripe, donc une alternative à 3 k$/mois aurait très bien pu valoir le coup. Notre cas était un peu différent, car c’était du retail et non de la facturation SaaS, mais je vois des situations où ça tient financièrement la route
J’ai parlé avec environ cinq fournisseurs d’API de facturation à l’usage, et en pratique presque personne ne s’intéressait au marché à moins de 1 000 $/mois où nous resterons probablement pendant notre phase de croissance l’an prochain. En plus, Lago et d’autres mettent en avant l’absence de partage de revenus, mais finissent toujours par proposer un prix basé sur un pourcentage du chiffre d’affaires. Techniquement, ce n’est pas du revenue share, mais le coût augmente presque linéairement avec les revenus
Éviter les petits clients, coûteux en support et peu rentables, laisser Stripe perdre de l’argent avec eux, puis ne récupérer que les bons clients déjà développés chez Stripe : si c’est leur stratégie tarifaire, c’est assez malin
Je pense que vendre aux développeurs sera difficile. Les développeurs ne dépensent pas d’argent, et même si le coût d’opportunité est 10 fois supérieur, ils préfèrent le faire eux-mêmes
Et dès qu’on essaie de monétiser d’une façon ou d’une autre, on risque une fuite massive au nom de la « trahison », comme avec Redis. Je le sais, je suis ce genre de développeur
J’avais absolument besoin d’un portail client, mais c’était une fonctionnalité premium, et le premium commençait à 1 500 $/mois minimum. Avec mon chiffre d’affaires, c’était difficile à justifier. Cela dit, Lago évite délibérément la tarification au pourcentage du revenu, donc ils sont pratiquement obligés de facturer un abonnement de base plus élevé. Stripe Billing facture en pourcentage, et pour une activité en croissance, ce n’est qu’une question de temps avant que la facture Stripe dépasse 1,5 k$
J’ai aussi étudié la facturation à l’usage de Stripe Billing, mais elle ne répondait pas à mes besoins. J’utilise Stripe Billing pour la facturation forfaitaire
Mon besoin exact était de vendre des crédits API prépayés inclus dans un abonnement. Par exemple, si un utilisateur prend 10 $ de crédits mensuels, il paie d’abord 10 $, puis consomme ces crédits. Stripe Billing ne prend pas en charge la facturation anticipée en usage-based billing et ne facture qu’à la fin de la période de facturation. Certains utilisateurs pouvaient exploiter le système en annulant puis en ne payant pas, donc ce n’était pas adapté à mon cas. Si je me souviens bien, Lago prenait en charge la facturation anticipée
Je voulais aussi pouvoir mélanger librement des crédits d’abonnement et des crédits prépayés. Quand un utilisateur dépassait son quota mensuel, je préférais qu’il recharge ponctuellement plutôt que de passer au forfait supérieur. Je devais aussi contrôler quels crédits étaient consommés en premier, et là encore Stripe Billing comme Lago posaient problème
Je voulais également prendre en charge le plus de moyens de paiement possible, en particulier pour les crédits prépayés, notamment des wallets chinois comme Alipay et WeChat. Lago ne prévoyait pas de l’implémenter, et j’ai même à moitié envisagé de l’ajouter moi-même dans Lago. En B2B, WeChat et Alipay sont peut-être moins importants
J’aime aussi le code avec des tests de régression très poussés, et sur ce point Stripe Billing est très en avance sur Lago grâce à la fonctionnalité de test clocks. Lago n’a pas de fonction permettant d’avancer le temps pour tester le cycle de vie des abonnements. Si on fait confiance au produit, il suffit peut-être de s’attendre à recevoir les bons callbacks au bon moment, donc c’est peut-être moins important
Cela dit, j’ai vu les développeurs de Lago prendre le temps de répondre sur Slack à des questions techniques très pointues. Si je dirigeais une startup B2B, surtout à une période où l’on voit beaucoup de cas de comptes Stripe suspendus, j’aurais probablement essayé de faire rentrer Lago dans l’équation d’une manière ou d’une autre
Et j’ai l’impression que c’est précisément l’hypothèse centrale de Lago : les développeurs veulent un logiciel de facturation open source qu’ils peuvent modifier eux-mêmes si nécessaire, plutôt que de dépendre d’un fournisseur monopolistique comme Stripe. Ce n’est pas une idée si absurde
Comme le dit le commentaire à côté, je paie volontiers pour ce qui crée de la valeur et me fait gagner du temps. Je n’ai d’ailleurs jamais envisagé de construire mon propre système de facturation
Je suis peut-être devenu trop vieux et ma compréhension de ce que signifie l’open source n’a peut-être pas suivi l’évolution du réel, mais quand je vois open source et « $22M de financement » dans la même phrase, ma première réaction est immédiatement : « mon œil, l’open source »
J’ai souvent vu ce sentiment, y compris chez des vétérans de l’open source comme rich harris. Ironiquement, il est aujourd’hui lui-même payé avec de l’argent de VC. D’un côté, j’ai moi aussi envie de râler et de dire que les gens devraient créer des logiciels ouverts juste pour le plaisir de construire et de partager. Mais dans le monde réel, vivre coûte cher, et il me semble improductif et injuste d’attendre de quelqu’un qu’il développe le logiciel que j’utilise utilement, et dont je tirerai peut-être même un revenu, le soir et le week-end, en échange de simples étoiles GitHub
Dans le cas de Lago, à part la visibilité et la sympathie des développeurs, je ne vois pas très bien l’intérêt de l’open source. Aujourd’hui, construire en open source ressemble à une impasse dans tous les cas, et si c’est cela l’avenir qui permet plus de longévité et de support, alors j’imagine qu’il faut l’accepter
À l’origine, au milieu des années 1970, l’esprit de l’open source consistait à partager gratuitement le logiciel. L’argent venait sous forme de subventions universitaires ou de recherche en entreprise, il n’y avait pas de modèle économique. En 1998, avec RedHat, MySQL et d’autres, l’argent a vraiment commencé à entrer quand ils ont ajouté du support et des services payants par-dessus le logiciel libre. À partir du milieu des années 2000, avec le cloud computing, l’idée de gagner de l’argent avec l’open source est devenue courante. Dans le SaaS, l’utilisateur ne sait pas forcément — ou ne se soucie pas — de savoir si l’intérieur est open source ou propriétaire, donc l’open source s’est retrouvé sur le même terrain de jeu
Il y a plusieurs raisons pour lesquelles les VC aiment l’open source. Je suis investisseur et ancien ingénieur machine learning, et personnellement j’ai aussi une forme de nostalgie pour d’excellents projets open source comme spaCy, que j’utilisais à l’université ; je partage aussi des valeurs comme la communauté, la transparence et le fait de rendre à la communauté. Mais en même temps, le métier d’un VC, c’est de gagner de l’argent
Les entreprises en code source fermé dépensent énormément en ventes et en marketing. En général, les développeurs détestent se faire vendre quelque chose : ils veulent choisir eux-mêmes plutôt qu’être persuadés. Si une entreprise gagne le cœur des développeurs, son logiciel se retrouve dans la short list d’achat sans qu’elle ait à dépenser des millions en ventes et marketing, ce qui rend le modèle économique plus efficace. Et c’est aussi une meilleure défense. Les grandes entreprises peuvent déverser de l’argent sur des commerciaux en costume pour vendre leurs produits, mais elles ne peuvent pas acheter l’amour des développeurs. Pour cela, il faut une excellente expérience développeur et de bonnes relations développeurs
Cela dit, gagner de l’argent avec l’open source est bien plus difficile qu’avec le SaaS. Dans le SaaS, on parle de product-market fit : si l’on trouve plus de cinq clients qui utilisent le produit de la même manière, l’achètent de la même manière et en tirent la même valeur, on obtient une certaine prévisibilité, et les VC financent alors l’expansion commerciale. Dans l’open source, le problème est trois fois plus compliqué. Il faut évaluer l’adéquation projet-communauté via les GitHub Stars, l’adéquation produit-marché via les téléchargements, et l’adéquation valeur-marché via le chiffre d’affaires. En plus, l’acheteur peut ne pas être le développeur ni même l’utilisateur. La plupart des excellents produits open source échouent sur l’adéquation valeur-marché
La plupart des fondateurs d’entreprises open source échouent à capter de la valeur. Soit c’est trop difficile, soit ils repoussent la monétisation parce qu’ils ont le sentiment que l’open source doit être du « logiciel gratuit ». Et quand ils commencent enfin à monétiser, il est déjà trop tard. Si vous avez reçu du lait gratuitement pendant des années, allez-vous acheter la vache ? Une autre raison est qu’ils ne savent tout simplement pas comment s’y prendre. Les moyens classiques de gagner de l’argent avec l’open source sont la vente de support et de services, l’open core qui vend des fonctionnalités propriétaires, et le SaaS qui vend l’hébergement et les outils. On peut citer RedHat, Confluent, Elastic et Databricks
Si l’on simplifie à partir des entreprises open source qui ont réussi, la version gratuite doit offrir tout ce qu’il faut pour qu’un développeur seul puisse terminer son travail. Le produit payant, lui, doit fournir les fonctionnalités supplémentaires nécessaires pour qu’une équipe puisse terminer le sien
J’aime l’open source, et cela me rend triste de voir des fondateurs extrêmement brillants et d’innombrables contributeurs investir leur passion dans un projet sans réussir à le faire grandir ni à en être récompensés. La commercialisation peut aider, mais c’est vraiment difficile. Les personnes qui contribuent à l’open source et en créent attachent beaucoup d’importance à la communauté et veulent donner gratuitement ; l’idée même de gagner de l’argent leur devient donc inconfortable. Et quand on est mal à l’aise, on revient à ce qu’on connaît, et pour la plupart des ingénieurs, c’est coder. C’est ainsi qu’on se retrouve avec un excellent logiciel open source plein de super fonctionnalités, et des fondateurs qui ont trop longtemps retardé la monétisation. À un moment donné, ils franchissent le point de non-retour, une nouvelle entreprise prometteuse meurt, et aussi bon que soit le produit, les investisseurs n’investiront pas s’ils ne peuvent pas récupérer leur argent
S’il faut quand même continuer à payer les frais de traitement, quel est l’avantage ici ?
Si je dois maintenir ma propre stack de paiement et la conformité PCI, cela me semble être une distraction énorme
Le suivi des paiements récurrents, des factures, des changements de forfait au prorata et des cas limites de la facturation à l’usage est difficile. Et l’API Stripe Billing n’est pas particulièrement élégante dans bien des cas. Je suis donc content de voir apparaître une nouvelle couche dans cet espace
Pour référence, j’ai fondé Very Good Security et j’en ai été le CEO pendant 8 ans
Il existe aussi l’open source https://hyperswitch.io écrit de façon similaire en Rust
Lago est écrit en Ruby, et j’ai aussi trouvé quelques autres systèmes de facturation open source écrits en Java. Quelqu’un en connaît un en Node.js ?
Paris semble vraiment être un endroit en ébullition pour faire émerger de nouvelles startups fintech
À l’inverse, il y a aussi en France de très bons contre-exemples partis d’excellentes intentions. Par exemple, Semmle [1] a été racheté par GitHub pour son analyse statique de dépôts. Inria [2] est également excellent, mais le problème n’est pas la recherche : c’est la manière de rivaliser, au niveau business, avec les entreprises à l’américaine
[1] https://en.wikipedia.org/wiki/Semmle
[2] https://www.inria.fr/en
Ils utilisent le mème Drake dans le README GitHub
https://github.com/getlago/lago
https://imgur.com/a/gsrhUXm
Je ne pensais pas voir la mémification de la documentation technique… mon dieu
Quelqu’un connaît une vraie alternative à Stripe Payments ? Stripe n’a pas envie de travailler avec nous, et comme ils ne veulent travailler qu’avec des concurrents closed source, on se retrouve coincés avec PayPal
Pour information, j’y travaille
Ce n’est pas une alternative à Stripe
La facturation, les factures, les paiements, les autorisations et les abonnements sont tous des choses différentes
Cela signifie que nous voulons proposer une alternative ouverte sur l’ensemble de la RevOps. Au lieu d’entrer dans un écosystème closed source comme Stripe, l’idée est de pouvoir construire une stack sur mesure et d’y connecter des outils de longue traîne, des cas d’usage et des systèmes internes avec une approche « best-of-breed ». Stripe a 21 produits, et beaucoup de fondateurs ne réalisent pas qu’ils n’utilisent pas seulement « Stripe payments », mais en utilisent 3 à 6, et que chacun prélève généralement une partie du revenu
Ils ont levé 15M en Series A, et la valorisation n’a pas été annoncée, mais la rumeur parle de 100M
D’après Crunchbase, les 7M correspondaient à leur seed de 2023. En lisant le dernier paragraphe de l’article lié, on dirait qu’ils ne cherchent pas à remplacer Stripe dans son ensemble. Quoi qu’il en soit, c’est une histoire intéressante de pivot réussi de startup, partie d’un post HN passionné