Kubernetes est mort. Vive l’IDP.

Voilà une affirmation qui fait grincer des dents dans les salles de conférence des DSI. Mais soyons honnêtes : le Kubernetes que vous avez appris à dompter entre 2018 et 2022 n’existe plus vraiment. Ce n’est pas une mort, c’est une métamorphose. En 2026, Kubernetes n’est plus un orchestrateur de conteneurs que vos équipes ops configurent à la main — c’est devenu le système d’exploitation de facto pour les workloads IA/ML à l’échelle de l’entreprise. Et cette transformation change radicalement la façon dont les organisations construisent leur socle technologique.

Selon le rapport CNCF Annual Survey 2025, 80 % des organisations en production ont désormais une forme d’Internal Developer Platform (IDP) construite au-dessus de Kubernetes. Ce chiffre n’est pas anodin : il traduit un glissement tectonique dans la manière dont les entreprises pensent la livraison logicielle, l’infrastructure IA et la gouvernance des ressources GPU.

Qu’est-ce qu’un Internal Developer Platform, exactement ?

Un IDP n’est pas un produit que vous achetez. C’est une couche d’abstraction — un ensemble d’outils, de workflows et de contrats d’interfaces — que votre équipe Platform Engineering construit pour vos développeurs. L’objectif est simple en théorie, brutal en pratique : que le développeur qui veut déployer un fine-tuning de LLaMA 3 sur des GPU A100 n’ait jamais à rédiger un seul manifeste YAML de NodeAffinity ou à comprendre ce qu’est un Device Plugin Kubernetes.

Le concept s’oppose frontalement à l’ancien modèle « tu veux déployer ? parle à l’ops ». Dans un IDP mature, le développeur ouvre un portail (souvent Backstage), sélectionne un template de workload IA, renseigne quelques paramètres (taille du modèle, dataset, budget GPU, SLA), et l’IDP s’occupe du reste : provisionnement du namespace, allocation des ressources via DRA, configuration du monitoring, création des pipelines CI/CD, et intégration au catalogue de services.

Pourquoi Kubernetes s’impose comme l’OS de l’IA

La question mérite d’être posée sans complaisance : pourquoi Kubernetes et pas autre chose ? Pourquoi pas des plateformes managées comme SageMaker, Vertex AI ou Azure ML Studio ?

La réponse tient en trois mots : portabilité, extensibilité, contrôle. Les hyperscalers vous vendent de la simplicité en échange de votre souveraineté. Kubernetes, lui, vous donne un socle universel sur lequel vous restez maître. En 2026, avec la montée des préoccupations réglementaires autour de l’IA (AI Act européen, Executive Order américain), les entreprises ne peuvent plus se permettre d’avoir leurs workloads d’entraînement de modèles enfermés dans un seul cloud.

Par ailleurs, l’écosystème Kubernetes a considérablement mûri pour les cas d’usage IA. La Dynamic Resource Allocation (DRA), stabilisée dans Kubernetes 1.32, permet enfin une gestion fine des GPU et des accélérateurs NPU. Le projet Kubeflow 2.0, les opérateurs comme KServe pour l’inférence, ou encore Volcano pour le scheduling de jobs batch ML — l’infrastructure existe, elle est production-ready, et elle s’intègre nativement dans n’importe quel IDP construit sur Kubernetes.

Déployer un IDP avec Backstage : un exemple concret

Arrêtons la théorie. Voici à quoi ressemble le déploiement d’un IDP minimal basé sur Backstage dans un cluster Kubernetes, via Helm :

# values.yaml pour le chart Helm Backstage (IDP baseline)
backstage:
  image:
    registry: ghcr.io
    repository: backstage/backstage
    tag: "1.28.0"

  appConfig:
    app:
      title: "Mon IDP IA Entreprise"
      baseUrl: https://idp.monentreprise.internal

    catalog:
      providers:
        kubernetes:
          - rules:
              - allow: [Component, API, Resource]

    gpu:
      dra:
        enabled: true
        resourceClaimTemplates:
          - name: gpu-a100-training
            spec:
              devices:
                requests:
                  - name: gpu
                    deviceClassName: nvidia.com/gpu
                    count: 4

postgresql:
  enabled: true
  auth:
    username: backstage
    database: backstage_plugin_catalog

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: idp.monentreprise.internal
      paths:
        - path: /
          pathType: Prefix

# Commandes de déploiement :
# helm repo add backstage https://backstage.github.io/charts
# helm upgrade --install backstage backstage/backstage 
#   --namespace platform --create-namespace 
#   --values values.yaml --wait --timeout 10m

