Renovate : automatiser les mises à jour

Renovate automatise les mises à jour de vos dépendances logicielles en créant des Pull Requests testables, traçables et fusionnables. Ce guide vous apprend à l’installer, le configurer et le sécuriser. Vous saurez adapter les stratégies de mise à jour à votre projet (scheduling, automerge, regroupement) et durcir votre installation contre les attaques supply chain. Prérequis : Node.js 20+ installé et un accès à un dépôt Git (GitHub, GitLab, Bitbucket ou autre).

Qu’est-ce que Renovate ?

Imaginez un assistant qui surveille en permanence toutes les bibliothèques de votre projet, vérifie si des versions plus récentes sont disponibles, et vous prépare une mise à jour testée automatiquement, prête à fusionner. C’est exactement ce que fait Renovate.

Renovate est un outil open source (licence AGPL) maintenu par Mend.io. Il analyse vos fichiers de dépendances (package.json, Dockerfile, docker-compose.yml, requirements.txt, go.mod, pom.xml, fichiers Terraform, playbooks Ansible, GitHub Actions, et bien d’autres), détecte les versions obsolètes, et crée automatiquement des Pull Requests (PR) avec les mises à jour correspondantes.

Sans Renovate	Avec Renovate
Vérification manuelle des versions	Détection automatique des mises à jour
Risque d’oublier des dépendances	Couverture exhaustive de tous les fichiers
Pas de traçabilité des décisions	Historique complet dans les PR
Vulnérabilités non détectées pendant des semaines	Alerte dès la publication d’un correctif

Renovate supporte plus de 90 gestionnaires de paquets (appelés managers) couvrant la quasi-totalité des écosystèmes : JavaScript (npm, Yarn, pnpm), Python (pip, Poetry, Pipenv), Java (Maven, Gradle), Go, Rust, Ruby, .NET, PHP, Helm, Terraform, Ansible, Docker, GitHub Actions, et bien d’autres encore.

Prérequis

Avant de commencer, vérifiez que vous disposez de :

Node.js 20 ou supérieur — Renovate s’installe via npm. Vérifiez avec node -v.
Un dépôt Git hébergé sur GitHub, GitLab, Bitbucket, Azure DevOps, Forgejo ou Gitea.
Un Personal Access Token (PAT) avec les droits nécessaires sur votre plateforme (détaillés plus bas).
Connaissances de base en Git — savoir ce qu’est une branche et une Pull Request.

Comment fonctionne Renovate

Comprendre le fonctionnement interne de Renovate permet de mieux le configurer. À chaque exécution, Renovate suit cinq phases :

Phase 1 — Initialisation. Renovate clone le dépôt, lit la configuration (renovate.json) et résout les presets étendus. Il vérifie si le dépôt est déjà onboardé (c’est-à-dire s’il possède un fichier de configuration).

Phase 2 — Extraction des dépendances. Les managers parcourent les fichiers du projet pour identifier toutes les dépendances déclarées. Chaque manager sait lire un format spécifique : le manager npm lit package.json, le manager dockerfile lit les instructions FROM, le manager terraform lit les blocs required_providers, et ainsi de suite.

Phase 3 — Recherche des mises à jour. Pour chaque dépendance extraite, Renovate interroge la datasource correspondante (le registre npm, Docker Hub, PyPI, etc.) pour trouver les versions disponibles. Il compare la version actuelle avec les versions publiées et détermine les mises à jour applicables.

Phase 4 — Écriture des mises à jour. Renovate génère les modifications nécessaires : il crée des branches, met à jour les fichiers de dépendance (y compris les fichiers lock), et ouvre les Pull Requests sur la plateforme.

Phase 5 — Finalisation. Renovate met à jour le Dependency Dashboard (s’il est activé), gère l’automerge des PR qui ont passé les tests, et nettoie les branches obsolètes.

Installation et première exécution

Installer Renovate globalement

Ouvrez un terminal et installez le paquet npm :
Fenêtre de terminal
```
npm install -g renovate
```
Vérification : exécutez renovate --version. Vous devez voir un numéro de version (par exemple 39.264.1).
Créer les Personal Access Tokens

