Routage par Tags & Tentatives

Les tags Apprise ne font pas que regrouper des services — ils peuvent piloter l’ordre de livraison, les chaînes de secours et le comportement en cas d’échec sans modifier une seule ligne de code applicatif.

Cette page explique comment configurer ces fonctionnalités dans vos fichiers de configuration et comment les contrôler depuis la bibliothèque Python ou la CLI.

---

Tags de Priorité

Chaque tag dans un fichier de configuration peut porter un préfixe numérique de priorité séparé par deux-points : N:nomdetag.

Les numéros inférieurs signifient une urgence plus haute — ils sont traités en premier.

Note

Le numero de priorite est uniquement un marqueur de regroupement et d’ordre de tri. Les services qui partagent le meme nom de tag et le meme numero de priorite sont dispatches ensemble comme un seul groupe. Les groupes s’executent dans l’ordre numerique croissant (le numero le plus bas en premier). Les valeurs choisies n’ont pas d’importance en elles-memes — 2, 50 et 9999 sont aussi valides que 1, 2 et 3. Seul leur ordre relatif compte.

TEXT

# Priorité 1 -- canaux d'alerte principaux (urgence maximale)
1:alerts=slack://tokenA/tokenB/tokenC
1:alerts=discord://webhook_id/webhook_token

# Priorité 2 -- canaux secondaires (utilisés uniquement si la priorité 1 échoue entièrement)
2:alerts=telegram://bottoken/chatid

# Priorité 5 -- dernier recours
5:alerts=mailto://user:pass@example.com

Les tags sans préfixe de priorité ont par défaut la priorité 0 (urgence maximale).

YAML

version: 1
urls:
  # Priorité 1 -- canaux d'alerte principaux (urgence maximale)
  - slack://tokenA/tokenB/tokenC:
      tag: 1:alerts

  - discord://webhook_id/webhook_token:
      tag: 1:alerts

  # Priorité 2 -- canaux secondaires (utilisés uniquement si la priorité 1 échoue entièrement)
  - telegram://bottoken/chatid:
      tag: 2:alerts

  # Priorité 5 -- dernier recours
  - mailto://user:pass@example.com:
      tag: 5:alerts

Les tags sans préfixe de priorité ont par défaut la priorité 0 (urgence maximale).

---

Fonctionnement de l’Envoi

Mode Escalade (par défaut)

Lorsque vous déclenchez un tag sans préfixe de priorité, Apprise utilise la chaîne d’escalade :

1. Les services sont regroupés par priorité de tag configurée.
2. Le groupe au numéro le plus bas (urgence la plus haute) s’exécute en premier.
3. Si chaque service de ce groupe réussit, Apprise retourne True immédiatement — les groupes de numéros supérieurs ne sont jamais déclenchés.
4. Si un service du groupe échoue, Apprise escalade vers le niveau de priorité suivant.

# Déclencher tous les services 'alerts' avec la chaîne d'escalade.
# Les entrées de priorité 1 s'exécutent en premier. Si elles réussissent toutes,
# les entrées de priorité 5 ne sont jamais déclenchées.
apobj.notify(body="Utilisation disque à 90%", tag="alerts")

# Équivalent CLI
apprise --config=config.yml --tag="alerts" --body="Utilisation disque à 90%"

Formation des Groupes

Tous les services partageant le même nom de tag et le même numéro de priorité sont traités comme un seul groupe. Le groupe est considéré comme réussi uniquement si chaque service qu’il contient réussit. Si un seul service échoue, Apprise escalade immédiatement vers le groupe au numéro supérieur suivant.

Les tags sans préfixe numérique ont par défaut la priorité 0 — le niveau d’urgence le plus élevé. Cela signifie qu’il est possible de mélanger des versions simples et préfixées d’un même tag pour créer une chaîne d’escalade sans modifier les entrées d’URL existantes :

TEXT

# Priorité 0 (par défaut, urgence maximale) -- ces deux entrées forment le premier groupe
abc=slack://tokenA/tokenB/tokenC
abc=discord://webhook_id/webhook_token

# Priorité 1 -- secours si le groupe de priorité 0 échoue
1:abc=telegram://bottoken/chatid

YAML

