---
title: "Le compte à rebours de 24 heures du CRA démarre le 11 septembre 2026 : assurez-vous que quelqu'un décroche"
description: "À partir du 11 septembre 2026, le règlement européen sur la cyberrésilience donne 24 heures aux fabricants pour transmettre une alerte précoce — dans un navigateur, sans API. Voici comment transformer ce déclencheur en appel téléphonique avec Echobell, et ce qu'une alerte plus sonore ne résout toujours pas."
date: 2026-08-21
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - règlement cyberrésilience
  - notification CRA
  - signalement d'incident
  - divulgation de vulnérabilités
  - alertes par appel
---

# Faites sonner un téléphone pour l'alerte précoce de 24 heures du CRA avant la fin du délai

Le **11 septembre 2026**, les obligations de signalement du règlement européen sur la cyberrésilience (CRA) entrent en application. À partir de cette date, un fabricant qui a connaissance d'une vulnérabilité activement exploitée dans un produit comportant des éléments numériques — ou d'un incident grave l'affectant — dispose de **24 heures** pour transmettre une alerte précoce à son CSIRT coordinateur et à l'ENISA ([Commission européenne](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting), [règlement (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)).

Ce délai possède une propriété que la plupart des échéances de conformité n'ont pas : il court en heures réelles. Aucune exception pour les jours ouvrés, aucune pause le week-end, aucun sursis pendant que votre responsable du signalement est en vol. Et la plateforme de dépôt, la plateforme de signalement unique (SRP) de l'ENISA, est un formulaire web : « aucune interface de programmation applicative ne sera fournie à ce stade » ([FAQ de l'ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions)). Une personne nommément désignée doit se connecter et soumettre.

La règle des 24 heures est donc un problème d'alerte avant d'être un problème de paperasse. Ce guide montre comment acheminer le moment de la prise de connaissance jusqu'à un téléphone qui sonne, avec [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-cra-24-hour-reporting-alerts-fr&mt=8), et reste honnête sur la grande part de la préparation au CRA qu'aucun outil de notification ne touche.

## Que commence exactement le 11 septembre 2026 ?

**Les fabricants de produits comportant des éléments numériques doivent signaler les vulnérabilités activement exploitées et les incidents graves via une plateforme européenne unique, selon un calendrier échelonné qui démarre dès la prise de connaissance.** Tout le reste du CRA — marquage CE, exigences essentielles de l'annexe I, évaluation de la conformité — s'applique à partir du 11 décembre 2027. Le signalement arrive quinze mois plus tôt, et il vise aussi les produits déjà sur le marché, pas seulement ce que vous livrerez après cette date ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/reporting.html)).

L'article 14 définit deux voies parallèles de même forme :

| Étape | Vulnérabilité activement exploitée — art. 14(2) | Incident grave — art. 14(4) |
| --- | --- | --- |
| Alerte précoce | Sous **24 heures** après la prise de connaissance | Sous **24 heures** après la prise de connaissance |
| Notification | Sous **72 heures** après la prise de connaissance | Sous **72 heures** après la prise de connaissance |
| Rapport final | Au plus tard **14 jours** après la disponibilité d'une mesure corrective ou d'atténuation | Sous **un mois** après la notification des 72 heures |

La formulation est « sans retard injustifié et en tout état de cause dans les 24 heures suivant la prise de connaissance par le fabricant » ([article 14](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_14.html)). Vingt-quatre heures est un plafond, pas une cible.

L'article 14(5) fixe le seuil du caractère « grave » : un incident l'est lorsqu'il affecte négativement, ou **est susceptible d'affecter** négativement, la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes, ou lorsqu'il a conduit — ou **est susceptible de conduire** — à l'introduction ou à l'exécution de code malveillant. Ce « susceptible de » compte : vous pouvez devoir signaler avant que quoi que ce soit ait réellement mal tourné pour un client.

L'article 14(8) ajoute une seconde obligation, en parallèle : vous devez également informer les utilisateurs affectés du produit de la vulnérabilité ou de l'incident et, si nécessaire, des mesures correctives qu'ils peuvent prendre. C'est un destinataire distinct du CSIRT, sur son propre canal.

## Qui est réellement concerné ?

**Les fabricants de produits comportant des éléments numériques, où qu'ils soient établis, ainsi que les gestionnaires (stewards) de logiciels libres, de manière plus restreinte.** Une entreprise hors UE qui vend dans l'Union n'échappe pas à l'obligation ; le règlement attend qu'un opérateur économique établi dans l'UE soit responsable des obligations pertinentes ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/explained.html)).

