# Deux services d’envoi en cascade : basculer si le premier échoue

> Une extension d'envoi critique peut tenter un second service si le premier renvoie une erreur, avec un délai d'observation avant retour au principal.

- Auteur : Clément Hadrot
- Publié le : 2026-05-13
- Mis à jour le : 2026-05-13
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/deux-services-envoi-cascade-basculer-premier-echoue/

## L’essentiel

- Un seul point de sortie pour un envoi critique devient un point de défaillance unique
- Une cascade tente un service secondaire uniquement après échec confirmé du principal
- Un délai d'observation évite d'osciller entre les deux services à chaque tentative

`WP_Error: cURL error 28: Connection timed out after 10000 milliseconds` — quand ce message apparaît sur le service d'envoi principal d'une extension qui transmet des convocations à des adhérents, chaque minute d'indisponibilité compte. Une architecture reposant sur un unique service d'envoi transforme la moindre panne de ce service en panne complète de la fonctionnalité, sans marge de manœuvre.

Ce cas concret traite de l'architecture d'une extension d'envoi critique capable de basculer vers un second service si le premier échoue, avec un délai d'observation avant de retenter le service principal. Le contenu des e-mails eux-mêmes, leur mise en forme ou leur personnalisation, ne fait pas partie du périmètre de cet article, volontairement centré sur le mécanisme de bascule.

## Le problème d'un point de sortie unique

La plupart des extensions se contentent d'un seul service d'envoi, appelé directement au moment où l'e-mail doit partir. Si ce service devient indisponible, même pour quelques minutes, chaque tentative d'envoi échoue silencieusement ou après un délai d'expiration coûteux, sans alternative prévue.

```
function envoyer_convocation( $destinataire, $sujet, $contenu ) {
    $reponse = wp_remote_post( 'https://api.service-principal.example/envoi', array(
        'body'    => array(
            'to'      => $destinataire,
            'subject' => $sujet,
            'html'    => $contenu,
        ),
        'timeout' => 10,
    ) );

    return ! is_wp_error( $reponse ) && 200 === wp_remote_retrieve_response_code( $reponse );
}
```

## Concevoir la cascade vers un service secondaire

> L'essentiel à retenir : Un seul point de sortie pour un envoi critique devient un point de défaillance unique ; Une cascade tente un service secondaire uniquement après échec confirmé du principal ; Un délai d'observation évite d'osciller entre les deux services à chaque tentative

Le principe de la cascade est simple : tenter le service principal, et seulement en cas d'échec confirmé, basculer immédiatement vers un second service configuré à l'avance, avec une structure de données et un format d'appel différents, qu'il faut donc adapter.

```
function envoyer_convocation_avec_cascade( $destinataire, $sujet, $contenu ) {
    if ( ! service_principal_indisponible() ) {
        $succes = tenter_envoi_service_principal( $destinataire, $sujet, $contenu );

        if ( $succes ) {
            return true;
        }

        marquer_service_principal_indisponible();
    }

    return tenter_envoi_service_secondaire( $destinataire, $sujet, $contenu );
}

function marquer_service_principal_indisponible() {
    set_transient( 'envoi_service_principal_indisponible', true, 5 * MINUTE_IN_SECONDS );
}

function service_principal_indisponible() {
    return (bool) get_transient( 'envoi_service_principal_indisponible' );
}
```

Le transient `envoi_service_principal_indisponible` joue le rôle de délai d'observation : une fois l'échec constaté, l'extension bascule directement sur le service secondaire pendant cinq minutes, sans retenter inutilement le service principal à chaque envoi suivant, ce qui éviterait de payer à nouveau le coût d'un délai d'expiration à chaque tentative.

## Pourquoi un délai d'observation, et pas un retour immédiat

Sans ce délai, l'extension retenterait le service principal à chaque nouvel envoi, même immédiatement après un échec. Si la panne dure plusieurs minutes, cela signifie autant de délais d'expiration subis que d'envois tentés durant cette période, avec un impact direct sur le temps de traitement de chaque convocation. Le délai d'observation regroupe ces tentatives inutiles en une seule pénalité, à l'origine de la bascule.

### Le retour au service principal doit rester progressif

À l'expiration du délai d'observation, l'extension retente le service principal sur le prochain envoi. Si ce service a effectivement retrouvé son fonctionnement normal, la bascule redevient inutile naturellement. Si la panne persiste, un nouvel échec redéclenche un nouveau délai d'observation, sans qu'aucune intervention manuelle ne soit nécessaire pour gérer la transition.

## Ce qu'il faut prévoir en plus du code de bascule

- Journaliser chaque bascule vers le service secondaire, avec l'horodatage et la raison de l'échec, pour identifier des pannes récurrentes du service principal.
- Vérifier que le format d'appel du service secondaire est réellement compatible, ou prévoir une fonction d'adaptation dédiée entre les deux structures de données.
- Ne jamais faire dépendre la disponibilité du transient de bascule d'un cache objet non persistant partagé entre plusieurs processus, au risque de perdre l'information de bascule en cours de route.

## Limites de cette approche

Cette architecture reste un mécanisme de bascule simple, pas un disjoncteur applicatif complet avec compteur d'échecs progressif ni remontée d'alerte automatique. Elle suffit néanmoins pour la grande majorité des extensions d'envoi critique, où l'objectif principal reste d'éviter qu'une panne de quelques minutes sur un service ne bloque totalement une fonctionnalité essentielle.

> Le meilleur service d'envoi secondaire est celui qu'on espère ne jamais avoir à utiliser, mais dont le format d'appel a déjà été testé avant la première vraie panne.

## En résumé

Une cascade à deux services, associée à un délai d'observation simple, suffit à transformer un point de défaillance unique en une architecture nettement plus résiliente, sans nécessiter de plateforme de résilience complexe. La configuration du second service et le test préalable de son format d'appel restent les étapes les plus souvent négligées, alors qu'elles conditionnent l'efficacité réelle de la bascule le jour où elle devient nécessaire.