AppFlowy archivé : Docmost, seule alternative Notion AGPL

AppFlowy proposait deux pièces distinctes : l'application cliente (Flutter + Rust, toujours active) et AppFlowy-Cloud, le serveur de collaboration multi-utilisateurs. C'est ce second dépôt — AppFlowy-IO/AppFlowy-Cloud — qui a été archivé le 11 septembre 2026 par l'organisation.

L'organisation renvoie désormais les utilisateurs vers AppFlowy-SelfHost-Commercial : un dépôt dont la base de code est propriétaire. On peut toujours déployer AppFlowy en mode serveur, mais plus sous licence libre. Ce n'est pas une évolution de licence sur le même code : c'est un fork commercial fermé qui remplace le dépôt public.

Pour les équipes qui citaient la licence AGPL comme condition de déploiement — exigence de conformité, politique DSI, contrat client — l'argument disparaît du jour au lendemain. Et pour celles qui avaient choisi AppFlowy précisément parce qu'une organisation fermant boutique ne laisse pas ses utilisateurs sans recours, l'ironie est réelle : la pièce qui gère la collaboration de l'équipe n'est plus auditable.

Docmost est une base de connaissance collaborative publiée sous licence AGPL-3.0 sur github.com/docmost/docmost. Son modèle de distribution ressemble à celui qu'AppFlowy promettait : un cœur entièrement libre, des extensions commerciales opt-in pour les grands comptes.

L'édition Open Source couvre l'essentiel : espaces et pages hiérarchiques, édition collaborative en temps réel, commentaires, historique de versions, permissions granulaires par espace, support RTL (ajouté en v0.96.0 — septembre 2026). Aucun plafond de membres, aucune fonction bloquée derrière un paywall dans l'édition de base.

Les éditions Business et Enterprise ajoutent des fonctions d'audit, d'export DOCX et de gouvernance pour les équipes qui en ont besoin — mais elles se greffent sur une base Open Source qui reste complète. La licence AGPL-3.0 du cœur impose à tout hébergeur d'en redistribuer les modifications : c'est la garantie que le code du serveur en face de vos données reste auditable.

Un argument revient souvent dans les fils de discussion : le dépôt principal AppFlowy-IO/AppFlowy — l'application de bureau et mobile — est toujours actif. C'est vrai. Mais cet argument confond la couche cliente et la couche serveur.

Dans un déploiement d'équipe, le serveur gère l'authentification, la synchronisation des données, les permissions, et le stockage des pages. C'est lui qui reçoit vos documents. C'est lui qui implémente les règles d'accès. L'application cliente, aussi libre soit-elle, ne change pas la nature du composant avec lequel elle parle.

Rester sur le dernier commit AGPL d'AppFlowy-Cloud signifie : aucun correctif de sécurité futur, des incompatibilités progressives avec le client (qui continue d'évoluer), et une base sans maintenance actuelle. C'est la définition d'une dette technique à horizon court.

AppFlowy et Docmost n'ont pas de format d'export commun natif. La migration la plus propre passe par l'export Markdown depuis AppFlowy (disponible depuis l'interface cliente) et l'import dans Docmost. Les images et fichiers attachés demandent un traitement séparé.

Docmost gère l'import de fichiers Markdown et de structures de pages hiérarchiques. Pour un volume important, l'import en lot via l'API reste la voie la plus fiable.

Quatre points à vérifier avant de basculer : la structure de vos espaces AppFlowy (un espace = un espace Docmost), les intégrations tierces branchées sur AppFlowy-Cloud (webhooks, scripts d'automatisation), les permissions assignées par groupe, et les utilisateurs sans compte e-mail vérifié qui ne passent pas le flow d'invitation Docmost standard.

AppFlowy n'est pas le premier projet à franchir ce pas. Le schéma est documenté : un outil commence sous licence permissive ou copyleft, gagne en popularité, lève des fonds, et réserve progressivement le code du serveur. Ce que cet archivage illustre, c'est la limite du modèle open-core quand le cœur commercial est le serveur.

La distinction qui compte pour un responsable technique : un projet dont l'éditeur tire des revenus de la licence du serveur a un intérêt direct à rendre ce serveur difficile à substituer. Un projet dont l'éditeur tire ses revenus des éditions Enterprise — construites sur un cœur open source stable — a un intérêt à maintenir ce cœur en bon état. C'est la tension que la licence AGPL tente de réduire : en imposant la publication des modifications, elle rend le cœur plus difficile à fermer.

Docmost suit ce second modèle. Son cœur AGPL est la fondation sur laquelle repose la confiance des équipes qui choisissent de l'héberger. Retirer cette fondation reviendrait à détruire la proposition de valeur que le projet vend à ses clients Business et Enterprise.

Docmost est stable en production depuis fin 2025. Quelques points à connaître avant un déploiement en équipe.

Sauvegardes : la donnée réside dans PostgreSQL et dans le volume de stockage fichiers. Une sauvegarde quotidienne automatisée des deux suffit. pg_dump schedulé via cron, et rsync ou un snapshot S3 pour les attachments.

Mises à jour : Docmost publie des releases régulières — environ une par mois en 2026. La procédure est un docker compose pull suivi d'un docker compose up -d. Les migrations de schéma sont appliquées au démarrage. Lisez les notes de version avant de mettre à jour : certaines versions introduisent des migrations non réversibles.

Authentification SSO : Docmost supporte SAML 2.0 et OIDC dans les éditions Business et Enterprise. L'édition Open Source gère l'authentification par e-mail et par invitation. Pour une équipe avec un annuaire LDAP/AD, l'édition Business est nécessaire.

Performance : sur 2 vCPU / 4 Go RAM, Docmost gère confortablement 20 à 50 membres actifs simultanément. Au-delà de 100 membres avec des espaces intensément utilisés, prévoir 4 vCPU / 8 Go et un nœud PostgreSQL dédié.