Vous signalez au CSIRT désigné comme coordinateur dans l'État membre où se trouve votre établissement principal dans l'Union, et simultanément à l'ENISA — mais vous ne déposez **qu'une seule fois**, via la plateforme de signalement unique, qui achemine vers les deux ([Commission européenne](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)).

Les gestionnaires de logiciels libres relèvent d'un sous-ensemble défini : l'obligation de l'article 14(1) s'applique dans la mesure où ils participent au développement de produits comportant des éléments numériques, et les articles 14(3) et (8) dans la mesure où des incidents graves affectent les réseaux et systèmes d'information qu'ils fournissent pour ce développement. Si vous gérez un projet largement utilisé, lisez l'article 24 avec l'article 14 plutôt que de supposer l'un ou l'autre extrême.

L'article 15 autorise par ailleurs le signalement volontaire — de vulnérabilités, cybermenaces, incidents et quasi-incidents — par les fabricants comme par toute autre personne. Le signalement volontaire ne crée pas d'obligations nouvelles, mais il passe par la même plateforme et se heurte au même problème : quelqu'un doit être réveillé.

## Pourquoi un délai de 24 heures est-il un problème d'alerte ?

**Parce que le compte à rebours démarre à la prise de connaissance, et que celle-ci survient rarement aux heures de bureau.** Le déclencheur, c'est un fait qui atteint votre organisation, pas une décision qu'elle prend.

Regardez d'où vient ce fait. Un chercheur écrit à `security@` à 23 h 40 un samedi. Un client en aval ouvre un ticket décrivant une exploitation. Un flux CVE ou KEV s'allume sur un composant que vous distribuez. Votre propre EDR détecte une exécution dans un système de build. La note de préparation de DLA Piper pointe précisément la version « chaîne d'approvisionnement » de ce problème : les fabricants sont rarement les premiers informés, et l'information arrive par des importateurs, distributeurs, chercheurs ou fournisseurs de composants ([DLA Piper](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations)).

Chacun de ces chemins aboutit à une notification que votre configuration actuelle délivre probablement en silence : un e-mail dans une boîte partagée, un message dans un canal Slack que personne ne surveille la nuit, un ticket dans une file triée le lundi. Aucune n'échoue. Toutes sont correctement livrées — à personne.

Trois détails creusent l'écart plus qu'il n'y paraît :

