Pour créer nos solutions cloud, nous développons nos propres applications métier. Cette maîtrise logicielle renforce notre indépendance et procure les outils les plus efficaces à nos collaborateurs. Récemment, une équipe a eu carte blanche pour faire évoluer les outils du support d’Infomaniak. Nous vous racontons ce projet à travers les yeux de nos développeurs.

Nous aimons notre support au moins autant que vous

Nos agents de support sont le lien entre tout ce que nous faisons et nos utilisateurs. C’est eux qui nous remontent vos suggestions, vos problèmes et qui permettent à nos produits d’évoluer selon vos priorités. Sans son support, Infomaniak ne serait pas Infomaniak.

Écouter. Identifier. Prioriser. Coder. Ajuster.

Pour améliorer nos outils, nos développeurs ont travaillé avec leurs collègues du support, en comité restreint et sans intermédiaire. Tout a commencé par une réunion entre le support, les développeurs et les ingénieurs système. L’équipe a identifié une myriade de points d’amélioration à réaliser pour optimiser :

  • la satisfaction des clients
  • la gestion interne du service
  • l’efficacité des processus
  • le confort de travail et la satisfaction des agents

Il a fallu trouver l’équilibre entre ce qui était faisable et la vision idéale imaginée ensemble. Chaque développement de fonctionnalité a été présenté aux utilisateurs finaux pour récolter leurs impressions et leurs retours afin d’apporter les derniers ajustements.

Répondre à des problématiques spécifiques du support

Nous avons demandé aux développeurs de nous parler des nouvelles fonctionnalités qu’ils ont réalisées pour le support :

1 – Fluidité des files d’attente

Pour raccourcir l’attente en cas d’indisponibilité dans certaines files, un système “fallback” redirige l’appel des clients vers le premier opérateur disponible dans leur langue. Les horaires de chaque file d’attente sont individuellement pilotés pour chaque jour de la semaine en fonction des spécialistes ou des langues disponibles. Pour informer les clients au plus tôt, nos agents peuvent générer des messages audio dynamiques à diffuser en fonction des conditions : file d’attente, problème technique par produit, langue.

2 – Analyse et amélioration de la productivité

Nous avons mis en place des statistiques et de nouveaux indicateurs (KPI) pour produire une vue d’ensemble de l’état du support sur des périodes données. Les agents du support peuvent :

  • identifier plus rapidement les problèmes
  • être au plus proche des attentes des clients
  • s’entraider en période de rush pour répondre plus rapidement aux clients

3 – Gestion dynamique de la centrale de support

Les responsables peuvent ajouter/supprimer les agents des files d’attente, désigner et modifier leur rôle, visualiser leur statut et définir un numéro interne (ce qui n’était pas faisable avant). Ils peuvent aussi définir une musique d’attente, modifier les différents seuils d’alertes et définir les délais :

  • avant de faire sonner un autre opérateur
  • entre chaque appel
  • de déclenchement du « rush time » et du « fallback »

Les appels peuvent à présent automatiquement être redirigés vers des mobiles pour traiter des demandes, même si un agent n’est pas présent sur site (périodes de permanence).

Au coeur du développement

Lorsqu’on parle de support, chaque détail contribue à l’expérience finale des clients. Nous avons donc tout fait en interne, selon nos contraintes technologiques et nos objectifs d’avenir.

Ce projet est un très bon exemple de la réalité quotidienne de nos développeurs. Il confronte et challenge des choix technologiques par rapport aux améliorations concrètes que nous voulons apporter à l’utilisateur, tout en offrant une très forte liberté dans les différentes étapes de réalisations. Julien Viard, VP of Engineering chez Infomaniak

Le Frontend

Le développement de l’interface d’administration et des interfaces de support live (écrans de contrôle en temps réel de la centrale) a été réalisé avec le framework AngularJS. C’est la technologie historique de l’application à laquelle les développeurs se sont greffés.

Plusieurs composants ont été réalisés sur mesure pour faciliter l’utilisation comme :

  • la sélection des utilisateurs pour les assigner à des files
  • le basculement dans l’interface du compte du client
  • le défilement automatique sur les interfaces de support live

Pour le support live, un choix a dû être fait : soit mettre en place des sockets (IPS) ou alors utiliser du polling en faisant un call backend toutes les 3/4 secondes. C’est la deuxième solution qui a été retenue pour des raisons d’écoconception et de facilité de mise en œuvre. Au lieu de maintenir un canal constamment ouvert entre le frontend et le backend pour mettre à jour les données, nous gérons les calculs côté serveur. L’interface frontend puise les informations dans le cache à disposition par intervalles de 3 secondes (au lieu de 1) pour limiter les appels serveur et les calculs redondants. Pour fournir un visuel fluide et agréable aux agents de support, on simule un rafraîchissement en temps réel avec des incréments visuels toutes les secondes.

Les statistiques (KPI) ont nécessité la mise en place de plusieurs graphiques et tableaux pouvant être affichés sur des échelles de durée plus ou moins longue. Si c’est sur une journée, les statistiques sont affichées par heure et par jour si c’est sur un mois.

Le Backend

La technologie historique de la centrale du support est Asterisk (protocole SIP) et AngularJS pour les outils préexistants. Il était nécessaire de se greffer sur la base de données d’Asterisk pour récupérer certaines informations à la volée, manipuler les agents du support et créer toutes les fonctionnalités qui vont avec. Dans le cadre de ces outils, nous procédons uniquement avec des routes API (REST) qui sont appelées depuis l’interface.

