# Canaux (/fr/docs/platform/features/alerting/channels)
Un canal est une destination pour les notifications. Créez-en un avant d'écrire la moindre règle, car une règle ne peut pas exister sans canal vers lequel pointer.
Nécessite le rôle **Gestionnaire** sur le site.
## Ajouter un canal [#ajouter-un-canal]
**Alertes** > **Configuration** > **Ajouter un canal**. Donnez-lui un nom, choisissez un type et renseignez la destination.
Le **type ne peut pas être changé après la création**. Pour faire passer un canal de Slack à Teams, créez-en un nouveau et repointez vos règles.
## Les types de canaux et ce que chacun exige [#les-types-de-canaux-et-ce-que-chacun-exige]
Chaque type de canal a besoin d'une destination différente. Chacun a son guide de configuration, couvrant à la fois le côté plateforme et le côté CentralCSP :
| Type | Ce qu'il lui faut | Format d'URL exigé |
| ----------------------------------------------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------- |
| [Slack](/fr/docs/platform/features/alerting/channels/slack) | URL de webhook entrant | Hôte `hooks.slack.com`, chemin commençant par `/services/` |
| [Google Chat](/fr/docs/platform/features/alerting/channels/google-chat) | URL de webhook | Hôte `chat.googleapis.com`, chemin commençant par `/v1/spaces/` |
| [Microsoft Teams](/fr/docs/platform/features/alerting/channels/teams) | URL de workflow Power Automate | Un hôte sous `logic.azure.com` ou `api.powerplatform.com` |
| [Telegram](/fr/docs/platform/features/alerting/channels/telegram) | Token de bot et identifiant de chat | Pas d'URL |
| [Webhook](/fr/docs/platform/features/alerting/channels/webhook) | N'importe quelle URL https, plus un secret de signature | Hôte public, https uniquement |
| [Email](/fr/docs/platform/features/alerting/channels/email) | Une à dix adresses | Pas d'URL |
Le format de l'URL est validé au fur et à mesure de la saisie, donc une URL mal formée est rejetée avant l'enregistrement.
Microsoft a retiré les connecteurs Office 365. Seules les URL de Power Automate Workflows sont acceptées, ce qui explique pourquoi l'hôte doit être sur `logic.azure.com` ou `api.powerplatform.com`. Si votre webhook Teams actuel est une URL de connecteur `office.com`, créez d'abord un Workflow ; le [guide de configuration Teams](/fr/docs/platform/features/alerting/channels/teams) détaille la marche à suivre.
Les adresses internes et privées sont rejetées, dont `localhost`, `.local`, `.internal`, les hôtes sans point, et tout ce qui pointe vers une plage d'IP privée. L'hôte est revérifié à chaque envoi, un canal ne peut donc pas être redirigé vers une infrastructure interne après coup.
## Les canaux email utilisent les membres de l'espace de travail [#les-canaux-email-utilisent-les-membres-de-lespace-de-travail]
Chaque adresse destinataire doit appartenir à un membre de l'espace de travail ayant accès au site ; une adresse extérieure est rejetée à l'enregistrement. Le [guide de configuration email](/fr/docs/platform/features/alerting/channels/email) explique comment les destinataires sont résolus et ce qui se passe quand les membres changent.
## Les payloads webhook sont signés [#les-payloads-webhook-sont-signés]
Un canal webhook exige un secret de signature d'au moins 8 caractères, et chaque envoi est signé en HMAC-SHA256. Le [guide de configuration webhook](/fr/docs/platform/features/alerting/channels/webhook) documente le format du payload, les headers de signature et le code de vérification.
Les secrets, les URL et les tokens de bot ne sont jamais renvoyés par l'API. La modification d'un canal affiche un aperçu masqué, et laisser le champ vide conserve la valeur existante.
## Testez avant de vous y fier [#testez-avant-de-vous-y-fier]
**Tester** envoie immédiatement une alerte d'exemple, à partir d'un faux événement de violation CSP. Cela confirme que la destination accepte les messages : c'est la panne que vous préférez découvrir maintenant plutôt qu'en plein incident.
Limité à un test par canal toutes les 15 secondes, et 20 tests par minute sur l'ensemble de l'espace de travail.
Un test en échec signifie que la destination a refusé le message. C'est une vraie réponse, pas une erreur passagère. Vérifiez l'URL, le token, et que l'application réceptrice est toujours installée.
## Les canaux se désactivent tout seuls [#les-canaux-se-désactivent-tout-seuls]
Après **cinq envois en échec consécutifs**, un canal se coupe automatiquement.
Pour repartir, corrigez la destination, puis remettez l'interrupteur **Activé**. La réactivation remet le compteur d'échecs à zéro. Tout envoi réussi le remet aussi à zéro, une destination intermittente n'accumule donc pas jusqu'à la limite.
C'est utile à savoir, parce qu'un webhook Slack révoqué échoue silencieusement de votre point de vue. Les alertes s'arrêtent, et rien ne change dans les pages de reports. Si les alertes deviennent silencieuses, regardez la liste des canaux.
## Suppression [#suppression]
Supprimer un canal empêche toute règle qui l'utilise d'envoyer. L'historique des envois est conservé, et les règles qui le référençaient ne cassent pas.
## Étapes suivantes [#étapes-suivantes]
* Configurez votre destination. [Slack](/fr/docs/platform/features/alerting/channels/slack), [Google Chat](/fr/docs/platform/features/alerting/channels/google-chat), [Microsoft Teams](/fr/docs/platform/features/alerting/channels/teams), [Telegram](/fr/docs/platform/features/alerting/channels/telegram), [Webhook](/fr/docs/platform/features/alerting/channels/webhook) ou [Email](/fr/docs/platform/features/alerting/channels/email).
* [Règles](/fr/docs/platform/features/alerting/rules)
* [Historique des envois](/fr/docs/platform/features/alerting/deliveries)