- **Il n'y a pas d'API.** L'ENISA indique clairement qu'aucune API de signalement ne sera fournie à ce stade. Impossible de laisser un script déposer l'alerte précoce pendant que tout le monde dort.
- **L'accès se configure personne par personne, à l'avance.** Les représentants autorisés s'enregistrent avec un compte EU Login, et le CSIRT coordinateur désigné valide leur autorité après le premier accès. Il y a un représentant principal et un suppléant, et l'invitation au suppléant **expire au bout de sept jours** ([FAQ de l'ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions), [cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)). Si la seule personne habilitée est injoignable, le délai n'en tient pas compte.
- **Le palier de sanction est le plus élevé.** L'article 64 place le non-respect des obligations des articles 13 et 14 dans la tranche d'amendes administratives « pouvant aller jusqu'à 15 000 000 EUR ou, si l'auteur de l'infraction est une entreprise, jusqu'à 2,5 % de son chiffre d'affaires annuel mondial total réalisé au cours de l'exercice précédent, le montant le plus élevé étant retenu » ([article 64](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_64.html)).

Une nuance honnête sur ce dernier point, car elle change le calcul pour les petites équipes : l'article 64 exclut les fabricants qui sont des microentreprises ou des petites entreprises des amendes administratives **pour non-respect du délai** de l'article 14(2)(a) ou 14(4)(a) — c'est-à-dire précisément l'alerte précoce de 24 heures. L'obligation de signaler demeure, et l'exclusion ne s'étend ni à la notification à 72 heures ni au reste de l'article 14. Lisez l'article et faites-vous conseiller, plutôt que de vous fier à un billet de blog pour savoir où se situe votre entreprise.

## Que contient réellement l'alerte précoce de 24 heures ?

**Très peu de choses — et c'est tout l'intérêt.** Les orientations de l'ENISA décrivent un petit ensemble de champs obligatoires au stade de l'alerte précoce : type de notification (vulnérabilité ou incident), niveau de notification, heure du signalement, informations sur le déclarant, nom du fabricant ou du gestionnaire, le produit, un titre, et pour les incidents, si des actes illicites ou malveillants sont suspectés. Les champs facultatifs à ce stade incluent un identifiant CVE ou EUVD.

Le tableau technique plus complet — nature générale de la vulnérabilité ou de l'exploitation, évaluation initiale, mesures correctives et d'atténuation — relève de la notification à 72 heures, pas des 24 premières heures.

L'alerte précoce n'est donc pas un projet de recherche. C'est un formulaire court qu'une personne préparée remplit en quelques minutes. La contrainte n'est pas le formulaire, mais le fait qu'une personne enregistrée, autorisée et éveillée l'apprenne à temps. C'est un problème d'acheminement de notifications, et il est soluble dès aujourd'hui.

## Comment placer un téléphone qui sonne devant le compte à rebours de 24 heures ?

Echobell transforme un appel webhook ou un e-mail en une alerte qui sonne et vibre comme un appel entrant, ce qui lui permet de traverser le mode Concentration et Ne pas déranger d'iOS (voir [contourner le mode Concentration d'iOS](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)). La configuration ci-dessous vient s'ajouter à vos processus de ticketing et de PSIRT existants — elle ne les remplace pas.

### Étape 1 — Créez un canal Appel réservé aux candidats CRA

Dans l'application, créez un canal et réglez le type de notification sur **Appel** ([types de notification](/docs/notification)). Nommez-le d'après la décision qu'il déclenche, pas d'après la source : « CRA — le compte à rebours de 24 h a peut-être démarré » vaut mieux que « Alertes sécurité ».

Ce canal doit rester silencieux. S'il sonne pour chaque avis, chaque scan en échec et chaque mise à jour de dépendance, les gens cesseront de décrocher, et vous aurez dépensé votre unique canal bruyant en bruit. Aiguillez le reste ailleurs — le [guide sur la fatigue d'alerte](/blog/fix-alert-fatigue-developer-guide) traite de ce partage.

Copiez l'URL webhook du canal depuis ses détails ; elle ressemble à `https://hook.echobell.one/t/<channel-token>`. Traitez-la comme un secret : quiconque la détient peut faire sonner les téléphones de votre équipe ([guide webhook](/docs/webhook)).

Configurez des modèles lisibles sur un écran verrouillé à 2 h du matin par quelqu'un à moitié endormi :

```
Titre : Signalement CRA possible — {{product}}
Corps : {{kind}} — {{summary}} (connu depuis {{time}} UTC)
```

`{{time}}`, `{{date}}`, `{{hour}}` et les autres [variables temporelles système](/docs/template) sont toujours injectées en UTC, de sorte que la notification porte un horodatage même si l'émetteur l'a oublié. Cet horodatage n'est pas une preuve juridique du début de la prise de connaissance, mais c'est un point d'ancrage utile pour reconstituer la chronologie ensuite.

### Étape 2 — Dirigez vos chaînes de détection vers le canal

Tout système capable d'appeler un webhook peut déclencher le canal. Les champs envoyés deviennent des variables de modèle :

