Scénario illustratif. Un lundi de campagne, l'agent de support qui tourne à merveille le reste de l'année reçoit en une heure ce qu'il reçoit d'habitude en une journée. Les premiers messages passent bien. Vingt minutes plus tard, les relances s'enchaînent, la file grossit, le fournisseur du modèle renvoie des erreurs de limite, et la boîte des humains, censée récupérer ce que l'agent ne résout pas, se remplit d'un coup. Personne n'a rien cassé : le système n'avait simplement jamais répété ce jour-là.
La thèse en une ligne : un agent dimensionné pour la journée moyenne ne lâche pas au pic parce qu'il est mauvais, il lâche parce que personne n'a décidé avant ce qui se dégrade en premier. On ne survit pas à un pic avec plus de puissance, mais avec un ordre de chute convenu d'avance.
Pourquoi un agent IA lâche-t-il pendant les pics de demande ?
Parce que les pics de demande ne mettent pas sous tension ce que tu as testé (la qualité de la réponse) mais ce que tu tenais pour acquis (tout ce qui l'entoure). Quatre points de rupture, presque toujours les mêmes :
- Limites de débit et quotas. Le fournisseur du modèle plafonne le nombre de requêtes et de tokens par minute. Si plusieurs agents partagent une clé, le pic de l'un avale la marge des autres. Les limites réelles dépendent de ton fournisseur et de ton offre : regarde-les avant, pas pendant.
- Files et nouvelles tentatives. Une relance sans frein transforme une panne ponctuelle en avalanche : chaque requête échouée revient et aggrave l'embouteillage qui l'a fait échouer.
- Coût. Avec plus de volume, des conversations plus longues et plus d'appels d'outils, la dépense grimpe plus vite que le trafic. Sans plafond, tu l'apprends en fin de mois, quand il n'y a plus rien à décider.
- Humains débordés. L'agent escalade les cas difficiles vers des personnes ; au pic, il escalade plus, et tout en même temps. Si la boîte humaine ne tient pas, le goulot ne disparaît pas : il se déplace.
Remarque ce qui manque dans la liste : le modèle. Ce n'est presque jamais le modèle. C'est tout ce qui y est accroché, et ça, ça se répète.
Que répéter avant le pic ?
Répéter, c'est jouer à temps la version réduite du désastre. Pas besoin d'un exercice géant ; il en faut un honnête. Une séquence minimale :
- Mesure ta journée moyenne et fixe le pic attendu avec des données réelles des dernières campagnes ou clôtures, pas au feeling. Pas d'historique ? Pars de tes pires heures connues.
- Monte la charge dans un environnement de test et regarde où apparaît la première limite : débit, file, outil externe ou personne. C'est ton vrai goulot, pas celui que tu imaginais.
- Teste la panne, pas seulement la charge. Coupe l'outil externe exprès, simule l'erreur de limite du fournisseur et observe l'agent : s'il invente, se tait ou relance sans fin, tu sais quoi corriger. Tester les changements sans casser l'automatisation sert aussi à ça.
- Fixe des plafonds de dépense et des alertes par système, avec un avertissement avant le plafond et non après, et une personne nommée qui le reçoit pendant le pic.
- Répète le relais humain. Combien de cas par heure absorbe la personne d'astreinte, et que devient le reste ? C'est ce que presque personne ne teste et ce qui se voit le plus ; la conception du humain dans la boucle décide si cette personne est un frein ou un filet.
Et mesure pendant que tu répètes : sans détection des pannes dans tes automatisations, un pic dégradé peut passer pour un pic tranquille.
Que dégrader exprès pour ne pas tomber ?
Dégrader avec élégance, c'est décider avant d'en avoir besoin ce que l'agent arrête de faire en premier. C'est la logique des niveaux d'autonomie d'un agent appliquée au temps : au pic, l'agent descend d'un barreau au lieu de tomber de l'immeuble.
| Ce qui casse | Dégradation possible | Ce que tu protèges |
|---|---|---|
| Quota du fournisseur épuisé | Passer à un modèle plus léger pour les demandes simples et garder le puissant pour les critiques | Les cas importants continuent d'avoir une réponse |
| File qui grossit | Accusé de réception immédiat avec un délai réaliste, traitement en arrière-plan | La confiance du client : il sait que son cas existe |
| Coût au-delà du plafond | Limiter les outils coûteux et la longueur des conversations ; renvoyer le reste vers un formulaire | Le budget, sans éteindre le service |
| Humains débordés | Trier par urgence et reporter le non urgent avec une date, au lieu de tout escalader | Les personnes et les cas qui ne peuvent pas attendre |
Rien de tout ça n'est glamour, et c'est pour ça que ça marche : ce sont des décisions d'exploitation, prises au calme un mardi d'octobre, pas à neuf heures le matin du Black Friday. Si tu préfères que celui qui l'exploite s'en charge, c'est exactement ce que couvrent garantir la disponibilité de l'IA et superviser l'IA en production.
Qui décide de ce qu'on coupe pendant le pic ?
Une dégradation convenue ne sert que si quelqu'un a l'autorité de l'activer sur le moment. En plein pic, pas le temps de réunir un comité : la décision se prend avant, et on écrit une page avec trois choses.
- Le déclencheur. Le signal concret qui active chaque dégradation : la file dépasse une certaine taille, la dépense franchit un certain pourcentage du plafond, le fournisseur renvoie des erreurs de limite plusieurs minutes d'affilée. Sans déclencheur mesurable, chaque décision devient un débat.
- Le responsable. Une personne nommée, et un suppléant, qui peut activer la dégradation sans demander la permission à personne. L'autorité déléguée d'avance, c'est ce qui transforme un plan en interrupteur.
- Le chemin du retour. Comment et quand on rétablit le comportement normal, et qui revoit ce qui a été différé pendant le pic. Une dégradation que personne ne désactive devient le nouveau standard sans que personne l'ait décidé.
Avec cette page, le pic cesse d'être de l'improvisation à neuf heures du matin et devient une procédure. Et ce qu'on a appris ce jour-là se note pour la prochaine fois : ce qui a déclenché chaque dégradation, combien de temps elle a duré et ce qu'on ferait autrement.
Quand n'a-t-on pas besoin de préparer le pic ?
Quand le pic est prévisible et petit, quand l'agent n'est pas sur le chemin critique (s'il tombe, les gens attendent, aucune commande n'est perdue) ou quand tomber un moment coûte moins cher que se préparer. Un agent interne de recherche, plus sollicité le lundi, n'a pas besoin d'exercice ; un agent qui prend des commandes pendant une campagne, si. Trop se préparer, c'est aussi du théâtre.
La phrase à retenir : ne dimensionne ni pour la journée moyenne ni pour la journée rêvée ; décide dans quel ordre la mauvaise journée s'effondre, et répète-le.
Note : cet article n'utilise aucun chiffre de tiers. Les limites de débit et les tarifs dépendent du fournisseur et de l'offre, et ils changent ; vérifie la documentation de ton fournisseur avant de dimensionner. Le scénario d'ouverture est illustratif.