Re: Titre

1) les images dont je connais la provenance vs celle dont je ne la connais pas.

Très bon point. Pas toujours le plus simple :-)

Est-ce que le fait d'avoir les informations (les badges visibles) "Verified Publisher" ou ici "Sponsored OSS" peuvent aider à faire ce tri ?

Afficher la source (le label org.opencontainers.image.source) serait un pas en avant.

Alors clairement oui. Je ne sais plus où ca en est, je sais que ca a déjà été évoqué. Un des problèmes ici est que beaucoup d'images n'utilisent pas ces labels, mais on travaille à améliorer ceci.

2) les images qui sont mises à jour assez régulièrement vs celles qui ne le sont pas.

C'est clairement un des points qu'on va mettre en avant.

3) je suis sans doute un puriste, mais les images qui lancent plusieurs process, c'est AMHA niet. Avoir supervisord ou autre dans l'image, ça me parait pas propre.

Dans l'idée je suis totalement d'accord. Dans les faits, c'est toujours un peu plus compliqué à détecter simplement. Je me demande si avec le SBOM on ne pourrait pas le savoir.
Je me le garde sous le coude, je vais voir pour le rajouter à notre liste.

4) la qualité des tags

Si je suis d'accord sur l'idée, sujet très épineux. Certains voudraient du semver partout, d'autres s'en fichent et veulent juste du latest. Pour le moment j'ai pas d'idée immédiate sur comment améliorer ce point, mais j'aimerais bien trouver quelque chose.

5) avoir un README. C'est con, mais c'est important.

Oui. J'irais même plus loin, je pense qu'on peut définir un certain nombre de choses qu'on voudrait dans un readme. Genre une description du schéma de tags, ou un exemple sur comment lancer l'image, quels sont les paramètres, variables d'environnement nécessaires, etc.

6) avoir une image vérifié du projet. [...] Ensuite, vu que Docker fournit des images officiels [...] qui sont pas les images de projets upstream, mais celle de Docker, je peux comprendre que ça ferait tache ou que ça rendrait le tout vachement flou.

Ho non, ca ne ferait pas tache. Un des axes de travail de mon équipe est justement de remettre dans les mains des éditeurs leurs images.
Il faut voir qu'il y a quelques années encore, faire des images c'était pas la principale qualité de nombreux éditeurs. D'où aussi les images officielles.
Aujourd'hui c'est de moins en moins valable, et inciter les éditeurs à avoir leurs propres images est probablement une bonne chose pour tout le monde.
Le fait de passer d'une image officielle (disons nginx) à une image plus classique (qui pourrait être nginx/nginx) n'est pas un problème en soit.
Néanmoins (et c'est l'objet de tout ceci) cela doit s'accompagner d'une qualité suffisante.

7) avoir l'image compilé par une CI, dont je peux voir les logs (ou au moins avoir une trace)

Je vois, mais j'imagine que ce n'est pas forcément évident vu la variété des solutions pour construire une image.
Mais c'est une bonne idée, au moins de manière optionnelle. Je me demande si on ne pourrait pas juste le faire avec un label dans l'image contenant un lien vers le build.

8) capable de se lancer sans être root avec le / en readonly

Quel serait le but du readonly sachant que le conteneur est déjà immuable ?

9) plus controversé, ne pas me filer un shell tout pourri

Je suis plutôt adepte du pas de shell dans le conteneur sur ce point :-)

J'imagine que je peux trouver d'autres points pour juger la qualité [...] mais c'est déjà long.

Nan c'est très bien.
Merci pour ces détails et ces idées.
Je vais partager au moins certaines d'entre elles en interne et voir ce qu'on peut améliorer sur ces points.