Dans le cadre de ses recrutements, Aurore Masse, Chargée RH, a voulu creuser dans le quotidien de l’équipe de développement XiVO.
A quoi ressemble le job de Dev XiVO, concrètement ? Quelle est la stack technique ? Soulevons le capot, via cette interview de Jirka Hlavacek, Lead tech / Head of Engineering chez Wisper, pour en savoir plus sur le back, le front, les environnements, l’intégration et le déploiement.
Peux-tu commencer par expliquer brièvement le produit ?
Jirka : L’aventure de la plateforme XiVO a démarré il y a une quinzaine d’années sur des technologies et problématiques assez différentes d’aujourd’hui. XiVO propose des services de communications unifiées : (appel, visio, chat, services de centre de contact – serveur vocal interactif, interface pour les agents et superviseurs, enregistrement et qualification d’appel ou encore des statistiques). La plateforme peut être intégrée comme moteur télécom pour des projets de téléphonie opérationnelle tels que les systèmes d’assistance.
Sur quel environnement travaillez-vous ?
Jirka : Notre quotidien est très riche, la partie visible de l’iceberg regroupe les interfaces web de notre client UC (Unified Communications), les applicatifs administration et CC (Contact Center), comprenant l’intégration de la voix et vidéo en s’appuyant sur la norme et les APIs WebRTC, tout cela avec Typescript, TDD et des tests Cypress pour nous aider à éviter des bugs.
Notre backend CTI est écrit en Scala avec le framework Akka pour la robustesse, toujours en TDD. La base de données principale est PostgreSQL, mais nous utilisons aussi ElasticSearch. Le moteur télécom de la plateforme est Asterisk, et la plupart des composants sont déployés dans Docker.
Peux-tu nous en dire plus sur les outils back-end ?
Jirka : Afin que tout cela soit possible il faut bien une base de configuration, dans notre cas PostgreSQL, et une interface web – cette fois en partie en PHP, mais en cours de migration vers AngularJS. Et puis côté moteur télécom (Asterisk) quelques patches ‘maison’ pour que la magie de provisioning puisse fonctionner. Et comme Asterisk est surtout une boîte à outils, il faut aussi des scripts pour vérifier le code de provisioning, les droits d’appel et autres, c’est le boulot d’un daemon en Python, xivo-agid. Les appels sortants, en revanche, sont gérés via un protocole plus récent, ARI, avec un module outcall écrit en Scala.
On ne va pas s’étaler sur la partie enregistrement d’appel, car mis à part la synchronisation des fichiers entre les serveurs de commutation et le stockage et le transcodage, cela présente peu d’intérêt. Mais sans les métadonnées permettant la recherche dans les enregistrements, les fichiers audio sont difficilement exploitables.
Regardons donc ce que nous faisons pour traiter les événements d’appel bruts délivrés par notre moteur Asterisk. Ces événements sont écrits localement dans la base PostgreSQL, d’où ils sont répliqués vers une machine dédiée pour le traitement avec une sous-partie de la configuration nécessaire pour pouvoir produire des rapports d’activité. Des modules de traitement de ces données à base de machines à état transforment ces événements en listes d’appels, transferts et d’autres objets compréhensibles par les humains, et puis en agrégations pour faciliter la création des rapports. Pour les centres de contact, nous avons également des panneaux de supervision en temps réel, soit à l’aide de l’outil Kibana, soit des pages web spécifiques à base des événements disponibles via une websocket proposé par le serveur XUC.
Serveur « XUC » ?
Seulement les plus anciens, une ou deux personnes se souviennent de l’origine du nom – XiVO Unified Communications je crois. C’est notre serveur CTI. Il écrit en mode TDD, API first, en Scala en s’appuyant sur le framework AKKA, qui a permis de profiter du principe de langage Erlang conçu par Ericsson spécialement pour les standards téléphoniques qui doivent « survivre » à toutes les erreurs. C’est vrai qu’il ne se plante jamais, les bugs n’impactent que des sous-systèmes (sauf en cas de surcharge, où même AKKA ne sait pas faire de miracles).
Ok plus clair, merci ; et côté front ?
Jirka : Que ce soit pour les interfaces d’administration, gestion ou pilotage du contre de contact, ou des applications offrant les services de communication voix ou vidéo à base de la technologie WebRTC, nous nous appuyons sur le typescript et AngularJS, toujours avec TDD et CI.
Un mot sur la chaîne d’intégration et de déploiement ?
Jirka : Les évolutions et corrections sont produites par chaque développeur·se dans les branches pour être revues et mergées par un autre membre de l’équipe suivant une « definition of done ». Tout cela supporté et supervisé par Jenkins, notre moteur d’intégration continue. Il s’occupe aussi de lancement des « daily install tests », et nous avons aussi des plateformes de charge pour identifier des fuites de mémoire ou d’autres problèmes qui ne sont visibles que sur du long-terme. Des émulateurs d’appel de type sipp nous aident bien, mais faute de trouver un équivalent pour WebRTC, nous avons notre propre pondeuse d’appels et des enregistrements WebRTC, puisque notre plateforme doit supporter plusieurs milliers d’utilisateurs et plusieurs centaines d’appels simultanés.
Pour la production nous avons adopté Docker depuis ses débuts. Ce n’était pas facile tous les jours au départ, mais l’outil est devenu mature très rapidement et nous facilite les tâches quotidiennes.
« Depuis le début » : quels étaient ces débuts ?
A l’époque, l’interconnexion avec les réseaux RNIS était le Saint Graal, cela concernait à la fois les problématiques de pilote du matériel Digium mais aussi la configuration du moteur télécom Asterisk, qui est le chef d’orchestre. Notre projet a beaucoup évolué depuis. Nous restons fidèles à l’Open Source, mais les problématiques adressées aujourd’hui sont très variées, ce qui fait que nos journées sont très enrichissantes… et parfois pleines de défis !
XiVO tourne sous Debian, et l’intégration du serveur DHCP permettant l’approvisionnement des postes et d’autres services nécessitent une intégration poussée avec l’OS. De plus, lors de la mise à jour d’une LTS (long-term support) à l’autre nous automatisons la mise à jour de Debian également, nous avons l’honneur d’avoir des clients fidèles depuis le début, c’est-à-dire plus de 10 ans !
Une fois que nous avons configuré l’OS – le bon partitioning du disque, configuration du NTP, DNS et autres – la partie approvisionnement des postes nous attend. Un serveur DHCP, soigneusement configuré pour attribuer l’adresse IP jusqu’aux terminaux connus par le système (les préfixes des adresses MAC nous aident avec cela), ce même serveur DHCP pousse les options nécessaires pour récupérer la configuration et le firmware du poste. D’abord en autoprovisioning, pour que l’utilisateur puisse « apprivoiser » les postes, ensuite via son code de provisioning.
Qu’aimerais-tu rajouter, pour donner envie aux personnes qui nous lisent de postuler ?
Jirka : Il y a bien plus à découvrir : les pondeuses d’appels pour les tests de charge, les mécanismes permettant de détecter les problèmes réseau impactant la qualité de la voix – entre autres.
Il y a des jours où on aimerait rester dans notre zone de confort, mais sur ce produit il faut se dépasser et parfois aller résoudre un problème dans un domaine où on n’a pas encore les reins assez solides. C’est cette curiosité insatiable, ce goût du challenge, le tout dans un projet open source, qui fédère autant l’équipe – et on est une équipe sympa, autoorganisée et bienveillante. Faisons connaissance !
Maintenant que vous connaissez la Stack Technique Wisper sur le bout des doigts, rejoignez nos équipes R&D et postulez dès aujourd’hui !
Découvrez plus précisément les cas d’usage de la solution XiVO avec des cas clients comme Gédimat, SantéVet, Groupama ou encore la Ville de Lille et l’Université de Lille.
