IA
Pourquoi votre agent IA en contact avec les clients a besoin d’un modèle de secours
Un fournisseur de modèles traverse une mauvaise heure et votre agent WhatsApp se tait pendant que les clients attendent. Un modèle de secours est l’assurance la moins chère contre ce risque. Voici comment fonctionne le secours, comment en choisir un et comment il s’articule avec les modèles rapides et les budgets.
Équipe MonoChat Mis à jour: 7 min de lecture
Sur cette page
- Pourquoi les défaillances de modèles font plus de dégâts dans les conversations clients
- Ce qui peut mal tourner
- Comment fonctionne le secours dans un agent
- Comment choisir un modèle de secours
- Le modèle rapide : l’autre moitié de la fiabilité
- Budgets : le filet de sécurité sous le filet de sécurité
- Modèle de secours et passage de relais ne sont pas la même chose
- Une liste de contrôle simple
- Configurez-le une fois, pour tous les canaux
Un agent IA en contact avec les clients a besoin d’un modèle de secours, car tout modèle finit par échouer au pire moment : le fournisseur subit une panne, votre compte atteint une limite de débit, une requête expire, ou une conversation inhabituelle consomme plus de tokens que prévu. Sans modèle de secours, l’agent se tait et le client attend. Avec lui, un second modèle prend le relais et la conversation continue. Dans l’Agent Harness de MonoChat, chaque nœud Agent IA dispose d’un modèle principal, d’un modèle de secours et d’un modèle rapide, ainsi que d’une limite de budget par exécution.
Cet article explique pourquoi les défaillances de modèles pèsent plus dans la messagerie client que partout ailleurs, comment fonctionne le secours, comment choisir un modèle de secours et comment il s’articule avec les modèles rapides, les budgets et le passage de relais à un humain.
Pourquoi les défaillances de modèles font plus de dégâts dans les conversations clients
Dans un outil interne, une requête IA qui échoue est un désagrément : on clique sur « réessayer ». Dans une conversation client sur WhatsApp, c’est une promesse non tenue. Le client a posé une question, a vu les coches bleues et attend une réponse.
Plusieurs facteurs rendent la messagerie client particulièrement sensible :
- Les clients ne réessaient pas. Ils écrivent à nouveau, plus agacés, ou ils partent.
- Le trafic est irrégulier. Une campagne, un retard de livraison ou des soldes peuvent multiplier les conversations en quelques minutes, c’est-à-dire précisément quand les limites de débit se font sentir.
- Les agents font de nombreux appels. Un agent harness exécute le modèle en boucle, souvent plusieurs fois par message client. Un seul appel en échec peut bloquer toute l’exécution.
- Le timing compte sur WhatsApp. Les réponses libres ne sont autorisées que dans les 24 heures suivant le dernier message du client. Un long blocage peut faire sortir une réponse de cette fenêtre, auquel cas il faut un modèle de message approuvé.
Rien de tout cela ne signifie qu’un fournisseur en particulier est peu fiable. Tous les fournisseurs connaissent des incidents, des maintenances et des limites de capacité. La seule question est de savoir si votre agent a prévu quelque chose pour y faire face.
Ce qui peut mal tourner
Pannes de fournisseur. Partielles ou totales, courtes ou longues. Même une disponibilité mensuelle de 99,9 % autorise plus de 40 minutes d’indisponibilité.
Limites de débit. Votre compte peut autoriser un certain nombre de requêtes ou de tokens par minute. Une heure chargée peut atteindre ce plafond même quand le fournisseur fonctionne parfaitement.
Délais d’attente dépassés et réponses lentes. Un modèle qui répond habituellement en deux secondes peut en mettre vingt en cas de charge. Pour un client sur son téléphone, cela donne l’impression que rien ne se passe.
Exécutions qui s’emballent. Un agent qui tourne en boucle sur une demande confuse, ou une conversation qui ne cesse de s’allonger, peut consommer bien plus qu’une exécution normale.
Changements de modèles. Les fournisseurs mettent à jour et retirent des modèles. Un comportement sur lequel vous comptiez peut changer avec peu de préavis.
Comment fonctionne le secours dans un agent
Le principe est simple : quand le modèle principal ne peut pas terminer le travail, un second modèle prend le relais. Dans MonoChat, le modèle de secours prend le relais après une limite souple ou quand le modèle principal échoue. La conversation, les outils et les instructions restent les mêmes ; seul le modèle qui fait le travail change.
Trois rôles collaborent dans chaque nœud Agent IA :
| Rôle | Ce qu’il fait |
|---|---|
| Modèle principal | Raisonne, décide et rédige les réponses |
| Modèle de secours | Prend le relais après une limite souple ou une défaillance |
| Modèle rapide | Prend en charge les tâches de fond |
En plus de ces rôles, une limite de budget par exécution plafonne ce qu’une seule conversation peut dépenser.
Comment choisir un modèle de secours
Privilégiez un autre fournisseur
Un modèle de secours du même fournisseur vous protège contre le dysfonctionnement d’un modèle, mais pas contre un incident général du fournisseur ni contre une limite de débit sur votre compte chez ce fournisseur. Un modèle d’un second fournisseur couvre les deux. MonoChat vous permet de connecter plusieurs fournisseurs grâce aux LLM personnalisés : c’est un choix de configuration, pas un projet.
Visez « assez bon », pas « identique »
Le modèle de secours n’a pas besoin d’être le meilleur modèle disponible. Il doit suivre vos instructions, appeler correctement vos outils et rédiger une réponse correcte. Testez-le seul sur vos conversations réelles, comme s’il était le modèle principal, avant de vous y fier.
Vérifiez qu’il gère vos outils
Les agents dépendent des appels d’outils : consulter une commande, vérifier un créneau, créer un ticket. Certains modèles gèrent bien mieux que d’autres les appels d’outils structurés. Un modèle de secours qui écrit de beaux textes mais appelle mal les outils est pire que pas de secours du tout.
Pensez aux langues que vous servez
Si vos clients écrivent en turc, en arabe ou en espagnol, assurez-vous que le modèle de secours écrit ces langues aussi bien que le modèle principal. Un changement soudain de qualité ou de ton se remarque.
Considérez le coût dans les deux sens
Un modèle de secours moins cher réduit le coût des exécutions longues ou inhabituelles qui dépassent une limite souple. Un modèle de secours plus cher peut convenir s’il ne traite que de rares défaillances. Décidez de la mission que vous voulez lui confier.
Le modèle rapide : l’autre moitié de la fiabilité
Toutes les étapes n’exigent pas votre meilleur modèle. Les tâches de fond, c’est-à-dire le travail autour de la conversation plutôt que la réponse elle-même, peuvent s’exécuter sur un modèle plus petit et plus rapide. Cela préserve la capacité et le budget du modèle principal pour ce que le client voit réellement, et réduit le risque d’atteindre une limite de débit sur le modèle principal aux heures de pointe.
Concrètement : placez votre modèle de raisonnement le plus solide en principal, un modèle fiable d’un second fournisseur en secours, et un modèle rapide et économique pour les tâches de fond.
Budgets : le filet de sécurité sous le filet de sécurité
Le modèle de secours maintient l’agent en fonctionnement. Les budgets le maintiennent abordable. Une limite de budget par exécution garantit qu’aucune conversation, aussi étrange soit-elle, ne peut dépenser plus que prévu. Associée à une limite souple après laquelle le modèle de secours prend le relais, elle donne un schéma prévisible : les conversations normales tournent sur le modèle principal, les longues se poursuivent sur le modèle de secours, et rien ne s’emballe.
Avec vos propres clés de fournisseur, MonoChat n’ajoute aucune majoration sur l’IA : ce que vous budgétez correspond donc à ce que facturent vos fournisseurs.
Modèle de secours et passage de relais ne sont pas la même chose
Il est tentant de voir dans un modèle de secours la réponse à tous les problèmes. Ce n’est pas le cas. Un modèle de secours résout les défaillances techniques : le modèle est en panne, lent ou à court de budget. Le passage de relais résout les problèmes de jugement : une réclamation, une question juridique, un remboursement au-delà de votre limite, ou un client qui demande simplement une personne.
Dans MonoChat, l’agent s’exécute dans un parcours : le passage de relais vers votre boîte de réception partagée, avec tout l’historique, est donc toujours disponible. WhatsApp attend aussi que les réponses automatisées proposent une voie claire vers un humain. Concevez les deux chemins :
- Le modèle principal échoue ou atteint une limite souple → le modèle de secours continue.
- Le cas nécessite une personne → passage de relais à la bonne équipe avec l’historique de la conversation.
- Les deux échouent → le parcours indique au client qu’une personne répondra et oriente la conversation vers la boîte de réception.
Une liste de contrôle simple
- Modèle principal choisi pour sa qualité sur vos conversations réelles.
- Modèle de secours d’un second fournisseur, testé seul avec vos outils et vos langues.
- Modèle rapide pour les tâches de fond.
- Limite de budget par exécution correspondant au coût normal de vos conversations, avec une certaine marge.
- Règles de passage de relais claires dans les instructions de l’agent et dans le parcours.
- Une revue d’un échantillon de conversations après la première semaine, y compris celles qui ont tourné sur le modèle de secours.
Configurez-le une fois, pour tous les canaux
Comme le nœud Agent IA vit dans un parcours MonoChat, les mêmes modèles principal, de secours et rapide protègent votre agent sur WhatsApp, Instagram, Messenger, TikTok, Telegram, le chat web, les SMS et la voix. Et comme Agent Harness vous laisse choisir le framework, la même approche fonctionne que votre agent s’exécute sur le harness intégré de MonoChat, le Claude Agent SDK, l’OpenAI Agents SDK, Pi ou votre propre framework.
Découvrez comment s’articulent les rôles des modèles sur la page Agent Harness.
Mettez-le en pratique avec MonoChat