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 fonctionnalités 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 avec 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.

De combien de RAM chaque outil de tableau a-t-il besoin ?

[
  {
    "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 indique une minute après le démarrage de la stack. Utilisez-les pour dimensionner une offre, puis mesurez votre propre installation. La tendance compte davantage que le nombre exact de mégaoctets. Si le même VPS doit aussi héberger votre photothèque, dimensionnez d’abord cette partie, car les besoins minimaux de la comparaison entre PhotoPrism et Immich sont d’un tout autre ordre de grandeur. L’outil de tableau pourra ensuite utiliser la mémoire restante.

Kanboard constitue le minimum, à 70 MB, car il repose sur PHP et SQLite. Aucun processus applicatif de longue durée ne conserve vos tableaux en mémoire. Le conteneur utilise donc presque aucune mémoire 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 suffit pour 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 n’est donc pas facultative.

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 ouverts 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, ce que docker compose ps affiche comme une boucle de redémarrage. Confirmez-le sur l’hôte avec dmesg -T | grep -i "out of memory", car l’out-of-memory killer du kernel ne transmet jamais d’information à l’application.

La dépendance à une base de données détermine une grande partie du travail de sauvegarde. Voici donc un résumé pour chaque 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 filaire 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 fourni si vous souhaitez utiliser MongoDB.

Quels projets 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 du board dans un plugin hébergé 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 » évident de cette comparaison. Pour les autres, le choix dépend des compromis accepté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, et les deux versions précédentes sont sorties 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 il faut interpréter ces deux faits différemment. Vikunja a publié v2.5.0 comme une version mineure ordinaire. Wekan a publié v10.65, v10.66 et v10.67 le même jour, conformément à 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 : verrouillez 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 en août 2026.
• Vikunja propose quatre vues d’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 propose des tableaux avec des limites de travaux en cours, des sous-tâches, des pièces jointes, des commentaires, des actions automatiques et un petit langage de requêtes pour le filtrage. Sa page d’accueil indique elle-même : « Le nombre de fonctionnalités est volontairement limité », ce qui est une description juste.
• Wekan propose 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 sur les mêmes cartes. Il est mentionné ici par souci d’exhaustivité.

Si vous cherchez en réalité un wiki avec un suivi des tâches associé, ce comparatif ne correspond pas à votre besoin. BookStack, Wiki.js et Outline couvrent ce modèle, tandis que les alternatives auto-hébergées à Notion couvrent l’espace de travail tout-en-un.

Accès multi-utilisateur et authentification unique

Planka prend en charge OpenID Connect dans l’édition gratuite Community. 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 un 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 léger), 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, ce qui constitue une deuxième raison de l’écarter.

Toutes ces solutions peuvent être associées à un fournisseur d’identité Authentik que vous administrez 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 offre la procédure la plus simple. Exportez le tableau depuis Trello au format JSON, créez un tableau dans Planka, cliquez sur Import, puis sélectionnez Trello. Consultez 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 conservée, et l’export JSON standard de Trello s’arrête à 1,000 actions sans indiquer qu’il a tronqué le résultat. Vérifiez vous-même le fichier avant de faire confiance au résultat.

Vikunja utilise le flux OAuth de Trello, dans Settings, puis "Import from other services". Chaque migrateur 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’écarter si vous devez migrer plusieurs années d’historique Trello.

Quelle est l’expérience mobile ?

Vikunja est le seul des cinq à proposer des applications mobiles officielles. Les versions Android et iOS sortent en même temps que chaque release, et le dépôt de l’application la décrit comme étant en alpha. Considérez-la donc comme un complément à l’interface web, et non comme le principal moyen d’accès. Planka ne dispose d’aucune application officielle du projet, même si son interface web est responsive et que des clients tiers existent. 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 ce qui distingue Planka

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é à l’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 celle-ci n’est pas approuvée par l’OSI. L’auto-hébergement pour vos propres utilisateurs est gratuit et explicitement autorisé pour un usage personnel, interne, non lucratif ou éducatif. 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 cette condition avant d’y faire travailler vingt personnes. Les quatre autres projets sont véritablement open source : Vikunja est sous AGPL-3.0, Wekan et Kanboard sous MIT, et Focalboard combine Apache 2.0 et AGPL-3.0.

Fichiers Compose figés pour les deux choix

Fixez le tag de l’image. latest signifie que le prochain docker compose pull peut vous faire passer à une version majeure, et les versions majeures exécutent des migrations de base de données difficiles à 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 en bon état affiche le service comme running, et l’endpoint info renvoie du JSON contenant un champ version. Une erreur « Connection refused » signifie ici que le conteneur s’est arrêté. docker compose logs vikunja indique la raison, et une erreur de permissions sur le fichier de base de données est la cause la plus fréquente.

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 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 exposée directement à Internet. Les deux services sont liés à 127.0.0.1 : placez donc un reverse proxy devant eux et terminez TLS (transport layer security) à cet endroit. Traefik devant plusieurs applications Compose est la méthode habituelle dès que vous hébergez plusieurs services, et le guide sur les bases de Docker Compose explique les éléments de ces fichiers qui ne sont pas détaillés sur cette page.

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

Un outil de tableau peut tomber en panne sans afficher d’erreur. 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 plusieurs semaines plus tard.

Ne copiez jamais un fichier SQLite actif 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. Indiquer un nom inexistant crée un volume vide et produit une archive valide mais vide, sans afficher d’erreur. Vérifiez donc ensuite la taille du fichier.

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 que vous n’avez jamais restaurée reste une supposition. Envoyez 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

Deux personnes sur un VPS de 2 GB : utilisez Planka. C’est l’équivalent le plus proche de Trello en termes d’apparence et de fonctionnement. L’import depuis Trello se fait avec un fichier à glisser-déposer. Avec 280 MB de mémoire au repos, la majeure partie des 2 GB reste disponible 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 source-available, Vikunja avec SQLite, à 110 MB, est le choix open source pour le même serveur.

Vingt personnes dans une organisation : utilisez Vikunja avec PostgreSQL. À cette taille, vous avez besoin d’OpenID Connect plutôt que de vingt mots de passe locaux. Vous avez aussi besoin d’équipes et du partage par projet. Une grande partie du travail ne tiendra pas sur un tableau. Les vues List, Table et Gantt cessent donc d’être un simple bonus. AGPL-3.0 évite également toute discussion de licence lorsque l’équipe s’agrandit. Utilisez PostgreSQL plutôt que SQLite, placez Vikunja derrière un reverse proxy et conservez la sauvegarde quotidienne sur un autre serveur.

Si la machine dispose de moins de 1 GB de RAM, aucune des deux réponses ne s’applique. Installez Kanboard avec 70 MB, acceptez de ressaisir vos cartes Trello, puis utilisez la mémoire économisée pour autre chose dans la sélection d’outils d’auto-hébergement pour 2026. Si cette machine exécute déjà Jellyfin, Halcyon transforme la bibliothèque en vidéoclub des années 90 que l’on peut parcourir, ce qui constitue un occupant plus divertissant qu’un deuxième outil de gestion de tableaux. L’installation détaillée de l’outil choisi fera 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 gourmand, avec environ 750 Mo, car Meteor conserve une couche de requêtes actives en mémoire Node pour chaque navigateur connecté. Mesurez votre propre consommation avec docker stats une fois la stack au repos : ces valeurs sont indicatives 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 pas d’importateur intégré. Deux limites sont à prévoir : 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 indiquer qu’il a été tronqué.

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

Non. La dernière release autonome, v8.0.0, date de juin 2024, soit 783 jours avant la vérification de cette comparaison, effectuée le 5 août 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. Le serveur que vous pourriez auto-héberger est donc la partie qui n’est plus maintenue. Choisissez plutôt Planka ou Vikunja.

Planka est-il toujours open source ?

Pas au sens de 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 réservés à l’offre Pro. Si une licence approuvée par l’OSI est indispensable, 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 personnes sur un même serveur. Planka nécessite PostgreSQL et ne propose aucune option SQLite. Passez à PostgreSQL lorsque plusieurs personnes é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.