version: 1
urls:
  # Priorité 0 (par défaut, urgence maximale) -- ces deux entrées forment le premier groupe
  - slack://tokenA/tokenB/tokenC:
      tag: abc

  - discord://webhook_id/webhook_token:
      tag: abc

  # Priorité 1 -- secours si le groupe de priorité 0 échoue
  - telegram://bottoken/chatid:
      tag: 1:abc

Lorsque notify(tag="abc") est appelé avec la configuration ci-dessus :

1. Le groupe de priorité 0 (Slack + Discord) s’exécute en premier.
2. Si les deux réussissent, True est retourné — Telegram n’est jamais contacté.
3. Si l’un ou l’autre échoue, Apprise escalade vers le groupe de priorité 1 (Telegram).

Les tags sans préfixe ayant par défaut la priorité 0, les définitions abc et 0:abc sont entièrement équivalentes dans une configuration de service. Toutes deux placent le service dans le groupe de priorité 0, et un filtre "abc" comme un filtre "0:abc" correspondent aux services définis avec l’une ou l’autre forme. Si les deux formes figurent dans le même fichier de configuration, ces services seront toujours distribués ensemble comme un groupe unique.

Mode Exclusif

Lorsque vous spécifiez un préfixe de priorité dans le filtre, Apprise ignore la chaîne d’escalade et ne notifie que les services dont le tag correspondant porte exactement cette priorité.

# Déclencher UNIQUEMENT les entrées 'alerts' configurées avec la priorité 2.
# Les entrées de priorité 1 et 5 ne sont pas affectées.
apobj.notify(body="Fenêtre de maintenance planifiée", tag="2:alerts")

# Équivalent CLI
apprise --config=config.yml --tag="2:alerts" --body="Fenêtre de maintenance planifiée"

Valeur du filtre	Comportement
"alerts"	Chaîne d’escalade — priorité la plus haute (numéro le plus bas) d’abord
"2:alerts"	Exclusif — uniquement les entrées alerts de priorité 2
"0:alerts"	Exclusif — uniquement les entrées de priorité 0 (alerts et 0:alerts sont identiques)

Note

Si aucun service ne correspond à la priorité exacte spécifiée, rien n’est envoyé. notify() retourne None et la CLI se termine avec le code 3 (aucun service correspondant trouvé). C’est intentionnel — un filtre exclusif est une sélection précise, pas une demande de secours.

Comportement en cas d’echec de chaine

Quand notify() execute plusieurs chaines OR independantes en parallele, le comportement par defaut est de laisser chaque chaine se terminer avant de retourner — meme si une chaine a deja echoue. Cela garantit que chaque service configure obtient au moins une tentative.

Pour arreter immediatement tous les rounds d’escalade restants des qu’une chaine epuise ses groupes de priorite sans succes, definissez abort_on_chain_failure=True sur votre AppriseAsset :

from apprise import Apprise, AppriseAsset

asset = AppriseAsset(abort_on_chain_failure=True)
apobj = Apprise(asset=asset)

# ...ajout des services...

# Si la chaine 'ops' echoue completement, Apprise s'arrete immediatement
# et ne lance pas de nouveaux rounds d'escalade pour la chaine 'securite'.
apobj.notify(body="Alerte critique", tag=["ops", "securite"])

abort_on_chain_failure	Comportement en cas d’echec d’une chaine
False (defaut)	Toutes les chaines se terminent ; chaque service est tente
True	Les rounds restants sont ignores ; False est retourne immediatement

---

Tentatives et Délai par Service

Chaque service peut être configuré avec son propre nombre de tentatives et délai inter-tentative. Ces paramètres sont indépendants de la chaîne d’escalade et s’appliquent à chaque échec de livraison.

• retry — nombre de tentatives supplémentaires après le premier échec (0 = pas de nouvelle tentative).
• wait — secondes de pause entre les tentatives (décimales acceptées ; 0.0 = pas de pause).

TEXT

Ajoutez ?retry=N et/ou ?wait=S directement à l’URL sous forme de paramètres de requête.

# jusqu'à 3 nouvelles tentatives, avec 5 secondes d'attente entre chacune
1:alerts=slack://tokenA/tokenB/tokenC?retry=3&wait=5

# jusqu'à 2 nouvelles tentatives avec 1,5 seconde d'attente
1:alerts=discord://webhook_id/webhook_token?retry=2&wait=1.5

