Kubeflow diplômé par la CNCF : plateforme de référence ou usine à gaz ? Grille de décision pour votre plateforme IA sur Kubernetes

La CNCF a annoncé le 17 août 2026 la graduation de Kubeflow, son plus haut niveau de maturité. Le communiqué le positionne comme le socle Kubernetes-natif unifié pour construire et exploiter des applications d’IA à l’échelle, et met en avant des chiffres flatteurs : plus de 6 600 contributeurs issus de plus de 1 000 organisations, plus de 33 000 étoiles GitHub cumulées, des références comme NVIDIA, Red Hat, Spotify ou Bloomberg.

La question que se posent les équipes plateforme n’a pourtant pas changé d’un iota depuis l’incubation en 2023 : faut-il adopter Kubeflow, ou assembler soi-même une stack plus étroite ? Un badge de maturité ne répond pas à cette question. Voici de quoi y répondre chez vous.

Ce que « graduated » veut dire — et ne veut pas dire

Le processus de graduation CNCF valide un ensemble de critères précis, essentiellement organisationnels et sécuritaires : gouvernance neutre et documentée, indépendance vis-à-vis d’un unique employeur, adoption démontrée en production par des utilisateurs référencés, respect du Code of Conduct, audit de sécurité par un tiers, et alignement sur les bonnes pratiques de supply chain (SBOM, signature des artefacts, politique de divulgation des vulnérabilités).

Ce sont de vrais garde-fous. Ils vous protègent contre le scénario « le projet est abandonné parce que son sponsor change de stratégie », et ils vous donnent des arguments recevables en comité d’architecture ou en audit.

Ce qu’ils ne garantissent pas, et il faut être clair là-dessus :

• la simplicité d’exploitation — la maturité de gouvernance et l’ergonomie opérationnelle sont deux axes orthogonaux ;
• le coût d’infrastructure — aucun critère CNCF ne porte sur l’empreinte du control plane ;
• la pérennité de chaque sous-composant — Kubeflow est un parapluie ; des composants peuvent en sortir (KServe l’a fait) ou être dépréciés sans que le projet parent bouge ;
• l’existence d’un support commercial pour votre installation. Une distribution communautaire reste une distribution communautaire.

Sur les chiffres, une précaution de lecture : les 33 000 étoiles sont un cumul sur plusieurs dizaines de dépôts (pipelines, trainer, katib, model-registry, manifests, SDK…). Ce n’est pas un indicateur de concentration de l’effort, et encore moins de la santé de chaque composant pris isolément. Le signal utile est ailleurs : le rythme de release par sous-projet, le nombre de mainteneurs actifs distincts par dépôt, et la fraîcheur du dernier commit sur les composants que vous comptez utiliser.

Anatomie de Kubeflow en 2026 : ce n’est plus le Kubeflow de 2021

Beaucoup d’équipes portent encore un jugement basé sur une évaluation faite en 2020 ou 2021. Le projet a changé de forme.

Le repositionnement en « Kubeflow AI Reference Platform » avec la 1.11 (décembre 2025) marque un tournant : un SDK unifié installable par pip, une réduction de l’empreinte injectée dans chaque namespace utilisateur, et le remplacement de MinIO par SeaweedFS pour le stockage d’artefacts — une conséquence directe du changement de licence côté MinIO, que beaucoup de projets CNCF ont dû absorber.

La cartographie actuelle, à connaître avant toute décision :

Et les dépendances lourdes, qui constituent l’essentiel de la friction : Istio (service mesh, utilisé pour le routage et l’AuthorizationPolicy par namespace), Dex et OAuth2-Proxy pour l’authentification. C’est là que se joue la réputation d’« usine à gaz » : vous n’installez pas un outil MLOps, vous installez un mesh et une brique IAM.

Le fait le plus structurant de la période reste le départ de KServe, devenu projet CNCF en incubation à part entière. Conséquence concrète sur votre architecture : le training et le serving sont désormais deux décisions séparées, avec deux cycles de release, deux matrices de compatibilité, et — bonne nouvelle — la possibilité parfaitement légitime de n’en prendre qu’un.

La distribution communautaire 26.03 a par ailleurs consolidé l’OIDC natif (moins de dépendance à un chemin d’authentification maison), généralisé les NetworkPolicies par défaut et étendu les control flows dans KFP (boucles et conditions plus expressives dans les DAG).

Le coût réel d’exploitation : mesurer avant de s’engager

Ne prenez pas au sérieux une estimation d’empreinte trouvée dans un billet de blog, y compris celui-ci. Mesurez la vôtre, sur votre distribution, avec vos réglages de résilience. La méthode tient en trois commandes :

