GitHub rend généralement disponible une image Windows 11 ARM64 avec Visual Studio 2026 sur ses runners hébergés standards et de grande taille. Les équipes peuvent la sélectionner dès maintenant avec runs-on: windows-11-vs2026-arm, avant une migration progressive de l’alias existant en septembre.

La réponse rapide

QuestionRéponse
Quel label tester ?windows-11-vs2026-arm
Quand commence la migration ?Le 21 septembre 2026.
Quand doit-elle se terminer ?Le 30 septembre 2026.
Le changement est-il transparent ?Pas pour les builds liés à Visual Studio 2022 ou à ses composants exacts.

Pourquoi l’alias peut casser un pipeline inchangé

Une image de runner inclut le système, le compilateur, les SDK et de nombreux outils préinstallés. Même si le fichier YAML ne change pas, le remplacement de Visual Studio 2022 par 2026 peut modifier MSBuild, les toolsets C++, les chemins ou les versions du SDK Windows.

GitHub prévient explicitement que les workflows dépendant de Visual Studio 2022 peuvent échouer. L’intervalle de migration est progressif : deux exécutions proches peuvent donc ne pas utiliser exactement la même génération d’image si le workflow suit un alias mouvant.

Tester sans attendre la bascule

Ajoutez temporairement un job parallèle ciblant windows-11-vs2026-arm. Compilez les mêmes configurations, exécutez les tests natifs et comparez les artefacts. Les projets .NET doivent contrôler la version du SDK réellement résolue ; les projets C++ doivent vérifier le toolset, l’architecture des dépendances et la présence des workloads Visual Studio nécessaires.

Conservez le diagnostic de l’environnement dans les journaux : sortie de dotnet --info, msbuild -version, version du compilateur et liste des SDK. Cette trace transforme une différence de runner en problème observable.

Éviter les dépendances implicites

Un pipeline robuste installe ou épingle ses outils critiques au lieu de supposer leur présence. Un fichier global.json peut fixer le SDK .NET, tandis qu’un gestionnaire comme vcpkg doit utiliser un commit ou une baseline identifiée. Les actions tierces doivent elles aussi être référencées par une version maîtrisée.

Épingler toute l’image n’est pas toujours possible sur les runners gérés. L’objectif est plutôt de rendre le build explicite, de détecter rapidement les variations et de conserver une matrice de compatibilité pendant la transition.

ARM64 mérite des tests natifs

Compiler sur x64 puis exécuter par émulation ne couvre pas toutes les différences. Un runner ARM64 révèle les dépendances qui ne publient pas de binaire compatible, les scripts qui supposent une architecture et les extensions natives mal empaquetées.

Pour une application Windows distribuée sur ARM, ajoutez au minimum compilation, installation, démarrage et tests des composants natifs. Vérifiez également la signature et la création des packages MSIX.

La disponibilité générale simplifie la CI Windows ARM64, mais l’alias automatique introduit une échéance. Tester le label Visual Studio 2026 avant le 21 septembre coûte moins cher qu’un diagnostic pendant la fenêtre de migration.