# Canal de secours -- pas besoin de nouvelles tentatives (comportement par défaut)
5:alerts=mailto://user:pass@example.com

YAML

Utilisez les clés retry: et wait: sous chaque entrée d’URL.

version: 1
urls:
  # jusqu'à 3 nouvelles tentatives, avec 5 secondes d'attente entre chacune
  - slack://tokenA/tokenB/tokenC:
      tag: 1:alerts
      retry: 3
      wait: 5

  # jusqu'à 2 nouvelles tentatives avec 1,5 seconde d'attente
  - discord://webhook_id/webhook_token:
      tag: 1:alerts
      retry: 2
      wait: 1.5

  # Canal de secours -- pas besoin de nouvelles tentatives
  - mailto://user:pass@example.com:
      tag: 5:alerts

Note

wait n’a de sens que lorsque retry est supérieur à zéro. Un service avec retry=0 effectue exactement une tentative quelle que soit la valeur de wait.

Valeurs acceptées

Paramètre	Type	Contraintes	Par défaut
retry	int	0 à 10	0
wait	float	0.0 à 20.0 ; les entiers sont promus en flottant	0.5

Les valeurs invalides (nombres négatifs, chaînes non numériques, inf, nan) sont rejetées et reviennent à la valeur par défaut de l’asset (voir Valeurs par Défaut Globales ci-dessous).

---

Services Optionnels

Le paramètre optional marque un service comme “souhaitable mais non indispensable”. Lorsque optional=yes est activé sur un service, un échec de livraison pour ce service est silencieusement absorbé — l’appel global à notify() retourne quand même True, tant que chaque service requis (non optionnel) a réussi.

Ce paramètre est utile pour tout service que vous souhaitez notifier opportunistement : envoyer la notification si le point de terminaison est disponible, mais ne pas considérer son absence comme un échec aux yeux de l’application appelante.

Exemple concret — écrans d’affichage domestiques

Imaginons que votre système domotique possède quatre écrans Kodi avec le tag media. Vous souhaitez afficher une notification sur les écrans actuellement allumés, mais vous ne voulez pas qu’un écran éteint déclenche une alerte d’astreinte à trois heures du matin.

TEXT

# Les quatre écrans sont optionnels -- leur indisponibilité n'est jamais une erreur.
media=kodi://192.168.1.10
media=kodi://192.168.1.11
media=kodi://192.168.1.12
media=kodi://192.168.1.13

Pour les rendre optionnels, ajoutez ?optional=yes à chaque URL :

media=kodi://192.168.1.10?optional=yes
media=kodi://192.168.1.11?optional=yes
media=kodi://192.168.1.12?optional=yes
media=kodi://192.168.1.13?optional=yes

YAML

version: 1
urls:
  - kodi://192.168.1.10:
      tag: media
      optional: yes

  - kodi://192.168.1.11:
      tag: media
      optional: yes

  - kodi://192.168.1.12:
      tag: media
      optional: yes

  - kodi://192.168.1.13:
      tag: media
      optional: yes

# Retourne True même si tous les écrans sont éteints ou inaccessibles.
apobj.notify(body="Le dîner est prêt", tag="media")

apprise --config=config.yml --tag="media" --body="Le dîner est prêt"

Interaction entre optional et les services requis

Le paramètre est par service. Vous pouvez librement mélanger des services optionnels et requis au sein du même groupe de tags. Le résultat global suit ces règles :

Services dans le lot	Résultat
Tous requis, tous réussissent	True
Tous requis, un ou plusieurs échouent	False
Tous optionnels, tous échouent	True
Tous optionnels, tous réussissent	True
Mélange requis/optionnels ; tous les requis réussissent	True
Mélange requis/optionnels ; au moins un requis échoue	False

En résumé : les échecs optionnels sont invisibles pour l’appelant. Seul l’échec d’un service requis peut faire retourner False à notify().

Interaction entre optional et les tentatives

Activer optional=yes ne saute pas le service et ne contourne pas la logique de tentatives. La livraison est toujours tentée, et si retry est supérieur à zéro, Apprise retentera le nombre de fois configuré avant d’abandonner. Ce n’est qu’après l’épuisement de toutes les tentatives qu’Apprise vérifie le paramètre optional pour décider d’absorber ou non l’échec.

