Papermerge se recentre sur le SaaS, sa version open source cherche des mainteneurs

9 ans. C’est la durée de développement open source que Papermerge a capitalisée avant d’annoncer sa bifurcation. Septembre 2026. Le dépôt officiel affiche un statut sans ambiguïté : « Seeking active maintainers (I’m transitioning to SaaS) ». 11 novembre 2026. Le Papermerge Cloud entre en service. Pourquoi c’est important : un système de gestion documentaire est un point de concentration de documents que l’on croyait pérennes, et le départ du mainteneur unique remet cette pérennité en question.

Ce que Papermerge a annoncé exactement

Papermerge est un document management system open source pensé pour les documents scannés : il extrait le texte par OCR, l’indexe et le rend consultable en recherche plein texte, avec une ergonomie proche d’un explorateur de fichiers de bureau. C’est l’un des rares concurrents directs de Paperless-ngx sur ce créneau.

La bifurcation tient en une phrase, publiée en tête du dépôt GitHub de l’organisation : « After 9 years of open-source development, Papermerge is now available in two forms. » D’un côté, Papermerge OSS, la version auto-hébergée, dont le statut affiché est « Seeking active maintainers » avec la parenthèse « I’m transitioning to SaaS ». De l’autre, Papermerge Cloud, le SaaS « géré, conforme GoBD, avec support professionnel », dont la mise en service est annoncée pour le 11 novembre 2026.

La version open source est décrite comme « stable et disponible pour toujours », et le texte invite chacun à forker, à utiliser la dernière release stable en l’état, ou à se porter volontaire comme mainteneur via l’issue #1318. Cette générosité de façade ne masque pas le fait : le dépôt papermerge-core compte 538 étoiles, 112 forks et une base de contributeurs modeste, sous licence Apache 2.0.

Pourquoi un DMS mono-mainteneur est un risque particulier

Tous les logiciels self-hosted ne se valent pas face à l’abandon. Un lecteur de flux ou un gestionnaire de favoris peut s’arrêter sans drame : on change d’outil, on perd peu. Un DMS est différent. C’est un système d’archivage qui doit conserver des documents sur dix, quinze ans ou plus — souvent pour des obligations légales de conservation. Les données ne sont pas un paramètre, elles sont le produit.

Le bus factor — le nombre de personnes dont le départ bloquerait le projet — vaut ici un. Eugen Ciur (GitHub ciur) est l’auteur et le mainteneur de fait du projet. Quand un projet de cette nature pivote vers un produit commercial, l’attention de son unique mainteneur se déplace mécaniquement vers ce qui paie les factures. Les correctifs de sécurité, les montées de dépendances Python/Django et la compatibilité avec les nouvelles versions cessent d’arriver au rythme attendu.

Le risque n’est pas théorique. La lettre Self-Host Weekly du 11 septembre 2026 a lu la situation sans détour : Papermerge « semble sur la voie de l’abandon » après que le développeur a annoncé déplacer son attention vers la version cloud/SaaS. Ce n’est pas un fork hostile ni une fermeture brutale — c’est le scénario plus insidieux du projet qui continue d’exister sur le papier mais cesse d’être maintenu.

La conformité GoBD change de camp

Le glissement vers le SaaS n’est pas neutre sur un point précis : la conformité GoBD. Cette norme allemande d’archivage — très regardée dans le monde germanophone, mais qui sert aussi de référence de bonnes pratiques ailleurs — impose l’immuabilité des documents, des pistes d’audit et une traçabilité des accès. C’est exactement ce que le Papermerge Cloud met en avant : « GoBD compliance, immutability & audit trails built-in ».

L’implication est directe pour qui auto-héberge aujourd’hui. La version open source n’est pas soudainement devenue non conforme, mais la charge de la conformité — sauvegardes prouvables, horodatage, non-répudiation — retombe entièrement sur l’administrateur, au moment même où le projet cesse d’évoluer. Celui qui avait choisi Papermerge pour son contrôle sur les données se retrouve avec la totalité du travail de conformité, sans la force de frappe d’un produit commercial.