Renovate a besoin de deux tokens pour fonctionner :
- GitHub
- GitLab
- GITHUB_COM_TOKEN : un PAT classic sur github.com avec le scope public_repo. Sert à récupérer les changelogs et éviter les limites d’API.
- RENOVATE_TOKEN : un PAT avec les scopes repo et workflow sur le dépôt cible.
- GITHUB_COM_TOKEN : même token GitHub que ci-dessus (pour les changelogs).
- RENOVATE_TOKEN : un PAT GitLab avec les droits api, write_repository et read_registry.
Exportez les tokens dans votre terminal :
Fenêtre de terminal
```
export GITHUB_COM_TOKEN="ghp_votre_token_github"
export RENOVATE_TOKEN="votre_token_plateforme"
```
N’ajoutez jamais de tokens dans vos fichiers de configuration versionnés. Utilisez des variables d’environnement ou un gestionnaire de secrets.
Créer le fichier de configuration

À la racine de votre dépôt, créez un fichier renovate.json :
```
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"]
}
```
Le preset config:recommended active les paramètres recommandés par l’équipe Renovate : regroupement des mises à jour non majeures par monorepo, limitation des PR concurrentes, et activation du Dependency Dashboard.
Lancer un dry-run local

Avant de lancer Renovate sur un vrai dépôt, testez-le en mode local pour voir ce qu’il détecte sans créer de branches ni de PR :
Fenêtre de terminal
```
LOG_LEVEL=debug renovate --platform=local --dry-run=lookup
```
Ce mode analyse le répertoire courant, identifie les dépendances et les mises à jour disponibles, puis s’arrête sans modifier quoi que ce soit. Parcourez les logs pour vérifier que Renovate détecte bien vos fichiers.
Exécuter Renovate sur un dépôt distant

Une fois satisfait du dry-run, lancez Renovate sur un vrai dépôt :
Fenêtre de terminal
```
renovate --platform=github votre-org/votre-repo
```
Ou pour GitLab :
Fenêtre de terminal
```
renovate --platform=gitlab --endpoint=https://gitlab.com/api/v4 votre-org/votre-repo
```
Lors de la première exécution, Renovate crée une PR d’onboarding qui propose un fichier renovate.json. Fusionnez cette PR pour activer Renovate sur votre dépôt.

Si vous préférez ne pas installer Node.js, utilisez l’image Docker officielle :

docker run --rm \
  -e RENOVATE_TOKEN \
  -e GITHUB_COM_TOKEN \
  renovate/renovate \
  --platform=github votre-org/votre-repo

L’image par défaut télécharge les outils nécessaires à la volée. L’image -full embarque tous les gestionnaires pré-installés mais pèse plusieurs gigaoctets.

Configuration de base

Les fichiers de configuration

Renovate cherche sa configuration dans l’un de ces fichiers, par ordre de priorité :

Fichier	Format
`renovate.json`	JSON standard
`renovate.json5`	JSON5 (commentaires autorisés)
`.renovaterc`	JSON ou JSON5
`.renovaterc.json`	JSON
`renovate` section dans `package.json`	JSON

En pratique, renovate.json est le choix le plus courant. Si vous préférez ajouter des commentaires pour documenter votre configuration, utilisez le format JSON5 avec renovate.json5.

Comprendre les presets

Les presets sont des configurations réutilisables. Au lieu de tout configurer manuellement, vous étendez un preset existant et ne surchargez que ce qui diffère. Pensez aux presets comme à des thèmes CSS : vous partez d’une base cohérente et vous ajustez les détails.

Les presets intégrés les plus courants :

Preset	Rôle
`config:recommended`	Configuration de base recommandée
`config:best-practices`	Recommandations renforcées (inclut `minimumReleaseAge` pour npm)
`:dependencyDashboard`	Active le tableau de bord des dépendances (inclus dans `config:recommended`)
`schedule:nonOfficeHours`	Limite les mises à jour en dehors des heures de bureau
`group:allNonMajor`	Regroupe toutes les mises à jour mineures et patches en une seule PR
`:automergeDigest`	Automerge les mises à jour de digests Docker

Voici un exemple combinant plusieurs presets :

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "schedule:nonOfficeHours",
    ":automergeDigest"
  ]
}

Stratégies de mise à jour

Versionnement sémantique (SemVer)

