5 signaux pour évaluer la pérennité d'une app self-hosted

L'open-source repose sur une promesse fonctionnelle : le code est lisible, modifiable, redistribuable. Cette promesse est contractuelle — elle est inscrite dans la licence. Ce qui n'est pas inscrit, c'est la continuité des fonctionnalités gratuites, la stabilité du périmètre, ou la pérennité des mainteneurs.

Les ruptures observées en 2025-2026 n'ont pas toutes la même nature. Certaines relèvent d'une décision commerciale délibérée (Planka, Grist, Portainer) : une fonctionnalité existante migre dans un tier payant. D'autres sont des glissements d'architecture (Netdata) : les fonctionnalités avancées nécessitent progressivement le cloud de l'éditeur. D'autres encore sont des risques de gouvernance (Jellyfin) : les mainteneurs principaux partent, et personne ne sait si le projet survivra.

Pour une agence, ces trois scenarii ont des conséquences très différentes — mais tous se détectent en amont, avec les bons indicateurs.

La première question n'est pas technique, elle est juridique : qui contrôle le dépôt, la marque et les décisions stratégiques ?

Une LLC ou une SAS avec un seul actionnaire signifie qu'une décision individuelle peut changer le modèle du jour au lendemain. Planka est exploité par une société commerciale qui peut, à tout moment, définir ce qui relève du « Community » et ce qui relève du « Pro ».

Une fondation à but non lucratif (Software Freedom Conservancy, Apache Software Foundation, Linux Foundation) ou une coopérative de contributeurs (modèle Codeberg) crée une friction institutionnelle avant tout changement de cap. Les statuts imposent un vote, une transparence, un délai. Ce n'est pas une garantie absolue, mais c'est un frein vérifiable.

Comment vérifier. Le fichier GOVERNANCE.md ou MAINTAINERS.md à la racine du dépôt. La page « About » de l'organisation GitHub. Le registre des marques (USPTO, EUIPO). Si le projet est sous un Fiscal Sponsor (Open Collective Foundation, NumFocus), la page de l'entité tutélaire. Jellyfin, par exemple, est hébergé sous la Software Freedom Conservancy — ce qui a contribué à ce que le projet survive au départ de ses fondateurs.

Un projet open-source qui ne reçoit plus de commits depuis 18 mois n'est pas « stable » — il est en fin de vie non déclarée. La vélocité de contribution mesure la capacité du projet à absorber les bugs de sécurité, à suivre les dépendances, à intégrer les correctifs.

Indicateurs à mesurer. Le GitHub Pulse sur 30 jours : nombre de commits, de pull requests ouvertes et fermées, de contributeurs actifs. La cadence de release : un projet sain publie des versions régulières, même mineures. Le temps de réponse moyen sur les issues critiques (label bug, security). Le ratio closed/open sur les issues de plus de 90 jours.

Via l'API GitHub, la commande suivante donne le pulse brut : curl "https://api.github.com/repos/<owner>/<repo>/stats/commit_activity" retourne 52 semaines de commits. Un projet dont la moyenne des 12 dernières semaines est inférieure à 2 commits par semaine mérite une attention particulière.

Ce que ça ne dit pas. Un projet très actif peut l'être parce qu'il accumule de la dette technique ou des breaking changes fréquents. La vélocité est un signal nécessaire, pas suffisant.

Le modèle de financement d'un projet open-source préfigure sa trajectoire commerciale. Ce n'est pas un jugement moral — un projet a besoin de ressources pour durer — mais un indicateur de risque.

VC-backed : un investisseur attend un retour. La pression sur la monétisation augmente avec le temps. Les fonctionnalités qui étaient gratuites deviennent des leviers de conversion. Grist Labs a reçu des financements avant de restreindre le SSO à son édition Enterprise.

Bootstrapped avec revenu commercial : le modèle économique est connu dès le départ (support, hosting managé, fonctionnalités pro). Le risque est plus prévisible. Planka a toujours eu une version Pro, mais la frontière a bougé sans préavis.

