Mettre à jour ses dépendances avec l’IA sans casse

Pour mettre à jour vos dépendances avec l’IA, laissez l’agent faire la lecture et les modifications répétitives, et gardez pour vous les règles de sécurité : une seule mise à jour majeure par branche, le guide de migration lu avant toute modification du code, et la suite de tests comme seule preuve que tout fonctionne. Les agents de code comme Claude Code, Codex et Gemini CLI excellent dans la partie fastidieuse des mises à jour : renommer une API dans quatre-vingts fichiers, adapter la configuration des tests à un nouveau runner, expliquer une erreur obscure de dépendance pair. Ils sont mauvais sur un point qui compte beaucoup ici : ils se souviennent de l’ancienne version de la bibliothèque.

Ce guide présente une méthode qui fonctionne aussi bien pour une petite application que pour un grand monorepo : inventaire, tri, regroupement des mises à jour faciles, isolement des difficiles, codemods, lockfiles, vérification, PR de bots et alertes de sécurité. Les exemples utilisent npm et pnpm, avec les équivalents Python là où ils diffèrent.

Pourquoi les mises à jour de dépendances tournent mal avec les agents

Les mises à jour ont l’air simples, et c’est justement pour cela qu’elles tournent mal. Les échecs habituels :

• Des connaissances périmées. Les données d’entraînement d’un modèle s’arrêtent à une certaine date. Demandez-lui de passer à une version sortie après, et il écrira avec assurance du code pour la version qu’il connaît.
• Le périmètre qui enfle. « Mettre à jour React » devient React, le routeur, la bibliothèque de tests, ESLint et trois plugins, le tout dans un seul diff.
• Déplacer les poteaux. Un test échoue après la mise à jour, alors l’agent met à jour le snapshot, assouplit l’assertion ou désactive le test.
• Faire taire l’installateur. Un conflit de dépendances pairs est « corrigé » avec --force ou --legacy-peer-deps au lieu de trouver des versions réellement compatibles.
• Le chaos du lockfile. L’agent supprime le lockfile pour faire disparaître une erreur d’installation, et des centaines de paquets transitifs changent d’un coup.

Chaque étape qui suit est là pour bloquer l’un de ces écueils.

Étape 1 : faire l’inventaire

Partez des faits, pas d’un prompt du genre « mets tout à jour ». Chaque écosystème a une commande intégrée qui liste ce qui est en retard :

npm outdated            # Current, Wanted (highest in your range) and Latest
pnpm outdated           # add -r in a workspace
pip list --outdated     # for the active Python environment

Ajoutez la vue sécurité :

npm audit
pip-audit               # PyPA tool: pip install pip-audit

Puis donnez la sortie à l’agent et demandez-lui un tri, pas des modifications :

Voici la sortie de npm outdated et de npm audit. Ne modifie rien pour l’instant.
Fais un tableau avec : paquet, version actuelle, wanted, latest, type de mise à jour
(patch/mineure/majeure), s’il s’agit d’une dépendance directe ou de dev, et un lien
vers son changelog ou sa page de releases. Signale tout ce qui a une alerte de sécurité.
Puis propose un ordre : ce qui peut être regroupé, ce qui demande sa propre branche.

C’est une tâche en lecture seule, vous pouvez donc la lancer en mode planification ou avec des permissions en lecture seule. Le tableau devient votre plan, et il vous montre tôt quelles mises à jour sont réellement lourdes.

Étape 2 : regrouper les mises à jour faciles

Les versions patch et mineures sont censées être rétrocompatibles. En pratique, elles le sont en général, et la suite de tests attrape le reste. Faites-les ensemble, sur une seule branche :

git switch -c deps/minor-patch
npm update              # stays inside the ranges in package.json

Avec pnpm, pnpm update fait la même chose, pnpm update --interactive vous laisse choisir, et pnpm update --latest franchit les versions majeures : gardez celle-là pour l’étape 3. Ensuite :

Lance toute la suite de tests, la vérification de types et le build. Si quelque chose
échoue, trouve quel paquet en est la cause et corrige le code, pas les tests. Si un
correctif demande plus de quelques lignes, remets ce paquet à sa version précédente
et note-le pour une mise à jour séparée.