# Empreinte demandée par le control plane Kubeflow
kubectl get pods -n kubeflow -o custom-columns=\
'NAME:.metadata.name,CPU:.spec.containers[*].resources.requests.cpu,MEM:.spec.containers[*].resources.requests.memory'

# Idem pour les dépendances transverses
kubectl get pods -n istio-system -n auth -o wide

# Consommation réelle vs. demandée après 48h de charge représentative
kubectl top pods -n kubeflow --sort-by=memory

Le poste à ne pas oublier est le coût par namespace utilisateur. Chaque Profile créé instancie un jeu d’objets (ServiceAccounts, AuthorizationPolicies, NetworkPolicies, éventuels sidecars) qui s’additionnent. Sur une plateforme mutualisée à cinquante utilisateurs, ce coût marginal devient le coût dominant.

apiVersion: kubeflow.org/v1
kind: Profile
metadata:
  name: team-fraud-detection
spec:
  owner:
    kind: User
    name: alice@example.com
  resourceQuotaSpec:
    hard:
      requests.nvidia.com/gpu: "8"
      requests.cpu: "64"
      requests.memory: 256Gi
      persistentvolumeclaims: "20"

Sur la multi-tenancy, soyons factuels. Ce qui fonctionne : l’isolation logique par Profile, les NetworkPolicies générées, le cloisonnement des artefacts de pipelines. Ce qui reste entièrement à votre charge : la politique de quotas GPU réellement équitable (un ResourceQuota ne fait pas de fair-share entre équipes), le contrôle d’egress vers Internet depuis les notebooks — vecteur d’exfiltration classique —, la gestion des secrets d’accès aux datasets, et l’audit des accès aux données.

Le vrai poste de dépense, sur trois ans, c’est la montée de version. Construisez et maintenez une matrice explicite : version Kubeflow × version de chaque composant × version Kubernetes × version Istio × version du driver GPU. C’est cette matrice, et non l’installation initiale, qui détermine si votre équipe de deux SRE peut tenir la plateforme. Une distribution communautaire n’a pas de SLA, pas de backport de correctif, pas d’engagement de compatibilité ascendante sur les CRD : si ce n’est pas acceptable, la question n’est pas « Kubeflow ou pas » mais « quelle distribution supportée ».

GPU : articuler Kubeflow avec DRA passé GA en 1.34

Le modèle historique d’allocation GPU sur Kubernetes est un simple compteur d’entiers :

resources:
  limits:
    nvidia.com/gpu: 1

Ce modèle atteint ses limites dès que vous sortez du cas « un job, un GPU entier » : partage de device entre plusieurs pods, découpage MIG, contraintes de topologie (GPU sur le même switch NVLink, affinité avec une NIC RDMA), sélection par attributs (mémoire disponible, génération d’architecture). Rien de tout cela n’est exprimable avec un compteur opaque.

DRA (Dynamic Resource Allocation), passé GA en Kubernetes 1.34, change le modèle : les devices deviennent des ressources décrites par attributs, réclamées par des objets dédiés que le scheduler prend en compte.

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: gpu-80gb
spec:
  spec:
    devices:
      requests:
      - name: gpu
        exactly:
          deviceClassName: gpu.nvidia.com
          selectors:
          - cel:
              expression: device.capacity["memory"].compare("70Gi") >= 0
---
apiVersion: v1
kind: Pod
spec:
  resourceClaims:
  - name: training-gpu
    resourceClaimTemplateName: gpu-80gb
  containers:
  - name: trainer
    resources:
      claims:
      - name: training-gpu

Pour Kubeflow, l’enjeu est que les CRD de haut niveau (TrainJob côté Trainer, les composants KFP) propagent proprement ces claims jusqu’aux pods, y compris pour les workers d’un job distribué qui doivent partager une même contrainte de topologie. Le support progresse mais reste à valider version par version : ne présumez pas qu’il fonctionne, testez-le avec un job multi-nœuds réel avant d’engager votre design.

Piège concret à éviter : ne mélangez pas DRA et device plugin sur le même pool de nœuds. Les deux mécanismes ont des vues incompatibles de la disponibilité des devices, ce qui produit des doubles allocations ou des pods Pending inexplicables. Segmentez par node pool, avec taints et labels explicites, et migrez pool par pool.

Grille de décision : Kubeflow, ou stack composable ?

Équipe de trois data scientists, un cluster partagé. N’installez pas Kubeflow. Argo Workflows pour l’orchestration, un object store, et KServe si vous devez servir des modèles. Vous économisez le mesh, Dex, et la matrice de compatibilité. Le jour où vous atteignez quinze utilisateurs, vous réévaluerez — la migration d’Argo Workflows vers KFP n’est pas triviale, mais elle est moins coûteuse que six mois d’exploitation d’une plateforme surdimensionnée.

