Ce que change Planka 2.2.0 — les faits
Le 9 août 2026, l'équipe Planka a publié la version 2.2.0. La issue #1754 et la note de version officielle confirment que le SSO OIDC quitte la Community Edition pour passer en fonctionnalité payante de l'offre Planka Pro.
Ce changement est immédiat à la mise à jour : aucune période de grâce n'est indiquée dans le journal. Plus grave, tous les comptes qui s'authentifiaient exclusivement via SSO sont désactivés après la montée de version — ils ne disposent d'aucun mot de passe local. L'administrateur doit réinitialiser manuellement chaque compte concerné avant de relancer le service. Si le seul administrateur de l'instance n'a pas de compte local, l'instance devient inaccessible.
La communauté des auto-hébergeurs a relevé ce signal rapidement : le bulletin hebdomadaire selfh.st du 14 août 2026 cite ce retrait parmi les événements notables de la semaine pour les administrateurs OIDC.
Pourquoi ce retrait pose un problème concret
- Production immédiatement impactée — une instance couplée à un IdP OIDC ne peut plus s'authentifier après la mise à jour ; les comptes SSO sont désactivés sans mécanisme de repli automatique.
- Aucune migration annoncée — la note de version ne propose pas de chemin de transition vers un mode de connexion alternatif pour les utilisateurs existants.
- Risque de verrouillage administrateur — si le seul admin utilise le SSO, l'instance devient inaccessible après la mise à jour sans création préalable d'un compte local.
- Brèche de sécurité potentielle — sans SSO, certaines équipes reviennent à des mots de passe locaux qui échappent aux politiques de rotation et de MFA centralisées.
- Coût de licence imprévisible — l'offre Planka Pro n'affiche pas de tarif public ; les équipes doivent demander un devis sans visibilité sur l'évolution tarifaire.
Migrer des données Planka : ce qui est exportable, ce qui ne l'est pas
C'est l'objection légitime avant toute migration : perdre l'historique des tâches ou les intégrations GitHub est inacceptable. Voici ce que Planka permet réellement d'exporter — et ce qu'il ne permet pas.
Ce qui n'existe pas nativement. Planka ne propose pas d'export JSON ou CSV de vos tableaux. Les demandes de fonctionnalité datent de plusieurs années (issue #670) et n'ont pas abouti à ce jour.
Ce qui est possible. Planka supporte l'import de tableaux Trello au format JSON — mais uniquement en entrée, pas en sortie. La seule extraction fiable de vos données passe par un dump direct de la base PostgreSQL (pg_dump).
Comment limiter le risque de migration.
1. Double-run temporaire — faire tourner la nouvelle instance (Kaneo ou Vikunja) en parallèle de Planka pendant une à deux semaines.
2. Snapshot de la base avant coupure — effectuer un pg_dump complet de la base Planka la veille de la coupure.
3. Gel des nouvelles tâches pendant la migration — communiquer une fenêtre de gel (quelques heures) pendant laquelle aucune carte n'est créée ou déplacée.
Les intégrations GitHub (liens de commits, webhooks) sont configurées au niveau de votre fournisseur Git, pas stockées dans Planka : elles se reconfigurent en quelques minutes dans Kaneo ou Vikunja après migration.
Kaneo et Vikunja : l'état du SSO OIDC en édition gratuite
Kaneo v2.16.2 (licence MIT) — publiée le 10 août 2026 sur GitHub, cette version maintient le support OAuth 2.0 et OIDC dans l'édition libre. La configuration est documentée sur kaneo.app/docs : Kaneo supporte la découverte automatique du fournisseur via une URL de discovery, le PKCE, le lien de compte avec un compte local existant et le logout côté fournisseur. La licence MIT permet l'usage commercial et la modification sans conditions.
Vikunja v2.4.0 (licence AGPL-3.0) — cette version maintient le SSO OIDC dans l'édition gratuite. La note de version Vikunja 2.4.0 le confirme explicitement : *« the things people often assume are enterprise upsells, SSO and LDAP, are still free and always have been »*. La configuration OIDC est documentée à vikunja.io/docs/openid.
Les deux projets maintiennent leur SSO OIDC dans l'édition gratuite sans annonce de changement de plan à horizon visible.
Comparatif : Kaneo vs Vikunja pour remplacer Planka
Les deux outils sont des gestionnaires de tâches open source avec SSO OIDC gratuit, mais leurs positionnements diffèrent.
Comparatif
| Critère | Kaneo v2.16.2 | Vikunja v2.4.0 |
|---|---|---|
| Licence | MIT | AGPL-3.0 |
| Philosophie UI | Kanban minimaliste, proche de Planka | Listes, Kanban, Gantt, Calendrier |
| SSO OIDC (gratuit) | Oui — OAuth 2.0 / OIDC avec PKCE | Oui — OpenID Connect natif |
| Ressources recommandées | 1 vCPU / 512 Mo RAM (PostgreSQL inclus) | 1 vCPU / 1 Go RAM (SQLite par défaut) |
| Base de données | PostgreSQL | SQLite (dev) / PostgreSQL, MySQL (prod) |
| Idéal pour | Migration directe depuis Planka, même philosophie Kanban | Équipes voulant plus de vues et de fonctionnalités |
Quelle alternative choisir ?
Choisissez Kaneo si votre équipe est attachée à l'interface Kanban épurée de Planka et veut un remplacement comme-pour-comme. L'empreinte mémoire est plus légère (512 Mo RAM), la licence MIT est sans contrainte, et la philosophie du projet est explicitement minimaliste : « All you need. Nothing you don't. »
Choisissez Vikunja si vos équipes ont besoin de plusieurs vues (Gantt, calendrier, liste) ou si vous gérez des projets complexes avec des dépendances entre tâches. La licence AGPL n'est pas une contrainte pour un self-hosting interne.
Dans les deux cas, le SSO OIDC est gratuit, disponible dès l'installation, et compatible avec les IdP courants (Google Workspace, Authentik, Authelia, Keycloak). Consultez nos guides dédiés : installer Kaneo sur VPS et installer Vikunja sur VPS.
Plan de migration en trois étapes
Étape 1 — Snapshot et double-run (J-7 à J-1)
Avant toute coupure, effectuez un dump complet de votre base PostgreSQL Planka :
pg_dump -U planka planka > planka_snapshot_$(date +%Y%m%d).sqlInstallez votre nouvelle instance (Kaneo ou Vikunja) sur un sous-domaine temporaire et configurez le SSO OIDC avec les mêmes paramètres client que votre IdP existant. Faites valider la connexion par vos administrateurs avant de communiquer sur la migration.
Étape 2 — Reprise manuelle des données actives (J)
Planka n'exporte pas en JSON ou CSV : la migration de contenu est manuelle pour les tableaux actifs. Identifiez les 2 à 5 tableaux les plus utilisés et planifiez une session de transfert avec vos équipes. Les tableaux archivés ou peu actifs peuvent rester consultables dans Planka en lecture seule le temps de la transition.
Étape 3 — Coupure et retrait du DNS (J+7)
Une fois les équipes autonomes sur la nouvelle instance, basculez le DNS de votre sous-domaine Planka vers une page de redirection, puis planifiez l'arrêt du conteneur Planka à J+30. Conservez le snapshot PostgreSQL pendant 90 jours minimum.
Activer cette solution
Kaneo est le successeur naturel de Planka — même philosophie Kanban minimaliste, licence MIT, SSO OIDC gratuit dès la première connexion. Le template VPS ServOrbit est préconfiguré et démarre en moins de deux minutes. Vous ne migrez pas vers un outil plus complexe : vous remplacez comme-pour-comme, sans perdre le SSO.
Deployer depuis : Activer cette solution
