Speakers : Sofia Calcagno et Emmanuel-Lin Toulemond

« Un architecte est souvent vu comme quelqu’un qui arrive avec un plan prédéfini à implémenter dans une durée de 6 à 10 mois »

Néanmoins, cette vision freine l’amélioration continue. Dans leur Talk Sofia Calcagno et Emmanuel-Lin Toulemonde, tous deux Consultants et Architecte Data au sein d’Octo Technology, nous présentent comment mettre en place une architecture émergente. À l'opposé de cette première vision, une architecture émergente encourage la mise en place des briques d'infrastructure du logiciel en même temps que sa construction.

Pour nous faire comprendre comment se passe réellement la conception d’une architecture émergente “sous le capot” ils nous proposent une démarche en 4 étapes  :

1. Expliquer le problème auquel nous répondons
2. Explorer les différentes solutions envisageables
3. Choisir et motiver le choix d’une solution
4. Dessiner en direct l’architecture associée au choix retenu

Ce processus sera ainsi répété plusieurs fois pour au final se retrouver avec une infrastructure globale répondant à toutes les problématiques rencontrées.

Durant ce talk, Sofia et Emmanuel-Lin utilisent un cas fictif comme support qui est celui de l'implémentation d’un site Web de type place de marché permettant l’achat d’offres culturelles (concerts, visites de musée, places de cinéma…).

Dans le but de proposer un système de recommandations d'offres culturelles diversifiées, le métier veut intégrer un algorithme de recommandations sur la page d'accueil de l'application web.

L’objectif est d’optimiser deux choses :

• Le nombre de ventes.
• La diversité des offres achetées.

Afin de mesurer la performance de notre recommandation, nous nous baserons sur le % d’utilisateurs qui achètent au moins deux offres de types différents dans le mois.

Une fois le besoin bien compris, l’idée est d’itérer sur le processus présenté ci-dessus autant de fois que nécessaire, jusqu’à la création d’une architecture optimale (répondant à toutes nos problématiques).

Chaque itération aura pour but de résoudre un problème que l’itération précédente ne traite pas. Durant ce talk, les speakers nous proposent de suivre le cheminement qui les auraient amenés à construire cette infrastructure, en dessinant au fur et à mesure leur schéma d'infrastructure.

Première itération :

Expliquer :

Pour la première itération, l’idée est de valider dans un premier temps l’hypothèse métier qui implique la création de toute notre infrastructure. Nous voulons optimiser la quantité et la variété des ventes, mais est ce que l’algo de recommandation est la solution : Les recommandations intéressent-elles les utilisateurs ?

Exploration :

Une fois le premier problème posé, nous pouvons passer à la phase d’exploration.

Sofia et Emmanuel-Lin posent ainsi les premières solutions qui leur viennent en tête :

Choisir :

Une fois les différentes solutions posées, nous devons choisir celle que nous utiliserons.

Pour cela, nous adopterons celle qui est la moins coûteuse à mettre en place, car si l’hypothèse de départ s'avère fausse, aucune infrastructure ne sera à créer.

Ainsi, le choix se porte sur une solution qui minimise :

• Le coût de développement de notre Algo de recommandation : On n’utilisera pas de ML pour faire la recommandation, mais simplement un top 5 des offres culturelles achetées par les utilisateurs.

• L’intégration de celui-ci : On enverra simplement nos recommandations par mail à nos clients.

Grâce à cette solution, on simplifie le problème et l’intégration, nous pouvons ainsi tester simplement notre hypothèse métier. L’exploration ainsi que les choix fait à chaque itérations sont enregistrés dans ce que l’on appelle un ADR (Architecture Decision Record), ce document permettra aux personnes qui arrivent a posteriori sur le projet de comprendre le chemin de pensée et donc les choix qui ont permis la construction de l’architecture.

Dessiner :

Il ne nous reste maintenant plus qu’à dessiner notre infra qui comporte :

• Une base de données contenant les offres
• Une base de données client contenant les mails utilisateurs
• Un script qui récupérera les offres et les enverras à notre système d'emailing
• Un service d’emailing

Toujours dans un désir de simplifier l’infrastructure de notre première itération, le script sera exécuté en local et les interactions entre nos briques seront faites manuellement.

Voici le résultat de la première itération de l’infra :

Suite à notre premier test, nous avons un feedback métier positif : Les clients sont réceptifs à la campagne d’emailing !

Nous pouvons donc passer à l’itération suivante.

Deuxième itération :

Expliquer :

