Cloud Native Buildpacks accède à la graduation CNCF et centralise le build d’images sans Dockerfile

11 août 2026. Annonce de graduation. 535 contributeurs. La Cloud Native Computing Foundation (CNCF) élève Cloud Native Buildpacks (CNB) au rang de projet gradué, le plus haut niveau de maturité de la fondation — celui qu’occupent Kubernetes, Prometheus ou Envoy. Derrière la formule, un chiffre qui dit tout : le projet agrège désormais 535 contributeurs issus de 164 organisations et plus de 20 adoptants déclarés, dont Google, GitLab, DigitalOcean, HashiCorp, Spring et VMware. Pour une équipe plateforme, c’est la validation qu’un build d’image sans Dockerfile, centralisé et reproductible, est désormais une option de série — pas un pari d’early adopter.

Pourquoi cette graduation n’est pas cosmétique

La graduation n’est pas un label marketing. C’est l’aboutissement d’un parcours à trois paliers — sandbox, incubating, graduated — que la CNCF n’accorde qu’à un projet dont la gouvernance est neutre vis-à-vis du vendeur, les pratiques de sécurité auditées et l’adoption en production démontrée. Cloud Native Buildpacks rejoint ainsi une liste fermée : depuis le début de l’année 2026, seuls deux autres projets ont franchi ce seuil, dont Kubeflow le 17 août.

Le projet n’est pas né d’hier. Le modèle de buildpack a été conçu par Heroku en 2011, repris par Cloud Foundry, Google App Engine, GitLab ou Knative. CNB a été lancé par Pivotal et Heroku en janvier 2018, puis donné à la CNCF en octobre 2018. Huit ans plus tard, la graduation entérine ce que les chiffres montrent : Bloomberg et Heroku (Salesforce) ne sont pas que des utilisateurs — ils poussent du code, des revues et des pull requests dans le projet.

Ce que Buildpacks change concrètement

Le principe tient en une phrase : CNB transforme le code source d’une application en image OCI exécutable sur n’importe quel cloud, sans Dockerfile. L’outillage détecte automatiquement le langage — Java, Python, Go, Node.js, Ruby —, installe les dépendances et découpe l’image en couches selon une spécification commune.

L’enjeu réel n’est pas technique, il est organisationnel. Avec un Dockerfile par application, chaque équipe réinvente le build, et la connaissance de ce qui entre dans l’image se disperse. Avec CNB, cette connaissance se concentre dans une équipe plateforme qui maintient les buildpacks, les builders et les stacks pour toute l’organisation. Le développeur écrit du code ; l’image sort d’une chaîne que la plateforme contrôle, met à jour et audite.

Deux mécanismes font la différence au quotidien. La détection automatique supprime les fichiers de configuration manuels. Le rebasing — la capacité de remplacer la couche de base d’une image sans reconstruire la couche applicative — transforme la correction d’une CVE dans l’image de base en une opération quasi instantanée. C’est là que l’argument supply chain devient concret.

La preuve par le chiffre : des semaines aux heures

La CNCF cite un cas d’usage qui a valeur de benchmark : dans des implémentations financières d’entreprise couvrant plus de 500 applications, les équipes ont fait passer le temps de résolution d’une vulnérabilité de plusieurs semaines à quelques heures, uniquement en appliquant les correctifs de manière centralisée au niveau du buildpack.

Le mécanisme est limpide. Un Dockerfile fige une image de base à un instant T : pour patcher une CVE dans debian:bookworm-slim, il faut re-déclencher chaque build. Avec le rebasing, on remplace la couche de base sur le registre et les applications récupèrent le correctif sans recompilation — un geste de plateforme, pas un chantier par équipe.

La trajectoire annoncée renforce cette logique : la feuille de route du projet cible l’extension aux OCI Artifacts, le renforcement des flux SBOM et la compatibilité avec des formats de charge de travail de nouvelle génération, dont WebAssembly. Autant de chantiers qui vont dans le sens d’images dont on sait prouver le contenu, pas seulement le deviner.

