Migrer Confluence Data Center vers Docmost avant 2029

Pourquoi migrer maintenant, pas en 2028

Atlassian a publié deux dates que toute agence administrant Confluence Data Center doit connaître. La première : le 30 mars 2026, Atlassian a cessé la vente de nouvelles licences Confluence Data Center — source : falconer.com/guides/confluence-data-center-end-of-life/. La seconde : le 28 mars 2029, toutes les instances Confluence Data Center existantes passeront en lecture seule — source : docmost.com/blog/atlassian-confluence-data-center-eol/. Entre les deux, une troisième date à noter : le 30 mars 2028, les clients existants perdent la possibilité de renouveler ou d'étendre leurs licences Data Center.

Ces jalons délimitent une fenêtre de trois ans. En pratique, une migration de wiki d'entreprise — inventaire des espaces, export des pages, conversion du balisage Confluence, traitement des macros non compatibles, formation des contributeurs — prend entre quatre et douze semaines selon la taille de l'instance. Si votre client a deux cents pages dans un espace, c'est faisable en deux sprints. S'il en a trois mille réparties dans quinze espaces avec des macros personnalisées, c'est un projet à part entière qu'on ne lance pas six mois avant l'échéance.

Six raisons de migrer vers Docmost plutôt que d'attendre

Échéance dure et documentée — le 28 mars 2029, l'instance passe en lecture seule : aucune nouvelle page, aucune modification, aucune révision. La date est publique et irrévocable.
Fin des correctifs de sécurité — en mode lecture seule, Atlassian ne publiera plus de patchs pour Confluence DC ; une instance exposée sur le réseau devient une cible sans protection.
Édition collaborative temps réel — Docmost propose la co-édition en direct avec curseurs en direct et synchronisation instantanée entre utilisateurs, sans conflit de version, une fonction absente de Confluence Data Center sans plugin tiers.
Diagrammes natifs — les blocs Mermaid (syntaxe texte), Draw.io (organigrammes, UML, diagrammes réseau) et Excalidraw sont intégrés sans configuration supplémentaire ; les diagrammes Confluence nécessitaient des licences addon distinctes.
Coût prévisible — Docmost est open source et se déploie sur une infrastructure que vous contrôlez : pas de tarification par utilisateur révisable unilatéralement, pas de renouvellement annuel imposé.
Export Markdown et HTML — les pages Docmost s'exportent en Markdown standard ou en HTML, ce qui simplifie les sauvegardes et rend les migrations futures vers n'importe quel outil compatible indépendantes de l'éditeur.
Déploiement Docker en trois conteneurs — docmost, db (PostgreSQL) et redis, un fichier docker-compose.yml officiel, un reverse proxy : l'instance est opérationnelle en moins d'une heure.

L'importeur Confluence de Docmost — ce qu'il préserve, ce qu'il ne préserve pas

Docmost propose un importeur Confluence natif, disponible dans l'édition Enterprise (docmost.com). Selon l'éditeur, il préserve les espaces Confluence, la hiérarchie des pages, les pièces jointes, les liens internes et les diagrammes draw.io. L'import s'effectue à partir de l'export XML produit par Confluence (format standard disponible dans l'administration Confluence via Backup Manager).

Ce qui est préservé. La structure arborescente des espaces et des pages, les pièces jointes associées aux pages, les liens internes entre pages et les diagrammes draw.io intégrés sont transférés automatiquement par l'importeur.

Ce qui n'est pas préservé — les macros Confluence. Confluence repose sur un système de macros (blocs dynamiques insérés dans les pages) dont une grande partie n'a pas d'équivalent direct dans Docmost. Les macros les plus courantes se comportent ainsi lors de l'import :
- Macros de mise en page (expand, panel, section/column) — le contenu textuel est généralement récupéré, mais la mise en forme structurée disparaît.
- Macros de contenu dynamique (children, include, excerpt-include) — ces macros qui injectent du contenu depuis d'autres pages ne sont pas reproduites.
- Macros de tableau de bord et de reporting (recently-updated, task-report, roadmap) — ces widgets n'existent pas dans Docmost ; ils disparaissent sans substitut automatique.
- Macros de code (code) — le contenu du bloc de code est généralement préservé ; la coloration syntaxique dépend du type de bloc disponible dans l'éditeur Docmost.
- Macros tierces (plugins Marketplace Confluence installés par l'administrateur) — non migrées.

Avant de lancer un import, dressez l'inventaire des macros utilisées dans les espaces à migrer. Exportez un espace de test et ouvrez-en le XML pour identifier les balises <ac:structured-macro> et les attributs ac:name — chaque valeur correspond à une macro. Cela vous donne la liste exacte de ce qui sera traité manuellement après import.

Si l'édition Enterprise n'est pas dans le budget, la migration est manuelle : export HTML ou PDF depuis Confluence (Administration → Backup Manager ou export par espace), puis recréation de la structure dans Docmost (espaces, arborescence de pages) et copier-coller des contenus page par page.

Découper la migration en sprints — la méthode pour les instances volumineuses

Une migration de wiki n'est pas un événement bascule. C'est une séquence de sprints qui permet de livrer de la valeur progressivement, de corriger les erreurs avant qu'elles se propagent, et de maintenir le wiki Confluence en parallèle jusqu'à la validation complète de chaque lot.

Sprint 0 — inventaire et tri (1 à 2 jours). Exportez la liste complète des espaces depuis l'administration Confluence. Pour chaque espace, notez : le nombre de pages, la date de dernière modification, les macros utilisées (repérez les <ac:structured-macro> dans le XML d'un export test), et l'équipe propriétaire. Classez les espaces en trois catégories : actifs (modifiés dans les six derniers mois), archivés (lecture seule de facto), et obsolètes (candidats à la suppression). N'importez pas les espaces obsolètes — c'est du bruit.