# Ce service est tenté jusqu'à 4 fois (tentative initiale + 3 nouvelles tentatives)
# avec une pause de 2 secondes entre chacune. Si les quatre tentatives échouent,
# l'échec est silencieusement absorbé grâce à optional=yes.
media=kodi://192.168.1.10?optional=yes&retry=3&wait=2

- kodi://192.168.1.10:
    tag: media
    optional: yes
    retry: 3
    wait: 2

Utilisation de optional depuis Python

Vous pouvez définir ce paramètre directement sur n’importe quel objet service chargé, ou le passer en argument lors de la construction manuelle d’objets service :

import apprise

apobj = apprise.Apprise()

# Option 1 -- paramètre de requête URL (fonctionne avec tous les chargeurs de config)
apobj.add("kodi://192.168.1.10?optional=yes")

# Option 2 -- définir l'attribut directement après chargement
obj = apprise.Apprise.instantiate("kodi://192.168.1.10")
obj.optional = True
apobj.add(obj)

# Option 3 -- argument mot-clé du constructeur
from apprise.plugins.NotifyJSON import NotifyJSON
svc = NotifyJSON(host="192.168.1.10", optional=True)
apobj.add(svc)

# Les trois options produisent le même comportement : les échecs sont silencieusement absorbés.
result = apobj.notify(body="Le dîner est prêt")
print(result)  # True même si chaque point de terminaison était inaccessible

Exemples supplémentaires

Journal de débogage non critique associé à un canal d’alerte requis :

TEXT

# Requis : l'ingénieur d'astreinte doit toujours être averti.
alerts=slack://tokenA/tokenB/tokenC

# Optionnel : enregistrer dans le canal de diagnostic interne s'il est disponible,
# mais ne jamais considérer son absence comme un échec.
alerts=json://diagnostics.internal/api/events?optional=yes

YAML

version: 1
urls:
  # Requis : l'ingénieur d'astreinte doit toujours être averti.
  - slack://tokenA/tokenB/tokenC:
      tag: alerts

  # Optionnel : enregistrer dans le canal de diagnostic interne si disponible.
  - json://diagnostics.internal/api/events:
      tag: alerts
      optional: yes

# Retourne True si Slack a réussi, quel que soit l'état du journal JSON.
apobj.notify(body="Base de données inaccessible", tag="alerts")

Groupe de tags entièrement optionnel — diffusion au mieux :

TEXT

# Notifier les trois écrans s'ils sont accessibles ; ne jamais échouer s'ils ne le sont pas.
affichages=kodi://192.168.1.10?optional=yes
affichages=kodi://192.168.1.11?optional=yes
affichages=kodi://192.168.1.12?optional=yes

YAML

version: 1
urls:
  - kodi://192.168.1.10:
      tag: affichages
      optional: yes

  - kodi://192.168.1.11:
      tag: affichages
      optional: yes

  - kodi://192.168.1.12:
      tag: affichages
      optional: yes

# Retourne toujours True quel que soit le nombre d'écrans ayant répondu.
apobj.notify(body="Mouvement détecté", tag="affichages")

---

Valeurs par Défaut Globales via AppriseAsset

Si vous souhaitez que chaque service d’une session Apprise partage les mêmes valeurs par défaut de tentatives et d’attente sans modifier chaque URL, définissez-les sur AppriseAsset :

from apprise import Apprise, AppriseAsset

asset = AppriseAsset(
    default_service_retry=2,   # jusqu'à 2 nouvelles tentatives en cas d'échec avant d'abandonner
    default_service_wait=3.0,  # attendre 3 secondes entre les tentatives
)

apobj = Apprise(asset=asset)
apobj.add("slack://tokenA/tokenB/tokenC")
apobj.add("discord://webhook_id/webhook_token")

apobj.notify(body="Valeurs par défaut retry/wait appliquées à chaque service")

Les valeurs par URL (?retry= / ?wait= ou clés YAML) remplacent les valeurs par défaut de l’asset pour ce service spécifique uniquement. Tous les autres services utilisent toujours les valeurs par défaut de l’asset.

---

Remplacement du Nombre de Tentatives par Appel

Un :N en fin de valeur de filtre de tag remplace le nombre de tentatives pour chaque service correspondant, pour cet appel uniquement. La configuration permanente du service n’est pas modifiée.

