Que faut-il vraiment cacher dans un pipeline CI/CD ?

Mettre du cache dans un pipeline CI/CD ne consiste pas à stocker des fichiers au hasard. Cet article propose une grille de lecture pragmatique pour comprendre quoi cacher, pourquoi, et comment éviter un cache fragile ou contre-productif.

I. Introduction  

Quand on cherche à accélérer un pipeline CI/CD, la première idée qui vient presque toujours est :

« il faut mettre du cache »

Mais très vite, une autre question apparaît :
qu’est-ce qu’on cache exactement ?

Des fichiers ? Des dossiers ? Des images Docker ? Des dépendances ?
Et surtout : quel cache a un vrai impact, et lequel complique juste le système ?

Cet article propose une grille de lecture simple et pragmatique pour répondre à cette question.

II.Le piège classique : cacher des fichiers au hasard  

Beaucoup de pipelines commencent comme ça :

• on cache node_modules
• on cache .pnpm-store ou .npm
• on cache des dossiers de build
• parfois même tout le workspace

Résultat :

• ça marche parfois
• ça casse souvent
• et personne ne sait vraiment pourquoi

Le problème n’est pas le cache en soi.
Le problème, c’est ce qu’on essaie de cacher.

III. Le principe clé : on ne cache pas des fichiers, on cache du travail  

Un pipeline CI/CD n’est pas une suite de fichiers, c’est une suite de tâches :

• installer des dépendances
• générer du code
• compiler
• tester
• packager

Chaque cache utile correspond à une tâche bien définie, avec :

• des entrées (inputs)
• des sorties (outputs)

Si les entrées n’ont pas changé, le travail n’a pas besoin d’être refait.

C’est cette logique qui doit guider tout cache efficace.

IV. Les grandes catégories de cache (et leur vraie valeur)  

1. Le cache de téléchargement (le minimum vital)  

Il évite de retélécharger ce qui existe déjà. C’ est à faire quasiment toujours.

Exemples :

• dépendances Node (pnpm / npm / yarn)
• modules Go
• dépendances Foundry / Solidity
• dépendances Maven / Gradle

Valeur

• gain immédiat
• faible risque
• facile à mettre en place

Limite

• ne supprime pas le travail de build
• seulement le coût réseau

2. Le cache de génération (codegen, artefacts intermédiaires)  

Il est un excellent candidat, très souvent oublié, et pourtant très rentable.

Exemples :

• génération GraphQL
• génération de bindings
• génération de contrats
• code produit par des outils

Valeur

• tâches souvent déterministes
• coûteuses à répéter
• idéales pour le cache

Condition clé

• les inputs doivent être clairement identifiés
  (schémas, fichiers source, versions d’outils)

3. Le cache de build (compilation)  

C’est là que les choses deviennent intéressantes… et délicates.

Exemples :

• build TypeScript
• build Go
• build Solidity
• build frontend

Valeur

• gains potentiels énormes
• réduction massive des temps CI

Risque

• si le cache est mal invalidé, on cache des bugs
• s’il est trop grossier, il devient inutilisable

Bonne pratique

• cacher par unité logique (projet, package, service)
• éviter le “cache global du build”

Il est très utile, mais demande de la discipline.

4. Le cache de tests  

Souvent contre-intuitif, mais parfois pertinent. Il est à utiliser avec discernement.

Exemples :

• tests unitaires purement déterministes
• tests basés uniquement sur le code source

Valeur

• énorme pour les suites longues
• améliore fortement le feedback loop

Attention

• tests dépendant du temps, de l’ordre ou de l’environnement → mauvais candidats
• tests d’intégration → généralement non

5. Le cache Docker (utile, mais mal compris)  

Le cache Docker est linéaire. Il est excellent pour le packaging mais mauvais comme cache principal de logique applicative :

• une modification dans une couche invalide toutes les suivantes
• il ne comprend pas la notion de “projet” ou de “tâche”

Ce que Docker cache bien

• dépendances système
• étapes de packaging
• images reproductibles

Ce que Docker ne sait pas faire

• réutiliser un build applicatif précis
• comprendre qu’un service n’est pas impacté

V. Le découpage à viser  

Un pipeline efficace cache :

Mais surtout : chaque cache doit correspondre à une tâche explicite, pas à un dossier arbitraire.

VI. Pourquoi beaucoup de pipelines deviennent ingérables  

Parce qu’ils empilent :

• un cache CI
• un cache Docker
• des scripts ad hoc
• des règles implicites

Sans jamais répondre à la question fondamentale :

Quel travail est-ce que j’essaie d’éviter de refaire ?

Quand cette réponse n’est pas claire, le cache devient :

• fragile
• incompris
• et rapidement désactivé “temporairement”… pour toujours

VII. Le bon indicateur de succès  

Un bon cache CI/CD a une propriété simple :

Un développeur peut prédire ce qui sera réutilisé sans lire la configuration CI.

Si ce n’est pas le cas, le cache est trop implicite.

VIII. Conclusion  

Mettre du cache dans un pipeline CI/CD n’est pas une question d’outil.
C’est une question de modélisation du travail.

• Cache ce qui est coûteux
• Cache ce qui est déterministe
• Cache ce qui est clairement délimité
• Évite de cacher ce que tu ne sais pas expliquer

Les outils viennent après. Toujours.

🔗 Liens utiles  

• CircleCI Engineering — Caching Dependencies to Speed Up Workflows

• GitHub Actions — Caching dependencies to speed up workflows

• GitLab CI — Cache and artifacts