La majorité des écosystèmes suivent la convention SemVer : MAJEURE.MINEURE.PATCH. Chaque type de mise à jour porte un risque différent :

Patch (ex : 1.2.3 → 1.2.4) : correctifs de bugs. Risque très faible.
Minor (ex : 1.2.3 → 1.3.0) : nouvelles fonctionnalités rétrocompatibles. Risque faible.
Major (ex : 1.2.3 → 2.0.0) : changements pouvant casser la rétrocompatibilité. Risque élevé.

Renovate distingue ces trois types et permet de configurer un comportement différent pour chacun. Le preset config:recommended sépare automatiquement les mises à jour majeures des autres.

Adapter la stratégie par type de mise à jour

Voici une configuration typique qui fusionne automatiquement les patches et mineures tout en gardant les majeures pour une revue manuelle :

{
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "description": "Automerge patches et mineures (hors v0.x)",
      "matchUpdateTypes": ["minor", "patch"],
      "matchCurrentVersion": "!/^0/",
      "automerge": true
    }
  ]
}

La condition matchCurrentVersion: "!/^0/" exclut les paquets en version 0.x, car le SemVer autorise des changements cassants sur toute mise à jour avant la version 1.0.0.

La stratégie de range

L’option rangeStrategy contrôle comment Renovate modifie les contraintes de version dans vos fichiers. Les valeurs possibles sont :

Stratégie	Comportement	Usage typique
`bump`	Augmente la borne inférieure (`^1.2.3` → `^1.3.0`)	Applications avec lock file
`replace`	Élargit le range si possible (`^1.2.3` → `^1.3.0` si compatible)	Bibliothèques publiées
`pin`	Fixe la version exactement (`^1.2.3` → `1.3.0`)	Reproductibilité maximale
`widen`	Élargit le range (`^1.2.3` → `^1.2.3 \|\| ^2.0.0`)	Bibliothèques supportant plusieurs majeures
`auto`	Laisse Renovate décider selon le contexte	Valeur par défaut

Pour un projet applicatif (non publié comme bibliothèque), la stratégie bump est généralement le meilleur choix car elle rend les mises à jour explicites dans le fichier lock.

Planifier les mises à jour

Par défaut, Renovate est “toujours actif” : il crée des PR dès qu’il trouve une mise à jour. Cela peut devenir bruyant sur des projets avec beaucoup de dépendances. L’option schedule permet de contrôler les fenêtres d’exécution.

Définir un fuseau horaire

Renovate utilise UTC par défaut. Pour utiliser votre heure locale, configurez le fuseau horaire avec un identifiant IANA :

{
  "timezone": "Europe/Paris"
}

Exemples de planification

Renovate recommande la syntaxe cron (5 champs) pour les schedules. L’astérisque * est obligatoire pour les minutes car Renovate ne supporte pas la granularité à la minute :

{
  "extends": ["config:recommended"],
  "timezone": "Europe/Paris",
  "schedule": ["* 0-4 * * 1-5", "* * * * 0,6"]
}

Cette configuration signifie : exécuter les mises à jour en semaine entre minuit et 5h, et à tout moment le week-end.

Autres exemples courants :

Besoin	Cron	Preset équivalent
En dehors des heures de bureau	`* 0-4,22-23 * * 1-5` + `* * * * 0,6`	`schedule:nonOfficeHours`
Uniquement le week-end	`* * * * 0,6`	`schedule:weekends`
Lundi matin avant 6h	`* 0-5 * * 1`	—
Trimestriel, le 1er du mois	`* * 1 /3 `	—

Limiter la fréquence pour un paquet spécifique

Certaines bibliothèques publient très souvent (AWS SDK, types TypeScript…). Vous pouvez leur appliquer un schedule dédié pour réduire le bruit :

{
  "packageRules": [
    {
      "description": "AWS SDK : mises à jour hebdomadaires uniquement",
      "matchPackageNames": ["@aws-sdk/**"],
      "schedule": ["* 21-23 * * 0"]
    }
  ]
}

Automerge : fusionner automatiquement

L’automerge permet à Renovate de fusionner une PR sans intervention humaine dès que les tests CI passent. Cette fonctionnalité est idéale pour les mises à jour à faible risque : patches de devDependencies, mises à jour de lock file, ou digests Docker.

