Renovate : Automatisez les Mises à Jour de vos Dépendances

Introduction

Les dépendances logicielles sont partout. Un projet moderne typique en contient des dizaines, voire des centaines : bibliothèques npm, packages Python, images Docker, charts Helm, modules Terraform, actions GitHub, rôles Ansible... Chaque dépendance évolue à son propre rythme, avec des corrections de bugs, des patchs de sécurité et de nouvelles fonctionnalités.

Le problème est bien connu : les mises à jour de dépendances sont la tâche la plus procrastinée du développement logiciel. On reporte, on oublie, et un beau jour on se retrouve avec des dépendances vieilles de deux ans, des vulnérabilités critiques non corrigées, et une migration massive et douloureuse à effectuer. C'est de la dette technique silencieuse qui s'accumule inexorablement.

Architecture en un coup d'œil

C'est exactement le problème que Renovate résout. Développé par Mend.io (anciennement WhiteSource) et entièrement open source, Renovate est un outil qui scanne automatiquement vos dépôts de code, détecte les dépendances obsolètes, et crée des pull requests (ou merge requests) pour les mettre à jour. Il supporte un nombre impressionnant de gestionnaires de paquets et de plateformes, et offre une flexibilité de configuration inégalée.

En 2025-2026, Renovate est devenu un standard de l'industrie, utilisé par des milliers d'entreprises et des projets open source majeurs. Dans cet article, nous allons explorer en détail son fonctionnement, sa configuration, et les bonnes pratiques pour l'adopter efficacement.

Le problème des dépendances obsolètes

Les risques de ne pas mettre à jour

Ne pas mettre à jour ses dépendances n'est pas simplement une question de bonnes pratiques — c'est un risque opérationnel et sécuritaire majeur :

• Vulnérabilités de sécurité : les CVE (Common Vulnerabilities and Exposures) sont publiées quotidiennement. Une dépendance obsolète peut contenir des failles critiques exploitées activement. L'attaque Log4Shell (CVE-2021-44228) a montré à quel point une seule dépendance vulnérable peut avoir des conséquences catastrophiques
• Incompatibilités croissantes : plus vous attendez, plus la mise à jour devient difficile. Passer de la v1.2 à la v1.5 est généralement simple. Passer de la v1.2 à la v4.0 nécessite souvent une migration complète
• Fin de support : les versions anciennes finissent par ne plus recevoir de correctifs, même pour des failles critiques
• Blocage des mises à jour en chaîne : la dépendance A nécessite la version 2+ de la dépendance B, mais vous êtes bloqué en version 1. Ces cascades de blocages deviennent ingérables
• Perte de productivité : les développeurs passent du temps à contourner des bugs déjà corrigés en amont

L'approche traditionnelle et ses limites

Sans automatisation, la gestion des mises à jour repose sur des processus manuels fragiles :

1. Audit périodique : un développeur lance npm audit ou pip-audit de temps en temps, traite les alertes les plus critiques, et repousse le reste
2. Journée de mise à jour : l'équipe consacre une demi-journée par mois aux mises à jour. En pratique, cette journée est souvent annulée pour cause de deadline
3. Dépendabot seul : GitHub propose Dependabot intégré, mais ses capacités sont limitées (nous y reviendrons)

Le résultat est prévisible : les mises à jour prennent du retard, la dette s'accumule, et les migrations deviennent des projets en soi.

Qu'est-ce que Renovate ?

Vue d'ensemble

Renovate est un outil open source d'automatisation des mises à jour de dépendances. Concrètement, il :

