Modernization | The .NET Blog

Docker Sandbox permet aux agents Copilot de refactoriser votre code sans risque pour votre machine

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si vous avez utilisé le mode agent de Copilot pour autre chose que de petites modifications, vous connaissez la douleur. Chaque écriture de fichier, chaque commande terminal — encore une demande de permission. Maintenant, imaginez ça sur 50 projets. Pas vraiment fun.

L’équipe Azure vient de publier un article sur Docker Sandbox pour les agents GitHub Copilot, et honnêtement, c’est l’une des améliorations les plus pratiques que j’ai vues dans l’outillage agentique. Le système utilise des microVMs pour donner à Copilot un environnement totalement isolé où il peut faire ce qu’il veut — installer des paquets, lancer des builds, exécuter des tests — sans toucher à votre système hôte.

Ce que Docker Sandbox vous apporte concrètement

L’idée de base est simple : démarrer une microVM légère avec un environnement Linux complet, synchroniser votre workspace dedans, et laisser l’agent Copilot opérer librement à l’intérieur. Quand il a terminé, les modifications sont synchronisées en retour.

Voici ce qui en fait plus qu’un simple “exécuter des trucs dans un conteneur” :

Synchronisation bidirectionnelle du workspace qui préserve les chemins absolus. La structure de votre projet est identique à l’intérieur du sandbox. Pas d’échecs de build liés aux chemins.
Docker daemon privé tournant à l’intérieur de la microVM. L’agent peut construire et exécuter des conteneurs sans jamais monter le socket Docker de votre hôte. C’est un gros plus pour la sécurité.
Proxies de filtrage HTTP/HTTPS qui contrôlent ce que l’agent peut atteindre sur le réseau. Vous décidez quels registries et endpoints sont autorisés. Des attaques de supply chain via un npm install malveillant dans le sandbox ? Bloquées.
Mode YOLO — oui, c’est vraiment comme ça qu’ils l’appellent. L’agent tourne sans demandes de permission parce qu’il ne peut littéralement pas endommager votre hôte. Toute action destructrice est contenue.

Pourquoi les développeurs .NET devraient s’y intéresser

Pensez au travail de modernisation auquel tant d’équipes font face en ce moment. Vous avez une solution .NET Framework avec 30 projets, et vous devez la migrer vers .NET 9. Ce sont des centaines de modifications de fichiers — fichiers de projet, mises à jour de namespaces, remplacements d’API, migrations NuGet.

Avec Docker Sandbox, vous pouvez pointer un agent Copilot sur un projet, le laisser refactoriser librement dans la microVM, exécuter dotnet build et dotnet test pour valider, et n’accepter que les changements qui fonctionnent réellement. Aucun risque qu’il détruise accidentellement votre environnement de développement local en expérimentant.

L’article décrit également l’exécution d’une flotte d’agents en parallèle — chacun dans son propre sandbox — s’attaquant à différents projets simultanément. Pour les grandes solutions .NET ou les architectures microservices, c’est un gain de temps massif. Un agent par service, tous isolés, tous validés indépendamment.

L’angle sécurité compte

Voici ce que la plupart des gens ignorent : quand vous laissez un agent IA exécuter des commandes arbitraires, vous lui confiez l’intégralité de votre machine. Docker Sandbox inverse ce modèle. L’agent obtient une autonomie totale dans un environnement jetable. Le proxy réseau garantit qu’il ne peut télécharger que depuis des sources approuvées. Votre système de fichiers hôte, votre Docker daemon et vos identifiants restent intacts.

Pour les équipes avec des exigences de conformité — et c’est le cas de la plupart des entreprises .NET — c’est la différence entre “on ne peut pas utiliser l’IA agentique” et “on peut l’adopter en toute sécurité.”

À retenir

Docker Sandbox résout la tension fondamentale du coding agentique : les agents ont besoin de liberté pour être utiles, mais la liberté sur votre machine hôte est dangereuse. Les microVMs vous offrent les deux. Si vous planifiez un refactoring ou une modernisation .NET à grande échelle, ça vaut le coup de le mettre en place maintenant. La combinaison de l’intelligence de code de Copilot avec un environnement d’exécution sécurisé est exactement ce que les équipes de production attendaient.

