12 points par GN⁺ 2026-01-24 | 3 commentaires | Partager sur WhatsApp
  • Ancien pionnier de la conteneurisation, Docker a multiplié les changements de cap pour trouver son identité et son modèle de revenus à l’horizon 2026
  • Après son échec face à Kubernetes, l’entreprise a cédé Swarm et déplacé son attention vers un écosystème d’outils centré sur l’expérience développeur (Scout, Testcontainers)
  • Elle s’est ensuite étendue à une plateforme d’exécution de modèles d’IA (Model Runner) et à la sécurité pour l’IA (MCP Defender), se transformant progressivement en entreprise d’infrastructure IA
  • Fin 2025, elle a publié en open source sous licence Apache 2.0 plus de 1 000 images durcies (Hardened Images), en réponse au succès de Chainguard
  • Cette série de changements, ainsi que le remplacement du CEO et les rumeurs de rachat, suggèrent que Docker se trouve moins dans une logique d’entreprise indépendante que dans une phase de réorganisation en vue d’une vente

La crise d’identité de Docker

  • Docker, l’entreprise qui a créé le standard de la conteneurisation, traverse une crise d’identité : bien qu’elle ait déjà trouvé son adéquation au marché, elle a échoué à la monétiser
    • À mesure que sa technologie centrale est devenue open source puis générique, il est devenu plus difficile de créer une valeur ajoutée réellement différenciante
    • Docker est devenu une infrastructure utilisée par tous, mais de moins en moins de clients sont prêts à payer directement

La fin de Swarm et le recul stratégique

  • Docker Swarm était une solution d’orchestration conçue pour concurrencer Kubernetes, mais la victoire totale de Kubernetes a conduit Docker à se retirer du marché
    • Docker a ensuite abandonné sa stratégie de plateforme full-stack pour se concentrer sur les domaines où il pouvait encore proposer quelque chose d’unique

Virage vers les outils pour développeurs

  • Docker a fait de l’amélioration de l’expérience développeur son principal facteur de différenciation
    • Docker Scout, introduit après l’acquisition d’Atomist en 2022, apporte des fonctions de sécurité de la supply chain logicielle et de visualisation des vulnérabilités
    • Grâce au rachat d’AtomicJar, Docker a mis la main sur Testcontainers, rendant possibles des tests d’intégration fondés sur des dépendances réelles
    • Ces capacités renforcent la valeur de Docker sur les volets sécurité, observabilité et fiabilité des tests

Virage centré sur l’IA

  • Docker a ensuite réorienté sa stratégie vers une plateforme d’exécution de modèles d’IA
    • Docker Model Runner prend en charge l’exécution de modèles d’IA, tandis que Docker Compose a été étendu pour orchestrer des agents et des modèles d’IA
    • Docker Offload permet l’exécution de charges de travail IA sur GPU à l’échelle du cloud
    • Des partenariats ont été conclus avec Google Cloud, Microsoft Azure, CrewAI, LangGraph, Vercel AI SDK et d’autres acteurs
    • En septembre 2025, avec l’acquisition de MCP Defender, Docker a ajouté des capacités de sécurité IA et de détection des menaces à l’exécution, accélérant sa transformation en entreprise de sécurité de l’infrastructure IA

Publication des images durcies

  • En décembre 2025, Docker a rendu gratuitement disponibles sous licence Apache 2.0 plus de 1 000 Hardened Images
    • Elles permettent de réduire jusqu’à 95 % les vulnérabilités par rapport aux images existantes
    • Cette décision est perçue comme une réponse au succès des images sécurisées de Chainguard
    • La gratuité et l’open source constituent une stratégie concurrentielle puissante, mais elles révèlent aussi le manque de clarté du modèle de revenus

Changement de direction et rumeurs de rachat

  • En février 2025, le CEO Scott Johnston a quitté ses fonctions, remplacé par Don Johnson, fondateur d’Oracle Cloud Infrastructure
    • Après ce changement de direction, le secteur a commencé à évoquer la possibilité d’un rachat par un grand acteur du cloud
    • La succession de pivots stratégiques et le changement de CEO laissent penser que Docker prépare peut-être davantage une vente qu’une croissance indépendante

Perspectives

  • La technologie Docker elle-même devrait perdurer, car elle est déjà profondément intégrée à l’infrastructure
    • De par sa nature open source, la technologie des conteneurs continuera d’exister, quelle que soit l’évolution de l’entreprise
  • En revanche, la pérennité de Docker Inc. comme entreprise reste incertaine
    • Les changements stratégiques fréquents et les remaniements de direction mettent en lumière l’absence d’une vision de long terme
  • Le cas Docker est vu comme un avertissement sur les limites de la monétisation d’une technologie open source devenue trop largement adoptée