Plateforme mutualisée, 50+ utilisateurs, plusieurs équipes métier. C’est le terrain naturel de Kubeflow. La valeur n’est pas dans les composants pris un par un — chacun a un équivalent crédible — mais dans la cohérence d’ensemble : un modèle de tenancy unique, un SDK, un Model Registry commun, une intégration Katib/Trainer/Pipelines qui vous évite d’écrire et de maintenir la glue. Le coût de cette glue maison est systématiquement sous-estimé.

Contexte régulé, besoin de traçabilité et de lineage. Le Model Registry et le lineage des runs KFP sont des arguments sérieux, à condition de vérifier que la granularité produite (dataset → run → artefact → version de modèle → déploiement) correspond à ce que votre auditeur attend. Faites l’exercice sur un cas réel avant de trancher.

Face aux alternatives, honnêtement :

• Flyte : typage fort des tâches, expérience développeur supérieure sur les workflows complexes ; couvre mal le serving et le tuning.
• Ray : excellent si votre problème est le calcul distribué (RL, tuning massif, inférence batch) ; ce n’est pas une plateforme multi-tenant.
• Argo Workflows + KServe : le duo le plus simple à exploiter ; vous écrirez vous-même le registre de modèles et l’onboarding des équipes.

Et le cas très fréquent du « je n’ai besoin que de serving » : depuis que KServe est un projet CNCF indépendant, l’installer seul est une option pleinement légitime, sans dette conceptuelle envers Kubeflow.

Dernier critère, souvent négligé : la distribution Kubernetes sous-jacente. Le programme Certified Kubernetes AI Conformance a presque doublé son nombre de plateformes certifiées en mars 2026, avec des exigences durcies sur la v1.35. Exiger cette certification de votre fournisseur est un filtre bon marché : il garantit que les briques dont Kubeflow dépend (DRA, gestion des devices, scheduling avancé) sont présentes et testées.

Plan de démarrage en deux semaines pour une évaluation sérieuse

Semaine 1 — installer et instrumenter. Un cluster de test dédié, avec au moins deux nœuds GPU pour valider le distribué. Installation de la distribution communautaire 26.03, puis relevé de l’empreinte de base. Créez immédiatement trois Profile avec trois quotas différents : c’est le test de tenancy, pas le « hello world » de pipeline.

Semaine 2 — charger avec du réel. Rejouez deux ou trois workloads de production existants (un entraînement multi-nœuds, un tuning Katib, un pipeline de features). Instrumentez trois métriques, et seulement celles-là :

1. temps de mise en production d’un modèle (commit → endpoint servi), mesuré de bout en bout ;
2. coût GPU par run, GPU-heures × prix, incluant le temps d’attente en Pending ;
3. temps d’onboarding d’une équipe, du ticket d’accès au premier run réussi.

Comparez ces trois chiffres à votre situation actuelle. S’ils ne s’améliorent pas nettement, le badge CNCF ne compensera rien.

Critères de sortie. Renoncez avant d’avoir investi six mois si : vous n’arrivez pas à faire fonctionner votre SSO d’entreprise via OIDC en moins de trois jours ; une montée de version mineure casse vos pipelines existants ; le partage GPU entre équipes exige du code maison dès la phase d’évaluation ; ou aucune personne de l’équipe ne sait diagnostiquer une AuthorizationPolicy Istio. Ce dernier point est le meilleur prédicteur d’échec que l’on observe sur le terrain.

Checklist avant KubeCon NA 2026 (Salt Lake City, 9–12 novembre, avec son nouveau track AI Inference + Agentic) : arrivez avec votre matrice de compatibilité, vos trois métriques mesurées, et deux questions précises pour les mainteneurs — l’état réel du support DRA dans Trainer, et la roadmap d’intégration avec KServe désormais que les deux projets sont séparés. C’est plus rentable que trois jours de keynotes.

La graduation de Kubeflow est une bonne nouvelle pour l’écosystème : elle stabilise une gouvernance, valide un audit de sécurité et rend le projet défendable en comité. Elle ne déplace pas d’un centimètre la frontière technique qui compte, à savoir le seuil d’utilisateurs et de diversité de workloads au-delà duquel la glue maison coûte plus cher que l’exploitation d’une plateforme intégrée. Ce seuil est propre à chaque organisation, il se mesure en deux semaines, et le fait de l’avoir mesuré vaut mieux que n’importe quel badge — dans un sens comme dans l’autre.