# Limiter les jetons envoyés à une API de LLM depuis un formulaire public

> Maîtriser le coût d'un assistant IA exposé aux visiteurs en limitant la longueur des textes envoyés depuis un formulaire du site.

- Auteur : WordPress Développement
- Publié le : 2024-02-23
- Mis à jour le : 2024-02-23
- Catégorie : IA & MCP
- URL : https://www.wpmoderne.fr/ia-mcp/limiter-jetons-envoyes-api-llm-formulaire/

## L’essentiel

- Un champ de formulaire sans limite expose à un coût par requête imprévisible
- Une limite côté serveur reste indispensable, une limite côté client ne suffit pas
- Un contrôle de fréquence complète la limite de longueur

Un champ de texte libre, sans limite de longueur, relié à un assistant IA exposé aux visiteurs d'un site : voilà une configuration qui transforme un formulaire ordinaire en surface d'exposition directe au coût d'une API facturée au jeton. Un visiteur, malveillant ou simplement peu attentif, peut coller un texte de plusieurs milliers de mots dans un champ prévu pour une question courte.

Deux contrôles complémentaires réduisent ce risque : une limite stricte sur la longueur du texte accepté, et un contrôle de fréquence sur le nombre d'envois autorisés par visiteur.

## Pourquoi une limite côté client ne protège rien

Un attribut `maxlength` sur un champ de formulaire HTML empêche la saisie au-delà d'un certain nombre de caractères dans le navigateur, mais n'empêche en rien l'envoi d'une requête directe vers le point d'entrée du serveur, en contournant totalement le formulaire affiché. Toute limite qui compte réellement doit s'appliquer côté serveur, au moment du traitement de la donnée reçue.

## Appliquer une limite de longueur côté serveur

> L'essentiel à retenir : Un champ de formulaire sans limite expose à un coût par requête imprévisible ; Une limite côté serveur reste indispensable, une limite côté client ne suffit pas ; Un contrôle de fréquence complète la limite de longueur

```
function traiter_question_visiteur( WP_REST_Request $request ) {
    $question = sanitize_textarea_field( $request->get_param( 'question' ) );

    if ( mb_strlen( $question ) > 500 ) {
        return new WP_Error(
            'question_trop_longue',
            'La question dépasse la longueur maximale autorisée.',
            array( 'status' => 400 )
        );
    }

    if ( mb_strlen( trim( $question ) ) < 3 ) {
        return new WP_Error(
            'question_trop_courte',
            'Merci de préciser votre question.',
            array( 'status' => 400 )
        );
    }

    return appeler_assistant( $question );
}
```

### Choisir une limite adaptée à l'usage réel

Cinq cents caractères couvrent largement une question de support classique. Un usage différent, comme la relecture d'un texte plus long soumis volontairement par un visiteur inscrit, justifierait une limite plus élevée, mais réservée à un contexte authentifié plutôt qu'à un formulaire public anonyme.

## Compléter par un contrôle de fréquence

Une limite de longueur seule n'empêche pas un visiteur d'envoyer de nombreuses requêtes courtes à la suite, ce qui reste coûteux cumulé sur un grand nombre d'envois. Un contrôle de fréquence, basé sur l'adresse IP ou sur un identifiant de session, complète la protection :

```
function verifier_frequence_visiteur( string $identifiant ): bool {
    $cle = 'frequence_ia_' . md5( $identifiant );
    $compteur = (int) get_transient( $cle );

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

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

Dix requêtes par heure et par visiteur reste un seuil raisonnable pour un usage légitime de support, tout en limitant fortement l'impact d'un abus isolé.

## Limiter également la longueur de la réponse générée

La longueur envoyée en entrée n'est qu'une moitié du problème : la réponse générée par le modèle contribue elle aussi au coût de l'appel. Le paramètre de limite de jetons de sortie, disponible dans la plupart des API de modèles de langage, mérite d'être fixé explicitement plutôt que laissé à sa valeur par défaut, parfois généreuse :

```
'body' => wp_json_encode( array(
    'model'      => 'modele-exemple',
    'messages'   => $messages,
    'max_tokens' => 300,
) ),
```

- Une limite de longueur en entrée, appliquée côté serveur uniquement
- Un contrôle de fréquence par visiteur, indépendant de la limite de longueur
- Une limite de jetons de sortie fixée explicitement dans l'appel à l'API

> Un formulaire public relié à un assistant IA sans aucune de ces trois limites revient à laisser un tiers, potentiellement malveillant, fixer lui-même le montant de la facture mensuelle du site.

## Ce qu'il faut retenir

Trois limites complémentaires, appliquées systématiquement côté serveur, protègent un formulaire public relié à un assistant IA contre un coût imprévisible : la longueur du texte reçu, la fréquence des envois par visiteur, et la longueur de la réponse générée. Aucune de ces trois mesures ne suffit isolément.