Libéré, délivré : le code de l’espace client OVH enfin open sourcé

Temps de lecture estimé : 9 minute

Annoncée lors du Summit 2016, la libération du code source de l’espace client OVH est maintenant une réalité. Chacun peut dorénavant participer à son évolution, via notre GitHub. Open sourcer cette application historique d’OVH — il s’agit de l’interface permettant à un utilisateur de gérer au clic l’ensemble de ses services — fut une grande aventure. Nous revenons sur cette expérience, et ce qu’elle nous a appris. Par l’équipe UX.

Pourquoi libérer le code ?

Parallèlement à la libération de l’organisation managériale d’OVH,  une autre libération se préparait chez OVH depuis quelques mois : celle de notre espace client. Celui-là même qui constitue la pierre angulaire des services OVH, le passage obligé de tout client pour administrer ses services… et concentre donc naturellement une grande partie des efforts de l’équipe UX (User eXperience). En tant que développeurs dédiés à l’expérience utilisateur, nous considérons que la démarche d’open sourcer le code a de nombreux avantages. Des avantages qui renforcent notre conviction profonde que l’open source est devenu un standard incontournable de l’IT professionnel.

L’esprit communautaire anime OVH depuis ses débuts. Autant que possible, nous avons toujours été à l’écoute des besoins, suggestions et critiques des utilisateurs. C’est ainsi que nous avons grandi. Il était temps de franchir une nouvelle étape, en ouvrant la voie au développement collaboratif. Ensemble, nous sommes plus efficaces pour augmenter la qualité globale de l’espace client. Nous le constatons d’ores et déjà avec la détection de bugs, encouragée par notre programme bug bounty lancé à l’été 2016, ou la correction des fautes d’orthographe constatées dans l’interface, et régulièrement dénoncées, avec plus ou moins de clémence, sur les réseaux sociaux par de zélés disciples de Bernard Pivot. Surtout, la communauté peut apporter de nouvelles idées, autant sur le plan technique qu’ergonomique. Avec un atout de poids : cet espace client, pour l’utiliser tous les jours ou presque, vous en êtes de fins connaisseurs. L’objectif est donc d’adapter notre feuille de route pour les développements ultérieurs de l’espace client en fonction de vos besoins.

La libération du code source, est aussi synonyme d’une plus grande transparence, à travers la mise à disposition d’un changelog, des commits et autres labels GitHub. Autant d’éléments qui vous permettent de connaître à chaque instant la direction prise par le projet, et de peser sur son évolution.


Faciliter la contribution

La première démarche pour permettre la contribution fut d’ouvrir les sources. Plus simple à dire qu’à faire : l’espace client OVH est un projet qui possède une longue histoire et, fatalement, accusait une dette technique considérable sur certains aspects. Le chantier le plus spectaculaire fut donc invisible pour vous. Voyons comment nous nous y sommes pris.

Des guidelines ouvertes aux suggestions

Impossible de coopérer sans fournir un cadre. Il était donc primordial de rédiger une documentation claire. Son objectif : assurer l’homogénéité de l’ensemble de nos dépôts, tant au niveau du code que sur le plan de la méthodologie de contribution. Pas assez précise, la documentation peut s’avère inutile. Trop lourde et restrictive, elle peut rendre la contribution fastidieuse. Pas évident de trouver le juste équilibre ! Pour cette raison, nos guidelines sont, elles aussi, ouvertes à vos suggestions.

Ces guidelines communautaires contiennent les fichiers suivants :

  • README.md : synthèse du formalisme attendu sur nos dépôts ;
  • CODE_OF_CONDUCT.md : définition des règles de bonne conduite entre contributeurs ;
  • CONTRIBUTING.md : il s’agit de notre gros bouquin poussiéreux, listant l’ensemble des règles nécessaires à la contribution pour chacun de nos projets.
  • ISSUE_TEMPLATE.md : template GitHub permettant de pré-remplir le formulaire de déclaration d’issue. Cela permet de traiter rapidement les issues grâce à un format similaire ;
  • PULL_REQUEST_TEMPLATE.md : identique à l’ISSUE_TEMPLATE, mais pour les pull requests ;
  • LICENSE.md : précise la licence standard « BSD 3-clause » à utiliser dans les projets.

Une boîte à outils

En plus de ces guidelines, nous proposons plusieurs outils pour faciliter le respect de celles-ci :

<emoji> <type>(<scope>): <subject>
<BLANK LINE>
<body>Espace Client Le Blanc
<BLANK LINE>
<footer>

Nous nous sommes bien sûr inspirés de normes existantes, telles que celles d’Angular, afin de créer un environnement familier pour les contributeurs.

  • Générateur de changelog : il s’agit d’un script Node.js permettant de générer un changelog au format standard. La génération se fait grâce au format spécifique des messages de commits.
Example de changelog. Ici le chatbot.

 

  • Un « linter » JavaScript et un « linter » stylesheet : il s’agit d’outils vérifiant la syntaxe et le format du code, afin qu’ils soient similaires sur un maximum de dépôts. La lecture du code est simplifiée si elle n’achoppe pas sur des syntaxes trop exotiques : il est alors plus aisé de se concentrer sur le code lui-même.