# Réessayer chaque service correspondant jusqu'à 5 fois pour cet appel uniquement
apobj.notify(body="Alerte critique", tag="alerts:5")

# Correspondance exclusive priorité 2 ET jusqu'à 3 tentatives par service
apobj.notify(body="Priorité 2 uniquement", tag="2:alerts:3")

# Équivalents CLI
apprise --config=config.yml --tag="alerts:5"   --body="Alerte critique"
apprise --config=config.yml --tag="2:alerts:3" --body="Priorité 2 uniquement"

Le suffixe :N suit les mêmes règles de validation que le paramètre URL retry. Sa spécification n’affecte pas wait — chaque service utilise toujours sa valeur d’attente configurée entre les tentatives.

Filtres OR et AND multi-tags

Apprise supporte deux façons de combiner des noms de tags dans un seul appel à notify.

Motif	Signification	Exemple
OR — plusieurs valeurs de tag séparées	Correspond aux services portant l’un ou l’autre des tags listés	Plusieurs indicateurs --tag dans la CLI ; une liste de chaînes de tags en Python
AND — plusieurs noms de tags dans une seule entrée de filtre	Correspond uniquement aux services portant tous les tags listés	Un seul --tag "a, b" dans la CLI ; une liste imbriquée en Python

Avec OR, chaque nom de tag forme une chaîne d’escalade indépendante. Toutes les chaînes doivent trouver un groupe de priorité entièrement réussi avant que notify() retourne True. Un suffixe :N sur un token ne s’applique qu’aux services correspondant à ce token ; les autres ne sont pas affectés.

# OR -- les services devops obtiennent retry=3 ; management obtient retry=2.
# Chaque chaîne d'escalade de tag s'exécute indépendamment.
apobj.notify(body="Alerte équipe", tag=["devops:3", "management:2"])

# OR -- plusieurs indicateurs --tag ; chacun est une chaîne indépendante.
apprise --config=config.yml \
        --tag="devops:3" \
        --tag="management:2" \
        --body="Alerte équipe"

Si tous les services devops réussissent dans leur groupe de priorité le plus bas, Apprise envoie quand même la chaîne management — les deux chaînes sont indépendantes l’une de l’autre.

Avec AND, les services doivent porter tous les tags du groupe pour être sélectionnés. Les services correspondant à un filtre AND partagent une seule chaîne d’escalade.

# AND -- le service doit porter "devops" ET "management" pour correspondre.
apobj.notify(body="Alerte combinée", tag=[["devops", "management"]])

# AND -- valeurs séparées par des virgules dans un seul indicateur --tag.
apprise --config=config.yml --tag="devops, management" --body="Alerte combinée"

---

Exemple Complet

L’exemple suivant combine les trois fonctionnalités : escalade par priorité, tentatives/attente par service, et remplacement du nombre de tentatives par appel.

Fichier de configuration

TEXT

# --- Canaux principaux (priorité 1) ---
# jusqu'à 2 nouvelles tentatives, 2 secondes d'attente entre chacune
1:alerts=slack://tokenA/tokenB/tokenC?retry=2&wait=2
1:alerts=discord://webhook_id/webhook_token?retry=2&wait=2

# --- Canal secondaire (priorité 5 -- secours) ---
# Une seule tentative suffit ; les canaux principaux ont déjà réessayé
5:alerts=mailto://user:pass@pagerduty.example.com

YAML

version: 1
urls:
  # Canaux principaux (priorité 1)
  - slack://tokenA/tokenB/tokenC:
      tag: 1:alerts
      retry: 2
      wait: 2

  - discord://webhook_id/webhook_token:
      tag: 1:alerts
      retry: 2
      wait: 2

  # Canal secondaire (priorité 5 -- secours)
  # Une seule tentative ; les canaux principaux ont déjà réessayé
  - mailto://user:pass@pagerduty.example.com:
      tag: 5:alerts

Bibliothèque Python

from apprise import Apprise, AppriseConfig

config = AppriseConfig()
config.add("config.yml")

apobj = Apprise()
apobj.add(config)

# Alerte normale -- chaîne d'escalade
# Slack et Discord (priorité 1) s'exécutent en premier ; chacun réessaie jusqu'à 2 fois
# avec une pause de 2 secondes. Si les deux réussissent, PagerDuty (priorité 5) est ignoré.
apobj.notify(body="Utilisation disque à 90%", tag="alerts")

