Une application de chat IA est une interface de messagerie textuelle où l’utilisateur saisit un message ; l’application transmet ce message à un service capable d’interroger un modèle d’IA, puis affiche la réponse du modèle à l’utilisateur.
Dans de nombreux produits, la réponse est transmise sous forme de flux (streaming) : l’utilisateur voit les jetons (tokens) apparaître progressivement au lieu d’attendre la réponse complète.
Pour simplifier le schéma, imaginons une petite équipe interne utilisant une application web unique qui communique avec un service backend unique, lequel fait appel à un seul fournisseur de modèles.
Avec un serveur unique, le flux fonctionne en boucle. Le client envoie le message de l’utilisateur à un serveur API unique ; ce serveur charge la conversation pour disposer du contexte, interroge le fournisseur de modèles, puis renvoie la réponse de l’assistant au client.
Le stockage de la conversation est important, même dans ce modèle de base, car un rafraîchissement de la page ne doit pas effacer le chat. Le serveur API enregistre chaque message de l’utilisateur et de l’assistant, puis utilise ces messages stockés pour poursuivre la même conversation lors de l’échange suivant.
Voici l’échange unique (ou « tour » de conversation) que nous construisons comme modèle de référence.
Le schéma remplit quatre fonctions. Le client recueille les entrées et affiche le flux de réponse ; le serveur API gère le cycle de vie de la requête ; le système de stockage des conversations conserve les messages afin que la discussion persiste après un rafraîchissement ; enfin, l’API du modèle génère les jetons de l’assistant que le serveur transmet au client.
Le périmètre fonctionnel se limite à une messagerie textuelle simple. En l’absence d’outils, d’images ou de téléchargements de fichiers, les seules tâches à effectuer à chaque tour d’échange sont le stockage des messages, la constitution du contexte et l’appel au modèle.
Ajoutons maintenant un chiffre susceptible de mettre un serveur unique sous pression. Avec 2 000 utilisateurs simultanés effectuant deux échanges par minute, le backend doit traiter environ échanges par seconde, ce qui correspond à un nombre équivalent d’appels parallèles au modèle.
Ce chiffre unique engendre deux contraintes non fonctionnelles qui influenceront la suite de la conception. La latence devient un facteur critique, car les appels au modèle représentent la majeure partie du temps de traitement global, et le coût devient une préoccupation majeure, puisque le système est facturé à la requête et au jeton généré.
Même avant d’envisager la montée en charge, l’architecture de base se décompose naturellement en composants réutilisables, chacun ayant une responsabilité unique.