Cette dernière phrase compte. Elle garde le lot petit et sans surprise, et envoie tout ce qui surprend vers sa propre branche.

Étape 3 : une mise à jour majeure par branche

Une version majeure implique par définition des changements cassants. Donnez à chacune sa propre branche et, si vous voulez en mener plusieurs en même temps, son propre dossier avec un git worktree :

git worktree add ../app-vite -b deps/vite-major
git worktree add ../app-eslint -b deps/eslint-major

Un agent met alors à jour l’outil de build, un autre le linter, et votre dossier principal reste intact. Si une mise à jour s’enlise, vous supprimez ce worktree et cette branche sans rien perdre d’autre. Les git worktrees pour agents en parallèle détaille la mise en place.

Deux règles pour les majeures :

• Une version majeure à la fois. Passer de la version 3 à la 6 d’un seul saut empile trois séries de changements cassants dans un seul diff. Passez de 3 à 4, obtenez du vert, committez, puis de 4 à 5.
• Mettez à jour ensemble les paquets liés, et rien d’autre. Un framework et ses plugins officiels doivent souvent avancer de concert. C’est normal. Les paquets sans rapport attendent.

Étape 4 : lire le guide de migration avant de toucher au code

C’est l’étape qui règle le problème des connaissances périmées. Avant que l’agent ne modifie quoi que ce soit, il doit lire la vraie documentation de la version exacte vers laquelle vous allez :

Nous passons eslint de la version 8 à la 9. Avant de modifier le moindre fichier :
1. Lis le guide de migration officiel et le changelog de la 9.0.0.
2. Liste chaque changement cassant qui s’applique à ce dépôt, avec les fichiers
   concernés (cherche dans le code pour le confirmer).
3. Dis ce que tu feras pour chacun.
Prends la documentation et les définitions de types du paquet installé comme source
de vérité, pas ce dont tu te souviens des anciennes versions. Attends mon accord.

Si votre agent peut naviguer sur le web, il récupère le guide lui-même ; sinon, collez les passages utiles ou indiquez-lui les notes de version dans node_modules/<package>/CHANGELOG.md quand le paquet en fournit. Un serveur MCP de documentation aide aussi ; voir les meilleurs serveurs MCP pour coder.

La liste qu’il produit sert aussi plus tard de checklist de revue : chaque élément doit correspondre à une modification dans le diff.

Étape 5 : laisser le codemod passer en premier

Beaucoup de frameworks fournissent des codemods : des scripts qui réécrivent le code mécaniquement pour une nouvelle version. Un codemod est déterministe et l’agent ne l’est pas, alors laissez le codemod faire tout ce qu’il peut et donnez le reste à l’agent.

Deux exemples connus :

# Next.js: upgrades Next.js, React and React DOM and runs the codemods
npx @next/codemod upgrade major

# Angular: updates packages and runs their migrations
ng update @angular/core @angular/cli

En octobre 2026, la documentation de Next.js précise que @next/codemod upgrade tourne en mode non interactif et accepte toutes les valeurs par défaut quand l’entrée standard n’est pas un terminal, ce qui est le cas quand un agent le lance. Si vous voulez choisir les codemods appliqués, lancez-le vous-même d’abord et confiez le résultat à l’agent.

Après le codemod, committez, puis demandez à l’agent de traiter les points restants de l’étape 4 : les cas que le codemod a signalés ou ignorés, vos propres surcouches autour de l’ancienne API, la configuration des tests et les fichiers de configuration. Garder la sortie du codemod et les modifications de l’agent dans des commits séparés facilite beaucoup la revue. Le même principe vaut pour les migrations plus lourdes ; refactoriser du code legacy avec l’IA et migrer de JavaScript vers TypeScript avec l’IA approfondissent les migrations pas à pas.

Étape 6 : traiter le lockfile comme une partie du changement

C’est le lockfile qui donne un sens à « ça marche sur ma machine ». Quelques règles à mettre dans AGENTS.md ou CLAUDE.md :

