Laravel & IA : évitez la facture surprise avec du rate limiting et un suivi de tokens
Intégrer Claude ou GPT-4o dans une application Laravel est techniquement simple. Un Http::post() et votre feature est en ligne. Le problème arrive le lendemain matin : un utilisateur a bouclé votre endpoint toute la nuit, ou un bot a scripté vos appels, et votre facture OpenAI affiche plusieurs centaines d'euros de consommation non prévue.
Ce scénario n'est pas hypothétique. Il est documenté et fréquent. La solution ne réside pas dans de meilleurs prompts, mais dans une couche d'infrastructure dédiée. Cet article, inspiré du guide publié sur dev.to par Dewald Hugo, présente une checklist concrète pour sécuriser vos intégrations IA en production avec Laravel.
Pourquoi passer par un middleware Laravel dédié à l'IA ?
Le middleware Laravel est l'endroit le plus approprié pour centraliser les préoccupations d'infrastructure : coût, quotas, logging. Ce découplage a un avantage direct : vous pouvez remplacer GPT-4o par une instance Llama auto-hébergée sans toucher à un seul contrôleur.
La formule de calcul du coût repose sur le pricing standard des tokens :
Coût total = Σ (tokens_entrée × prix_entrée + tokens_sortie × prix_sortie)
Chaque appel à l'API IA doit être intercepté, mesuré et enregistré avant que votre logique métier ne soit exécutée. Le middleware est la seule couche qui vous garantit cela systématiquement, sans dépendre de la discipline des développeurs dans chaque contrôleur.
Les 4 briques de la couche middleware IA
1. Rate limiting par paliers (tiered rate limits)
Un rate limiting unique et global n'est pas suffisant. Il faut distinguer les niveaux d'utilisation selon le profil utilisateur : un compte gratuit, un abonné, un compte entreprise n'ont pas le même quota légitime.
Avec Laravel, la façade RateLimiter permet de définir plusieurs limiteurs nommés :
RateLimiter::for('ai-free', function (Request $request) {
return Limit::perDay(20)->by($request->user()->id);
});
RateLimiter::for('ai-premium', function (Request $request) {
return Limit::perDay(500)->by($request->user()->id);
});
Le middleware sélectionne ensuite le bon limiteur en fonction du plan de l'utilisateur authentifié. Si la limite est atteinte, une réponse HTTP 429 est retournée avec un message explicite.
⚠️ Ne mutualisez pas un seul limiteur global : un utilisateur abusif ne doit pas impacter les autres.
2. Comptage de tokens avec Redis
Les API OpenAI et Anthropic retournent le nombre de tokens consommés dans la réponse (usage.prompt_tokens, usage.completion_tokens). Il faut capturer ces valeurs et les accumuler en temps réel.
Redis est le bon outil pour ça : les opérations INCR et EXPIRE sont atomiques et performantes. Un pattern typique :
$key = "ai:tokens:user:{$userId}:" . now()->format('Y-m-d');
Redis::incrby($key, $tokensConsumed);
Redis::expire($key, 86400); // TTL 24h
Cela vous donne une vue en temps réel de la consommation par utilisateur et par jour, sans requête SQL. Vous pouvez aussi définir un seuil d'alerte : si un utilisateur dépasse 80 % de son quota tokens dans la journée, déclenchez une notification ou bloquez proactivement.
3. Logging asynchrone en base de données
Enregistrer chaque appel IA de façon synchrone ralentirait vos endpoints. La bonne pratique est de déléguer l'écriture en base à un job Laravel dispatché après la réponse :
DispatchAfterResponse::dispatch(new LogAiUsageJob([
'user_id' => $userId,
'model' => $model,
'prompt_tokens' => $usage['prompt_tokens'],
'completion_tokens'=> $usage['completion_tokens'],
'cost_eur' => $calculatedCost,
'endpoint' => $request->path(),
]));
La table ai_usage_logs en PostgreSQL devient ainsi votre source de vérité pour la facturation, les audits et les analyses de coûts par feature ou par client. Vous pouvez y associer des agrégations quotidiennes via des vues matérialisées ou des commandes artisan planifiées.
4. Tests avec Pest pour valider que les gardes fonctionnent
Une infrastructure non testée est une infrastructure non fiable. Les tests Pest permettent de valider le comportement du middleware de façon lisible et rapide.
Quelques cas à couvrir impérativement :
it('bloque un utilisateur ayant dépassé son quota journalier', function () {
$user = User::factory()->plan('free')->create();
actingAs($user);
// Simule 20 appels déjà consommés
RateLimiter::hit('ai-free:' . $user->id, 20);
$response = postJson('/api/ai/chat', ['message' => 'Bonjour']);
$response->assertStatus(429);
});
it('logge les tokens consommés après un appel réussi', function () {
$user = User::factory()->plan('premium')->create();
actingAs($user);
Http::fake(['https://api.openai.com/*' => Http::response([
'choices' => [['message' => ['content' => 'Réponse IA']]],
'usage' => ['prompt_tokens' => 50, 'completion_tokens' => 80],
])]);
postJson('/api/ai/chat', ['message' => 'Test']);
Queue::assertPushed(LogAiUsageJob::class);
});
Ces tests doivent faire partie de votre CI. Ils garantissent que personne ne peut accidentellement retirer une garde en refactorant le middleware.
Checklist de mise en production
Avant de déployer votre couche middleware IA, voici les points à valider :
Conclusion
Intégrer une API IA sans couche d'infrastructure, c'est laisser les clés de votre budget à n'importe quel utilisateur malveillant ou simplement maladroit. Un middleware Laravel dédié — avec rate limiting par paliers, comptage de tokens dans Redis et logging asynchrone en base — vous donne le contrôle nécessaire pour exploiter sereinement des modèles comme GPT-4o ou Claude en production.
Cette architecture est modulaire : vous pouvez la faire évoluer progressivement, en commençant par le rate limiting puis en ajoutant le tracking de tokens. L'essentiel est de ne pas attendre la première facture imprévue pour l'implémenter.
Source originale : Laravel AI Middleware: Token Tracking & Rate Limiting par Dewald Hugo sur dev.to.