Quand activer l’automerge

L’équipe Renovate recommande d’activer l’automerge pour toute mise à jour que vous fusionneriez systématiquement de toute façon. En pratique, cela concerne souvent :

Les devDependencies (linters, outils de test, formatters)
Les mises à jour mineures et patches sur des projets bien testés
La maintenance des lock files (rafraîchissement sans changement de version déclarée)
Les digests Docker (mise à jour du hash sans changement de tag)

Exemples de configuration automerge

Automerge des devDependencies linters :

{
  "packageRules": [
    {
      "description": "Automerge des outils de dev",
      "matchDepTypes": ["devDependencies"],
      "matchPackageNames": ["eslint", "prettier", "vitest"],
      "automerge": true
    }
  ]
}

Automerge de toutes les mises à jour non majeures :

{
  "packageRules": [
    {
      "description": "Automerge non-major hors v0.x",
      "matchUpdateTypes": ["minor", "patch"],
      "matchCurrentVersion": "!/^0/",
      "automerge": true
    }
  ]
}

Automerge de la maintenance du lock file :

{
  "lockFileMaintenance": {
    "enabled": true,
    "automerge": true,
    "schedule": ["* * * * 0"]
  }
}

Branch automerge vs PR automerge

Par défaut, Renovate crée une PR puis la fusionne via la plateforme (platformAutomerge). Vous pouvez configurer un mode plus silencieux avec automergeType: "branch" : Renovate crée uniquement une branche, et si les tests passent, il pousse directement le commit sur la branche cible sans créer de PR. Si les tests échouent, il crée alors une PR pour vous permettre d’investiguer.

{
  "automergeType": "branch"
}

Dependency Dashboard

Le Dependency Dashboard est un ticket (issue) que Renovate crée dans votre dépôt. Il sert de tableau de bord centralisé montrant l’état de toutes les mises à jour : en cours, en attente, fermées ou ignorées.

Le preset config:recommended active le Dashboard par défaut. Si vous souhaitez l’activer manuellement :

{
  "dependencyDashboard": true
}

Le Dashboard apporte trois fonctionnalités particulièrement utiles dans un contexte d’équipe.

Visibilité des mises à jour ignorées. Si quelqu’un ferme une PR Renovate sans la fusionner, la mise à jour apparaît dans la section “Closed/Ignored” du Dashboard. Vous pouvez la relancer d’un clic en cochant la case correspondante.

Workflow d’approbation. Pour les mises à jour sensibles, vous pouvez demander à Renovate d’attendre une approbation explicite avant de créer la PR. Cette approbation se fait en cochant une case dans le Dashboard :

{
  "major": {
    "dependencyDashboardApproval": true
  }
}

Avec cette configuration, les mises à jour majeures n’apparaissent que dans le Dashboard. Renovate ne crée la PR que lorsque vous cochez la case correspondante. Les mises à jour mineures et patches continuent normalement.

Détection d’abandon. Le preset config:best-practices inclut abandonments:recommended qui signale les paquets n’ayant publié aucune mise à jour depuis plus d’un an. Ces avertissements apparaissent en haut du Dashboard pour vous alerter de dépendances potentiellement abandonnées.

Configuration avancée

Les packageRules

Les packageRules sont le mécanisme central pour personnaliser le comportement de Renovate par dépendance, groupe de dépendances, type de mise à jour ou tout autre critère. Chaque règle est un objet avec des matchers (critères de sélection) et des options à appliquer.

Les matchers principaux :

Matcher	Rôle	Exemple
`matchPackageNames`	Nom du paquet (glob ou regex)	`["react", "@types/**"]`
`matchDepTypes`	Type de dépendance	`["devDependencies"]`
`matchUpdateTypes`	Type de mise à jour	`["major", "minor", "patch"]`
`matchDatasources`	Source de données	`["docker", "npm"]`
`matchFileNames`	Fichier source	`["docker-compose*.yml"]`
`matchManagers`	Gestionnaire de paquets	`["dockerfile", "helm-values"]`
`matchCurrentVersion`	Version actuelle (regex)	`"!/^0/"`

Voici un exemple complet combinant plusieurs règles :

