# Trois techniques pour brider les appels qu’un agent envoie à un site WordPress

> Comparatif d'un compteur en transient, d'une file Action Scheduler et d'un middleware côté serveur web pour brider un agent trop actif.

- Auteur : WordPress Développement
- Publié le : 2025-05-20
- Mis à jour le : 2025-05-20
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/trois-techniques-brider-appels-agent/

## L’essentiel

- Le transient convient à un plafond simple par heure, sans file d'attente
- Action Scheduler lisse la charge dans le temps mais ajoute une latence
- Le middleware serveur protège même si le code PHP est contourné

Combien d'appels par minute un agent devrait-il pouvoir envoyer à un site WordPress avant que cela ne devienne un problème ? La réponse dépend du contexte, mais la question inverse compte tout autant : quelle technique choisir pour appliquer concrètement cette limite une fois qu'elle est fixée. Trois approches, testées sur des projets différents, apportent chacune une réponse adaptée à un contexte précis.

Ce comparatif comprend un compteur simple basé sur les transients WordPress, une file d'attente construite avec Action Scheduler, et un middleware appliqué au niveau du serveur web plutôt que dans le code PHP.

## Technique 1 : le compteur en transient

La première technique, la plus simple à mettre en œuvre, consiste à incrémenter un compteur stocké dans un transient à durée de vie fixe, et à refuser tout appel supplémentaire une fois le plafond atteint pour la période en cours.

```
function wpm_verifier_quota_agent( string $identifiant_agent, int $plafond_horaire = 60 ): bool {
    $cle = 'wpm_quota_' . $identifiant_agent;
    $compteur = get_transient( $cle );

    if ( false === $compteur ) {
        set_transient( $cle, 1, HOUR_IN_SECONDS );
        return true;
    }

    if ( $compteur >= $plafond_horaire ) {
        return false;
    }

    set_transient( $cle, $compteur + 1, HOUR_IN_SECONDS );
    return true;
}
```

## Technique 2 : la file Action Scheduler

> L'essentiel à retenir : Le transient convient à un plafond simple par heure, sans file d'attente ; Action Scheduler lisse la charge dans le temps mais ajoute une latence ; Le middleware serveur protège même si le code PHP est contourné

La deuxième technique ne refuse pas l'appel excédentaire, elle le met en file d'attente pour un traitement différé, à l'aide d'Action Scheduler, la bibliothèque de planification de tâches déjà présente sur de nombreux sites WordPress via WooCommerce. Chaque appel de l'agent devient une tâche planifiée, exécutée à un rythme contrôlé plutôt qu'immédiatement.

```
function wpm_mettre_en_file_appel_agent( array $donnees_appel ): void {
    as_schedule_single_action(
        time() + wpm_calculer_delai_file( $donnees_appel['identifiant_agent'] ),
        'wpm_executer_appel_agent_differe',
        array( $donnees_appel )
    );
}
```

Cette approche lisse la charge dans le temps plutôt que de la refuser brutalement, au prix d'une latence supplémentaire que l'agent doit pouvoir tolérer sans que sa logique de décision n'en souffre.

## Technique 3 : le middleware côté serveur web

La troisième technique intervient avant même que la requête n'atteigne PHP, au niveau du serveur web, par exemple via une configuration Nginx limitant le nombre de requêtes par adresse ou par jeton d'authentification sur une route donnée.

```
limit_req_zone $http_x_agent_key zone=agent_limit:10m rate=1r/s;

location /wp-json/wpm/v1/ {
    limit_req zone=agent_limit burst=5 nodelay;
    proxy_pass http://backend;
}
```

Cette approche protège le site même si une faille dans le code PHP permettait de contourner la vérification de quota applicative, ce qui en fait un filet de sécurité complémentaire plutôt qu'une solution unique.

## Comparatif des trois approches

| Critère | Transient | Action Scheduler | Middleware serveur |
| --- | --- | --- | --- |
| Complexité de mise en œuvre | faible | modérée | modérée, hors PHP |
| Comportement en cas de dépassement | refus immédiat | mise en file, exécution différée | refus immédiat au niveau réseau |
| Résiste à un contournement du code PHP | non | non | oui |
| Adapté à un agent qui tolère la latence | non | oui | non |

## Comment choisir selon le contexte

Le transient convient à un plafond simple, sans exigence de traitement garanti au-delà du plafond. Action Scheduler s'impose quand l'agent peut tolérer un délai et qu'aucun appel ne doit être définitivement perdu. Le middleware serveur reste la seule option qui protège indépendamment du code applicatif, particulièrement utile si plusieurs équipes interviennent sur le même code au fil du temps.

> Sur nos projets, la combinaison la plus robuste associe un compteur applicatif pour la logique métier et un middleware serveur en filet de sécurité, plutôt que de se reposer sur une seule des trois techniques isolément.

## Notre verdict

Aucune des trois techniques ne s'impose universellement : le choix dépend de la tolérance de l'agent à la latence, et du niveau de confiance accordé au code applicatif face à un contournement éventuel. Combiner un contrôle applicatif et un filet de sécurité côté serveur reste l'approche la plus prudente sur un projet exposé à plusieurs agents.