Open core

Open core, open source et freemium sont trois lignes différentes

Ces termes s'emploient l'un pour l'autre alors qu'ils découpent selon des axes différents. La précision en vaut la peine, car c'est cette différence qui décide de ce qui vous arrive si l'éditeur change d'avis.

• Open source est un fait de licence portant sur le code : la licence vous accorde le droit de l'exécuter, de l'étudier, de le modifier et de le redistribuer. Elle ne dit rien de qui paie quoi.
• Open core est une décision d'emballage par-dessus : une partie du produit porte une licence ouverte et une autre n'existe tout simplement pas en public. La moitié propriétaire est en général le service hébergé, l'authentification unique, les journaux d'audit, les permissions et tout ce que réclament les plus gros clients.
• [Freemium](/glossary/freemium) est une décision de prix à l'intérieur d'un seul produit propriétaire : un palier gratuit et des paliers payants du même logiciel fermé. Rien n'est ouvert et l'auto-hébergement n'est pas sur la table.
• [Tarification à l'usage](/glossary/usage-based-pricing) est orthogonale aux trois — elle décrit comment la facture est calculée, pas ce que vous avez le droit de faire du code.

Un test utile : en freemium, atteindre le plafond signifie que vous changez de palier. En open core, atteindre le plafond signifie que vous changez de palier ou que vous construisez vous-même la pièce manquante, puisque vous avez le reste du système entre les mains. Cette seconde option est toute la valeur du modèle pour qui l'adopte, et elle est réelle plus souvent qu'on ne le suppose.

Lire un dépôt pour voir où passe vraiment la ligne

Nous couvrons régulièrement des outils de croissance open source sur nos pages /grow, et après plus de soixante d'entre eux le motif est assez constant pour devenir une liste de vérification. Ce qu'affirme le badge et l'endroit où se trouve le mur payant sont deux faits distincts, et c'est le second qui décide si l'outil résout votre problème. Cherchez ceci avant d'adopter quoi que ce soit :

• Ouvrez le fichier LICENSE, pas le badge. Le champ licence de GitHub lui-même affiche `NOASSERTION` quand il n'arrive pas à classer ce qu'il a trouvé, et certains dépôts arborant un badge de licence n'ont aucun texte de licence. Pris isolément ce n'est pas une preuve, mais c'est le seul champ où vous ne pouvez pas vous permettre de deviner.
• Cherchez la note de bas de page qui dit disponible uniquement dans le cloud. La forme la plus courante est une liste de fonctions dans le README où une ou deux entrées portent une mention discrète indiquant qu'elles existent dans l'offre hébergée. Si cette entrée est précisément votre raison d'adopter l'outil, vous avez déjà lu toute l'histoire.
• Lisez le tableau comparatif que le projet publie sur lui-même. C'est du marketing, méfiez-vous donc des colonnes concurrentes, mais la colonne qui décrit son propre produit est généralement exacte et révèle ce que les mainteneurs pensent vendre.
• Regardez quels plugins ou modules sont étiquetés comme cœur. Un projet qui marque certaines capacités comme cœur et d'autres comme optionnelles a déjà tracé sa ligne en public, ce qui est bien plus fiable qu'une page de tarifs.
• Vérifiez le détenteur du copyright et l'accord de contribution. Une seule entreprise détenant le copyright peut changer de licence plus tard ; une fondation ou une base large de personnes contributrices rend cela nettement plus difficile. C'est le champ qui prédit ce qui se passera dans trois ans.

docmd, un compilateur de documentation que nous avons présenté le 3 septembre 2026, est un petit exemple net de cette forme rendue lisible : le compilateur et toutes ses sorties de compilation sont sous MIT dans le dépôt, et la seule pièce hébergée — un relais permettant à un site purement statique de faire tourner l'assistant IA sans exploiter de backend — est clairement identifiée comme le service facultatif. En une minute vous savez ce que vous auto-hébergeriez et ce que vous achèteriez, ce qui n'est pas vrai de tous les projets de la catégorie.

Ce que cela implique si vous l'adoptez, et si vous le construisez

Du côté de qui adopte, la question honnête n'est pas de savoir si l'outil est ouvert, mais ce que coûte votre sortie. L'auto-hébergement est gratuit en licence et pas gratuit en heures : quelqu'un assure les mises à jour, les sauvegardes et la panne. Comparez cela à l'offre hébergée à la taille que vous prévoyez dans un an, pas à celle d'aujourd'hui. Ce que vous achetez avec ces heures est cependant réel : vos données restent dans une base que vous contrôlez et, si la feuille de route de l'éditeur s'éloigne de vous, il vous reste un système en marche plutôt qu'une migration.

Si vous créez votre entreprise et envisagez ce modèle pour votre propre produit, il faut voir clairement que l'open core est une stratégie de distribution avant d'être une stratégie de revenus. Il achète de la portée, de la crédibilité auprès des personnes qui développent et un flux de contributions ; il ne produit pas de clients par lui-même, et il vous contraint ensuite, car déplacer une fonction du côté ouvert vers le côté payant fait partie des rares décisions qui coûtent à coup sûr sa bienveillance à un projet. Décidez la ligne avant de rendre le dépôt public, et écrivez-la là où vos utilisateurs peuvent la lire.

Cela ne supprime rien non plus du travail de se faire trouver. Un dépôt ouvert est un canal de distribution avec le même problème que tous les autres : il faut que quelqu'un en entende parler. C'est pourquoi les projets qui gagnent avec ce modèle sont d'ordinaire ceux qui font le travail ordinaire de contenu et de communauté en parallèle de l'ingénierie, et non ceux qui ont supposé que la licence ferait le marketing.