L'Évaluateur de Risque de Mise à Niveau des Dépendances : Transformez une liste de paquets obsolètes en un plan de mise à niveau hiérarchisé
Pourquoi ce prompt est important
Dependency debt compounds silently. Each deferred upgrade doesn't just add one more overdue package — it makes the eventual upgrade riskier, because more changes stack up between your current version and the one you'll be forced onto during a security incident or an end-of-life deadline. Teams that never explicitly prioritize upgrades don't avoid the work; they just do it later, under worse conditions, usually as an unplanned emergency instead of a scheduled sprint task.
À quoi nous l'utilisons
Your `npm outdated` output lists 34 packages behind, most flagged for major-version gaps. Your tech lead wants a prioritized upgrade plan before tomorrow's sprint planning, and you don't have time to read every changelog yourself.
Prompt
Act as a senior engineer responsible for dependency management who has run upgrade cycles across dozens of production codebases and knows how deferred upgrades turn into emergency migrations. Context: Project type and stack: [e.g., "Node.js/TypeScript monorepo, ~200k LOC, deployed to production weekly"] Outdated dependencies: [PASTE THE LIST — package name, current version, latest version, e.g. from `npm outdated`, `pip list --outdated`, or `bundle outdated`] Changelog or release-notes excerpts, if you have them: [PASTE RELEVANT EXCERPTS, OR WRITE "NONE PROVIDED" FOR ANY PACKAGE] Team capacity this sprint: [e.g., "limited — can only take on 2-3 low-risk upgrades" or "dedicated tech-debt sprint, can absorb larger changes"] Task: For each dependency listed, assess: 1. How many major and minor versions behind it currently is 2. Its risk category — security-critical, breaking-change-heavy, or routine 3. A specific recommendation: upgrade now, schedule for next sprint, or defer (with a reason) Constraints: - Flag any dependency with a known CVE or security advisory as highest priority regardless of stated team capacity. - Clearly distinguish between "this WILL break something" (based on documented breaking changes you were given) and "this MIGHT break something" (no changelog provided, so assume moderate risk) — never present a guess with the same confidence as a documented fact. - The "upgrade now" shortlist must respect the stated team capacity — do not recommend more work than the team can realistically absorb this sprint. - If changelog excerpts weren't provided for a package, say so explicitly in your reasoning rather than inventing specific breaking changes. Output Format: 1. A ranked table: Package | Current → Latest | Risk Level | Recommendation | Reasoning 2. A "Do This Sprint" shortlist that respects the stated capacity 3. One clarifying question to ask before greenlighting the single riskiest upgrade on the list
Résultat
| Package | Current → Latest | Risk Level | Recommendation | Reasoning |
|---|---|---|---|---|
| auth-token-lib | 2.3.1 → 2.3.9 | Security-Critical | Upgrade now | Changelog for 2.3.7 lists a fix for CVE-2026-31442, a token-validation bypass. This overrides capacity limits — security fixes are non-negotiable regardless of sprint load. |
| axios | 0.21.4 → 1.7.2 | Breaking-Change-Heavy | Schedule for next sprint | Major version jump (0.x → 1.x). Changelog confirms the default export pattern changed and several config options were renamed. This WILL require code changes across every file that imports axios directly — not a drop-in bump. |
| lodash | 4.17.15 → 4.17.21 | Routine | Upgrade now | Patch-only jump within the same minor version. No changelog excerpt was provided, but the version delta itself (patch-level only) makes breaking changes very unlikely. Low effort, safe to batch with the security fix above. |
| express | 4.17.1 → 4.19.2 | Routine | Upgrade now | Minor version bumps within Express 4.x have historically been backward-compatible. No changelog was provided for this specific range, so this is a moderate-confidence assessment, not a documented guarantee. |
| react | 17.0.2 → 18.3.1 | Breaking-Change-Heavy | Defer | Major version jump requiring the new root API (createRoot) and auditing all components for concurrent-rendering side effects. Given your stated capacity of 2-3 upgrades this sprint, this is too large to absorb alongside the security fix — defer to the dedicated tech-debt sprint. |
Do This Sprint (respecting stated capacity of 2-3 upgrades):
- auth-token-lib (security-critical, mandatory)
- lodash (near-zero risk, low effort)
- express (routine, moderate confidence)
Clarifying question before greenlighting axios 1.x: Do you have integration test coverage on every code path that calls axios directly, or only on the handful of endpoints your team remembers using it? A breaking-change-heavy upgrade is far riskier in code paths without test coverage, since you won't catch a broken call signature until it fails in production.
Chaque équipe d'ingénierie accumule un arriéré de dépendances obsolètes, et presque toutes les équipes gèrent cela de la même manière insatisfaisante : quelqu'un jette un coup d'œil à la sortie, ressent un bref sentiment de culpabilité, et passe au développement de fonctionnalités. Le problème ne vient pas d'un manque de sensibilisation — c'est que transformer une liste de plus de trente paquets en un véritable plan priorisé prend du temps réel, et ce temps concurrence directement la livraison. Ce prompt est conçu pour condenser ce travail de triage en une seule passe.
Pourquoi ce prompt est structuré de cette façon
La contrainte exigeant que le modèle traite toute CVE connue comme étant automatiquement prioritaire, indépendamment de la capacité déclarée de l'équipe, existe parce que les correctifs de sécurité constituent la seule catégorie de travail sur les dépendances qui n'est pas réellement facultative. Un prompt qui laisserait une « capacité limitée » déprioriser silencieusement un correctif de sécurité serait activement dangereux à utiliser — tout l'intérêt d'automatiser ce triage est de s'assurer qu'aucun élément important ne passe entre les mailles du net, et non de fabriquer une excuse commode pour l'ignorer.
La distinction entre « cela VA casser quelque chose » et « cela POURRAIT casser quelque chose » est la contrainte la plus importante de tout le prompt, et elle est là parce que le mode de défaillance le plus courant de la planification assistée par IA est la fausse confiance. Un modèle à qui l'on fournit un extrait de journal des modifications confirmant un changement cassant d'API est sur des bases solides. Un modèle à qui l'on demande de deviner si une mise à jour de version sans documentation est sûre fait quelque chose de fondamentalement moins fiable — et si les deux sont présentés avec le même ton confiant, le plan devient activement trompeur. Forcer le modèle à indiquer dans quelle catégorie tombe chaque évaluation signifie que vous savez exactement quelles recommandations vous pouvez suivre les yeux fermés et lesquelles méritent une vérification de cinq minutes du journal des modifications avant de vous engager.
La contrainte de capacité est ce qui transforme cela d'un simple rapport de dépendances générique en un véritable outil de planification de sprint. Une évaluation des risques qui ignore la quantité de travail que votre équipe peut réellement absorber cette semaine est un conseil pour une équipe hypothétique, pas pour la vôtre. Forcer la liste restreinte « À faire ce sprint » à respecter un chiffre de capacité déclaré signifie que le résultat est quelque chose que vous pouvez confier directement à la planification de sprint au lieu de le traduire vous-même.
Pourquoi le format de tableau est important
Un tableau trié, plutôt qu'un compte-rendu narratif, est délibéré. Le triage des dépendances est fondamentalement une tâche de comparaison — vous pesez plusieurs paquets les uns par rapport aux autres pour décider ce qui entre dans une capacité limitée — et un tableau vous permet de parcourir et de réorganiser mentalement d'une manière qu'un format d'un paragraphe par paquet ne permet pas. La question de clarification finale sur la couverture des tests existe parce que le plus grand risque caché dans toute mise à jour cassante n'est pas le changement lui-même, c'est de savoir si vous remarquerez réellement s'il casse quelque chose — et c'est une question que le modèle peut vous inciter à répondre mais qu'il ne peut pas résoudre sur votre propre base de code.
Comment l'adapter
Pour une base de code avec un accès aux journaux des modifications véritablement médiocre (paquets privés, projets open-source abandonnés avec des notes de version éparses), attendez-vous à ce que davantage d'éléments atterrissent par défaut dans la catégorie « POURRAIT casser quelque chose » — c'est le prompt qui fonctionne correctement, et non un échec. Dans cette situation, il vaut la peine d'associer le résultat à une vérification rapide des problèmes GitHub de chaque paquet pour y chercher de nouveaux rapports de bugs avant de finaliser le plan de sprint.
Pour les équipes qui exécutent cela de manière trimestrielle plutôt que par sprint, remplacez le cadre de la capacité de « ce sprint » par « ce trimestre », et envisagez de demander une deuxième passe qui regroupe les paquets par framework sous-jacent partagé (par exemple, « tous les paquets de l'écosystème React »), étant donné que les sauts de versions majeures dans un framework central forcent souvent les paquets associés à se mettre à jour de concert de toute façon.