Planka retire le SSO de son édition communautaire et désactive les comptes OIDC existants
Le 9 août 2026, Planka publie la version 2.2.0, qui retire l’authentification OIDC/SSO de l’édition communautaire et désactive les comptes qui en dépendaient. Avant de mettre à jour, créez un administrateur local, sinon l’instance peut devenir inaccessible.
9 août 2026. Planka publie la version 2.2.0 de son kanban auto-hébergé, et la note de version s’ouvre sur un avertissement en gras : « OIDC/SSO has been removed from PLANKA Community ». Le 14 août, la Self-Host Weekly consacre sa tribune de la semaine au sujet. La conséquence est immédiate pour les instances en production : tous les comptes qui se connectaient via SSO sont désactivés à la mise à jour.
Si votre instance Planka repose sur OIDC ou SAML pour l’authentification, cette version n’est pas une mise à jour comme les autres. C’est un changement de modèle économique qui vous concerne directement, et il arrive avec un piège : un administrateur qui n’existe que par SSO se retrouve verrouillé hors de sa propre instance.
Ce que fait réellement la 2.2.0
Le contenu de la note de version est sans ambiguïté. L’authentification OIDC/SSO est retirée de l’édition Community, et déplacée vers l’offre payante Planka Pro. Le mécanisme est précis :
- Après la mise à jour, tous les utilisateurs basés sur SSO sont désactivés, car ils n’ont plus de mot de passe local.
- Un administrateur peut restaurer leur accès en fixant un mot de passe à chacun puis en les réactivant, un par un.
- Si votre unique compte administrateur est basé sur SSO, vous êtes verrouillé. La documentation recommande de créer un administrateur local avant la mise à jour.
Deux autres changements accompagnent le lot. La version exige Node.js 24 pour les installations manuelles — les déploiements Docker ne sont pas concernés — et abandonne les images Docker armv7. C’est un détail pour la plupart des homelabs en x86-64 ou ARM64, mais les Raspberry Pi 3 et autres cartes 32 bits restent sur la 2.1.1.
Le point à retenir n’est pas technique, il est opérationnel. Une mise à jour qui désactive silencieusement des comptes — y compris potentiellement l’administrateur — n’est pas une mise à jour de routine. C’est une migration, et elle doit être traitée comme telle.
Le « SSO tax », une monétisation qui arrive après coup
Ce mouvement porte un nom dans l’écosystème auto-hébergé : le SSO tax. Le principe est simple — l’authentification unique est une fonctionnalité qu’une organisation ne peut pas se permettre de perdre, donc certains projets la placent derrière un paywall pour générer du revenu. Le site sso.tax recense le phénomène, qui ne touche pas que Planka.
Ce qui distingue le cas Planka, c’est la temporalité. La plupart des projets qui pratiquent le SSO tax le font dès l’origine : la fonctionnalité n’a jamais été gratuite, et l’utilisateur choisit en connaissance de cause. Ici, le SSO/OIDC était disponible dans l’édition communautaire, utilisé en production par des équipes et des associations, et il est retiré rétroactivement. Pour ceux qui ont investi du temps et de l’infrastructure dans la plateforme, c’est un rug-pull, et la réaction sur le dépôt GitHub (issue #1754) a été à la hauteur de la frustration.
Il faut aussi dire ce que cela signifie pour la sécurité des petites instances. Le SSO n’est pas un luxe d’entreprise : c’est souvent la seule manière, pour une petite équipe, de gérer proprement les départs, la révocation d’accès et l’authentification forte. Retirer le SSO de l’édition gratuite pousse ces équipes vers deux mauvaises options — payer pour une fonctionnalité qui était gratuite, ou revenir à des mots de passe locaux partagés.
Il serait malhonnête de ne pas regarder l’autre côté de la pièce. Les mainteneurs de Planka ne doivent rien à personne, et l’entretien d’un projet open source ne paie pas les courses — la phrase « Commits on GitHub don’t pay for groceries », repérée dans la même édition de la Self-Host Weekly, résume la tension. Un éditeur a le droit de chercher un modèle économique viable. La question n’est donc pas faut-il monétiser, mais comment : retirer une fonctionnalité de sécurité existante, en désactivant les comptes qui l’utilisaient, est la manière la plus brutale de le faire.
Ce que la 2.2.0 ajoute en échange
Ironie du calendrier, la 2.2.0 n’est pas une version au rabais. Elle ajoute précisément des fonctions de sécurité pour les comptes locaux :
- Authentification à deux facteurs (TOTP) pour les comptes locaux, avec dix codes de récupération et une réinitialisation côté administrateur.
- Déconnexion automatique en cas d’inactivité, avec délai configurable et avertissement avant la sortie.
- Appareils de confiance : marquer un navigateur comme fiable pour sauter la 2FA pendant une durée donnée, avec liste et révocation individuelle.
Autrement dit, la version renforce la sécurité de l’authentification locale au moment même où elle retire l’authentification fédérée. Le message est limpide : la 2FA est gratuite, l’OIDC est payant. Pour un homelab solo ou une petite équipe sans SSO, cette version est objectivement une amélioration. Pour une organisation qui s’appuie sur un fournisseur d’identité, c’est une régression nette.
Savoir si vous êtes concerné
Avant de décider quoi que ce soit, vérifiez si votre instance utilise réellement le SSO. Deux indices suffisent : la présence de comptes créés via OIDC/SAML dans la liste des utilisateurs, et la présence d’un fournisseur d’identité configuré dans votre déploiement. Si tout le monde se connecte par identifiant/mot de passe local, la 2.2.0 ne désactivera personne — le seul impact restant est l’exigence Node.js 24 pour les installations manuelles et la fin des images armv7.
Si un seul compte — même le vôtre — passe par le SSO, traitez la mise à jour comme une migration, pas comme une routine.
Les options avant la mise à jour
Si vous dépendez du SSO, quatre issues s’offrent à vous, et il faut choisir avant de lancer docker compose pull.
La première est la plus simple : ne pas mettre à jour. Épingler l’image à la dernière version compatible est une décision défendable à court terme, le temps de préparer la migration :
services:
planka:
image: ghcr.io/plankanban/planka:2.1.1
# reste sur la dernière version incluant le SSO/OIDCLa deuxième consiste à créer un administrateur local avant la mise à jour, pour ne jamais risquer le verrouillage. Depuis la 1.13, Planka ne crée plus d’administrateur automatiquement ; on le crée par script ou par variables d’environnement :
docker compose run --rm planka npm run db:create-admin-userLa troisième est de migrer vers Planka Pro, où le SSO reste inclus et maintenu. La migration depuis l’édition Community est documentée et s’effectue depuis le panneau client après l’achat.
La quatrième est de changer d’outil. Le marché des kanbans auto-hébergés est dense — Vikunja, Focalboard, Kanboard ou Wekan couvrent des besoins comparables, avec des politiques de monétisation différentes. C’est l’option la plus coûteuse en temps, mais la seule qui ne vous laisse pas dépendant d’une fonctionnalité que l’éditeur peut retirer du jour au lendemain.
Verdict
Planka reste un excellent kanban auto-hébergé, et la 2.2.0 apporte une vraie valeur — la 2FA TOTP et la déconnexion automatique étaient attendues depuis longtemps. Le problème n’est pas la technique, c’est la méthode : retirer une fonctionnalité de sécurité existante de l’édition gratuite, en désactivant les comptes qui l’utilisaient, est un précédent qui engage la confiance à long terme.
Si vous n’utilisez pas le SSO, la 2.2.0 est une mise à jour nette à appliquer : vous gagnez la 2FA, l’auto-logout et les appareils de confiance, sans rien perdre.
Si vous utilisez l’OIDC/SAML en production, ne mettez pas à jour tant que vous n’avez pas créé un administrateur local et choisi une destination — Planka Pro, un fork, ou un outil concurrent. Épingler la 2.1.1 vous donne le temps de décider sans subir un verrouillage au prochain docker compose up -d.