1. Scanne vos dépôts de code à intervalles réguliers
2. Détecte tous les fichiers de dépendances (package.json, requirements.txt, Dockerfile, docker-compose.yml, Chart.yaml, main.tf, .github/workflows/*.yml, etc.)
3. Vérifie s'il existe des versions plus récentes pour chaque dépendance
4. Crée des pull/merge requests avec les mises à jour, incluant les changelogs, les notes de release, et l'historique des commits
5. Met à jour automatiquement les PR en cas de conflits
6. Peut auto-merger les mises à jour mineures/patch si les tests passent

Renovate est écrit en TypeScript et est distribué comme :

• GitHub App : installation en un clic sur GitHub.com (géré par Mend.io)
• GitLab CI/CD : intégration native via un pipeline
• Self-hosted : exécutable en Docker, npm, ou binary, pour Gitea, Forgejo, Bitbucket, Azure DevOps, etc.

Le dépôt et la communauté

Le projet est hébergé sur github.com/renovatebot/renovate avec plus de 18 000 étoiles GitHub (en 2025), des centaines de contributeurs, et un rythme de release intense (plusieurs releases par semaine). La documentation est excellente et couvre chaque option de configuration en détail.

Renovate vs Dependabot : comparaison détaillée

Dependabot est l'outil de mise à jour de dépendances intégré à GitHub. Bien qu'il soit pratique car pré-intégré, Renovate le surpasse dans de nombreux domaines :

En résumé : Dependabot est un bon point de départ si vous êtes exclusivement sur GitHub et avez des besoins simples. Renovate est le choix professionnel dès que vous avez besoin de flexibilité, de multi-plateforme, ou de configurations avancées.

Installation de Renovate

Option 1 : GitHub App (la plus simple)

Pour les dépôts GitHub, la méthode la plus simple est d'installer l'application Renovate depuis le GitHub Marketplace :

1. Rendez-vous sur github.com/apps/renovate
2. Cliquez sur « Install »
3. Sélectionnez les dépôts sur lesquels activer Renovate (tous ou une sélection)
4. Renovate créera automatiquement une première PR « onboarding » dans chaque dépôt, avec une configuration par défaut

L'application est gérée par Mend.io et est gratuite pour les dépôts publics et privés. C'est la méthode recommandée pour débuter.

Option 2 : GitLab CI/CD

Pour GitLab, Renovate s'intègre via un pipeline CI/CD dédié. Créez un projet « renovate-runner » avec le fichier suivant :

# .gitlab-ci.yml pour le runner Renovate
# Ce pipeline exécute Renovate sur tous vos projets GitLab

variables:
  RENOVATE_PLATFORM: "gitlab"
  RENOVATE_ENDPOINT: "https://gitlab.example.com/api/v4/"
  RENOVATE_TOKEN: "${GITLAB_TOKEN}"  # Token d'accès avec scope api
  RENOVATE_GIT_AUTHOR: "Renovate Bot <renovate@example.com>"
  LOG_LEVEL: "info"

renovate:
  image: renovate/renovate:latest
  stage: deploy
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  script:
    - renovate --autodiscover=true --autodiscover-filter="group-name/*"
  timeout: 1h

Configurez ensuite un pipeline schedule dans GitLab (par exemple toutes les 2 heures) pour déclencher automatiquement les scans.

Option 3 : Self-hosted avec Docker

Pour une installation self-hosted (Gitea, Forgejo, Bitbucket Server, ou tout simplement pour garder le contrôle), vous pouvez exécuter Renovate dans un conteneur Docker :

# Exécution ponctuelle de Renovate avec Docker
docker run --rm \
  -e RENOVATE_PLATFORM=gitea \
  -e RENOVATE_ENDPOINT=https://git.example.com \
  -e RENOVATE_TOKEN=your-api-token \
  -e RENOVATE_GIT_AUTHOR="Renovate Bot <renovate@example.com>" \
  -e LOG_LEVEL=info \
  renovate/renovate:latest \
  --autodiscover=true

# Ou pour des repos spécifiques
docker run --rm \
  -e RENOVATE_PLATFORM=github \
  -e RENOVATE_TOKEN=ghp_xxxxxxxxxxxx \
  renovate/renovate:latest \
  org/repo1 org/repo2

Option 4 : Self-hosted avec Docker Compose (production)

# docker-compose.yml pour Renovate self-hosted
version: "3.8"

services:
  renovate:
    image: renovate/renovate:38  # Version spécifique recommandée
    restart: "no"
    environment:
      - RENOVATE_PLATFORM=gitea
      - RENOVATE_ENDPOINT=https://git.example.com
      - RENOVATE_TOKEN=${RENOVATE_TOKEN}
      - RENOVATE_GIT_AUTHOR=Renovate Bot <renovate@example.com>
      - RENOVATE_AUTODISCOVER=true
      - RENOVATE_AUTODISCOVER_FILTER=myorg/*
      - LOG_LEVEL=info
      - RENOVATE_OPTIMIZE_FOR_DISABLED=true
      - RENOVATE_REPOSITORY_CACHE=enabled
      - RENOVATE_PERSIST_REPO_DATA=true
    volumes:
      # Cache pour accélérer les exécutions suivantes
      - renovate-cache:/tmp/renovate/cache
      # Configuration globale optionnelle
      - ./config.js:/usr/src/app/config.js:ro
    mem_limit: 2g
    cpus: 2

volumes:
  renovate-cache:

# Cron pour exécuter Renovate toutes les 2 heures
# Ajoutez dans crontab : crontab -e
0 */2 * * * cd /opt/renovate && docker compose run --rm renovate >> /var/log/renovate.log 2>&1

Option 5 : Kubernetes CronJob

# renovate-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: renovate
  namespace: ci
spec:
  schedule: "0 */3 * * *"  # Toutes les 3 heures
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: renovate
              image: renovate/renovate:38
              env:
                - name: RENOVATE_PLATFORM
                  value: "gitea"
                - name: RENOVATE_ENDPOINT
                  value: "https://git.example.com"
                - name: RENOVATE_TOKEN
                  valueFrom:
                    secretKeyRef:
                      name: renovate-secrets
                      key: token
                - name: RENOVATE_AUTODISCOVER
                  value: "true"
                - name: LOG_LEVEL
                  value: "info"
              resources:
                requests:
                  cpu: "500m"
                  memory: "1Gi"
                limits:
                  cpu: "2"
                  memory: "2Gi"
              volumeMounts:
                - name: cache
                  mountPath: /tmp/renovate/cache
          volumes:
            - name: cache
              persistentVolumeClaim:
                claimName: renovate-cache
          restartPolicy: Never
      backoffLimit: 3

Configuration de Renovate : le fichier renovate.json

La configuration de Renovate se fait principalement via un fichier renovate.json (ou .renovaterc.json, ou renovate.json5) à la racine de chaque dépôt. C'est le cœur du système et sa flexibilité est remarquable.

Configuration complète et commentée

Voici un fichier renovate.json5 complet pour un projet typique, couvrant toutes les fonctionnalités majeures :

// renovate.json5 — Configuration Renovate complète
// Documentation : https://docs.renovatebot.com/configuration-options/
{
  // === SCHEMA ===
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",

  // === PRESETS ===
  // Hériter de configurations prédéfinies communautaires
  "extends": [
    "config:recommended",           // Configuration recommandée par défaut
    ":dependencyDashboard",         // Active le dashboard (issue récapitulative)
    ":semanticCommits",             // Commit messages avec prefixes conventionnels
    ":separateMajorMinor",          // PRs séparées pour major vs minor
    "group:monorepos",              // Regroupe les packages de monorepos (ex: babel/*)
    "group:recommended",            // Regroupements recommandés
    "replacements:all",             // Applique les remplacements de packages dépréciés
    "workarounds:all",              // Contournements connus pour certains packages
    "security:openssf-scorecard",   // Affiche le score OpenSSF dans les PRs
    ":pinVersions"                  // Pin les versions (ex: ^1.2.3 → 1.2.3)
  ],

  // === LABELS ET ASSIGNEES ===
  // Labels ajoutés automatiquement aux PRs créées par Renovate
  "labels": ["dependencies", "automated"],
  // Assignees par défaut (optionnel)
  // "assignees": ["team-lead"],
  // Reviewers automatiques
  // "reviewers": ["team:devops"],

  // === SCHEDULING ===
  // Quand Renovate peut créer/mettre à jour des PRs
  "schedule": [
    "after 8am and before 6pm on monday through friday"
  ],
  // Fuseau horaire
  "timezone": "Europe/Paris",

  // === AUTOMERGE ===
  // Automerge global désactivé par défaut (activé par packageRules)
  "automerge": false,
  // Type d'automerge : "pr" (merge la PR) ou "branch" (push direct sans PR)
  "automergeType": "pr",
  // Stratégie de merge
  "automergeStrategy": "squash",
  // Nombre minimum de jours avant automerge (stabilisation)
  "minimumReleaseAge": "3 days",

  // === LIMITES ===
  // Nombre max de PRs ouvertes simultanément
  "prConcurrentLimit": 10,
  // Nombre max de PRs créées par heure
  "prHourlyLimit": 5,
  // Nombre max de branches créées par exécution
  "branchConcurrentLimit": 15,

  // === COMMIT ET PR ===
  // Prefix des branches
  "branchPrefix": "renovate/",
  // Template du titre des PRs
  "prTitle": "{{#if isPin}}pin{{else}}{{{depType}}}{{/if}}(deps): update {{{depName}}} to {{#if isPinDigest}}{{{newDigest}}}{{else}}{{#if isMajor}}v{{{newMajor}}}{{else}}{{{newValue}}}{{/if}}{{/if}}",
  // Body additionnel dans les PRs
  "prBodyNotes": [
    "⚠️ Veuillez vérifier les breaking changes avant de merger les mises à jour majeures.",
    "✅ Les mises à jour mineures et patch avec automerge activé seront mergées automatiquement si les tests passent."
  ],

  // === VULNERABILITY ALERTS ===
  // Traiter les alertes de vulnérabilité en priorité
  "vulnerabilityAlerts": {
    "labels": ["security", "priority-high"],
    "automerge": true,
    "minimumReleaseAge": "0 days",
    "schedule": ["at any time"],
    "prPriority": 10
  },

  // === PACKAGE RULES ===
  // Règles spécifiques par type de dépendance
  "packageRules": [
    // --- Automerge pour les mises à jour mineures et patch ---
    {
      "description": "Automerge minor et patch pour les dépendances de production",
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true,
      "automergeType": "pr",
      "minimumReleaseAge": "3 days"
    },

    // --- Automerge immédiat pour les devDependencies (patch) ---
    {
      "description": "Automerge immédiat pour les devDependencies (patch)",
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["patch"],
      "automerge": true,
      "automergeType": "branch",
      "minimumReleaseAge": "1 day"
    },

    // --- Regrouper les types (@types/*) ---
    {
      "description": "Regrouper toutes les mises à jour @types/*",
      "matchPackagePatterns": ["^@types/"],
      "groupName": "TypeScript type definitions",
      "automerge": true
    },

    // --- Regrouper les mises à jour ESLint ---
    {
      "description": "Regrouper les mises à jour ESLint et plugins",
      "matchPackagePatterns": ["^eslint", "^@typescript-eslint/"],
      "groupName": "ESLint and plugins",
      "automerge": true,
      "matchUpdateTypes": ["minor", "patch"]
    },

    // --- Docker : regrouper les mises à jour de digest ---
    {
      "description": "Automerge les mises à jour de digest Docker",
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["digest"],
      "automerge": true,
      "automergeType": "branch"
    },

    // --- Terraform providers : grouper les mineurs ---
    {
      "description": "Regrouper les Terraform providers (minor/patch)",
      "matchDatasources": ["terraform-provider"],
      "matchUpdateTypes": ["minor", "patch"],
      "groupName": "Terraform providers",
      "automerge": true
    },

    // --- GitHub Actions : automerge minor/patch ---
    {
      "description": "Automerge GitHub Actions (minor/patch)",
      "matchManagers": ["github-actions"],
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true,
      "automergeType": "branch"
    },

    // --- Helm charts : PR séparée pour chaque chart ---
    {
      "description": "Helm charts : PRs séparées, pas d'automerge",
      "matchDatasources": ["helm"],
      "automerge": false,
      "labels": ["helm", "infrastructure"]
    },

    // --- Ignorer certaines dépendances ---
    {
      "description": "Ignorer les mises à jour de aws-sdk v2 (en cours de migration v3)",
      "matchPackageNames": ["aws-sdk"],
      "enabled": false
    },

    // --- Pin une dépendance à une version spécifique ---
    {
      "description": "Pin Node.js à la version LTS 20.x",
      "matchPackageNames": ["node"],
      "matchDatasources": ["docker"],
      "allowedVersions": "20.x"
    },

    // --- Mises à jour majeures : labels et review obligatoire ---
    {
      "description": "Mises à jour majeures : review obligatoire",
      "matchUpdateTypes": ["major"],
      "labels": ["breaking-change", "needs-review"],
      "automerge": false,
      "prPriority": -1,
      "minimumReleaseAge": "7 days"
    },

    // --- Regrouper les mises à jour Go par module ---
    {
      "description": "Regrouper les modules Go",
      "matchDatasources": ["go"],
      "matchUpdateTypes": ["minor", "patch"],
      "groupName": "Go modules (minor/patch)",
      "automerge": true
    },

    // --- Python : regrouper les outils de dev ---
    {
      "description": "Regrouper les outils Python de dev",
      "matchPackageNames": ["black", "ruff", "mypy", "pytest", "pytest-cov", "isort"],
      "groupName": "Python dev tools",
      "automerge": true
    },

    // --- Ansible collections : review obligatoire ---
    {
      "description": "Ansible collections : review obligatoire",
      "matchManagers": ["ansible-galaxy"],
      "automerge": false,
      "labels": ["ansible", "infrastructure"]
    }
  ],

  // === REGEX MANAGERS ===
  // Détecter des versions dans des fichiers non standard
  "customManagers": [
    {
      "customType": "regex",
      "description": "Détecter les versions dans les variables d'environnement (.env)",
      "fileMatch": ["(^|/)?\\.env$", "(^|/)?docker-compose\\.ya?ml$"],
      "matchStrings": [
        "# renovate: datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?\\n.*?[:=]\\s*[\"']?(?[^\"'\\s]+)[\"']?"
      ],
      "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}"
    },
    {
      "customType": "regex",
      "description": "Détecter les versions d'outils dans Makefile",
      "fileMatch": ["(^|/)Makefile$"],
      "matchStrings": [
        "# renovate: datasource=(?.*?) depName=(?.*?)\\n.*?_VERSION\\s*[:?]?=\\s*(?.+)"
      ]
    },
    {
      "customType": "regex",
      "description": "Détecter les versions dans les scripts shell",
      "fileMatch": ["\\.sh$"],
      "matchStrings": [
        "# renovate: datasource=(?.*?) depName=(?.*?)\\n.*?VERSION=(?[^\\s\"']+)"
      ]
    }
  ],

  // === POST-UPGRADE TASKS ===
  // Commandes à exécuter après une mise à jour
  "postUpgradeTasks": {
    "commands": [
      "npm install --package-lock-only --ignore-scripts"
    ],
    "fileFilters": ["package-lock.json"],
    "executionMode": "branch"
  },

  // === LOCK FILE MAINTENANCE ===
  // Rafraîchir périodiquement les lock files
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["before 5am on monday"],
    "automerge": true,
    "automergeType": "branch"
  },

  // === DEPENDENCY DASHBOARD ===
  // Configuration de l'issue de dashboard
  "dependencyDashboard": true,
  "dependencyDashboardTitle": "🔄 Renovate Dashboard",
  "dependencyDashboardLabels": ["renovate", "dashboard"],
  "dependencyDashboardOSVVulnerabilitySummary": "all"
}

