Alternatives auto-hébergées à Trello : comparatif

Quelle alternative auto-hébergée à Trello choisir ?

Trois alternatives auto-hébergées à Trello méritent votre attention : Planka si vous voulez retrouver exactement les tableaux de Trello et importer son fichier, Vikunja lorsqu’une équipe a besoin du single sign-on et de fonctions qui dépassent le simple tableau, et Kanboard lorsque le VPS (virtual private server) dispose de peu de ressources. Ne démarrez pas un nouveau projet sur Focalboard. Son serveur autonome n’a pas eu de release depuis 783 jours, et son README demande désormais un mainteneur.

Wekan est le cinquième des 5 outils présentés ici. Il fonctionne, mais consomme plusieurs fois plus de mémoire que tous les autres. Chaque version, licence et date ci-dessous a été vérifiée le 5 août 2026.

Quel volume de RAM chaque outil de tableau nécessite-t-il ?

[
  {
    "tool": "Planka + Postgres",
    "idle_memory_mb": 280
  },
  {
    "tool": "Vikunja + SQLite",
    "idle_memory_mb": 110
  },
  {
    "tool": "Focalboard + SQLite",
    "idle_memory_mb": 120
  },
  {
    "tool": "Wekan + FerretDB",
    "idle_memory_mb": 750
  },
  {
    "tool": "Kanboard + SQLite",
    "idle_memory_mb": 70
  }
]

Ces valeurs correspondent à une installation neuve au repos, sans utilisateur actif. C’est le type de valeur que docker stats affiche une minute après le démarrage de la stack. Utilisez-les pour dimensionner une offre, puis mesurez votre propre consommation. La tendance compte plus que le nombre exact de mégaoctets.

Kanboard représente le minimum, avec 70 MB, car il utilise PHP avec SQLite. Aucun processus applicatif à longue durée d’exécution ne conserve vos tableaux en mémoire. Le conteneur consomme donc presque rien entre deux requêtes. Vikunja est un binaire Go unique qui utilise 110 MB. SQLite est sa base de données par défaut, donc un seul conteneur compose toute la stack. Planka nécessite 280 MB, car il utilise toujours deux conteneurs : un serveur Node et PostgreSQL. Planka ne propose pas d’option SQLite. La base de données est donc obligatoire.

Wekan utilise 750 MB, car c’est une application Meteor. Meteor conserve une couche de requêtes en temps réel dans la mémoire de Node et transmet chaque modification de tableau à tous les navigateurs connectés via un WebSocket. Sa consommation mémoire augmente donc avec le nombre d’utilisateurs connectés, au lieu de rester stable. Sur un VPS de 1 GB, Wekan démarre, puis s’arrête dès que plusieurs utilisateurs ouvrent un grand tableau. Le symptôme est un conteneur qui disparaît puis redémarre avec le code de sortie 137. docker compose ps l’affiche sous la forme d’une boucle de redémarrage. Confirmez-le sur l’hôte avec dmesg -T | grep -i "out of memory", car l’oom-killer du noyau ne transmet aucune information à l’application.

La dépendance à une base de données détermine la moitié du travail de sauvegarde. Voici donc le résumé, outil par outil. Planka nécessite PostgreSQL. Vikunja utilise SQLite par défaut et prend également en charge PostgreSQL ainsi que MySQL ou MariaDB. Kanboard utilise SQLite par défaut et prend également en charge MySQL, MariaDB et PostgreSQL. Sa documentation recommande PostgreSQL et déconseille SQLite sur NFS (network file system). Focalboard utilise SQLite par défaut. Wekan utilise le protocole wire MongoDB. Son fichier Compose par défaut inclut désormais FerretDB v1 avec un backend SQLite intégré, au lieu d’un véritable serveur MongoDB. Un fichier Compose distinct pour MongoDB 7 est disponible si vous souhaitez utiliser MongoDB.

Quels sont les projets qui sont encore maintenus ?

