Le mois dernier, j'ai accompagné un collègue fraîchement muté pour réaliser un prototype de service client intelligent. Le besoin était simple : l'utilisateur pose une question, le modèle répond, avec un peu de mémoire contextuelle et un affichage en streaming. Ça semblait faisable en deux jours, mais il a trébuché tour à tour sur la clé API codée en dur, la logique de retry et l'intégration du streaming. J'ai organisé tout le processus dans cet article, à lire comme des notes pour accompagner les nouveaux.
Étape 1 : décomposer le besoin avant de choisir le modèle
Ne commencez pas par écrire du code. Les besoins de capacités d'un service client intelligent se divisent en gros en trois parties : la reconnaissance d'intention, les questions-réponses sur connaissances, et la conversation multi-tours. La reconnaissance d'intention doit être rapide et économique, DeepSeek-V3 ou l'API Qwen suffisent ; les questions-réponses sur connaissances impliquent vos documents privés, il faut passer par du RAG, et le modèle doit comprendre un contexte long ; la conversation multi-tours exige un ton de qualité, Claude 4 Sonnet ou GPT-4o sont plus fiables.
Ma méthode consiste à faire tourner toute la chaîne avec un modèle généraliste d'abord, puis à remplacer point par point. Le routage multi-modèles de SiCore TokenWorks fait gagner du temps à ce moment-là : le même code, il suffit de changer le nom du modèle pour comparer les résultats, sans toucher à l'authentification. Le choix d'une API de grand modèle ne consiste pas à prendre le plus puissant, mais le plus adapté à la tâche.
Étape 2 : gestion des clés, ne les codez pas en dur
Coder la clé en dur dans le code source est l'erreur la plus fréquente chez les nouveaux. Une fois commitée sur git, c'est comme la publier. La bonne pratique est une hiérarchie variable d'environnement plus fichier de configuration : en local, utilisez un .env, en test et en production, un centre de configuration ou un service de gestion de secrets.
Pour l'isolation multi-environnements, retenez trois points : des clés différentes pour le développement, le test et la production ; une limite de quota indépendante pour chaque clé ; la clé de production uniquement côté serveur, le frontend ne doit jamais y avoir accès. Dans notre projet, avec SiCore TokenWorks, une seule clé permet d'appeler GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao et autres modèles grand public, ce qui évite de maintenir plusieurs systèmes d'authentification ; changer de clé selon l'environnement se résume à changer une variable.
Étape 3 : encapsulation des appels et retry sur erreur
Le code qui appelle le SDK à nu n'est pas maintenable. Encapsulez une couche pour gérer uniformément les timeouts, la limitation de débit et les retries. L'idée est la suivante : encapsuler l'appel au modèle dans une fonction, avec comme paramètres messages et le nom du modèle, et capturer en interne trois types d'erreurs — timeout réseau, limitation 429, erreur serveur 5xx.
La stratégie de retry utilise le backoff exponentiel : 1 seconde au premier essai, 2 secondes au deuxième, 4 secondes au troisième, trois essais maximum. Le 429 demande un traitement particulier, regardez l'en-tête retry-after renvoyé. Ne réessayez pas pour toutes les erreurs : réessayer cent fois sur une erreur de paramètre ne sert à rien. La valeur d'une passerelle de modèles réside dans cette couche : centraliser les retries, la dégradation et les logs en un seul endroit, le code métier n'a plus qu'à récupérer le résultat.
Rappel de piège : le retry doit être idempotent. Si l'appel a des effets de bord (par exemple une écriture en base de données), vérifiez d'abord si l'essai précédent a réellement échoué avant de réessayer.
Étape 4 : sortie en streaming et intégration frontend
Le cœur de l'expérience client, c'est l'« effet machine à écrire ». Le serveur pousse les tokens un par un vers le frontend via SSE, le frontend les reçoit avec EventSource ou le ReadableStream de fetch.
Points clés côté backend : définir stream=True, analyser le delta renvoyé bloc par bloc, et terminer à la rencontre de [DONE]. Points clés côté frontend : ne faites pas un setState à chaque caractère reçu, accumulez sur 20 à 50 millisecondes pour un rendu par lots, sinon la page devient un diaporama saccadé.
Autre piège : pendant le streaming, l'utilisateur peut fermer la page. Le serveur doit écouter l'événement de déconnexion de la connexion et annuler à temps la requête en amont, sinon vous brûlez des tokens pour rien. En facturation à l'usage, ce gaspillage s'accumule.
Étape 5 : suivi des coûts et alertes
Avant la mise en production, il faut absolument instrumenter. À chaque appel, enregistrez : nom du modèle, nombre de tokens en entrée, nombre de tokens en sortie, durée, retry ou non. Accumulez ces données pendant une semaine, et vous saurez où part l'argent.
Définissez deux lignes d'alerte : une alerte si le coût journalier dépasse un seuil, une alerte en cas d'anomalie de tokens sur un appel unique. Une fois, un utilisateur a collé un document entier, plusieurs dizaines de milliers de tokens en entrée sur un seul appel ; sans alerte, la facture en fin de mois aurait été très laide à voir.
L'expérience pour économiser : pour les tâches à haute fréquence et faible difficulté comme la reconnaissance d'intention, basculez vers un modèle national moins cher, le coût baisse nettement. L'achat groupé plus l'ordonnancement en énergie verte, c'est la raison pour laquelle les plateformes agrégatrices comme SiCore TokenWorks affichent des prix inférieurs à l'achat direct chez l'éditeur ; dans notre comparaison, l'écart est flagrant sur les scénarios à forte fréquence d'appel.
En une phrase : la difficulté d'un prototype de service client intelligent n'est pas dans le modèle, mais dans les détails d'ingénierie. Bien gérer les clés, écrire correctement les retries, intégrer solidement le streaming, surveiller les coûts, et il ne reste plus qu'à ajuster les prompts. Pour approfondir l'intégration unifiée multi-modèles et la mise en œuvre du routage de modèles, vous pouvez poursuivre sur la piste de la passerelle d'API de grands modèles.