Les presets : réutiliser et partager la configuration

Presets communautaires

Renovate propose un système de presets qui permet de réutiliser des configurations. Les presets communautaires les plus utilisés sont :

• config:recommended : la configuration recommandée (inclut la séparation major/minor, les regroupements de monorepos, etc.)
• config:best-practices : un preset encore plus opinionné avec des bonnes pratiques strictes
• :pinVersions : pin toutes les versions (remplace ^1.2.3 par 1.2.3)
• :preserveSemverRanges : conserver les ranges semver existantes
• :semanticCommits : messages de commit conventionnels
• :automergeMinor : automerge les mises à jour mineures
• :automergePatch : automerge les mises à jour patch
• :dependencyDashboard : activer l'issue dashboard
• group:monorepos : regrouper les packages de monorepos
• group:recommended : regroupements recommandés
• replacements:all : remplacements automatiques de packages dépréciés
• workarounds:all : contournements de bugs connus
• docker:enableMajor : activer les mises à jour majeures pour Docker
• helpers:pinGitHubActionDigests : pin les GitHub Actions par digest SHA

Presets privés (organisation)

Vous pouvez créer vos propres presets dans un dépôt dédié et les partager au sein de votre organisation. C'est extrêmement puissant pour uniformiser la configuration Renovate à travers des dizaines ou centaines de dépôts :