[
  {
    "tool": "Planka 2.1.1",
    "release_age": 109
  },
  {
    "tool": "Vikunja 2.5.0",
    "release_age": 1
  },
  {
    "tool": "Focalboard 8.0.0",
    "release_age": 783
  },
  {
    "tool": "Wekan 10.67",
    "release_age": 1
  },
  {
    "tool": "Kanboard 1.2.53",
    "release_age": 12
  }
]

Focalboard est l’exception, avec 783 jours. Sa dernière version autonome, v8.0.0, date de juin 2024. Mattermost a déplacé le développement des tableaux vers un plugin dans un dépôt distinct, et le README de la version autonome indique que le dépôt n’est actuellement plus maintenu. C’est le seul « non » clair de cette comparaison. Pour les autres, le choix dépend de vos priorités.

Les 109 jours de Planka sont un délai normal pour un projet qui publie quelques versions par an. La version 2.1.1 date d’avril 2026. Kanboard a publié v1.2.53 12 jours avant la vérification, après avoir publié deux versions en mars et avril 2026.

Vikunja et Wekan ont tous deux publié une version dans la journée précédant la vérification, mais ces deux faits ne s’interprètent pas de la même manière. Vikunja a marqué v2.5.0 comme une version mineure ordinaire. Wekan a marqué v10.65, v10.66 et v10.67 le même jour, ce qui correspond à son rythme habituel. Des publications fréquentes ne garantissent pas une cible stable. Avec Wekan, vous choisissez de suivre un numéro de version qui évolue rapidement. Épinglez donc le tag et lisez les notes avant chaque mise à jour.

Obtenez-vous plus qu’un tableau ?

La plupart des comparatifs s’arrêtent à « cela ressemble à Trello ». Ce critère compte davantage que la RAM, car un tableau convient mal à tout ce qui comporte une échéance.

• Planka est uniquement un outil de tableaux : projets, tableaux, listes, cartes, étiquettes, listes de contrôle, commentaires et pièces jointes. Les vues calendrier et carte sont des fonctionnalités Pro depuis août 2026.
• Vikunja propose quatre vues pour un même ensemble de tâches : Liste, Kanban, Tableau et Gantt. Une tâche n’existe qu’une seule fois ; vous changez de vue au lieu de la dupliquer.
• Kanboard fournit des tableaux avec des limites de travail en cours, des sous-tâches, des pièces jointes, des commentaires, des actions automatiques et un petit langage de requête pour filtrer. Sa propre page d’accueil indique que « Le nombre de fonctionnalités est volontairement limité », ce qui est une description juste.
• Wekan fournit des tableaux avec des couloirs, ainsi que des listes de contrôle, des champs personnalisés, une API REST (representational state transfer) et des webhooks.
• Focalboard proposait des vues tableau, table et calendrier pour les mêmes cartes. Il figure ici par souci d’exhaustivité.

Si ce que vous cherchez réellement est un wiki auquel s’ajoute un peu de suivi des tâches, ce comparatif ne correspond pas à votre besoin. BookStack, Wiki.js et Outline couvrent ce type d’outil, tandis que les alternatives auto-hébergées à Notion couvrent les espaces de travail tout-en-un.

Accès multi-utilisateur et authentification unique

Planka prend en charge OpenID Connect dans l’édition Community gratuite. Le fichier Compose officiel contient les paramètres commentés, notamment OIDC_ISSUER, OIDC_CLIENT_ID et OIDC_CLIENT_SECRET. Il suffit donc de les décommenter, sans effectuer de mise à niveau. Les rôles invités pour les personnes extérieures à votre organisation sont une fonctionnalité Pro.

Vikunja prend en charge OpenID Connect avec plusieurs fournisseurs simultanément. Définissez VIKUNJA_AUTH_OPENID_ENABLED=true, puis ajoutez un bloc de variables VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* par fournisseur. Il propose également des équipes et le partage par projet, ce qui correspond aux besoins réels d’une organisation de vingt personnes.

Wekan prend en charge LDAP (protocole d’accès à un annuaire), OAuth2, OIDC et SAML. Kanboard intègre LDAP et propose un plugin OAuth2 générique pour les autres besoins, ainsi que des rôles et des groupes par projet. Le serveur autonome de Focalboard ne prend pas du tout en charge l’authentification unique. C’est une deuxième raison de l’écarter.