```bash
curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "vulnérabilité activement exploitée",
    "summary": "rapport de chercheur, exploit fonctionnel joint",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'
```

La variable spéciale `externalLink` devient un lien cliquable dans l'enregistrement de la notification : décrocher place le répondant à un tap du ticket qui contient les détails.

À brancher, à peu près par ordre de fréquence en tant que premier signal :

- **Votre file PSIRT ou d'accueil sécurité** — un webhook lorsqu'un ticket est étiqueté candidat CRA.
- **Les avis de sécurité GitHub et les alertes Dependabot** sur les dépôts qui construisent des produits livrés ([intégration GitHub](/docs/developer/github)).
- **Votre SIEM, EDR ou WAF**, pour les détections visant l'infrastructure de build, de publication ou de signature — l'article 14(5) vise explicitement les incidents pouvant conduire à l'introduction de code malveillant.
- **Les flux de renseignement sur les vulnérabilités** que vous consommez déjà, filtrés sur les composants présents dans vos propres SBOM.

### Étape 3 — Utilisez des conditions pour ne faire sonner que les candidats plausibles

**C'est cette étape qui préserve la crédibilité du canal.** Les [conditions](/docs/conditions) d'Echobell évaluent les mêmes variables et en-têtes HTTP que vos modèles, et le canal ne se déclenche que si l'expression est vraie :

```
craCandidate == true && confirmed == true
```

Ou filtrez sur un en-tête si le système émetteur ne peut pas façonner son corps de requête :

```
header["x-cra-severity"] == "reportable"
```

Placez le seuil à « une personne compétente devrait regarder cela dans l'heure », pas à « c'est assurément signalable ». Décider si l'article 14 est engagé est un jugement qui exige une personne disposant des faits ; le rôle du canal est d'amener cette personne aux faits, vite. Sur-filtrer ici est l'erreur coûteuse, car un signalement jamais entamé est pire qu'un appel dont vous n'aviez pas besoin.

### Étape 4 — Attrapez les systèmes qui n'envoient que des e-mails

Le premier contact venu de l'extérieur arrive le plus souvent par e-mail : le chercheur, le client, le CSIRT national, le fournisseur de composants. Chaque canal Echobell peut disposer de sa propre adresse : une simple règle de transfert sur `security@` convertit ces messages en appels ([déclencheurs e-mail](/docs/email-trigger)).

Les déclencheurs e-mail exposent `from`, `to`, `subject`, `text` et `html` comme variables : vous pouvez filtrer sans rien parser.

```
subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")
```

Convenez d'un marqueur d'objet avec vos déclarants habituels et vos fournisseurs clés, puis filtrez dessus. C'est un petit détail contractuel qui transforme une boîte non structurée en signal routable.

### Étape 5 — Mettez tous les représentants enregistrés sur le canal

Partagez le canal avec toutes les personnes réellement en mesure de déposer : le représentant autorisé principal, le suppléant, et le responsable sécurité capable de trancher sur l'article 14. Chaque abonné choisit son type de notification : la personne d'astreinte peut être en **Appel** et le reste du groupe en **Sensible au temps**.

C'est là tout l'enjeu. La SRP exige une personne physique enregistrée et validée. Si une seule personne de l'entreprise est enregistrée, votre délai de 24 heures repose sur un point de défaillance unique doté d'une batterie de smartphone.

### Étape 6 — Répétez avant le 11 septembre, pas après

Deux répétitions, toutes deux à faire ce mois-ci :

