Huit mois à chercher quelqu'un pour prendre la relève

Pavel Djundik a lancé SteamDB en 2013 comme projet parallèle suivant les prix, le nombre de joueurs et l'historique des mises à jour sur la plateforme Steam de Valve. Cette année, le site était devenu quelque chose que les journalistes du jeu vidéo citaient comme source statistique, que les acheteurs de Steam Deck consultaient pour les notes de compatibilité, et sur lequel des outils tiers s'appuyaient discrètement, le tout pendant que Djundik le gérait seul. En janvier 2026, il a commencé à chercher discrètement un repreneur, non pas pour encaisser un gain, mais parce que la tâche avait dépassé ce qu'une seule personne pouvait tenir : les coûts d'hébergement, les limites de débit de l'API, la lutte contre les abus et les demandes de fonctionnalités continuaient de croître avec le trafic, alors que son temps disponible non.

En septembre 2026, il a vendu SteamDB à Chosen, l'entreprise derrière Nexus Mods, fondée par son PDG Victor Folmann. Djundik a décrit sa recherche comme celle d'une équipe qui comprenne ce que signifie être responsable de quelque chose dont dépend une communauté, présentant l'accord autour de la pérennité plutôt que d'une sortie lucrative. Le prix n'a pas été dévoilé.

Personne n'a rien signé, tout le monde en dépendait

Ce qui rend cette histoire plus qu'une note de bas de page dans l'actualité du jeu vidéo, c'est ce qu'était réellement SteamDB en pratique : une infrastructure non rémunérée et informelle autour de laquelle un grand nombre d'acteurs extérieurs avaient discrètement bâti leurs flux de travail. Nexus Mods elle-même a décrit la situation en disant que des millions de joueurs, de développeurs et d'éditeurs dépendaient d'un service sans accord de niveau de service, sans plan de succession et sans aucun organe surveillant ce qui se passerait si son unique mainteneur se retirait. Il n'y avait aucun contrat parce qu'il n'y avait aucun fournisseur, juste une personne avec un site web et un sentiment d'obligation grandissant envers tous ceux qui l'utilisaient.

Cette situation n'a rien d'inhabituel. C'est la condition par défaut d'une énorme partie de l'infrastructure que l'industrie technologique traite comme allant simplement de soi : la bibliothèque open source d'un mainteneur unique, une API gratuite que le produit principal d'une startup appelle discrètement des milliers de fois par jour, une base de données gérée par la communauté qui survit à toute autre partie de la pile d'origine d'une entreprise. Les incidents de left-pad en 2021 et de xz-utils en 2024 ont fait la même démonstration sur le code ; SteamDB la fait sur un service de données vivant et d'usage public.

La décision que personne n'a prise avant d'y être forcé

Djundik a pris la décision responsable qui s'offrait à lui : passer huit mois à chercher un gardien avant que l'épuisement ne force un résultat pire, un site qui se dégraderait, disparaîtrait ou serait vendu au plus offrant sans égard à ses intentions. Mais la décision la plus difficile, celle qui n'a jamais été prise, revenait à tous ceux qui ont bâti un flux de travail sur SteamDB sans se demander ce qui se passerait s'il arrêtait discrètement. Nexus Mods contrôle désormais des données que le journalisme du jeu vidéo et les outils tiers traitent comme une source de référence, et sa propre déclaration selon laquelle SteamDB doit générer des revenus est un signal, pas une menace, que les conditions de cette dépendance peuvent changer.

Nexus Mods mérite d'être crédité pour avoir bien géré la transition : pas d'intégration forcée de compte, pas de publicité pour l'instant, et un engagement public à préserver les fonctionnalités gratuites existantes. C'est la meilleure version possible de cette transition. La question inconfortable qu'elle laisse à toute entreprise ne concerne pas SteamDB en particulier. C'est de savoir si le même audit a déjà été fait en interne : de quel outil gratuit, quelle bibliothèque maintenue par une seule personne, quelle API non officielle votre propre flux de travail dépend-il, et quel est le plan réel pour le jour où son mainteneur s'épuisera.

Ce qu'il faut vraiment vérifier cette semaine

Menez un véritable audit de dépendances sur tout ce qui est destiné aux clients ou génère des revenus : listez chaque service externe ou bibliothèque que votre système appelle et qui est maintenu par une seule personne ou une équipe d'une à trois personnes, sans contrat de support commercial derrière. Pour chacun, notez ce qui casserait s'il disparaissait sans préavis, et s'il existe une alternative comparable vers laquelle votre équipe pourrait basculer en une semaine. Si la réponse honnête, ne serait-ce que pour un seul élément, est que plus rien ne fonctionnerait et qu'il n'existe aucun plan, ce n'est pas un problème propre à l'industrie du jeu vidéo. C'est le même risque sans prix qui vient de changer de mains chez SteamDB, tapi discrètement au sein d'une entreprise qui n'a pas encore connu son propre moment de janvier 2026.