7 min de lecture
Deux signaux en provenance de l’univers cloud-native pointent dans la même direction : la CNCF a élevé Knative au statut Graduated, et Kubernetes 1.34 rend le scheduling du matériel d’IA et de ML prêt pour la production. Les deux semblent relever du travail de détail pour les équipes plateforme. Au total, cela signifie quelque chose de plus grand : le serverless et les workloads d’IA s’exécutent désormais sur une infrastructure mature et indépendante des fournisseurs. Pour les équipes DACH, cela déplace la question du « si » au « comment ».
Les points clés en bref
- Knative est gradué. Le serverless sur Kubernetes est désormais considéré comme mature et éprouvé en production.
- Kubernetes 1.34 intègre l’IA dans l’exploitation courante. Le scheduling matériel pour l’IA et le ML devient prêt pour la production, avec une sécurité renforcée de la supply chain.
- Indépendance des fournisseurs. Ces deux composants s’exécutent dans votre propre cluster, sans dépendre d’un service hyperscaler.
En lien :VMware VCF 9.1 et la question de la souveraineté / FinOps et le gaspillage cloud
Ce que signifie la graduation de Knative
Qu’est-ce que Knative ? Knative est une couche open source sur Kubernetes qui permet des applications serverless et pilotées par événements. Elle gère le scaling, le routage et le traitement des événements, de sorte que les développeurs n’ont pas à se soucier de l’infrastructure sous-jacente. Le code scale à la demande jusqu’à zéro et remonte automatiquement en cas de charge.
Le statut Graduated de la CNCF n’est pas une distinction marketing, mais un signal de maturité. Il signifie qu’un projet dispose d’une large base d’utilisateurs, d’une gouvernance stable et d’une capacité éprouvée en production. Pour une équipe plateforme qui évalue une technologie, c’est la différence entre une expérience et une base solide. Exploiter Knative en mode serverless n’est donc plus un pari.
L’intérêt pratique réside dans l’indépendance. Jusqu’à présent, le serverless était principalement proposé comme service hyperscaler, avec son revers bien connu : celui qui y construit ses fonctions s’engage auprès d’un fournisseur et de son modèle tarifaire. Knative apporte le même concept d’utilisation dans votre propre cluster Kubernetes. L’application scale à zéro lorsqu’il n’y a pas d’activité, et l’exploitation reste en interne. Un avantage particulièrement pertinent pour les secteurs régulés des pays DACH.
Pourquoi Kubernetes 1.34 compte pour les charges de travail d’IA
Longtemps, Kubernetes n’a été que partiellement adapté aux travaux d’IA gourmands en GPU. L’ordonnancement du matériel spécialisé était fastidieux, l’allocation grossière. La version 1.34 change la donne avec une allocation dynamique des ressources prête pour la production. Traduction : le cluster peut désormais distribuer finement et de manière fiable les GPU et autres accélérateurs aux charges de travail qui en ont besoin. C’est la condition préalable pour exécuter de manière économique l’entraînement et l’inférence de l’IA sur sa propre plateforme.
S’ajoute à cela la sécurité renforcée de la chaîne d’approvisionnement. À une époque où les attaques via des paquets et des images manipulés augmentent, ce n’est pas un détail. Un cluster qui impose des artefacts signés et vérifie la provenance de ses composants ferme précisément la porte d’entrée exploitée par de nombreux incidents récents. Ici, la maturité ne signifie pas seulement plus de fonctionnalités, mais moins de surface d’attaque.
Points à considérer
- L’exploitation en propre exige une compétence plateforme
- Plus de composants, plus de maintenance
- Maturité ne signifie pas automatiquement simplicité
Ce que cela apporte
- Serverless et IA sans dépendance aux hyperscalers
- Maîtrise des données au sein de son propre cluster
- Mise à l’échelle à zéro pour économiser les coûts d’inactivité
Ce que les équipes DACH en font
Le constat honnête : la maturité réduit les risques, elle n’élimine pas le travail. Une équipe qui souhaite exploiter Knative et l’ordonnancement d’IA dans son propre cluster a besoin de compétences plateforme. Celle qui ne les possède pas ou ne souhaite pas les développer sera probablement mieux servie par un service managé. La graduation rend l’exploitation en propre viable, elle ne la rend pas sans prérequis.
Pour qui cela vaut-il donc la peine ? Principalement pour les organisations présentant deux caractéristiques : un besoin sérieux de maîtrise des données et une équipe qui exploite déjà Kubernetes. Pour celles-ci, l’obstacle était jusqu’à présent que le serverless et l’ordonnancement d’IA sur leur propre plateforme semblaient immatures. Cet obstacle est levé. La décision ne porte plus sur la question de savoir si la technique tient la route, mais si l’équipe est prête à la porter.
Une technologie mature n’est pas une promesse de simplicité. C’est l’assurance que les fondations tiennent. Le reste, c’est à l’équipe de le faire.
Ce qui reste, c’est une image claire. Le cloud natif est arrivé à un point où les charges de travail sérieuses d’IA et de serverless n’ont plus nécessairement besoin de la cloud public. C’est une bonne nouvelle pour la région DACH, car cela réunit maîtrise des données et rentabilité. C’est aussi une invitation à réfléchir honnêtement à sa propre compétence plateforme. La technique est prête. La question est de savoir si l’organisation l’est aussi.
Foire aux questions
Que signifie le statut « Graduated » auprès de la CNCF ?
Il s’agit du niveau de maturité le plus élevé de la Cloud Native Computing Foundation. Il suppose une large base d’utilisateurs, une gouvernance stable et une aptitude éprouvée à la production. Pour les évaluations, cela marque le passage de l’expérimentation à une base solide et fiable.
Qu’apporte Knative par rapport au serverless des hyperscalers ?
Le même concept d’utilisation, mais au sein de votre propre cluster Kubernetes et sans dépendance à un fournisseur. Les applications peuvent descendre à une échelle zéro, tandis que l’exploitation reste en interne. Cela est particulièrement pertinent pour les secteurs soumis à des exigences de souveraineté des données.
Pourquoi Kubernetes 1.34 est-il important pour l’IA ?
L’allocation dynamique des ressources, désormais mature en production, permet de distribuer finement et de manière fiable les GPU et accélérateurs aux workloads. C’est la condition préalable pour exploiter économiquement l’entraînement et l’inférence de l’IA sur sa propre plateforme.
L’auto-hébergement est-il désormais plus simple ?
Plus viable, mais pas sans prérequis. La maturité réduit les risques, mais exige toujours une compétence en matière de plateforme. Les équipes dépourvues de cette expertise pourraient s’en sortir mieux avec un service managé.
Pour qui cette étape vaut-elle le coup ?
Pour les organisations ayant un besoin sérieux de souveraineté des données et une équipe qui gère déjà Kubernetes. Pour elles, l’obstacle précédent lié à l’immaturité est levé, et la décision devient une question de capacité interne.
Plus d’articles du réseau MBF Media
Une vision ne suffit plus : les conseils d’administration exigent des arguments défendables
Source de l’image : générée par IA (juin 2026), certificat C2PA intégré à l’image