chatbuss_chat 1.0.0

Support client in-app pour applications Flutter — messagerie temps réel, pièces jointes et enquête de satisfaction, adossés à la plateforme ChatBuss.

Journal des versions

Le SDK est embarqué dans des applications tierces que ni un déploiement ni une mise à jour serveur ne peuvent corriger à distance : chaque version part en revue sur les stores et une partie du parc ne se met jamais à jour. Toute évolution du contrat doit donc rester rétrocompatible, ou changer de version majeure.

1.0.0

Façade serveur dédiée (FIX-01) — rupture de contrat

Jusqu'ici le SDK appelait /api/v1/livechat/*, exactement comme le widget web. Un seul contrat servait donc un client qui se redéploie en une minute et un client qui met des jours à passer les stores — et dont une partie du parc ne se met jamais à jour. Toute évolution pour le web cassait les applications déjà publiées.

• Base d'URL : /api/v1/app-chat/v1/. Une v2 pourra vivre à côté de la v1 le temps que le parc se renouvelle.
• POST /init devient POST /session ; visitor_id devient user_id. Une application a des utilisateurs identifiés, pas des visiteurs anonymes.
• En-tête X-Chatbuss-SDK sur chaque requête, exposé par ChatbussClient.contractVersion.
• ChatbussException.isOutdated (HTTP 426) : le serveur ne parle plus notre version. Rejouer n'y changera rien — l'application doit inviter à la mise à jour, au lieu d'échouer sans explication.
• Le canal doit être de type app_chat, pas livechat. Un identifiant de widget web est désormais refusé, et réciproquement : sans cela, la configuration prévue pour un site s'appliquerait à une application.

Migration. Créer un canal app_chat dans la console et remplacer le channelId. Aucun autre changement côté application : l'API Dart est inchangée.

0.3.0 — non publiée

Pièces jointes (FIX-23)

Le SDK n'envoyait que du texte. « Envoyez-moi une capture d'écran » — le cas d'usage n°1 du support d'une application — obligeait l'agent à basculer le client sur WhatsApp, et la conversation se coupait en deux.

• ChatbussClient.sendMedia(bytes:, filename:, mimeType:) — sans dépendance : le SDK ne choisit pas le fichier, il reçoit des octets. C'est ce qui lui évite d'imposer un sélecteur natif à l'application hôte.
• ChatAttachment sur ChatMessage : URL, type, nom, taille (entier ; le serveur normalise une colonne stockée en texte).
• Bouton trombone dans ChatbussChatScreen, avec aperçu local pendant l'envoi.
• Contrôles avant le téléversement — cinq formats, 10 Mo — pour ne pas faire monter un fichier sur une connexion mobile et récolter un refus.
• Un média envoyé par l'agent arrive maintenant entier en temps réel : la charge utile poussée au visiteur écrivait "type": "text" en dur et laissait tomber la pièce jointe.

Enquête de satisfaction (FIX-26)

Le CSAT n'atteignait pas le livechat : côté serveur, send_survey_via_channel ne connaissait pas ce type de canal et marquait l'enquête failed. Aucun utilisateur d'application mobile n'en a jamais reçu.

• ChatSurvey sur ChatMessage : barème, réponse déjà donnée, options.
• ChatbussClient.answerSurvey(surveyId:, rating:, comment:).
• Étoiles cliquables dans ChatbussChatScreen, figées après la réponse — le serveur refuse la seconde, et laisser appuyer laisserait croire à une correction possible.
• Une enquête déjà répondue vaut succès : un double appui n'est pas une faute.

Temps réel versionné

Le SDK se connectait à /api/v1/ws/livechat, partagé avec le widget web : le versionnement obtenu sur les routes HTTP ne couvrait donc pas le temps réel. Modifier la forme d'un événement aurait cassé les applications publiées, par l'autre porte. Le SDK vise désormais /api/v1/ws/app-chat/v1, avec user_id.

Dépendances

• file_picker: ^8.0.0 — sélecteur par défaut du bouton trombone. Surchargeable via ChatbussChatScreen(pickAttachment: ...) : une application qui possède déjà le sien évite ainsi deux sélecteurs différents selon l'écran.
• http_parser: ^4.0.0 — déjà tirée par http, désormais déclarée : sendMedia en importe MediaType directement, et dépendre d'une transitive se casse en silence le jour où http change la sienne.

Limite assumée

Une pièce jointe en échec ne survit pas à la fermeture de l'application, contrairement au texte (gardé dans la file persistée) : écrire 10 Mo dans les préférences partagées à chaque envoi serait ruineux.

0.1.0 — non publiée

Première mise sous gestion de version. Le SDK existait déjà mais n'était suivi par aucun dépôt : ce commit initial fige l'état atteint au 3 août 2026.

Fonctionnalités

• Écran de chat clé en main (ChatbussChatScreen) et client bas niveau (ChatbussClient) pour une interface sur mesure.
• Session visiteur persistée (SharedPreferences) : la conversation reprend au relancement de l'application.
• Réception des réponses par interrogation périodique (3 s).
• Enregistrement du jeton push, l'initialisation Firebase restant à la charge de l'application hôte.

Ajouts du 3 août 2026

• ChatUser.externalUserId — pivot d'identité prioritaire sur l'email. L'email peut changer ; un changement scindait alors l'historique en deux contacts.
• ChatUser.userHash — signature HMAC-SHA256 calculée par le backend de l'application hôte. Sans elle, une identité déclarée est crue sur parole, et connaître l'email d'un utilisateur suffit à lire son historique de support. Exigée uniquement si le canal active la vérification côté ChatBuss.
• Application d'exemple : serveur et canal configurables par --dart-define (CHATBUSS_SERVER, CHATBUSS_CHANNEL) au lieu de valeurs en dur, et trafic HTTP en clair autorisé dans le manifeste de debug uniquement, pour joindre un serveur local.

Limites connues

Recensées dans chatbuss_server/docs/features/LIVECHAT_MODULE.md (§14). Les principales : réception par interrogation et non en temps réel, aucune pièce jointe, aucun formulaire d'identification quand l'application hôte ne fournit pas l'identité, notification non actionnable, et absence d'API de déconnexion.