Derrière mon avatar IA : l'architecture d'un chatbot IA de bout en bout
Mais faire produire une réponse par un modèle de langage sur une machine ne suffit pas à en faire un service fiable. Entre la question et la réponse s'enchaînent une interface, une validation, un appel réseau, un modèle, une gestion des visiteurs simultanés, une couche de sécurité, des journaux et des mécanismes de reprise en cas d'erreur.
Cet article est le making-of technique de cette démonstration : ce qui tourne réellement derrière l'avatar aujourd'hui, ce qu'il faudrait ajouter pour en faire un système de production complet, et ce qui reste une extension possible plutôt qu'une fonctionnalité active. La question qui structure tout le reste : comment passe-t-on d'un modèle qui fonctionne à un système IA exploitable ?
Ce que vous voyez
L'avatar occupe l'écran de la démo ; le champ de texte (ou le micro) est juste à côté. Vous tapez une question, elle part vers le serveur, une réponse revient et s'affiche — l'avatar peut aussi la lire à voix haute, bouche animée en temps réel sur l'amplitude du son qu'il produit (une approximation assumée comme telle dans le code, pas une synchronisation labiale phonème par phonème).
Cette interface est la partie émergée. Tout ce qui rend une réponse correcte, rapide et sûre à obtenir se passe derrière, invisible pour vous.
De la question à l'API
Le champ de saisie envoie la question au serveur en une seule requête. Côté serveur : la question est validée (200 caractères maximum, jamais tronquée silencieusement), un visiteur anonyme est identifié par un cookie signé — pas de compte, pas de mot de passe — et une limite de fréquence s'applique, un délai entre deux questions et un quota par fenêtre glissante. Toute erreur réseau, tout délai dépassé renvoie un code d'erreur précis plutôt qu'un échec muet.
À approfondir : Construire une API de production autour d'un LLM →
Le modèle et son fournisseur
La démo n'exécute aucun modèle elle-même. Le serveur appelle l'API d'un fournisseur tiers qui héberge le modèle, avec un nom de modèle défini par configuration plutôt qu'écrit en dur — deux niveaux d'effort de raisonnement existent selon le mode choisi, un seul modèle derrière les deux.
Auto-héberger un modèle demanderait de choisir un moteur d'exécution (vLLM, TGI, llama.cpp, Ollama...) et d'en assumer l'exploitation — un compromis différent, pas encore fait ici.
À approfondir : Choisir le bon LLM pour son cas d'usage → · Ollama, vLLM, TGI ou llama.cpp → · Quantification d'un LLM →
Coûts et capacité d'un modèle hébergé
Sans serveur GPU à dimensionner soi-même, la contrainte se déplace ailleurs : chaque appel a un coût par token, une limite de temps (120 secondes ici) et dépend entièrement de la disponibilité du fournisseur. Le principal levier disponible aujourd'hui est le niveau d'effort de raisonnement demandé au modèle — un compromis qualité / latence / coût, pas un réglage matériel.
Le jour où l'auto-hébergement redevient pertinent, c'est le matériel (mémoire, précision, fenêtre de contexte) qui fixera ces mêmes limites autrement.
À approfondir : CPU, GPU et VRAM : dimensionner un serveur LLM →
Latence et streaming
Trois notions comptent pour la latence perçue : le temps avant le premier mot, la vitesse de génération, et la latence totale. Aujourd'hui, la démo ne fait ni l'un ni l'autre en flux continu : le serveur attend la réponse complète du modèle avant de la renvoyer en un seul bloc JSON. L'effet « en train d'écrire » que vous voyez à l'écran est une animation côté navigateur, pas un flux réel de tokens.
C'est une limite connue, pas un choix définitif : faire réellement du streaming est l'étape suivante logique.
À approfondir : TTFT, tokens/seconde et streaming : comprendre la latence d'un LLM →
Plusieurs visiteurs en même temps
Si plusieurs personnes interrogent la démo au même moment, chacune reste bornée par les mêmes règles : un délai minimum entre deux questions, un quota par fenêtre glissante et, en option, un plafond quotidien par mode. Il n'existe en revanche aucune file d'attente ni contrôle de concurrence dédié à l'inférence : le serveur tourne sur un seul processus, un choix fait pour la sécurité des écritures en base, pas pour absorber une charge importante.
Faire cohabiter proprement de nombreuses requêtes simultanées reste un chantier à part entière.
À approfondir : Files d'attente, concurrence et backpressure pour servir un LLM →
Contexte, mémoire et RAG
Le modèle ne connaît par défaut ni votre historique ni vos documents. Trois mécanismes existent déjà : les derniers messages sont renvoyés tels quels à chaque appel, l'historique plus ancien est résumé automatiquement une fois un certain volume dépassé, et une mémoire durable, opt-in, peut être conservée entre les sessions si le visiteur y consent explicitement.
Un RAG existe également, mais seulement sur les documents qu'un visiteur importe dans sa propre conversation — ce n'est pas une base de connaissances permanente sur l'entreprise. L'étendre à une base documentaire globale reste une extension possible, pas une fonctionnalité active aujourd'hui.
À approfondir : Gérer le contexte, la mémoire et le RAG sans saturer le modèle →
Sécurité et exposition sur Internet
Un service accessible publiquement s'expose à des abus : requêtes malveillantes, tentatives d'injection de prompt via un document importé, saturation volontaire. La démo répond par plusieurs couches indépendantes — un piège à robots, un cookie de session signé plutôt qu'un identifiant devinable, une limite de fréquence, et un encadrement explicite du contenu de tout document avant qu'il n'atteigne le modèle. La clé d'accès au fournisseur du modèle ne quitte jamais le serveur, y compris pour la voix en temps réel, où le navigateur ne reçoit qu'un jeton temporaire.
À approfondir : Sécuriser un LLM exposé sur Internet →
Observabilité et résilience
Un point de contrôle simple répond en continu pour signaler que le service tourne. Chaque échange conserve le modèle utilisé, sa latence, ses tokens consommés et son statut, pour pouvoir être rejoué après coup plutôt que perdu dans un journal brut. Un incident réel — un secret affiché en clair dans un journal d'accès — a déjà conduit à ajouter un filtre de rédaction automatique.
Ce qui manque encore : des métriques exposées pour un tableau de bord, des tentatives automatiques après un échec, des circuit breakers. Une base existe ; l'outillage complet reste à construire.
À approfondir : Logs, métriques et traces : observer un LLM en production → · Timeouts, retries et fallbacks →
Tester avant de considérer le système comme prêt
Avant de qualifier un système IA de prêt pour la production, il faut pouvoir répondre à des questions précises : quelle proportion de réponses est correcte sur un jeu de cas réels, comment le système se comporte sous charge, quel taux d'hallucination est tolérable, quels critères déclenchent un refus de mise en production. Ce travail d'évaluation n'existe pas encore pour cette démo — il fait partie de ce qui sépare un prototype convaincant d'un système sur lequel on peut s'appuyer.
À approfondir : Évaluer, charger et red-teamer un LLM avant la production →
Exploiter le système dans la durée
Le nom du modèle est un paramètre de configuration, pas une valeur figée : le faire évoluer ne demande pas de réécrire le code. Le reste — suivi des coûts réels, décision de migrer tout ou partie vers un modèle auto-hébergé, montée en charge — dépend de l'usage observé dans la durée, pas d'un choix pris à l'avance.
À approfondir : Coûts, versions et montée en charge d'un LLM en production →
Conclusion
Revenez à l'avatar de la page d'accueil : une question, une réponse. Ce que cet article voulait montrer, c'est que la qualité d'un tel système ne tient pas qu'au modèle — elle tient à tout ce qui l'entoure : l'API qui l'expose, la sécurité qui le protège, l'observabilité qui permet de le surveiller, et les choix d'exploitation qui le font durer.
Trois façons de continuer :
Tester l'avatar → · Explorer les prochains articles → · Discuter de votre projet →