Portainer, l’outil gratuit de gestion Docker et Kubernetes déjà couvert sur ce site, s’apprête à changer de version bien plus profondément que le numéro ne le laisse croire. Dans un billet publié le 11 septembre 2026, le CEO Neil Cresswell annonce trois choses à la fois : une version majeure sur une base de code repensée et pensée Kubernetes en priorité, une nouvelle famille de consoles de gestion à usage unique, et un rôle différent pour l’édition Community (CE) gratuite.
Voici ce qui change réellement, ce qui reste identique, et ce qui a suscité les critiques de la communauté.
Une nouvelle version majeure, pensée Kubernetes d’abord
Portainer 2.45 LTS, sortie fin août 2026, est la dernière version de la branche 2.x. Vient ensuite la 3.0.0, livrée dans un premier temps en Short-Term Support (STS) sur la nouvelle base de code, avant qu’une version Long-Term Support (LTS) complète pour la branche 3.x n’arrive plus tard.
L’explication de Cresswell derrière cette refonte est assez directe : maintenir une parité de fonctionnalités complète entre Docker/Podman, Swarm et Kubernetes dans une seule base de code n’était plus tenable. Chaque nouvelle capacité en gestion des politiques, API d’opérations et authentification interne devait être développée trois fois, pour trois environnements différents. Or, deux de ces environnements ne concentrent plus l’essentiel des efforts d’ingénierie de l’écosystème aujourd’hui. Portainer 3.x est donc conçu Kubernetes d’abord, ce qui ouvre la voie à une nouvelle gamme de consoles spécialisées :
- Portainer-Run, déjà disponible, permet à des non-développeurs de déployer des applications construites par IA sur Kubernetes sans toucher à l’infrastructure
- Portainer-IDP, un portail développeur interne, à venir
- Portainer-Command, une passerelle MCP qui attribue aux agents IA des rôles en lecture seule à durée limitée et fait passer tout changement réel par GitOps
- Portainer-Operations, une console GitOps conçue pour les opérations quotidiennes de cluster
- Portainer-AiGrid, pour faire tourner des charges de travail IA sur Kubernetes
Plusieurs de ces outils s’appuient sur KubeSolo, la distribution Kubernetes mono-nœud open source et sous licence MIT de Portainer, qui intègre désormais nativement la couche de traduction Portainer-D2K : une seule installation fournit un cluster Kubernetes mono-nœud, un cluster Swarm synthétique et un hôte Docker synthétique, le tout sous 200 Mo de RAM grâce au passage de CRI-O à crun.
Si vous faites tourner Portainer sur Docker aujourd’hui, rien ne change
Pour les self-hosters, la vraie question est de savoir si une installation Docker existante demande une quelconque action. La réponse est non. Portainer affirme qu’elle continuera à livrer mises à jour de sécurité, correctifs de bugs et rétroportages sélectifs de fonctionnalités de la 3.x vers la branche 2.x. Rester sur la 2.x est présenté comme un choix durable et soutenu, pas comme une salle d’attente, sans migration forcée ni date limite annoncée.
Ce qui arrive vraiment à Portainer Community Edition
C’est le passage à lire deux fois. Portainer Community Edition, l’édition gratuite derrière la plupart des installations Docker en homelab, reste sur la base de code 2.x et ne recevra pas les changements de la 3.x. Aucune version CE distincte de la 3.0 n’est prévue.
Cela ne rend pas la 3.x payante pour autant. Portainer promet qu’elle restera gratuite pour la communauté via son programme existant « 3 Nodes Free », déjà crédité de plus de 110 000 licences Business gratuites actives. Sa justification : le modèle de politiques, l’API d’opérations et les consoles spécialisées de la 3.x sont conçus pour un usage entreprise, si bien que les distribuer sous l’étiquette CE donnerait, selon ses mots, « une image trompeuse de ce que c’est et à qui c’est destiné ».
En résumé : la 3.x sur Kubernetes est gratuite jusqu’à trois nœuds. Docker, lui, vous maintient sur la branche 2.x, étiquette CE incluse.
La contestation, et la mise au point de Portainer
L’annonce a suscité assez de réactions négatives pour que Portainer ajoute une section de clarification à ce même billet, intitulée « A clarification ». L’essentiel : l’entreprise affirme ne pas abandonner Docker, citant des clients commerciaux qui font tourner de larges flottes Docker comme preuve. L’un d’eux gère plus de 125 000 appareils Docker en périphérie de réseau, une flotte qui grossirait d’environ 7 000 appareils par mois, et qui paie Portainer pour que cela continue de fonctionner.
La branche 2.45 LTS, en Community comme en Business Edition, continuera de recevoir correctifs de sécurité, correctifs de bugs, et rétroportages de toute capacité de la 3.x ayant un équivalent dans l’API Docker. Ce que Portainer ne promet pas, c’est une parité de fonctionnalités complète : certaines capacités de la 3.x reposent sur des primitives natives à Kubernetes (politiques réseau, normes de sécurité des pods, contrôleurs d’admission) que Docker et Swarm n’ont tout simplement pas les moyens d’égaler.
Une passerelle gratuite, pour le jour où vous voudrez franchir le pas
Curieux de Kubernetes sans vouloir abandonner votre flux de travail Docker ? Portainer-D2K mérite un coup d’œil. C’est gratuit, open source, et disponible dès maintenant sur GitHub. Il présente un environnement Docker synthétique (nœud unique ou cluster façon Swarm) en réalité adossé à un vrai cluster Kubernetes : vos commandes docker et docker compose, vos outils CI/CD et de supervision compatibles Docker, continuent de fonctionner sans réécriture. Portainer annonce également l’arrivée d’un module de migration dédié, censé convertir les conteneurs et stacks Docker existants en manifestes Kubernetes via GitOps.
Ce qu’il faut retenir concrètement
Rien de tout cela n’exige d’action de la part d’un homelab ou d’une petite structure qui fait tourner Portainer sur Docker. La branche 2.x, CE incluse, continue de recevoir ses correctifs de sécurité et de bugs, et Portainer s’est engagée à prévenir à l’avance et à fournir un chemin de migration si le support Docker venait un jour à être réellement arrêté. Le changement est stratégique, pas immédiat : les nouveaux produits seront désormais conçus Kubernetes d’abord, et le support Docker/Swarm sur la 2.x devient une voie de maintenance plutôt que de croissance. C’est un changement de gouvernance à connaître, pas une raison de toucher à quoi que ce soit aujourd’hui.