{
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "description": "Regrouper les paquets React",
      "matchPackageNames": ["react", "react-dom", "@types/react"],
      "groupName": "react monorepo"
    },
    {
      "description": "Automerge les outils de lint",
      "matchPackageNames": ["eslint*", "prettier"],
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true
    },
    {
      "description": "Bloquer les mises à jour Node.js 22+",
      "matchPackageNames": ["node"],
      "matchUpdateTypes": ["major"],
      "enabled": false
    },
    {
      "description": "Limiter Terraform providers au week-end",
      "matchManagers": ["terraform"],
      "matchDatasources": ["terraform-provider"],
      "schedule": ["* * * * 0,6"]
    }
  ]
}

Les règles sont évaluées dans l’ordre : la dernière règle qui matche une dépendance a la priorité pour chaque option qu’elle définit.

Custom Managers

Les customManagers permettent à Renovate de détecter des dépendances dans des fichiers au format non standard. Renovate supporte deux types de custom managers : regex et jsonata.

Le type regex est le plus courant. Vous écrivez une expression régulière qui capture les informations nécessaires : depName, currentValue, et datasource.

Prenons un exemple concret : vous avez un script shell qui télécharge une image cloud Ubuntu, et vous voulez que Renovate détecte et mette à jour la version automatiquement.

Dans votre script download-ubuntu.sh :

# renovate: datasource=github-releases depName=canonical/cloud-init
CLOUD_INIT_VERSION="24.4"

Dans renovate.json :

{
  "customManagers": [
    {
      "customType": "regex",
      "fileMatch": ["\\.sh$"],
      "matchStrings": [
        "#\\s*renovate:\\s*datasource=(?<datasource>.*?)\\s+depName=(?<depName>.*?)\\n.*?VERSION=\"(?<currentValue>.*?)\""
      ]
    }
  ]
}

Le commentaire structuré # renovate: datasource=... depName=... dans le fichier source fournit le contexte nécessaire à la regex. Cette convention permet de rendre n’importe quel fichier “renovatable” sans changer le format.

Custom Datasources

Lorsque les versions d’un outil ne sont pas publiées sur un registre classique (npm, PyPI, Docker Hub…), vous pouvez créer une customDatasource qui interroge une URL personnalisée :

{
  "customDatasources": {
    "UbuntuCloudImages": {
      "defaultRegistryUrlTemplate": "https://cloud-images.ubuntu.com/releases/24.04/",
      "format": "html"
    }
  },
  "packageRules": [
    {
      "matchDatasources": ["custom.UbuntuCloudImages"],
      "extractVersion": "^release-(?<version>\\d+)/$"
    }
  ]
}

Les formats supportés sont json, plain, html et yaml. Le champ extractVersion utilise une regex pour extraire le numéro de version depuis le contenu retourné.

Regrouper les mises à jour

Par défaut, Renovate crée une PR distincte par dépendance. Sur un gros projet, cela peut générer des dizaines de PR. Le regroupement (groupName) rassemble plusieurs dépendances dans une seule PR :

{
  "packageRules": [
    {
      "description": "Regrouper toutes les dépendances AWS SDK",
      "matchPackageNames": ["@aws-sdk/**"],
      "groupName": "AWS SDK"
    },
    {
      "description": "Regrouper tous les non-major en une PR",
      "matchUpdateTypes": ["minor", "patch"],
      "groupName": "all non-major dependencies",
      "groupSlug": "all-minor-patch"
    }
  ]
}

Le preset group:allNonMajor fait exactement cela de manière concise :

{
  "extends": ["config:recommended", "group:allNonMajor"]
}

Limiter le nombre de PR

Pour éviter la surcharge, Renovate offre plusieurs limiteurs :

Option	Rôle	Valeur par défaut
`prConcurrentLimit`	Nombre max de PR ouvertes en parallèle	10
`prHourlyLimit`	Nombre max de PR créées par heure	2
`branchConcurrentLimit`	Nombre max de branches actives	10

{
  "prConcurrentLimit": 5,
  "prHourlyLimit": 1
}

Sécuriser Renovate

Renovate exécute du code provenant de vos dépôts (scripts d’installation, post- upgrade tasks). Sur une installation self-hosted partagée entre plusieurs équipes, une mauvaise configuration peut transformer Renovate en vecteur d’attaque supply chain. Cette section détaille les risques et les contre-mesures.

