Nouveau Manager : OVH mise sur le développement Full-Stack et l’UX

Temps de lecture estimé : 12 minutes

*Attention, ce contenu a été publié il y a 2 années. Il n'est peut-être plus d'actualité.*

PayPal, Netflix, et tout récemment WordPress ont adopté le Javascript Full-Stack. Cela signifie que ces applications utilisent désormais le même langage pour le front-end, le middleware et les bases de données. Ce mouvement, OVH y a participé très tôt, puisqu’en 2013 le manager télécom a été présenté à la conférence Devoxx France comme l’une des premières interfaces client codées en AngularJS et Bootstrap – ne manquait plus que le backoffice en Javascript pour parvenir au Full-Stack. Comment rendre agiles des applications aussi complexes que le manager OVH ? Quelles technologies et méthodes permettent de rendre les développeurs plus efficaces, tout en tenant mieux compte du feedback des utilisateurs ?

Ux Team OVH

Pourquoi l’avenir est au Full-Stack

Express.js, AngularJS, ou encore Bootstrap sont les trois principaux frameworks utilisés pour réécrire le manager OVH. « Ces technologies offrent une grande liberté de conception, se réjouit Jean-Philippe Blary, développeur au sein de l’équipe UX, évoquant l’exemple des Popover affichés au sein de la section « Public Cloud » du manager. Le développeur peut désormais se mettre tout entier au service de l’expérience utilisateur. » À l’instar de nombreux développeurs, Jean-Philippe a travaillé avec le Google Web Toolkit avant d’arriver chez OVH. « Les bibliothèques de composants permettent de gagner du temps, en contrepartie de quoi il faut se satisfaire du look and feel proposé. Les modifications possibles sont marginales. Les frameworks que nous avons choisis sont, au contraire, des couteaux suisses, avec lesquels nous pouvons développer les maquettes proposées par les ergonomes quasiment à l’identique. »
Au sein de l’équipe UX, la tendance est au développeur Full-Stack, capable de travailler sur toutes les couches d’une application. « Il est en quelque sorte le pendant du devops, qui allie à ses compétences de développeur un savoir-faire en matière d’administration système », explique Kevin Bonduelle, qui travaille également à la réécriture du manager. Dans le secteur informatique, la pénurie de main d’œuvre ne touche pas tous les profils. Elle influence néanmoins les méthodes de travail et certains choix de technologie, de façon à maximiser l’efficacité des développeurs. Les généralistes ont ainsi le vent en poupe, notamment dans les startups, obligées d’innover rapidement sans pouvoir multiplier les embauches. C’est un changement important, car ces dernières années l’hyperspécialisation a été encouragée, en lien avec l’explosion du nombre de nouvelles technologies (mobile, Big Data, IoT, IA…). « Le besoin de développeurs spécialisés va demeurer, car certaines technologies ne peuvent pas être maîtrisées de façon superficielle, explique Kevin. Mais cette demande va décroître, car la tendance de fond est la simplification de la pile technologique des applications. » Dans ces conditions, le développeur Full-Stack n’est plus le « mythe » qu’ont dénoncé certains.
Il est d’ailleurs intéressant de constater que le mouvement Full-Stack essaime au-delà de l’univers IT. Pour le cabinet KPMG , le fabricant américain de batteries de voiture Tesla, qui aurait pu se limiter à être un sous-traitant des fabricants automobiles mais a choisi de construire ses propres véhicules, est ainsi dans une démarche « Full-Stack », qui vise à maîtriser toute la chaîne de valeur d’une innovation. Il y a quelques mois encore, on parlait d’intégration verticale. Le vocabulaire de l’informatique fertilise aujourd’hui le champ lexical de l’économie. Faut-il y voir le signe de son importance grandissante ?

Google Trends permet de se rendre compte, au moyen des volumes de recherche enregistrés par le moteur de recherche, que l’utilisation des technologies node.js (en vert), AngularJS (rouge) et bootstrap (violet) a explosé à partir de 2013.
Google Trends permet de se rendre compte, au moyen des volumes de recherche enregistrés par le moteur de recherche, que l’utilisation des technologies node.js (en vert), AngularJS (rouge) et bootstrap (violet) a explosé à partir de 2013.

Manager OVH : d’une conception monolithique orientée technique à une conception modulaire pilotée par l’utilisateur

Après onze années de bons et loyaux services, le manager v3 est en passe d’être enterré, au profit du « v6 », une application full Javascript user-friendly. « Une révolution ! commente Jean-Philippe. Car la conception du manager v3 est l’héritage du règne des développeurs chez OVH : lorsqu’un département avait la capacité technique de développer une nouvelle fonctionnalité, celle-ci était ajoutée dans l’interface. Le bouton était affiché là où il restait de la place, et on ne souciait pas assez de savoir s’il répondait à un besoin. Qui plus est, le manager v3 n’a pas été pensé pour exploiter les données comportementales. Or, avec jusqu’à 40 000 utilisateurs quotidiens interagissant avec l’interface, nous aurions pu accumuler un savoir immense sur les améliorations à réaliser. Aujourd’hui, la conception de l’interface client est la mission d’une seule et même équipe, l’UX, et elle est centrée utilisateur/métier : on analyse les besoins, on maquette, on teste, on développe, on recueille le feedback et on itère. » L’objectif de l’équipe UX est de cacher la complexité d’OVH derrière une interface simple : « Si notre travail n’est pas à la hauteur, la sanction est immédiate : les clients engorgent les files d’appels du support, utilisent l’API directement pour ceux qui le peuvent, ou tout simplement nous quittent… ». Un indice de satisfaction est d’ailleurs mesuré mensuellement, grâce à l’envoi de plusieurs milliers de questionnaires à un panel de clients ayant récemment utilisé le manager.

