Merci pour ces précisions, Jay.
Après des diagnostics supplémentaires, il semble que le HTTPS sortant ne soit pas bloqué sur l’hôte lui-même — les requêtes curl directes vers GitHub et raw.githubusercontent.com aboutissent de manière constante. Le problème ne se manifeste que dans le conteneur d’initialisation, où git ls-remote via HTTPS rencontre occasionnellement des délais d’attente SSL. L’accès à GitHub en SSH reste entièrement fiable, c’est pourquoi j’avais initialement envisagé la possibilité d’utiliser un chemin SSH propre lors de l’initialisation.
Ton argument concernant la difficulté de réécrire tous les composants qui supposent l’utilisation du HTTPS est tout à fait fondé. Étant donné que les échecs du HTTPS sont liés à une instabilité de la route de mon FAI vers GitHub, et non à un pare-feu local ou à un problème de réseau Docker, je vais me concentrer sur la stabilisation du chemin réseau amont plutôt que de tenter de modifier le processus d’initialisation.
Merci encore pour tes conseils et pour avoir clarifié les contraintes liées à l’utilisation du HTTPS dans la chaîne de construction.