Risque 1 — Autodiscovery sans filtre

Lorsque autodiscover: true est activé sans restriction, Renovate traitera tous les dépôts auxquels le bot a accès. Sur GitLab, un attaquant peut inviter le bot dans un dépôt piégé (les invitations sont acceptées par défaut), et à la prochaine exécution, Renovate clone le dépôt malveillant et exécute ses scripts.

Par exemple, un dépôt Gradle piégé avec un gradlew modifié exécutera du code arbitraire lors de la phase de résolution des dépendances, car Renovate invoque le gestionnaire natif du langage.

Contre-mesure : toujours restreindre l’autodiscovery avec un filtre explicite :

{
  "autodiscover": true,
  "autodiscoverFilter": ["mon-org/frontend-*", "mon-org/backend-*"]
}

Ou mieux, utilisez une liste fixe de dépôts dans votre configuration globale self-hosted :

{
  "repositories": ["mon-org/app-web", "mon-org/api-backend"]
}

Risque 2 — Scripts d’installation et variables d’environnement

Deux options self-hosted sont particulièrement dangereuses si elles sont mal configurées :

allowScripts: true permet aux dépôts d’exécuter les scripts postinstall, prepare, etc. lors du npm install. Un paquet malveillant peut y placer du code arbitraire.
exposeAllEnv: true transmet toutes les variables d’environnement du processus Renovate aux sous-processus. Le token RENOVATE_TOKEN peut être exfiltré via un commit message crafté.

Contre-mesure : gardez les valeurs par défaut et configurez explicitement ce dont vous avez besoin :

{
  "allowScripts": false,
  "exposeAllEnv": false,
  "ignoreScripts": true,
  "allowedCommands": []
}

Si vous avez besoin d’un script post-upgrade spécifique, restreignez-le avec une regex stricte dans allowedCommands :

{
  "allowedCommands": ["^npm run lint:fix$", "^go mod tidy$"]
}

Risque 3 — Automerge sans délai de sécurité

Si l’automerge est activé sans période de cooldown, un paquet npm compromis peut être publié et mergé dans votre projet en quelques minutes, avant que quiconque ne détecte le problème. C’est ce qu’on appelle la fenêtre dorée (golden hour) de l’attaque supply chain.

Contre-mesure : activez minimumReleaseAge pour imposer un délai entre la publication d’une version et son adoption par Renovate :

{
  "extends": ["config:best-practices"],
  "minimumReleaseAge": "3 days"
}

Le preset config:best-practices inclut déjà un minimumReleaseAge de 3 jours pour l’écosystème npm. Vous pouvez l’ajuster par dépendance via les packageRules.

Risque 4 — Race condition sur l’automerge (GitLab)

Sur GitLab, un développeur malveillant avec un rôle developer peut ajouter un commit dans la branche d’une MR Renovate avant que le bot n’active l’automerge. Si le timing est bon, le commit non revu est fusionné automatiquement dans la branche protégée, contournant le principe de revue à quatre yeux.

Contre-mesure : configurez GitLab pour n’autoriser l’automerge que si la pipeline CI a été relancée après le dernier commit :

Activez les pipelines for merge results
Exigez que tous les jobs de la pipeline soient passés sur le dernier commit

Configuration self-hosted durcie complète

Pour une installation self-hosted sécurisée, combinez toutes les contre-mesures dans votre configuration globale (fichier config.js ou variables d’environnement) :

// config.js — configuration globale self-hosted durcie
module.exports = {
  platform: 'gitlab',
  endpoint: 'https://gitlab.example.com/api/v4',
  token: process.env.RENOVATE_TOKEN,

  // Restreindre les dépôts traités
  autodiscover: true,
  autodiscoverFilter: ['mon-org/frontend-*', 'mon-org/backend-*'],

  // Bloquer l'exécution de code arbitraire
  allowScripts: false,
  exposeAllEnv: false,
  allowedCommands: ['^npm run lint:fix$'],

  // Délai de sécurité
  extends: ['config:best-practices'],

  // Auditer les actions
  repositoryCache: 'enabled',
};

Exécuter Renovate en CI/CD