De manière générale, ce projet a laissé beaucoup de place à la créativité. Avec Asterisk et une DB en realtime il était possible de faire un peu tout ce que nous souhaitions. Une fonctionnalité intéressante est qu’il est possible pour un agent de cliquer sur une file d’attente dans laquelle il ne se trouve pas initialement (par exemple un autre département ou langue) pour prendre un seul et unique appel de cette file. Il suffit d’ajouter l’agent dans la file de manière dynamique, puis de le retirer de cette dernière en interceptant son prochain appel réceptionné (à l’aide du système de gestion d’événements).

Nous avons mis en place un système de gestion d’événements : le serveur téléphonique effectue des appels API avec certains paramètres et effectue les actions liées côté backend. C’est à l’aide de ce genre d’événement qu’il est possible de voir apparaître le compte client lié (en fonction du numéro de l’appelant) dans l’interface, lors de la prise d’appel. Ce système récupère les données stockées dans la requête, puis dispatch des jobs pour que la réponse API soit très rapide et ne retarde pas la prise de l’appel en lui-même.

Pour la gestion des messages dynamiques, le texte est transcrit en vocal puis est directement déployé sur un repository Git : la centrale est greffée sur ce dernier et peut accéder aux messages en temps réel. C’est une fonctionnalité qui a été très sympa à développer étant donné qu’on peut vite constituer un petit repo de messages vocaux et y accéder depuis une interface dédiée pour les écouter / éditer.

Certaines routes d’API sont consommées directement depuis les scripts de nos administrateurs système. Les paramètres diffèrent un peu de ceux utilisés par notre interface puisque les fonctions ne sont pas 100% identiques. En une ligne de commande, on peut visualiser l’état d’une redirection et le modifier en indiquant uniquement le numéro interne et externe qui doit être utilisé. Cela permet de gérer automatiquement les redirections liées aux astreintes.

Le développement interne : un défi et un levier

C’est rare d’avoir autant de liberté dans un projet. Le rapprochement au plus près des utilisateurs finaux a permis de créer une émulsion de productivité pour faire vite, bien et pertinent. Florian Grenier, Frontend developer

Tout l’enjeu et aussi l’intérêt de ce projet, c’est sa voilure légère qui permet un maximum d’autonomie et d’efficacité. Les utilisateurs finaux sont nos propres collègues ce qui permet de placer les curseurs différemment. L’équipe volontairement minimaliste a progressé en comité restreint pendant 2 mois. Nous avons fait de l’intégration continue (CI) avec un serveur de staging 1 pour 1 serveur de production, et le déploiement automatisé sur un serveur de test est poussé via un script interne.

Faire du neuf performant avec un framework ancien

Bien qu’il existe une API intégrée au serveur Asterisk, nous avons choisi de ne pas l’utiliser. Elle ne répondait pas à nos besoins et nous ne pouvions pas modifier son comportement. Nous avons donc développé nos propres API.

L’enjeu technique de ce projet était de jongler entre les fonctionnalités disponibles, l’existant et les développements spécifiques tout en proposant des délais de mise en production assez courts et une qualité notable.

Des ajustements nécessaires

Il a été difficile de lancer des tests dans les conditions réelles de production : beaucoup plus d’appels à la fois / des appels qui durent plus longtemps / des temps d’attente plus importants. Tout cela a fait entrer l’équipe de développement dans des conditions qu’ils n’ont jamais rencontrées auparavant et qui ont nécessité des petits correctifs, par exemple au niveau des affichages en temps réel.

L’un des plus gros problèmes n’est pas arrivé tout de suite. Il a fallu attendre plusieurs semaines pour se rendre compte de l’importante quantité de logs générés par la centrale. Cela a eu tendance à trop ralentir la génération des statistiques et les différentes actions. Un système de flush automatique a été mis en place, accompagné d’un système de cache pour éviter le recalcul de données ne nécessitant pas d’être rafraichies à la même fréquence.

Les développeurs du projet

Florian Grenier, Frontend developer : j’ai rejoint Infomaniak il y a deux ans en tant que développeur Frontend. Mon parcours est assez vaste : développeur PHP, puis C#, court passage sur de l’app mobile Ionic, chef de projet junior puis développeur Java. Je suis diplômé bac+5 de l’école française Y-NOV depuis 2016 où j’ai réalisé beaucoup de projets et de concours de développement, hors école aussi. Côté ressources, je me balade très souvent sur ce site pour prendre des idées. J’aime aussi suivre les tutos de Grafikart sur YouTube.

Cela peut être frustrant de faire face à d’anciennes technologies (dette technique). La réalité d’un développeur, c’est de composer avec l’existant qui n’est pas forcément très sexy au départ pour délivrer au final une solution de qualité avec un réel impact sur la vélocité de l’entreprise.

Noé Fleury, Backend developer : je suis développeur Backend chez Infomaniak depuis environ 1 an. Je me suis d’abord formé en autodidacte sur plusieurs langages (PHP, C, Python, SQL, etc.) et j’ai validé mes acquis avec un Bachelor dans une école d’ingénieur (HES) en informatique il y a 2 ans.

Ce projet prouve que nous pouvons développer des outils très efficaces sans avoir recours à des solutions externes moins flexibles. Puisque l’interface est dédiée à l’usage interne uniquement, il a été possible d’ajouter de petites fonctionnalités non prévues, mais qui sont finalement très utiles au quotidien.