Chacune de ces solutions peut être associée à un fournisseur d’identité Authentik que vous gérez vous-même. C’est généralement préférable à la gestion d’un mot de passe distinct par application pour vingt personnes.

Pouvez-vous importer vos tableaux Trello ?

Planka propose la procédure la plus simple. Exportez le tableau depuis Trello au format JSON, créez un tableau dans Planka, cliquez sur Import, puis choisissez Trello. Lisez d’abord les limites, car elles sont importantes : les utilisateurs et les pièces jointes ne sont pas importés, une seule checklist par carte est transférée, et l’export JSON par défaut de Trello s’arrête à 1,000 actions sans indiquer qu’il a été tronqué. Vérifiez vous-même le fichier avant de vous fier au résultat.

Vikunja utilise le flux OAuth de Trello, dans Settings, puis « Import from other services ». Chaque migrator doit être activé dans la configuration avant que son icône apparaisse, et VIKUNJA_SERVICE_PUBLICURL doit être correct, car la redirection OAuth s’effectue dans votre navigateur, et non depuis le serveur. Vikunja importe également les données de Todoist, Microsoft To Do, TickTick et Wekan.

Wekan accepte un JSON de tableau Trello collé dans son formulaire d’importation. Kanboard ne possède aucun importateur Trello intégré. C’est la principale raison de l’éviter si vous devez migrer plusieurs années d’historique Trello.

Quelle est l’expérience sur mobile ?

Vikunja est le seul des cinq à disposer d’applications mobiles officielles. Les versions Android et iOS sortent en même temps que chaque release, et le dépôt de l’application se décrit lui-même comme alpha. Considérez-la donc comme un complément à l’interface web, et non comme le principal point d’accès. Planka ne propose pas d’application officielle du projet, mais son interface web est responsive et il existe des clients tiers. Wekan et Kanboard sont uniquement accessibles sur le web, et l’interface de Kanboard est clairement conçue pour un écran d’ordinateur.

La question de la licence, et pourquoi Planka est différent

Planka n’est plus open source, et c’est le point que la plupart des comparatifs omettent. Le projet a commencé sous licence MIT, est passé sous AGPL-3.0 en 2023, puis est distribué depuis la série 2.0 sous la PLANKA Community License, une licence fair-code détenue par PLANKA Software GmbH. GitHub indique « Other » comme licence, car cette licence n’est pas approuvée par l’OSI. L’auto-hébergement pour vos propres utilisateurs est gratuit et explicitement autorisé. Cela couvre les usages personnels, internes, à but non lucratif et éducatifs. La revente de l’accès ou l’exploitation du logiciel en tant que service pour d’autres entreprises nécessite une licence commerciale.

Pour deux personnes, c’est un compromis raisonnable. Pour une entreprise, il faut lire ces conditions avant d’y investir le travail de vingt personnes. Les quatre autres projets sont sous des licences open source classiques : Vikunja est sous AGPL-3.0, Wekan et Kanboard sous MIT, et Focalboard utilise un mélange d’Apache 2.0 et d’AGPL-3.0.

Fichiers Compose épinglés pour les deux solutions

Épinglez le tag de l’image. latest signifie que le prochain docker compose pull peut vous faire passer à une version majeure, et que les versions majeures exécutent des migrations de base de données qu’il est difficile d’annuler. Les deux fichiers ci-dessous sont ceux fournis en amont, avec le tag fixé sur une version réellement publiée.

Vikunja avec SQLite, un conteneur :

services:
  vikunja:
    image: vikunja/vikunja:2.5.0
    restart: unless-stopped
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com
      VIKUNJA_SERVICE_SECRET: replace-with-a-long-random-string
      VIKUNJA_SERVICE_TIMEZONE: Europe/Berlin
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_PATH: /app/vikunja/files/vikunja.db
    ports:
      - "127.0.0.1:3456:3456"
    volumes:
      - ./files:/app/vikunja/files

