> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corgea.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Slack
> Configuration des notifications Slack avec les webhooks Corgea
Envoyez les alertes Corgea dans Slack en connectant un webhook Slack Workflow Builder depuis **Intégrations → Webhooks**.
L’entrée **Slack** autonome de la section Automation Integrations est obsolète. Créez désormais les notifications Slack avec **Webhooks**. Les intégrations Slack existantes continuent de fonctionner ; utilisez **View All** pour les tester ou les supprimer.
## Prérequis
* Un accès administrateur dans Corgea
* L’autorisation de créer des workflows dans votre espace de travail Slack
## Configurer Slack Workflow Builder
Utilisez Slack Workflow Builder pour mapper les champs de **premier niveau** du payload Corgea dans un message de canal.
Slack Workflow Builder ne prend en charge que les **clés JSON de premier niveau**. Les chemins imbriqués tels que `data.message` ou `data.summary.total_issues` ne sont **pas pris en charge** et provoquent souvent une erreur HTTP 400 `invalid_workflow_input`.
Avec `Type = Slack` et une URL Workflow Builder (`hooks.slack.com/triggers/...`), Corgea aplatit **uniquement** `scan.started`, `scan.completed`, `scan.failed` et `webhook.test` dans un payload de premier niveau. Mappez `message`, `pull_request_id`, `scan_url` et `true_positive_count`, et non les champs imbriqués `data.*`.
Les autres événements souscrits sur le même webhook Slack, par exemple `issue.status_changed` ou `sla.violation`, conservent leur enveloppe imbriquée. Pour Workflow Builder, privilégiez les événements du cycle de vie des scans. Pour les autres événements, utilisez un corps personnalisé ou une destination autre que Slack.
1. Dans Slack, ouvrez votre menu d’espace de travail
2. Accédez à **Tools → Workflow Builder**
3. Cliquez sur **Create**
4. Choisissez **Webhook** comme déclencheur
5. Nommez le workflow et poursuivez
1. Copiez l’URL du webhook Workflow Builder (`hooks.slack.com/triggers/...`)
2. À l’étape du déclencheur **Webhook**, **ajoutez des variables** dont les noms correspondent aux clés de premier niveau de Corgea. Slack ne détecte pas automatiquement les champs du payload. Ajoutez au minimum : `message`, `pull_request_id`, `scan_url`, `true_positive_count`, `scan_id`, `event_type`, `project_name`, `status`, `branch`, `company`
3. Ajoutez une étape **Send a message**. Elle est obligatoire, car Corgea ne publie pas lui-même dans Slack.
4. Utilisez **Insert a variable** pour insérer ces variables dans le message. La saisie manuelle du texte `{message}` ne fonctionne pas.
Exemple de corps plat `scan.completed` envoyé par Corgea à Workflow Builder (les objets imbriqués `project`, `summary` et `scheduled_scan_ids` ne sont **pas** inclus) :
```json theme={null}
{
"event_id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
"event_type": "scan.completed",
"timestamp": "2025-01-15T15:45:00.000Z",
"message": "Scan completed for My Project (PR #42): 5 true-positive findings. View: https://app.corgea.app/project/proj-uuid-9012/?scan_id=scan-uuid-7890",
"scan_id": "scan-uuid-7890",
"scan_url": "https://app.corgea.app/project/proj-uuid-9012/?scan_id=scan-uuid-7890",
"scan_type": "full",
"pull_request_id": "42",
"true_positive_count": 5,
"status": "completed",
"branch": "feature/auth",
"project_name": "My Project",
"company": "comp-uuid-1234",
"run_id": "run-abc",
"engine": "corgea"
}
```
Pour `scan.failed`, le corps plat contient également le champ de premier niveau `error` lorsqu’il est disponible.
Commencez par `message` pour obtenir un résumé prêt à envoyer, puis ajoutez `pull_request_id`, `scan_url` et `true_positive_count` pour le triage des pull requests.
Le texte `message` d’un scan terminé utilise le nombre de **résultats confirmés**, et non le nombre total de problèmes :
`Scan completed for {project} (PR #N): X true-positive finding(s) [(Y with fixes)]. View: {scan_url}`
`Y with fixes` ne compte que les correctifs associés à ces résultats confirmés.
5. Terminez et publiez le workflow
1. Accédez à **Intégrations → Webhooks**
2. Créez un webhook
3. Définissez **Type** sur `Slack`
4. Saisissez un nom et collez l’URL Workflow Builder
5. Abonnez-vous à `scan.completed` et/ou `scan.failed`, et éventuellement à `scan.started`
6. Sous **Filtres d’événements de scan** (facultatif) :
* **Uniquement les scans de pull request ou de merge request** — ignore les scans qui ne concernent pas une pull request
* **Uniquement les scans terminés comportant des résultats confirmés** — ignore `scan.completed` lorsque `true_positive_count` vaut 0, sans affecter `scan.failed`
7. Cliquez sur **Create Webhook** et enregistrez la clé secrète à usage unique
8. Cliquez sur **Test** pour confirmer la livraison
## Résultat attendu du test du webhook
Lorsque vous cliquez sur **Test Webhook** pour une destination Slack Workflow Builder, Corgea envoie un exemple de payload plat :
```json theme={null}
{
"event_id": "...",
"event_type": "webhook.test",
"timestamp": "2025-01-15T15:45:00.000Z",
"message": "This is a test webhook from Corgea",
"test": true,
"webhook_name": "My Slack Hook",
"company": "comp-uuid-1234",
"company_id": "comp-uuid-1234",
"scan_id": "00000000-0000-0000-0000-000000000000",
"scan_url": "https://app.corgea.app/project/example/?scan_id=00000000-0000-0000-0000-000000000000",
"scan_type": "full",
"pull_request_id": "123",
"true_positive_count": 2,
"status": "completed",
"branch": "main",
"project_name": "Example Project",
"run_id": "test-run",
"engine": "corgea"
}
```
`company` correspond à la clé utilisée pour les événements de scan réels. `company_id` contient la même valeur pour assurer la compatibilité avec les anciens consommateurs des événements de test. Les destinations autres que Slack reçoivent ces champs sous `data`, dans l’enveloppe habituelle.
Attendez-vous à :
* HTTP 2xx de Slack (pas 400 `invalid_workflow_input`)
* Un message Slack non vide lorsque vous mappez la variable de premier niveau `message`
* Des noms de variables identiques à ceux des événements de scan en production, afin de pouvoir mapper le numéro de pull request, le lien vers le scan et le nombre de résultats confirmés pendant le test
## Contenu des notifications
Pour Slack Workflow Builder (`Type = Slack` et `hooks.slack.com/triggers/...`), mappez les champs de **premier niveau** suivants :
| Champ | Description |
| --------------------- | ----------------------------------------------------------------------------------------------------------- |
| `message` | Résumé prêt à envoyer (numéro de pull request, nombre de résultats confirmés et URL du scan, si disponible) |
| `event_type` | Par exemple, `scan.completed`, `scan.failed`, `webhook.test` |
| `event_id` | UUID de l’événement de livraison |
| `timestamp` | Horodatage ISO 8601 |
| `scan_id` | UUID du scan |
| `scan_url` | Lien direct vers le scan dans Corgea |
| `scan_type` | Type de scan |
| `pull_request_id` | Numéro de pull request ou de merge request lorsque le scan en concerne une (vide sinon) |
| `true_positive_count` | Résultats de sécurité non supprimés excluant les faux positifs et la qualité du code |
| `status` | `started`, `completed` ou `failed` |
| `branch` | Branche Git |
| `project_name` | Nom du projet |
| `company` | ID de l’entreprise (même clé que dans les payloads des événements de scan réels) |
| `company_id` | Même valeur que `company` (`webhook.test` uniquement ; absent des événements `scan.*` réels) |
| `run_id` | ID de l’exécution du scan |
| `engine` | Moteur de scan |
| `error` | Motif de l’échec (`scan.failed` uniquement, si présent) |
| `test` | `true` uniquement pour `webhook.test` |
| `webhook_name` | Nom d’affichage du webhook (`webhook.test` uniquement) |
`true_positive_count` correspond au nombre de problèmes de sécurité affiché dans l’interface du scan : il exclut `status=false_positive`, `hold_reason=false_positive` et `detected_by=code-quality`. Les champs imbriqués tels que `summary`, `project`, `scheduled_scan_ids`, `scan_errors`, `created_at` et `processed_at` restent disponibles sous `data` pour Zapier et les autres destinations, ainsi que dans l’historique des livraisons, mais ne sont pas aplatis pour Slack Workflow Builder.
## Notes de compatibilité
* **Zapier / Autres** : ces destinations reçoivent toujours l’enveloppe imbriquée (`event_id`, `event_type`, `timestamp`, `data`), notamment `data.message`, `data.summary` et les nouveaux champs de triage sous `data`.
* **Configurations Slack Workflow Builder existantes** : celles qui mappent des champs `data.*` imbriqués ne fonctionnent pas. Mappez les clés de premier niveau, par exemple `message` et non `data.message`.
* **Historique des livraisons** : Corgea conserve l’enveloppe imbriquée, même lorsque Slack reçoit un corps HTTP plat.
* **Événements autres que les scans** : ils ne sont pas aplatis sur un webhook Slack Workflow Builder. Utilisez Zapier, une autre destination ou un corps personnalisé si vous avez besoin de variables Slack exploitables.
## Webhooks entrants vs Workflow Builder
* **Recommandation** : utilisez une URL Workflow Builder (`hooks.slack.com/triggers/...`) avec une étape **Send a message**. Corgea aplatit `scan.*` et `webhook.test` lorsque `Type = Slack`.
* **Incoming Webhooks** (`hooks.slack.com/services/...`) : l’enregistrement est refusé, sauf si vous ajoutez un [corps personnalisé](/fr/webhooks) dont le JSON rendu contient un champ `text` non vide de premier niveau. Des blocs `blocks` facultatifs peuvent l’accompagner. `{"text": "{{message}}"}` ne fonctionne que si le webhook est limité à `scan.started`, `scan.completed`, `scan.failed` et `scheduled_scan.daily_report`, car `{{message}}` est vide pour les autres événements. Sans corps valide, les livraisons échouent et le webhook peut être automatiquement mis en pause.
## Gestion des intégrations Slack existantes
Si vous utilisez encore des intégrations dans l’ancienne ligne Slack, ouvrez **Voir tout** pour les tester ou les supprimer :
## Options de personnalisation
Avec Workflow Builder, vous pouvez :
* Acheminer les messages vers différents canaux selon la sévérité ou le projet
* Ajouter des rappels ou des étapes de suivi
* Ajouter une logique conditionnelle fondée sur les résultats des scans, par exemple pour ne notifier que lorsque `true_positive_count` est supérieur à 0
* Réutiliser les mêmes variables de payload dans plusieurs actions
Privilégiez les **filtres d’événements de scan** de Corgea (pull requests uniquement et scans terminés avec résultats) pour éviter le bruit des scans planifiés ou complets sans recourir à un outil tiers comme Zapier.
## Ressources supplémentaires
* [Guide Slack Workflow Builder](https://slack.com/help/articles/360035692513-Guide-to-Workflow-Builder)
* [Aplatir JSON pour Workflow Builder](https://slack.dev/flatten-json-for-workflow-builder/)
* [Webhooks Corgea](/fr/webhooks)