Une pipeline de tests qui échoue en silence ne sert à rien : si personne ne le voit avant le lendemain matin, le rouge reste rouge une nuit entière et le déploiement suivant repart sur une base cassée. C’est exactement ce qui nous est arrivé sur un projet client à échéance serrée, où un test de régression cassé un vendredi soir n’a été repéré que le lundi matin, retardant la mise en production de trois jours.
Depuis, chaque pipeline GitHub Actions que nous mettons en place pour un client se termine par une étape de notification vers un canal Slack dédié, mais seulement en cas d’échec — une notification à chaque exécution réussie finit par être ignorée par lassitude.
Pourquoi ne notifier qu’en cas d’échec
Le réflexe naturel consiste à notifier systématiquement, en vert pour un succès et en rouge pour un échec. Nous avons abandonné cette approche après avoir constaté que l’équipe finissait par couper les notifications du canal au bout de quelques semaines, noyée sous les messages de succès. Ne notifier qu’en cas d’échec restaure l’attention : un message dans le canal signifie systématiquement qu’il faut agir.
Configurer le webhook Slack entrant
- Créer une application Slack dédiée depuis la console des applications, avec un webhook entrant activé sur le canal choisi.
- Copier l’URL du webhook générée, propre à ce canal.
- Enregistrer cette URL comme secret du dépôt GitHub, sous le nom
SLACK_WEBHOOK_URL, jamais en clair dans le fichier de workflow. - Répéter l’opération pour chaque client avec un canal Slack distinct, afin qu’une équipe ne voie jamais les échecs d’un projet qui ne la concerne pas.
Écrire l’étape de notification conditionnelle
Dans le fichier .github/workflows/tests.yml, l’étape de notification est placée en fin de job avec la condition if: failure(), qui garantit qu’elle ne s’exécute que si une étape précédente a échoué :
jobs:
tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Installer les dépendances
run: composer install --no-interaction
- name: Lancer les tests PHPUnit
run: vendor/bin/phpunit
- name: Notifier Slack en cas d'échec
if: failure()
run: |
curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"Échec des tests sur ${{ github.repository }} — job : ${{ github.run_id }}\"}" \
${{ secrets.SLACK_WEBHOOK_URL }}
Rendre le message actionnable
Un message Slack qui se contente de dire « les tests ont échoué » oblige la personne à retourner ouvrir GitHub pour comprendre quoi. Nous enrichissons systématiquement le message avec :
- Le nom de la branche concernée, via la variable
github.ref_name. - Le nom de l’auteur du commit déclencheur, via
github.actor. - Un lien direct vers le détail du job, construit à partir de
github.server_url,github.repositoryetgithub.run_id.
--data "{\"text\":\"Échec des tests sur *${{ github.repository }}* (branche ${{ github.ref_name }}, par ${{ github.actor }}) : ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}\"}"
Distinguer les canaux par projet et par gravité
Sur un parc de plusieurs clients, tous les échecs ne méritent pas la même urgence. Nous séparons deux canaux : un canal général qui reçoit tous les échecs de tests, utile pour une vue d’ensemble, et un canal spécifique par client réservé aux échecs sur la branche principale, ceux qui bloquent réellement une mise en production imminente.
| Type d’échec | Canal | Urgence |
|---|---|---|
| Échec sur une branche de développement | Canal général CI | À traiter dans la journée |
| Échec sur la branche principale | Canal du client concerné | Immédiate |
Ce que ce réglage a changé
Depuis la mise en place de ces notifications ciblées, le délai moyen entre un échec de test et sa prise en charge est passé de plusieurs heures à quelques minutes sur nos projets suivis, simplement parce que l’information arrive là où l’équipe regarde déjà, sans effort de surveillance actif.
Une notification que personne ne consulte n’est pas une notification, c’est un log de plus.
En résumé
Brancher Slack sur une pipeline GitHub Actions ne demande que quelques lignes de YAML, à condition de résister à la tentation de tout notifier. Le bon réglage reste simple : silence en cas de succès, message clair et actionnable en cas d’échec, avec un canal par niveau de gravité.