Aperçu des architectures techniques respectives du Manager v3 et v6.
Aperçu des architectures techniques respectives du Manager v3 et v6.

La migration du manager v3 à l’espace client v6 est un chantier colossal, précisément parce que ce n’est pas une migration, mais une réécriture depuis zéro de plus de 400 fonctionnalités macroscopiques, qui se déclinent en dizaines de milliers de cas d’utilisation à prendre en compte. « L’architecture sous-jacente a été entièrement repensée, explique Kevin. Le manager v3 reposait sur une architecture monolithique en Perl, XML et XSLT, à laquelle la base de données était directement greffée. Chaque modification, même graphique, était périlleuse. Et les calculs étant réalisés côté serveur, le temps de chargement des pages était long. » Le manager v6 s’appuie sur une architecture modulaire, avec une application web exploitant AngularJS et Bootstrap, qui requête une première API en Node.js, qui requête à son tour l’API d’OVH (au sein de laquelle on trouve du Perl, du Go, du Java et du Python), laquelle va extraire l’information au sein des bases de données. « L’API over API en Node.js, que nous avons baptisé 2API, est un middleware faisant fonction d’agrégateur de l’API v6. Elle permet de passer outre la limitation à six requêtes simultanées des navigateurs web. L’affichage de certaines pages du manager, pour les clients ayant plusieurs services OVH, peut nécessiter plusieurs centaines de requêtes. Grâce à cette solution les pages s’affichent plus rapidement, et progressivement : le chargement s’effectue au fur et à mesure que l’utilisateur scrolle. » Par ailleurs, les normes d’appel (REST) et de retour des API ont été standardisées, de façon à rendre possibles de futurs pivots technologiques.
« Nous avons encore des progrès à réaliser pour atteindre les performances souhaitées sur certaines opérations, les opérations de masse notamment. Nous y travaillons, sans exclure de remettre en question certains choix de technologie. La réflexion sur une API v7 est déjà en cours. »

L’outil City JS permet ici de comparer la structure monolithique de l’architecture du manager v3 à celle, beaucoup plus modulaire, du manager v6. La base rectangulaire blanche figure l’application dans son intégralité, en marron figurent les districts (dossiers), en rouge les modules (namespaces), en vert les fonctions anonymes et en bleu les fonctions nommées.
L’outil City JS permet ici de comparer la structure monolithique de l’architecture du manager v3 à celle, beaucoup plus modulaire, du manager v6. La base rectangulaire blanche figure l’application dans son intégralité, en marron figurent les districts (dossiers), en rouge les modules (namespaces), en vert les fonctions anonymes et en bleu les fonctions nommées.

Derrière le défi technique se cache un autre défi : faire accepter le changement aux utilisateurs. Ce à quoi s’emploie Anne-Claire Maury, ergonome au sein de l’équipe UX : « Il y a un phénomène d’habituation à l’ancienne interface, engendré par sa fréquence d’utilisation – certains clients, les revendeurs notamment, y passent plusieurs heures chaque jour – et le fait qu’elle a peu évolué au fil du temps. Ce qui la rend complément anachronique du point de vue ergonomique. Cette habituation peut rendre “allergique” au changement : le temps passé à s’approprier une interface, dans un contexte professionnel, doit être considéré comme un investissement. On peut comprendre que les utilisateurs rechignent à utiliser une autre interface. Le travail de l’ergonome, qui consiste à rendre la phase d’apprentissage la plus rapide et indolore possible, est crucial. Et c’est aussi la raison pour laquelle nous nous sommes engagés sur la voie de l’amélioration continue, avec des modifications progressives. Il n’y aura plus de changements aussi brutaux à l’avenir. »

Multiplier les retours des utilisateurs