## Dépendances
- Ne supprime jamais package-lock.json / pnpm-lock.yaml pour corriger une erreur d’installation.
- N’utilise pas --force ni --legacy-peer-deps sans demander.
- Installe avec npm ci en CI ; committe le lockfile avec la modification de package.json.
- N’ajoute pas de nouvelles dépendances pendant une tâche de mise à jour.

Quand une installation échoue sur des dépendances pairs, demandez à l’agent d’expliquer le conflit au lieu de le forcer. npm explain <package> (alias npm why) montre pourquoi un paquet est dans l’arbre et qui exige quelle version ; npm ls <package> montre chaque copie. Souvent, la vraie solution consiste à mettre à jour le plugin qui fige l’ancienne dépendance pair, et cela a sa place sur la même branche.

En revue, regardez aussi le diff du lockfile. Une montée mineure d’une seule dépendance directe qui modifie trois cents entrées transitives mérite une question.

Étape 7 : vérifier avec vos propres contrôles

« Ça s’installe » ne veut pas dire « c’est fini ». Définissez la fin dans le prompt, en des termes que l’agent peut vérifier :

Terminé signifie : npm ci réussit, npm test passe, tsc --noEmit passe,
npm run build passe, et aucun fichier de test existant n’a été modifié sauf
là où le guide de migration l’exige (explique chacun).

Si votre suite de tests est mince autour de la bibliothèque que vous mettez à jour, ajoutez d’abord quelques tests, sur l’ancienne version, et gardez-les au vert pendant toute la mise à jour. Pour les bibliothèques d’interface, un contrôle rapide dans un vrai navigateur attrape ce que les tests unitaires ratent : un agent équipé d’un navigateur peut ouvrir les pages principales et signaler les erreurs de console. Pour les outils de build, comparez la taille de la sortie avant et après ; un bundle qui double est un bug, même si tous les tests passent.

Relisez le diff avec trois questions : un test a-t-il changé, un comportement public a-t-il changé, et chaque modification correspond-elle à un élément de la liste des changements cassants ?

PR de bots : Dependabot et Renovate, plus un agent

Dependabot et Renovate savent bien ouvrir des PR de mise à jour selon un calendrier. Ce qu’ils ne savent pas faire, c’est corriger le code quand la mise à jour casse quelque chose. C’est la partie qu’un agent peut prendre en charge.

Une configuration Dependabot minimale qui regroupe les mises à jour faciles dans une seule PR :

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      minor-and-patch:
        update-types:
          - "minor"
          - "patch"

L’équivalent Renovate part de son preset recommandé :

{
  "extends": ["config:recommended"],
  "packageRules": [
    { "matchUpdateTypes": ["minor", "patch"], "groupName": "minor and patch" }
  ]
}

Quand une PR de bot passe au rouge, la boucle ressemble à ceci :

gh pr checkout 123
gh pr checks 123              # find the failing run
gh run view <run-id> --log-failed   # the log of its failed jobs

Ceci est une PR Dependabot qui fait passer zod à la majeure suivante. La CI échoue
avec le log ci-dessous. Trouve la cause racine, lis les notes de version de la
nouvelle version et corrige notre code pour qu’il fonctionne avec elle. Ne fige pas
l’ancienne version et ne modifie pas les tests pour masquer l’échec. Lance les tests
en local, puis résume la modification avant de pousser.

Un détail : dès que vous poussez vos propres commits sur une branche Dependabot, Dependabot cesse de rebaser automatiquement cette PR, et @dependabot recreate jetterait votre correctif. Fusionnez-la vite ou rebasez-la vous-même. Pour la version générale de cette boucle, voir corriger automatiquement les échecs de CI avec l’IA.

Alertes de sécurité

npm audit liste les vulnérabilités connues de votre arbre. Quelques points pour qu’il reste utile :

