Une communication temps réel et bidirectionnelle entre serveur et navigateur
Les technologies Ajax peuvent être considérées comme l’ancêtre des WebSockets dans la mesure où elles ont apporté davantage de finesse dans la communication entre navigateur et serveur. Mais elles se limitaient à la communication du navigateur vers le serveur, avec des requêtes qui évitaient de rafraîchir l’ensemble de l’écran du navigateur.
WebSocket permet pour sa part un dialogue bidirectionnel. Le serveur peut ainsi envoyer des informations au client sans que celui-ci l’ait sollicité. Un tel dialogue n’était auparavant possible que moyennant l’installation, toujours contraignante, d’un client lourd ou léger (Flash, ActiveX, applet Java…). WebSocket se concrétise par un nouveau protocole qui se substitue à http et permet d’envoyer des messages de façon bidirectionnelle. La normalisation, liée à celle de HTML 5, est en cours de finalisation. Mais WebSocket est déjà supporté par presque tous les navigateurs.
Les centres de contacts en profiteront en premier lieu
Le champ d’application de WebSocket est immense mais s’exprime plus particulièrement dans le domaine de la relation client omnicanale/multicanale. En effet, les applications serveurs liées aux centres de contacts doivent couramment pousser des notifications (appels entrants, e-mails…) vers les téléconseillers, ce qui nécessite l’envoi de données, du serveur vers le navigateur.
En particulier, le CTI (couplage téléphonie- informatique) nécessite une communication entre une application CRM et un « bandeau téléphonique ». Ce dernier est une petite application cliente qui permet au téléconseiller de gérer les fonctions téléphoniques. Lorsqu’un appel entrant se présente dans le système Voix, celui-ci doit notifier le bandeau du téléconseiller par un message qui va donc du serveur vers le client. Ce bandeau est fréquemment couplé à un CRM. La présentation d’un appel entrant aboutit alors à une montée de fiche de l’appelant (client ou prospect) dans ce CRM. Or, ce bandeau téléphonique est souvent une application web, qui doit dialoguer de façon bidirectionnelle avec le serveur téléphonique et le navigateur affichant le CRM (si celui-ci est également une application web).
Pour permettre un tel dialogue, cette application web se présente traditionnellement sous la forme d’un composant ActiveX ou Flash, ou d’une applet Java. Or, le déclin de ces technologies amène les entreprises et éditeurs de solutions à chercher une alternative. WebSocket est le candidat idéal. D’abord parce qu’il est compatible avec n’importe quel navigateur standard, sans besoin de télécharger une applet ou un composant Flash. Ensuite parce qu’il permet une montée en charge à moindre coût – un atout essentiel dans des centres de contacts qui doivent couramment supporter des centaines voire des milliers de communications simultanées.
WebSocket optimise la montée en charge
Pour comprendre l’efficacité intrinsèque de WebSocket, un peu d’histoire s’impose. Auparavant, pour envoyer une information du serveur vers le client, le navigateur devait faire du polling (interroger régulièrement le serveur). Afin d’optimiser le polling, le serveur pouvait faire du « long polling ». Ce procédé aussi connu sous le nom de Comet consiste à laisser ouverte la connexion avec le navigateur faisant du polling. Dans tous les cas, cela consommait des ressources serveurs, ce qui limitait la montée en charge ou augmentait significativement son coût.
En permettant un dialogue bidirectionnel à l’initiative du navigateur ou du serveur, WebSocket fait sauter ces contraintes de façon spectaculaire. Un modeste serveur peut ainsi gérer à moindre coût des milliers de communications en parallèle.
Une mise en œuvre assez simple malgré quelques contraintes
L’implémentation de WebSocket est simple et basique. Coté client, un code JavaScript permet d’envoyer des messages dont le format est libre. Ce protocole traverse sans problème les firewalls et proxys car il passe toujours par le port 80 dédié au protocole http. Au moment de la connexion, le navigateur demande, en http, au serveur d’utiliser le protocole WebSocket. Si le serveur accepte, la connexion http est remplacée par une connexion WebSocket bidirectionnelle. Une connexion est établie pour chaque navigateur mais le serveur peut aussi envoyer un même message à l’ensemble des navigateurs. Si la connexion est coupée, les navigateurs et le serveur sont notifiés.
WebSocket n’est certes pas sans contraintes. Tout d’abord, en https, la connexion WebSocket doit être sécurisée, ce qui impose d’avoir un certificat valide. De plus, le serveur d’application doit être compatible WebSocket. Il est donc souvent nécessaire de le mettre à niveau (au minimum Tomcat 7.0.27 et IIS 8). Autre contrainte, l’évolution de l’existant peut imposer quelques adaptations. Ainsi, Almavia CX a développé pour le compte d’un éditeur d’une solution de centre d’appels, un bandeau téléphonique web dialoguant avec le serveur. Mais ce dernier déconnectait le client lorsqu’une communication était coupée, ce qui était incompatible avec le maintien d’une session WebSocket. Pour contourner l’obstacle, nous avons développé un proxy qui vient s’insérer entre le navigateur et le serveur, faisant croire au serveur que le navigateur est toujours connecté.
Ces contraintes mineures n’empêcheront évidemment pas WebSocket de s’imposer largement dans le domaine des centres de contacts, comme dans bien d’autres domaines nécessitant un dialogue bidirectionnel entre navigateur et serveur.
Paulo Decarvalho, consultant Centres de contacts chez Almavia CX
Almavia CX accompagne ses clients dans leur transformation digitale, sur toute la chaine de l'Expérience Client, en plaçant l’humain au cœur de son savoir-faire et au centre de sa stratégie.
