Le préchauffage de cache comme dernière étape de votre pipeline de déploiement

La solution la plus fiable à la lenteur post-déploiement est de faire du préchauffage de cache la dernière étape de votre pipeline CI/CD : un seul appel API après le déploiement, et le cache est reconstruit avant que le trafic réel ne remarque quoi que ce soit. Ce guide donne des exemples à copier-coller pour GitHub Actions et GitLab CI, et montre comment gérer plusieurs environnements.

Le problème déploiement → cache froid

Chaque déploiement de code qui vide le cache crée une fenêtre pendant laquelle votre site est lent. Cette fenêtre peut durer 30 secondes ou 5 minutes selon la taille de votre catalogue, mais pendant ce laps de temps, vos premiers vrais visiteurs (souvent les plus enthousiastes, juste après la mise en ligne d'une nouveauté) subissent une expérience dégradée.

Faire du préchauffage de cache la dernière étape de votre pipeline de déploiement referme cette fenêtre. Quand le déploiement se termine, le cache est déjà reconstruit.

Déclencher un préchauffage depuis le CI/CD

CacheBoost expose un endpoint d'API REST simple pour déclencher l'exécution d'un boost :

POST https://api.cache-boost.com/v1/boosts/{boost_id}/run
Authorization: Bearer cb_live_...

C'est une seule requête HTTP. Elle s'intègre dans n'importe quel système CI/CD : GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines, un Makefile, un script shell.

Exemple GitHub Actions

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: ./deploy.sh

      - name: Warm cache
        run: |
          curl -s -o /dev/null -w "%{http_code}" \
            -X POST https://api.cache-boost.com/v1/boosts/${{ secrets.CACHEBOOST_BOOST_ID }}/run \
            -H "Authorization: Bearer ${{ secrets.CACHEBOOST_API_KEY }}" \
            -H "Content-Type: application/json"

Stockez CACHEBOOST_API_KEY et CACHEBOOST_BOOST_ID comme secrets du dépôt. L'appel de préchauffage est de type « fire-and-forget » : il met l'exécution en file d'attente et répond immédiatement, donc il ne bloque pas votre pipeline.

Exemple GitLab CI

stages:
  - deploy
  - warm_cache

deploy:
  stage: deploy
  script:
    - ./deploy.sh

warm_cache:
  stage: warm_cache
  script:
    - |
      curl -s -X POST https://api.cache-boost.com/v1/boosts/$CACHEBOOST_BOOST_ID/run \
        -H "Authorization: Bearer $CACHEBOOST_API_KEY"
  needs: [deploy]

Attendre la fin du préchauffage

L'endpoint de déclenchement répond immédiatement. Si vous souhaitez attendre la fin de l'exécution avant de marquer le déploiement comme réussi, vous pouvez interroger le statut de l'exécution :

# Déclencher l'exécution et capturer l'ID du run
RESPONSE=$(curl -s -X POST https://api.cache-boost.com/v1/boosts/$BOOST_ID/run \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json")
RUN_ID=$(echo $RESPONSE | jq -r '.data.id')

# Interroger jusqu'à la fin
while true; do
  STATUS=$(curl -s https://api.cache-boost.com/v1/runs/$RUN_ID \
    -H "Authorization: Bearer $API_KEY" | jq -r '.data.status')
  echo "Run status: $STATUS"
  [ "$STATUS" = "completed" ] || [ "$STATUS" = "failed" ] && break
  sleep 10
done

Pour la plupart des pipelines, le fire-and-forget suffit. Le préchauffage s'exécute en parallèle de vos éventuelles vérifications post-déploiement.

Environnements multiples

Si vous avez des environnements de staging et de production, créez un boost par environnement :

• Boost staging : couvre votre domaine de staging, user-agents de priorité réduite, une seule région
• Boost production : couvre votre domaine de production, tous les user-agents, toutes les régions

Dans votre configuration CI/CD, sélectionnez le bon ID de boost selon la branche ou une variable d'environnement :

- name: Warm cache
  run: |
    BOOST_ID=$([[ "$BRANCH" == "main" ]] && echo "$PROD_BOOST_ID" || echo "$STAGING_BOOST_ID")
    curl -s -X POST https://api.cache-boost.com/v1/boosts/$BOOST_ID/run \
      -H "Authorization: Bearer $CACHEBOOST_API_KEY"

Combiner avec un préchauffage planifié

Le déclenchement au déploiement couvre les déploiements de code. Mais les rédacteurs ne passent pas par votre pipeline de déploiement : ils publient directement dans le CMS. Combinez le préchauffage déclenché au déploiement avec un préchauffage complet planifié chaque nuit pour couvrir les deux cas :

• Au déploiement : déclenchement immédiat via l'API
• Chaque nuit à 3h : préchauffage complet planifié via une expression cron dans la configuration du boost

Cette approche à deux niveaux garantit que ni les déploiements de code ni les mises à jour de contenu ne laissent votre cache froid bien longtemps.