3 commentaires

 
hongminhee 2026-01-24

C’est peut-être un jugement un peu sévère, mais pour garder un certain équilibre, ce commentaire publié sur Lobsters mérite aussi d’être lu. En gros, il explique qu’une grande partie de ce que nous pensons que Docker, Inc. a innové reposait déjà sur des concepts et des technologies préexistants, et que Docker, Inc. a tenté de se les approprier.

 
ethanhur 2026-01-24

C’est une technologie/entreprise qui a beaucoup contribué au secteur, donc c’est dommage que l’opinion à son égard se soit autant dégradée.

Des erreurs comme le changement de politique de licence ont sans doute beaucoup joué, mais je n’arrive pas à me défaire de l’impression que la monétisation devient de plus en plus difficile pour les entreprises open source.

 
GN⁺ 2026-01-24
Réactions sur Hacker News
  • La technologie Docker a réussi, mais le vrai problème a été l’absence d’une stratégie de monétisation solide
    En réalité, Docker était open source dès le départ, et d’autres équipes faisaient déjà des choses similaires
    Mais Docker l’a rendu facile à utiliser pour le grand public, puis a trop attendu pendant que d’autres entreprises sortaient de meilleurs produits
    Swarm n’avait pas été conçu pour concurrencer Kubernetes, mais simplement comme un outil de clustering
    Le fait d’avoir offert gratuitement des fonctions de sécurité était remarquable, mais au final l’entreprise ne s’est pas vraiment laissé de marge de manœuvre
    En agissant comme une organisation à but non lucratif, c’était bénéfique pour les utilisateurs, mais désavantageux à long terme pour l’entreprise

    • Le problème, c’est que Docker a refusé le modèle de revenus classique des entreprises open source, à savoir les contrats de support entreprise
      Les clients professionnels voulaient des réponses sur les problèmes de sécurité du daemon Docker exécuté avec les privilèges root, sur les conflits avec systemd et sur l’exploitation de registres privés, mais Docker a ignoré ces besoins
      Red Hat a même proposé des correctifs, mais après leur refus, l’entreprise a fini par créer des alternatives comme Podman et Quay et a récupéré le marché entreprise
    • Quand on pense au fait que Docker a cofondé l’Open Container Initiative en 2015, l’idée qu’ils se comportaient comme une organisation non lucrative devient encore plus intéressante
      Quelqu’un a même plaisanté sur la possibilité que l’entreprise Docker ait été en elle-même un « plan de long terme » visant à soutenir l’open source grâce à l’argent du capital-risque
    • Docker aurait dû rendre Docker Desktop payant dès le début
      Même à 5 dollars par mois, cela aurait semblé naturel, alors que le passage ultérieur au payant a donné une impression de « rug pull »
      Le vrai problème a été de ne pas avoir défini de modèle économique dès le départ et de s’être concentré uniquement sur une idée séduisante
    • La véritable innovation de Docker, c’était le format Dockerfile et le registre gratuit
      Ces deux éléments ont permis à la communauté de croître de manière explosive
      Même aujourd’hui, avec d’autres outils, on écrit encore des Dockerfile et on utilise des dépôts similaires à Docker Hub
    • Certains ne sont pas d’accord avec l’idée que Swarm n’était pas destiné à rivaliser avec Kubernetes
      En tout cas, le marketing le positionnait clairement ainsi
  • La manière dont Docker a réagi lors du changement de politique de licence lui a fait perdre la confiance des utilisateurs
    On peut comprendre qu’une licence commerciale soit demandée aux entreprises qui génèrent du chiffre d’affaires, mais c’est l’approche qui a posé problème
    Envoyer des mails du type « achetez une licence sous 30 jours ou nous engagerons des poursuites » n’a fait qu’alimenter la défiance
    Au final, les entreprises sont passées à Rancher Desktop

    • Notre entreprise a vécu quelque chose de similaire
      D’un coup, un mail interne a circulé disant « n’installez pas Docker Desktop », ce qui a créé de la confusion alors même que nous poussions une transition vers les conteneurs
    • Cette attitude rappelait Oracle
    • Le changement de licence en soi ne pose pas problème, mais certains se demandent pourquoi un préavis de 30 jours serait problématique
      Après tout, il y avait eu une annonce préalable, et demander l’arrêt de l’usage ou le paiement peut sembler une procédure normale
    • Ce changement de politique a finalement donné à Podman une raison d’exister
      Si Docker n’avait pas agi ainsi, il n’y aurait peut-être pas eu de motivation pour développer une alternative
      Il aurait mieux valu rendre Docker Hub payant plus tôt ou construire des solutions de workflow pour l’entreprise
    • Certains ont aussi fait remarquer qu’une entreprise de taille intermédiaire devrait utiliser un système de gestion d’installation comme SCCM
  • Docker disposait d’une excellente technologie, mais n’a jamais trouvé son marché (Product-Market Fit)
    Son succès est venu de sa diffusion en tant qu’open source gratuit, mais cela n’a pas fonctionné sur le marché payant

    • Une opinion plus cynique disait qu’au final Docker n’est rien d’autre qu’un simple wrapper autour de l’appel système setns()
  • Docker semble critiqué quoi qu’il fasse
    Le garder en open source pose problème, faire payer les fonctionnalités entreprise pose problème, explorer les outils IA pose aussi problème
    Docker continue pourtant à maintenir des runtimes clés comme containerd et runc
    Et malgré cela, certains disent encore que Docker n’a plus de sens

    • runc a déjà été donné à l’OCI, et containerd est géré sous l’égide de la CNCF
      Podman utilise une base de code distincte maintenue par Red Hat
    • Podman ne dépend pas de Docker, car il a réimplémenté presque tout
    • En regardant la liste des mainteneurs de containerd et moby, on voit encore des employés de Docker
      En revanche, il n’est pas clair s’ils bénéficient officiellement du soutien de Docker
    • Rancher, containerd et podman ne dépendent pas de Docker ; ils ne fournissent qu’une couche de compatibilité
    • Docker Desktop n’est pas open source, et certains critiquent le modèle Open Core, estimant qu’il ne correspond pas à l’esprit du véritable open source
  • Le fondateur de Docker est intervenu en personne pour expliquer que « tout a commencé en 2008 avec Dotcloud et qu’il est parti en 2018 », puis a lancé un AMA (posez-moi n’importe quelle question)

    • Un utilisateur a dit vouloir en savoir plus sur le développement de Docker, sa commercialisation et sa situation actuelle
    • Un autre a demandé quelle était selon lui la priorité absolue pour Docker aujourd’hui
    • Certains ont aussi demandé ce qu’il pensait de Podman
    • Une question a également porté sur les projets à venir pour le nouveau projet Dagger
    • Quelqu’un a aussi demandé ce qu’il aurait fait différemment avec le recul
  • Certains ont suggéré que Docker devait lancer un nouveau produit
    Par exemple, créer une VM à démarrage ultra-rapide appelée DockerVM pour concurrencer Firecracker ou gVisor,
    ou encore lancer un sandbox runner pour agents IA

    • En pratique, Docker a déjà publié la documentation AI Sandboxes
    • D’autres estimaient qu’un service de CI Runner serait aussi une bonne direction
  • L’une des raisons pour lesquelles certains n’aiment pas Docker tient à la nécessité des privilèges root et à la façon dont les images sont gérées
    Ils voudraient simplement pouvoir les déplacer avec mv ou cp, mais Docker les gère via une base de données interne

    • Il existe bien un mode rootless, mais il nécessite une configuration de l’hôte
      Ce n’est pas une limite propre à Docker, mais une contrainte du noyau Linux
      Le stockage des images ne repose pas sur une base de données mais sur un système de fichiers adressé par contenu
      Le modifier directement créerait des problèmes de sécurité
      Voir la documentation rootless Docker pour plus de détails
    • Il existe aussi un tutoriel rootless pour Podman
    • Certains trouvent étrange de se plaindre qu’un utilisateur non root ne puisse pas installer le logiciel
      Le vrai problème était plutôt que l’utilisation de Docker permettait une élévation de privilèges root, et Podman a résolu cela
    • Pour un sandboxing plus robuste, on peut aussi envisager des alternatives comme gVisor(runsc)
      Voir la documentation gVisor
  • Sur macOS, apple/container émerge comme une bonne alternative à Docker for Mac
    Quelqu’un dit l’utiliser depuis six mois ; il reste encore des problèmes, mais le développement est actif
    apple/container GitHub

    • nerdbox de containerd a aussi été cité comme alternative (nerdbox GitHub)
    • Une question a été posée pour savoir si cela permettait aussi de construire des images exécutables sous Windows ou Linux
    • D’autres demandaient quel était le surcoût de performance par rapport à Docker for Mac
  • Autrefois, certains aimaient beaucoup docker-compose, mais aujourd’hui ils préfèrent la combinaison nix + process-compose
    Cela reste flexible, car on peut ajouter k3s ou tilt seulement quand c’est nécessaire

    • Quelqu’un a demandé comment utiliser Nix pour gérer plusieurs instances de serveur
      Il hésite entre exécuter Nix dans Docker ou Docker dans Nix
    • D’autres ont réagi en disant qu’il fallait absolument essayer process-compose
  • Notre entreprise utilise encore Docker Swarm en production
    Pour la plupart des entreprises, Kubernetes est une sur-ingénierie
    Swarm reste simple et suffisamment puissant