Ce qu’il faut faire selon votre situation

Avant toute décision, mesurez l’activité réelle du dépôt plutôt que de vous fier au README :

git clone https://github.com/papermerge/papermerge-core.git
cd papermerge-core
git log --since="6 months ago" --oneline | wc -l

Un compteur proche de zéro sur six mois confirme ce que le statut laisse entendre. Si vous êtes en production sur Papermerge OSS, traitez la situation comme un plan de continuité, pas comme un sujet de curiosité :

• Exportez maintenant. Les documents, le texte OCR et les métadonnées doivent sortir du système dans un format ré-importable. Un DMS dont l’export est incomplet ou propriétaire vous piège ; vérifiez que vos données ne le sont pas.
• Figez votre version. Une release stable « disponible pour toujours » signifie figée, donc vulnérable à la première CVE non corrigée. Minimisez la surface exposée en ne l’exposant pas à Internet.
• Planifiez la cible de migration. Paperless-ngx reste le point de chute naturel : communauté active, développement soutenu et fonctionnalités de gestion documentaire auto-hébergée matures. Mayan EDMS est l’autre alternative sérieuse si vous avez besoin de gestion de workflows plus poussée.
• Ne confondez pas le SaaS avec un sauveur. Le Papermerge Cloud est une option légitime pour qui veut la conformité GoBD sans l’exploiter soi-même. Mais c’est aussi une dépendance nouvelle envers une entreprise portée par une seule personne : négociez l’export, la portabilité et les conditions de sortie avant d’y verser vos archives.

Ce que l’historique du projet raconte

Papermerge n’en est pas à sa première refonte. Le projet a connu une v1 historique (ciur/papermerge) puis une réécriture majeure sous le nom papermerge-core, avec une architecture en micro-services — API, workers, serveur d’authentification — plus proche d’une plateforme que d’un simple monolithe Django. Cette complexité a un coût de maintenance que la base de contributeurs — 538 étoiles, 112 forks — n’a jamais pu porter à elle seule.

La comparaison avec Paperless-ngx est parlante. Là où Papermerge a suivi une trajectoire « un auteur, une réécriture, un SaaS », Paperless-ngx a bâti un collectif de mainteneurs et une cadence de releases soutenue, sans bifurquer vers un produit commercial. Ce n’est pas un jugement moral : c’est une leçon de gouvernance. Un projet qui veut survivre à son fondateur distribue la maintenance avant d’en avoir besoin, il ne cherche pas des mainteneurs au moment où le fondateur s’en va.

C’est précisément le point d’alerte pour les self-hosters. Le signal n’est pas « le SaaS existe », c’est « le projet cherche des mainteneurs après avoir annoncé la bascule ». On ne recrute pas une communauté en partant ; on la construit pendant qu’on est encore là. L’issue #1318 — « Interested in maintaining? » — est le symptôme d’une transition déjà engagée, pas d’une précaution.

Verdict

Papermerge illustre le risque structurel du self-hosting mono-mainteneur : un outil excellent peut cesser d’être un choix rationnel du jour où son unique auteur change de cap.

Si vous auto-hébergez Papermerge aujourd’hui, engagez une migration vers Paperless-ngx (ou Mayan EDMS pour des workflows avancés) et ne laissez pas la « disponibilité pour toujours » servir d’excuse au report. Si vous avez besoin de la conformité GoBD sans maintenir une infrastructure, le Papermerge Cloud est une option à étudier, à condition d’obtenir des garanties écrites de portabilité des données. Et si vous envisagiez d’adopter Papermerge, ne le faites pas : il n’y a plus de mainteneur derrière la version que vous auriez déployée.

Références

• GitHub — organisation Papermerge : « After 9 years of open-source development… »
• GitHub — papermerge/papermerge-core, dépôt open source (issue #1318 « Interested in maintaining? »)
• selfh.st — Self-Host Weekly, 11 septembre 2026
• Papermerge — FAQ : « The cloud service launching on November 11, 2026… »
• CloudHostReview — Paperless-ngx vs Papermerge vs Mayan EDMS (2026)