1. **Le chemin d'alerte.** Lancez le `curl` ci-dessus avec Ne pas déranger réellement activé, sur le téléphone qui sera vraiment sur la table de nuit. Activez **Réessayer les appels échoués** dans l'application pour qu'un appel qui échoue soit retenté. Un chemin d'escalade non testé n'est qu'une hypothèse.
2. **Le chemin de dépôt.** Déroulez un signalement sur papier à l'aide des guides pas à pas d'enregistrement et de soumission de l'ENISA, mis à jour tout au long d'août 2026 ([SRP de l'ENISA](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp)). Créez les comptes EU Login dès maintenant, confirmez quel CSIRT est votre coordinateur, et envoyez tôt l'invitation au représentant suppléant — elle expire au bout de sept jours.

La seconde répétition comporte une subtilité à connaître : dans les orientations de juillet de l'ENISA, l'URL publique de la plateforme était encore mentionnée comme « à fournir au lancement », rendant impossible un test réel de bout en bout ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)). L'ENISA s'est engagée à ce que la plateforme soit opérationnelle au 11 septembre 2026. Répétez tout ce qui dépend de vous et ne faites pas de l'état de préparation de la plateforme une raison de retarder le vôtre.

## Ce qu'Echobell ne fait pas

Être précis ici compte plus que d'habitude, parce que le sujet est réglementaire :

- **Cela ne vous rend pas conforme.** Echobell est un canal de notification. Cartographier vos produits, faire tourner un processus de gestion des vulnérabilités, décider si l'article 14 est engagé, vous enregistrer sur la SRP et déposer dans les temps : tout cela vous incombe. Aucun outil d'alerte n'a jamais satisfait une obligation de signalement.
- **Il ne dépose rien.** Il n'existe pas d'API de dépôt, et s'il en existait une, ce ne serait pas Echobell qui l'appellerait. Il fait sonner un téléphone ; une personne enregistrée fait le reste.
- **Ce n'est pas un horodatage juridique.** La variable `{{time}}` enregistre le moment où le déclencheur est parvenu à Echobell, en UTC. Le début de la « prise de connaissance » est une question de fait propre à votre organisation, et c'est votre registre d'incidents — pas une notification push — qui la documente.
- **Il n'a ni politique d'escalade ni accusé de réception.** Pas de « si personne ne répond en dix minutes, appeler le suivant », pas de rotation, pas de piste d'audit indiquant qui a accusé réception de quoi. Pour cela, il faut une plateforme d'incidents — voir [les alternatives à Opsgenie](/blog/opsgenie-end-of-life-alternatives).
- **Il ne garantit pas la livraison.** Un appel dépend de l'infrastructure de push, du réseau et d'un téléphone chargé. Voyez-le comme la couche qui réduit l'écart entre l'arrivée d'un fait et sa connaissance par une personne, pas comme un contrôle à présenter en audit.
- **Il ne suit pas l'heure locale.** Les variables temporelles intégrées sont uniquement en UTC et ne suivent pas l'heure d'été. Les conditions qui délimitent une plage horaire demandent un ajustement manuel deux fois par an.

## FAQ

### Utiliser Echobell nous rend-il conformes au CRA ?

Non. Le CRA impose des obligations aux fabricants, et aucune application de notification ne peut s'en acquitter. Ce qu'Echobell adresse, c'est un mode de défaillance précis : l'alerte précoce de 24 heures est manquée parce que la personne qui aurait pu la déposer ne l'a appris que le jour ouvré suivant. C'est une défaillance réelle et fréquente, mais ce n'est qu'une pièce d'un programme de conformité bien plus vaste.

### Quand le compte à rebours de 24 heures démarre-t-il vraiment ?

Lorsque le fabricant prend connaissance de la vulnérabilité activement exploitée ou de l'incident grave. Le règlement ne définit pas d'instant exact, et la prise de connaissance dépend des faits et de la rapidité avec laquelle ils peuvent être établis ([DLA Piper](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations)). En pratique, cela plaide pour un tri rapide et documenté : plus l'écart entre l'arrivée d'un signal et son évaluation est grand, plus il sera difficile à expliquer par la suite.

### Nous sommes une petite entreprise. Sommes-nous exemptés ?

Pas du signalement. L'article 64 exclut les microentreprises et les petites entreprises des amendes administratives spécifiquement pour non-respect du délai de 24 heures de l'article 14(2)(a) ou 14(4)(a). L'obligation de signaler demeure, la notification à 72 heures et le rapport final ne sont pas concernés, et les définitions de microentreprise et de petite entreprise ne sont pas à supposer. Considérez cela comme une atténuation étroite, pas comme un laissez-passer.

