Construire un streaming robuste pour chatbot IA : reconnexion, réponses partielles et annonces d'état accessibles

Le streaming donne l'impression d'un chatbot IA plus rapide, car les premiers mots apparaissent avant même que la réponse complète ne soit calculée. Techniquement, cela crée cependant un flux distribué : le serveur, le fournisseur du modèle, le proxy, le navigateur et l'interface utilisateur partagent un état commun pendant plusieurs secondes ou minutes. La connexion mobile change de réseau, un onglet passe en arrière-plan, un proxy termine une connexion inactive ou un utilisateur clique à nouveau par erreur. Sans protocole clair, des morceaux de texte apparaissent en double, des déclarations incomplètes sont marquées comme terminées ou la même action d'outil est déclenchée deux fois.

Un chatbot web robuste traite donc le streaming comme une machine à états, et non comme une simple animation. Ce guide montre comment les identifiants d'événements, la reprise de session, la finalisation atomique et des messages discrets pour lecteurs d'écran fonctionnent ensemble.

Un message a besoin d'une identité permanente

Attribuez un ID de requête côté client lors de l'envoi et un ID de message immuable côté serveur. Chaque segment du flux reçoit également un numéro de séquence consécutif. Si la même requête arrive à nouveau après une erreur de connexion, le serveur ne doit pas lancer un second traitement indépendant, mais retourner l'état existant ou poursuivre l'exécution de manière sécurisée.

Ces identités remplissent des rôles différents : l'ID de requête rend l'écriture idempotente, l'ID de message désigne le résultat et le numéro de séquence ordonne les fragments. Un simple horodatage ne suffit pas, car des requêtes parallèles peuvent entrer en collision ou arriver en retard.

Séparer le transport de l'état métier

Que vous utilisiez des Server-Sent Events, des flux Fetch ou des WebSockets, le cycle de vie métier ne change pas. Modélisez au minimum les états : accepté, en cours, terminé, annulé et échoué. Seul un événement de fin explicite rend une réponse définitive. En revanche, la fin d'une connexion TCP ne garantit pas la réussite de l'opération.

Pour les Server-Sent Events, la norme HTML décrit la réattache et la transmission du dernier ID d'événement. Ce mécanisme est utile, mais il ne remplace pas un historique côté serveur. Le serveur doit savoir quels fragments appartiennent à un message et si une nouvelle requête peut ignorer les séquences déjà transmises.

Reconnexion sans texte en doublon

Conservez un tampon d'événements limité pour chaque message en cours. Lors de la reconnexion, le client envoie la dernière séquence confirmée. Le serveur ne délivre que les événements ultérieurs. Si le tampon a expiré, il ne répond pas avec des fragments devinés, mais avec un instantané du texte complet actuel et une nouvelle séquence de base.

Le client traite les événements de manière idempotente : les séquences inférieures ou égales à la dernière valeur appliquée sont ignorées. Les écarts plus importants déclenchent une récupération d'instantané. L'affichage reste ainsi exact, même si un proxy répète des données ou si le navigateur redevient en ligne après un court laps de temps.

Les réponses partielles ne doivent pas déclencher d'actions

Le texte transmis en streaming est provisoire. Des liens peuvent être encore incomplets, une condition restrictive peut n'apparaître que dans la phrase suivante, et les arguments structurés d'un outil sont syntaxiquement invalides jusqu'à la fin. Affichez le texte de façon progressive, mais n'activez les actions à risque qu'une fois le flux terminé et après une validation distincte.

Cela vaut particulièrement pour les commandes, la prise de rendez-vous, la modification de données clients ou l'envoi d'e-mails. L'exécution d'un outil nécessite son propre ID d'action idempotent, un contrôle d'autorisations et, si nécessaire, une confirmation visuelle. Une reconnexion ne doit jamais réexécuter le même effet secondaire.

Traiter l'annulation comme un vrai événement de protocole

Un bouton d'arrêt ne doit pas seulement interrompre le rendu visuel. Le client envoie une demande d'annulation contenant l'ID du message ; le serveur marque l'exécution et met fin, dans la mesure du possible, aux traitements du modèle et des outils. Les fragments arrivant ultérieurement sont rejetés. L'interface doit indiquer clairement que la réponse a été annulée.

Si la demande d'annulation n'atteint pas le serveur, des traitements peuvent continuer à s'y exécuter. C'est pourquoi le serveur vérifie lui aussi régulièrement cet état. Les métriques de coût et de latence doivent compter les Exécutions annulées séparément, sous peine de les faire passer pour des erreurs normales ou de les masquer de l'analyse.

