Standardiser les images Docker sans réécrire toute la chaîne de livraison

Le problème réel

L’organisation cherchait à accélérer sa chaîne de livraison, mais chaque équipe avait progressivement construit sa propre définition d’une « bonne » image Docker.

Les images de base variaient, les styles de build divergeaient, les scans n’étaient pas appliqués de manière homogène et les discussions sur l’optimisation se concentraient sur des gains locaux.

Le risque était de rendre chaque Dockerfile un peu meilleur tout en laissant la chaîne globale devenir plus difficile à comprendre et à gouverner.

Ce que nous avons trouvé

Le problème principal n’était pas un Dockerfile particulièrement mauvais.

C’était l’absence de baseline commune : quelles images de base sont acceptables, quels contrôles doivent bloquer une livraison, qui maintient les images de référence et à quel moment une exception est justifiée.

Sans ce socle, les optimisations de taille, de temps de build ou de registry restaient difficiles à comparer et encore plus difficiles à maintenir.

Notre intervention

Nous avons commencé par l’inventaire et la classification plutôt que par une réécriture.

Les images ont été examinées selon leur usage, leur base, leur structure de build et les contrôles appliqués dans la CI. Les pratiques récurrentes ont ensuite été transformées en un standard commun : images de base par type de workload, multi-stage build lorsque pertinent, scan intégré au chemin de livraison et responsabilité explicite sur les exceptions.

L’arbitrage

Le choix a été de renoncer temporairement aux optimisations opportunistes pour créer d’abord un cadre commun.

Cela permettait de corriger progressivement les images existantes sans imposer une migration générale du registry ni une réécriture simultanée de toute la chaîne.

Ce qui a changé

Les équipes disposent désormais d’une définition commune de ce qui peut être considéré comme une image acceptable.

La plateforme et la sécurité disposent d’un point de contrôle plus clair en CI, tandis que les travaux d’optimisation peuvent être priorisés à partir d’une baseline partagée plutôt qu’à partir d’une collection de Dockerfiles indépendants.

Ce que nous retenons

Dans une chaîne de livraison, standardiser produit souvent plus de valeur durable qu’optimiser chaque artefact isolément.

Une image légèrement plus petite est utile. Une organisation capable de produire, contrôler et faire évoluer ses images de manière cohérente l’est davantage.