Hemmelig archive son dépôt : ce que la fin d’un mainteneur solo enseigne aux self-hébergeurs
Le 5 octobre 2026, Hemmelig, la plateforme open source de partage de secrets chiffrés, a archivé son dépôt GitHub et cessé tout correctif, tout en laissant tourner le service hébergé dans une direction distincte. Pour un self-hébergeur, c’est un rappel concret : la pérennité d’un outil dépend d’un mainteneur, pas de sa popularité, et il faut un plan de sortie.
5 octobre 2026. Le dépôt GitHub de Hemmelig est archivé par son propriétaire : plus de correctifs, plus de fonctionnalités, plus de releases. 1 235 commits. C’est le volume de travail accumulé par le projet avant l’archivage — et il devient figé, en lecture seule, du jour au lendemain. 10 octobre 2026. La nouvelle circule dans la lettre Self-Host Weekly. Pourquoi c’est important : Hemmelig illustre un risque structurel du self-hosting que peu d’outils documentent — la dépendance à un mainteneur unique, dont la décision de continuer ou non conditionne la sécurité de tous ceux qui ont installé le logiciel.
Ce que Hemmelig faisait, et comment
Hemmelig est un service de partage de secrets chiffrés : il sert à transmettre un mot de passe, une clé API ou une note sensible via un lien à usage unique qui s’autodétruit après lecture, au lieu de laisser traîner l’information dans un chat ou un e-mail. Son architecture est zero-knowledge : le chiffrement se fait dans le navigateur, le serveur ne stocke que des données chiffrées et ne voit jamais ni le secret ni la clé. L’utilisateur règle une expiration, un nombre maximal de lectures et un mot de passe optionnel, puis partage le lien.
Le déploiement en self-hosted passait par Docker, sans conteneur supplémentaire, et le projet embarquait l’essentiel de ce qu’on attend d’un service moderne : une API REST avec spécification OpenAPI, des métriques Prometheus, des sondes de santé et une génération de SDK. En résumé, un outil mature et bien tenu — jusqu’à l’archivage.
# Déploiement Hemmelig via Docker (dépôt archivé, image toujours sur Docker Hub)
docker pull hemmeligapp/hemmelig:latest
docker run -d -p 3000:3000 -e SECRET_LOCAL_HEMMELIG_KEY="changez-moi" hemmeligapp/hemmelig:latestLa nuance est dans l’avis d’archivage lui-même. Le dépôt est en lecture seule et ne recevra plus de correctifs, mais les forks restent autorisés, à condition de conserver les termes de la licence O’Saasy — une licence dérivée du MIT qui interdit de concurrencer l’éditeur en proposant un SaaS hébergé. Et surtout, le service hébergé à hemmelig.app continue de fonctionner, mais « se développe désormais dans sa propre direction, séparée de ce dépôt ». Autrement dit : le code public s’arrête, le service privé continue.
Le signal d’alarme : licence, mainteneur et divergence
Cette configuration — code public gelé, service propriétaire qui continue — est le signal le plus instructif de l’épisode. Quand un projet open source s’archive en conservant un service hébergé actif, le self-hébergeur ne perd pas seulement des correctifs : il perd la traçabilité entre ce qu’il installe et ce qui continue d’évoluer côté éditeur. Les correctifs de sécurité futurs, s’il y en a, iront au service hébergé, pas au dépôt que vous avez cloné.
La licence O’Saasy ajoute une couche à connaître. Un fork est légalement possible, mais la clause « pas de concurrence SaaS » restreint ce qu’un repreneur peut en faire. Dans la pratique, les 124 forks du dépôt sont autant de points de départ potentiels, mais aucun n’a l’élan, les contributeurs ou la légitimité de l’original. Le résultat est classique dans l’open source solo : le code survit, la maintenance meurt.
C’est le cœur du problème. Hemmelig n’a pas échoué faute de qualité — le projet était propre, testé, documenté. Il a atteint la fin d’un cycle de vie individuel : son mainteneur, Bjarne Øverli, a décidé d’arrêter le développement public. Dans un écosystème où des dizaines d’outils self-hosted reposent sur une personne, cette décision est le risque numéro un, loin devant les failles que l’on redoute tous.
Comment évaluer le risque de maintenance d’un outil
L’épisode Hemmelig fournit une grille d’évaluation concrète avant d’adopter un outil self-hosted. D’abord, regardez qui maintient : un dépôt avec un seul contributeur actif porte un risque de « bus factor » égal à un — la moindre absence suspend les correctifs. Ensuite, mesurez la fréquence des releases et des correctifs de sécurité sur les douze derniers mois : un projet vivant publie régulièrement, un projet moribond répond rarement aux issues de sécurité. Enfin, regardez la licence sous l’angle de la reprise : une licence permissive classique laisse la porte ouverte à un fork communautaire, une licence restrictive comme O’Saasy complique la succession.
Pour un service qui manipule des secrets, la question est encore plus tranchée. Un gestionnaire de secrets ou un outil de partage chiffré non maintenu n’est pas un logiciel « qui marche encore » : c’est une surface qui ne recevra plus de correctifs, et dont les dépendances — Node, Prisma, les bibliothèques de chiffrement — accumuleront des failles sans que personne ne les referme. Le chiffrement côté client de Hemmelig protège le contenu, mais il ne protège pas le serveur lui-même d’une exploitation via une dépendance obsolète.
Les alternatives à connaître
La bonne nouvelle, c’est que le créneau du partage de secrets éphémère est bien fourni en self-hosted. Yopass, PrivateBin, Password Pusher et Onetime Secret couvrent tous le même besoin — chiffrement côté client, lien à usage unique, expiration — avec des degrés variés de maturité. Password Pusher est notoirement actif et simple à déployer ; PrivateBin est un vétéran du partage de texte chiffré ; Yopass reste populaire chez les équipes techniques. Pour un besoin minimal, une note chiffrée dans PrivateBin suffit souvent là où Hemmelig apportait plus d’options (fichiers, QR, webhooks).
Le choix d’un remplaçant doit appliquer la même grille qu’au-dessus : mainteneur multiple si possible, historique de correctifs récent, licence de reprise claire. Migrer d’un outil archivé vers un autre outil à mainteneur unique ne fait que déplacer le risque.
Verdict
Si vous utilisiez Hemmelig en self-hosted, ne paniquez pas mais ne restez pas non plus sur un dépôt archivé : vos secrets déjà partagés ont expiré ou sont chiffrés, mais l’instance ne recevra plus de correctifs — planifiez la migration vers Yopass, PrivateBin ou Password Pusher dans les prochaines semaines, en exportant vos usages plutôt que vos données. Si vous dépendez d’un service hébergé chez hemmelig.app, sachez que sa feuille de route est désormais séparée du code public et décidez si vous acceptez cette divergence. Et avant d’adopter n’importe quel outil self-hosted, posez la question du mainteneur avant celle des fonctionnalités : un logiciel qui manipule vos secrets vaut par la continuité de sa maintenance, pas par la richesse de son interface. La leçon d’Hemmelig tient en une phrase — un dépôt peut mourir un mardi, et vos correctifs avec lui.