Symptôme fréquent avant la mise en place de cette notification : un déploiement échouait silencieusement en fin de journée, personne ne consultait l’onglet Actions de GitHub avant le lendemain matin, et le client découvrait un site cassé avant que qui que ce soit côté agence ne s’en aperçoive. Le pipeline de déploiement lui-même fonctionnait bien, ce qui manquait était un canal de communication qui pousse l’information vers l’équipe plutôt que d’attendre qu’elle aille la chercher.
L’ajout d’une étape de notification Slack en fin de pipeline règle ce problème sans complexité particulière. Ce texte ne revient pas sur la construction du pipeline de déploiement lui-même, déjà couverte en détail par ailleurs, mais uniquement sur cette étape de notification.
Créer le webhook entrant Slack
Un webhook entrant (incoming webhook) Slack, configuré depuis les paramètres d’une application Slack dédiée à l’agence, fournit une URL unique vers laquelle poster des messages JSON qui apparaissent automatiquement dans un canal choisi, ici #deploiements. Cette URL, sensible, est stockée comme secret dans chaque dépôt GitHub, jamais en clair dans un fichier de workflow.
Le message de succès
Un message de notification utile ne se contente pas d’un « déploiement terminé » laconique. Il précise le site concerné, la branche déployée, l’auteur du commit, et un lien direct vers le run de la pipeline pour investiguer si besoin :
- name: Notifier Slack en cas de succès
if: success()
run: |
curl -s -X POST -H 'Content-Type: application/json' \
-d "{
\"attachments\": [{
\"color\": \"#2eb886\",
\"title\": \"✅ Déploiement réussi : boutique-nord\",
\"text\": \"Branche \`${{ github.ref_name }}\` déployée par ${{ github.actor }}\",
\"footer\": \"Voir le run : ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}\"
}]
}" \
"${{ secrets.SLACK_WEBHOOK_DEPLOIEMENTS }}"
Le message d’échec, avec un ton différent
L’étape symétrique se déclenche sur l’échec du job, avec une couleur rouge et une formulation qui invite explicitement à consulter les logs, plutôt que de simplement signaler l’échec sans piste d’action :
- name: Notifier Slack en cas d'échec
if: failure()
run: |
curl -s -X POST -H 'Content-Type: application/json' \
-d "{
\"attachments\": [{
\"color\": \"#e01e5a\",
\"title\": \"🔴 Échec du déploiement : boutique-nord\",
\"text\": \"Branche \`${{ github.ref_name }}\` poussée par ${{ github.actor }} — vérifier les logs sans attendre\",
\"footer\": \"Voir le run : ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}\"
}]
}" \
"${{ secrets.SLACK_WEBHOOK_DEPLOIEMENTS }}"
Où placer ces étapes dans le workflow
Les conditions if: success() et if: failure() évaluées au niveau d’une étape s’appuient sur le résultat des étapes précédentes du même job. Il faut veiller à placer ces étapes de notification après toutes les étapes de déploiement effectif, et non entre deux d’entre elles, sous peine de notifier un succès prématuré alors qu’une étape suivante échouera peut-être.
Mutualiser le message via une action réutilisable
Sur un parc de plusieurs dizaines de dépôts, dupliquer ce bloc de notification dans chaque fichier de workflow devient vite ingérable dès qu’un ajustement de format s’impose. L’agence a extrait cette logique dans une action composite réutilisable, hébergée dans un dépôt central :
# .github/workflows/notifier-slack/action.yml
name: Notifier Slack déploiement
inputs:
webhook_url:
required: true
site_nom:
required: true
statut:
required: true
runs:
using: composite
steps:
- shell: bash
run: |
if [ "${{ inputs.statut }}" = "succes" ]; then
COULEUR="#2eb886"; TITRE="✅ Déploiement réussi : ${{ inputs.site_nom }}"
else
COULEUR="#e01e5a"; TITRE="🔴 Échec du déploiement : ${{ inputs.site_nom }}"
fi
curl -s -X POST -H 'Content-Type: application/json' \
-d "{\"attachments\":[{\"color\":\"${COULEUR}\",\"title\":\"${TITRE}\"}]}" \
"${{ inputs.webhook_url }}"
Chaque pipeline de déploiement du parc appelle désormais cette action réutilisable avec deux lignes, plutôt que de dupliquer un bloc curl complet à chaque fois :
- uses: agence/actions-partagees/notifier-slack@v1
if: always()
with:
webhook_url: ${{ secrets.SLACK_WEBHOOK_DEPLOIEMENTS }}
site_nom: boutique-nord
statut: ${{ job.status == 'success' && 'succes' || 'echec' }}
Éviter le bruit de notification
Un canal Slack qui reçoit une notification à chaque commit sur une branche de développement, en plus des déploiements réels en production, finit rapidement ignoré par l’équipe. La règle retenue par l’agence limite ces notifications aux seuls déploiements vers un environnement de staging ou de production, jamais aux exécutions de tests sur une simple branche de travail.
Une notification qui n’arrive qu’en cas de problème grave finit par se fondre dans le bruit ambiant ; celle qui confirme aussi les succès garde l’équipe attentive au canal.
En résumé
Cette simple étape de notification, quelques lignes ajoutées en fin de pipeline, a changé la dynamique de l’équipe face aux incidents de déploiement : un échec se découvre désormais en quelques secondes plutôt qu’au petit matin suivant. L’action composite réutilisable a par ailleurs réduit la duplication de code sur la trentaine de dépôts qui en bénéficient, un gain de maintenance qui dépasse largement l’objectif initial de simple notification.
