Loyalty Company : une plateforme de fidélisation pour les programmes de plusieurs grands comptes

Jusque-là, chaque programme était un projet dédié, construit et personnalisé pour son client. Avec MAX, d'abord appelée LWS, le groupe a choisi une seule application en marque blanche, dupliquée pour chaque client avec sa propre configuration : chaque fonctionnalité développée pour l'un profite à tous. L'équipe a déployé une instance par programme, configurée par un fichier de paramètres propre à chacun.

En janvier 2016, Innéair a posé la structure de l'application Symfony et de son API, puis, pendant dix-neuf mois, a dirigé une équipe qui a compté jusqu'à cinq développeurs et piloté la plateforme en binôme avec le product owner, sous la responsabilité du directeur technique et du directeur du numérique du groupe. D'octobre 2016 à mai 2017, l'équipe a mis en production dix programmes sur cette même plateforme, dont ceux de Michelin, d'Euromaster, de PepsiCo et de GroupAuto, puis les a livrés à chaque nouvelle version ; Innéair a elle-même préparé la configuration de production de plusieurs d'entre eux, dont ceux de PepsiCo et d'Euromaster.

Chaque client voulait son programme à sa marque, avec ses fonctionnalités et ses règles d'accès. Selon le programme, les participants s'authentifiaient par un formulaire, par un annuaire LDAP, par l'authentification unique (SSO) de leur entreprise ou par un lien signé. Innéair a piloté ces quatre modes et intégré elle-même les deux derniers : l'authentification unique SAML 2.0, pour des programmes comme celui de Michelin, puis la connexion par lien signé JWT depuis le système d'information du client.

MAX s'appuyait sur le système central du groupe, qui tenait le catalogue, les commandes et les comptes de points. Innéair a regroupé les modules de la plateforme dans un seul dépôt, puis a sorti le reporting dans un module qui se teste et se publie à part. Innéair a construit ce reporting : ses tableaux de bord et ses classements, comme les produits et les catégories les plus commandés, lisaient la base analytique du système central. Quelques semaines plus tard, Innéair a regroupé de la même façon les appels au système central dans un module dédié.

Un animateur pouvait créditer ou débiter des points à de nombreux participants en déposant un fichier, mais l'interface restait bloquée tant que durait le traitement. Innéair a conçu le passage de ces imports en tâches asynchrones : le fichier est découpé en tâches qu'une file de messages distribue, et un courriel prévient l'animateur à la fin. Ce nouvel import est passé en production après le départ d'Innéair.

Les versions de MAX se succédaient à un rythme soutenu. Innéair a décrit les six environnements de la plateforme : chaque branche est validée en recette avant de rejoindre une branche de développement qui doit toujours rester stable, et chaque livraison passe par une validation du client. Elle pilotait la préparation des versions, avec leurs scripts de migration et leurs notes de version, et a consolidé les tests automatisés.

Innéair a aussi écrit la documentation technique pour que chaque développeur puisse reprendre un sujet sans dépendre d'elle ; avant son départ, elle l'a restructurée et y a décrit tous les modules.

Avant MAX, Innéair a d'abord travaillé sur des projets de clients du groupe. Le premier était le site de fidélisation et de services qu'un client offrait à son réseau de plusieurs milliers de points de vente. Innéair y a pris en charge le changement de gérant d'un point de vente, détecté lors de la synchronisation nocturne avec la base du client, la réorganisation de sa hiérarchie commerciale et l'import des comptes de points.

Certains exports du back-office n'aboutissaient pas, même avec 1 Go de mémoire. Innéair les a réécrits : ils sont sortis en une ou deux minutes, avec 10 Mo au plus.

Une plateforme partagée par plusieurs clients tient par deux choses : des modules que l'on peut sortir et tester isolément, et une documentation qui permet au suivant de reprendre.