Créez d’abord le répertoire de données avec le bon propriétaire, car le conteneur s’exécute avec l’UID 1000 et ne peut pas écrire dans un répertoire appartenant à root :

mkdir -p files && sudo chown 1000 files
docker compose up -d
docker compose ps
curl -sf http://127.0.0.1:3456/api/v1/info

Une stack fonctionnelle affiche le service comme running, et l’endpoint info renvoie un JSON contenant un champ version. Un refus de connexion à cet endroit signifie que le conteneur s’est arrêté. docker compose logs vikunja indique la raison. Une erreur de permission sur le fichier de base de données est le cas le plus fréquent.

Planka avec PostgreSQL, deux conteneurs :

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - data:/app/data
    ports:
      - "127.0.0.1:3000:1337"
    environment:
      - BASE_URL=https://boards.example.com
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=replace-with-openssl-rand-hex-64
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_HOST_AUTH_METHOD=trust
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  data:
  db-data:

POSTGRES_HOST_AUTH_METHOD=trust signifie que PostgreSQL accepte toute connexion sans mot de passe. Cette configuration est sûre uniquement parce que le port de la base de données n’est jamais publié sur l’hôte. Le seul élément qui peut l’atteindre est donc l’autre conteneur du même réseau Compose. N’ajoutez pas d’entrée ports: au service postgres.

Aucune des deux stacks ne doit être directement exposée à Internet. Les deux services sont liés à 127.0.0.1. Placez donc un reverse proxy devant eux et terminez-y TLS (transport layer security). Traefik devant plusieurs applications Compose est la méthode habituelle lorsque vous hébergez plusieurs services. Le guide des bases de Docker Compose explique les éléments de ces fichiers qui ne sont pas détaillés ici.

Votre board est une base de données : sauvegardez-la

Un outil de board peut échouer silencieusement. Personne ne remarque l’absence d’une sauvegarde avant la disparition d’un volume, et un fichier SQLite endommagé peut s’ouvrir normalement avant de signaler database disk image is malformed semaines plus tard.

Ne copiez jamais un fichier SQLite utilisé par un service avec cp. La copie peut capturer une écriture en cours. L’archive semble alors complète, mais sa restauration produit une base de données à laquelle il manque des lignes. Arrêtez le service pendant les quelques secondes nécessaires à la copie :

docker compose stop vikunja
tar czf vikunja-$(date +%F).tgz files
docker compose start vikunja

Pour Planka, exportez PostgreSQL au lieu de copier le répertoire de données d’un cluster en fonctionnement. Sauvegardez aussi le volume des uploads séparément, car les pièces jointes ne sont pas stockées dans la base de données :

docker compose exec -T postgres pg_dump -U postgres -Fc planka > planka-db.dump
docker volume ls
docker run --rm -v planka_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files.tgz -C /data .

docker volume ls affiche le nom réel du volume. Il s’agit du nom de votre projet Compose suivi de _data. Si vous indiquez un nom inexistant, un volume vide est créé et vous obtenez une archive valide mais vide, sans message d’erreur. Vérifiez donc la taille du fichier ensuite.

Restaurez ensuite cette sauvegarde une fois dans une stack de test sur le même serveur, puis ouvrez une carte dont vous vous souvenez. Une sauvegarde jamais restaurée n’est qu’une supposition. Copiez aussi les archives hors du serveur, car une copie stockée sur le VPS que vous protégez n’est pas une sauvegarde. Sauvegardes restic depuis un VPS couvre cette partie.

Deux recommandations

Pour deux personnes sur un VPS de 2 GB : utilisez Planka. C’est l’outil qui se rapproche le plus de Trello par son apparence et son fonctionnement. L’importation depuis Trello consiste à déposer un fichier. Avec 280 MB de mémoire au repos, il reste l’essentiel des 2 GB pour le reverse proxy et les autres services hébergés. La Community License couvre gratuitement une équipe interne de deux personnes. Si vous préférez ne pas dépendre d’une licence qui autorise l’accès au code source, Vikunja avec SQLite, à 110 MB, est le choix open source adapté au même serveur.