# Créez un repo "renovate-config" dans votre org
# Avec un fichier default.json à la racine

# default.json dans le repo myorg/renovate-config
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    ":dependencyDashboard",
    ":semanticCommits",
    "group:monorepos",
    "group:recommended"
  ],
  "timezone": "Europe/Paris",
  "schedule": ["after 9am and before 5pm every weekday"],
  "labels": ["dependencies"],
  "prConcurrentLimit": 10,
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true,
      "minimumReleaseAge": "3 days"
    },
    {
      "matchUpdateTypes": ["major"],
      "labels": ["breaking-change"],
      "automerge": false
    }
  ]
}

# Puis dans chaque repo de l'org, le renovate.json est simplement :
# {
#   "extends": ["local>myorg/renovate-config"]
# }
# ou pour GitHub :
# {
#   "extends": ["github>myorg/renovate-config"]
# }

Support étendu des gestionnaires de paquets

L'un des atouts majeurs de Renovate est son support extrêmement large des gestionnaires de paquets. En 2025, Renovate supporte plus de 80 managers. Voici les principaux par écosystème :

JavaScript / TypeScript

• npm : package.json, package-lock.json
• Yarn : yarn.lock (v1, v2, v3, v4)
• pnpm : pnpm-lock.yaml
• Bun : bun.lockb

