Un agent se tait au milieu d'une réponse. Deux minutes plus tard, un autre fournisseur le bloque aussi. Les journaux disent deux choses différentes, et aucune des deux n'est une panne : c'est un plafond.
1. La scène
Un agent de bureau répond à une question en dictée vocale. La réponse s'interrompt brutalement. L'utilisateur relance : « allo ? ». Silence.
Pendant ce temps, dans les journaux du serveur, deux événements se succèdent à dix-sept minutes d'intervalle.
Événement un, 11 h 16. L'agent demande une réponse à un modèle gratuit, servi par une passerelle publique. Réponse : 403 Forbidden, avec un message explicite — la passerelle a détecté un trafic qu'elle juge abusif et refuse l'appel. Rien à voir avec une clé invalide : c'est un filtrage de réputation, appliqué à l'adresse du serveur.
Événement deux, 11 h 33. L'application bascule automatiquement sur un autre fournisseur, resté configuré en secours. Cette fois, la réponse est un refus de quota : vingt requêtes par jour sur l'offre gratuite, quota épuisé, réessayer dans douze heures et vingt-six minutes.
Deux causes distinctes, un seul symptôme visible : un agent muet.
2. Premier plafond : la réputation, pas le contrat
Le 403 mérite qu'on s'y arrête, parce qu'il ne ressemble à rien de connu.
Une clé valide, un compte valide, une requête valide — et un refus. Le message parle de « trafic abusif ». La passerelle ne compte pas des requêtes par contrat : elle observe des motifs. Une adresse IP de centre de données, plusieurs comptes, des appels réguliers : dans son modèle, cela ressemble à un usage automatisé non autorisé.
Ce filtrage est légitime — c'est ainsi qu'un service gratuit se protège. Mais il faut comprendre sa nature : ce n'est pas un quota, c'est une réputation. Un quota se lit, se prévoit, s'alerte. Une réputation se devine, se dégrade sans prévenir, et ne se conteste pas dans un tableau de bord.
Conséquence pratique : un service gratuit peut cesser de fonctionner sans qu'aucun compteur n'ait bougé. Un plan de secours est donc obligatoire, pas optionnel.
3. Second plafond : vingt requêtes par jour
Le second refus est plus franc, et plus utile à étudier.
Vingt requêtes par jour. Pour un humain qui pose des questions dans une interface, c'est confortable. Pour une flotte d'agents qui utilise un modèle comme moteur de raisonnement, c'est dérisoire : vingt appels, c'est trois tâches un peu sérieuses.
Et le refus n'est pas progressif. Il n'y a pas de ralentissement, pas de dégradation, pas de message d'avertissement à 80 % : il y a un mur, puis douze heures d'attente.
Le détail le plus instructif est le temps d'attente annoncé : douze heures et vingt-six minutes. Le plafond n'est pas seulement un nombre de requêtes, c'est une fenêtre temporelle. On ne peut pas l'augmenter en payant un peu : on attend le reset.
4. Ce que l'agent a fait de ces douze heures
Pendant les quinze minutes qui ont précédé le mur, l'agent a cherché la documentation officielle du produit pour répondre à une question sur l'apparence des messages. Il a fouillé des paquets d'application, lu des fichiers de traduction, comparé des variantes. Une recherche honorable, coûteuse en requêtes, et inutile : l'information cherchée n'était pas là.
Ce n'est pas une faute morale. C'est un problème de budget non conscient : l'agent ne savait pas qu'il dépensait une ressource finie. Il n'avait aucune jauge, aucun plafond interne, aucune raison de préférer une réponse courte à une exploration exhaustive.
Un agent qui ne connaît pas son budget se comporte comme un chercheur sans limite de temps : il creuse. C'est acceptable quand la ressource est abondante ; c'est destructeur quand elle est plafonnée.
5. Le plan de secours n'était pas un plan
La bascule automatique vers un modèle de secours était une bonne idée. Elle reposait toutefois sur une hypothèse fausse : que le secours serait disponible.
Or le secours était lui aussi gratuit, donc lui aussi plafonné. Une chaîne de secours composée uniquement de ressources plafonnées n'est pas une chaîne de secours : c'est une file d'attente.
Trois règles en découlent :
Un : le secours doit être d'une autre nature que le principal. Un modèle payant à l'usage, un modèle local, un modèle servi par une autre infrastructure. Pas « le même gratuit, ailleurs ».
Deux : le secours doit être testé régulièrement. Un secours jamais sollicité est un secours dont on ignore l'état. Chez nous, une bascule manuelle est déclenchée une fois par semaine pour vérifier qu'elle fonctionne encore.
Trois : l'échec doit être dit. L'agent muet est le pire des états. Un agent qui répond « je ne peux pas répondre, mon modèle est bloqué jusqu'à telle heure » rend service ; un agent qui ne répond pas laisse croire à une panne générale.
6. Ce que ça change dans la conception
Nous avons tiré trois conséquences opérationnelles.
Mesurer la marge, pas seulement l'usage. Un tableau de bord qui affiche « 20 requêtes » ne sert à rien ; ce qu'il faut savoir, c'est combien il en reste et à quelle heure le compteur se réinitialise.
Plafonner le travail exploratoire. Une recherche documentaire dans des paquets d'application doit avoir un budget explicite : nombre d'appels, durée, critère d'arrêt. Sans critère d'arrêt, l'exploration ne s'arrête pas d'elle-même.
Séparer les usages. Un modèle à vingt requêtes par jour convient à un agent de secrétariat qui répond à quelques messages ; il ne convient pas à un agent qui explore, compare et diagnostique. Le même plafond n'a pas le même sens selon l'usage, et confondre les deux conduit exactement à la panne décrite ici.
7. La leçon
Les offres gratuites ne sont pas des ressources : ce sont des prêts à durée déterminée. Elles sont plafonnées en volume, parfois en réputation, et toujours dans le temps.
Cela ne les rend pas inutilisables — nous en vivons. Cela impose de les traiter comme ce qu'elles sont : une ressource mesurée, avec un plafond connu, un secours d'une autre nature, et un agent capable de dire « je suis à sec » au lieu de se taire.
À retenir. Un 403 pour « trafic abusif » n'est pas un bug : c'est de la réputation. Vingt requêtes par jour ne sont pas un budget : c'est un plafond temporel. Mesurez la marge, plafonnez l'exploration, et prévoyez un secours d'une autre nature.