Sprint 1 — espace pilote (3 à 5 jours). Choisissez un espace actif de taille moyenne, sans macros critiques. Importez-le avec l'importeur Confluence Enterprise ou manuellement. Validez page par page : hiérarchie, pièces jointes, liens internes, rendu des blocs de code. Identifiez les macros qui ont produit du contenu dégradé et définissez leur traitement standard. Ce sprint produit votre grille de référence pour tous les sprints suivants.

Sprints 2 à N — espaces par lots (1 semaine par lot). Regroupez les espaces par affinité et importez-les par lots. Après chaque import, assignez les pages dégradées à leurs propriétaires pour correction. Maintenez un tableau de suivi avec l'état de chaque espace.

Sprint final — bascule et archivage. Une fois tous les espaces validés dans Docmost, désactivez les droits d'écriture dans Confluence pour les espaces migrés. Après 30 jours sans demande de retour arrière, archivez les exports XML et coupez l'instance Confluence.

Règle pratique pour les agences. Ne migrez jamais l'intégralité des espaces d'un client en un seul import, même si l'importeur le permet techniquement. Des lots de 200 à 300 pages par sprint permettent de corriger les erreurs à l'échelle d'une équipe, pas d'une organisation.

Prérequis chiffrés avant de commencer

Docmost se déploie avec trois conteneurs Docker : docmost (l'application principale), db (PostgreSQL 18) et redis (Redis 8). Le fichier docker-compose.yml officiel est disponible dans la documentation de l'éditeur. L'éditeur ne publie pas de prérequis matériels chiffrés sur son site ; pour un usage de production accueillant une équipe de 10 à 50 utilisateurs, un VPS avec 2 vCPU, 4 Go de RAM et 40 Go de stockage est une base raisonnable — ajustez le stockage selon le volume de pièces jointes de vos espaces Confluence.

Du côté des prérequis réseau et système : un VPS accessible en SSH avec accès root, Docker et docker compose v2 installés, un domaine ou sous-domaine pointant vers le VPS, et les certificats TLS générés avant d'ouvrir l'accès aux utilisateurs. Si vous utilisez Nginx comme reverse proxy, configurez proxy_pass vers le port interne de Docmost et activez proxy_read_timeout à une valeur suffisante pour les imports volumineux (300 secondes).

Pour l'import Confluence, préparez également : un export XML de chaque espace Confluence (Administration → Backup Manager → Export de l'espace, format XML, pièces jointes incluses), l'inventaire des macros utilisées, et un VPS avec un espace disque suffisant pour stocker les archives XML pendant la durée de la migration.

Procédure de migration pas à pas

Exporter les espaces depuis Confluence Data Center

