Tencent finance Godot à 18 M$ — j’ai arrêté de croire que l’open source ne payait pas, voici les 4 modèles qui marchent

J’ai passé une bonne partie de ma carrière à défendre l’open source auprès de clients qui me répondaient invariablement la même chose : « oui, mais qui paie ? ». Pendant longtemps, ma réponse honnête était : personne, ou presque. La plupart des bibliothèques dont dépend votre application sont maintenues le soir, gratuitement, par des gens qui ont un vrai travail à côté.

L’annonce du 25 août 2026 ne renverse pas ce constat, mais elle documente une exception qui devient un modèle. W4 Games lève 18 millions de dollars en Série B, sous la conduite de Tencent, avec à ses côtés OSS Capital, LUX, Naval Ravikant et le family office de Tobias Lütke, le fondateur de Shopify. La société porte son total levé à 33 millions de dollars et annonce vouloir agrandir son équipe internationale d’environ 50 % et accélérer son offre destinée aux entreprises.

Le détail qui compte pour nous, développeurs : W4 Games a été créée en 2021 par Juan Linietsky, le créateur du moteur Godot, entouré de mainteneurs du projet comme Fabio Alessandrelli et Rémi Verschelde, avec Nicola Farronato comme co-dirigeant. Autrement dit, ce sont les gens qui écrivent le code libre qui ont monté la structure commerciale — et non un fonds qui aurait acheté le projet pour le fermer.

Ce qui a été annoncé — et ce qui ne l’a pas été

Reprenons précisément, parce que ce genre d’annonce circule vite en version déformée.

• Le fait : Série B de 18 millions de dollars dans W4 Games, menée par Tencent, annoncée le 25 août 2026.
• Les co-investisseurs : OSS Capital, LUX, Naval Ravikant, family office de Tobias Lütke.
• L’usage annoncé des fonds : croissance de l’équipe internationale d’environ 50 %, développement de l’offre entreprise, réponse à la demande des studios utilisant Godot.
• Le volet stratégique : un partenariat pluriannuel avec Tencent pour développer l’écosystème Godot en Asie.
• Ce qui n’a pas été annoncé : aucun changement de licence de Godot, aucune prise de contrôle du projet, aucune modification de sa gouvernance par la fondation. Le moteur reste sous MIT.

Cette dernière ligne est celle que je vois le plus mal comprise. Godot et W4 Games sont deux entités distinctes. Le moteur appartient à sa communauté sous une licence permissive irrévocable ; W4 Games vend des produits et services autour de lui. Un investisseur qui entre au capital de W4 Games n’acquiert aucun droit sur le code de Godot — il achète une part d’une entreprise dont le produit s’appuie sur ce code, comme n’importe qui pourrait le faire.

Les 4 modèles open source qui produisent vraiment des revenus

Après quinze ans à contribuer et à conseiller des éditeurs, voici les seuls schémas que j’ai vus financer durablement des salaires. Le tour de W4 Games relève clairement du premier.

1. La société commerciale satellite

Le projet reste libre et gouverné par une fondation ; une entreprise distincte, souvent fondée par les mainteneurs eux-mêmes, vend ce que le projet ne vend pas : support contractuel, briques propriétaires pour les cas d’usage professionnels, portages vers des plateformes fermées, mise en conformité. C’est le modèle de W4 Games, et c’est celui qui aligne le mieux les intérêts — l’entreprise a besoin que le projet libre reste sain, puisque c’est son socle.

Son point faible : il exige une masse critique d’utilisateurs professionnels. En dessous de quelques milliers d’entreprises utilisatrices, le marché du support n’existe pas.

2. L’hébergement managé

Vous publiez le logiciel librement, et vous vendez le fait de ne pas avoir à l’exploiter soi-même. C’est le modèle le plus rentable de la liste et le plus simple à expliquer à un directeur financier. C’est aussi le plus exposé : un fournisseur de cloud plus gros que vous peut proposer le même service, ce qui a provoqué la vague de changements de licences que l’écosystème a connue ces dernières années.

3. Le double licenciement