L'évaluation de modernisation de GitHub Copilot est le meilleur outil de migration que vous n'utilisez pas encore

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Migrer une application legacy .NET Framework vers .NET moderne est l’une de ces tâches que tout le monde sait devoir faire mais que personne ne veut commencer. Ce n’est jamais juste « changer le framework cible ». Ce sont des API qui ont disparu, des packages qui n’existent plus, des modèles d’hébergement qui fonctionnent totalement différemment, et un million de petites décisions sur ce qu’il faut containeriser, réécrire ou laisser tel quel.

Jeffrey Fritz vient de publier une plongée approfondie dans l’évaluation de modernisation de GitHub Copilot, et honnêtement ? C’est le meilleur outillage de migration que j’ai vu pour .NET. Pas à cause de la génération de code — c’est devenu standard maintenant. À cause du document d’évaluation qu’il produit.

Ce n’est pas qu’un moteur de suggestions de code

L’extension VS Code suit un modèle Évaluer → Planifier → Exécuter. La phase d’évaluation analyse l’intégralité de votre codebase et produit un document structuré qui capture tout : ce qui doit changer, quelles ressources Azure provisionner, quel modèle de déploiement utiliser. Tout en aval — infrastructure as code, containerisation, manifestes de déploiement — découle de ce que l’évaluation trouve.

L’évaluation est stockée sous .github/modernize/assessment/ dans votre projet. Chaque exécution produit un rapport indépendant, vous construisez ainsi un historique et pouvez suivre l’évolution de votre posture de migration au fur et à mesure que vous corrigez les issues.

Deux façons de commencer

Évaluation Recommandée — la voie rapide. Choisissez parmi des domaines curatés (Mise à jour Java/.NET, Cloud Readiness, Sécurité) et obtenez des résultats significatifs sans toucher à la configuration. Idéal pour un premier regard sur l’état de votre application.

Évaluation Personnalisée — la voie ciblée. Configurez exactement ce qu’il faut analyser : compute cible (App Service, AKS, Container Apps), OS cible, analyse de containerisation. Choisissez plusieurs cibles Azure pour comparer les approches de migration côte à côte.

Cette vue de comparaison est véritablement utile. Une app avec 3 issues obligatoires pour App Service pourrait en avoir 7 pour AKS. Voir les deux aide à prendre la décision d’hébergement avant de s’engager sur un chemin de migration.

Le détail des issues est actionnable

Chaque issue est accompagné d’un niveau de criticité :

Obligatoire — doit être corrigé sinon la migration échoue
Potentiel — pourrait impacter la migration, nécessite un jugement humain
Optionnel — améliorations recommandées, ne bloque pas la migration

Et chaque issue renvoie aux fichiers affectés et numéros de lignes, fournit une description détaillée de ce qui ne va pas et pourquoi c’est important pour votre plateforme cible, donne des étapes concrètes de remédiation (pas juste « corrigez ceci ») et inclut des liens vers la documentation officielle.

Vous pouvez confier des issues individuelles à des développeurs et ils ont tout ce dont ils ont besoin pour agir. C’est la différence entre un outil qui vous dit « il y a un problème » et un qui vous dit comment le résoudre.

Les chemins de mise à jour couverts

Pour .NET spécifiquement :

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Chaque chemin de mise à jour a des règles de détection qui savent quelles API ont été supprimées, quels patterns n’ont pas d’équivalent direct et quels problèmes de sécurité nécessitent une attention particulière.

Pour les équipes gérant plusieurs applications, il y a aussi un CLI qui supporte les évaluations batch multi-repo — clonez tous les repos, évaluez-les tous, obtenez des rapports par application plus une vue agrégée du portfolio.

Mon avis

Si vous êtes assis sur des applications legacy .NET Framework (et soyons honnêtes, la plupart des équipes enterprise le sont), c’est l’outil par lequel commencer. Le document d’évaluation seul vaut le temps — il transforme un vague « on devrait moderniser » en une liste concrète et priorisée d’éléments de travail avec des chemins clairs vers l’avant.

Le workflow collaboratif est malin aussi : exportez les évaluations, partagez-les avec votre équipe, importez-les sans relancer. Revues d’architecture où les décideurs ne sont pas ceux qui exécutent les outils ? Couvert.

Pour conclure

L’évaluation de modernisation de GitHub Copilot transforme la migration .NET d’un projet effrayant et indéfini en un processus structuré et traçable. Commencez avec une évaluation recommandée pour voir où vous en êtes, puis utilisez des évaluations personnalisées pour comparer les cibles Azure et construire votre plan de migration.

Lisez le walkthrough complet et récupérez l’extension VS Code pour l’essayer sur votre propre codebase.