referJournal

8 October 2026

Bonnes pratiques pour construire des images Docker

Conseils concrets pour construire des images Docker légères, sécurisées et reproductibles : images de base officielles, multi-stage, .dockerignore, gestion du cache des couches et étiquettes.

Par Refer·3 min de lecture

title: “Bonnes pratiques pour construire des images Docker” date: “2026-10-08” author: “Refer” draft: false summary: “Conseils concrets pour construire des images Docker légères, sécurisées et reproductibles : images de base officielles, multi-stage, .dockerignore, gestion du cache des couches et étiquettes.”

Bonnes pratiques pour construire des images Docker

Introduction

Chaque déploiement moderne passe désormais par une image Docker. Encore faut il que cette image soit légère, rapide à construire, sûre et reproductible. Un Dockerfile mal écrit peut multiplier les temps de build, alourdir les déploiements et exposer des failles de sécurité. Voici les bonnes pratiques à connaître pour construire des images Docker professionnelles.

1. Utiliser une image de base officielle et adaptée

La première règle est de partir d’une image fiable :

  • Privilégier les images officielles (node, python, nginx, postgres…) disponibles sur Docker Hub.
  • Choisir une variante légère : alpine, slim, ou bookworm-slim au lieu de l’image complète.
  • Éviter le tag latest en environnement de production ; privilégier un tag immuable (version).

Exemple :

FROM node:20-bookworm-slim

L’image de base doit être mise à jour régulièrement, car elle rendra les vulnérabilités en provenance de la plateforme.

2. Privilégier les builds en plusieurs étapes (multi-stage)

Les builds en plusieurs étapes permettent de séparer l’environnement de compilation de l’environnement d’exécution. Résultat : l’image finale ne contient que ce qui est nécessaire, et pas les compilateurs, outils de développement ou dépendances de build.

# ── Étape 1 : build ──────────────────────────────
FROM node:20-bookworm-slim AS build
WORKDIR /app
COPY package*.json ./ 
RUN npm ci
COPY . . 
RUN npm run build

# ── Étape 2 : production ─────────────────────────
FROM node:20-bookworm-slim AS production
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

L’image finale pèse quelques dizaines de Mo au lieu de plus de 500 Mo.

3. Optimiser le cache des couches

Chaque instruction Dockerfile crée une couche. Docker réutilise les couches inchangées. Pour accélérer les builds :

  • Placer les instructions les moins susceptibles de changer en premier (installations de dépendances).
  • Copier les fichiers de dépendances séparément avant le code source.
  • Regrouper les appels apt-get ou RUN pour limiter le nombre de couches.

Mauvais exemple :

RUN apt-get update
RUN apt-get install -y curl

Bon exemple :

RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

4. Utiliser un fichier .dockerignore

Pour ne pas embarquer inutilement des artefacts dans l’image (node_modules, .git, target/, .env), créer un .dockerignore à la racine du projet :

node_modules
.git
.env
*.log
dist
target

Cela réduit la taille du contexte de build et améliore le cache.

5. Ajouter des métadonnées et un point de contrôle de santé

Les labels servent à documenter l’image :

LABEL maintainer="é[email protected]"
LABEL version="1.0"
LABEL description="Service API métier"

Une directive HEALTHCHECK permet à l’outil d’orchestrateur de détecter un conteneur en panne :

HEALTHCHECK --interval=30s --timeout=3s   CMD curl -fsS http://localhost:3000/health || exit 1

6. Jamais de secrets dans l’image

Un Dockerfile est stocké dans le code source : on ne y mettra jamais de mot de passe, token ou clé privée. Pour passer des secrets à un build :

ARG API_KEY
RUN echo "$API_KEY" > /tmp/api.key

Puis au build :

docker build --build-arg API_KEY="$(cat .env.api)" -t mon-app .

Alternativement, Docker fournit des secrets de build disponibles uniquement pendant le RUN, ce qui évite tout trace dans la couche finale.

Conclusion

Construire une bonne image Docker, c’est : une image de base fiable, des builds en plusieurs étapes, un fichier .dockerignore, un ordre d’instructions optimisé, des métadonnées, et zéro secret. Ces pratiques consultables, faciles à mettre en place, ont un impact direct sur les temps de build, la sécurité et la reproductibilité de vos déploiements.