• Concentrez-vous sur ce qui part en production. npm audit --omit=dev laisse de côté les dépendances de dev, et --audit-level=high ne fait échouer la commande qu’à partir d’une sévérité haute ou critique, ce qui constitue un garde-fou de CI raisonnable.
• npm audit fix ou --force. audit fix seul reste dans vos plages déclarées. Avec --force, il peut installer des versions semver-majeures ; traitez cela comme une mise à jour de l’étape 3, pas comme un correctif rapide.
• Les paquets transitifs. Quand le paquet vulnérable est profond dans l’arbre et que son parent n’a pas publié de correctif, le champ overrides de npm dans package.json (ou pnpm.overrides chez pnpm) peut imposer une version corrigée. Demandez à l’agent d’ajouter un commentaire ou une issue qui explique pourquoi, pour que l’override soit retiré plus tard.
• Demandez si le code est atteignable. Faites vérifier par l’agent si votre code utilise réellement la fonction vulnérable. Cela ne veut pas dire que vous sautez le correctif, mais vous savez s’il est urgent aujourd’hui ou s’il peut rejoindre le lot hebdomadaire.

Côté Python, pip-audit signale le même genre de problèmes pour un environnement ou un requirements.txt, et pip-audit --fix tente de mettre à jour les paquets concernés. La question plus large de ce que les agents eux-mêmes ont le droit d’installer est traitée dans la sécurité des agents de code IA.

Erreurs fréquentes

• « Mets toutes les dépendances à la dernière version » en un seul prompt. Vous obtenez un diff géant et aucun moyen de le bissecter.
• Sauter le guide de migration. L’agent écrit du code pour la version dont il se souvient.
• Laisser les tests changer en silence. Un snapshot mis à jour est acceptable quand le guide explique le changement ; sinon, il masque une régression.
• Forcer l’installateur. Un --force aujourd’hui, c’est une installation cassée pour la personne suivante.
• Fusionner des branches de mise à jour parallèles sans les tester ensemble. Deux branches vertes peuvent devenir rouges une fois combinées ; une file de fusion teste chacune par-dessus le dernier main.

Le faire dans AgentVera

AgentVera est une application de bureau qui fait tourner côte à côte des CLI d’agents de code comme Claude Code, Codex et Gemini CLI, avec git intégré. Plusieurs de ses fonctionnalités collent directement à cette méthode :

• Un worktree par mise à jour majeure. Créez un worktree depuis le panneau Git et lancez-y un agent en un clic ; menez la mise à jour de Vite dans un panneau et celle d’ESLint dans un autre.
• Une règle hebdomadaire pour les dépendances. Les automatisations (Pro) peuvent lancer un agent selon un planning cron dans son propre worktree. L’un des playbooks intégrés est « mettre à jour les dépendances (mineures et correctifs uniquement) », et le résultat peut arriver sous forme de PR ou entrer dans la file de fusion.
• La CI rouge confiée à un agent. Le centre CI/CD liste les exécutions GitHub Actions, GitLab CI et Jenkins ; sur une exécution en échec, « Corriger avec un agent » ouvre un agent Claude avec les détails de l’exécution et la fin du log de jusqu’à trois jobs en échec. Une automatisation peut aussi lancer un agent quand la CI passe au rouge sur les branches de votre choix.
• Vérifier selon votre définition de « terminé ». Écrivez « les tests, la vérification de types et le build passent ; aucun fichier de test modifié » dans votre message. Verify en fait des critères et, à la fin du tour, un vérificateur distinct qui ne peut pas modifier de fichiers contrôle chacun avec des preuves.
• Revue et file de fusion. La revue de code relit ce que l’agent a modifié avec un second modèle, et la file de fusion intègre les branches de mise à jour une à une par-dessus la dernière version de la cible, en lançant votre commande de vérification sur le résultat fusionné.

Pour conclure

Mettre à jour ses dépendances avec l’IA fonctionne quand vous gardez au travail une forme réduite : l’inventaire d’abord, les mises à jour faciles en un seul lot, chaque majeure sur sa propre branche, le guide de migration lu avant la première modification, le codemod avant l’agent, et les tests comme juges. L’agent vous épargne la lecture et la centaine de petites modifications ; la méthode garde ces modifications honnêtes. Une fois la mise à jour terminée, si vous voulez aussi rendre l’application plus rapide, lisez comment optimiser les performances du code avec l’IA.

Pour l’essayer sur votre propre dépôt, téléchargez AgentVera.