Pourquoi le cache Docker est insuffisant pour un monorepo ?

Le cache Docker est puissant pour le packaging et la reproductibilité, mais il atteint rapidement ses limites dans un monorepo. Cet article explique pourquoi son modèle linéaire ne permet pas d’éviter le travail inutile, et pourquoi un cache plus granulaire devient indispensable.

I. Pourquoi le cache Docker est insuffisant pour un monorepo  

Docker est partout.
Et avec lui, une idée largement répandue :

« Si on structure bien nos Dockerfiles, le cache Docker va accélérer notre CI. »

C’est vrai… mais seulement jusqu’à un certain point.

Dès qu’on travaille dans un monorepo — avec plusieurs projets, plusieurs langages, plusieurs pipelines logiques — le cache Docker montre rapidement ses limites.

Cet article explique pourquoi, sans dénigrer Docker, et surtout ce qu’il faut comprendre pour éviter de l’utiliser au mauvais endroit.

II. Ce que fait très bien le cache Docker  

Commençons par être justes :
le cache Docker est excellent dans son domaine.

Docker met en cache :

• les couches (layers) d’un Dockerfile
• chaque instruction (RUN, COPY, etc.) crée une couche
• si l’instruction et son contexte n’ont pas changé → la couche est réutilisée

Cela fonctionne très bien pour :

• installer des dépendances système
• builder une image de manière reproductible
• packager une application
• garantir que “ce qui marche en CI marchera en prod”

Docker excelle comme outil de packaging et de distribution.

III. Le problème fondamental : le cache Docker est linéaire  

Le cache Docker est basé sur une chaîne linéaire de couches.

Layer 1 → Layer 2 → Layer 3 → Layer 4

Si une couche change :

• toutes les couches suivantes sont invalidées
• même si elles n’ont aucun lien logique avec le changement

Exemple typique :

COPY package.json .
RUN pnpm install

COPY src/ ./src
RUN pnpm build

Un changement dans package.json invalide tout (ce qui est normal).

Mais un changement mineur dans src/ invalide aussi toute la fin, même si :

• seule une partie du code est concernée
• un seul projet du monorepo est touché

Docker ne sait pas faire autrement.

IV. Pourquoi cette approche casse dans un monorepo  

Un monorepo, ce n’est pas :

• une application
• un build unique

C’est :

• plusieurs projets
• plusieurs graphes de dépendances
• plusieurs unités de travail indépendantes

Exemples :

• frontend web
• application mobile
• backend API
• génération de code GraphQL
• contrats Solidity
• bibliothèques partagées

Docker ne comprend pas ces frontières.

Pour Docker :

• tout ce qui est copié dans le contexte est vu comme une seule masse
• tout ce qui est construit produit un seul résultat

Résultat :

• un petit changement dans un projet invalide des builds sans rapport
• on reconstruit “le monde” trop souvent
• les temps CI explosent à mesure que le dépôt grandit

V. Multi-stage builds : amélioration réelle, mais insuffisante  

Les multi-stage builds sont souvent présentés comme la solution.

Ils permettent :

• de séparer les étapes dépendances / build / runtime
• de réduire la taille des images finales
• d’éviter de recompiler certains éléments inutilement

Exemple :

FROM node:20 AS deps
RUN pnpm install

FROM deps AS build
RUN pnpm build

FROM nginx AS runtime
COPY --from=build /dist /usr/share/nginx/html

C’est une très bonne pratique.

Mais attention :

• chaque stage reste linéaire
• à l’intérieur d’un stage, le problème est identique
• Docker ne sait toujours pas ce qu’est un « projet » ou une « tâche »

Les multi-stage builds optimisent le packaging, pas l’orchestration.

VI. Et BuildKit ? Le parallélisme ne change pas le modèle  

Docker BuildKit apporte des améliorations réelles :

• exécution parallèle de certains stages
• cache plus intelligent
• meilleures performances globales

Mais :

• le modèle mental reste le même
• BuildKit optimise comment on exécute les couches
• pas quoi doit être exécuté

BuildKit accélère un modèle linéaire.
Il ne le transforme pas en modèle granulaire.

VII. Le vrai décalage : Docker cache des couches, pas du travail  

C’est le point clé.

Docker cache :

• des instructions
• des états intermédiaires
• des fichiers dans une image

Mais dans un monorepo, on veut cacher :

• le résultat d’une tâche
• conditionnée par des inputs explicites
• produisant des outputs identifiés

Exemples de vraies unités de cache utiles :

• build du frontend web
• tests du backend
• génération GraphQL
• build des contrats Solidity

Ces unités n’existent pas dans Docker.

VIII. Le symptôme typique : un cache qui devient fragile  

Quand Docker est utilisé comme cache principal dans un monorepo, on observe souvent :

• des Dockerfiles de plus en plus complexes
• des COPY fragmentés à l’extrême
• des règles implicites
  (« ne touche pas à ce fichier sinon tout rebuild »)
• des temps CI imprévisibles
• des développeurs qui désactivent le cache “temporairement”

Ce n’est pas un problème de compétence.
C’est un mauvais outil pour ce niveau d’abstraction.

IX. La bonne place du cache Docker  

Docker a parfaitement sa place dans un pipeline monorepo, mais pas comme moteur principal d’orchestration. Son rôle est d’assurer la reproductibilité et la portabilité des environnements.

Il excelle lorsqu’il s’agit d’installer des dépendances système, de construire des images fiables, de packager des artefacts finaux et de garantir une cohérence stricte entre la CI et la production.

En revanche, Docker n’est pas conçu pour décider quoi doit être reconstruit après un changement. Il ne comprend pas les frontières entre projets, ni les graphes de dépendances internes d’un monorepo. Son modèle repose sur des couches successives, pas sur des unités de travail indépendantes.

Autrement dit, Docker est un excellent outil de packaging et d’exécution, mais un mauvais outil d’orchestration. Dans un monorepo, il doit rester complémentaire : il exécute ce qui a été décidé ailleurs, mais ne devrait jamais être responsable de déterminer ce qui mérite d’être refait.

X. Conclusion  

Le cache Docker n’est pas mauvais.
Il est insuffisant.

La règle simple à retenir

Docker sait “comment construire une image”.
Il ne sait pas “quel travail mérite d’être refait”.

Dans un monorepo, cette décision est centrale.

Pas parce qu’il est lent,
mais parce qu’il opère au mauvais niveau d’abstraction pour un monorepo.

Si ton pipeline cherche à :

• éviter de refaire du travail inutile
• comprendre l’impact réel d’un changement
• garder des temps CI stables quand le dépôt grandit

Alors Docker ne peut pas être ton cache principal.

Il doit être complémentaire, pas central.

🔗 Liens utiles  

• Docker Documentation — Use cache effectively

• Docker BuildKit — Overview and cache behavior