Ces outils, en plus du code lui-même, constituent autant d’éléments auxquels se familiariser avant de pouvoir contribuer. C’est pourquoi nous facilitons l’installation de l’espace client grâce au standard Makefile, connu de tous. Deux commandes sont donc essentielles :

make install
make dev

Nous n’allons rien vous apprendre : la première commande installe les dépendances nécessaires au fonctionnement de l’espace client. La seconde lance l’environnement de développement. Ensuite… « il n’y a plus qu’à ! »


Dépoussiérage du code : une étape fastidieuse et indispensable

Comment avons-nous procédé pour libérer le code ? Voici les grandes étapes.

Pour que l’espace client fonctionne, un ensemble de briques logicielles, que nous appelons composants, est nécessaire. Pour libérer ces briques, 53 dépôts GitHub ont été créés, avant d’être publiés sur NPM et Bower. Rendre open source autant de composants est une tâche fastidieuse, surtout que le code ne correspondait pas toujours aux standards actuels de qualité. Pour le dire de façon moins politiquement correcte : certaines portions de code étaient sacrément moches, et méritaient un petit relooking (qu’on nous jette la première pierre !).

Une fois ce toilettage du code réalisé, les briques essentielles ont été publiées. Puis nous avons choisi de rendre l’espace client Télécom disponible sur GitHub. Pourquoi l’espace client Télécom ? Étant la partie la plus récente de l’espace client, le manager Télécom comportait la moins grande part de code dit « legacy ». Peu de refactoring nécessaire : le plus gros du travail consista à s’assurer qu’aucun commentaire ou bout de code ne puisse être à l’origine de failles de sécurité, ne soit obsolète ou contienne des commentaires internes à OVH. Une fois cet espace client libéré, suivit le manager Cloud. La même méthodologie fut appliquée, en raison des similitudes architecturales dans le code des managers Cloud et Télécom.

L’héritage machiavélique de l’espace client Web

Deux espaces client ont accumulé un retard technique tel que leur publication en l’état était impossible : le manager web et le manager serveur dédié.

« Le possible est déjà fait. L’impossible est en cours. Pour les miracles, prévoir 48h de délai. » Vous connaissez sans doute cet aphorisme, qui prend tout son sens dans l’informatique quand on caresse l’idée d’éponger une dette technique creusée avec amour pendant près de 19 ans par une armée de développeurs. Nous avons décidé de donner un coup de frais à ces parties les plus anciennes de l’espace client, en commençant par celle qui a l’histoire la plus riche (et mouvementée) : le manager Web. Pour vous donner une idée, nous parlons de 32 000 lignes de JavaScript environ, 800 templates HTML et une palanquée de fichiers CSS. Autant dire qu’il ne s’agissait pas de repeindre les murs en blanc et de changer la moquette. Un tel chantier ne se réalise pas en une seule enjambée, mais en plusieurs petits pas maîtrisés.

Nous avons d’abord réusiné le code. Et tout devait y passer, notamment les fichiers JavaScript et leur migration en ES6 et AngularJS supérieur à 1.3, de sorte à correspondre à des normes plus actuelles. Et plus usuelles pour la communauté amenée à travailler sur le projet GitHub. Afin d’éviter toute régression, nous nous sommes aidés d’outils comme « prettier » et « SonarJS ». Ils sont d’une grande aide pour la détection de bugs et l’homogénéisation des fichiers.

Ensuite, ce fut au tour de fichiers HTML de bénéficier d’une cure de jouvence. Là encore, nous avons simplifié le DOM et migré le projet sur les mêmes librairies que les managers Télécom et Cloud, telles que Bootstrap 3. Cette phase de mise à niveau se terminant, nous appliquons désormais le processus décrit plus haut et utilisé pour open sourcer les espaces client Cloud et Télécom. Il en sera de même pour l’espace client Dédié dans les mois à venir.

Les composants utilisés par le manager Web seront publiés sur GitHub, de sorte à pouvoir mettre à disposition le code courant septembre 2017.


Make the fork be with you

Vous l’aurez constaté, libérer le code de l’espace client OVH est un chantier dont seules les fondations sont en train d’être achevées. Les prochaines étapes seront autant de moments importants pour la communauté et ceux qui souhaitent prendre part à ce projet.

L’un de nos objectifs est de permettre à chacun de forker l’espace client OVH et de le déployer sur sa propre infrastructure. Qu’il s’agisse d’adapter l’espace client à des usages très spécifiques ou d’en créer une version en marque blanche, l’espace client est à vous !

Vous l’avez sans doute remarqué : nous parlons de l’espace client OVH, mais en réalité il s’agit de plusieurs bases de code, chacune correspondant à un univers de produits OVH : Télécom, Cloud, Web, Dédié. Ceci s’explique par une organisation aujourd’hui révolue. Cette séparation des différents univers de produits au niveau de l’espace client a eu pour conséquence les divergences techniques et ergonomiques que vous avez tous constatées, et contre lesquelles vous avez souvent pesté.

Nous allons, dans les mois qui viennent, travailler à l’unification technique et ergonomique des espaces client OVH. Ceci afin de procurer l’expérience utilisateur et développeur la plus agréable possible.

L’aventure continue. Avec vous !

Copywriter at OVH.