# Réduire le nombre d’appels avant tout : le coût énergétique d’un agent bavard

> Un agent qui interroge trois fois le même modèle pour une seule tâche ne consomme pas trois fois plus par hasard. Voici ce que cela change vraiment.

- Auteur : WordPress Développement
- Publié le : 2024-03-09
- Mis à jour le : 2024-03-09
- Catégorie : IA & MCP
- URL : https://www.wpmoderne.fr/ia-mcp/reduire-appels-cout-energetique-agent-bavard/

## L’essentiel

- Trois appels au lieu d'un multiplient le coût par trois
- Le cache de contexte réduit la facture, pas la conception
- Un prompt mal structuré coûte plus cher qu'un serveur mal réglé

Douze appels au modèle pour publier un article, alors qu'un seul aurait suffi. C'est le constat que nous avons fait en instrumentant un agent chargé de relire, catégoriser et publier des billets sur un site WordPress. Chaque étape déclenchait sa propre requête vers le même modèle de langage, avec le même contexte renvoyé presque intégralement à chaque fois.

L'argument marketing autour de la sobriété numérique d'un agent bavard tient rarement la route dès qu'on regarde le détail des appels réseau. Ce n'est pas l'hébergement du modèle qui pose problème ici, ni la puissance de calcul du centre de données qui l'exécute : c'est la logique de l'agent lui-même, qui reformule, revérifie et rappelle le même modèle pour des micro-décisions qu'un seul appel bien construit aurait pu trancher.

## Ce que révèle un simple compteur de requêtes

Nous avons ajouté un compteur autour de notre fonction d'appel au modèle, en enregistrant chaque requête dans une table personnalisée avec l'horodatage, le nombre de jetons envoyés et reçus, et l'action déclenchante. Sur un lot de cent articles traités automatiquement, la moyenne s'est établie à 3,4 appels par article, alors que la tâche — proposer un titre, un extrait et trois étiquettes — peut se résoudre en un seul appel avec une sortie structurée.

Le détail est instructif : un appel pour générer le titre, un second pour vérifier qu'il respecte la longueur imposée, un troisième pour proposer les étiquettes à partir du même contenu déjà envoyé deux fois. Le modèle refait le même travail de compréhension du texte à chaque requête, sans qu'aucune information nouvelle ne soit apportée entre les appels.

## Le coût réel d'un appel superflu

> L'essentiel à retenir : Trois appels au lieu d'un multiplient le coût par trois ; Le cache de contexte réduit la facture, pas la conception ; Un prompt mal structuré coûte plus cher qu'un serveur mal réglé

Sur nos projets, un appel de vérification supplémentaire coûte environ autant qu'un appel de génération, car le modèle doit relire l'intégralité du contexte fourni pour rendre un verdict, même binaire. Multiplier les allers-retours ne divise donc pas le travail : il le répète.

- Chaque appel réenvoie le système de prompt complet, souvent plusieurs centaines de mots
- Le contenu de l'article est retransmis à l'identique à chaque étape
- Le temps de réponse cumulé s'additionne, ce qui ralentit la publication
- La facture au fournisseur suit une progression linéaire avec le nombre d'appels, pas avec la complexité de la tâche

## Fusionner les étapes plutôt que les enchaîner

La correction la plus efficace n'a pas consisté à changer de modèle ni à optimiser l'hébergement, mais à redessiner le prompt pour qu'il rende, en une seule réponse, un objet structuré contenant le titre, l'extrait et les étiquettes. Le modèle reçoit une seule fois le contenu et restitue un JSON validé côté serveur.

```
function wpm_generer_metadonnees( string $contenu ): array {
    $prompt = "Réponds uniquement en JSON avec les clés titre, extrait, etiquettes (tableau de 3).";
    $reponse = wpm_appeler_llm( $prompt, $contenu );
    $donnees = json_decode( $reponse, true );

    if ( ! is_array( $donnees ) || empty( $donnees['titre'] ) ) {
        return array();
    }

    return $donnees;
}
```

Ce changement a fait passer notre moyenne de 3,4 à 1,1 appel par article, sans dégrader la qualité perçue des métadonnées produites. Le gain n'est pas seulement financier : le temps de traitement d'un article est passé de plusieurs secondes à moins d'une seconde dans la majorité des cas.

## Où la réduction des appels trouve ses limites

Fusionner les étapes ne fonctionne pas toujours. Quand une tâche dépend du résultat d'une précédente — par exemple, choisir une catégorie avant de vérifier qu'elle existe réellement dans la taxonomie du site — un second appel reste justifié. La vraie question n'est pas « combien d'appels au minimum », mais « quelles décisions dépendent réellement les unes des autres ».

> Sur nos projets, la règle qui a le mieux fonctionné est simple : si deux appels utilisent le même contexte sans qu'aucune information nouvelle ne soit apparue entre les deux, ils devraient n'en faire qu'un.

## Mesurer avant de conclure

Un compteur de requêtes coûte peu à mettre en place et change immédiatement la façon dont on conçoit un agent. Sans lui, on raisonne sur des impressions ; avec lui, on voit concrètement où les appels s'accumulent sans justification, et où une fusion de prompt rapporte plus qu'une optimisation d'infrastructure.

## En résumé

Réduire le nombre d'appels avant tout autre chantier reste la mesure la plus rentable sur un agent qui interroge un modèle de langage. Avant de discuter d'hébergement ou de fournisseur, il vaut mieux vérifier que chaque appel apporte une information que le précédent n'avait pas.