# Incident critique -- jusqu'à 5 nouvelles tentatives pour cet appel uniquement
apobj.notify(body="Base de données inaccessible", tag="alerts:5")

# Fenêtre de maintenance -- cibler uniquement le canal email de secours (priorité 5)
apobj.notify(body="Coupure planifiée dans 30 min", tag="5:alerts")

CLI

# Alerte normale -- chaîne d'escalade
apprise --config=config.yml --tag="alerts" \
        --body="Utilisation disque à 90%"

# Incident critique -- jusqu'à 5 nouvelles tentatives pour cet appel uniquement
apprise --config=config.yml --tag="alerts:5" \
        --body="Base de données inaccessible"

# Fenêtre de maintenance -- cibler uniquement le canal email de secours (priorité 5)
apprise --config=config.yml --tag="5:alerts" \
        --body="Coupure planifiée dans 30 min"

---

Variantes

Les exemples ci-dessous illustrent des schemas de notification courants.

Note

Les numeros de priorite sont des marqueurs d’ordre relatif, pas des valeurs fixes. Un service a la priorite 2 sera toujours envoye avant un service a la priorite 500 pour le meme tag — les valeurs exactes n’ont pas d’importance, seul leur ordre compte.

Exemple 1

Tag unique avec deux niveaux d’escalade — les valeurs 2 et 50 montrent que les numeros sont arbitraires ; seul l’ordre importe.

TEXT

# Premier essai (numero inferieur = urgence superieure)
2:alertes=slack://tokenA/tokenB/tokenC

# Secours ; s'execute uniquement si la priorite 2 echoue
50:alertes=mailto://user:pass@example.com

YAML

version: 1
urls:
  - slack://tokenA/tokenB/tokenC:
      tag: 2:alertes

  - mailto://user:pass@example.com:
      tag: 50:alertes

# Chaine d'escalade : Slack d'abord, e-mail seulement en cas d'echec
apobj.notify(body="Alerte", tag="alertes")

apprise --config=config.yml --tag="alertes" --body="Alerte"

Exemple 2

Trois chaines OR avec plusieurs niveaux de priorite — alpha, beta et gamma sont des chaines independantes dispatchees simultanement. Au sein de chaque chaine, les groupes de priorite inferieure s’executent en premier ; les echecs escaladent au niveau suivant. Si une chaine epuise tous ses niveaux sans succes, Apprise s’arrete immediatement et retourne False sans lancer de nouveaux rounds pour les autres chaines.

TEXT

# alpha : trois niveaux avec des valeurs de priorite arbitraires
1:alpha=slack://tokenA/tokenB/tokenC
1:alpha=mailto://user:pass@gmail.com
5:alpha=telegram://bottoken/chatid
700:alpha=discord://webhook_id/webhook_token

# beta : un seul niveau a la priorite 500
500:beta=discord://webhook_id2/webhook_token2

# gamma : deux niveaux ; sans prefixe = priorite 0 (la plus haute)
gamma=telegram://bottoken2/chatid2
200:gamma=telegram://bottoken3/chatid3

YAML

version: 1
urls:
  # alpha -- trois niveaux d'escalade
  - slack://tokenA/tokenB/tokenC:
      tag: 1:alpha
  - mailto://user:pass@gmail.com:
      tag: 1:alpha
  - telegram://bottoken/chatid:
      tag: 5:alpha
  - discord://webhook_id/webhook_token:
      tag: 700:alpha

  # beta -- niveau unique
  - discord://webhook_id2/webhook_token2:
      tag: 500:beta

  # gamma -- deux niveaux (sans prefixe = priorite 0)
  - telegram://bottoken2/chatid2:
      tag: gamma
  - telegram://bottoken3/chatid3:
      tag: 200:gamma

Ordre de dispatch quand les trois chaines sont combinees en OR :

Round	alpha	beta	gamma
1	Slack + Gmail (priorite 1)	Discord (priorite 500)	Telegram 2 (priorite 0)
2 (si echec au round 1)	Telegram (priorite 5)	— epuise —	Telegram 3 (priorite 200)
3 (si echec au round 2 pour alpha)	Discord (priorite 700)