Rendre les erreurs compréhensibles et reproductibles

Distinguez au minimum les interruptions réseau, les dépassements de délai, les erreurs de fournisseur, les blocages de sécurité et les échecs de validation métier. Le message destiné à l'utilisateur n'a pas besoin de révéler les détails techniques internes, mais doit suggérer une étape suivante sûre. « Connexion interrompue – la réponse va reprendre » diffère grandement de « Cette action n'a pas été exécutée ».

Un bouton de réessai ne réutilise l'ID de requête initial que si la même exécution doit être poursuivie. Pour une véritable nouvelle génération, un nouvel ID est créé et l'interface montre les deux versions séparément, sans les fusionner en un seul résultat.

Ne pas submerger les lecteurs d'écran avec chaque jeton

Le contenu dynamique doit être perceptible par les technologies d'assistance. WAI-ARIA définit pour cela des régions en direct et différents niveaux d'urgence. Une zone mise à jour jeton par jeton avec aria-live peut provoquer des centaines d'interruptions. Il est préférable d'associer un affichage visuel du streaming à un canal d'état distinct et courtois.

Annoncez par exemple « Génération de la réponse en cours », puis à des intervalles raisonnables une phrase ou une section terminée, et enfin « Réponse complète ». Utilisez aria-live="polite" pour la progression normale ; assertive est réservé aux erreurs réellement urgentes. Le focus reste sur le champ de saisie ou à l'endroit choisi par l'utilisateur, sans sauter à chaque fragment reçu.

Placez aria-busy="true" sur la zone de réponse tant que le contenu est incomplet, puis retirez-le lors de la finalisation atomique. Le bouton d'arrêt doit avoir un nom explicite et être accessible au clavier. Pensez également à tester les modes d'animation réduite, le zoom et les affichages sur petits écrans mobiles.

Tester rigoureusement la machine à états

Un simple test de scénario idéal ne suffit pas. Automatisez au moins les cas suivants :

• Déconnecter le réseau après plusieurs fragments et reprendre sans texte en doublon.
• Délivrer deux fois le même événement et ne l'appliquer qu'une seule fois.
• Omettre une séquence et demander un instantané de rattrapage.
• Mettre l'onglet en pause, changer de réseau puis afficher la bonne fin de traitement.
• Annuler pendant la préparation d'un outil sans exécuter d'effet secondaire.
• Marquer comme incomplète une réponse partielle interrompue par un délai dépassé.
• Vérifier la fréquence des annonces vocales et le comportement du focus pour les lecteurs d'écran.

Mesurez le temps jusqu'au premier fragment visible, le temps jusqu'à l'achèvement complet, le taux de reconnexion, les séquences répétées ou rejetées ainsi que le succès des annulations. Le temps jusqu'au premier jeton peut sembler excellent alors même que de nombreuses réponses n'aboutissent jamais correctement.

Un plan de déploiement progressif

1. Définir les états de message et d'événement côté serveur.
2. Implémenter les identifiants idempotents et la numérotation des séquences avant l'animation UI.
3. Ajouter la reconnexion avec tampon et l'option de secours par instantané.
4. Séparer strictement l'exécution des outils du texte provisoire.
5. Tester les annonces d'état au clavier et avec un lecteur d'écran.
6. Valider les cas d'erreur sous un réseau restreint ou instable.
7. Activer le streaming progressivement pour le trafic de production seulement après ces étapes.

Conclusion : Rapidement visible, clairement finalisé

Un streaming réussi combine une vitesse perçue élevée et un modèle de vérité sans ambiguïté. Des ID permanents, des événements ordonnés, une finalisation atomique et une reconnexion sûre évitent les réponses en double ou tronquées. Une zone en direct discrète rend l'expérience accessible sans assaillir les utilisateurs de lecteurs d'écran à chaque jeton.

Testez ensuite votre chat en conditions réelles sur un réseau mobile instable. Si après une coupure et une reconnexion, vous ne pouvez pas savoir avec certitude quel message est complet et quelle action a été exécutée, c'est le protocole qu'il faut corriger — pas l'animation de chargement.

Sources

• Spécification WHATWG HTML : Server-Sent Events
• MDN Web Docs : API Streams
• W3C : WAI-ARIA 1.2
• W3C WAI : Messages d'état avec les zones en direct ARIA