Neuf minutes pour exécuter une suite de tests qui, en local, sur le poste d’un développeur, prend à peine deux minutes. Cet écart, observé sur le pipeline d’un thème WordPress à blocs, intrigue l’équipe depuis des semaines sans qu’elle prenne le temps de creuser. Le réflexe habituel consiste à blâmer la lenteur générale du fournisseur d’intégration continue, ou la complexité supposée du projet. La vraie cause, une fois isolée, est beaucoup plus banale : chaque exécution du pipeline réinstalle intégralement les dépendances Composer et npm depuis zéro, à chaque commit, même quand aucun fichier de verrouillage n’a changé.
Cet article ne traite pas du choix du fournisseur d’intégration continue lui-même, mais du calcul du temps perdu par l’absence de cache, un problème qui se pose de façon identique quel que soit l’outil utilisé.
Ce que réinstalle un pipeline sans cache, à chaque exécution
Sans mécanisme de cache configuré, chaque exécution d’un pipeline part d’une machine vierge. La commande composer install télécharge et installe l’ensemble des dépendances PHP du projet, y compris celles qui n’ont pas changé depuis des mois. La commande npm install fait de même côté JavaScript, souvent pour un projet dont le fichier package-lock.json reste identique commit après commit. Ce travail redondant s’ajoute mécaniquement à chaque exécution, sans jamais bénéficier de ce qui a déjà été calculé la fois précédente.
Calculer le coût réel sur une semaine de travail d’équipe
Sur ce projet, l’équipe pousse en moyenne dix-huit commits par jour ouvré, répartis entre plusieurs développeurs travaillant sur des branches distinctes. Chaque exécution de pipeline sans cache ajoute environ quatre minutes de réinstallation de dépendances par rapport à une exécution qui réutiliserait un cache déjà chaud. Le calcul est simple à poser :
- Dix-huit exécutions par jour, quatre minutes perdues par exécution, soit soixante-douze minutes cumulées par jour ouvré.
- Sur une semaine de cinq jours, cela représente environ six heures de calcul entièrement redondant.
- Sur un mois, cette redondance dépasse vingt-quatre heures de machine consommées pour réinstaller strictement les mêmes fichiers.
Ce temps ne se traduit pas uniquement en coût de facturation du fournisseur d’intégration continue : il se traduit surtout en attente pour les développeurs, qui patientent avant de voir le résultat de leurs tests et retardent d’autant leurs itérations suivantes.
Mettre en place le cache des dépendances
La correction demande peu de travail comparée au gain obtenu. Elle consiste à mettre en cache les dossiers vendor et node_modules, en indexant ce cache sur le contenu des fichiers de verrouillage plutôt que sur une clé fixe, pour que le cache se régénère automatiquement dès qu’une dépendance change réellement :
- name: Cache des dépendances Composer
uses: actions/cache@v4
with:
path: vendor
key: composer-${{ hashFiles('composer.lock') }}
- name: Cache des dépendances npm
uses: actions/cache@v4
with:
path: node_modules
key: npm-${{ hashFiles('package-lock.json') }}
La clé basée sur un condensé du fichier de verrouillage garantit que le cache reste valide tant que les dépendances déclarées ne changent pas, et qu’il se reconstruit automatiquement dès qu’une mise à jour de dépendance modifie ce fichier.
Ce qu’on voit après la mise en place du cache
Une fois ce mécanisme en place, seule la première exécution après un changement de dépendances paie le coût complet de l’installation. Toutes les exécutions suivantes, tant que les fichiers de verrouillage restent identiques, réutilisent l’archive mise en cache et gagnent les quatre minutes identifiées plus haut. Sur ce projet, le temps moyen d’exécution du pipeline est passé de neuf à environ cinq minutes, un gain qui se ressent immédiatement dans le rythme de travail de l’équipe.
| Configuration | Temps moyen d’exécution |
|---|---|
| Sans cache de dépendances | 9 minutes |
| Avec cache indexé sur les fichiers de verrouillage | 5 minutes |
Une phrase qui a convaincu l’équipe plus vite qu’aucune explication technique : « ce cache que nous n’avons pas mis en place nous a déjà coûté l’équivalent d’une journée de travail ce mois-ci ». Le calcul parle souvent mieux que la théorie.
Notre verdict
Un pipeline d’intégration continue sans cache de dépendances n’est pas seulement plus lent : il consomme silencieusement un temps cumulé considérable, invisible tant que personne ne prend la peine de le chiffrer précisément. La mise en place d’un cache indexé sur les fichiers de verrouillage demande quelques lignes de configuration et se traduit, sur ce projet, par un gain de plusieurs heures de travail d’équipe chaque mois.
