Docker Desktop 4.39 : MCP pour l'agent IA et CLI en GA

Docker Desktop 4.39, sorti le 6 mars 2025, n'est pas une mise à jour de maintenance ordinaire. Deux évolutions structurelles y coexistent : le Docker AI Agent s'appuie désormais sur le Model Context Protocol (MCP) pour passer du mode conversationnel au mode actionnable sur Kubernetes, et le Docker Desktop CLI quitte la bêta pour entrer en disponibilité générale. Pour les équipes PHP/Symfony qui conteneurisent leur chaîne de développement, c'est un palier concret — pas une promesse marketing.

Docker AI Agent + MCP : du chatbot à l'agent Kubernetes

Depuis sa sortie en 2024, le Docker AI Agent se limitait à répondre à des questions sur tes images et tes Compose files. Avec 4.39, il franchit un cap : grâce à l'intégration native du Model Context Protocol (standardisé par Anthropic en novembre 2024 et déjà adopté par une dizaine d'outils), l'agent peut désormais agir. Il interroge l'état réel de ton cluster Kubernetes local, déploie des services, lit les logs de pods en direct. Ce n'est plus un assistant qui suggère — c'est un agent qui exécute.

Concrètement, l'agent expose trois capacités MCP documentées dans cette version : gestion de namespaces Kubernetes (create, list, delete), déploiement de services depuis une description en langage naturel, et analyse de logs de pods avec résumé structuré. Le tout sans quitter Docker Desktop. Si tu as déjà utilisé Claude 3.7 Sonnet via une interface MCP pour interroger un outil externe, le mécanisme est identique — Docker joue ici le rôle de serveur MCP local.

# Exemple : demander à l'agent d'analyser un pod en erreur
# via l'interface Docker Desktop AI (onglet Ask Gordon)
# "Pourquoi le pod symfony-worker-xxx est-il en CrashLoopBackOff ?"

# L'agent émet en coulisses les appels MCP suivants :
# mcp://docker/kubernetes/pods/logs?namespace=default&pod=symfony-worker-xxx
# puis résume la stack trace PHP sans que tu tapes une seule commande kubectl

Docker Desktop CLI en GA : ce que tu peux maintenant scripter

Le CLI Docker Desktop était en bêta depuis plusieurs mois. Il est désormais stable et intégré au PATH sur macOS, Windows et Linux. La commande centrale est docker desktop, qui expose le cycle de vie de l'application elle-même — démarrage, arrêt, état et reset des paramètres — directement depuis le terminal. Pour les équipes qui provisionnent les postes développeurs via Ansible ou un script d'onboarding, c'est la fin des contournements.

• docker desktop start / stop : démarre ou arrête Docker Desktop sans interaction GUI
• docker desktop status : retourne l'état JSON (running, stopped, starting) — scriptable
• docker desktop settings : lit et écrit la config (resourceAllocation, kubernetes.enabled…) en CLI
• docker buildx build --platform linux/amd64,linux/arm64 : le flag --platform multi-arch est maintenant documenté GA avec les binaires Docker Desktop

#!/usr/bin/env bash
# Script d'onboarding équipe Symfony — Docker Desktop 4.39+

set -euo pipefail

# Attendre que Docker Desktop soit opérationnel
until docker desktop status 2>/dev/null | grep -q '"running"'; do
  echo "En attente de Docker Desktop..."
  sleep 3
done

# Activer Kubernetes localement via CLI
docker desktop settings --kubernetes.enabled=true

# Builder l'image Symfony en multi-arch
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag registry.example.com/symfony-app:latest \
  --push \
  .

Impact réel sur un workflow Symfony conteneurisé

Sur un projet Symfony 7.2 / PHP 8.4, les deux apports se combinent de façon pratique. Côté build, le flag --platform en GA supprime les erreurs silencieuses lors du déploiement d'images AMD64 sur des runners ARM (Apple Silicon ou instances Graviton). Côté debug, l'agent MCP réduit significativement le temps de diagnostic Kubernetes local : au lieu de naviguer entre kubectl describe pod, kubectl logs et la documentation, tu poses la question en langage naturel et l'agent consolide la réponse depuis les données réelles du cluster.

# docker-compose.yml — Symfony 7.2 / PHP 8.4
# Compatible Docker Desktop 4.39 GA
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      platforms:
        - linux/amd64
        - linux/arm64
    environment:
      APP_ENV: dev
      DATABASE_URL: postgresql://app:secret@db:5432/app
    volumes:
      - .:/var/www/html:cached
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      timeout: 5s
      retries: 5

CVE-2025-1696 et sécurité : point rapide

Docker Desktop 4.39 corrige également la CVE-2025-1696, une vulnérabilité affectant la couche de virtualisation réseau sur macOS et Windows. Si tu n'as pas encore appliqué la mise à jour, c'est une raison supplémentaire de le faire sans attendre — au-delà des nouvelles fonctionnalités. La mise à jour est disponible directement depuis Docker Desktop (icône de barre de menus → Check for updates) ou via docker desktop update depuis le CLI.

Docker Desktop 4.39 marque une évolution de posture : l'outillage local se rapproche du paradigme agent-first qui s'installe progressivement sur l'ensemble de la chaîne de développement. Pour les équipes Symfony qui hésitent encore à intégrer Kubernetes en local ou à standardiser leur setup multi-arch, c'est le bon moment pour poser les bases. Si tu veux un regard externe sur ta stack conteneurisée — images, Compose, pipeline CI et surface de sécurité — le Bear Scan est un audit technique ciblé fait pour ça.