CrEv a écrit 4577 commentaires

  • [^] # Re: Jamais pratiqué

    Posté par  (site web personnel) . En réponse au journal Des emojis dans votre historique Git (ou tout autre CVS) ?. Évalué à 2.

    Sous mac tu as un raccourcis clavier par défaut et tu as directement la fenêtre de clavier des emoji qui apparait https://support.apple.com/fr-fr/guide/mac-help/mchlp1560/mac

    Ah sous Mac les emoji ne sont pas correctement affichés ?

    C'est essentiellement une question d'outils.
    Et il m'arrive de voir des logs dans un terminal sur une autre machine et là les :rotating_light: ou :ambulance: ca me fatigue.

  • [^] # Re: Jamais pratiqué

    Posté par  (site web personnel) . En réponse au journal Des emojis dans votre historique Git (ou tout autre CVS) ?. Évalué à 3.

    C'est puérile de se prendre ce genre de remarque derrière.

    Rien de puérile ici je demande juste comment ca se passe sous linux aujourd'hui. Sous mac j'ai directement accès à une méthode de saisie des emoji et autres caractères spéciaux très facilement. La dernière fois que j'ai utilisé des workstation linux c'était très loin d'être le cas. Et j'ai l'impression que c'est toujours le cas…

    j'en suis revenu

    Pourquoi donc ?

    Parce que c'est marrant si l'emoji est toujours affichée, lorsqu'elle ne l'est pas pour une raison où un autre (genre un outil qui ne l'interpète pas) alors c'est beaucoup moins intéressant.
    Et dans ce cas je préfère les conventional commits de base.
    Aussi il est plus facile de convaincre tout une équipe d'utiliser du conventional commit texte qu'emoji. Et tout l'intérêt de ce genre de pratique c'est quand tout le monde le fait.
    Enfin j'ai aussi des outils qui utilisent conventional commits pour automatiquement générer les bons bunp de version quand on release, ils ne fonctionnent pas avec les emojis.

  • [^] # Re: Jamais pratiqué

    Posté par  (site web personnel) . En réponse au journal Des emojis dans votre historique Git (ou tout autre CVS) ?. Évalué à 5.

    tu a un outil pour avoir le smiley ou c'est par copier/coller avec le site ?

    Pardon pour la question idiote mais on ne peut pas facilement saisir d'emoji sous linux ?
    Oui ca fait un moment que mes machines de taff sont sous mac donc c'est super simple (d'autant plus que c'est mappé sur une double frappe de ma touche échappe qui est en gros à la place du caps lock, donc accessible)

    Sinon sur le sujet en lui même je l'ai utilisé sur plusieurs projets sur les 6-7 dernières années en gros. C'est bien mais j'en suis revenu, et maintenant je reste avec du conventional commit plus classique et ca marche bien.

  • [^] # Re: Qu'en penser ?

    Posté par  (site web personnel) . En réponse au journal Docker aime finalement le libre. Évalué à 10.

    40 postes non techniques pour 34 postes techniques. La proportion est-elle la même à l'intérieur de Docker ?

    Je ne sais pas exactement. J'imagine que ca doit pas être très loin, mais je n'ai pas les chiffres donc c'est un avis au doigt mouillé.

    Plus la boite grandit, plus on a besoin de rôles autres que engineering & products. On passe d'un système très plat à un système qui l'est moins. On a besoin de plus de management, de plus d'autres fonctions (genre marketing, product marketing, devrel, etc). Et ca c'est sans parler de l'administratif et de toutes les autres fonctions utiles.

    pour mettre un ingénieur au travail il faut une personne en fonction support ?

    Tout dépend ce que tu entend par "ingénieur" car "engineering & products" ne veut pas dire ingénieur.
    Mais grosso modo on tente d'avoir dans chaque équipe de dev 1 engineering manager, 1 product manager, 1 UI designer (et si possible un UX designer, mais généralement partagé entre plusieurs équipes). Donc on va dire grosso modo 3 personnes pour 3-5 devs, data engineer, etc.
    Et ensuite il y a en effet toutes les autres fonctions, administratives, sales, marketing, etc.

    D'ailleurs si certains sont intéressé j'en profite, mon équipe (et les équipes annexes) embauchent. Ce sont les offres "Software Supply Chain" dispo sur le site (plus ou moins expérimenté, clojure ou non). Je met pas de lien ni rien, c'est facile à trouver, et s'il y a des questions faut pas hésiter ;-)

  • [^] # Re: Qu'en penser ?

    Posté par  (site web personnel) . En réponse au journal Docker aime finalement le libre. Évalué à 9.

    Je me demandais justement si Docker est une grosse boîte ou pas
    il y a plus de 70 postes ouverts au recrutement !
    C'est pas si petit, Docker-l'entreprise, non ?

    Et si :-) Docker est beaucoup, beaucoup plus petit qu'on ne pense.
    Je ne sais plus quels sont les chiffres officiellement communiqués, mais il n'y a pas si longtemps on était encore moins de 300.
    Alors oui par contre il y a pas mal de postes ouverts, mais ça c'est parce que la boite fonctionne bien et donc on embauche car il y a beaucoup, beaucoup de choses à faire.

    dans l'objectif d'éviter des licenciements (comme on en voit pas mal ces temps-ci dans l'informatique)

    Non, on n'est pas touché par ça. Beaucoup d'entreprises qui licencient maintenant ont en fait embauché à tout vas (et probablement trop, trop vite) pendant la période covid.
    Docker de son côté revenait tout juste de passer par la case séparation. Une source externe parmi d'autres : https://www.infoworld.com/article/3632142/how-docker-broke-in-half.html
    On s'est donc retrouvé à moins de 100 personnes pour l'ensemble de Docker dans le monde à cette époque.
    Et entre autre, quand on a senti le vent tourner on a ralenti les embauches (au moment où tout le monde y allait à fond). Résultat (même si ce n'est pas la seule raison) il n'y a pas de licenciements ici.

  • [^] # Re: Qu'en penser ?

    Posté par  (site web personnel) . En réponse au journal Docker aime finalement le libre. Évalué à 10. Dernière modification le 25 mars 2023 à 00:37.

    éviter la mauvaise pub

    Il est évident que personne ne souhaite ça. Dire que ça n'a pas d'impact serait idiot.

    ils ont écouté la communauté

    Oui la boite écoute la communauté. Et agit en conséquence lorsqu'on fait des erreurs.
    Ce n'est pas la première fois. L'une des dernières dans mes souvenirs était quand on avait voulu changer la gestion des mises à jour de Docker Desktop où on avait fait marche arrière dans un premier temps, puis trouvé une meilleure façon de le faire qui me semble convenir à tout le monde désormais.

    un mix des deux

    Assurément, c'est toujours un mix de plein d'aspects différent, un compromis.

    Fournir les bonnes fonctionnalités est toujours quelque chose de compliqué. C'est rarement une ligne droite.
    Mais ce qui compte (pour moi) c'est de savoir reconnaître ses erreurs, de tenter de les corriger, d'apprendre et d'ensuite faire mieux. En tout c'est ce qu'on tente de faire, parfois avec plus ou moins de succès (d'autant plus pour une boite comme Docker, qui a beau être petite mais dont chaque décision, chaque changement a souvent un impact assez vaste), mais l'important est aussi dans la démarche.

  • # Annonce

    Posté par  (site web personnel) . En réponse au journal Docker aime finalement le libre. Évalué à 5.

  • [^] # Re: Lopin compris

    Posté par  (site web personnel) . En réponse au journal hello wowlrd. Évalué à 9.

    C'est ça, et s'en est devenu une blague, première présentation de Docker et une typo dans Hello World :-D

  • [^] # Re: Update

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 4.

    bah, on attend celui — factuel — qui aurait été attendu :-)

    Le factuel c'est que le "Free Team" est déprécié depuis longtemps, qu'on ne peut pas en créer depuis longtemps et que d'autres solutions existes. Je ne dis pas que les autres sont parfaites, juste qu'elles existes.
    Ce "Free Team" de la manière dont il est encore utilisé, pose un certain nombre de problèmes, et il est temps de fermer cette page. Ce qui est l'objet de cette campagne de dépréciation.
    A aucun moment le but n'est de fermer, bloquer ou autre, de supprimer du contenu. Il s'agit de remettre les choses d'équerre, pour pouvoir continuer à avancer.

    En 15 jours suivants, vous allez promouvoir les projets éligibles ? J'y crois peu

    Tu parles du programme de sponsoring?
    Si oui, la suspension est en pause lorsqu'il y a application et durant le revue

    For new users interested in joining DSOS from a previous Free Team organization, we will defer any organization suspension or deletion while the DSOS application is under review.

    On a mis plus de monde sur le sujet. Je bosse toujours proche de la Product Manager en charge de ce projet. Et si certains veulent en discuter plus précisément, n'hésitez pas à me contacter directement et je peux voir, en discuter, et regarder en interne où ça en est, etc.
    Normalement il n'est pas bien compliqué de trouver un moyen de me joindre, et si besoin un message ci-dessous.

  • [^] # Re: Update

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 3.

    De toute façon je sais bien que pour certains il n'y a rien qui ne sera bien pris.

    Docker a voulu un changement qu'on estime être pour de bonnes raisons.
    La communication n'a pas été bonne, beaucoup de personnes se sont affolées (à juste titre vu la communication loin d'être claire, mal ciblée).
    L'entreprise présente ses excuses pour la façon dont ca c'est passé

    We apologize again for the poor communication and execution surrounding this deprecation and promise to continue to listen to community feedback.

    Maintenant tout le monde est libre de croire ce que je dis ou non, la seule différence c'est que moi je sais comment ça se passe en interne, quelles sont les discussions sur le sujet. Et quand je parle d'humilité c'est bien parce que je pense que c'est fait de cette manière.

  • # distribution -> cncf

    Posté par  (site web personnel) . En réponse au journal Alternatives à Docker (ou presque). Évalué à 5.

    Docker Distribution
    Ici, je vais parler du projet Distribution de Docker.
    Oui, il s'agit d'un logiciel de chez Docker

    Plus ou moins. Enfin plus moins que plus désormais.

    distribution est maintenant un projet de la CNCF: https://www.docker.com/blog/donating-docker-distribution-to-the-cncf/
    Justement dans le but de continuer à le faire vivre, en dehors des besoins de Docker Hub.

    A noter que de nombreuses registry utilisent distribution:

    It is a core library for many registry operators including Docker Hub, GitHub Container Registry, GitLab Container Registry and DigitalOcean Container Registry, as well as the CNCF Harbor Project, and VMware Harbor Registry.

  • # Update

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 8.

    We apologize. We did a terrible job announcing the end of Docker Free Teams.

    https://www.docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams/

    Oui, la communication n'a pas été bonne. Et le signal envoyé n'était pas celui escompté.

    S'il y a pour ma part une chose que j'apprécie chez Docker (d'aucuns diront surtout depuis le reboot il y a un peu plus de 3 ans) c'est d'avoir l'humilité de dire quand on n'a pas été bon.
    Ici, clairement, ce fut le cas.

  • [^] # Re: Copieurs!

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 3.

    le développeur de curl indique recevoir les mails de suppression

    Qu'est-ce qui te dit qu'il n'a pas aussi des orgas free team qui sont dépréciées, en plus de l'orga curl qui elle n'est pas impactée ?
    En fait tu n'en sais toi absolument rien.

    Va falloir vous synchroniser en interne

    Mais ça aussi tu n'en sais rien du tout.

    Depuis le début le programme DSOS est indiqué comme alternative (sous conditions certes). L'orga curl fait partie du programme DSOS et est donc protégée. Où est la non synchro ici ?

  • [^] # Re: Copieurs!

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 2.

    curl fait partie du programme de sponsoring open-source et son image ne va pas disparaître

  • [^] # Re: Copieurs!

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 3.

    Le stockage est déjà (heureusement) dédupliqué. Le principe de la registry est d'avoir un contenu adressable. Chaque blob (layer ou autre, peu importe) est adressé par son digest et un même contenu (à ce niveau de granularité) n'est stocké qu'une fois.

  • [^] # Re: J'utilise docker hub : je suis bien embêté

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 3.

    Et ça marche en été, quand il fait trop chaud et qu'on porte des tshirts ?

    Ça dépend, parfois il faut les relier aux chiffres d'e-graisse et ça peut faire peur.

  • [^] # Re: C'est tabou de payer pour du logiciel libre ... même pour les libristes :.(

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 6.

    c'est aussi difficile de ne pas lier ça à un autre changement assez récent (https://www.docker.com/increase-rate-limits/) en novembre 2020

    Oui alors ce changement était là aussi pour une autre raison :-)
    L'un des objectifs principaux de ce changement (et d'autres comme l'arrêt de la partie gratuite de la CI de Docker Hub, Autobuilds) est de limiter les abus.
    Le problème quand on offre des choses gratuitements c'est qu'il y en aura toujours pour abuser, et que eux peuvent couter extrèmement cher pour… rien.
    En l'occurrence il y avait des très gros abusers en terme de pull (genre, vraiment) et les limites appliquées ont surtout permis de résoudre ce problème. Assez peu de personnes extérieures ont réellement étées impactées.
    Pour Autobuild c'est pareil, c'était noyé sous l'utilisation des cryptominers et autres, et à un moment il a été décidé d'en limiter le scope aux comptes payant. S'ils n'y avaient pas eu d'abus, tout le monde pourrait encore en profiter. Mon équipe était justement responsable de ce changement.

    Bien évidemment qu'il y a des raisons économiques aux choix. Ou plutôt que les choix sont toujours fait avec aussi l'aspect économique.
    Docker reste une petite entreprise (j'imagine que personne ne s'en rend compte, mais on a passé la barre des 300 employés il n'y a pas si longtemps) et se doit d'être rentable. Tout le monde a tellement tapé sur Docker qui ne l'était pas que c'est marrant de voir les même taper quand Docker change dans cet optique.

    Oui le programme DSOS n'a pas toujours été au top. On a beaucoup rebossé le programme, je travaille toujours avec la PM en charge de celui-ci, et honnêtement, sans dire qu'il est parfait, ce programme me tiens beaucoup à coeur car je pense que Docker a une responsabilité envers les communautés open source et qu'on se doit de rendre la pareille. Ca ne veut pas dire à n'importe quel prix, mais ca fait partie des choses qu'on peut faire aujourd'hui.

    Concernant le fait de réappliquer tous les ans. C'est la seule manière de s'assurer que les projets correspondent toujours aux critères. Il faut voir aussi que ce n'est pas juste un programme donnant des ressources matérielles. Ca fait aussi partie d'un programme plus vaste visant à avoir du contenu de qualité sur le Hub. Ce qui demande aussi des vérifications et du travaille côté Docker. On est loin de "on file un namespace et basta".

    Après, je peux comprendre que tout le monde n'est pas prêt à réappliquer tous les ans. A chacun de décider si ca en vaut la peine ou non.

  • [^] # Re: J'utilise docker hub : je suis bien embêté

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 3.

    Ensuite, ça reste du théorique, car je n'ai pas essayé, et je ne me souvient pas avoir vu quelqu'un faire ça

    Ça existe et ça fonctionne.
    Je n'arrive plus à retrouver le nom, mais il y a une boite qui fait ça, un "proxy" (j'ai pas étudié en détail, j'ai pas vérifié comment ça fonctionne exactement) docker, pour avoir ton propre domaine et des analytics. Je crois qu'ils font ça pour d'autres types de registries aussi (npm par ex, mais il faudrait vérifier).

    Généralement les gens utilisent ça pour avoir des analytics sur les pulls, mais (totalement biaisé car je travaillais dessus) les données qu'on a sont bien meilleures, avec une compréhension des usages plus avancée.

  • [^] # Re: C'est tabou de payer pour du logiciel libre ... même pour les libristes :.(

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 5. Dernière modification le 16 mars 2023 à 12:06.

    Mais, actuellement, le plan s'écroule car il n'était valable que dans des conditions économiques spécifiques (à savoir, de l'argent pas cher).

    Ben en fait non.

    Docker Inc ne peut pas vraiment venir chouiner sur "ça coûte trop cher" quand il y a 5 ans, ils ont refuser de lâcher leur place. C'est vrai que ça coûte trop cher

    Ben pareil, non.

    La décision de clôturer les comptes utilisant un plan déprécié depuis 2 ans n'est absolument pas lié au contexte économique actuel comme tu le sous entend ici et là.
    Surtout qu'il existe déjà des options utilisables en remplacement. Que ce soit l'utilisation de comptes simples (gratuits) avec une infinité de collaborateurs ou le programme de sponsoring, il y a toujours la possibilité d'héberger des contenus public sans trop de problème sur Docker Hub.
    Si c'était lié au contexte économique actuel ces solutions auraient été supprimées ou réduites, ce qui n'est pas le cas.

  • [^] # Re: C'est tabou de payer pour du logiciel libre ... même pour les libristes :.(

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 5.

    Nope, absolument pas ;-)

    Start with minimum 5 users for $25
    Billed annually for $300

    Annuellement c'est $9 par mois par utilisateur, sachant que le premier package est de 5 utilisateurs pour $25 par mois.

    Donc en comparaison avec l'ancienne formule free team (qui était limitée à 3 utilisateurs) c'est bien $300 par an pour un team avec 5 utilisateurs.

    $420 c'est le tarif par an payé mensuellement. C'est juste de la mauvaise fois d'Alex Ellis qui le sait très bien mais que tout le monde a repris. D'ailleurs de mémoire ses tweets qui en parlaient, avant l'article, parlaient bien de $300 par an. Mais c'est plus vendeur de parler de $420.

  • [^] # Re: C'est tabou de payer pour du logiciel libre ... même pour les libristes :.(

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 3.

    $420/an

    Juste parce que quand même, une offre team c'est $300/an https://www.docker.com/pricing/
    Ça change pas tout, mais autant prendre les vrais chiffres.

  • # précisions

    Posté par  (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 10.

    Quelques précisions…

    Pour que les choses soient limpides, je travaille chez Docker, et je travaillais spécifiquement dans l'équipe en charge du programme de sponsoring open source jusqu'à récemment (même si je suis dans une autre équipe aujourd'hui). Néanmoins je ne m'exprime ici qu'en mon nom, avec des infos qui sont de toute façon accessibles par ailleurs.

    Concernant les "free teams" :
    - ils ne sont plus accessible (on ne peut plus en créer) depuis quelques temps déjà (pas loin de 2 ans si je ne me trompe). Donc tout projet créé dès lors n'utilise déjà pas cette solution
    - un compte personnel peut être utilisé par un nombre illimité de collaborateurs, tant que c'est sur les repos publics -> ce qui en fait permet à de nombreux projets libres, publics d'être hébergés sur Docker Hub sans aucun problème

    https://www.docker.com/pricing/

    Plus exactement, pour avoir droit à la gratuité pour un accès multi-utilisateurs (le Open Source program)

    Le "Open Source program" n'existe pas, quand bien même Alex l'écrit.
    Le seul qui existe est le "Docker-Sponsored Open Source Program" (DSOS). Alors je pinaille mais la nuance est importante.
    Le but de se programme n'est pas d'offrir gratuitement des ressources à tout le monde, il est de sponsoriser des projets libres non commerciaux (et aussi dans le cadre éducation, université, etc). Les membres de se programme reçoivent des fonctionnalités actuellement disponibles sur les offres team/business voir certaines fonctionnalités qui n'y sont même pas présentes comme la suppression des limites de pull et des statistiques de pull détaillées (je travaillais essentiellement sur cet aspect). Ce programme est très loin de ce qu'étaient les "free teams".
    D'ailleurs les membres du DSOS program font aussi partie de ce qu'on appelle Docker Trusted Content avec les images officielles et les Verified Publishers.

    Alors pourquoi sponsoriser ces projets et pas tous les projets libres ? Je dirais tout simplement parce que ce sont avant tous ces projets, sans revenus, qui ont besoin d'aide. Et dans cet optique ce qu'offre Docker est loin d'une offre d'équipe au rabais, c'est un panel complet de fonctionnalités pour aider et développer les projets open source communautaires (non commerciaux).

  • [^] # Re: Titre

    Posté par  (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 2.

    Tant que j'y pense, un point de détail mais qui n'est pas si détail que ca :

    6) avoir une image vérifié du projet. On parle de la vérification sur le fediverse (en utilisant rel=me, mais j'aimerais aussi avoir ça (et pas que pour Docker, car j'ai aussi le souci avec les images Centos sur AWS). Ensuite, vu que Docker fournit des images officiels (genre https://hub.docker.com/_/nginx) 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.

    L'image officielle nginx est l'image du projet upstream. Cette image est maintenue par nginx, pas par Docker.

    C'est visible en haut du README :

    Maintained by:
    the NGINX Docker Maintainers

    Alors certes ce n'est pas très visible, et on va travailler sur cette partie. Mais image officielle docker ne veut pas dire que ce n'est pas l'image officielle du projet upstream.

  • [^] # Re: 100% dispo

    Posté par  (site web personnel) . En réponse au journal Le cloud ça scale bien. Évalué à 10.

    Un peu comme quand OVH crame un datacenter, en somme…

    C'était pas plutôt en Alsace ?

  • [^] # Re: Titre

    Posté par  (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 4.

    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.