Tout ce qu’il faut pour construire un vrai chatbot propulsé par un grand modèle de langage. Cet article couvre le choix du modèle, la conception du prompt système, la mémoire de conversation, l’intégration de l’API en Python, les pièges courants qui font planter les bots en production, ainsi que la manière de tester et de passer à l’échelle sans faire exploser votre budget API.
Créer un chatbot exigeait autrefois des années de recherche en NLP et des montagnes de données d’entraînement. Aujourd’hui, vous pouvez mettre en place un bot conversationnel opérationnel en un après-midi en appelant une API de LLM. La partie difficile n’est plus de le faire répondre. La partie difficile est de le faire répondre bien, de manière constante, sans dériver hors sujet ni halluciner des faits. Cet article vous guide à travers chaque couche de ce problème, du choix du bon modèle à la conception de prompts système qui tiennent en production.
La plupart des gens considèrent les LLM comme une boîte noire. Vous envoyez du texte, du texte en ressort. Mais comprendre ce qui se passe à l’intérieur change la façon de construire, et surtout la façon de déboguer quand les choses tournent mal.
Un LLM ne lit pas des mots. Il lit des tokens, c’est-à-dire des fragments de texte d’environ 3 à 4 caractères chacun. Chaque modèle dispose d’une fenêtre de contexte : le nombre maximal de tokens qu’il peut traiter en une seule requête. GPT-4o gère 128 000 tokens. Llama 2 7B Chat plafonne à 4 096. Cette différence compte énormément lorsque vous construisez une conversation à plusieurs tours.
💡 Règle empirique : 1 000 tokens représentent environ 750 mots. Une longue conversation atteint la limite de contexte plus vite que la plupart des développeurs ne l’imaginent.
Lorsque la fenêtre de contexte est pleine, le modèle ne peut plus se souvenir de ce qui précède. Ce n’est pas un bug. C’est ainsi que fonctionnent les transformers. C’est à votre code applicatif de gérer la mémoire, pas au modèle.
Voici un point qui piège tous ceux qui construisent un chatbot pour la première fois : les LLM sont sans état. Chaque appel d’API est totalement indépendant. Le modèle ne sait pas ce qui a été dit cinq messages plus tôt, sauf si vous incluez explicitement ces messages dans la requête en cours.
Cela signifie que la « mémoire » de votre chatbot relève entièrement de votre responsabilité. Vous tenez une liste de messages. Vous transmettez la liste complète à chaque appel. Le modèle voit du contexte, pas un historique. Ce seul fait d’architecture change tout dans la façon de construire une application de chatbot.
Si vous oubliez cela et stockez l’état de la conversation uniquement côté interface, vous obtiendrez un chatbot qui perd toute sa mémoire à chaque rafraîchissement de page. Si vous conservez un historique trop long sans le tronquer, vous atteindrez les limites de contexte lors des sessions longues. La bonne approche consiste en un magasin de sessions côté serveur qui persiste la liste des messages, la tronque intelligemment et envoie la bonne portion au modèle à chaque appel.
Le modèle que vous choisissez détermine le plafond des capacités de votre chatbot. Il n’existe pas de réponse unique, mais il existe des compromis clairs qu’il vaut la peine de comprendre avant de vous engager dans une direction d’infrastructure.
| Open source | Propriétaire | |
|---|---|---|
| Coût | Hébergement gratuit ou peu coûteux | Paiement au token |
| Confidentialité | Les données restent sur vos serveurs | Données envoyées au fournisseur |
| Performance | Varie selon la taille du modèle | Généralement plus solide |
| Contrôle | Accès complet au fine-tuning | API uniquement |
| Délai de mise en place | Nécessite une infrastructure | Opérationnel en quelques minutes |
Pour le prototypage, les modèles propriétaires l’emportent en matière de rapidité. GPT-5 et Claude 4 Sonnet vous mènent rapidement à une démo fonctionnelle. Pour la production, avec des exigences strictes de confidentialité ou un volume très élevé, des modèles comme Llama 4 Maverick Instruct ou Mistral 7B v0.1 exécutés sur votre propre infrastructure réduisent sensiblement les coûts.
Un chatbot repose sur trois éléments qui travaillent ensemble : un magasin de messages, un prompt système et un appel d’API. Si vous maîtrisez ces trois éléments, tout le reste relève du polissage.
Le prompt système définit la personnalité de votre chatbot et ses règles de fonctionnement. Il s’exécute avant chaque conversation et pose le cadre de toutes les réponses. C’est là que la plupart des projets de chatbot réussissent ou échouent.
Un prompt système faible : "You are a helpful assistant."
Un prompt système solide :
You are a customer support agent for a SaaS product called Orbit.
You only answer questions about Orbit's features, pricing, and troubleshooting.
If a user asks about something outside Orbit, politely redirect them.
Keep responses under 150 words unless the user explicitly asks for more detail.
Never make up pricing figures. If you do not know the answer, say so clearly
and offer to escalate to a human agent.
La différence tient à la précision. Le modèle a besoin de contraintes, pas seulement d’un rôle. Les contraintes produisent un comportement constant et prévisible. Des rôles vagues produisent des résultats vagues.
💡 Testez votre prompt système en demandant au bot de faire des choses qu’il devrait refuser. Un prompt qui tient face à des entrées adverses tiendra en production.
Rédigez votre prompt système comme une fiche de poste destinée à un employé très littéral, qui fait exactement ce que vous dites et rien de plus. Chaque phrase qui ajoute une contrainte réduit l’imprévisibilité.
Votre magasin de messages est une liste d’objets, chacun avec un rôle (system, user ou assistant) et un contenu. Une conversation typique ressemble à ceci :
messages = [
{"role": "system", "content": "You are a helpful support agent..."},
{"role": "user", "content": "How do I reset my password?"},
{"role": "assistant", "content": "To reset your password, click..."},
{"role": "user", "content": "I do not see that button anywhere."},
]
Vous ajoutez chaque nouveau message utilisateur et chaque réponse de l’assistant à cette liste. À chaque appel d’API, vous envoyez la liste complète. Le modèle lit l’intégralité de la conversation et génère la réponse suivante dans ce contexte.
Stratégie de troncature : lorsque la liste devient longue, tronquez-la avant l’envoi pour éviter les erreurs de fenêtre de contexte. Trois options :
La fenêtre glissante est la plus simple à implémenter et convient à la plupart des cas d’usage. Le résumé préserve davantage de contexte, au prix d’appels d’API supplémentaires et d’une latence accrue.
La température contrôle le caractère aléatoire. À 0.0, les réponses sont déterministes et souvent répétitives. À 1.0, elles sont créatives et enclines à dériver hors sujet. Pour la plupart des chatbots, la plage de 0.3 à 0.7 est la bonne.
| Paramètre | Ce qu’il contrôle | Valeur typique |
|---|---|---|
temperature | Caractère aléatoire et créativité | 0,3 à 0,7 |
max_tokens | Plafond strict de la longueur de réponse | 512 à 2 048 |
top_p | Largeur de l’échantillonnage des tokens | 0,9 |
frequency_penalty | Pénalise les formulations répétées | 0,1 à 0,3 |
Le code réel est plus simple que ne le suggèrent la plupart des tutoriels. Voici une implémentation minimale fonctionnelle utilisant le client OpenAI, compatible avec la plupart des fournisseurs de LLM.
pip install openai
from openai import OpenAI
client = OpenAI(api_key="your-api-key-here")
Pour les modèles open source servis via une API locale (comme Ollama ou LM Studio), vous remplacez le paramètre base_url. Le reste du code reste identique, ce qui est l’un des véritables avantages du standard d’API compatible OpenAI adopté par la plupart des fournisseurs.
class Chatbot:
def __init__(self, system_prompt: str, max_turns: int = 20):
self.system_prompt = system_prompt
self.max_turns = max_turns
self.history = []
def chat(self, user_message: str) -> str:
self.history.append({"role": "user", "content": user_message})
# Keep only the last N turns to avoid context overflow
recent = self.history[-(self.max_turns * 2):]
messages = [
{"role": "system", "content": self.system_prompt}
] + recent
response = client.chat.completions.create(
model="gpt-5",
messages=messages,
temperature=0.5,
max_tokens=1024,
)
reply = response.choices[0].message.content
self.history.append({"role": "assistant", "content": reply})
return reply
Voici la boucle centrale. Chaque chatbot de production est une variante de ce schéma, avec une logique supplémentaire superposée.
Les utilisateurs tolèrent beaucoup mieux l’attente lorsqu’ils voient le texte apparaître en temps réel. Le streaming est intégré à toutes les grandes API de LLM et mérite d’être mis en place dès le premier jour :
stream = client.chat.completions.create(
model="gpt-5",
messages=messages,
stream=True,
)
for chunk in stream:
delta = chunk.choices[0].delta.content
if delta:
print(delta, end="", flush=True)
Diffusez la réponse vers votre interface via Server-Sent Events (SSE) ou WebSockets. La latence perçue passe de plusieurs secondes à presque instantanée, et les utilisateurs se déclarent nettement plus satisfaits des réponses diffusées en continu que lorsqu’ils attendent une réponse complète.
PicassoIA héberge plus de 65 grands modèles de langage, disponibles directement dans le navigateur, sans configuration d’API, sans paramétrage de facturation et sans infrastructure. Cela permet de tester vos prompts système et la logique de votre chatbot avant d’écrire la moindre ligne de code.
Rendez-vous dans la section Large Language Models de PicassoIA. Vous y trouverez toutes les grandes familles de modèles : GPT-5 et GPT-4o d’OpenAI, Claude 4 Sonnet d’Anthropic, Gemini 2.5 Flash de Google, Llama 4 Maverick Instruct de Meta, ainsi que des spécialistes du raisonnement comme DeepSeek R1 et Kimi K2 Instruct.
💡 Utilisez Kimi K2 Instruct lorsque votre chatbot doit écrire ou relire du code. Utilisez DeepSeek R1 lorsqu’il doit raisonner pas à pas sur des problèmes à plusieurs étapes.
Le principal mode de défaillance des chatbots en production est d’atteindre la limite de la fenêtre de contexte sans aucun code de gestion. Lorsque cela arrive, l’API renvoie une erreur context_length_exceeded et votre chatbot plante ou affiche une page d’erreur générique. Implémentez toujours une stratégie de troncature ou de résumé avant la mise en production.
Règle simple : si l’historique de votre conversation approche 80 % de la limite de contexte du modèle, calculée en nombre de tokens, commencez à supprimer les messages non système les plus anciens de la liste d’historique.
Des bibliothèques comme tiktoken (pour les modèles OpenAI) vous permettent de compter les tokens avec précision avant chaque appel d’API. Utilisez-les.
Des instructions vagues produisent un comportement vague. Trois schémas à éviter :
"Be helpful and friendly." Cela ne dit rien au modèle de ce qu’il doit faire ou ne pas faire.À grande échelle, chaque token inutile coûte de l’argent. Un prompt système de 800 tokens plus long que nécessaire coûte ces 800 tokens à chaque appel d’API. À 10 000 conversations par jour, cela représente 8 millions de tokens d’entrée supplémentaires par jour, facturés au tarif d’entrée du modèle. Auditez votre prompt système sans complaisance avant le lancement et supprimez toute consigne redondante ou verbeuse.
Chaque API de LLM impose des limites de débit : requêtes par minute, tokens par minute et, dans certains cas, plafonds quotidiens. Anticipez-les avant le lancement. Avec un faible trafic, les API propriétaires sont le bon choix pour la qualité et la rapidité. Avec un trafic élevé, l’auto-hébergement d’un modèle open source comme Llama 4 Maverick Instruct devient souvent nettement moins coûteux.
Comparaison approximative des coûts pour un chatbot gérant 10 000 conversations par jour, avec en moyenne 500 tokens de sortie par conversation :
| Modèle | Coût approximatif pour 1 M de tokens de sortie | Coût quotidien en sortie |
|---|---|---|
| GPT-4o | ~15 $ | ~75 $ |
| GPT-4o Mini | ~0,60 $ | ~3 $ |
| Claude 4 Sonnet | ~15 $ | ~75 $ |
| Llama 4 (auto-hébergé) | Infrastructure uniquement | Variable |
GPT-4o Mini mérite une évaluation sérieuse pour les cas d’usage à fort volume où la pleine capacité de GPT-4o n’est pas strictement nécessaire. Beaucoup de tâches de chatbot, comme répondre à une FAQ ou assurer un routage simple, n’ont pas besoin d’un modèle de pointe.
La mise en ligne n’est pas la fin du travail. Vous avez besoin de visibilité sur ce que votre bot dit réellement aux utilisateurs. Au minimum, journalisez chaque tour de conversation avec :
Examinez un échantillon aléatoire de conversations chaque jour pendant la première semaine. Vous repérerez les échecs de prompt, les hallucinations et les cas limites qui n’étaient pas apparus lors des tests.
💡 Mettez en place des déclencheurs de revue : si un utilisateur écrit une phrase comme « c’est faux » ou « vous avez inventé ça », signalez cette conversation pour une revue manuelle immédiate.
Une fois votre chatbot fonctionnel et déployé, ces trois ajouts le font passer du statut de démo à celui de produit :
1. Retrieval Augmented Generation (RAG) : connectez votre bot à une base de données vectorielle de vos propres documents. Au lieu de s’appuyer sur les données d’entraînement du modèle, il récupère les passages pertinents et s’en sert comme contexte avant de générer une réponse. C’est ainsi que l’on construit un chatbot capable de répondre avec exactitude aux questions sur votre produit, vos politiques internes ou votre base de connaissances, sans halluciner de détails.
2. Garde-fous : ajoutez une vérification secondaire qui valide à la fois les entrées utilisateur et les sorties du bot avant que quoi que ce soit n’atteigne l’utilisateur. Cela détecte les tentatives d’injection de prompt, les violations de politique et les réponses hors sujet avant qu’elles ne deviennent visibles pour votre public. Une couche de règles simple ou un second appel à un modèle léger suffit dans la plupart des cas.
3. Suite d’évaluation : rédigez un jeu de test de 50 à 100 paires entrée/sortie attendue couvrant les cas d’usage principaux de votre chatbot. Exécutez-le automatiquement après chaque modification du prompt système. C’est le seul moyen fiable de détecter les régressions avant que les utilisateurs ne les rencontrent. Des tests manuels à cette échelle ne sont plus réalistes après la première semaine.
L’architecture est claire. Le code n’est pas compliqué. Ce qui distingue un chatbot qui impressionne en démo d’un chatbot qui fonctionne de façon fiable en production, c’est l’itération. Plus précisément : l’itération sur le prompt système, la stratégie de troncature, le choix du modèle et la mise en place du suivi, le tout guidé par les données réelles de conversation.
Rien de cette itération n’exige d’écrire du code au préalable. Vous pouvez faire la partie la plus précieuse, trouver le bon modèle et un prompt système qui tienne vraiment, dans un navigateur, avant d’ouvrir votre environnement de développement.
PicassoIA vous donne un accès direct à plus de 65 grands modèles de langage dans votre navigateur, dont GPT-5, Claude 4 Sonnet, Llama 4 Maverick Instruct, Kimi K2 Instruct, DeepSeek R1 et Gemini 2.5 Flash.
Rédigez votre prompt système. Choisissez un modèle. Observez comment il répond réellement. Testez les cas limites. Cassez-le volontairement. Puis affinez. Cette boucle d’itération est ce qui construit la véritable qualité d’un chatbot, et vous pouvez mener tout ce processus sur PicassoIA avant de vous engager dans un seul appel d’API ou une seule ligne de code.
Les modèles sont disponibles. Votre chatbot ne se construira pas tout seul.
Choisissez votre langue
