Pourquoi remplacer Jira en 2026
Atlassian a officiellement fermé les nouvelles souscriptions Jira Software Data Center. Les équipes déjà sous licence peuvent renouveler, mais toute organisation qui n'avait pas encore de contrat doit désormais passer par Jira Cloud — un modèle SaaS avec une facturation par siège qui échappe à votre maîtrise d'infrastructure. Linear Enterprise, autre référence des équipes tech, a relevé ses tarifs en début d'année, touchant les équipes de taille intermédiaire qui utilisaient le produit pour ses sprints et son intégration GitHub.
Ce contexte pousse un nombre croissant d'agences à évaluer des alternatives open source auto-hébergées. Deux projets s'imposent dans la comparaison : Vikunja, un gestionnaire de tâches léger en monoexécutable Go sous licence AGPL-3.0, et Plane CE (Community Edition), une plateforme de gestion de projet plus complète, architecturée autour de cinq services Docker, elle aussi sous AGPL-3.0. Les deux ont des profils très différents : connaître leurs prérequis VPS et leurs limites fonctionnelles est la première décision à prendre avant de migrer.
Vikunja vs Plane CE — tableau comparatif
| Critère | Vikunja | Plane CE |
|---|---|---|
| RAM requise | 512 Mo (production légère) | ≥ 4 Go (8 Go recommandés) |
| Licence | AGPL-3.0 | AGPL-3.0 |
| Kanban | Natif (vues Kanban, liste, Gantt) | Natif (Board view, états personnalisables) |
| Gantt | Natif | Via modules et dates d'échéance |
| Sprints / cycles | Absent nativement — simulable par listes | Cycles natifs (début, fin, progression) |
| API REST | Complète, documentée OpenAPI | Complète, documentée OpenAPI |
| Intégrations Git | Webhooks sortants, pas d'intégration native GitHub/GitLab | Intégration GitHub et GitLab natives dans les réglages |
| Multi-tenants / workspaces | Oui — projets et équipes séparés par namespace | Oui — workspaces distincts, membres et rôles par workspace |
| Application mobile | iOS et Android natifs officiels | PWA uniquement (pas d'app native publiée) |
Vikunja — légèreté et polyvalence
Vikunja (anciennement Todoist-like) est un gestionnaire de tâches et de projets entièrement auto-hébergeable, distribué sous licence AGPLv3. Son point fort : un exécutable unique en Go qui ne requiert qu'une base de données (MySQL, PostgreSQL ou SQLite) et consomme moins de 100 Mo de RAM en charge normale. L'interface propose des vues Kanban, Gantt et liste, ainsi qu'une API REST complète exploitée par des clients mobiles natifs (iOS et Android). Depuis la version 0.22, Vikunja supporte les équipes (namespaces partagés) et les webhooks, ce qui le rend viable pour des agences gérant plusieurs clients sur une seule instance.
Forces de Vikunja
- Empreinte mémoire minimale — 512 Mo de RAM suffisent en production ; un VPS d'entrée de gamme accueille Vikunja sans redimensionnement.
- Monoexécutable Go — un seul binaire regroupe le serveur API et le service de tâches de fond ; le déploiement Docker se résume à un seul service applicatif et une base de données.
- Vues multiples natives — Kanban, liste, Gantt et tableau récapitulatif sont disponibles sans extension ni plugin supplémentaire.
- API REST complète — chaque entité (tâche, liste, projet, utilisateur, étiquette) est exposée via une API documentée OpenAPI, ce qui facilite l'automatisation des workflows agence.
- Applications mobiles natives — des applications iOS et Android officielles sont publiées dans les stores, ce qui est rare parmi les outils open source de gestion de tâches.
- Licence AGPL-3.0 — le code source est public, les contributions de la communauté sont rapides, notamment sur les correctifs de sécurité.
Installer Vikunja sur VPS avec Docker Compose
Créer le répertoire de travail
Connectez-vous à votre VPS et créez un répertoire dédié : mkdir -p /opt/vikunja && cd /opt/vikunja. Ce répertoire accueillera le fichier docker-compose.yml, le fichier de configuration config.yml et les données persistantes.
Rédiger le fichier docker-compose.yml
Créez un fichier docker-compose.yml avec deux services : la base de données et Vikunja lui-même. Exemple minimal avec PostgreSQL :
services:
db:
image: postgres:16
restart: unless-stopped
environment:
POSTGRES_USER: vikunja
POSTGRES_PASSWORD: changeme
POSTGRES_DB: vikunja
volumes:
- vikunja-db:/var/lib/postgresql/data
vikunja:
image: vikunja/vikunja:latest
restart: unless-stopped
ports:
- "127.0.0.1:3456:3456"
environment:
VIKUNJA_DATABASE_TYPE: postgres
VIKUNJA_DATABASE_HOST: db
VIKUNJA_DATABASE_USER: vikunja
VIKUNJA_DATABASE_PASSWORD: changeme
VIKUNJA_DATABASE_DATABASE: vikunja
VIKUNJA_SERVICE_PUBLICURL: https://vikunja.votre-domaine.com
volumes:
- vikunja-files:/app/vikunja/files
depends_on:
- db
volumes:
vikunja-db:
vikunja-files:Démarrer les services
Lancez la pile avec docker compose up -d. Au premier démarrage, Vikunja applique les migrations de base de données automatiquement. L'interface est accessible sur le port 3456 en quelques secondes — Vikunja démarre très rapidement grâce à son binaire Go.
Configurer le reverse proxy HTTPS
Pointez Nginx ou Caddy vers 127.0.0.1:3456. Avec Caddy, la configuration se résume à :
vikunja.votre-domaine.com {
reverse_proxy 127.0.0.1:3456
}Caddy gère le certificat Let's Encrypt automatiquement. Avec Nginx, ajoutez les en-têtes Upgrade et Connection pour les WebSockets si vous utilisez les notifications temps réel.
Créer le premier compte administrateur
Ouvrez votre sous-domaine dans un navigateur. Vikunja affiche un écran d'inscription : le premier compte créé obtient automatiquement les droits administrateur. Activez ensuite la double authentification (TOTP) depuis les réglages de compte — indispensable si l'instance est exposée publiquement.
Vérifier les sauvegardes
Planifiez une sauvegarde quotidienne du volume PostgreSQL et du volume vikunja-files. Une commande suffisante : docker exec vikunja-db-1 pg_dump -U vikunja vikunja | gzip > /backup/vikunja-$(date +%Y%m%d).sql.gz. Testez la restauration sur un environnement de test avant de migrer vos données de production.
Plane CE — les fonctionnalités enterprise open-source
Plane CE (Community Edition) est la version open source auto-hébergeable de Plane, une plateforme de gestion de projet conçue pour remplacer Jira dans les équipes pratiquant les méthodes agile. Son architecture microservices s'appuie sur PostgreSQL, Redis, MinIO et RabbitMQ — ce qui explique ses besoins en RAM plus élevés (4 Go minimum, 8 Go recommandés). En contrepartie, elle offre des cycles de sprint complets, des feuilles de route, des modules multi-projets, une intégration GitHub/GitLab native et un importeur Jira disponible depuis la version 0.22. La version CE est gratuite et sous licence AGPL-3.0 ; la version cloud est payante.
Forces de Plane CE
- Cycles natifs (sprints) — créez des cycles avec dates de début et de fin, suivez la progression par points ou par issues, et archivez les cycles terminés sans perdre l'historique.
- Modules et regroupements transverses — regroupez des issues de différents projets dans un module thématique, utile pour les agences qui gèrent plusieurs clients en parallèle.
- Importeur Jira natif — Plane CE embarque un connecteur d'import Jira dans Settings > Importers, qui transfère issues, statuts, priorités, commentaires et membres en quelques clics.
- Intégrations GitHub et GitLab natives — reliez vos dépôts directement depuis les réglages du workspace ; les commits et pull requests apparaissent dans les issues concernées.
- Architecture Docker claire — cinq services documentés (web, API, worker, PostgreSQL, Redis) et un MinIO optionnel pour le stockage de pièces jointes ; chaque service se dimensionne indépendamment.
- Pages wiki intégrées — chaque projet dispose d'un espace de documentation structuré, disponible sans module externe.
- API REST complète — toutes les entités Plane sont accessibles via une API versionnée ; des SDK Python et JavaScript sont maintenus par la communauté.
- Licence AGPL-3.0 — le code source est auditable, et la communauté GitHub compte plusieurs milliers de contributeurs actifs.
Installer Plane CE sur VPS
Vérifier les prérequis système
Plane CE requiert au minimum 4 vCPU et 8 Go de RAM pour un déploiement confortable en production. Sous ce seuil, les workers Celery entrent en compétition mémoire avec PostgreSQL et Redis, ce qui provoque des redémarrages intempestifs. Vérifiez que Docker Engine ≥ 24 et Docker Compose ≥ 2.20 sont installés : docker --version && docker compose version.
Télécharger le script de déploiement officiel
Plane CE fournit un script d'installation qui génère le fichier docker-compose.yml et le fichier .env avec des secrets aléatoires :
curl -fsSL https://raw.githubusercontent.com/makeplane/plane/master/deploy/selfhost/install.sh | bashLe script crée un répertoire /opt/plane et y place tous les fichiers nécessaires. Relisez le .env généré avant de continuer : les variables SECRET_KEY, DATABASE_URL et REDIS_URL sont pré-remplies avec des valeurs aléatoires sécurisées.
Configurer le domaine dans le fichier .env
Ouvrez /opt/plane/.env et renseignez WEB_URL=https://plane.votre-domaine.com. Si vous utilisez MinIO pour le stockage des pièces jointes, renseignez également AWS_S3_ENDPOINT_URL, AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY. Désactivez le stockage MinIO si vous préférez stocker les fichiers sur le volume local — modifiez USE_MINIO=0.
Démarrer les cinq services Docker
Depuis /opt/plane, lancez docker compose up -d. Les cinq services principaux démarrent : web (interface React), api (Django REST), worker (Celery), beat (tâches périodiques Celery), et db (PostgreSQL). Redis est inclus comme sixième service pour le cache et la file de messages. Attendez environ deux à trois minutes que les migrations Django se terminent avant d'ouvrir l'interface.
Configurer le reverse proxy HTTPS
Plane expose le service web sur le port 3000 et l'API sur le port 8000 en interne. Votre reverse proxy doit router les deux : l'interface React sur / et les requêtes API sur /api/ et /auth/. Avec Nginx, utilisez deux blocs location dans le même server block pointant respectivement vers 127.0.0.1:3000 et 127.0.0.1:8000. Les WebSockets sont utilisés pour les mises à jour en temps réel — transmettez les en-têtes Upgrade et Connection.
Créer le premier espace de travail
Ouvrez votre domaine dans un navigateur. Plane affiche un écran d'inscription : créez un compte administrateur, puis suivez l'assistant de création de workspace. Importez votre premier projet depuis Jira ou créez un projet vierge pour valider l'installation. Invitez les membres depuis Settings > Members > Invite Members — chaque membre reçoit un lien d'invitation par e-mail.
Planifier les sauvegardes des cinq services avec état
Plane dispose de cinq services stateful à sauvegarder : PostgreSQL (volume pgdata), Redis (volume redisdata), et MinIO si activé (volume uploads). Planifiez des dumps PostgreSQL quotidiens (pg_dump depuis le conteneur db), et archivez les volumes Docker avec votre outil de sauvegarde préféré. Testez systématiquement la restauration sur un VPS de test avant de mettre l'instance principale en production.
Sécurité — réactivité des deux projets
La question de la maturité sécurité des outils open source est légitime, et les deux projets offrent des réponses concrètes. Les deux projets ont démontré une capacité à corriger rapidement leurs vulnérabilités, avec des correctifs publiés en moins de dix jours après divulgation dans les cas documentés. Le correctif a été intégré dans la Vikunja en moins de dix jours après la divulgation publique, ce qui illustre la capacité de réaction rapide d'une communauté open source bien organisée. La leçon pratique : maintenez Vikunja à jour via docker compose pull && docker compose up -d sur un cycle hebdomadaire, et activez les notifications de sécurité du dépôt GitHub (Watch > Security alerts).
Plane CE suit un cycle de release mensuel avec un changelog public détaillé. Les issues de sécurité sont traitées dans un canal privé avant publication, selon un processus de divulgation responsable documenté dans le dépôt. Pour les deux outils, l'audit trail des actions utilisateurs (qui a modifié quoi, quand) est disponible dans les logs applicatifs — exportables pour répondre à une exigence de conformité interne.
Pour importer depuis Jira vers Plane CE : sauvegardez votre base Plane avant de commencer (docker exec plane-db-1 pg_dump -U plane plane > backup-avant-import.sql). Puis, dans Plane, rendez-vous dans Settings > Importers > Jira. L'importeur demande votre URL Jira, un Personal Access Token Jira, et le nom du projet à importer. Les issues, statuts, priorités, commentaires et membres sont transférés en une seule opération. Sauvegardez également votre base après l'import et vérifiez le nombre total d'issues importées avant de révoquer les accès Jira.
Guide décisionnel — quand choisir l'un ou l'autre
Choisissez Vikunja si votre équipe gère principalement des tâches et des listes sans processus de sprint formalisé, si votre VPS est limité à 1 ou 2 Go de RAM, si vous avez besoin d'applications mobiles natives pour des équipes en déplacement, ou si vous préférez une architecture simple à maintenir (un seul binaire, une seule base de données). Vikunja est aussi un excellent choix si vous hébergez plusieurs projets clients sur une même instance grâce à son système de namespaces.
Choisissez Plane CE si votre équipe vient de Jira et cherche à retrouver des cycles (sprints), des états personnalisables et un importeur Jira natif. Plane CE est plus adapté aux agences qui gèrent des workflows transverses (modules multi-projets), qui ont besoin d'une intégration GitHub ou GitLab directement dans les issues, ou qui souhaitent un outil dont l'interface sera immédiatement reconnaissable par des développeurs habitués à Linear ou Jira. Le prérequis de 4 à 8 Go de RAM est la contrainte principale : vérifiez votre VPS avant de choisir.
Dans tous les cas, commencez par un projet pilote sur une instance séparée avant de migrer la production. L'effort de migration d'un outil de gestion de projet est rarement neutre pour une équipe — prévoir deux semaines de cohabitation entre l'ancien et le nouvel outil permet de valider le mapping des statuts, les habitudes de workflow et les intégrations CI sans bloquer les livraisons.
Ressources agence ServOrbit
ServOrbit propose des VPS Linux avec accès root complet, dimensionnés de 1 vCPU / 1 Go RAM (suffisant pour Vikunja) à 8 vCPU / 32 Go RAM (confortable pour Plane CE avec plusieurs dizaines d'utilisateurs). Tous les VPS sont livrés avec une image Docker prête à l'emploi, une connexion SSH sécurisée, et une bande passante non limitée sur le trafic interne. Pour les agences qui gèrent plusieurs clients, nos offres VPS incluent la possibilité de provisionner des instances isolées par client depuis une console centralisée.
Pour approfondir votre migration depuis les outils Atlassian ou Linear, consultez nos guides connexes : la migration depuis Jira vers OpenProject ou Plane, le contexte de fermeture de Jira Data Center et ses implications pour les équipes en place, et notre comparatif complet des outils de gestion de projet self-hosted incluant Huly.