Ce manifeste illustre l’essentiel : Backstage devient le portail unifié, PostgreSQL stocke le catalogue de services, et l’intégration DRA permet aux développeurs de réclamer des GPU via des templates prédéfinis — sans jamais toucher aux entrailles de Kubernetes.

Le rôle de l’IA dans les IDP : de l’automatisation à l’autonomie

Le paradoxe amusant de 2026, c’est que les IDP sont désormais eux-mêmes alimentés par l’IA qu’ils sont censés héberger. Les plateformes les plus avancées intègrent des couches d’intelligence qui transforment l’expérience développeur de manière radicale.

Concrètement, cela se traduit par des copilotes d’infrastructure capables de recommander automatiquement le bon profil de ressources pour un job d’entraînement, d’analyser les logs de crashs de pods et de proposer un correctif YAML en langage naturel, ou encore de détecter les dérives de coût GPU en temps réel. Des outils comme k8sGPT, désormais intégré nativement dans plusieurs distributions Kubernetes enterprise, illustrent cette tendance.

Selon un article de DevOps.com, les équipes platform engineering qui ont intégré des assistants IA dans leur IDP rapportent une réduction de 40 % du temps passé à résoudre les incidents d’infrastructure liés aux workloads ML.

Les pièges que personne ne vous dit d’éviter

Construire un IDP, c’est aussi construire une dette technique d’un nouveau type. Les équipes qui se lancent tête baissée en 2026 font souvent les mêmes erreurs.

L’erreur n°1 : confondre IDP et portail de self-service. Un formulaire web qui crée des namespaces, ce n’est pas un IDP. Un IDP, c’est un contrat : il encode les opinions de votre organisation sur la façon correcte de déployer, monitorer, sécuriser et facturer les workloads.

L’erreur n°2 : ignorer le « golden path ». Le concept de golden path — le chemin idéal et pré-balisé que l’IDP propose par défaut — est critique. Si vous offrez trop de liberté, les développeurs reproduisent le chaos que vous vouliez éliminer.

L’erreur n°3 : sous-estimer le changement culturel. Comme le souligne un article de Medium sur le Platform Engineering, la résistance vient rarement des outils — elle vient des équipes ops habituées à être le goulot d’étranglement central.

L’écosystème CNCF qui fait tourner les IDP en 2026

Un IDP production-ready ne se construit pas ex nihilo. En 2026, la stack CNCF de référence pour les IDP IA comprend généralement :

  • Backstage — portail développeur et catalogue de services
  • Crossplane — provisionnement d’infrastructure déclaratif
  • ArgoCD + Argo Workflows — GitOps et orchestration de pipelines ML
  • Karpenter — auto-scaling intelligent des nodes, critique pour les workloads GPU éphémères
  • OpenCost — attribution des coûts par workload, par équipe, par modèle IA
  • Prometheus + Grafana — observabilité, enrichis de dashboards GPU via DCGM Exporter
  • Kubeflow Pipelines — orchestration ML end-to-end

La CNCF publie régulièrement des rapports sur l’adoption de ces outils : Backstage a dépassé les 3 000 entreprises utilisatrices en production, Crossplane a vu son adoption tripler en 18 mois, et KServe s’impose comme le standard de facto pour le serving de modèles en inférence.

Conclusion : votre feuille de route IDP pour les 12 prochains mois

Le message est clair : en 2026, ne pas avoir de stratégie IDP, c’est accepter de rester en retard sur la courbe de productivité et d’agilité IA. Voici une feuille de route actionnable en trois étapes :

  1. Mois 1-3 — Auditer et cataloguer. Déployez Backstage en mode lecture seule sur votre cluster existant. Laissez-le découvrir et cataloguer vos services, vos APIs, vos workloads ML.
  2. Mois 3-6 — Définir votre premier golden path. Choisissez UN cas d’usage IA concret et construisez le template IDP complet autour de lui. Ce premier golden path vous donnera les patterns que vous répliquerez ensuite.
  3. Mois 6-12 — Étendre et automatiser. Intégrez les couches d’IA opérationnelle (k8sGPT, recommandations de ressources, alerting prédictif). Ouvrez progressivement l’IDP à d’autres équipes. Mesurez l’adoption via les métriques DORA.

Kubernetes n’est pas mort. Il a grandi. Et les entreprises qui comprennent que l’IDP est la prochaine couche d’abstraction nécessaire au-dessus de lui seront celles qui transformeront leurs ambitions IA en avantages compétitifs réels.

Sources :
Documentation officielle Kubernetes — Workloads |
Backstage.io — What is Backstage? |
CNCF Annual Survey 2024 |
Medium — Platform Engineering Publication |
DevOps.com — The Rise of Platform Engineering |
CNCF — Projet Backstage (Graduated)

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.