Le 25 juin 2026, GitHub a ajouté l’exécution parallèle des étapes dans un même job Actions. Jusqu’ici, une étape attendait la fin de la précédente. Il fallait passer par le shell pour contourner ce comportement, avec des sorties qui finissaient facilement mélangées.
La nouveauté ajoute notamment background, wait, wait-all, cancel et parallel. La syntaxe officielle des workflows permet donc de lancer plusieurs étapes en même temps tout en conservant des logs séparés.
Ça arrive au moment où je viens justement de brancher le déploiement de ce site sur GitHub Actions. La tentation logique serait de chercher immédiatement ce que je peux paralléliser.
Je ne vais pas le faire.
## Avant, la séquence faisait partie du déploiement
Mon workflow arrive jusqu’à un script sur mon VPS. Ce script récupère le code, construit l’application et relance le processus géré par pm2.
Vu de loin, ce sont juste plusieurs commandes posées les unes sous les autres. En pratique, leur ordre transporte de l’état.
Le 14 août, j’ai corrigé deux problèmes qui le montrent bien.
Le premier venait du script de déploiement lui-même. Il exécutait un git pull, récupérait donc potentiellement une nouvelle version de son propre fichier, puis continuait avec l’ancienne version déjà chargée par Bash. J’ai dû rendre sa relance explicite après la mise à jour.
Le second concernait le cache d’images de Next.js. Remplacer une image dans public/ sans changer son nom ne suffisait pas. Les variantes déjà optimisées restaient dans .next/cache/images, même après le build et le redémarrage pm2. Le déploiement purge maintenant ce cache.
Ces commandes ne sont pas indépendantes. Le nouveau code doit être récupéré avant que sa version soit exécutée. Le build doit être terminé avant de servir l’application reconstruite. Le cache doit être supprimé avant que l’ancienne image continue sa vie après le redémarrage.
La séquence n’est donc pas seulement le comportement par défaut de GitHub Actions. C’est une partie du contrat de mon déploiement.
## Le parallèle ajouterait un état intermédiaire
Avec background, je pourrais laisser une étape tourner et passer à la suivante. Avec parallel, je pourrais regrouper plusieurs opérations indépendantes, puis attendre leur fin avant de continuer.
Le mot important est indépendantes.
Dans mon déploiement actuel, je n’ai pas identifié deux tâches suffisamment coûteuses et réellement indépendantes pour justifier ce changement. Je pourrais découper davantage le workflow juste pour utiliser la nouveauté, mais ce serait fabriquer une optimisation avant d’avoir trouvé un problème.
Surtout, chaque étape en arrière-plan crée un nouvel état possible. Le build peut être en cours pendant qu’une autre commande agit sur les fichiers. Une purge peut se terminer avant ou après une opération voisine. En cas d’échec, il faut savoir ce qui tourne encore, ce qui a fini et ce qui doit être annulé.
GitHub fournit justement wait et cancel pour contrôler ça. L’outil n’est pas incomplet. C’est simplement mon déploiement qui n’a pas encore besoin de cette complexité.
## Ce qui pourrait me faire changer
Je ne rejette pas la fonctionnalité. Je garde surtout un seuil clair.
Si j’ajoute plus tard plusieurs vérifications qui ne modifient pas le serveur et ne dépendent pas les unes des autres, les exécuter en parallèle pourra avoir du sens. Même chose si un workflow doit préparer plusieurs artefacts séparés avant une étape commune.
À ce moment-là, les logs distincts seront plus propres qu’un bricolage avec & dans une commande shell. Et je mesurerai au moins le temps réellement gagné avant de modifier le flux.
Pour le déploiement actuel, je conserve une ligne simple : une étape termine, son résultat est connu, puis la suivante commence. Après deux corrections liées à l’état exact du script et du cache, ce comportement me sert davantage que le parallélisme.
La prochaine fois que je touche au workflow, je commencerai donc par écrire quelles étapes dépendent de quelles autres. S’il ne reste aucun bloc réellement indépendant, le YAML restera séquentiel.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.