Dans l'administration Confluence, accédez à Administration générale → Backup Manager. Sélectionnez l'export par espace (pas l'export global si votre instance dépasse quelques centaines de pages — les exports globaux sont tronqués silencieusement au-delà de la limite de taille). Pour chaque espace, cochez l'inclusion des pièces jointes. Téléchargez l'archive ZIP produite et vérifiez sa taille : une archive anormalement petite par rapport au nombre de pages annonce un export incomplet. Répétez pour chaque espace à migrer.

Déployer Docmost sur le VPS via Docker

Récupérez le fichier docker-compose.yml officiel depuis la documentation Docmost. Créez un fichier .env à côté avec les variables obligatoires : APP_URL (votre domaine avec protocole, ex. https://wiki.client.com), APP_SECRET (chaîne aléatoire de 32 caractères minimum), et les paramètres de connexion PostgreSQL (DB_URL). Lancez la stack avec docker compose up -d et attendez la fin des migrations de base de données. Configurez Nginx comme reverse proxy devant le port applicatif de Docmost et générez les certificats TLS avec Certbot.

Créer les espaces de destination dans Docmost

Dans l'interface Docmost, créez un espace pour chaque espace Confluence à migrer. Respectez les noms d'espaces Confluence pour faciliter la correspondance pendant la validation. Si votre instance Docmost est en édition Enterprise, vous n'avez pas besoin de créer la structure manuellement — l'importeur la recrée à partir de l'export XML.

Lancer l'importeur Confluence (édition Enterprise)

Dans les paramètres de l'espace Docmost, accédez à Import et sélectionnez le format Confluence. Téléversez l'archive ZIP exportée depuis Confluence. L'importeur de Docmost préserve la hiérarchie des pages, les pièces jointes, les liens internes et les diagrammes draw.io selon la documentation de l'éditeur. Pour les instances sans édition Enterprise, procédez manuellement : décompressez l'archive ZIP, récupérez les fichiers HTML des pages depuis le dossier pages/, et copiez le contenu page par page dans Docmost.

Valider les pages importées et traiter les macros dégradées

Après chaque import d'espace, parcourez un échantillon représentatif de pages : hiérarchie dans le panneau latéral, rendu des blocs de code, présence des pièces jointes, fonctionnement des liens internes. Pour les pages contenant des macros non migrées, utilisez votre grille de référence établie au sprint pilote pour appliquer le traitement standard. Assignez les corrections aux propriétaires de page concernés plutôt que de les traiter vous-même.

Configurer les utilisateurs et les permissions

Docmost gère les accès par espaces et par groupes, avec RBAC (contrôle d'accès basé sur les rôles). Créez les groupes correspondant aux équipes de votre client, assignez les espaces à ces groupes avec les niveaux de permission appropriés. L'édition Enterprise inclut le SSO via SAML 2.0, OpenID Connect et LDAP.

Configurer les sauvegardes et la supervision

Configurez une sauvegarde quotidienne de la base PostgreSQL (pg_dump dans un script cron ou via un outil de backup automatisé) et du volume Docker contenant les pièces jointes. Vérifiez que les sauvegardes sont stockées hors du VPS (stockage objet, serveur distant). Activez les logs applicatifs de Docmost et configurez une alerte de disponibilité sur l'URL principale de l'instance.

Ce que Docmost ne reprend pas de Confluence

Avant d'annoncer la migration à vos clients, documentez explicitement ce qui ne sera pas transféré.

Les macros dynamiques. Les macros de contenu dynamique (children, include, excerpt-include), de reporting (recently-updated, task-report) et les macros tierces du Marketplace Confluence ne sont pas migrées.

L'historique de versions complet. L'importeur transfère la version courante des pages. L'historique de révisions Confluence n'est pas conservé. Si l'historique a une valeur légale ou de conformité pour votre client, exportez-le en PDF depuis Confluence avant la migration.

Les pages blog Confluence. Confluence distingue les pages standard et les pages de type Blog. Ces dernières n'ont pas d'entité équivalente dans Docmost — leur contenu peut être importé comme pages standard, mais le format blog est perdu.

Les modèles de page. Les templates Confluence définis au niveau de l'espace ou de l'instance ne sont pas importés. Recréez les modèles les plus utilisés dans Docmost après la migration.

Les intégrations Jira. Les macros Confluence qui affichaient des données Jira en temps réel (jira macro, panneaux de tickets) disparaissent à l'import.

Exportez toujours un espace test en XML et ouvrez-le dans un éditeur de texte avant de lancer l'import de production. Recherchez les balises <ac:structured-macro ac:name="..."> — chaque valeur de ac:name est une macro. En dix minutes, vous avez la liste exacte des macros à traiter manuellement pour cet espace. Cette vérification préalable évite les mauvaises surprises au moment de la validation et permet de calibrer correctement le temps de correction dans votre planning de sprint.

Docmost sur VPS — une sortie propre de Confluence Data Center

La migration depuis Confluence Data Center n'est pas un projet de plusieurs mois si elle est abordée en sprints progressifs. Un inventaire des espaces par priorité, un sprint pilote pour calibrer le traitement des macros, et l'importeur Confluence de Docmost (édition Enterprise) suffisent à transférer la hiérarchie, les pièces jointes et les liens internes de vos wikis clients sans perte de structure.

Pour les budgets hors Enterprise, la migration manuelle reste viable sur des volumes limités — l'export HTML de Confluence est lisible et le copier-coller de contenus page par page est une opération sans risque technique. La contrainte est le temps, pas la faisabilité.

Dans les deux cas, vous récupérez le contrôle complet : accès root au serveur, sauvegardes maîtrisées, données hébergées dans l'infrastructure de votre choix, et un wiki collaboratif avec co-édition temps réel, diagrammes natifs et recherche plein texte — sans tarification par utilisateur révisable unilatéralement.