Python

• pip : requirements.txt, requirements/*.txt
• Pipenv : Pipfile, Pipfile.lock
• Poetry : pyproject.toml (section tool.poetry)
• PDM : pyproject.toml (section project.dependencies)
• pip-compile : *.in files
• setup.py / setup.cfg

Conteneurs et infrastructure

• Docker : Dockerfile, docker-compose.yml
• Helm : Chart.yaml, values.yaml
• Kubernetes : manifests YAML (images)
• Terraform : .tf files (providers, modules)
• Ansible : requirements.yml (collections et roles)
• Kustomize : kustomization.yaml
• ArgoCD : Application manifests
• Flux : HelmRelease, GitRepository

Go, Rust, Java et autres

• Go : go.mod, go.sum
• Cargo (Rust) : Cargo.toml, Cargo.lock
• Maven : pom.xml
• Gradle : build.gradle, build.gradle.kts, libs.versions.toml
• NuGet (.NET) : *.csproj, packages.config
• Composer (PHP) : composer.json
• Bundler (Ruby) : Gemfile, Gemfile.lock
• Mix (Elixir) : mix.exs

CI/CD et autres

• GitHub Actions : .github/workflows/*.yml
• GitLab CI : .gitlab-ci.yml
• CircleCI : .circleci/config.yml
• Nix : flake.nix, flake.lock
• Bazel : WORKSPACE, MODULE.bazel
• Pre-commit : .pre-commit-config.yaml

Le regex manager : détecter n'importe quelle version

Parfois, les versions de dépendances se trouvent dans des fichiers non standard : variables d'environnement, Makefiles, scripts d'installation, fichiers de configuration propriétaires. Le regex manager (customManagers) permet de détecter ces versions avec des expressions régulières.

L'astuce repose sur des commentaires annotés dans vos fichiers :

# Dans un Makefile
# renovate: datasource=github-releases depName=kubernetes-sigs/kustomize
KUSTOMIZE_VERSION := 5.4.3

# renovate: datasource=github-releases depName=helm/helm
HELM_VERSION := 3.16.3

# renovate: datasource=docker depName=postgres
POSTGRES_VERSION := 16.4

# Dans un .env
# renovate: datasource=github-releases depName=traefik/traefik
TRAEFIK_VERSION=v3.2.1

# renovate: datasource=npm depName=typescript
TYPESCRIPT_VERSION=5.6.3

# Dans un script shell (install.sh)
#!/bin/bash
# renovate: datasource=github-releases depName=argoproj/argo-cd
ARGOCD_VERSION=2.13.2

# renovate: datasource=github-releases depName=derailed/k9s
K9S_VERSION=0.32.7

Avec les regex managers configurés (voir la section renovate.json plus haut), Renovate détectera automatiquement ces versions et créera des PRs pour les mettre à jour.

Automerge : la mise à jour automatique

L'automerge est la fonctionnalité qui transforme Renovate d'un outil de notification en un outil de mise à jour véritablement automatique. Quand l'automerge est activé pour une mise à jour et que les conditions sont remplies (tests verts, délai de stabilisation respecté), Renovate merge automatiquement la PR.

Stratégies d'automerge

• automergeType: "pr" : Renovate crée une PR, attend que les checks CI passent, puis merge. C'est la stratégie recommandée car elle laisse une trace dans l'historique et permet la review si nécessaire
• automergeType: "branch" : Renovate push directement la mise à jour sur une branche et la merge sans créer de PR. Plus rapide, mais moins de visibilité. Utile pour les mises à jour très mineures (digest Docker, patch de devDependencies)

Bonnes pratiques pour l'automerge

1. Tests solides obligatoires : l'automerge ne fonctionne que si votre suite de tests est fiable. Des tests flaky qui échouent aléatoirement bloqueront l'automerge
2. Commencez conservativement : activez l'automerge uniquement pour les patches au début, puis étendez aux mineurs une fois la confiance établie
3. Utilisez minimumReleaseAge : attendez 3-7 jours avant d'automerger, le temps que la communauté détecte d'éventuels problèmes dans la nouvelle version
4. Jamais d'automerge pour les majeurs : les mises à jour majeures contiennent des breaking changes par définition et nécessitent toujours une review humaine
5. Monitoring des automerges : surveillez les déploiements post-automerge pour détecter rapidement les régressions

Grouping : regrouper les mises à jour

Par défaut, Renovate crée une PR par dépendance et par type de mise à jour. Cela peut générer beaucoup de PRs. Le grouping permet de regrouper les mises à jour liées dans une seule PR :

// Exemples de regroupement dans renovate.json5
{
  "packageRules": [
    // Regrouper tout l'écosystème React
    {
      "groupName": "React ecosystem",
      "matchPackagePatterns": ["^react", "^@types/react"],
      "matchUpdateTypes": ["minor", "patch"]
    },

    // Regrouper toutes les mises à jour non-majeures en une seule PR
    // (approche agressive, pour les projets avec bons tests)
    {
      "groupName": "all non-major dependencies",
      "groupSlug": "all-minor-patch",
      "matchUpdateTypes": ["minor", "patch"],
      "matchPackagePatterns": ["*"]
    },

    // Regrouper par type de mise à jour
    {
      "groupName": "all patch updates",
      "matchUpdateTypes": ["patch"]
    },

    // Regrouper les outils de lint
    {
      "groupName": "linting tools",
      "matchPackageNames": [
        "eslint", "prettier", "stylelint",
        "ruff", "black", "isort", "mypy"
      ],
      "matchPackagePatterns": [
        "^eslint-", "^@typescript-eslint/", "^prettier-"
      ]
    },

    // Regrouper les dépendances Kubernetes (Helm charts)
    {
      "groupName": "Kubernetes Helm charts",
      "matchDatasources": ["helm"],
      "matchUpdateTypes": ["minor", "patch"]
    }
  ]
}

Scheduling : contrôler le timing

Le scheduling permet de contrôler quand Renovate crée et met à jour les PRs. C'est essentiel pour éviter de perturber les développeurs pendant les heures de travail critique, ou pour concentrer les mises à jour sur des fenêtres de maintenance :

// Exemples de schedules
{
  // Seulement pendant les heures de bureau en semaine
  "schedule": ["after 9am and before 5pm every weekday"],
  "timezone": "Europe/Paris",

  // Ou : le lundi matin uniquement
  // "schedule": ["after 8am and before 12pm on monday"],

  // Ou : la nuit du dimanche au lundi (fenêtre de maintenance)
  // "schedule": ["after 10pm on sunday and before 6am on monday"],

  // Ou : combinaison de cron expressions
  // "schedule": ["* 8-17 * * 1-5"],  // 8h-17h, lundi-vendredi

  // Schedules spécifiques par type de dépendance
  "packageRules": [
    {
      "description": "Mises à jour Docker uniquement le week-end",
      "matchDatasources": ["docker"],
      "schedule": ["after 10pm on friday and before 6am on monday"]
    },
    {
      "description": "Mises à jour Terraform uniquement le mercredi",
      "matchDatasources": ["terraform-provider", "terraform-module"],
      "schedule": ["on wednesday"]
    }
  ]
}

Intégration avec Forgejo et Gitea

Renovate supporte nativement Gitea et Forgejo, ce qui est précieux pour les entreprises et organisations qui auto-hébergent leur forge logicielle. La configuration est similaire à GitHub/GitLab, avec quelques spécificités :

# Configuration self-hosted pour Forgejo/Gitea
# config.js (fichier de configuration global du runner Renovate)
module.exports = {
  platform: 'gitea',
  endpoint: 'https://git.example.com/api/v1/',
  token: process.env.RENOVATE_TOKEN,
  gitAuthor: 'Renovate Bot <renovate@example.com>',

  // Autodiscovery : scanner tous les repos de l'organisation
  autodiscover: true,
  autodiscoverFilter: ['myorg/*'],

  // Optimisations pour les grandes instances
  optimizeForDisabled: true,       // Skip rapidement les repos sans config Renovate
  repositoryCache: 'enabled',       // Cache les métadonnées des repos
  persistRepoData: true,            // Persiste le clone entre les runs

  // Gitea/Forgejo spécifique
  // Utiliser les labels existants (les créer si nécessaire)
  labels: ['dependencies'],

  // Rate limiting pour ne pas surcharger l'instance
  prHourlyLimit: 3,
  prConcurrentLimit: 5,

  // Configuration par défaut pour tous les repos
  onboarding: true,
  onboardingConfig: {
    extends: ['config:recommended', ':dependencyDashboard'],
    schedule: ['after 9am and before 6pm every weekday'],
    timezone: 'Europe/Paris',
    labels: ['dependencies'],
    automerge: false,
  },
};

# Lancer Renovate pour Forgejo
docker run --rm \
  -v $(pwd)/config.js:/usr/src/app/config.js:ro \
  -e RENOVATE_TOKEN=your-forgejo-api-token \
  -e LOG_LEVEL=info \
  renovate/renovate:latest

# Ou avec un token depuis un fichier
docker run --rm \
  -v $(pwd)/config.js:/usr/src/app/config.js:ro \
  -e RENOVATE_TOKEN=$(cat /run/secrets/renovate-token) \
  renovate/renovate:latest

Le Dependency Dashboard

Le Dependency Dashboard est une issue GitHub/GitLab/Gitea créée et maintenue automatiquement par Renovate dans chaque dépôt. Cette issue sert de tableau de bord centralisé pour toutes les mises à jour :

• Mises à jour en attente : liste des PRs ouvertes avec leur état
• Mises à jour disponibles : nouvelles versions détectées mais pas encore traitées (en attente de schedule, limites de rate, etc.)
• Mises à jour ignorées : dépendances désactivées ou avec des versions contraintes
• Alertes de vulnérabilité : CVEs détectées dans les dépendances actuelles
• Actions manuelles : cocher une case dans le dashboard pour forcer la création d'une PR ou relancer une mise à jour échouée

Le dashboard est particulièrement utile pour les tech leads et les responsables sécurité qui veulent avoir une vue d'ensemble de l'état des dépendances sans naviguer dans chaque PR individuellement.

Changelogs automatiques

L'une des forces de Renovate est la richesse des informations incluses dans chaque PR. Pour chaque mise à jour, Renovate inclut automatiquement :

• Release notes : extraites depuis GitHub Releases, CHANGELOG.md, ou les tags du dépôt source
• Comparaison de versions : lien direct vers le diff entre l'ancienne et la nouvelle version sur GitHub/GitLab
• Historique des commits : liste des commits entre les deux versions
• Score de confiance : basé sur l'âge de la version, le nombre de téléchargements, et le score OpenSSF
• Informations de sécurité : CVEs corrigées dans la nouvelle version

Ces informations permettent aux reviewers de prendre des décisions éclairées rapidement, sans avoir à rechercher manuellement les changements.

Cas d'usage en entreprise

Monorepo avec multiples technologies

Dans un monorepo contenant du JavaScript (frontend), du Python (API), du Go (microservices), et de l'infrastructure Terraform, Renovate gère simultanément toutes les dépendances avec des règles spécifiques par chemin :

// renovate.json5 pour un monorepo
{
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "description": "Frontend React : automerge minor/patch",
      "matchFileNames": ["frontend/**"],
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true,
      "groupName": "frontend dependencies"
    },
    {
      "description": "API Python : grouper par type",
      "matchFileNames": ["api/**"],
      "matchUpdateTypes": ["minor", "patch"],
      "groupName": "api dependencies"
    },
    {
      "description": "Infrastructure Terraform : review obligatoire",
      "matchFileNames": ["infra/**"],
      "matchManagers": ["terraform"],
      "automerge": false,
      "reviewers": ["team:platform"],
      "labels": ["infrastructure", "needs-review"]
    },
    {
      "description": "Microservices Go : automerge patch uniquement",
      "matchFileNames": ["services/**"],
      "matchManagers": ["gomod"],
      "matchUpdateTypes": ["patch"],
      "automerge": true
    }
  ]
}

Politique de sécurité stricte

Pour les environnements réglementés (finance, santé, gouvernement), Renovate peut être configuré pour appliquer des politiques strictes :

// renovate.json5 pour un environnement réglementé
{
  "extends": [
    "config:recommended",
    ":pinVersions",
    "helpers:pinGitHubActionDigests"
  ],
  // Jamais d'automerge
  "automerge": false,
  // Attendre 14 jours avant de proposer une mise à jour
  "minimumReleaseAge": "14 days",
  // Maximum 3 PRs ouvertes
  "prConcurrentLimit": 3,
  // Seulement pendant les fenêtres de maintenance
  "schedule": ["after 6pm on thursday and before 6am on friday"],
  "timezone": "Europe/Paris",
  // Review obligatoire
  "reviewers": ["team:security"],
  "labels": ["dependencies", "security-review-required"],
  // Alertes de vulnérabilité : priorité maximale
  "vulnerabilityAlerts": {
    "labels": ["security", "critical"],
    "schedule": ["at any time"],
    "minimumReleaseAge": "0 days",
    "reviewers": ["team:security", "team:leads"],
    "prPriority": 10
  },
  "packageRules": [
    {
      "description": "Interdire les versions pre-release",
      "matchUpdateTypes": ["major", "minor", "patch"],
      "ignoreUnstable": true
    }
  ]
}

Bonnes pratiques pour adopter Renovate

Phase 1 : Démarrage (semaine 1-2)

1. Installez Renovate sur un dépôt pilote, de préférence un projet non critique avec de bons tests
2. Acceptez la PR d'onboarding avec la configuration par défaut
3. Observez les PRs créées pendant une à deux semaines sans activer l'automerge
4. Vérifiez que les tests CI détectent les régressions introduites par les mises à jour

Phase 2 : Configuration (semaine 3-4)

1. Activez l'automerge pour les patches des dépendances de développement
2. Configurez le scheduling pour éviter de perturber les sprints
3. Définissez les groupements pour réduire le bruit
4. Ajoutez les regex managers pour les versions dans les fichiers non standard

Phase 3 : Déploiement large (mois 2-3)

1. Créez un preset partagé pour votre organisation
2. Déployez sur tous les dépôts avec autodiscover
3. Étendez l'automerge aux mises à jour mineures avec minimumReleaseAge
4. Formez l'équipe aux conventions Renovate (labels, dashboard, etc.)

Phase 4 : Optimisation continue

1. Analysez les métriques : combien de PRs automerged vs manuelles, temps moyen de merge, taux de régression
2. Ajustez les packageRules en fonction des retours d'expérience
3. Automatisez davantage : post-upgrade tasks, lock file maintenance
4. Intégrez avec vos outils : Slack notifications, Jira tickets, etc.

Dépannage et astuces

Debug et logs

# Activer les logs détaillés
docker run --rm \
  -e LOG_LEVEL=debug \
  -e RENOVATE_TOKEN=xxx \
  renovate/renovate:latest myorg/myrepo

# Dry run (simule sans créer de PRs)
docker run --rm \
  -e LOG_LEVEL=debug \
  -e RENOVATE_TOKEN=xxx \
  -e RENOVATE_DRY_RUN=full \
  renovate/renovate:latest myorg/myrepo

# Vérifier la configuration
npx renovate-config-validator renovate.json

Problèmes courants

• Trop de PRs : utilisez le grouping, réduisez prConcurrentLimit, et activez l'automerge
• PRs ignorées par l'équipe : configurez des assignees, des reviewers, et utilisez le dependency dashboard pour sensibiliser
• Automerge qui ne se déclenche pas : vérifiez que les status checks sont configurés comme required dans les branch protection rules
• Mises à jour cassantes automerged : augmentez minimumReleaseAge, améliorez la couverture de tests, désactivez l'automerge pour les packages problématiques
• Rate limiting de l'API : augmentez les intervalles entre les runs, utilisez optimizeForDisabled, activez le cache

Alternatives à Renovate

Bien que Renovate soit le choix recommandé pour la majorité des cas, il est utile de connaître les alternatives :

• Dependabot : intégré à GitHub, plus simple mais moins flexible (voir comparaison détaillée plus haut)
• Snyk : orienté sécurité d'abord, propose des mises à jour de dépendances comme fonctionnalité secondaire. Payant pour les fonctionnalités avancées
• Socket.dev : analyse la sécurité de la chaîne d'approvisionnement logicielle, complémentaire à Renovate
• WhiteSource/Mend.io : solution entreprise complète (Mend.io est l'entreprise derrière Renovate)
• Updatecli : outil open source de mise à jour déclaratif, plus orienté infrastructure

L'avenir de Renovate

En 2025-2026, Renovate continue d'évoluer rapidement :

• Nouveaux managers : support continu de nouveaux gestionnaires de paquets et formats de fichiers
• Merge confidence : Renovate affiche un score de confiance basé sur les données d'adoption communautaire d'une version
• Intégration OpenSSF Scorecard : affichage du score de sécurité des dépendances dans les PRs
• Amélioration de la détection de vulnérabilités : intégration avec OSV (Open Source Vulnerabilities) pour une couverture élargie
• Performance : optimisations continues pour les grandes organisations avec des milliers de dépôts
• Intelligence artificielle : analyse prédictive des risques de breaking changes basée sur l'historique des mises à jour communautaires

Conclusion

La gestion des dépendances est un problème résolu — à condition d'utiliser les bons outils. Renovate transforme une tâche manuelle, fastidieuse et souvent négligée en un processus automatisé, fiable et transparent. Avec sa flexibilité de configuration, son support étendu de gestionnaires de paquets, et ses fonctionnalités avancées comme l'automerge, le grouping et les regex managers, il s'adapte à tous les contextes, du projet personnel au monorepo d'entreprise.

Les bénéfices sont tangibles et immédiats :

• Réduction des vulnérabilités : les patchs de sécurité sont appliqués en jours plutôt qu'en mois
• Moins de dette technique : les dépendances restent à jour, les migrations majeures sont progressives
• Gain de temps développeur : les mises à jour mineures/patch sont automerged, les développeurs se concentrent sur les breaking changes
• Visibilité : le dependency dashboard offre une vue d'ensemble de l'état de santé des dépendances
• Standardisation : les presets partagés assurent une politique cohérente à travers l'organisation

Si vous ne l'avez pas encore fait, installez Renovate aujourd'hui sur un dépôt pilote. La PR d'onboarding sera créée en quelques minutes, et vous pourrez commencer à bénéficier de mises à jour automatiques dès la première heure. La dette technique de vos dépendances n'a que trop duré.

Pour aller plus loin : la documentation officielle de Renovate (docs.renovatebot.com) est exceptionnellement complète et bien structurée. Le dépôt GitHub contient de nombreux exemples et discussions. Et le forum de discussions est actif et accueillant pour les questions.