Anne-Claire encourage, autant que possible, les utilisateurs à s’exprimer. Par exemple sur le stand qu’elle tenait durant le Summit 2015. Elle qui a déjà convié plusieurs panels de clients à Lille, pour tester différentes sections du manager durant sa réécriture, en est convaincue : « Il faut multiplier les tests. En une journée, avec cinq participants auxquels on confie un scenario semi-directif à réaliser sur un prototype dynamique, on est capable d’identifier 85 % des problèmes d’une interface. » Également menés sur des utilisateurs internes, ces tests permettent d’évaluer l’utilisabilité, c’est-à-dire l’efficience d’une application, son efficacité et la satisfaction qu’elle procure. « Et on tue dans l’œuf les conflits d’égo : c’est l’utilisateur qui tranche la pertinence de nos propositions. » Les retours proviennent également du support d’OVH, au sein duquel a été mise en place une nouvelle équipe : les chargés d’améliorations continue. « Les statistiques qu’ils alimentent en recensant le motif des appels nous servent à nourrir et prioriser notre backlog kaizen [liste de fonctionnalités et modifications attendues par les utilisateurs, NDR]. » À l’issue des tests, lorsqu’une nouvelle fonctionnalité est implémentée, Anne-Claire passe le relais aux testeurs, qui s’ingénient à débusquer les bugs en multipliant les tests fonctionnels. « Leur mission est d’envisager tous les cas d’utilisation, des plus classiques jusqu’aux plus improbables – auxquels les clients se retrouvent parfois confrontés. Puis de vérifier, en phase pré-production, que la nouvelle fonctionnalité ne casse rien. » Ces tests revêtent une importance capitale : « Dans la pyramide de Maslow revisitée pour décrire les besoins des utilisateurs du web, la base est de disposer d’une application fiable ! L’utilisabilité – sur laquelle nous concentrons nos efforts actuellement, et les aspects esthétique et émotionnel viennent ensuite. »

Les chantiers techniques : Mobile First et AngularJS 2.0

Immédiatement après que le manager v6 aura définitivement remplacé le manager v3 (ils seront iso-fonctionnels mi-janvier), une des priorités de l’équipe UX sera la stratégie Mobile First. Anne-Claire développe : « Sur l’ancien manager, le mobile représente 3 à 4 % des connexions, mais l’interface n’est clairement pas adaptée. On sait que l’on se connecte aujourd’hui à Internet davantage depuis des devices mobiles que depuis des postes fixes. Et 90 % du temps passé sur les mobiles est capté par les applications. L’équation est donc très simple : il faut être, au minimum, compatible avec le mobile (responsive), adaptive (sélectionner les fonctionnalités à faire apparaître quand on se connecte depuis un mobile) et, à terme, proposer une application. Cela fait sens pour certains usages du manager : commande ou renouvellement de noms de domaine, monitoring d’un serveur… »
Autre challenge : sauter sur les prochaines innovations technologiques. « Nous avons fait le choix de frameworks jeunes et dynamiques, dont l’évolution est très rapide, justifie Jean-Philippe. AngularJS propose déjà une version 2.0, très prometteuse, notamment parce qu’elle embarque un transpiler. Cela nous permettra de livrer une première application mobile hybride (basée sur le même code source que le manager web), et d’utiliser la norme ECMAScript 6, sur laquelle se basent Javascript 2015 et Typescript. » Rapide pour développer, et léger à exécuter, ce langage n’a aujourd’hui pour seul inconvénient de n’être pas pris en charge par l’ensemble des navigateurs (cf. tableau ci-dessous). « En résumé, AngularJS 2.0 nous permettra de proposer les fonctionnalités de demain dans les navigateurs d’hier – mais pas d’avant-hier ! Et s’il faut faire des choix, sommes persuadés qu’il ne faut plus freiner l’adoption des innovations en raison des risques d’incompatibilité avec d’anciennes versions des navigateurs web. En tant qu’acteur de premier plan du Web, nous avons même le devoir de pousser les utilisateurs à mettre à jour leurs navigateurs. Cela profitera à tous. »

La compatibilité d'une fonction ECMAScript 6 (let) en fonction des différents navigateurs web, fournie par le site http://caniuse.com (vert = compatible ; vert clair = compatibilité non garantie ; rouge = non compatible)
La compatibilité d’une fonction ECMAScript 6 (let) en fonction des différents navigateurs web, fournie par le site http://caniuse.com (vert = compatible ; vert clair = compatibilité non garantie ; rouge = non compatible)

L’UX, une équipe pluridisciplinaire, entre la France et le Québec

L’équipe UX d’OVH est répartie entre Roubaix, le siège social d’OVH, Rennes et Québec, où l’hébergeur a ouvert un bureau en avril 2015. « Notre implantation à Québec permet d’attirer des profils issus du monde du jeu vidéo, explique Pierre Leroux, VP UX chez OVH, qui fut lui-même producteur de jeu, chez Ubisoft notamment. Le secteur du Game était, et demeure, précurseur en matière de tests utilisateurs. Nous essayons de mettre à profit cette expérience chez OVH. » De plus, l’équipe UX est la première équipe chez OVH réunissant les compétences d’ergonomes, de développeurs, de testeurs…
Convaincue par les bienfaits de l’agilité, la team UX expérimente également la collaboration à distance, grâce aux outils de téléprésence, ou encore la liberté de choix de l’IDE pour chaque développeur : « Notre mission est de faire en sorte que nos clients aient l’expérience la plus fluide et agréable possible. Pour y parvenir, nous commençons par donner un maximum de liberté aux développeurs dans le choix de leur outil de travail. Innovation is Freedom! » résume Kevin. « On parle beaucoup de l’Internet of Things. Notre vision, c’est l’Internet of People, construit conjointement par l’utilisateur et le développeur. »

Copywriter at OVH.