GitHub Actions ajoute le calcul multicloud : des tâches Linux peuvent tourner sur AWS, listes d’IP à mettre à jour

GitHub a indiqué le 28 octobre 2026 que GitHub Actions répartit désormais les tâches éligibles sur un parc de calcul multicloud plus large : des tâches Linux éligibles peuvent donc s’exécuter sur Amazon Web Services en plus de Microsoft Azure. Les objectifs annoncés sont plus de capacité, des files d’attente plus courtes liées à la capacité et une meilleure résilience aux heures de pointe. Le changement est progressif et s’accompagne d’un avertissement : des listes d’autorisation réseau qui ne nomment que des plages Azure ou Microsoft peuvent bloquer les nouveaux exécuteurs.

Le périmètre est étroit. Le calcul multicloud s’applique aux exécuteurs Linux standard de 2 et 4 cœurs et aux grands exécuteurs compatibles de 2 et 4 cœurs sans configuration spécialisée. Il ne s’applique pas aux exécuteurs Windows ni à ceux qui ont un réseau privé ou une autre configuration spécialisée. GitHub ne publie ni la part des tâches qui basculeront, ni une date de début par compte, ni une amélioration mesurée des temps d’attente ; le bénéfice est donc un objectif annoncé, pas un résultat.

Qui en profite dépend de la formule. Les clients de GitHub Free, GitHub Pro et GitHub Team utilisent automatiquement le calcul multicloud pour les exécuteurs éligibles. Les clients de GitHub Enterprise Cloud doivent l’activer : dans les paramètres de l’entreprise, sous Actions, dans les fournisseurs cloud de calcul hébergé, un administrateur active le calcul AWS. GitHub dit répartir automatiquement les tâches éligibles entre les fournisseurs disponibles, les étiquettes d’exécuteur et la syntaxe des flux de travail restant inchangées. Une équipe ne choisit donc pas un cloud par tâche ; elle choisit seulement, sur Enterprise Cloud, si le calcul AWS est autorisé.

L’action recommandée est la partie qui peut casser des pipelines. Les exécuteurs du parc élargi utilisent des adresses IP sortantes supplémentaires. Une politique qui n’autorise que des plages Azure ou appartenant à Microsoft, y compris une politique d’accès conditionnel Microsoft Entra, peut donc bloquer les connexions ou l’authentification de ces exécuteurs. Les tâches qui joignent une base de données protégée par pare-feu, un registre de paquets privé ou une API cloud vérifiant l’adresse de l’appelant sont les cas probables. Comme le déploiement est progressif, une telle panne pourrait apparaître par intermittence, sur certaines tâches seulement, ce qui la rend plus difficile à diagnostiquer.

La solution de GitHub consiste à cesser de tenir des listes propres à un cloud. Toutes les plages d’adresses IP des exécuteurs GitHub Actions, y compris les nouvelles, sont publiées dans le tableau actions de la réponse de GET https://api.github.com/meta. GitHub recommande de synchroniser les listes d’autorisation avec ce point d’accès plutôt que de s’appuyer sur les plages d’un seul fournisseur, et de le faire dès maintenant, avant que des flux de travail commencent à tourner dans le parc élargi. Une équipe peut automatiser la synchronisation et la lancer régulièrement, la liste publiée pouvant changer. Les clients Enterprise Cloud qui n’activent pas l’option évitent les nouvelles adresses, mais le journal ne dit pas combien de temps ce choix restera possible.

Pour la plupart des équipes, le travail est petit et concret : repérer chaque règle de pare-feu, politique d’accès conditionnel et groupe de sécurité cloud qui admet les exécuteurs hébergés par GitHub, remplacer les plages fixes par la liste du point d’accès meta et surveiller les journaux à la recherche de connexions bloquées après le début du déploiement. Les équipes qui utilisent des exécuteurs Windows, de grands exécuteurs spécialisés ou un réseau privé noteront que ces cas sont hors du périmètre de l’annonce.