Le projet est publié sous une licence copyleft, et une licence commerciale est vendue à ceux que le copyleft gêne — typiquement les intégrateurs qui veulent embarquer la bibliothèque dans un produit fermé. Modèle éprouvé, revenus prévisibles, mais il impose de détenir l’intégralité des droits, donc de faire signer une cession de droits à chaque contributeur. En pratique, cela décourage les contributions externes et le projet devient l’œuvre d’une seule entreprise.

4. Le financement par les industriels dépendants

Les entreprises dont l’activité repose sur un projet le financent directement, par des salaires de mainteneurs ou des contributions à une fondation. C’est ce qui finance la plupart des grands projets d’infrastructure. Le risque est ailleurs : la feuille de route s’aligne progressivement sur les besoins des gros contributeurs, et les usages minoritaires sont progressivement délaissés.

Et le cinquième, celui qui ne marche pas

Les dons individuels. J’ai maintenu une bibliothèque utilisée par plusieurs milliers de projets ; les dons couvraient l’hébergement et à peu près rien d’autre. Les plateformes de dons sont utiles pour signaler la reconnaissance d’une communauté, elles ne remplacent pas un modèle. Un projet qui ne repose que sur les dons est un projet à mainteneur unique en sursis — et c’est précisément le profil de risque que documentent les attaques de chaîne d’approvisionnement des deux dernières années.

Ce que ça change pour un développeur ou une agence en France

Trois conséquences pratiques, dans l’ordre où je les mettrais en œuvre.

D’abord, l’argument commercial devient défendable. Proposer un socle libre à un client se heurtait toujours à la question de la pérennité. Vous disposez désormais d’un contre-exemple précis et daté : un moteur sous MIT, une fondation qui le gouverne, une société capitalisée à 33 millions qui vend le support professionnel, et des industriels qui financent l’écosystème. Ce n’est pas une promesse idéologique, c’est une structure vérifiable.

Ensuite, le critère de choix se déplace. La bonne question n’est plus « libre ou propriétaire ? » mais « quelle est la structure de gouvernance et qui paie les mainteneurs ? ». Un projet propriétaire adossé à un éditeur solide peut être plus sûr qu’un projet libre maintenu par une personne épuisée. Inversement, un projet libre sous licence permissive avec une fondation et plusieurs financeurs offre une garantie qu’aucun contrat commercial ne procure : l’impossibilité de revenir sur ce qui a déjà été publié.

Enfin, il faut regarder les licences transitives. Un projet MIT peut embarquer une dépendance sous licence copyleft, et c’est elle qui s’appliquera à votre livraison. Nous détaillons la méthode complète dans notre guide sur l’audit des dépendances npm en 7 étapes, et le raisonnement vaut à l’identique pour un écosystème de greffons de moteur.

Les 3 choses à vérifier avant de bâtir sur un projet libre

1. La licence réelle, dépendances transitives comprises. Lisez le fichier de licence du dépôt principal, puis produisez l’inventaire des licences de l’arbre complet. Un socle permissif avec une brique copyleft enfouie à trois niveaux vous impose ses obligations, et vous ne le découvrirez qu’au moment de la livraison.
2. La gouvernance, nommément. Qui a le droit de fusionner du code ? Qui arbitre la feuille de route ? Une fondation, une entreprise unique, ou une personne ? La réponse change complètement votre profil de risque et se trouve en général dans le fichier de gouvernance du dépôt.
3. Le nombre de mainteneurs réellement actifs sur douze mois. Pas le nombre de contributeurs cumulés depuis la création, qui ne veut rien dire. Un projet à mainteneur unique est un risque opérationnel documenté, et pas seulement en matière de sécurité.

Sur le volet sécurité de ces dépendances — durcissement des chaînes de publication, gestion des secrets et rotation — nos confrères de WebGuard Agency documentent régulièrement les vecteurs constatés en France. Et si votre stack embarque des briques d’IA, les équipes de Plug-Tech ont publié une analyse utile sur la concentration de la couche de distribution des modèles, qui pose exactement le même problème de dépendance non contractualisée.

Si vous démarrez un projet et hésitez sur le socle technique, notre guide comment créer une marketplace détaille les arbitrages entre briques libres et services managés, budget à l’appui.

Questions fréquentes