Pour vingt personnes dans une organisation : utilisez Vikunja avec PostgreSQL. À cette échelle, vous avez besoin d’OpenID Connect plutôt que de vingt mots de passe locaux. Vous avez aussi besoin des équipes et du partage par projet. Une grande partie du travail ne tiendra pas sur un tableau. Les vues List, Table et Gantt ne sont donc plus un simple ajout pratique. La licence AGPL-3.0 évite également toute discussion sur la licence lorsque l’effectif augmente. Utilisez PostgreSQL plutôt que SQLite, placez le service derrière un reverse proxy et conservez le dump quotidien sur un autre serveur.

Si le serveur dispose de moins de 1 GB de RAM, aucune de ces deux options ne convient. Choisissez Kanboard à 70 MB, acceptez de ressaisir vos cartes Trello et utilisez la mémoire économisée pour autre chose dans la sélection d’outils self-hosted pour 2026. L’installation détaillée de l’outil choisi doit faire l’objet d’un guide distinct. Cette page sert uniquement à faire le choix.

FAQ

Quelle alternative auto-hébergée à Trello consomme le moins de RAM ?

Kanboard, avec environ 70 Mo au repos, car il repose sur PHP et SQLite et ne conserve rien en mémoire entre les requêtes. Vikunja arrive ensuite, avec environ 110 Mo sous la forme d’un binaire Go unique. Wekan est le plus lourd, avec environ 750 Mo, car Meteor conserve une couche de requêtes actives dans la mémoire de Node pour chaque navigateur connecté. Mesurez votre propre consommation avec docker stats une fois la stack au repos : ces chiffres sont indicatifs et ne constituent pas une garantie.

Puis-je importer mes tableaux Trello dans un outil auto-hébergé ?

Planka et Wekan acceptent directement l’export JSON d’un tableau Trello. Vikunja importe les données via le flux OAuth de Trello, et le migrateur doit être activé dans la configuration avant d’apparaître dans l’interface. Kanboard ne possède aucun importateur intégré. Tenez compte de deux limites : Planka n’importe ni les utilisateurs ni les pièces jointes et ne gère qu’une seule checklist par carte ; l’export JSON par défaut de Trello s’arrête à 1,000 actions sans vous avertir de la troncature.

Focalboard reste-t-il un bon choix en 2026 ?

Non. La dernière release autonome, v8.0.0, date de June 2024, soit 783 jours avant la vérification de cette comparaison, effectuée le 5 August 2026. Le README indique que le dépôt n’est actuellement plus maintenu. Mattermost a poursuivi le développement des tableaux uniquement sous la forme d’un plugin dans un dépôt distinct. La partie que vous devriez auto-héberger est donc celle dont le développement s’est arrêté. Choisissez plutôt Planka ou Vikunja.

Planka est-il toujours open source ?

Pas selon la définition de l’OSI. Planka était sous licence MIT, est passé sous AGPL-3.0 en 2023, puis est distribué sous la PLANKA Community License depuis la version 2.0. L’auto-hébergement est gratuit pour un usage personnel, interne, à but non lucratif ou éducatif. La revente de l’accès ou l’exploitation du logiciel en tant que service pour des tiers nécessite une licence commerciale. La vue calendrier, les rôles d’invité et les cartes récurrentes sont en outre réservés à l’offre Pro. Si une licence approuvée par l’OSI est obligatoire, Vikunja est sous AGPL-3.0 et Kanboard sous MIT.

Ai-je besoin de PostgreSQL, ou SQLite suffit-il ?

Vikunja, Kanboard et Focalboard utilisent SQLite par défaut, ce qui convient à quelques utilisateurs sur un même serveur. Planka nécessite PostgreSQL et ne propose aucune option SQLite. Passez à PostgreSQL lorsque plusieurs utilisateurs écrivent simultanément, car SQLite sérialise les écritures et une instance chargée commence à renvoyer database is locked. Ne placez pas non plus un fichier SQLite sur un partage réseau : la documentation de Kanboard déconseille SQLite sur NFS pour cette raison précise.