En production, Renovate est rarement lancé manuellement. Il est intégré dans un pipeline CI/CD qui l’exécute à intervalles réguliers (typiquement toutes les heures ou toutes les nuits).

GitHub Actions
GitLab CI/CD

Utilisez l’action officielle renovatebot/github-action :

name: Renovate
on:
  schedule:
    - cron: '0 */2 * * *'       # Toutes les 2 heures
  workflow_dispatch:
permissions: {}
jobs:
  renovate:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - uses: renovatebot/github-action@e084b5481e3a5381a3dd80bfaa41edfa886634f6 # v41.0.13
        with:
          configurationFile: renovate.json
          token: ${{ secrets.RENOVATE_TOKEN }}
        env:
          GITHUB_COM_TOKEN: ${{ secrets.GITHUB_COM_TOKEN }}

Ajoutez un job planifié dans votre .gitlab-ci.yml :

renovate:
  image: renovate/renovate:latest
  stage: maintenance
  variables:
    RENOVATE_TOKEN: $RENOVATE_TOKEN
    GITHUB_COM_TOKEN: $GITHUB_COM_TOKEN
    RENOVATE_PLATFORM: gitlab
    RENOVATE_ENDPOINT: $CI_API_V4_URL
    LOG_LEVEL: info
  script:
    - renovate $CI_PROJECT_PATH
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

Créez ensuite un schedule dans les paramètres CI/CD de GitLab pour déclencher ce pipeline toutes les heures ou selon vos besoins.

Dépannage

Symptôme	Cause probable	Solution
Renovate ne crée aucune PR	Dépôt pas encore onboardé	Fusionnez la PR d’onboarding, ou vérifiez que `renovate.json` existe
Automerge ne fonctionne pas	Branche protégée avec revues obligatoires	Configurez `platformAutomerge: true` et ajoutez le bot comme auteur autorisé
”Automerge: Disabled by config” dans la PR	Configuration automerge incorrecte	Vérifiez les packageRules : la dernière règle matchant a la priorité
PR créées puis fermées immédiatement	Rate limit atteinte ou fichier lock en conflit	Consultez les logs avec `LOG_LEVEL=debug`, vérifiez `prConcurrentLimit`
Fichier lock non mis à jour	Gestionnaire de paquets non trouvé	En self-hosted, vérifiez `binarySource` et que les outils sont installés
Dependency Dashboard non créé	Feature non supportée par la plateforme	Le Dashboard nécessite les issues Markdown (non supporté sur Bitbucket Server)
“Cannot find manager” dans les logs	Format de fichier non reconnu	Vérifiez le nom du fichier ou créez un `customManager`
PR trop nombreuses	Pas de schedule ni de limite configurée	Ajoutez `schedule`, `prConcurrentLimit` et envisagez `group:allNonMajor`

À retenir

Renovate automatise la création de PR pour mettre à jour vos dépendances, couvrant plus de 90 gestionnaires de paquets.
Les presets (config:recommended, config:best-practices) offrent une base solide sans configuration manuelle complexe.
L’automerge réduit la charge de travail pour les mises à jour à faible risque (patches, devDependencies, lock files), mais exigez toujours des tests CI qui passent.
Le Dependency Dashboard centralise la visibilité sur toutes les mises à jour et permet un workflow d’approbation pour les changements sensibles.
minimumReleaseAge est votre première ligne de défense contre les attaques supply chain : imposez un délai avant d’adopter une nouvelle version.
En self-hosted, ne jamais activer autodiscover sans filtre, ni allowScripts ou exposeAllEnv sans raison explicite.
Les packageRules permettent un contrôle granulaire : grouper, planifier, automerger ou bloquer par dépendance, manager ou type de mise à jour.

Prochaines étapes

Gestion des dépendances Fondamentaux de la gestion des dépendances logicielles

Dependabot : l'alternative GitHub Configurer Dependabot pour les projets GitHub

Sécuriser la supply chain Protéger votre chaîne d'approvisionnement logicielle

Risques Dependabot et Renovate 6 failles de configuration exploitables et leurs corrections

Expressions régulières Maîtriser les regex pour les customManagers Renovate

Pipelines CI/CD Intégrer Renovate dans votre pipeline d'automatisation