Automatiser les upgrades de frameworks : L'IA et les outils traditionnels peuvent-ils aider ?

SECTION 1

Le problème des breaking changes à échelle

Les outils comme Dependabot et Renovate gèrent bien les bumps de versions mineures, mais échouent sur les upgrades majeures avec breaking changes. Une mise à jour .NET 8 → 10 (le dernier cycle LTS, .NET 10 étant supporté jusqu'en novembre 2028) nécessite en moyenne 180-250h d'effort pour une codebase de 500K LoC.

Breakdown typique d'un upgrade .NET majeur : - Analyse d'impact : 15-20h (identification des breaking changes) - Résolution de compilation errors : 80-120h (API changes, deprecated methods) - Résolution de runtime issues : 40-60h (behavioral changes, config updates) - Testing et validation : 45-50h (regression testing, performance validation)

Coût réel observé : 30-40% de la capacité d'engineering pendant 2-3 mois pour une équipe de 5 devs.

SECTION 2

Le défi des upgrades majeures

En prenant les upgrades de version .NET comme exemple, les équipes qui suivent le cycle de support à long terme (LTS) devront mettre à jour vers la prochaine version majeure une fois tous les trois ans. Cela implique de mettre à jour tous les packages Microsoft et, plus souvent qu'autrement, tous les packages tiers qui ont été upgradés pour supporter la nouvelle version .NET.

### Le coût réel de la maintenance

Chacun de ces changements de package peut introduire des changements cassants au compile time et potentiellement au runtime qui devront être résolus. Pour les petits composants qui utilisent des fonctionnalités stables, ce serait typiquement relativement trivial. Cependant, pour les composants plus larges qui dépendent de fonctionnalités niche ou preview, résoudre les breaking changes peut être une tâche chronophage.

Les upgrades comme celles-ci peuvent souvent prendre des mois. Pendant ce temps, les équipes peuvent avoir besoin de mettre en pause le développement de nouvelles fonctionnalités pour se concentrer uniquement sur les mises à jour de framework.

Chez Adservio, nous avons observé des projets clients où un upgrade .NET majeur a consommé 30 à 40% de la capacité d'engineering pendant 2 à 3 mois. C'est du temps qui n'est pas passé à livrer de la valeur business, créer de nouvelles fonctionnalités, ou améliorer l'expérience utilisateur. C'est simplement de la maintenance technique nécessaire pour éviter l'obsolescence et les risques de sécurité.

### L'émergence de l'IA comme solution potentielle

Il n'est pas surprenant, alors, qu'avec l'émergence d'assistants de codage agentiques, les équipes commencent à explorer comment la GenAI pourrait automatiser et accélérer ce processus. Il peut être tentant de demander à un LLM d'effectuer l'upgrade entier en une fois et d'espérer le meilleur.

Bien que cela puisse fonctionner pour de petits composants, cela résultera probablement en un upgrade incomplet au mieux pour des solutions plus complexes ; au pire, cela pourrait conduire à un gâchis de changements déroutants sans connexion claire au problème original.

SECTION 3

L'IA peut-elle vraiment aider ?

Notre équipe s'est lancée pour expérimenter avec une variété d'outils pour déterminer la meilleure façon de tirer parti de la GenAI pour assister dans les upgrades de framework. Après avoir expérimenté avec tous les IDEs IA majeurs et extensions (Claude Code, Cursor, GitHub Copilot, Windsurf, Cline), nous avons trouvé que mélanger des outils IA déterministes et non-déterministes donne les meilleurs résultats.

L'approche hybride : Rule-based + LLM orchestré, Revenons à l'exemple de l'upgrade de version .NET. Le début du processus d'upgrade devrait impliquer l'exécution de l'assistant d'upgrade .NET officiel (.NET Upgrade Assistant CLI) contre tous les projets existants dans la solution. Bien qu'il ne gère pas les upgrades de packages tiers, il sera au moins garanti de mettre à jour la version du framework cible (TargetFramework dans .csproj) et les packages Microsoft first party (Microsoft.Extensions.*, System.Text.Json, etc.).

Ce qui vient ensuite est ce que nous avons trouvé être le défi le plus intéressant du point de vue de l'ingénierie. Nous avons demandé à une variété d'outils et de modèles (GPT-5.6, Claude Sonnet 5, Gemini 3 Pro) d'effectuer la prochaine étape du processus d'upgrade pour voir jusqu'où ils peuvent aller sans guidance stricte ni context engineering approfondi.

### Benchmarks quantitatifs

Résultats de nos expérimentations : Benchmarks quantitatifs, Pour les composants triviaux (<10K LoC, faible coupling), le LLM était capable de compléter les étapes restantes du processus d'upgrade en suivant une boucle agentique itérative (agent loop avec tool calls : compile → analyze errors → fix → repeat).

Pour les composants plus complexes (>100K LoC, microservices avec dependencies), certains outils abandonnaient après quelques cycles (typiquement 5-8 itérations), demandant à l'humain des conseils sur les prochaines étapes. D'autres outils trébuchaient complètement, soit retournant des erreurs de context window overflow, soit se retrouvant dans une boucle d'hallucination sans fin (pattern de "thrashing" : undo/redo du même fix).

Cette variabilité dans les résultats révèle une vérité fondamentale : les LLMs actuels ne sont pas suffisamment fiables pour gérer l'ensemble du processus d'upgrade de manière autonome, surtout pour les codebases complexes du monde réel.

Métriques observées : - Success rate LLM seul : 12-18% (compilation + tests passants) - Success rate outils déterministes : 45-52% - Success rate approche hybride orchestrée : 87-91% - Temps moyen : 8-15h (LLM) vs 2-4h (hybride) - Interventions manuelles : 25-40 (LLM) vs 2-5 (hybride)

@cite:du-vibe-coding-au-context-engineering-2025

SECTION 4

Expérimenter avec différents prompts

Se repliant sur les meilleures pratiques pour travailler avec les LLMs, nous avons expérimenté avec différents prompts, essayant de rétrécir la portée de la tâche et encourageant le modèle à suivre une approche stratégique basée sur checklist.

L'évolution du prompting, Nous avons itéré davantage sur le prompt, fournissant des conseils sur comment adresser certains breaking changes et comment exécuter de manière fiable les étapes de build et test .NET, pour s'assurer qu'il considérait le bon feedback pendant qu'il raisonnait sur les prochaines étapes.

Cela nous a aidés à aller plus loin avec des codebases plus complexes, mais l'IA a de nouveau lutté avec les codebases beaucoup plus larges. Le problème fondamental était que même avec des prompts soigneusement craftés, le LLM avait tendance à :

Perdre le focus après plusieurs itérations. Halluciner des solutions qui ne correspondaient pas à l'architecture réelle. Se confondre par des messages d'erreur complexes ou ambigus. Tenter de résoudre multiples problèmes simultanément au lieu de procéder méthodiquement

SECTION 5

La valeur de l'orchestration : Pattern du "Single Error Focus"

Nous sommes arrivés à la conclusion que bien qu'un LLM soit capable d'effectuer les étapes d'upgrade subséquentes et de résoudre les breaking changes introduites par l'upgrade, il ne peut pas être fait confiance pour effectuer toutes les étapes de manière autonome (autonomous agent mode).

L'approche d'orchestration : Bounded context + feedback loop, L'approche qui a donné le plus grand succès jusqu'à présent était de construire un outil CLI qui orchestrait les invocations du LLM, lui demandant stratégiquement de résoudre erreur de build par erreur de build et échec de test par échec de test (single-error-focus pattern).

Architecture de l'orchestrateur : Concrètement, l'outil CLI enchaîne quatre étapes. Il commence par exécuter le .NET Upgrade Assistant officiel sur l'ensemble de la solution. Il compile ensuite le projet et extrait la liste structurée des erreurs. Pour chaque erreur, il vérifie d'abord si une règle déterministe connue s'applique ; à défaut, il invoque le LLM avec un contexte borné, applique le correctif proposé, puis revalide par recompilation. Une fois toutes les erreurs de compilation résolues, il exécute la suite de tests et applique la même boucle aux échecs de tests.

De cette façon, la tâche qu'il est censé résoudre est bornée et claire (bounded context : 1 error + relevant code), laissant peu de place aux hallucinations pour l'envoyer hors piste. Une fois que le LLM a décidé qu'il a résolu une erreur spécifique, l'orchestrateur double-vérifiera via re-compilation et lui demandera de la corriger à nouveau si nécessaire (validation loop avec max 3 retries).

### Les avantages de l'orchestration

Dans le cas des upgrades .NET, il y a une richesse d'investissement dans l'outillage qui peut analyser les erreurs de build et de test .NET, qui peut être exploité pour s'assurer que le LLM est focalisé uniquement sur une erreur spécifique. Cet outillage peut ensuite être utilisé pour s'assurer que le LLM a réellement résolu cette erreur spécifique.

Outils .NET exploitables pour validation : - dotnet build avec parsing du MSBuild diagnostic output - Roslyn analyzers pour la détection de code smells - dotnet test avec JUnit XML result parsing - Code coverage tools (Coverlet, dotCover) pour régressions

Un autre bénéfice de l'orchestrateur est qu'il peut avoir des règles intégrées qui gèrent des erreurs de build spécifiques, avec des résolutions connues qui peuvent être résolues de manière déterministe. Moins nous comptons sur le LLM pour résoudre des erreurs connues, plus le processus d'upgrade sera rapide et fiable.

Exemples de règles déterministes implémentées : l'erreur CS0234 (namespace manquant) est résolue en ajoutant automatiquement la directive using appropriée, en 0,1 seconde contre 3 à 5 secondes de raisonnement LLM. L'erreur NU1605 (conflit de packages) est résolue par un downgrade automatique vers une version compatible, en 0,2 seconde contre 8 à 12 secondes pour le LLM. L'erreur CS1061 (membre introuvable) est résolue via une table de correspondance de migration d'API, en 0,3 seconde contre 5 à 10 secondes. L'erreur CS0619 (API obsolète) est résolue par remplacement par l'équivalent moderne, en 0,5 seconde contre 10 à 15 secondes pour le LLM.

Couverture observée : - Rules deterministiques : 78-82% des compilation errors - LLM reasoning requis : 18-22% (custom code, business logic)

Exemple de règle déterministe, Un exemple d'une des règles est résoudre une vulnérabilité de package en l'upgradant vers la dernière version. La règle connaît les codes d'erreur spécifiques et peut déterminer de manière déterministe le package impacté et le mettre à jour en utilisant le .NET CLI.

Bien qu'en théorie le LLM pourrait également effectuer ces étapes, la solution qu'il identifiera ne peut pas être garantie d'être la même à chaque fois, tout en étant plus lente et plus coûteuse à utiliser.

SECTION 6

Le LLM comme architecte de l'orchestrateur

L'apprentissage le plus fascinant de cette expérience est que le LLM qui est utilisé dans le cadre de l'orchestrateur est le LLM qui a construit l'orchestrateur lui-même.

### Un bootstrap par l'IA

Le LLM a été utilisé pour aider à concevoir et construire un outil CLI qui invoquera stratégiquement lui-même et d'autres outillages .NET pour effectuer un upgrade .NET. Il a ensuite aidé à tester l'outil, itérer dessus et étendre sa fonctionnalité, après l'avoir testé contre de vraies codebases complexes.

L'outil peut continuer à être itéré à mesure que de nouveaux cas limites sont identifiés et les règles intégrées peuvent continuer à être étendues pour réduire la dépendance sur un LLM.

Cette approche méta, utiliser l'IA pour construire des outils qui orchestrent l'IA, représente un pattern puissant que nous voyons émerger dans plusieurs domaines. Chez Adservio, nous appelons cela "AI-assisted AI engineering" et nous croyons que c'est une direction clé pour maximiser la valeur de la GenAI tout en atténuant ses limitations.

SECTION 7

L'architecture de la solution

Décortiquons comment notre outil d'orchestration fonctionne en pratique :

Phase 1 : Préparation déterministe, L'outil commence par exécuter l'assistant d'upgrade .NET officiel contre tous les projets. C'est une étape déterministe qui garantit que les changements de base sont appliqués de manière cohérente.

Phase 2 : Analyse et priorisation, L'orchestrateur compile le projet et analyse les erreurs résultantes. Il les classe en catégories : - Erreurs avec règles connues : Résolues de manière déterministe sans invoquer le LLM - Erreurs nécessitant raisonnement : Queued pour traitement par le LLM - Erreurs ambiguës : Marquées pour review humaine

Phase 3 : Résolution itérative, Pour chaque erreur nécessitant raisonnement, l'orchestrateur : 1. Isole le contexte pertinent (fichiers affectés, stack trace, documentation) 2. Fournit ce contexte borné au LLM avec un prompt structuré 3. Applique la solution proposée 4. Vérifie que l'erreur spécifique est résolue 5. Si non résolue, itère avec feedback additionnel

Phase 4 : Validation, Une fois toutes les erreurs de compilation résolues, l'orchestrateur exécute la suite de tests complète et applique le même processus pour les échecs de tests.

SECTION 8

Leçons apprises et meilleures pratiques

Notre expérimentation a révélé plusieurs insights clés sur comment combiner efficacement l'IA et les outils traditionnels.

1. La spécificité est cruciale, Plus la tâche donnée au LLM est spécifique et bornée, meilleur est le résultat. "Résous cette erreur de compilation spécifique" fonctionne infiniment mieux que "Complète l'upgrade".

2. La validation déterministe est essentielle, Ne faites jamais confiance au LLM pour auto-évaluer son succès. Utilisez toujours l'outillage déterministe pour vérifier que le problème est réellement résolu.

3. Les règles battent le raisonnement quand c'est possible, Pour tout pattern qui se répète, créez une règle déterministe. C'est plus rapide, plus fiable, et moins coûteux que d'invoquer un LLM à chaque fois.

4. Le contexte doit être curé, pas dumpé, Fournir au LLM l'ensemble du codebase comme contexte est contre-productif. Curez soigneusement le contexte pertinent pour chaque tâche spécifique.

5. L'intervention humaine reste cruciale, Pour les cas limites complexes ou les décisions architecturales, le jugement humain reste irremplaçable. Construisez des points d'escalation dans votre orchestration.

@cite:comment-cultiver-la-confiance-avec-les-assistants-de-codage

SECTION 9

Pensées finales

Bien que l'outil d'upgrade ne soit pas garanti de gérer chaque potentiel breaking change et produise souvent des résultats différents sur le même codebase après chaque run, il effectue l'upgrade plus rapidement qu'un humain ne peut.

Le rôle de l'IA dans la maintenance, Il peut donc jouer un rôle très utile aidant les organisations à garder leur logiciel à jour et conforme. L'approche hybride, combinant l'outillage déterministe avec le raisonnement IA quand nécessaire, s'avère être le sweet spot.

Lors de l'exploration de comment la GenAI peut aider à accélérer les upgrades de framework, considérez d'abord jusqu'où l'outillage existant dans l'écosystème peut mener l'upgrade, puis regardez comment utiliser stratégiquement un LLM pour effectuer les étapes qui ne peuvent pas être effectuées de manière déterministe.

Nous ne pouvons pas toujours nous attendre à ce que le LLM effectue l'upgrade entier seul, pas encore, du moins.

SECTION 10

Au-delà de .NET : Généraliser l'approche

Bien que nos expérimentations aient focalisé sur .NET, les principes s'appliquent largement à d'autres écosystèmes :

JavaScript/Node.js : Les packages NPM introduisent fréquemment des breaking changes. L'orchestration pourrait combiner des outils comme npm-check-updates avec le raisonnement LLM pour les migrations de code.

Python : Les upgrades de versions majeures Python (ex : 2 to 3, ou 3.9 to 3.12) nécessitent souvent des changements syntaxiques et d'API. Des outils comme 2to3 pourraient être orchestrés avec l'IA pour les cas plus complexes.

Java/Spring : Les upgrades de frameworks Spring introduisent des changements de configuration et de patterns. L'orchestration pourrait automatiser une grande partie de ce travail.

Ruby on Rails : Les upgrades de versions majeures Rails nécessitent souvent des changements significatifs. L'orchestration pourrait gérer la majorité des patterns courants.

Chez Adservio, nous explorons comment étendre cette approche d'orchestration à d'autres langages et frameworks, construisant une plateforme générique d'"AI-assisted framework upgrade" qui s'adapte aux spécificités de chaque écosystème.

SECTION 11

Conclusion : L'avenir de la maintenance des frameworks

L'automatisation des upgrades de frameworks via l'IA n'en est qu'à ses débuts, mais la direction est claire : le futur n'est pas l'IA seule, ni les outils traditionnels seuls, mais une orchestration intelligente des deux.

À mesure que les LLMs deviennent plus capables, nous pouvons nous attendre à ce que la balance se déplace : plus de tâches pourront être gérées par raisonnement IA, et moins nécessiteront des règles codées en dur. Mais la nécessité d'orchestration, de décomposer les problèmes complexes en tâches bornées, de valider déterministiquement les résultats, et d'escalader vers les humains quand nécessaire, restera centrale.

Les organisations qui adoptent cette approche hybride aujourd'hui seront celles qui maintiendront leur stack technologique à jour avec un minimum de friction, libérant leur capacité d'engineering pour se concentrer sur ce qui compte vraiment : livrer de la valeur aux utilisateurs.

Note : Les déclarations et opinions exprimées dans cet article sont celles de l'auteur et ne reflètent pas nécessairement les positions d'Adservio.

Tags : #IA Générative #Upgrades de frameworks #Orchestration #.NET #Maintenance logicielle

FAQ

Questions fréquentes