Docker rend son programme Verified Publisher libre-service
Le 20 août 2026, Docker ouvre les candidatures au programme Verified Publisher en libre-service depuis Docker Hub, tout en conservant une revue manuelle de chaque dossier. Pour les équipes qui consomment des images, le badge reste un maillon de confiance, pas une garantie CVE.
20 août 2026. Docker officialise le libre-service de son programme Verified Publisher (DVP). Avant cette date, un éditeur qui voulait le badge de confiance devait passer par l’équipe commerciale. Désormais, la candidature se dépose directement depuis Docker Hub, sans friction, avec deux formules au choix — et l’équipe Docker continue d’évaluer chaque dossier à la main.
Derrière cette annonce, il y a un vrai basculement de doctrine. Le badge n’est plus un privilège qu’on négocie, mais un canal de distribution qu’on ouvre. Pour un RSSI ou un SRE qui sélectionne des images à la vitesse d’un agent, la question n’est pas « le badge vaut-il encore quelque chose ? » mais « à quelle condition continue-t-il d’être un signal fiable ? ».
Le badge change de canal, pas de nature
Le discours de Docker est limpide : « quand un logiciel est choisi à la vitesse de la machine, la question n’est plus “est-ce populaire ?” mais “sait-on qui l’a publié ?” ». Le DVP répond précisément à cette question en reliant un contenu à un éditeur dont l’identité a été vérifiée manuellement.
Ce qui change le 20 août 2026, c’est uniquement le canal d’entrée. Avant, l’accès au programme passait par le service commercial — un filtre humain en amont, lent, réservé de fait aux éditeurs assez gros pour avoir un contact chez Docker. Désormais, n’importe quel éditeur peut déposer une candidature en libre-service, choisir entre deux formules, et attendre l’examen.
Le point décisif : Docker affirme explicitement que la revue reste manuelle. Le libre-service accélère le dépôt, il ne remplace pas l’évaluation. C’est ce qui distingue le DVP d’un simple badge auto-déclaré, et c’est aussi la ligne de crête de l’annonce — un flux de candidatures plus large doit être absorbé par une équipe humaine dont la capacité n’est pas infinie.
Ce que le libre-service change pour les éditeurs
Pour un éditeur, la nouvelle est sans ambiguïté : le DVP devient une démarche à faible coût d’entrée, avec des contreparties commerciales chiffrables.
Le badge s’accompagne d’un rangement prioritaire dans les résultats de recherche de Docker Hub : à contenu égal, le contenu vérifié s’affiche d’abord. S’y ajoutent des rapports d’analytics — quelles versions gagnent en traction, vers quelles entreprises les pulls se dirigent. Sur la formule supérieure, les rapports d’entreprise suivis transforment le trafic de pulls anonyme en entreprises nommées : les équipes qui exécutent déjà votre logiciel apparaissent dans votre pipeline commercial.
La portée du badge s’élargit aussi. Docker Hub n’est plus seulement un registre d’images : on y distribue des serveurs MCP, des modèles, des sandboxes, des agents. Le DVP devient « une seule revue, un seul badge, une seule réponse à “qui a publié ça ?” », quel que soit le type de contenu. Google, Microsoft, AWS, Datadog, Grafana Labs et n8n figurent déjà parmi les éditeurs vérifiés.
Le message commercial est donc cohérent : le libre-service transforme le badge d’une relation de confiance en un entonnoir d’adoption. Pour un éditeur, ne pas candidater devient une anomalie concurrentielle.
Ce que ça ne change pas pour vous, consommateur
C’est là que l’annonce mérite d’être lue froidement. Docker lui-même encadre son propre badge, et cet encadrement est la partie la plus utile du billet pour qui consomme des images.
Le badge atteste une seule chose : Docker a revu l’éditeur et confirmé qu’il est bien qui il prétend être. Il ne dit rien de la qualité du code, de l’état des CVE, de la fraîcheur des dépendances, ni de la provenance d’un artefact précis. Docker le formule noir sur blanc : tirer ses images depuis un éditeur vérifié « est un bon pas », mais doit être complété par la revue de l’artefact précis, le pin à un digest plutôt qu’à un tag mutable, la vérification de la provenance et des signatures au niveau de l’image, et le contrôle des CVE.
La conséquence pratique est directe. Un agent qui choisit des images « à la vitesse de la machine » n’a pas le droit de réduire sa politique de confiance à « est-ce un DVP ? ». Le badge est un filtre d’identité, pas un filtre de sécurité. Le confondre avec ce second rôle, c’est reproduire l’erreur que le programme prétend combattre — faire confiance à un signal trop faible au moment où la sélection s’automatise.
Le risque du libre-service, s’il en existe un, est donc moins la dilution du badge que la tentation de le surinterpréter à mesure qu’il se généralise. Plus le badge est courant, plus il devient un prérequis de visibilité, et plus un consommateur pressé peut être tenté de s’arrêter là.
Verdict
Si vous êtes éditeur, candidater au DVP est désormais une évidence : le coût d’entrée s’effondre, la revue reste manuelle, et le badge apporte un rangement prioritaire plus des rapports d’adoption. Ne pas y être, c’est laisser la visibilité à vos concurrents.
Si vous consommez des images, traitez le badge pour ce qu’il est — un contrôle d’identité de l’éditeur, pas une garantie sur l’artefact. Maintenez le pin par digest, vérifiez provenance et signatures, et scannez les CVE. Le libre-service ne change pas cette règle ; il la rend plus nécessaire, parce que le badge va devenir plus fréquent, donc plus facile à confondre avec un feu vert.
Si vous outillez des agents, encodez explicitement que « DVP vérifié » est une condition nécessaire et non suffisante. La sélection à la vitesse de la machine exige des garde-fous au niveau de l’artefact, pas seulement au niveau de l’identité du fournisseur.