HUGO BOSS — internaliser des applications Android globales
Problème
Les applications BOSS et HUGO s'adressent à des clients dans quinze pays et huit langues, avec plus de 500 000 installations sur Google Play. Elles assurent l'e-commerce, le click-and-collect, la prise de rendez-vous en boutique et le programme de fidélité HUGO BOSS XP.
Elles étaient développées et exploitées par une agence externe. Ce montage fonctionne jusqu'au jour où l'application devient centrale pour l'activité ; à partir de là, chaque question la concernant — ce que l'on développe ensuite, à quelle vitesse, à quoi ressemble le code sous le capot — doit passer par un contrat avant de trouver une réponse.
Contrainte
Les applications ont continué de vendre sur quinze marchés pendant toute la transition. Internaliser le développement ne pouvait signifier ni une pause, ni une réécriture, ni un trimestre de livraison dégradée. La reprise devait se faire sous une activité qui continuait de tourner, et l'équipe destinée à recevoir la base de code n'existait pas encore.
Décisions
- Internaliser d'abord, améliorer ensuite. Reprendre la base de code exactement telle qu'elle était, plutôt que de voir dans la reprise un feu vert pour une réécriture. Une réécriture aurait été la décision la plus gratifiante à prendre, et la plus susceptible de mettre fin au programme prématurément.
- Constituer l'équipe Android interne à partir de zéro — recrutement, intégration, et les règles de fonctionnement dont une équipe entièrement nouvelle a besoin avant même de pouvoir avancer.
- Mettre les conventions par écrit. Conventions de code, patterns d'architecture, workflows, méthodes de travail. Avec une équipe neuve et une base de code héritée, il n'y a pas de savoir tacite sur lequel s'appuyer : c'est l'explicitation des conventions qui a permis à chacun de prendre les bonnes décisions sans qu'un ingénieur senior soit présent à chaque fois.
- Moderniser sous la contrainte de livraison, et non au lieu de livrer, pour que l'application puisse continuer d'absorber l'e-commerce, le click-and-collect, la prise de rendez-vous en boutique et les fonctionnalités de fidélité pendant que la base était remise au niveau des standards actuels.
- Découper le module unique, puis câbler l'ensemble par injection de dépendances. L'application est arrivée sous la forme d'un module unique. J'ai refait son architecture en de nombreux modules et introduit l'injection de dépendances dans les couches données et métier. Cela a apporté deux choses difficiles à obtenir autrement. Le comportement de l'application pouvait varier d'un pays à l'autre en remplaçant une implémentation, sans rien recâbler dans l'interface. Et chaque couche est devenue simulable en Kotlin pur, sans bibliothèque de mock tierce — les tests unitaires pouvaient donc s'exécuter en parallèle, plus vite, et sans les échecs intermittents qu'entraîne une infrastructure de test partagée.
Résultat
Le développement est passé d'une livraison par l'agence à une équipe interne, avec des applications restées en production sur quinze marchés du début à la fin.
Le signe le plus net que le travail a survécu au projet : les conventions, les patterns d'architecture et les méthodes de travail définis pour Android ont été adoptés par la direction dans toute l'organisation mobile. La base de code a été modernisée aux standards d'ingénierie actuels, pour que l'e-commerce, le click-and-collect, la prise de rendez-vous en boutique et le programme de fidélité HUGO BOSS XP puissent évoluer avec l'activité plutôt que contre elle.
La suite de tests est passée de rien à environ 70 % de couverture en douze mois. C'est sur ce chiffre que repose le reste : moins de défauts arrivant en production, une application plus stable, et une équipe produit qui pouvait tenter quelque chose et savoir si cela fonctionnait, sans attendre une campagne manuelle de tests de régression.
Ce que je ferais autrement
J'écrirais les conventions avant la reprise, et non après. Nous avons d'abord repris la base de code, puis documenté les méthodes de travail pendant que l'équipe se constituait encore : les premiers recrutés ont donc tranché des questions alors qu'aucun écrit ne pouvait encore leur servir de référence. Ce sont précisément ces conventions que la direction a fini par adopter dans toute l'organisation mobile — elles valaient davantage que leur place dans l'ordre des opérations ne le laissait croire, et elles auraient dû être le premier livrable de l'internalisation plutôt qu'un de ses sous-produits.