Détails techniques

Cette page s’adresse aux personnes qui souhaitent entrer dans le détail. Tout ce qui suit a été mesuré ou relevé dans le code source ; rien n’est estimé.

Comment le widget se charge

En deux étapes. D’abord, un petit chargeur dessine le bouton et ne fait rien d’autre. Le chat lui-même n’est chargé que lorsqu’un des cinq déclencheurs se produit : le navigateur est disponible (au plus tard après trois secondes), une souris ou un doigt touche le bouton, une commande provient de la page, MousePlayer envoie un signal de frustration ou une relance push arrive, par exemple depuis votre service worker.

La raison est simple : la plupart des visiteurs n’ouvrent jamais le chat. Pour eux, il ne doit pas retarder le chargement de la page ; les déclencheurs applicables se définissent sur la balise script.

• Chargeur : 3,48 kB, tels que notre CDN les transfère avec gzip
• Widget complet : 85,5 kB, transférés de la même manière, uniquement lorsqu’un des déclencheurs se produit
• Délai avant l’apparition du bouton : 11–21 ms
• Décalage de mise en page : 0,0000 – l’espace est réservé avant toute apparition

À titre de comparaison, également mesurés et tous trois compressés avec brotli : le chargeur de Crisp fait 2 876 B, celui d’Intercom 3 161 B. Avec 3 069 B, nous sommes entre les deux, pas plusieurs ordres de grandeur en dessous. Quiconque affirme le contraire n’a pas mesuré.

Il ne perturbe pas votre site

Le widget se trouve dans un shadow DOM fermé. Vos styles ne peuvent pas l’atteindre, ses styles ne peuvent pas atteindre votre page, même si vous définissez * { box-sizing: border-box } ou utilisez un framework CSS qui redéfinit tout.

Il fonctionne avec une Content Security Policy stricte sans aucun message dans la console : aucun eval, aucune police web, aucun pixel de suivi. Il définit ses styles avec des feuilles de style constructibles, que style-src ne couvre pas. Le bouton, la fenêtre du chat, les visites guidées du produit et la console agents sur votre site n’ont donc pas besoin de unsafe-inline. Mesures sous style-src 'self' et même sous style-src 'none' : aucune violation, tous les styles appliqués. Mesuré dans un Chromium actuel ; les navigateurs plus anciens sans feuilles de style constructibles (comme Safari avant 16.4) utilisent en repli un élément <style>, bloqué par une politique stricte.

Aucune requête vers d’autres serveurs. Tout provient de reactive.chat ou, avec un domaine personnalisé, de votre propre adresse ; les images comme le logo et les avatars proviennent des adresses que vous fournissez vous-même.

Le protocole

La connexion utilise WebSocket ; lorsqu’un réseau ne le laisse pas passer, elle utilise des requêtes HTTPS ordinaires (Server-Sent Events ou interrogation longue). Le protocole est versionné et définit 31 codes d’erreur, dont 26 pour le widget et les autres pour l’espace agents et la recherche sur le site. Chacun impose une réaction au client (réessayer immédiatement, après une attente, après reconnexion ou ne pas réessayer), avec parfois un code de fermeture. Une erreur absente de la liste est traitée comme une erreur temporaire du serveur : nouvelle tentative après une attente ; après cinq tentatives, le message est considéré comme non distribué et peut être renvoyé. Aucune boucle sans fin.

Reconnexion avec délai croissant. Si la connexion tombe, les messages sont mis en tampon et envoyés dès son retour. Chaque message porte un identifiant ; le serveur reconnaît les répétitions et ne les stocke pas deux fois.

Accessibilité

Conçu selon WCAG 2.2 AA :

• Focus maintenu dans la fenêtre ouverte, Échap ferme la fenêtre, le focus revient à son emplacement précédent
• Annonce des nouveaux messages via aria-live
• Contraste entre le texte et la surface calculé, pas supposé – voir ci-dessous
• Utilisable entièrement au clavier, indicateur de focus visible

Le contraste est calculé

Vous donnez une couleur. La surface prend exactement cette couleur. La couleur du texte est ajustée jusqu’à atteindre un rapport de 4,5:1, l’exigence WCAG pour le texte normal.

Mesuré sur 178 couleurs, deux thèmes et trois associations, soit 1 068 points de données : aucun en dessous de 4,5:1, avec une valeur minimale de 4,50:1.

C’est la différence avec d’autres fournisseurs : chez eux, il est possible de configurer un widget jusqu’à ce que plus personne ne puisse le lire.

Données personnelles

Le masquage intervient à deux endroits : dans le navigateur du visiteur avant que quoi que ce soit quitte son appareil, puis sur le serveur avant tout stockage. Sont reconnus les numéros de carte (avec vérification de Luhn), les IBAN, les adresses e-mail, les numéros de téléphone, les numéros fiscaux et les numéros de carte d’identité. Les numéros de commande et de client restent intacts.

Deux endroits, car un seul ne suffit pas : le masquage dans le navigateur peut être désactivé et celui du serveur ne voit que ce qui arrive.

Règles

Les interventions du widget sont définies dans une liste de règles déclarative, pas dans une condition du code. Six règles sont fournies par défaut (temps passé sur une page, clic de rage, erreur JavaScript, formulaire bloqué, intention d’achat, abandon du paiement) ; le clic de rage, le formulaire bloqué et l’intention d’achat ne sont détectés qu’avec MousePlayer. Vous pouvez ajouter vos propres règles dans votre compte. Avec le forfait Free, une relance active par projet s’applique.

La différence est pratique : modifier une règle revient à changer un réglage dans votre compte, pas à effectuer un déploiement.

Intégrations

Les webhooks et Slack sont terminés. Une connexion est prête pour plus de 30 autres services ; la plupart ont été testés avec des services simulés mais n’ont jamais fonctionné avec le service réel, et la page des intégrations de votre compte les signale ainsi.

L’API serveur (REST et MCP) lit les conversations, messages, projets, visiteurs, événements et règles, écrit des messages et des événements et enregistre des webhooks. La liste des visiteurs et MCP peuvent être désactivés par projet.

Chaque intégration passe par une file d’attente avec coupe-circuit : si un tiers se bloque, il est ignoré pendant un moment après des échecs répétés. Un message de chat n’est jamais retardé par cela ; c’est la règle essentielle de cette couche.

Ce qui n’est pas terminé

Pour que personne ne le découvre pendant l’intégration :

• Le pont MousePlayer fonctionne par interrogation périodique, car MousePlayer n’émet pas encore lui-même les événements convenus.
• Les pièces jointes, les tests A/B et le domaine personnalisé sont en bêta : ils fonctionnent et ont été mesurés, mais peuvent encore changer.
• Les canaux e-mail, Telegram, SMS, WhatsApp, Messenger et Instagram ont été testés avec des services simulés, pas encore avec des comptes réels. Lorsqu’une réponse via un canal échoue définitivement, la conversation ne l’indique pas actuellement.

Pour approfondir dans la documentation

Comment le widget, le serveur et la connexion fonctionnent ensemble : Architecture et fonctionnement. Connexion, repli HTTP et reconnexion : Transport. Tous les chapitres : documentation.