Maintenant, que nous avons la certitude que notre service de recommandation a fonctionné pour la première itération, il convient de se demander si c’était un coup de chance ou si cela se vérifie également dans le temps : Les recommandations sont-elles pertinentes dans le temps ?

Exploration :

Pour cela, plutôt que de passer chaque jour du temps à exécuter les scripts, les speakers nous proposent d’automatiser l’infrastructure afin de la tester dans le temps.

Choisir :

Le choix 1 d’intégrer le top 5 des ventes directement dans la web app semble un peu prématuré. On choisira plutôt d’automatiser la newsletter pour ainsi avoir un système autonome sans entrer dans l’infrastructure de la web app.

Dessiner :

Pour automatiser ce système, nous hébergerons simplement les différentes briques sur un cloud provider puis nous automatiserons le lancement du script. Pour s’assurer que la recommandation est fiable dans le temps, on ajoute également un système de dashboarding permettant le stockage et la visualisation des métriques de notre système de recommandation.

À la fin de cette étape, nous sommes en capacité d'affirmer que la recommandation fonctionne. Nous pouvons nous lancer dans l'amélioration de cette infrastructure et la rendre la plus adéquate possible à notre besoin.

Maintenant que nous avons bien compris comment fonctionne ce processus en 4 étapes, nous allons voir les itérations suivantes de façon plus succincte pour ainsi arriver à notre infrastructure finale.

Troisième itération :

Le problème suivant rencontré est que les offres recommandées ne correspondent pas géographiquement aux utilisateurs (ex: Un Lyonnais se retrouve avec des recommandations d'offres sur la ville de Paris).

Pour cela nous ajoutons un module prenant en compte la distance entre l’offre culturelle et le lieu de résidence de l’utilisateur.

Quatrième itération :

Suite à cet ajout, notre métrique (% d’utilisateurs ayant réservé deux offres culturelles différentes) augmente. Nous avons donc maintenant un système de recommandation dans lequel nous avons confiance et qui est relativement efficace.

Fort de cette confiance que nous accordons à notre système de recommandation, nous souhaitons l’intégrer directement à l’application web, supprimant ainsi la méthode d’emailing devenue redondante avec l'application elle-même. Pour cela, nous prenons la décision de créer une nouvelle route d’API qui va nous permettre de découpler notre infrastructure. On pourra ainsi mieux piloter les besoins liés à notre système qui à moyen terme embarquera du Machine Learning pouvant nécessiter des ressources particulières (GPU, CPU). Grâce à cette API, les recommandations sont mises à disposition d’une partie des utilisateurs (Canary déploiement) directement sur l’application web.

A ce niveau d’itération, notre schéma d’architecture a déjà bien évolué, voici à quoi il ressemble :

Cinquième itération :

Suite au déploiement de notre service à de nombreux utilisateurs, nous nous retrouvons face à un nouveau problème, le service de calcul de distance mis en place devient très coûteux suite au multiple appel qu’on lui fait : la facture explose !

Coder ce calcul de distances pour ne plus utiliser l’API semble être une première solution, mais un peu complexe à mettre en place. Notre choix se porte donc plus vers la mise en place d’un cache sur les distances calculées, solution plus simple et moins coûteuse.

Sixième itération :

À ce niveau, le moment est venu d’améliorer le système de recommandation qui est toujours une simple proposition du top 5 des offres vendues.

Septième itération :

Notre infrastructure est à présent assez mature pour accueillir du Machine Learning. L’implémentation de cette brique est très simple, il nous suffit de remplacer le générateur des 5 meilleures ventes par notre modèle de ML.

Pour finir, comme la quasi-totalité des modèles de Machine Learning en production, sa performance se dégrade dans le temps.

Nous allons donc pouvoir intégrer à notre infra une brique de réentrainement automatique qui permettra à notre système de toujours proposer les meilleures recommandations à nos utilisateurs.

Voici comment au fil des itérations Sofia et Emmanuel-Lin ont pu concevoir une infrastructure s’adaptant parfaitement à notre besoin. À noter que si de nouveaux problèmes apparaissent, nous pouvons itérer à nouveau dans le but de les résoudre :

Architecture final

Takeaways :

• Commencer par valider des hypothèses métiers.
• Commencer simple et manuel avant de partir sur plus complexe.
• Afin de :
  • Livrer de la valeur rapidement
  • Limiter les a-priori
  • Piloter la technique par les besoins
• Le Machine Learning est intéressant lorsque vous avez déjà validé l’usage et que les règles métiers ne suffisent plus.