# « 429 Too Many Requests » d’une API de LLM : la vraie reprise à mettre en place

> Comparer une nouvelle tentative immédiate à un backoff exponentiel face à un dépassement de quota d'API de modèle de langage, et choisir la bonne stratégie.

- Auteur : WordPress Développement
- Publié le : 2023-10-03
- Mis à jour le : 2023-10-03
- Catégorie : IA & MCP
- URL : https://www.wpmoderne.fr/ia-mcp/429-too-many-requests-api-llm-reprise/

## L’essentiel

- Une nouvelle tentative immédiate aggrave souvent le dépassement de quota
- Un backoff exponentiel espace les tentatives progressivement
- Un budget de requêtes en amont prévient le problème plutôt que le subir

Relancer immédiatement une requête qui vient d'échouer avec un code 429 semble une réaction naturelle : l'échec paraît temporaire, une nouvelle tentative rapide devrait aboutir. C'est pourtant exactement le comportement qui aggrave la situation, en ajoutant une requête supplémentaire à un service déjà en train de rejeter du trafic par manque de capacité disponible pour le compte concerné.

Comparer deux stratégies de reprise face à ce code d'erreur éclaire pourquoi l'une échoue en pratique là où l'autre stabilise le système : la nouvelle tentative immédiate d'un côté, le backoff exponentiel de l'autre.

## Pourquoi la nouvelle tentative immédiate échoue en pratique

Un code 429 signale que le quota de requêtes autorisé sur une fenêtre de temps donnée est déjà atteint. Relancer la requête dans la seconde qui suit ne change rien à cet état : la fenêtre de quota reste pleine, et la nouvelle tentative échoue à nouveau, avec le même code. Sur un site à trafic soutenu, plusieurs requêtes concurrentes appliquant la même logique de reprise immédiate peuvent même amplifier le problème, en multipliant les tentatives simultanées contre un service déjà saturé.

```
// Stratégie à éviter
for ( $tentative = 0; $tentative < 3; $tentative++ ) {
    $reponse = wp_remote_post( $url, $arguments );
    if ( 429 !== (int) wp_remote_retrieve_response_code( $reponse ) ) {
        break;
    }
    // aucune attente avant la tentative suivante
}
```

## Le backoff exponentiel espace les tentatives

> L'essentiel à retenir : Une nouvelle tentative immédiate aggrave souvent le dépassement de quota ; Un backoff exponentiel espace les tentatives progressivement ; Un budget de requêtes en amont prévient le problème plutôt que le subir

Un backoff exponentiel augmente le délai d'attente entre chaque tentative, en le multipliant à chaque échec. Cette progression laisse le temps à la fenêtre de quota de se libérer, plutôt que de la solliciter en continu :

```
function appeler_avec_backoff( string $url, array $arguments, int $max_tentatives = 3 ) {
    for ( $tentative = 0; $tentative < $max_tentatives; $tentative++ ) {
        $reponse = wp_remote_post( $url, $arguments );
        $code = wp_remote_retrieve_response_code( $reponse );

        if ( 429 !== (int) $code ) {
            return $reponse;
        }

        $delai_secondes = (int) ( 2 ** $tentative );
        sleep( $delai_secondes );
    }

    error_log( 'Échec définitif après ' . $max_tentatives . ' tentatives (429)' );
    return null;
}
```

### Respecter l'en-tête Retry-After lorsqu'il est fourni

Certaines API renvoient un en-tête `Retry-After` indiquant précisément le délai à respecter avant une nouvelle tentative. Lorsqu'il est présent, cette valeur doit primer sur le calcul exponentiel générique, car elle reflète l'état réel du quota côté fournisseur :

```
$retry_after = wp_remote_retrieve_header( $reponse, 'retry-after' );
$delai_secondes = $retry_after ? (int) $retry_after : (int) ( 2 ** $tentative );
```

## Pourquoi sleep() n'est pas anodin dans une requête WordPress

Utiliser `sleep()` dans une requête déclenchée pendant le chargement d'une page bloque le processus PHP concerné, et donc le visiteur, pendant toute la durée d'attente cumulée. Ce backoff n'a de sens que dans un contexte asynchrone : une tâche planifiée via `wp_schedule_single_event`, une commande WP-CLI, ou un traitement en arrière-plan qui n'attend aucun visiteur.

## Prévenir plutôt que subir : un budget de requêtes

Le backoff exponentiel gère l'incident une fois survenu. Une prévention plus efficace consiste à limiter en amont le nombre de requêtes envoyées sur une fenêtre de temps donnée, avant même d'atteindre le quota du fournisseur :

- Compter les appels effectués dans une transient à durée de vie glissante
- Refuser localement une requête supplémentaire si le budget de la fenêtre est déjà consommé
- Répartir les traitements groupés sur plusieurs créneaux plutôt qu'en une seule rafale

> Un budget de requêtes respecté en amont évite la majorité des codes 429 ; le backoff exponentiel reste une protection pour les cas où ce budget, malgré tout, se révèle insuffisant.

## Ce qu'il faut retenir

Face à un code 429, la reprise immédiate aggrave le problème qu'elle prétend résoudre, tandis que le backoff exponentiel, combiné au respect de l'en-tête `Retry-After` quand il existe, donne au service distant le temps de libérer son quota. Un budget de requêtes appliqué en amont reste toutefois la mesure la plus efficace, en réduisant la fréquence même de ces incidents.