### Notre boîte sécurité est surveillée aux heures ouvrées. N'est-ce pas suffisant ?

Seulement si vous acceptez de perdre jusqu'aux deux tiers de la fenêtre lors d'un week-end ordinaire. Un signalement arrivé vendredi à 18 h vous laisse une échéance au samedi 18 h. La surveillance en heures ouvrées est un réglage par défaut raisonnable pour presque tout le reste ; le compte à rebours de 24 heures est précisément le cas qu'elle ne couvre pas.

### Conformité, juridique et ingénierie peuvent-ils recevoir la même alerte ?

Oui, et ils le devraient. Partagez un canal et chaque abonné est notifié au même déclenchement, avec son propre niveau d'urgence. L'ingénieur qui confirme l'exploitation et la personne qui déposera le formulaire doivent démarrer à la même minute, pas l'un après l'autre.

### Cela aide-t-il pour l'obligation d'information des utilisateurs de l'article 14(8) ?

Indirectement. L'article 14(8) impose d'informer les utilisateurs affectés de la vulnérabilité ou de l'incident et, si nécessaire, des mesures correctives. C'est de la communication client, qui passe par vos propres canaux. Echobell peut réveiller en même temps les personnes qui portent cette communication et celles qui portent le dépôt, afin que les deux chantiers démarrent ensemble.

### Nous déclarons déjà au titre de NIS2 ou de DORA. Est-ce la même chose ?

Non, même si les formes se ressemblent. NIS2 et DORA imposent des devoirs à des entités selon le secteur et la criticité ; le CRA les impose à des fabricants selon les produits qu'ils mettent sur le marché de l'UE. Une même organisation peut être soumise aux trois, avec des horloges et des destinataires différents. Si ces régimes vous concernent aussi, voir [les alertes de signalement d'incident DORA et NIS2](/blog/dora-nis2-incident-reporting-alerts) — la couche d'alerte peut être mutualisée même quand les obligations ne le sont pas.

### L'appel traverse-t-il vraiment Ne pas déranger ?

Les notifications de type Appel sont délivrées comme des alertes d'appel, ce qui leur permet de percer le mode Concentration sur iOS. Ce n'est pas magique : cela dépend toujours des réglages du système, du réseau et d'un téléphone chargé. Testez-le sur l'appareil réel, avec le mode Concentration réellement actif, avant de compter dessus — et activez **Réessayer les appels échoués**.

### Est-ce réservé à iOS ?

Non. Echobell est disponible sur iOS et sur [Android via Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid) ([sortie Android](/blog/echobell-android-release)). Le comportement des alertes de type appel diffère selon la plateforme : testez sur l'appareil que la personne d'astreinte aura réellement sur elle.

### Que mettre dans le payload du webhook ?

Le minimum pour décider de se lever : le produit, le type de signal, une ligne de contexte, et un `externalLink` vers le ticket qui contient le détail. Echobell conserve le contenu et l'historique des notifications sur l'appareil et ne garde côté serveur que les comptes, canaux et abonnements ([modèle de confidentialité](/docs/features)), mais la bonne habitude avec du matériel sensible reste d'envoyer un pointeur, pas la substance.

---

## À lire aussi

- [Alertes de signalement d'incident DORA et NIS2](/blog/dora-nis2-incident-reporting-alerts)
- [Comment venir à bout de la fatigue d'alerte](/blog/fix-alert-fatigue-developer-guide)
- [Comment contourner le mode Concentration d'iOS pour les alertes critiques](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [Alternatives à Opsgenie après sa fin de vie](/blog/opsgenie-end-of-life-alternatives)
- [Guide d'intégration webhook](/docs/webhook)
- [Déclencheurs e-mail](/docs/email-trigger)
- [Guide des conditions](/docs/conditions)