Donations ou subventions uniquement : le projet est vulnérable aux variations de revenus. Mais les décisions commerciales restent rares. Jellyfin fonctionne principalement sur ce modèle.

Comment vérifier. La page Open Collective du projet (montants reçus, dépenses, sponsors). Le fichier FUNDING.yml du dépôt GitHub. Crunchbase pour les levées de fonds. Les issues ou discussions GitHub intitulées sustainability, funding, business model. La question n'est pas « est-ce financé par du VC ? » mais « comment le retour sur investissement est-il prévu, et à quel horizon ? »

La licence open-source dit ce que vous pouvez faire avec le code. Elle ne dit pas ce que l'éditeur fera du code à l'avenir. Deux situations à distinguer.

La licence est permissive ou copyleft classique (MIT, Apache 2.0, GPL, AGPL) : vous avez le droit de forker, modifier, et redistribuer. Si l'éditeur change de cap, vous pouvez continuer avec la dernière version libre. C'est le cas de Jellyfin (GPL-2.0) — toutes les versions publiées restent librement forkables.

La licence est une Business Source License (BSL) ou SSPL : ces licences contiennent une clause de « change date » ou de restriction d'usage commercial. HashiCorp, Elasticsearch, et d'autres ont démontré qu'une migration de licence s'applique aux versions futures, pas aux passées. Un déploiement existant est protégé ; un déploiement futur ne l'est peut-être plus.

Comment vérifier. Le fichier LICENSE à la racine. grep -r 'Business Source License\|SSPL\|Commons Clause' <repo>/ pour détecter les clauses restrictives. L'historique git de LICENSE : une modification récente est un signal d'alerte fort. La page SPDX du projet si elle existe. Un projet peut aussi avoir une double licence (édition community sous AGPL, édition enterprise sous licence commerciale) — ce qui est lisible et prévisible.

La fork-ability est la capacité réelle — pas théorique — de continuer le projet de façon autonome si l'éditeur change de cap. Elle dépend de plusieurs facteurs techniques.

CI publique. Si le pipeline de build est dans .github/workflows/ ou un équivalent public, vous pouvez reproduire les artefacts. Si la CI s'appuie sur des runners privés, des secrets non documentés, ou un système propriétaire, la fork ne compiles pas.

Dépendances propriétaires. Certains projets intègrent des appels à des services de l'éditeur (analytics, licensing, telemetry) qui ne fonctionnent pas sans un compte ou une clé API propriétaire. grep -r 'app.getport.io\|license.example.com\|api.vendor' <repo>/src/ pour détecter ces dépendances.

Code obscurci ou binaires précompilés. Un dépôt qui contient des .jar, .dll, ou des fichiers minifiés sans source correspondante crée des zones opaques dans le fork.

Comment évaluer. Cloner le dépôt et tenter un build local depuis zero en suivant uniquement la documentation publique. Analyser le résultat de docker build — si l'image tire des couches depuis un registry privé de l'éditeur, la fork-ability est compromise. Vérifier que le changelog technique est public et lisible (pas uniquement un flux marketing).

Les cinq cas de 2025-2026 ont un point commun : dans chacun, des signaux étaient lisibles avant la rupture. La structure LLC de Planka, la présence d'investisseurs chez Grist, la roadmap publique de Portainer, la concentration des commits chez Jellyfin — tout cela était dans le dépôt GitHub, dans les issues, dans les changelogs.

La différence entre une agence exposée et une agence sereine tient moins à ses choix d'apps qu'à sa rigueur de qualification. Déployer une stack self-hosted pour un client sans avoir passé ces cinq signaux, c'est accepter implicitement qu'une décision prise dans un bureau à l'autre bout du monde puisse créer une urgence dans votre planning.

L'audit prend 30 à 60 minutes par app. Il se documente en une fiche. Et il se relit une fois par an — ce qui suffit généralement à voir venir les changements avant qu'ils deviennent des incidents.