Tout le monde sait écrire un Dockerfile. Peu savent en écrire un bon. Une image Docker mal construite est lourde, lente à builder et truffée de failles. Voici les pratiques qui font la différence en 2026.
Partir d’une image de base minimale
Une image node:latest pèse des centaines de Mo. Une variante alpine ou slim réduit drastiquement la taille — et donc la surface d’attaque. Moins il y a dans l’image, moins il y a à sécuriser et à transférer.
Maîtriser le cache de build
L’ordre des instructions dans un Dockerfile détermine l’efficacité du cache. Copiez d’abord les fichiers de dépendances, installez, puis copiez le code. Ainsi, un changement de code ne réinvalide pas l’installation des dépendances.
Adopter les multi-stage builds
C’est la pratique la plus impactante. Un multi-stage build sépare l’environnement de compilation de l’image finale : vous compilez dans une première étape, puis ne copiez que l’artefact nécessaire dans une image minimale. Résultat : des images de production légères, sans outils de build superflus.
Ne jamais tourner en root
Par défaut, un conteneur s’exécute en root. C’est un risque majeur. Créez un utilisateur dédié et passez en USER non privilégié. Une faille dans l’application ne donne alors pas les pleins pouvoirs.
Gérer les secrets correctement
Ne mettez jamais de secret dans un Dockerfile ou une variable d’environnement en clair dans l’image. Utilisez les mécanismes de secrets de votre orchestrateur ou un gestionnaire dédié.
Scanner ses images
Intégrez un scan de vulnérabilités (Trivy, Grype) dans votre pipeline. Une image validée hier peut contenir une CVE découverte aujourd’hui.
En résumé
Une bonne image Docker est légère, reproductible, non privilégiée et scannée. Ces réflexes s’acquièrent par la pratique — c’est l’objet de notre formation Docker, des fondamentaux jusqu’à la préparation pour la production.