Buildpacks face au Dockerfile et à BuildKit

Il serait faux de présenter CNB comme le remplaçant universel du Dockerfile. Les trois outils n’occupent pas le même étage. Le Dockerfile reste le mode d’expression le plus fin — chaque instruction est explicite — mais il distribue la responsabilité du build et dérive d’une équipe à l’autre. BuildKit est le moteur de build sous-jacent : il n’écrit pas le build, il l’exécute, et CNB peut d’ailleurs s’appuyer dessus. CNB, lui, standardise ce qui doit être construit et qui en garde le contrôle.

Le verdict comparatif est simple : le Dockerfile gagne sur la granularité, CNB gagne sur la reproductibilité, la conformité et le coût de maintenance dès que le parc dépasse quelques dizaines d’applications. BuildKit n’est pas un concurrent, c’est un composant que les deux peuvent réutiliser.

Adopter sans tout réécrire

Le point d’entrée officiel est le CLI pack. Un build tient en une commande — le builder embarqué fait le reste :

# Construire une image OCI à partir du code source, sans Dockerfile
pack build myapp --builder paketobuildpacks/builder-jammy-base

Les builders prêts à l’emploi existent pour la plupart des familles de langage : Paketo Buildpacks (la distribution de référence, portée par VMware), Google Buildpacks et les buildpacks Heroku. L’adoption n’exige pas de basculer d’un coup : on prend une application, on construit son image avec CNB en parallèle du Dockerfile existant, on compare les couches et le SBOM, puis on généralise. La migration se fait application par application, sans arrêter la chaîne en place.

Rebaser et générer un SBOM en pratique

La valeur de CNB se mesure en deux commandes. La première produit le SBOM — la nomenclature logicielle — de l’image construite, au format CycloneDX, SPDX ou Syft :

# Générer le SBOM de l'image construite au format CycloneDX
pack sbom download myapp --format cyclonedx-json

La seconde est le rebasing, qui remplace la couche de base d’une image sans recompiler la couche applicative :

# Mettre à jour l'image de base et rebaser l'application sans rebuild
pack rebase myapp --run-image paketobuildpacks/run-jammy-base:latest

Le scénario qui en découle est le cœur de l’argument supply chain : une CVE tombe dans l’image de base, la plateforme reconstruit le run image, puis rebase l’ensemble du parc en quelques minutes — sans toucher au code applicatif, sans re-déclencher les CI, sans réveiller les équipes. À l’échelle de 500 applications, c’est la différence entre une maintenance subie et une maintenance pilotée.

La graduation change aussi la lecture du risque. Tant que CNB était un projet incubating, un responsable sécurité pouvait légitimement hésiter à en faire un composant central de sa chaîne de build. Le statut gradué — gouvernance neutre, pratiques de sécurité auditées — lève cet argument, exactement comme il l’avait fait pour Kubernetes ou Envoy.

Verdict

Si votre organisation gère plusieurs dizaines d’applications, un parc en croissance ou un cadre de conformité exigeant, adoptez Cloud Native Buildpacks maintenant : le rebasing seul — corriger une CVE de base en heures plutôt qu’en semaines — rentabilise la mise en place, et la graduation CNCF lève le dernier risque de pérennité du projet. Commencez par un builder Paketo et une application pilote.

Si vous gérez deux ou trois services avec un mainteneur Docker senior et zéro contrainte réglementaire, gardez vos Dockerfiles : la granularité et l’absence d’indirection valent le contrôle direct. Dans ce cas, CNB reste un outil à connaître — pas à déployer — et BuildKit suffit à accélérer vos builds existants.

Références

• CNCF Announces Graduation of Cloud Native Buildpacks, Advancing the Standard for Container Builds — CNCF, 11 août 2026
• Cloud Native Buildpacks — buildpacks.io, consulté le 27 août 2026
• Buildpacks contributor insights — Linux Foundation, consulté le 27 août 2026