Choisir quel grand modèle de langage alimentera votre agent est l’une des décisions techniques les plus importantes de votre projet.
Ce choix influence les performances de votre agent, le coût de fonctionnement et la prévisibilité de son comportement dans le temps.
Il n’existe pas de modèle universellement meilleur. Le bon choix dépend de vos objectifs, de votre budget et du niveau de contrôle que vous souhaitez sur les réponses.
Les équipes qui prennent cette décision à la hâte le regrettent souvent par la suite. L’essentiel est de tester tôt, de définir des priorités claires et d’éviter de vous enfermer dans un seul fournisseur ou une seule configuration.
Une bonne stratégie LLM répond à quatre questions principales :
- Quel modèle utilisez-vous et pourquoi ?
- À quelle fréquence testerez-vous des alternatives ?
- Qu’est-ce qui compte le plus pour votre cas d’usage : la rapidité ou la puissance ?
- Quel est votre plan de secours si le modèle échoue ou se dégrade ?
Voyons chacune de ces questions.
Choisir un modèle, c’est avant tout une question d’adéquation, pas de prestige. Certains modèles sont rapides et peu coûteux, d’autres plus lents mais meilleurs pour le raisonnement complexe.
Si votre cas d’usage concerne de courtes interactions clients, la latence et le coût peuvent être plus importants que la profondeur.
Si votre cas d’usage nécessite un raisonnement en plusieurs étapes ou des résumés détaillés, la puissance sera prioritaire.
Tester tôt et régulièrement vous permet de voir comment les modèles réagissent avec vos propres données. Chaque LLM a ses particularités : certains suivent mieux les instructions, d’autres sont plus constants dans le ton ou plus précis. Vous ne pouvez le découvrir qu’avec des exemples concrets issus de vos flux de travail.
La planification d’un plan de secours est tout aussi essentielle. Même les API les plus stables peuvent parfois changer de comportement, se dégrader ou tomber en panne. Prévoyez toujours un modèle de secours et une politique de bascule si les performances passent sous votre seuil de référence. (Ou assurez-vous que votre outil de création d’agents propose une option de secours par défaut, comme le fait Botpress)
Chez Terminal Roast, Ross, le comptable, analyse les chiffres. L’équipe souhaite que leur agent gère les discussions simples avec les clients sur le café et les pâtisseries sans délai perceptible. Après avoir testé plusieurs options, ils choisissent Gemini 2.5 Flash. Il est rapide, économique et offre suffisamment de capacités de raisonnement pour des conversations client informelles.
Pour le plan de secours, ils configurent le système pour basculer vers un modèle secondaire si la latence ou le taux d’erreur dépasse leur seuil. Ce choix garantit une expérience utilisateur fluide et un coût d’exploitation prévisible.
Ross note que si l’agent doit évoluer vers des tâches plus complexes, ils pourront revoir le choix du modèle.
Chaque décision sur le modèle est aussi une décision business. Un mauvais choix peut doubler vos coûts d’exploitation ou provoquer des retards inutiles dans les interactions. Le bon équilibre entre performance et coût doit correspondre à l’expérience que vous souhaitez offrir.
La flexibilité est tout aussi cruciale. Évitez de concevoir votre architecture autour d’un seul modèle au point de rendre tout changement ultérieur difficile. Utilisez une couche d’abstraction ou un fournisseur qui prend en charge plusieurs modèles pour pouvoir vous adapter à l’évolution du marché.
Cette flexibilité rend votre système plus résilient et vous évite de dépendre d’un seul fournisseur ou de sa politique tarifaire.
Pour établir une vraie stratégie LLM, documentez trois éléments :
- Votre modèle principal et la raison de ce choix.
- Vos seuils de performance et de coût à partir desquels envisager un changement.
- Votre modèle de secours et les règles pour l’activer.
Reprenez ces décisions au moins tous les trimestres. Le rythme d’évolution des LLM est très rapide, et de nouveaux modèles surpassent souvent les anciens à moindre coût. Considérez cela comme une évaluation continue, pas une configuration définitive.
Le choix de Terminal Roast de privilégier la rapidité et la prévisibilité plutôt que la puissance brute rend leur premier déploiement durable. Cela satisfait les clients, limite les coûts et leur permet de collecter des données réelles sans instabilité technique.
Cet équilibre — choisir un modèle adapté, anticiper les changements et rester flexible — distingue les projets expérimentaux des déploiements en production.
Votre stratégie LLM doit toujours servir vos objectifs business, et non les dicter.
Action : Notez le modèle que vous prévoyez d’utiliser, ce qui compte le plus pour votre cas d’usage (vitesse, coût ou profondeur), et votre option de secours. Révisez ces choix régulièrement à mesure que vous collectez des données d’utilisation.
