Mission Colissimo
Source : La Poste
Contexte
Ma mission a été effectuée pour La Poste Colis, un client important et historique d’Artik Consulting. Dans cette mission, j’ai intégré la Squad 1 pour la refonte du projet « Webhook ». Cependant, ce projet n’est pas le seul sur lequel la Squad travaille. Une squad est un concept agile où une équipe de projet de petite taille, avec un ou plusieurs projets assignés, est autonome et polyvalente, avec les différents rôles métiers présents.
Source : Tuleap
La Squad travaille sur les projets qui concernent Colis 360. Colis 360 est un projet de Colissimo permettant de centraliser les informations que Colissimo reçoit de la part de tiers travaillant avec La Poste Colis. Les différents tiers ont leurs propres méthodes et formats de message. Par exemple, un sous-traitant chargé du transport de colis entre les centres de tri et les centres de livraison a un format différent de celui du transporteur final vers le client. Ces messages sont totalement différents mais ont un but similaire.
Avec les différents messages centralisés vers un même format où toutes les informations des différents tiers sont présentes, on peut alors les exploiter pour assurer un meilleur suivi colis ou pour des applications tierces.
Projet Webhook
Contexte Initial
Avant que le projet « Webhook » ait été créé, il existait uniquement deux solutions pour exposer les données des suivis aux clients :
Échanges de Données Informatisés (EDI) : Les processus permettant l’échange d’informations entre les SI d’entreprises différentes. Pour faire fonctionner ces processus, il faut définir des normes entre ces entreprises, ce qui peut demander des efforts de la part des responsables SI et des experts métiers.
Applications Web : Permettant de faire le suivi uniquement avec des requêtes de la part des clients (« Pooling »). Lors d’un suivi en temps réel, le client envoie des requêtes à une certaine fréquence pour assurer une mise à jour du statut du colis, ce qui entraîne des appels superflus. Ces solutions n’offrent aucune possibilité de personnalisation.
Source : La Poste
Objectifs du Projet Webhook
Le projet « Webhook » vise à :
- Réduire les appels des services web pour le suivi des colis.
- Proposer aux clients une alternative pour le suivi en temps réel.
- Offrir une meilleure personnalisation des suivis en fonction des besoins clients (filtrage par type, etc.).
- Diminuer les contacts avec les équipes support.
Cette solution vise des clients entreprises (B2B) tels que Amazon, Alibaba, Temu, et d’autres, des entreprises avec une forte volumétrie. Comme le nom du projet l’indique, il est basé autour de « webhooks », un rappel HTTP qui se produit lorsqu’un événement se passe. Le client n’aura plus besoin d’actualiser ou de faire des appels pour voir l’état d’avancement des colis suivis, ils sont généralement utilisés pour les notifications en temps réel.
Mécanisme de Base
Le mécanisme de base des webhooks consiste à faire une requête HTTP à une URL spécifique. Un webhook effectue un rappel HTTP vers une URL qui est configurée par le système pour recevoir des données. Alors que les API et les webhooks accomplissent tous deux la même tâche, les webhooks sont beaucoup plus efficaces pour transférer les données en réduisant de manière significative la charge de serveur par rapport aux appels API.
Une première version du projet avait pour estimation de réduire les coûts d’infrastructure en réduisant le nombre d’appels quotidiens de 5,9 millions à 1,7 million, soit une réduction du trafic de 70 %.
Refonte du Projet Webhook
Problèmes Initiaux
La version initiale du projet avait quelques problèmes :
- Le projet a été initialement prévu pour un client dans le cadre d’un MVP (Minimum Viable Product).
- Des erreurs de push vers un client affectaient les autres clients.
- On ne pouvait pas traiter des centaines de clients en prévision des besoins futurs, cette solution n’était pas scalable.
- On souhaitait remplacer le framework « Akka » (Scala/Java) par le framework Spring.
Source : Akka
Nouvelle Architecture
Dans cette nouvelle version, une nouvelle architecture a été implémentée pour répondre aux nouvelles exigences fonctionnelles telles que :
- L’exportation des données vers des formats spécifiques aux clients logistiques.
- Une gestion de la consommation des messages pour les clients.
- Différents profils d’abonnement dépendant des besoins.
- La possibilité aux clients de s’abonner à plusieurs API depuis un seul compte.
- L’implémentation d’un système de rejeu technique et fonctionnel.
Cette nouvelle architecture se concentre sur trois axes : la scalabilité, l’adaptabilité, et l’exploitabilité. Pour cela, on utilise Spring boot avec Swagger.