apobj.notify(body="Diffusion", tag=["alpha", "beta", "gamma"])

apprise --config=config.yml \
        --tag="alpha" \
        --tag="beta" \
        --tag="gamma" \
        --body="Diffusion"

Exemple 3

Deux chaines OR independantes avec surcharge de tentatives par appel — chaque token porte son propre suffixe :N : les services devops obtiennent trois tentatives et les services direction en obtiennent deux.

TEXT

10:devops=slack://tokenA/tokenB/tokenC
10:direction=discord://webhook_id/webhook_token

YAML

version: 1
urls:
  - slack://tokenA/tokenB/tokenC:
      tag: 10:devops

  - discord://webhook_id/webhook_token:
      tag: 10:direction

# devops : retry=3 ; direction : retry=2
apobj.notify(body="Alerte equipe", tag=["devops:3", "direction:2"])

apprise --config=config.yml \
        --tag="devops:3" \
        --tag="direction:2" \
        --body="Alerte equipe"

Exemple 4

Filtre AND — seuls les services portant tous les tags listes sont dispatches.

TEXT

# Les deux tags sur la meme URL ; seul ce service correspond au filtre AND
devops direction=slack://tokenA/tokenB/tokenC

# Un seul tag "devops" -- ne correspond PAS au filtre AND
devops=discord://webhook_id/webhook_token

YAML

version: 1
urls:
  # Les deux tags sur la meme URL
  - slack://tokenA/tokenB/tokenC:
      tag:
        - devops
        - direction

  # Un seul tag -- ne correspond pas au filtre AND
  - discord://webhook_id/webhook_token:
      tag: devops

# AND -- le service doit porter "devops" ET "direction"
apobj.notify(body="Alerte combinee", tag=[["devops", "direction"]])

# AND -- valeurs separees par une virgule dans un seul flag --tag
apprise --config=config.yml --tag="devops, direction" --body="Alerte combinee"

Exemple 5

Dispatch exclusif — un prefixe de priorite dans le filtre cible uniquement ce niveau exact. Aucune chaine d’escalade n’est construite ; les services correspon- dants sont dispatches en un seul lot plat.

TEXT

2:alertes=slack://tokenA/tokenB/tokenC
50:alertes=mailto://user:pass@example.com

YAML

version: 1
urls:
  - slack://tokenA/tokenB/tokenC:
      tag: 2:alertes

  - mailto://user:pass@example.com:
      tag: 50:alertes

# Exclusif : seules les entrees de priorite 50 s'executent ; Slack est ignore
apobj.notify(body="Maintenance", tag="50:alertes")

apprise --config=config.yml --tag="50:alertes" --body="Maintenance"

---

Récapitulatif

Fonctionnalité	Où le configurer	Portée
Priorité de tag	N:nomdetag dans le fichier de configuration (TEXT ou YAML)	Par définition de service
Nombre de tentatives par service	Paramètre URL ?retry=N ou clé YAML retry:	Par définition de service
Délai inter-tentative par service	Paramètre URL ?wait=S ou clé YAML wait:	Par définition de service
Service optionnel	Paramètre URL ?optional=yes ou clé YAML optional: yes	Par définition de service
Valeurs par défaut globales	AppriseAsset(default_service_retry=N, default_service_wait=S)	Tous les services de la session
Envoi en escalade	notify(tag="nomdetag") ou --tag nomdetag (sans préfixe de priorité)	Un appel notify() / CLI
Envoi exclusif	notify(tag="N:nomdetag") ou --tag N:nomdetag	Un appel notify() / CLI
Remplacement des tentatives	notify(tag="nomdetag:N") ou --tag nomdetag:N	Un appel notify() / CLI
Envoi OR multi-tags	notify(tag=["tagA", "tagB"]) ou --tag tagA --tag tagB	Un appel notify() / CLI
Envoi AND multi-tags	notify(tag=[["tagA", "tagB"]]) ou --tag "tagA, tagB"	Un appel notify() / CLI
Envoi OR multi-tags avec tentatives par tag	notify(tag=["tagA:N", "tagB:M"]) ou --tag tagA:N --tag tagB:M	Un appel notify() / CLI
Arret anticipe sur echec de chaine	AppriseAsset(abort_on_chain_failure=True)	Tous les services de la session