DealTracker - Architecture
L'architecture de DealTracker est conçue en plusieurs parties, dont beaucoup sont hébergées chez moi dans mon homelab.
1- La couche d'accès aux données
Là où je récupère des données exploitables auprès de divers marketplaces.
L'objectif de cette partie est de collecter les données des annonces d'occasion publiées sur différents marketplaces. Ces données sont restructurées et normalisées, afin de permettre un traitement équivalent quel que soit le marketplace sur laquelle l'annonce a été publiée à l'origine.
2- Le labo IA
L'endroit où je crée des modèles de vision capable d'identifier des produits précis sur le marché de l'occasion.
Je pense que la création de ce labo IA est l'un de mes accomplissements les plus significatifs sur DealTracker. Sa maturité technologique vient d'un grand nombre d'essais et d'erreurs, de restructuration d'apprentissage et de code, de nuits passées à observer l'évolution de métriques sur Tensorboard et ajuster le procédé.
3- L'enrichissement des annonces
La couche d'inférence, où j'utilise les modèles de Machine Learning du labo pour ajouter des informations pertinentes aux annonces.
Lorsque des annonces sont collectées, nous devons l'enrichir avec notre système de Machine Learning.
C'est un procédé durant lequel nous allons:
- Télécharger les images
- Les envoyer à notre système de Machine Learning chargé de la classification
- Faire d'éventuels post-traitements sur la base du contenu textuel
- Calculer l'attractivité de l'annonce (à quel point c'est une bonne affaire selon son prix)
- La mettre à jour dans la base de données
4- La couche d'accès aux données (l'API)
Le composant backend qui rend l'information accessible au front-end
Une fois les annonces enrichies, elles sont prêtes à être affichées sur notre site internet. Pour cela, il faut que nous mettions en place une API, afin de rendre les informations sur les annonces disponibles aux clients. Je me suis naturellement orienté vers FastAPI (le framework web Python le plus à jour du moment, asynchrone par nature et bien implémenté).
J'ai peu de commentaires à faire sur cette API, qui est sommes toutes classique. Elle récupère les données, les met en cache, et les sert à la demande. Deux parties semblent particulièrement intéressantes:
La réalisation de la liste des meilleures affaires:
Qu'est-ce que la bonne affaire ? La bonne affaire, c'est une annonce:
- Publiée récemment
- Près de chez vous
- À un prix cassé
Lorsqu'un utilisateur demande à voir les bonnes annonces, ces 3 critères sont donc pris en compte et pondérées afin de fournir la liste la plus pertinente.
Le filtrage géographique:
Un utilisateur sur le site de DealTracker a la possibilité de faire un filtrage géographique, et de dire "quelles sont les annonces dans un rayon de X km autour de telle ville". Lorsqu'il fait ce filtrage, cela envoie une requête à notre API, afin de retourner une liste filtrée d'annonces.
Ce filtrage géographique des annonces est réalisé avec geopandas, une version enrichie de pandas qui est dédiée au traitement d'informations géographiques. Après avoir trouvé une liste de géodonnées vectorielles pour chacune des communes françaises, j'ai donc pu implémenter l'algorithme permettant, à partir de la localisation envoyée par l'utilisateur, de trouver toutes les annonces situées à moins de X km.
5- Le Frontend
L'interface utilisateur, optimisée pour être intuitive et agréable à utiliser.
L'objectif du Front-end, c'est de fournir une interface pour que les utilisateurs puissent accéder aux résultats de notre analyse. Cette interface doit être:
- Fluide
- Ergonomique
- Conviviale
- Optimisée pour du SEO
Pour ce site, j'ai fini par m'orientier vers du NextJS. Ce n'était pas mon premier choix, j'avais d'abord décidé de le faire en Flutter web... Une erreur terrible.
Le design est fait avec antd, et j'ai fait un véritable travail sur la hiérarchisation de l'information pertinente. Bien sûr, vous pouvez accéder au site internet sur https://www.dealtracker.org
Service de données, front-end
Pour servir les données à haute performance, j'ai mis en place une API FastAPI.
Côté Front-end, je tenais à avoir les meilleures performances possibles, je me suis donc orienté vers NextJS (app router), avec un output constitué uniquement de fichiers statiques. J'ai beaucoup travaillé sur l'interface et l'optimisation du SEO.
Cette partie m'a demandé de travailler sur des sujets divers:
- Filtrages géographiques avec Géopandas
- Design de l'API pour limiter les appels à la base de données
- Optimisation de la vitesse de service des informations au niveau du cache
- Définition des flux de données entre le front-end et le backend
- Étude des meilleures librairies front-end disponible